Authentication, Authorization and F. Alfano Accounting P. McCann Internet-Draft Lucent Technologies Expires: January 10, 2005 H. Tschofenig Siemens July 12, 2004 Diameter Quality of Service Application draft-alfano-aaa-qosprot-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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 January 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract 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. This QoS AAA protocol may be used between any bearer-level network element that lies on the Alfano, et al. Expires January 10, 2005 [Page 1] Internet-Draft Diameter Quality of Service Application July 2004 path of an application flow and an application server that lies anywhere in the network, allowing for a wide variety of flexible service deployment models. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. QoS Authorization for a Session . . . . . . . . . . . . . . . 7 3.1 Session Establishment . . . . . . . . . . . . . . . . . . 7 3.2 QoS Re-Authorization . . . . . . . . . . . . . . . . . . . 7 3.3 Session Termination . . . . . . . . . . . . . . . . . . . 7 4. Diameter QoS Messages . . . . . . . . . . . . . . . . . . . . 8 4.1 QoS-Request (QAR) Command . . . . . . . . . . . . . . . . 8 4.2 QoS-Answer (QAA) Command . . . . . . . . . . . . . . . . . 8 5. Diameter QoS AVPs . . . . . . . . . . . . . . . . . . . . . . 10 5.1 Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 10 5.2 Credit Control . . . . . . . . . . . . . . . . . . . . . . 10 5.3 Authentication/Authorization . . . . . . . . . . . . . . . 11 5.4 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5 Diameter QoS Application Defined AVPs . . . . . . . . . . 11 5.6 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 13 5.7 Security Considerations . . . . . . . . . . . . . . . . . 16 5.8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 17 5.9 Open Issues . . . . . . . . . . . . . . . . . . . . . . . 17 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 6.2 Informative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 A. AVP Formats . . . . . . . . . . . . . . . . . . . . . . . . . 22 A.1 RSVP to Diameter QoS AVPs Mapping . . . . . . . . . . . . 22 A.1.1 RSVP Objects for the QoS-RSVP AVP . . . . . . . . . . 22 A.1.2 RSVP Objects for the Filter-Rule AVP . . . . . . . . . 24 A.1.3 RSVP Objects for the QoS-Auth-Resources . . . . . . . 26 A.2 NSIS to Diameter QoS AVPs Mapping . . . . . . . . . . . . 26 A.3 SIP to Diameter QoS AVPs Mapping . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . 28 Alfano, et al. Expires January 10, 2005 [Page 2] Internet-Draft Diameter Quality of Service Application July 2004 1. Introduction To meet the quality-of-service needs of applications such as voice-over-IP, it will often be necessary to explicitly request resources from the network. This will allow the network to identify packets belonging to these application flows and ensure that bandwidth, delay, and error rate requirements are met. By performing admission control on individual flows, the network can avoid congestion and the resulting high packet drop rates. When bandwidth is expensive and must be carefully managed, such as in wide-area cellular networks, and/or when applications and transport protocols lack the capability or cannot be trusted to perform congestion control, explicit reservation techniques are required. A variety of protocols could be used to make a reservation request, such as: o RSVP o NSIS o Link-specific means o SIP/SDP Alfano, et al. Expires January 10, 2005 [Page 3] Internet-Draft Diameter Quality of Service Application July 2004 +------+ +------+ | Subs | | | | DB | | AS | | | | | +---\--+ +---/--+ \ / \ / /-\----------/\ //// \\\\ || || | AAA Cloud | || || \\\\ //// \-------+-----/ | +---+--+ Application | | Flow ===============+ BE +==========>> | | +------+ Figure 1: An architecture supporting QoS-AAA Figure 1 depicts a bearer element through which application flows need to pass, a cloud of AAA servers, a database containing subscriber records, and an application server. Here the term "AAA Cloud" is used to refer to the network of AAA proxy/broker arrangements that may be in place. Also, note that there may be more than one bearer element that needs to interact with the AAA cloud along the path of a given application flow, although the figure only depicts one for clarity. Similarly, a given user may have subscriber records stored in more than one place and might make use of multiple application servers. In the simplest case, bearer elements will request authentication and authorization for QoS from the AAA cloud, which will route the request to the home network and consult a static subscriber record of the endpoint making the request and 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 bearer element and AAA cloud would be identical in both cases. Bearer elements 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. Alfano, et al. Expires January 10, 2005 [Page 4] Internet-Draft Diameter Quality of Service Application July 2004 This document describes a Diameter Application protocol that is used for AAA in an environment where user applications request better than best effort Quality of Service. This Diameter QoS application protocol when combined with [RFC3588], satisfies the QoS related requirements defined in [I-D.alfano-aaa-qosreq]. This document first describes the operation of a Diameter QoS application. Then it defines the Diameter message Command-Codes. The following sections enumerate the AVPs used in these messages. 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]. 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. Alfano, et al. Expires January 10, 2005 [Page 5] Internet-Draft Diameter Quality of Service Application July 2004 2. Terminology 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]. Furthermore, we use terminology defined in [RFC3588]. Alfano, et al. Expires January 10, 2005 [Page 6] Internet-Draft Diameter Quality of Service Application July 2004 3. QoS Authorization for a Session The request for a quality of service enabled bearer starts a Diameter QoS message exchange. 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) which contains QoS authorization, accounting, and bearer gating information, or a failure code(Result-Code AVP). 3.1 Session Establishment 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] and as extended in this Diameter application. Loss of bearer information is reported using Diameter QoS defined command codes (QAR) and AVPs. 3.2 QoS Re-Authorization It is for further study whether a re-authorization capability is required. Thereby an application server can specify a period of time for which an application is authorized to use QoS resources. 3.3 Session Termination A Diameter QoS Session is terminated when the authorizing entity sends an Abort Session Request [RFC3588] to the bearer control element, either in response to a loss of bearer report, or session termination at the application layer. Alfano, et al. Expires January 10, 2005 [Page 7] Internet-Draft Diameter Quality of Service Application July 2004 4. Diameter QoS Messages This section defines new Diameter message Command-Code [RFC3588] 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 Y.1 QoS-Answer QAA XXX Y.2 4.1 QoS-Request (QAR) Command 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 user and application flow. The message MUST carry authenticating information to validate that the QAR-Request is coming from a valid bearer element. The Request SHOULD carry enough information to identify the user. If the QoS-Request is intended for a specific application server, the Request MUST include session identification AVPs. Message Format ::= < Diameter Header: XXX, REQ, PXY > < Session-Id > { Auth- Application-Id } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination Realm } { Auth-Request-Type } [ QoS-Account-Corr-Id ] [ User-Name ] [ State ] * [ AVP ] 4.2 QoS-Answer (QAA) Command 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 Alfano, et al. Expires January 10, 2005 [Page 8] Internet-Draft Diameter Quality of Service Application July 2004 authorization of the QoS resources as well as accounting and bearer gating information. ::= < Diameter Header: XXX, PXY > < Session-Id > { Auth-Application-Id } { Result-Code } { Origin-Host } { Origin-Realm } [ QoS-Auth-Resources ] [ QoS-Flow-State ] * [ AVP ] Alfano, et al. Expires January 10, 2005 [Page 9] Internet-Draft Diameter Quality of Service Application July 2004 5. Diameter QoS AVPs 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. 5.1 Diameter Base Protocol AVPs The AVPs in this section are defined in the Base Protocol, and are included here for reference. For more information, see [RFC3588]. 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. 5.2 Credit Control The AVPs in this section are defined as part of the Diameter draft [I-D.ietf-aaa-diameter-cc]. Accounting-Correlation-Id The Accounting-Correlation-Id AVP (AVP Code TBD) is of type OctetString and contains information to correlate accounting data generated produced by different components of the service, e.g. Alfano, et al. Expires January 10, 2005 [Page 10] Internet-Draft Diameter Quality of Service Application July 2004 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. 5.3 Authentication/Authorization 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], [I-D.ietf-aaa-diameter-sip-app] and [I-D.ietf-aaa-diameter-nasreq] The details of the required attributes for authentication and authorization is for further study. 5.4 Accounting Applications implementing this specification use Diameter Accounting as defined in the draft [I-D.ietf-aaa-diameter-cc]. The Diameter QoS Application uses a Credit Control Application AVP in its QAR message to specify an Accounting-Correlation ID. 5.5 Diameter QoS Application Defined AVPs 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. 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 | | | | | | Resources | | | | | | QoS-Filter-Rule XXX 4.3 IPfltrRul | | | | | | QoS-Flow-State XXX 4.3 Enumerated | | | | | | QoS-SDP XXX 4.3 OctetString | | | | | | QoS-RSVP XXX 4.3 OctetString | | | | | | QoS-NSIS XXX 4.3 OctetString | | | | | | | | | | | | -----------------------------------------+----+-----+----+-----+----+ Alfano, et al. Expires January 10, 2005 [Page 11] Internet-Draft Diameter Quality of Service Application July 2004 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 user (described by the User-Name AVP) and session (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. The QoS-Auth-Resources also defines the mandatory fields for a Users Subscription QoS Profile. These AVPs correspond to the QoS Parameters of the Application and may not be the same as the QoS parameters requested of the bearer. If this is the case, some translation from the application level parameters to the bearer level parameters may be required. QoS-Auth-Resources ::= * [ QoS-Filter-Rule ] 0*1 < QoS-SDP > 0*1 < QoS-RSVP > 0*1 < QoS-NSIS > The AVPs that are part of QoS-Auth-resource AVP are: QoS-Filter-Rule: The QoS-Filter-Rule AVP is of type IPFilterRule, 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]. QoS-RSVP: The QoS-RSVP AVP is of type OctetString. It contains the information carried in the FLOWSPEC (see Appendix A.1). 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] and [I-D.qspecteam-nsis-nslp-qspec]. Note that this work is still in progress. More specific packet format will be described in Appendix A.2 in a future version of Alfano, et al. Expires January 10, 2005 [Page 12] Internet-Draft Diameter Quality of Service Application July 2004 this document. It is for further investigation whether a more generic formation for the QoS description in SDP, RSVP 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). 5.6 Scenarios This section illustrates the interworking of NSIS (in Figure 8) and RSVP (in Figure 9) in combination with the Diameter QoS application. Figure 8 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. This response, for example, 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 3.6 of [I-D.ietf-nsis-qos-nslp]. 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 Alfano, et al. Expires January 10, 2005 [Page 13] Internet-Draft Diameter Quality of Service Application July 2004 message to the end host (such as 'Authorisation 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 8: Message flow with NSIS and Diameter QoS Application Figure 9 depicts the interaction between the SIP/RSVP aware end host in a scenario with application layer interaction. The basic Alfano, et al. Expires January 10, 2005 [Page 14] Internet-Draft Diameter Quality of Service Application July 2004 signaling exchange is similar to Figure 8 but a few differences exist. First, the Diameter QoS application needs to carry RSVP and SDP specific payloads. Furthermore, the protocol specific mechanisms caused by RSVP (e.g., receiver initiated reservations) and SIP (such as [RFC2327] and [RFC3313]) need to be considered. The message flow in Figure 9 also shows a QoS reservation in both direction - RSVP PATH/RESV messages signaling QoS information in both directions (from the Mobile Node to the Correspondent Node and vice versa). The authorization token handling of the Correspondent Node is omitted from the description. Authorization IMS Proxy Correspondent Enforcement Pt. SIP Server Node (e.g.router) Mobile Node AAA Diameter IMS SIP Proxy Server | | | | | | +-+---------+-------------------+---------+---------+-+ | | |Invite (SDP) | | | | | +---------+---------+---------> | | | | | |100 Trying | | | | | <---------+---------+---------+ | | | | | | | Invite (SDP) | | | | | | +---------> | | | | | | |100 Trying | | | | | | <---------+ | | | | | | | Invite (SDP)| | | | | | +---------> | | | | | | | 180 SDP'| | | | | | | <---------+ | | | | | |180 SDP' | | | | | | | <---------+ | | | | | | +--------+ | | | | | | | |Generate| | | | | | | | | Token | | | | | | | | +--------+ | | | | | |180 (SDP',Token) | | | | +-----------+---------+---------+---------+---------+-+ |RSVP PATH| | | | | +---------> | | | | | | | |RSVP PATH| | | +---------+--...----+---------+---------> | | | | | | | +---------+--...----+---------+---------+ |RSVP RESV| | | | | Alfano, et al. Expires January 10, 2005 [Page 15] Internet-Draft Diameter Quality of Service Application July 2004 <---------+ | | | | | | |RSVP PATH| | | | <---------+--...----+---------+---------+ |RSVP PATH| | | | | <---------+ | | | | |RESV(TOKEN) | | | | +---------> | | | | | | | RESV | | | +---------+--...----+---------+---------> | | | | | | | Diameter QoS | | | | Application | | | | Request (Token) | | | | +---------> | | | | | Diameter QoS | | | | Application | | | | Request (Token) | | | | +---------> | | | | Diameter QoS | | | | Application | | | | Response(QoS) | | | | <---------+ | | | Diameter QoS | | | | Application | | | | Response(QoS) | | | | <---------+ | | | |+--------+--------+| | | | |+QoS Authorization|| | | | || Enforcement || | | | || Decision || | | | |+--------+--------+| | | | | | | | | | | |Allow or Delete RSVP Path | | <---------0---------+---------+---------+---------> | | 200 OK | | | <---------+---------+---------+---------+---------+ | | | | | | | | | | | | Figure 9: Message flow with RSVP and Diameter QoS Application A future version of this document will describe scenarios with other authorization models. 5.7 Security Considerations This document describes a mechanism for performing authorization of a QoS reservation at a third party entity. Thereby, it is necessary to Alfano, et al. Expires January 10, 2005 [Page 16] Internet-Draft Diameter Quality of Service Application July 2004 understand 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. 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]. 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] and [I-D.tschofenig-nsis-qos-authz-issues]. 5.8 Acknowledgments The authors would like to thank Tseno Tsenov for his early implementation work of this proposal. 5.9 Open Issues During our work on this document we identified the following open issues: o The security functionality of RSVP has been analysed in [I-D.ietf-nsis-rsvp-sec-properties]. Some of the mechanisms proposed with [RFC3182] do not seem to be adquate for today's usage. Hence, there is the question which functionality should be supported by the Diameter QoS application. o This Diameter QoS application can reuse a number of other Diameter applications. This is a big advantage over other approaches. This interaction and a list of useful attributes needs to be collected and described. This aspect is for further study. o The NSIS group is currently working on QoS models. As soon as results are available it is feasible to incorporate them into this Diameter application to build a complete solution for QoS signaling which uses a backend infrastructure. o Several authorization models have been described in [I-D.ietf-nsis-qos-nslp]. Section 5.6 currently addresses only the third party approach using authorization tokens. Further work is needed to describe the details of a generic three party scenario. Alfano, et al. Expires January 10, 2005 [Page 17] o Section 3.3 describes the session termination functionality. Should a new command code for bearer gating purposes be introduced, i.e., what if the application server wants to temporarily disable the bearer without terminating the session with ASR? o Section 3.2 raises the question of a re-authorizing capability for the Diameter application. The authors think that such a re-authorization capability would be desirable (e.g., using with the RAR/RAA message exchange). Note that it would require the bearer path signaling protocol (for example RSVP or NSIS) to support network-initiated re-auth, which might not always be in place. There should be a failure code for the case where the underlying bearer signaling protocol does not support it. o The QoS-Filter-Rule is of type IPFilterRule and specifies which traffic has to experience QoS treatment. The definition of the IPFilterRule in [RFC3588] does not explicitly list the capability to support IPsec protected traffic. Such a flow identifier description is required with NSIS and [RFC2207]. Alfano, et al. Expires January 10, 2005 [Page 18] Internet-Draft Diameter Quality of Service Application July 2004 6. References 6.1 Normative References [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, . 6.2 Informative References [I-D.alfano-aaa-qosreq] Alfano, F., McCann, P., Towle, T., Ejzak, R. and H. Tschofenig, "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-05 (work in progress), May 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-16 (work in progress), June 2004, . [I-D.ietf-aaa-diameter-sip-app] Garcia-Martin, M., "Diameter Session Initiation Protocol (SIP) Application", draft-ietf-aaa-diameter-sip-app-02 (work in progress), April 2004, . [I-D.ietf-aaa-eap] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", draft-ietf-aaa-eap-08 (work in progress), June 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-03 (work in progress), May 2004. Alfano, et al. Expires January 10, 2005 [Page 19] Internet-Draft Diameter Quality of Service Application July 2004 [I-D.ietf-nsis-rsvp-sec-properties] Tschofenig, H. and R. Graveman, "RSVP Security Properties", draft-ietf-nsis-rsvp-sec-properties-04 (work in progress), February 2004, . [I-D.qspecteam-nsis-nslp-qspec] Ash, J., Bader, A. and C. Kappler, "QoS-NSLP Qspec Template", draft-qspecteam-nsis-nslp-qspec-00 (work in progress), May 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, . [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997, . [RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997, . [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997, . [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998, . [RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000, . [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001, . Alfano, et al. Expires January 10, 2005 [Page 20] Internet-Draft Diameter Quality of Service Application July 2004 [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. Authors' Addresses 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 Alfano, et al. Expires January 10, 2005 [Page 21] Internet-Draft Diameter Quality of Service Application July 2004 Appendix A. AVP Formats 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]) 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.1 RSVP to Diameter QoS AVPs Mapping The following RSVP objects need to be mapped to the Diameter QoS AVPs: FLOWSPEC, FILTER_SPEC and POLICY_DATA. The FLOWSPEC defines a desired QoS, in a Resv message. FILTER_SPEC defines a subset of session data packets that should receive the desired QoS (specified by a FLOWSPEC object), in a Resv message. POLICY_DATA carries information about the user requesting QoS resources. A.1.1 RSVP Objects for the QoS-RSVP AVP The QoS-Flow-state AVP has to carry QoS specific information. This section describes payloads which are relevant for the transport of RSVP QoS specific payloads. The subsequently listed RSVP objects are taken from [RFC2210] and [RFC2205]. For completeness we list these attributes in this section. The RSVP FLOWSPEC object, including the RSVP object header, for requesting Controlled-Load Service is described below: Alfano, et al. Expires January 10, 2005 [Page 22] Internet-Draft Diameter Quality of Service Application July 2004 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 The RSVP FLOWSPEC object, including the RSVP object header, for requesting Guaranteed Service is described below: Alfano, et al. Expires January 10, 2005 [Page 23] Internet-Draft Diameter Quality of Service Application July 2004 31 24 23 16 15 8 7 0 +---------------+---------------+---------------+---------------+ | Length (44 bytes) | Class = 9 | C-Type =2 | +---------------+---------------+---------------+---------------+ | 0 (a) | Unused | 10 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 (c) |0| reserved | 9 (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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 130 (h) | 0 (i) | 2 (j) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rate [R] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slack Term [S] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) - Message format version number (0) (b) - Overall length (9 words not including header) (c) - Service header, service number 2 (Guaranteed) (d) - Length of per-service data, 9 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 parameter header (h) - Parameter ID, parameter 130 (Guaranteed Service RSpec) (i) - Parameter 130 flags (none set) (j) - Parameter 130 length, 2 words not including parameter header A.1.2 RSVP Objects for the Filter-Rule AVP The RSVP FLOWSPEC needs to be associated with the FILTER_SPEC to describe which traffic should experience QoS treatment. The subsequent attributes list relevant payloads used in RSVP for this purpose. These objects need to be carried in the Filter-Rule AVP. The subsequent attributes are reused from RSVP and show the Alfano, et al. Expires January 10, 2005 [Page 24] Internet-Draft Diameter Quality of Service Application July 2004 attributes that have to be supported. The IPv4 FILTER_SPEC object has the following structure: 31 24 23 16 15 8 7 0 +---------------+---------------+---------------+---------------+ | Length ( 8 bytes) | Class = 10 | C-Type =1 | +---------------+---------------+---------------+---------------+ | IPv4 SrcAddress (4 bytes) | +---------------+---------------+---------------+---------------+ | ////// | ////// | SrcPort | +---------------+---------------+---------------+---------------+ The IPv6 FILTER_SPEC object has the following structure: 31 24 23 16 15 8 7 0 +---------------+---------------+---------------+---------------+ | Length (20 bytes) | Class = 10 | C-Type =2 | +---------------+---------------+---------------+---------------+ | | + + | | + IPv6 SrcAddress (16 bytes) + | | + + | | +---------------+---------------+---------------+---------------+ | ////// | ////// | SrcPort | +---------------+---------------+---------------+---------------+ The IPv6 Flow-label FILTER_SPEC has the following structure: 31 24 23 16 15 8 7 0 +---------------+---------------+---------------+---------------+ | Length (20 bytes) | Class = 10 | C-Type = 3 | +---------------+---------------+---------------+---------------+ | | + + | | + IPv6 SrcAddress (16 bytes) + | | + + | | +---------------+---------------+---------------+---------------+ | ////// | Flow Label (24 bits) | Alfano, et al. Expires January 10, 2005 [Page 25] Internet-Draft Diameter Quality of Service Application July 2004 +---------------+---------------+---------------+---------------+ The IPv4/GPI FILTER_SPEC object, which was introduced with [RFC2207] has the following structure: +-------------+-------------+-------------+-------------+ | IPv4 SrcAddress (4 bytes) | +-------------+-------------+-------------+-------------+ | Generalized Port Identifier (GPI) | +-------------+-------------+-------------+-------------+ The IPv6/GPI FILTER_SPEC object, which was introduced with [RFC2207] has the following structure: +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 SrcAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | Generalized Port Identifier (GPI) | +-------------+-------------+-------------+-------------+ The Generalized Port Identifier (GPI) contains the SPI. A.1.3 RSVP Objects for the QoS-Auth-Resources User authentication/authorization capabilities have been added to RSVP with [RFC3182]. Additionally, a token-based authorization mechanism has been proposed with [RFC3520] and [RFC3521] which should also supported by this Diameter application. A future version of this document will map these objects to QoS-Auth-Resources AVP (or related attributes). Please also see the open issue in Section 5.9. A.2 NSIS to Diameter QoS AVPs Mapping 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] and in the area of QoS models (see [I-D.qspecteam-nsis-nslp-qspec] for ongoing work). Alfano, et al. Expires January 10, 2005 [Page 26] Internet-Draft Diameter Quality of Service Application July 2004 A.3 SIP to Diameter QoS AVPs Mapping 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 SDP payloads [RFC2327] to this Diameter application. Alfano, et al. Expires January 10, 2005 [Page 27] Internet-Draft Diameter Quality of Service Application July 2004 Intellectual Property Statement 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. Disclaimer of Validity 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 Statement 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Alfano, et al. Expires January 10, 2005 [Page 28]