| TOC |
|
This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 23, 2005.
Copyright (C) The Internet Society (2004).
This document describes a Diameter Application that performs Authentication, Authorization, and Accounting for Quality-of-Service reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources used during the life of the application flow. Clients that implement the Diameter QoS Application contact an authorizing entity/application server that lies anywhere in the network, allowing for a wide variety of flexible service deployment models.
1.
Introduction
1.1
Deployment architecture
1.2
Network element functional model
1.3
Requirements for QoS AAA protocol
2.
Terminology
3.
QoS Application messages
4.
QoS Authorization session
4.1
Authorization models
4.2
Session Initiation
4.3
Session Establishment
4.4
QoS Re-Authorization
4.4.1
Client-side initiated Re-Authorization
4.4.2
Server-side initiated Re-Authorization
4.5
Session Termination
4.5.1
Client-side initiated session termination
4.5.2
Server-side initiated session termination
5.
Accounting
6.
Diameter QoS Messages
6.1
QoS-Request (QAR) Command
6.2
QoS-Answer (QAA) Command
7.
Diameter QoS AVPs
7.1
Diameter Base Protocol AVPs
7.2
Credit Control
7.3
Authentication/Authorization
7.4
Accounting AVPs
7.5
Diameter QoS Application Defined AVPs
8.
Examples
9.
Security Considerations
10.
Contributors
11.
Acknowledgements
12.
Open Issues
13.
References
13.1
Normative References
13.2
Informative References
§
Authors' Addresses
A.
AVP Formats
A.1
NSIS to Diameter QoS AVPs Mapping
A.1.1
NSIS QSpecs Template structure
A.1.2
AVP format
A.2
SIP to Diameter QoS AVPs Mapping
§
Intellectual Property and Copyright Statements
| TOC |
To meet the quality-of-service needs of applications such as voice-over-IP in a heavily loaded network, packets belonging to real-time application flows must be identified and segregated from other traffic to ensure that bandwidth, delay, and loss rate requirements are met. In addition, new flows should not be added to the network when it is at or near capacity, which would result in degradation of quality for all flows carried by the network.
In some cases, these goals can be achieved with mechanisms such as differentiated services and/or end-to-end congestion and admission control. However, when bandwidth is scarce and must be carefully managed, such as in wide-area cellular networks, or when applications and transport protocols lack the capability to perform end-to-end congestion control, explicit reservation techniques are required. In these cases, the endpoints will send reservation requests to edge and/or interior nodes along the communication path. In addition to verifying whether resources are available, the recipient of a reservation request must also authenticate and authorize the request, especially in an environment where the endpoints are not trusted. In addition, these nodes will generate accounting information about the resources used and attribute usage to the requesting endpoints. This will enable the owner of the network element to generate usage-sensitive billing records and to understand how to allocate new network capacity.
A variety of protocols could be used to make a reservation request, including RSVP [RFC2210]Wroclawski, J., The Use of RSVP with IETF Integrated Services, September 1997., NSIS [I-D.ietf-nsis-qos-nslp]Bosch, S., Karagiannis, G. and A. McDonald, NSLP for Quality-of-Service signaling, July 2004., link-specific messaging or even SIP/SDP [RFC2327]Handley, M. and V. Jacobson, SDP: Session Description Protocol, April 1998.. This document focuses on supporting the NSIS QoS NSLP. This will have an implication on the content and format of the flow identifiers and QoS attributes that represent a particular reservation request within the Diameter QoS Application; however, other aspects of its operation should be easily generalizable to other reservation protocols. The Diameter QoS Application could be used directly in the context of these other reservation protocols, given the definition of a suitable conversion between the representations used by those protocols and the ones used by NSIS.
The Diameter QoS Application runs between a network element receiving QoS reservation requests (acting as a AAA client) and the resource authorizing entity (acting as a AAA server). A high-level picture of the resulting architecture is shown in Figure 1An Architecture supporting QoS-AAA.
+-------------+
| Resource |
| Authorizing |
| Entity |
+-----+-------+
|
|
/\-----+-----/\
//// \\\\
|| ||
| AAA Cloud |
|| ||
\\\\ ////
\-------+-----/
|
+---+--+ +---+--+ +---+--+
Application | | | | | |
===============+ NE +===+ NE +===+ NE +========>>
Flow | | | | | |
+------+ +------+ +------+
| Figure 1: An Architecture supporting QoS-AAA |
Figure 1An Architecture supporting QoS-AAA depicts network elements through which application flows need to pass, a cloud of AAA servers, and an authorizing entity. Note that there may be more than one router that needs to interact with the AAA cloud along the path of a given application flow, although the figure only depicts one for clarity. Routers will request authorization for QoS from the AAA cloud, which will route the request to the home network where the home authorizing entity will return a grant/deny decision.
In more complex deployment models, the authorization will be based on dynamic application state, so the request must be authenticated and authorized based on information from one or more application servers. If defined properly, the interface between the routers and AAA cloud would be identical in both cases. Routers are therefore insulated from the details of particular applications and need not know that application servers are involved at all. Also, the AAA cloud would naturally encompass business relationships such as those between network operators and third-party application providers, enabling flexible intra- or inter-domain authorization, accounting, and settlement.
Figure 2Network element functional model depicts a logical operational model of resource management in a router.
+-----------------------------------------------------+
| DIAMETER Client |
| Functionality |
| +---------------++---------------++---------------+ |
| | User || Authorization || Accounting | |
| | Authentication|| of QoS || for QoS | |
| +---------------+| Requests || Traffic | |
| +---------------++---------------+ |
+-----------------------------------------------------+
^ ^
v v
+--------------+ +----------+
|QoS Signaling | | Resource |
|Msg Processing|<<<<<>>>>>>>|Management|
+--------------+ +----------+
. ^ | * ^
| v . * ^
+-------------+ * ^
|Signaling msg| * ^
| Processing | * V
+-------------+ * V
| | * V
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
. . * V
| | * .............................
. . * . Traffic Control .
| | * . +---------+.
. . * . |Admission|.
| | * . | Control |.
+----------+ +------------+ . +---------+.
<-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
| Packet | | Interface | .+----------+ +---------+.
===>|Processing|====| Selection |===.| Packet |====| Packet |.=>
| | |(Forwarding)| .|Classifier| Scheduler|.
+----------+ +------------+ .+----------+ +---------+.
.............................
<.-.-> = signaling flow
=====> = data flow (sender --> receiver)
<<<>>> = control and configuration operations
****** = routing table manipulation
| Figure 2: Network element functional model |
Processing of incoming QoS reservation requests include 3 actions: admission control, authorization and resource reservation.
Admission control local function provides information for available resources and if they are enough to fulfill requested QoS. Authorization is performed by Diameter client function which involves contacting an authorization entity, lying anywhere in the network, through the AAA cloud introduced in Section 1.1Deployment architecture. If both checks succeed, auhorized QoS parameters /they MIGHT be different from requested QoS/ are set in the Packet classifier and Packet scheduler to obtain the authorized QoS. Once the requested service is being provided, Resource management provides accounting information to the Authorizing entity using the Diameter client function.
Intended deployment architecture and functionalities put a number of requirements on the Diameter QoS application. These requirements are reviewed in details in [I-D.alfano-aaa-qosreq]Alfano, F., Requirements for a QoS AAA Protocol, October 2003.. A short list is provided here:
- Inter-domain support
In particular, users may roam outside their home network, leading to a situation where the network element and authorizing entity are in different administrative domains.
- Identity-based Routing
The QoS AAA protocol MUST route AAA requests to the authorizing entity based on the identity information given in the QoS signaling protocol.
- Flexible Authentication Support
The QoS AAA protocol MUST support a variety of different authentication protocols for verification of authentication information present in QoS signaling messages.
- Making an Authorization Decision
The QoS AAA protocol MUST exchange sufficient information between the authorizing entity and the enforcing entity (and vice versa) to compute an authorization decision and to execute this decision.
- Triggering an Authorization Process
The QoS AAA protocol MUST allow periodic and event triggered execution of the authorization process, originated at the enforcing entity or even at the authorizing entity.
- Associating QoS Reservations and Application State
The QoS AAA protocol MUST carry information sufficient for an application server to identify the appropriate application session and associate it with a particular QoS reservation.
- Dynamic Authorization
It MUST be possible for QoS AAA protocol to push updates towards the network element(s) from authorizing entities.
- Bearer Gating
The QoS AAA protocol MUST allow the authorizing entity to gate authorized application flows e.g. based on application state transitions.
- Accounting Records
The QoS AAA protocol MUST define QoS accounting records containing duration, volume (byte count) usage information and description of the QoS attributes (e.g., bandwidth, delay, loss rate) that were supported for the flow.
- Sending Accounting Records
The network element MUST send accounting records for a particular application flow to the authorizing entity for that flow or to another entity identified by the authorizing entity.
- Failure Notification
The QoS AAA protocol MUST allow the network element to report failures(such as loss of connectivity due to movement of a mobile node or other reasons for packet loss) to the authorizing entity.
- Accounting Correlation
- The QoS AAA protocol MUST support the exchange of sufficient information to allow for correlation between accounting records generated by the network elements and accounting records generated by an application server.
- Interaction with other AAA Applications
- Interaction with other AAA applications such as [I-D.ietf-aaa-diameter-cc]Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H. Hakala, Diameter Credit-control Application, August 2004. and [I-D.ietf-aaa-diameter-nasreq]Calhoun, P., Zorn, G., Spence, D. and D. Mitton, Diameter Network Access Server Application, July 2004. is required for exchange of authorization, authentication and accounting information.
This document first defines used Diameter messages and Command-Codes. Then it describes the operation of a Diameter QoS Application. The following sections enumerate the Diameter message Command-Codes and AVPs used in these messages.
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997..
- Application Server
- An application server is a network entity that exchanges signaling messages with an application endpoint. It may be a source of authorization for QoS-enhanced application flows. For example, a SIP server is one kind of application server.
- Application Endpoint
- An application endpoint is an entity in an end user device that exchanges signaling messages with application servers or directly with other application endpoints. Based on the result of this signaling, the endpoint will make a request for QoS from the network. For example, a SIP User Agent is one kind of application endpoint.
- Authorizing Entity
- The authorizing entity is that entity responsible for authorizing QoS requests for a particular application flow. This may be a AAA server (with a subscriber database) or an application server or some other entity.
- AAA Cloud
- A network of AAA proxy/broker arrangements.
Furthermore, we use terminology defined in [RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003..
| TOC |
The purposes of QoS Authorization requires definition of new mandatory AVPs and Command-Codes for the QoS Diameter application. Two new Diameter messages are defined:
Command-Name Abbrev. Code Reference QoS-Request QAR XXX 6.1 QoS-Answer QAA XXX 6.2
Also following Diameter-base messages are used:
Command-Name Abbrev. Code Reference Accounting-Request ACR 271 [RFC3588] Accounting-Answer ACA 271 [RFC3588] Re-Auth-Request RAR 258 [RFC3588] Re-Auth-Answer RAA 258 [RFC3588] Abort-Session-Request ASR 274 [RFC3588] Abort-Session-Answer ACA 274 [RFC3588] Session-Term-Request STR 275 [RFC3588] Session-Term-Answer STA 275 [RFC3588]
Diameter nodes conforming to this specification MAY advertise support by including the value of TBD in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003..
The value of TBD (TBD) MUST be used as the Application-Id in all QAR and QAA commands. The value of TBD (TBD) MUST be used as the Application-Id in all ACR/ACA commands, because this application defines new, mandatory AVPs for accounting. The value of zero (0) SHOULD be used as the Application-Id in all STR/STA, ASR/ASA, and RAR/RAA commands, because these are defined in the Diameter base protocol and no additional mandatory AVPs for those commands are defined in this document.
| TOC |
In respect to NSIS signaling, different authorization models are present. They are discussed in details in [I-D.tschofenig-nsis-aaa-issues]Tschofenig, H., NSIS Authentication, Authorization and Accounting Issues, March 2003.. From the prospective of the Diameter QoS application these models differ in authentication and authorization information that need to be carried. Here we focus on the "Tree party approach" model(Figure 5Three party approach) and its derivation "Token based three party approach"(fig-three-party-token-approach).
+--------------+
| Entity |
| authorizing | <......+
| resource | .
| request | .
+------------+-+ .
--^----------|-- . .
///// | | \\\\\ .
// | | \\ .
| QoS | QoS AAA | QoS |.
| authz| protocol |authz |.
| req.| | res. |.
\\ | | // .
\\\\\ | | ///// .
QoS --|----------v-- . .
+-------------+ request +-+------------+ .
| Entity |----------------->| BE | .
| requesting | | performing | .
| resource |granted / rejected| QoS | <.....+
| |<-----------------| reservation | financial
+-------------+ +--------------+ settlement
| Figure 5: Three party approach |
In "Tree party approach" model, a resource request by the end host is received at the router in the local network and then forwarded to the user's home network where authorization is provided. The response is then returned and resources are granted (in case of a successful authorization decision). The interaction between the visited network and the home network establishes the necessary financial infrastructure to latter charge the user for the consumed resources.
financial settlement
...........................+
Authorization V ------- .
Token Request +--------------+ / QoS AAA \ .
+-------------->| Entity | / protocol \ .
| | authorizing +--------------+ \ .
| | resource | | | | .
| +------+ request |<--+----+ | | .
| | +--------------+ |QoS | |QoS |.
| | |authz| |authz|.
| |Authorization |req.+| |res. |.
| |Token |Token| | |.
| | | | | . | .
| | \ | | . / .
| | \ | | / .
| | QoS request |-----V . .
+-------------+ + Authz. Token +--------+-----+ .
| Entity |----------------->| BE | .
| requesting | | performing | .
| resource |granted / rejected| QoS | <....+
| |<-----------------| reservation |
+-------------+ +--------------+
| Figure 6: Token based three party approach |
The token based three party approach is applicable in environments where a previous protocol interaction is used to request authorization tokens (or something similar) to assist the authorization process at the entity performing the QoS reservation. A host contacts the Authorizing entity and obtains an authorization token for a requested service prior to sending a QoS reservation request. It includes the authorization token in its reservation request and this token is used in the routers along the flow path for QoS authorization. (e.g. the authorization token is included in QoS AAA messages between the router and the Authorizing entity.)
The request for a quality of service enabled bearer starts a Diameter QoS message exchange (ExamplesExamples). The identity of the user, message authentication information, and depending on the scenario, the identity of the QoS authorizing application server and session identification information, are assembled into a Diameter QoS Authorization Request (QAR) message by the bearer control element(s) responsible for resource allocation and sent either to the identified application server, or to a supporting diameter server in the user's home realm.
The server processes the information and responds with a Diameter QoS Answer message (QAA) that contains QoS authorization, accounting, and bearer gating information. Also Session-Timeout, Auth-Lifetime and Grace-Period AVPs SHOULD be included for specifying the authorization validity period and session duration. CC-Correlation-ID and Acc-Multisession-ID AVPs SHOULD be present for accounting session binding.(Section 5Accounting) [RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003., [I-D.alfano-aaa-qosreq]Alfano, F., Requirements for a QoS AAA Protocol, October 2003..
In case of unsuccessful authorization an QAA message, including a failure code(Result-Code AVP) specifying the rejections reason, is sent which ends this session.
When the QoS authorization exchange completes successfully, the QoS Diameter application SHOULD start a session context for reporting accounting information and loss of bearer. Accounting information is reported as described in [RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003. and as extended in this Diameter application Section 5Accounting. Loss of bearer information is reported using Diameter QoS defined command codes (QAR) and AVPs.
A possible solution is taken from [RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003.:(See Open IssuesOpen Issues)
Authorization server can specify a period of time for which an application is authorized to use QoS resources and after which re-authorization is required. Authorization lifetime is specified in Authorization-Lifetime and Grace-Period AVPs included in successful authorization QAA message. In the event of Authorization-Lifetime expiration the bearer device initiates QAR/QAA message exchange for re-authorization.
At any time during the QoS session the Authorizing server MAY send Re-Auth-Request (RAR) message. The Diameter client /the bearer element/ MUST respond with Re-Auth-Answer (RAA) message. The bearer element will then send an QoS-Request message with re-authorization info.
A QoS Session may be terminated from the client side by sending a Session-Termination-Request message to the server. This action is defined in [RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003..
At anytime during a session the Authorizing Server may send an Abort-Session-Request message to the bearer control element [RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003.. Possible reasons are a response to a loss of bearer report, or session termination at the application layer.
| TOC |
Diameter QoS Application presented in this document use Diameter Accounting as defined in [RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003.. A definition of new Accounting attributes is necessary. (TBD)
After a successful QoS Authorization the router starts corresponding Accounting session by sending an Accounting-Request message. The message SHOULD contain necessary attributes to bind the current accounting session to the reported QoS session/CC-Correlation-ID AVP and Acc-MultiSession-ID AVP/. Authorizing server replies to successfully received Accounting-Request message with Accounting-Answer message which MAY contain instructions for handling of the accounting session e.g. Accounting-Interim-Interval AVPs.
After every successful re-authorization procedure the bearer element SHOULD initiate accounting message exchange.
After successful session termination the bearer element SHOULD initiate final exchange of accounting messages with the authorizing server.
| TOC |
This section defines new Diameter message Command-Code [RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003. values that MUST be supported by all Diameter implementations that conform to this specification. The Command Codes are:
Command-Name Abbrev. Code Reference QoS-Request QAR XXX 6.1 QoS-Answer QAA XXX 6.2
The QoS-Request message (QAR), indicated by the Command-Code field set to XXX and 'R' bit set in the Command Flags field, is used by bearer control elements to request quality of service related resource authorization for a given flow.
The message MUST carry information to authorize the QoS requestor. As such it is at minimum necessary to carry enough info to identify the user. If the QoS-Request is intended for a specific application server, the Request MUST include session identification AVPs.
Message Format
<QoS-Request> ::= < Diameter Header: XXX, REQ, PXY >
< Session-Id >
{ Auth- Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination Realm }
{ Auth-Request-Type }
[ User-Name ]
[ CC-Correlation-Id ]
[ State ]
* [ AVP ]
The QoS-Answer message (QAA), indicated by the Command-Code field set to XXX and 'R' bit cleared in the Command Flags field, is sent in response to the QoS-Request message. If the QoS-Request message is processed successfully, the response will include the AVPs to allow authorization of the QoS resources as well as accounting and bearer gating information.
<QoS-Answer> ::= < Diameter Header: XXX, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ QoS-Auth-Resources ]
[ QoS-Flow-State ]
* [ AVP ]
| TOC |
Each of the AVPs identified in the QoS-Request and QoS-Answer command codes and the assignment of their value(s) is given in this section.
The AVPs in this section are defined in the Base Protocol, and are included here for reference. For more information, see [RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003..
- Session-Id AVP
The Diameter QoS Application client MUST create a unique value for the Session-Id. This value serves the purpose of uniquely identifier a particular session.
- Auth-Application-Id
The Auth-Application-Id is assigned by IANA to Diameter Applications. The value of the Auth-Application-Id for the Diameter QoS Application is XXX.
- Result-Code AVP
The Result-Code AVP indicates if a particular request was completed successfully.
- Origin-Host
The Origin-Host AVP identifies the endpoint that originated the Diameter message.
- Origin-Realm
The Origin-Realm AVP contains the Realm of the originator of the Diameter message.
The AVPs in this section are defined as part of the Diameter draft [I-D.ietf-aaa-diameter-cc]Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H. Hakala, Diameter Credit-control Application, August 2004..
- CC-Correlation-Id
The CC-Correlation-ID AVP (AVP code TBD) is of type OcterString and contains information to correlate accounting data generated for different components of the service, e.g. transport and application level. In the Diameter QoS Application, this AVP is assigned a value by the Diameter QoS client and sent to the server in a QAR message.
Authentication and authorization is important for the Diameter QoS application. Therefore, a number of AVPs of related Diameter applications can be used, such as [I-D.ietf-aaa-eap]Eronen, P., Hiller, T. and G. Zorn, Diameter Extensible Authentication Protocol (EAP) Application, August 2004., [I-D.ietf-aaa-diameter-sip-app]Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C. and K. Tammi, Diameter Session Initiation Protocol (SIP) Application, October 2004. and [I-D.ietf-aaa-diameter-nasreq]Calhoun, P., Zorn, G., Spence, D. and D. Mitton, Diameter Network Access Server Application, July 2004.
The details of the required attributes for authentication and authorization is for further study.
The Diameter QoS Application uses Diameter Accounting as defined in [RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003.. Diameter base accounting AVPs and Credit-Control AVPs SHOULD be used.
- Acc-Multisession-ID
Acc-Multisession-ID AVP SHOULD be used to link together multiple related accounting sessions. This AVP MAY be returned by the Diameter server in an authorization answer, and MUST be used in all accounting messages for the given session.
This section defines the Quality of Service AVPs that are specific to the Diameter QoS Application that MAY be included in the Diameter QoS Application messages.
Description format is taken from QoS NSLP Qspec Template which is expected to cover all present QoS description methods [QOS-NSIS-QSPEC]. The template proposed there includes description of QoS Control information and requested, reserved, available and minimum QoS which are used in NSIS QoS protocol. For the authorization purposes not all of the description parameters are required e.g. only Minimum and Available QoS description MAY be used. A separate AVP MAY be specified for description of QoS in 3GPP networks scenarios.
The following table describes the Diameter AVPs in the QoS Application, their AVP code values, types, possible flag values, and whether the AVP MAY be encrypted.
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST| |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
QoS-Auth- XXX 4.3 Grouped | M | P | | V | Y |
Resources | | | | | |
QoS-Filter-Rule XXX 4.3 Grouped | M | P | | v | Y |
QoS-Flow-State XXX 4.3 Enumerated | M | P | | V | Y |
QoS-SDP XXX 4.3 OctetString | M | P | | V | Y |
QoS-NSIS XXX 4.3 OctetString | M | P | | V | Y |
IPFilter XXX 4.3 IpfltrRule | M | P | | V | Y |
SPI XXX 4.3 Unsigned32 | M | P | | V | Y |
DSCP XXX 4.3 Unsigned32 | M | P | | V | Y |
| | | | | |
-----------------------------------------+----+-----+----+-----+----+
- QoS-Auth-Resources
The QoS-Auth-Resources AVP (AVP Code N) is of type Grouped. Each individual AVP in the grouped QoS-Auth-Resources describes the value of a resource that has been authorized by an application server for a particular QoS Request (described by the Session-Id AVP). The QoS-Auth-Resources AVP is Optional, however one of QoS-Auth-Resources, or QoS-Flow-State is mandatory in a QAA message.
QoS-Auth-Resources ::= * [ QoS-Filter-Rule ]
0*1 < QoS-SDP >
0*1 < QoS-NSIS >
The AVPs that are part of QoS-Auth-resource AVP are:
- QoS-Filter-Rule
QoS-Filter-Rule::= 0*1 < IPFilter > 0*1 < SPI > 0*1 < DSCP >The QoS-Filter-Rule AVP is of type Grouped, and provides filter rules for the packet flow of the user. One or more such AVPs MAY be present in a QAA response.
- QoS-SDP
The QoS-SDP AVP is of type OctetString. It contains the SDP data from the application layer session negotiation. The format of the data is as specified in [RFC2327]Handley, M. and V. Jacobson, SDP: Session Description Protocol, April 1998..
- QoS-NSIS
The QoS-NSIS AVP is of type OctetString. It contains QoS parameter information. The format will be described in [I-D.ietf-nsis-qos-nslp]Bosch, S., Karagiannis, G. and A. McDonald, NSLP for Quality-of-Service signaling, July 2004. and [I-D.ietf-nsis-qspec]Ash, J., QoS-NSLP QSpec Template, October 2004.. Note that this work is still in progress. See Appendix A.1NSIS to Diameter QoS AVPs Mapping for a preliminary packet format.
It is for further investigation whether a more generic formation for the QoS description in SDP, and NSIS can be compiled.
- QoS-Flow-State:
The QoS-Flow-State AVP is of type Enumerated and is used in both QAR and QAA messages. When included in a QAR message, it indicates the state of the flow identified by the User-Name and Session-Id AVPs. When included in a QAA message, it is instructions to the bearer control element with regard to the state to which the flow should be set. The supported values are
0 Open 1 Close 2 Maintain
The QoS-Flow-State is an optional AVP. When not included in a QAA response, the default behavior is to immediately allow the flow of packets (Open).
- IPFilter:
The IPFilter AVP is of type IPflrtRule and represents a flow identifier used in Packet Clasifier.
- SPI:
The SPI AVP is of type Unsigned32 and together with IPFilter AVP provides support for IPsec protected traffic.
- DSCP:
The DSCP AVP is of type Unsigned32 and together with IPFilter AVP provides support for DiffServ marked traffic.
| TOC |
This section illustrates a general message flow of QoS authorization session establishment(Figure 14Diameter QoS Application session) and interworking with NSIS (Figure 15Message flow with NSIS and Diameter QoS Application).
Figure 14Diameter QoS Application session shows a session for QoS authorization established between the bearer element and authorizing entity. An incoming QoS reservation request received at the bearer node invokes sending of QoS-Request message to the Authorization server. Server replies with QoS-Answer which grants reservation of certain resources. After the successful exchange of authorization QAR/QAA messages, bearer node starts an Accounting session with sending of Accounting-Request message. Server replies with Accounting-Answer message which MAY includes instruction for further handling of the accounting session such as Acc-Interim-Period AVP. Possible Client-side Re-authorization caused by expiration of Authorization life timer initiates QAR/QAA message exchange. After successful re-authorization an accounting message ACR SHOULD be sent. Server replies to it with ACA message. Session termination is initiated from the server by sending of Abort-Session-Request message. Client responds with ASA message and Session-Termination-request message. After receiving of STA, which finalize the authorization session, from the server side, final accounting info is sent with ACR message. ACA message from the server side terminates the accounting session too.
Router(Diameter client) Diameter Server
-----------> | |
QOS | QoS-Request |
reservation |----------------------------------------------->|
request | |
| QoS-Answer/QoS-Auth-Res./ |
|<-----------------------------------------------|
| |
Start |Accounting-Request/Start,QoS Acc-Msess-ID.../ |
Accounting |----------------------------------------------->|
| Accounting-Answer/...Acc-Interim-Period.../ |
|<-----------------------------------------------|
| |
Authorization| |
LifeTime | |
Expires: | |
Re- | QoS-Request |
Authorization|----------------------------------------------->|
| QoS-Answer/QoS-Auth-Res./ |
|<-----------------------------------------------|
| Accounting-Request/Interim, Acc-Msess-ID.../ |
|----------------------------------------------->|
| Accounting-Answer/...Acc-Interim-Period.../ |
|<-----------------------------------------------|
.....................
| | Session
| | Term.
| |initiate
| |by Server
| Abort-Session-Request |<--------
|<-----------------------------------------------|
| Abort-Session-Answer |
|----------------------------------------------->|
| Session-Termination-Request |
|----------------------------------------------->|
| Session-Termination-Answer |
|<-----------------------------------------------|
Accounting | Accounting-Request/Final,Acc-Msess-ID.../ |
end |----------------------------------------------->|
| Accounting-Answer /Final,.../ |
|<-----------------------------------------------|
| Figure 14: Diameter QoS Application session |
Figure 15Message flow with NSIS and Diameter QoS Application shows the interaction between NSIS, application layer signaling (e.g., SIP) and the Diameter QoS application. First, a service request is sent from the client to the application server. In response, for example, it returns an authorization token to bind the application layer signaling exchange to the subsequent NSIS signaling session. The authorization token is attached to the NSIS signaling message and the message itself is intercepted by the first NSIS NSLP node. This router then needs to authorize the QoS request and delegates this responsibility to the Diameter QoS application. This type of authorization model is described in Section 1Introduction and Section 3.6 of [I-D.ietf-nsis-qos-nslp]Bosch, S., Karagiannis, G. and A. McDonald, NSLP for Quality-of-Service signaling, July 2004.. The Diameter QoS Authorization Request (QAR), which includes authorization information and QoS information is, in this case, forwarded to the administrative domain of the application domain for verification. As a response, the authorization decision is returned with the Diameter QoS Answer message (QAA). Finally, the NSIS QoS NLP aware router acts as an enforcement point. If the authorization decision provided with the QAA message was successful then the NSIS signaling message is forwarded along the path. Otherwise, the QoS NSLP returns an error message to the end host (such as 'Authorization denied').
Diameter QoS
Application
Enabled Router Application
Enforcement Pt Server
Application +
Client Domain 1 + Domain 2
| | + |
| Service Request (QoS) |
+------------+------------+------------->
| | + |
| | + |
| Service Response (QoS', Token) |
<------------+------------+-------------+
| | + |
| | + |
|NSIS (Token)| + |
+------------> + |
| | + |
| | -+-- |
| |QAR(Token)- + -QAR(Token)|
| +--------/> + --\-------->
| | / + \ |
| | / + \ |
| | | + | |
| | QAA(QoS) + QAA(QoS) |
| <------+--- + <---+------+
| | | + | |
| | | Diameter | |
| | \ Network / |
| | \ + / |
| | \ + / |
| Authorization \- + -/ |
| Enforcement -+-- |
| Decision + |
| | + |
| | + |
| Allow or Terminate Flow |
<-----------+*+------------------------->
| | + |
| | + |
| Figure 15: Message flow with NSIS and Diameter QoS Application |
A future version of this document will describe scenarios with other authorization models.
| TOC |
This document describes a mechanism for performing authorization of a QoS reservation at a third party entity. Thereby, it is necessary the QoS signaling protocol to forward the necessary information to the backend AAA server. This functionality is particularly useful in roaming environments where the authorization decision is most likely provided at an entity where the user is known i.e. home realm. To provide proper authorization authentication might be necessary at least for the generic third party model (described in Section 3.6 of [I-D.ietf-nsis-qos-nslp]Bosch, S., Karagiannis, G. and A. McDonald, NSLP for Quality-of-Service signaling, July 2004.. The concept of an authorization token based third party approach is also described in the same document. The impact of the existence of different authorization models is (with respect to this Diameter QoS application) the ability to carry different authentication and authorization information.
Further discussions on the authorization handling for QoS signaling protocols is available with [I-D.tschofenig-nsis-aaa-issues]Tschofenig, H., NSIS Authentication, Authorization and Accounting Issues, March 2003. and [I-D.tschofenig-nsis-qos-authz-issues]Tschofenig, H., QoS NSLP Authorization Issues, June 2003..
| TOC |
The authors would like to thank Tseno Tsenov for his contributions to this document.
| TOC |
Add your name here.
| TOC |
During our work on this document we identified the following open issues:
| TOC |
| TOC |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. |
| [RFC3588] | Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. |
| TOC |
| [I-D.alfano-aaa-qosreq] | Alfano, F., "Requirements for a QoS AAA Protocol", draft-alfano-aaa-qosreq-01 (work in progress), October 2003. |
| [I-D.ietf-aaa-diameter-cc] | Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H. Hakala, "Diameter Credit-control Application", draft-ietf-aaa-diameter-cc-06 (work in progress), August 2004. |
| [I-D.ietf-aaa-diameter-nasreq] | Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter Network Access Server Application", draft-ietf-aaa-diameter-nasreq-17 (work in progress), July 2004. |
| [I-D.ietf-aaa-diameter-sip-app] | Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C. and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", draft-ietf-aaa-diameter-sip-app-04 (work in progress), October 2004. |
| [I-D.ietf-aaa-eap] | Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", draft-ietf-aaa-eap-09 (work in progress), August 2004. |
| [I-D.ietf-nsis-qos-nslp] | Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-04 (work in progress), July 2004. |
| [I-D.ietf-nsis-qspec] | Ash, J., "QoS-NSLP QSpec Template", draft-ietf-nsis-qspec-01 (work in progress), October 2004. |
| [I-D.tschofenig-nsis-aaa-issues] | Tschofenig, H., "NSIS Authentication, Authorization and Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 (work in progress), March 2003. |
| [I-D.tschofenig-nsis-qos-authz-issues] | Tschofenig, H., "QoS NSLP Authorization Issues", draft-tschofenig-nsis-qos-authz-issues-00 (work in progress), June 2003. |
| [RFC2210] | Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997 (HTML, XML). |
| [RFC2327] | Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998 (HTML, XML). |
| [RFC2749] | Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000. |
| [RFC3313] | Marshall, W., "Private Session Initiation Protocol (SIP) Extensions for Media Authorization", RFC 3313, January 2003. |
| [RFC3520] | Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003. |
| [RFC3521] | Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003. |
| TOC |
| Frank M. Alfano | |
| Lucent Technologies | |
| 1960 Lucent Lane | |
| Naperville, IL 60563 | |
| USA | |
| Phone: | +1 630 979 7209 |
| EMail: | falfano@lucent.com |
| Peter J. McCann | |
| Lucent Technologies | |
| 1960 Lucent Lane | |
| Naperville, IL 60563 | |
| USA | |
| Phone: | +1 630 713 9359 |
| EMail: | mccap@lucent.com |
| Hannes Tschofenig | |
| Siemens | |
| Otto-Hahn-Ring 6 | |
| Munich, Bayern 81739 | |
| Germany | |
| EMail: | Hannes.Tschofenig@siemens.com |
| TOC |
This section provides a strawman proposal for the AVPs introduced by this document. Additionally, the content of the payload is described. Unlike the approach followed with RSVP (see [RFC2749]Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. and A. Sastry, COPS usage for RSVP, January 2000.) where the entire RSVP message is encapsulated into a COPS message this approach only includes the relevant fields. This approach avoids a certain overhead of transmitting fields which are irrelevant for the AAA infrastructure, it keeps implementations simpler and it allows to reuse other Diameter AVPs. Finally, it helps to make this Diameter application less dependent on any particular QoS signaling protocol or a particular QoS model.
A future version of this document will contain payload descriptions of objects introduced by the NSIS protocol suite. Relevant parameters can be found in [I-D.ietf-nsis-qos-nslp]Bosch, S., Karagiannis, G. and A. McDonald, NSLP for Quality-of-Service signaling, July 2004. and in the area of QoS models (see [I-D.ietf-nsis-qspec]Ash, J., QoS-NSLP QSpec Template, October 2004. for ongoing work).
Considering that the work on QoS parameters in [I-D.ietf-nsis-qos-nslp]Bosch, S., Karagiannis, G. and A. McDonald, NSLP for Quality-of-Service signaling, July 2004. and [I-D.ietf-nsis-qspec]Ash, J., QoS-NSLP QSpec Template, October 2004. is ongoing, this section presents a preliminary attempt for defining a structure of the AVPs for NSIS QSpec template. Issues stated in Section 7.5Diameter QoS Application Defined AVPs should be taken into account as well.
Current proposed structure of the NSIS QSpec template is defined in [I-D.ietf-nsis-qspec]Ash, J., QoS-NSLP QSpec Template, October 2004.:
- QSP ID
- QOS Control Information
- Hop Count
- Service Schedule
- QOS Description
- QOS Desired
- R - rate
- token bucket
- r
- b
- p
- m
- M
- Qos class
- Priority
- QOS Available
- non IS hop
- IS hops
- Available BW
- Min latency
- MTU
- Ctot
- Dtot
- Csum
- Dsum
- QOS Reserved
- token bucket
- R - rate
- S - Slack term
- Qos class
- Priority
- Min QoS
- token bucket
- Qos class
- Priority
For description of Token Bucket parameter from QoS Descriptions the following structure taken from [RFC2210]Wroclawski, J., The Use of RSVP with IETF Integrated Services, September 1997. MIGHT be used. For completeness the RSVP object header is not removed:
31 24 23 16 15 8 7 0
+---------------+---------------+---------------+---------------+
| Length (32 bytes) | Class = 9 | C-Type =2 |
+---------------+---------------+---------------+---------------+
| 0 (a) | reserved | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 (c) |0| reserved | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (7 words not including header)
(c) - Service header, service number 5 (Controlled-Load)
(d) - Length of controlled-load data, 6 words not including
per-service header
(e) - Parameter ID, parameter 127 (Token Bucket TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including per-service
header
This structure is taken from [RFC2210]Wroclawski, J., The Use of RSVP with IETF Integrated Services, September 1997.. For completeness the RSVP object header is not removed:
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | Unused | 19 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |x| reserved (d)| 8 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 4 (f) | (g) | 1 (h) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | zero extension of .. IS hop cnt (16-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | 6 (i) | (j) | 1 (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Path b/w estimate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | 8 (l) | (m) | 1 (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Minimum path latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 10 (o) | (p) | 1 (q) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | zero extension of .. composed MTU (16-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | 2 (r) |x| reserved (s)| 8 (t) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | 133 (u) | (v) | 1 (w) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
13 | End-to-end composed value for C [Ctot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
14 | 134 (x) | (y) | 1 (z) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
15 | End-to-end composed value for D [Dtot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | 135 (aa | (bb | 1 (cc) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17 | Since-last-reshaping point composed C [Csum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
18 | 136 (dd) | (ee) | 1 (ff) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19 | Since-last-reshaping point composed D [Dsum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | 5 (gg |x 0 (hh) | 0 (ii) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Word 1: Message Header:
(a) - Message header and version number
(b) - Message length - 19 words not including header
Words 2-7: Default general characterization parameters
(c) - Per-Service header, service number 1
(Default General Parameters)
(d) - Global Break bit (NON_IS_HOP general parameter 2) (marked x)
(e) - Length of General Parameters data block (8 words)
(f) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS
general parameter)
(g) - Parameter 4 flag byte
(h) - Parameter 4 length, 1 word not including header
(i) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH
general parameter)
(j) - Parameter 6 flag byte
(k) - Parameter 6 length, 1 word not including header
(l) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY
general parameter)
(m) - Parameter 8 flag byte
(n) - Parameter 8 length, 1 word not including header
(o) - Parameter ID, parameter 10 (PATH_MTU general parameter)
(p) - Parameter 10 flag byte
(q) - Parameter 10 length, 1 word not including header
Words 11-19: Guaranteed service parameters
(r) - Per-Service header, service number 2 (Guaranteed)
(s) - Break bit
(t) - Length of per-service data, 8 words not including header
(u) - Parameter ID, parameter 133 (Composed Ctot)
(v) - Composed Ctot flag byte
(w) - Composed Ctot length, 1 word not including header
(x) - Parameter ID, parameter 134 (Composed Dtot)
(y) - Composed Dtot flag byte
(z) - Composed Dtot length, 1 word not including header
(aa)- Parameter ID, parameter 135 (Composed Csum).
(bb)- Composed Csum flag byte
(cc)- Composed Csum length, 1 word not including header
(dd)- Parameter ID, parameter 136 (Composed Dsum).
(ee)- Composed Dsum flag byte
(ff)- Composed Dsum length, 1 word not including header
Word 20: Controlled-Load parameters
(gg - Per-Service header, service number 5 (Controlled-Load)
(hh)- Break bit
(ii)- Length of controlled-load data, 0 words not including header
QoS authorization with the Diameter QoS Application requires that also SIP specific mechanisms are exchanged via Diameter. A future version of this document will describe the mapping of QoS relevant parameters of the SDP payload [RFC2327]Handley, M. and V. Jacobson, SDP: Session Description Protocol, April 1998. to QoS parameters of the QSpec template used in this specification.
| TOC |
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.