Authentication, Authorization and F. Alfano Accounting P. McCann Internet-Draft Lucent Technologies Expires: January 19, 2006 H. Tschofenig T. Tsenov Siemens July 18, 2005 Diameter Quality of Service Application draft-alfano-aaa-qosprot-03.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a Diameter Application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) 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 Alfano, et al. Expires January 19, 2006 [Page 1] Internet-Draft Diameter QoS Application July 2005 resources consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Network element functional model . . . . . . . . . . . . . 7 3.2 Authorization models . . . . . . . . . . . . . . . . . . . 9 3.3 QoS authorization considerations . . . . . . . . . . . . . 10 4. Diameter QoS Authorization session establishment and management . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1 Session parties' functional description . . . . . . . . . 14 4.1.1 End-user initiator of the QoS signaling session . . . 14 4.1.2 QoS policy aware transport plane element functionality . . . . . . . . . . . . . . . . . . . . 15 4.1.3 Authorizing Entity functionality . . . . . . . . . . . 16 4.2 QoS authorization session re-authorization . . . . . . . . 16 4.2.1 Client-side initiated Re-Authorization . . . . . . . . 16 4.2.2 Server-side initiated Re-Authorization . . . . . . . . 16 4.3 Server-side initiated QoS parameter provisioning . . . . . 17 4.4 Session Termination . . . . . . . . . . . . . . . . . . . 17 4.4.1 Client-side initiated session termination . . . . . . 17 4.4.2 Server-side initiated session termination . . . . . . 17 5. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Diameter QoS authorization application Messages . . . . . . . 19 6.1 QoS-Authorization Request (QAR) . . . . . . . . . . . . . 20 6.2 QoS-Authorization Answer . . . . . . . . . . . . . . . . . 20 6.3 QoS-Install Request . . . . . . . . . . . . . . . . . . . 21 6.4 QoS-Install Request . . . . . . . . . . . . . . . . . . . 22 7. Diameter QoS Authorization Application AVPs . . . . . . . . . 23 7.1 Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 23 7.2 Credit Control application AVPs . . . . . . . . . . . . . 23 7.3 Authentication/Authorization AVPs . . . . . . . . . . . . 24 7.4 Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 24 7.5 Diameter QoS Application Defined AVPs . . . . . . . . . . 24 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 36 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 13.1 Normative References . . . . . . . . . . . . . . . . . . . 37 13.2 Informative References . . . . . . . . . . . . . . . . . . 37 Alfano, et al. Expires January 19, 2006 [Page 2] Internet-Draft Diameter QoS Application July 2005 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . 40 Alfano, et al. Expires January 19, 2006 [Page 3] Internet-Draft Diameter QoS Application July 2005 1. Introduction 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 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 QoS request, including RSVP [RFC2210], NSIS [I-D.ietf-nsis-qos-nslp], link-specific signaling or even SIP/SDP [RFC2327]. 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 can easily be generalized to other QoS signaling 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. Alfano, et al. Expires January 19, 2006 [Page 4] Internet-Draft Diameter QoS Application July 2005 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]. The following terms are used in this document: 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]. Alfano, et al. Expires January 19, 2006 [Page 5] Internet-Draft Diameter QoS Application July 2005 3. Framework 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 1. +-------------+ | Resource | | Authorizing | | Entity | +-----+-------+ | | /\-----+-----/\ //// \\\\ || || | AAA Cloud | || || \\\\ //// \-------+-----/ | +---+--+ +---+--+ +---+--+ Application | | | | | | ===============+ NE +===+ NE +===+ NE +========>> Flow | | | | | | +------+ +------+ +------+ Figure 1: An Architecture supporting QoS-AAA Figure 1 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, for example, to the home network where the home authorizing entity will return authorizing information. 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 Alfano, et al. Expires January 19, 2006 [Page 6] Internet-Draft Diameter QoS Application July 2005 network operators and third-party application providers, enabling flexible intra- or inter-domain authorization, accounting, and settlement. 3.1 Network element functional model Figure 2 depicts a logical operational model of resource management in a router. Alfano, et al. Expires January 19, 2006 [Page 7] Internet-Draft Diameter QoS Application July 2005 +-----------------------------------------------------+ | 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 includes three actions: admission control, authorization and resource reservation. The admission control function provides information for available resources and determines whether there are enough resources to Alfano, et al. Expires January 19, 2006 [Page 8] Internet-Draft Diameter QoS Application July 2005 fulfill the request. Authorization is performed by the Diameter client function which involves contacting an authorization entity through the AAA cloud shown in Section 3. If both checks are successful, the authorized QoS parameters are set in the packet classifier and the packet scheduler. Note that the parameters passed to the Traffic Control function may be different from requested QoS (depending on the authorization decision). Once the requested resource is granted, the Resource Management function provides accounting information to the Authorizing entity using the Diameter client function. 3.2 Authorization models With respect to NSIS signaling, different authorization models have been investigated and discussed in detail in [I-D.tschofenig-nsis- aaa-issues] and in [I-D.tschofenig-nsis-qos-authz-issues]. From the Diameter QoS application's point of view these models differ in type of information that need to be carried. Here we focus on the 'Three party approach' model (Figure 3) and the 'Token based three party approach' model (Figure 4). +--------------+ | 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 3: Three Party Approach In the 'Three party approach' model, a resource request by the end host is received at the router in the local network and then sent to Alfano, et al. Expires January 19, 2006 [Page 9] Internet-Draft Diameter QoS Application July 2005 the user's home network (after processing) 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 later 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 4: 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.) 3.3 QoS authorization considerations A QoS authorization application must meet a number of requirements applicable to a diverse set of networking environments and services. Alfano, et al. Expires January 19, 2006 [Page 10] Internet-Draft Diameter QoS Application July 2005 It should be compliant with different deployment scenarios with specific QoS signaling models and security issues. In addition, real-time signaling for QoS provisioning requires a QoS authorization application to support flexible and fast authentication and authorization methods. Satisfying these requirements while interworking with QoS signaling protocols, a Diameter QoS application should accommodate the capabilities of the QoS signaling protocols rather than introducing functional requirements on them. A list of requirements for a QoS authorization application is reviewed in details in [I-D.alfano-aaa-qosreq]. 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. Alfano, et al. Expires January 19, 2006 [Page 11] Internet-Draft Diameter QoS Application July 2005 Dynamic Authorization It MUST be possible for the 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 (i.e., enable/disable) authorized application flows based on e.g., 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 Diameter Credit Control [I-D.ietf-aaa-diameter-cc] and Diameter NASREQ [I-D.ietf- aaa-diameter-nasreq] is required for exchange of authorization, authentication and accounting information. Deployment scenarios for Diameter QoS applicatuion should be divided into Authorization_Only or Authentication_and_Authorization, depending on the service that a contacted 3-rd party Authorizing Alfano, et al. Expires January 19, 2006 [Page 12] Internet-Draft Diameter QoS Application July 2005 entity must provide. Authorization decisions are based on a provided identifier (user or application session) that must be authenticated. In cases where authentication is done a priory at the Authorizing entity or at the transport plane element by other means, (e.g., collocated application for network access (NASREQ) or authentication for secured transport channel establishment used by GIMPS [I-D.ietf- nsis-ntlp] in the NSIS, the Authorizing entity is contacted only with a request for QoS authorization. In cases where other authentication mechanisms are not present, the Authorizing entity must also authenticate the user in order to authorize the QoS request. Alfano, et al. Expires January 19, 2006 [Page 13] Internet-Draft Diameter QoS Application July 2005 4. Diameter QoS Authorization session establishment and management 4.1 Session parties' functional description Authorization models supported by this application include 3 parties: o The End-user as the initiator of the QoS signaling session. o QoS policy aware transport plane element(s) (Diameter QoS application client). o Authorizing entity (Diameter QoS application server). Note that the End-user is an indirect participant in the QoS authorization session and is not directly involved in the Diameter QoS application session. The End-user may communicate with the Authorizing entity via off-path application level signaling. The End-user communicates with the QoS policy aware network element(s) via the QoS signaling protocol. Considering its indirect role in the Diameter QoS application session, we briefly include its functional description for clarification purposes. 4.1.1 End-user initiator of the QoS signaling session Based on one of the authorization and authentication models, an End- user may be involved in application level service negotiation with an Application server (Authorizing entity). At that time the user requests are validated against their subscription and as a result the Application server issues an authorization token to the End-user for the negotiated application service and QoS resources. An authorization token may contain several pieces of information pertaining to the authorized application session, but at minimum it should contain: o An identifier of the Application server which issued the token, o An identifier of the application session for which it is issued and o Authentication data that guarantees the validity of the token. A possible structure for the authorization token and the policy element carrying it are proposed in [RFC3520], [ETSI-OSP]. In a different authentication and authorization scenario, which does not use a token generated by the authorizing entity, (General 3 party approach Figure 3), an End-user MAY initiate a QoS signaling session by generating a QoS Reserve message containing the requested QoS resource description and additional user identification data, which is used also to locate the Authorizing entity. The Authorizing entity should use the provided request and credentials in the authentication and authorization process and integrity verification of the QoS request. Alfano, et al. Expires January 19, 2006 [Page 14] Internet-Draft Diameter QoS Application July 2005 4.1.2 QoS policy aware transport plane element functionality A request for a QoS reservation received by a Policy aware node, initiates a Diameter QoS authorization session. The Policy aware node generates a QoS-Authorization-Request message (QAR) in which it maps required objects from the QoS signaling message to Diameter AVPs. Depending on the deployment scenario, information for signaling session identification, Authorizing entity identification, requested QoS description, End-user identity, authorization token, End-user authentication credentials and authentication information for QoS objects may all be encapsulated into Diameter AVPs and included into the Diameter message send to the Authorizing entity (Application server or End-user's home realm). The final result of the authorization request is provided in the Result-Code AVP of the QoS-Authorization-Answer message (QAA) sent by the Authorizing entity. Description of authorized QoS resources and status of the authorized flow (enabled/disabled) are provided in the included QoS-Authorization-Resources AVP of the QAA message too. Authorized parameters may be installed into the QoS Traffic Control function of the QoS policy aware transport plane element (see Figure 2). Authorization duration information is also provided in the QAA. A number of factors MAY influence the authorized session duration such as the user's subscription plan or the method used for QoS negotiation and authorization. Currently authorization duration is time-based as specified in [RFC3588]. Before expiration of the authorization period, a new QoS-Authorization-Request/Answer message exchange should be initiated. After expiration of the authorization lifetime, an explicit request for re-authorization must be sent to the transport plane element using a Re-Auth-Request message (RAR). Further authorization session maintenance issues are discussed in the following section for Re-Authorization and Session termination (see Section 4.2 and Section 4.4). Authorization duration may also be based on data volume transferred on an authorized data flow. After successful authorization, session establishment and initiation of the data flow, a Diameter accounting session should be established between the transport plane element and an Accounting server. Accounting information is reported as specified in [RFC3588] with additional extensions specified in a subsequent section for Accounting (Section 5). Alfano, et al. Expires January 19, 2006 [Page 15] Internet-Draft Diameter QoS Application July 2005 4.1.3 Authorizing Entity functionality The Diameter QoS application server receives the initial QoS- Authorization-Request message (QAR). It verifies the integrity of the included Authorization-Token AVP (if included) (Figure 4). Based on the info in the authorization token and/or the provided user identity and credentials, the server determines the authorized QoS resources and flow state (enabled/disabled) from a priory negotiated resource information or user subscription profile, and includes this information in an QoS-Authorization-Answer message (QAA). Authorizing entity establishes authorization session state and SHOULD save additional information for management of the session (Acc- Mulisession-Id, signaling session identifier and authentication data) as part of the session state info. Signaling session identifier (if present) SHOULD be used together with the generated Acc-Multisession-Id AVP for binding of authorization and accounting session information in case of user mobility. The authentication data should be used for verification of the freshness and authenticity of subsequent QoS requests. 4.2 QoS authorization session re-authorization Client and server-side initiated re-authorizations are considered in the design of the Diameter QoS application. These have impact on the interworking between the Diameter and the QoS signaling protocols. 4.2.1 Client-side initiated Re-Authorization As described above, the Authorizing entity provides the duration of the authorization session as part of the QoS-Authorization-Answer message (QAA). At any time before expiration of this period, a new QoS-Authorization-Request message (QAR) may be sent to the authorizing entity. It may be triggered by a reception of a new QoS Reserve message which requests modification of the authorized QoS reservation state. 4.2.2 Server-side initiated Re-Authorization If the client does not re-authorize the session before it expires, after expiration of the authorization lifetime, an explicit request for re-authorization is sent from the Authorizing entity to the transport plane element with an Re-Auth-Request message (RAR). This message should trigger a notification QoS signaling message sent to the End-user who is expected to initiate a refreshing QoS Reserve message containing a description of the refreshed QoS resources. Reception of this message at the QoS policy aware node will trigger QoS-Authorization-Request message (QAR), which eventually re- Alfano, et al. Expires January 19, 2006 [Page 16] Internet-Draft Diameter QoS Application July 2005 authorizes the authorization session and extend its lifetime. At any time during the QoS authorization session the Authorizing server MAY send Re-Auth-Request message (RAR). The transport plane element MUST respond with Re-Auth-Answer message (RAA) and send a notification QoS signaling message to the End-user, which will trigger the previously described process of QoS state refresh and re- authorization. 4.3 Server-side initiated QoS parameter provisioning The Authorizing entity (Home Server or Application Server) is enabled to update installed QoS parameters and flow state at the QoS aware transport plane elements by sending a QoS-Install Request message (QIR). Transport elements MUST apply the updates and respond with an QoS-Install Answer message (QIA). An example application of this functionality would be updating of the flow status of an established QoS reservation due to a change of the application service session. Early initial QoS parameter installation (prior to a request from a transport plane element) is allowed. Early installation requires availability of specific information to the Authorizing entity, e.g., identity of the node that should be contacted and identification of the flow (filter specifications) for which the QoS reservation is established. 4.4 Session Termination 4.4.1 Client-side initiated session termination A QoS authorization session MAY be terminated from the client side by sending a Session-Termination-Request message (STR) to the server. This is a Base Diameter protocol functionality and it is defined in [RFC3588]. Session termination can be caused by a QoS signaling tear down message or via a loss of bearer report. After a successful termination of the authorization session, final accounting messages should be exchanged. 4.4.2 Server-side initiated session termination At anytime during a session the Authorizing server may send an Abort- Session-Request message (ASR) to the transport plane element [RFC3588]. Possible reasons are insufficient accounting credits or session termination at the application layer. This results in termination of the authorization session, release of the reserved resources at the transport plane node and sending appropriate QoS signaling notification to other transport plane elements aware of the signaling session. Final accounting message exchanges must also occur. Alfano, et al. Expires January 19, 2006 [Page 17] Internet-Draft Diameter QoS Application July 2005 5. Accounting The Diameter QoS application presented in this document reuses Diameter Accounting as defined in [RFC3588]. A definition of new Accounting attributes is necessary, but left for further study. After a successful QoS authorization and start of the transport plane flow, the transport plane element starts the corresponding accounting session by sending an Accounting-Request message (ACR). The message SHOULD contain necessary attributes to facilitate the binding of the current accounting session to the reported authorization session. The Accounting server replies to a successfully received Accounting- Request message (ACR) with an Accounting-Answer message (ACA), which MAY contain instructions for handling of the accounting session, e.g., the Accounting-Interim-Interval AVPs. After every successful re-authorization procedure the transport plane element SHOULD initiate an accounting message exchange. After successful session termination the transport plane element MUST initiate a final exchange of accounting messages with the Accounting server. Alfano, et al. Expires January 19, 2006 [Page 18] Internet-Draft Diameter QoS Application July 2005 6. Diameter QoS authorization application Messages The Diameter QoS Application requires the definition of new mandatory AVPs and Command-codes [RFC3588]. Four new Diameter messages are defined along with Command-Codes whose values MUST be supported by all Diameter implementations that conform to this specification. Command-Name Abbrev. Code Reference QoS-Authz-Request QAR [TBD] Section 6.1 QoS-Authz-Answer QAA [TBD] Section 6.2 QoS-Install-Request QIR [TBD] Section 6.3 QoS-Install-Answer QIA [TBD] Section 6.4 In addition, the following Diameter Base protocol messages are used in the Diameter QoS application: Command-Name Abbrev. Code Reference Accounting-Request ACR 271 RFC 3588 Accounting-Request ACR 271 RFC 3588 Accounting-Answer ACA 271 RFC 3588 Re-Auth-Request RAR 258 RFC 3588 Re-Auth-Answer RAA 258 RFC 3588 Abort-Session-Request ASR 274 RFC 3588 Abort-Session-Answer ACA 274 RFC 3588 Session-Term-Request STR 275 RFC 3588 Session-Term-Answer STA 275 RFC 3588 Diameter nodes conforming to this specification MAY advertise support by including the value of TBD (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/ QAA and QIR/QIA 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 commands 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 19, 2006 [Page 19] Internet-Draft Diameter QoS Application July 2005 6.1 QoS-Authorization Request (QAR) The QoS-Authorization-Request message (QAR) indicated by the Command- Code field set to TDB (TBD) and 'R' bit set in the Command Flags field is used by transport plane elements to request quality of service related resource authorization for a given flow. The message MUST carry information for signaling session identification, Authorizing entity identification, requested QoS description, and End-user identity. In addition, depending on the deployment scenario, an authorization token, End-user authentication credentials and QoS objects authentication information should be included. The message format is defined as follows: ::= < Diameter Header: XXX, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } [ Destination-Host ] [ Signaling-Session-Id ] [ Authorization-Token ] [ User-Name ] [ QoS-Authorization-Resources ] [ QoS-Authentication-Data ] [ CC-Corelation-Id ] [ Acc-Multisession-Id ] * [ AVP ] 6.2 QoS-Authorization Answer The QoS-Authorization-Answer message (QAA), indicated by the Command- Code field set to TBD (TBD) and 'R' bit cleared in the Command Flags field is sent in response to the QoS-Authorization-Request message (QAR). If the QoS authorization request is successfully authorized, the response will include the AVPs to allow authorization of the QoS resources as well as accounting and transport plane gating information. The message format is defined as follows: Alfano, et al. Expires January 19, 2006 [Page 20] Internet-Draft Diameter QoS Application July 2005 ::= < Diameter Header: XXX, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ Signaling-Session-Id ] [ QoS-Authorization-Resources ] [ Acc-Multisession-Id ] [ Session-lifetime ] [ Authz-Session-Lifetime ] [ Authz-Grace-Period ] [ Authz-Session-Volume ] * [ AVP ] 6.3 QoS-Install Request The QoS-Install Request message (QIR), indicated by the Command-Code field set to TDB (TBD) and 'R' bit set in the Command Flags field is used by Authorizing entity to install or update the QoS parameters and the flow state of an authorized flow at the transport plane element. The message MUST carry information for signaling session identification or identification of the flow to which the provided QoS rules apply, identity of the transport plane element, description of provided QoS parameters, flow state and duration of the provided authorization. The message format is defined as follows: ::= < Diameter Header: XXX, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } [ Destination-Host ] [ Signaling-Session-Id ] [ QoS-Authorization-Resources ] [ Session-Timeout ] [ Authz-Session-Lifetime ] [ Authz-Grace-Period ] [ Authz-Session-Volume ] Alfano, et al. Expires January 19, 2006 [Page 21] Internet-Draft Diameter QoS Application July 2005 * [ AVP ] 6.4 QoS-Install Request The QoS-Install Answer message (QAA), indicated by the Command-Code field set to TBD (TBD) and 'R' bit cleared in the Command Flags field is sent in response to the QoS-Install Request message (QIR) for confirmation of the result of the installation of the provided QoS reservation instructions. The message format is defined as follows: ::= < Diameter Header: XXX, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Auth-Request-Type } { Result-Code } [ Signaling-Session-Id ] [ QoS-Authorization-Resources ] * [ AVP ] Alfano, et al. Expires January 19, 2006 [Page 22] Internet-Draft Diameter QoS Application July 2005 7. Diameter QoS Authorization Application AVPs Each of the AVPs identified in the QoS-Authorization-Request/Answer and QoS-Install-Request/Answer messages and the assignment of their value(s) is given in this section. 7.1 Diameter Base Protocol AVPs The Diameter QoS application uses a number of session management AVPs, defined in the Base Protocol ([RFC3588]). Attribute Name AVP Code Reference [RFC3588] Origin-Host 264 Section 6.3 Origin-Realm 296 Section 6.4 Destination-Host 293 Section 6.5 Destination-Realm 283 Section 6.6 Auth-Application-Id 258 Section 6.8 Result-Code 268 Section 7.1 Auth-Request-Type 274 Section 8.7 Session-Id 263 Section 8.8 Authz-Lifetime 291 Section 8.9 Authz-Grace-Period 276 Section 8.10 Session-Timeout 27 Section 8.13 User-Name 1 Section 8.14 Some of the listed AVPs require definition and assignment of additional values which is described here: Auth-Application-Id AVP The Auth-Application-Id is assigned by IANA to Diameter applications. The value of the Auth-Application-Id for the Diameter QoS application is TBD (TBD). Result-Code AVP The Result-Code AVP indicates if a particular request was completed successfully. Definition of QoS authorization specific Result-Code values is for further study. (TBD) 7.2 Credit Control application AVPs The process of QoS authorization and accounting of the consumed reserved resources is closely related to credit control over the services provided to a user. An option for correlating of the accounting records for the different provided services should be Alfano, et al. Expires January 19, 2006 [Page 23] Internet-Draft Diameter QoS Application July 2005 available. For this purpose, the Diameter QoS application should support appropriate AVPs defined by the Diameter Credit Control document [I-D.ietf-aaa-diameter-cc]. CC-Correlation-Id AVP 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. 7.3 Authentication/Authorization AVPs Authentication and authorization is essential for the Diameter QoS application. Flexibility is desired for deployment into infrastructures with different security features and usage of authentication and authorization applications such as [I-D.ietf-aaa- eap] and [I-D.ietf-aaa-diameter-nasreq]. Multiple methods specified in these applications MIGHT be reused. Alternatively autonomous and QoS-specific authentication methods may be supported depending on the features of the QoS signaling protocols. Therefore, a number of AVPs of related Diameter applications can be used. The three party general approach (see Figure 3) utilizes an EAP based authentication and session key exchange which requires the support of AVPs defined in the Diameter-EAP application [I-D.ietf-aaa-eap]. The details of the required attributes for authentication and authorization is for further study. 7.4 Accounting AVPs The Diameter QoS application uses Diameter Accounting and accounting AVPs as defined in Section 9 of [RFC3588]. Additional description of the usage of some of them in QoS authorization context is provided: Acc-Multisession-ID Acc-Multisession-ID AVP (AVP Code 50) SHOULD be used to link multiple accounting sessions together, allowing the correlation of accounting information. This AVP MAY be returned by the Diameter server in a QoS-Authorization-Answer message (QAA), and MUST be used in all accounting messages for the given session. 7.5 Diameter QoS Application Defined AVPs This section defines the Quality of Service AVPs that are specific to the Diameter QoS application and MAY be included in the Diameter QoS application messages. Unlike the approach followed with RSVP (see Alfano, et al. Expires January 19, 2006 [Page 24] Internet-Draft Diameter QoS Application July 2005 [RFC2749]), where the entire RSVP message is encapsulated into a COPS message, only the relevant fields SHOULD be included. This approach avoids a certain overhead of transmitting fields which are irrelevant for the AAA infrastructure. It keeps implementations simpler and it allows the reuse of other Diameter AVPs. 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| ------------------------------------------+----+---+----+-----+----+ Signaling-Session TBD 7.5 Unsigned32 | M | P | | V | Y | -Id | | | | | | Flow-ID TBD 7.5 Unsigned32 | M | P | | V | Y | QoS-Filter-Rule TBD 7.5 QoSFltrRule| M | P | | V | Y | SPI TBD 7.5 Unsigned32 | M | P | | V | Y | QoS-Flow-State TBD 7.5 Enumerated | M | P | | V | Y | IND-Flow TBD 7.5 Grouped | M | P | | V | Y | Flows TBD 7.5 Grouped | M | P | | V | Y | QSPEC TBD 7.5 OctetString| M | P | | V | Y | QoS-Auth TBD 7.5 Grouped | M | P | | V | Y | -Resources | | | | | | QoS-Auth-Data TBD 7.5 Grouped | M | P | | V | Y | Authorization TBD 7.5 OctetString| M | P | | V | Y | -Token | | | | | | Auth-Session TBD 7.5 Unsigned32 | M | P | | V | Y | -Volume | | | | | | ------------------------------------------+----+---+----+-----+----+ Signaling-Session-ID Signaling-Session-ID AVP (AVP Code TBD) is of type Unsigned32 and contains a copy of the QoS signaling session identifier, which is a unique identifier of the QoS signaling session that in NSIS case remains unchanged for the duration of the session. Flow-ID The Flow-ID AVP (AVP Code TBD) is of type Unsigned32 and contains identifier of an IP flow. Alfano, et al. Expires January 19, 2006 [Page 25] Internet-Draft Diameter QoS Application July 2005 QoS-Filter-Rule The QoS-Filter-Rule AVP (AVP Code TBD) is of type QoSFilterRule and provides filter rules for a packet flow of the user. It would be used in case of the explicit rule provisioning initiated by the Authorizing server, too. SPI The SPI AVP (AVP Code TBD) is of type Unsigned32 and extends the QoS-Filter-Rule AVP to support IPsec protected traffic. QoS-Flow-State The QoS-Flow-State AVP (AVP Code TBD) is of type Enumerated. It gives an indication by the Authorizing entity how the flow MUST be treated. When included in a QAA message, it is instructions to the transport plane control element with regard to the state to which the flow should be set. The supported values are: 0 Open - Enable the transport plane service, for which the signaling is done 1 Close - Disable the transport plane service 2 Maintain - Current state (enabled/disabled) of the transport plane service is maintained The QoS-Flow-State is an optional AVP. When not included in a QAA response, the default behaviour is to immediately allow the flow of packets (Open). IND-Flows The IND-Flows AVP (AVP Code TBD) is of type Grouped and specifies IP Flows via their flow identifiers and filter-rule. IND-Flows ::= [Flow-Id] [QoS-Filter-Rule] [0-1] [SPI] [0-1] [QoS-Flow-State] Alfano, et al. Expires January 19, 2006 [Page 26] Internet-Draft Diameter QoS Application July 2005 Flows The Flows AVP (AVP Code TBD) is of type Grouped and contains all the individual flows that receive the same QoS specified in the included QSPEC. Flows ::= < AVP Header: XXX > [1+]* [ IND-Flows ] QSPEC The QSPEC AVP (AVP Code TBD) is of type OctetString and contains QoS parameter information. Description format is taken from QoS NSLP Qspec template, which is expected to cover all present QoS description methods [I-D.ietf-nsis-qspec]. QoS-Authorization-Resources The QoS-Auth-Resources AVP (AVP Code TBD) is of type Grouped and includes description of the resources that have been requested by the user or authorized by the application server for a particular QoS request. More than one MAY be included into a message. QoS-Auth-Resources ::= < AVP Header: XXX > [0-1] [ Signaling-Session-ID ] [0-1]* [ Flows ] [1] [ QSPEC ] [0-1] [ QoS-Flow-State ] Included QoS-Flow-State AVP SHOULD be overwritten by any included QoS-Flow-State AVPs specified for the individual flows. QoS-Authentication-Data The QoS-Authentication-Data AVP (AVP Code TBD) is of type Grouped and contains data used for End-user authentication and integrity protection of the QoS signaling messages. (TBD) Alfano, et al. Expires January 19, 2006 [Page 27] Internet-Draft Diameter QoS Application July 2005 Authorization-Token The Authorization-Token AVP (AVP Code TBD) is of type OctetString and SHOULD contain application session authorization token such as the one defined in [RFC3520] (TBD) Authz-Session-Volume The Authz-Session-Volume AVP (AVP Code TBD) is of type Unsigned32 and contains the maximum data volume authorized by the Authorizing entity. Alfano, et al. Expires January 19, 2006 [Page 28] Internet-Draft Diameter QoS Application July 2005 8. Examples This section illustrates a general message flow of QoS authorization session establishment(Figure 17) and interworking with NSIS (Figure 18). Figure 17 shows the protocol exchange between the Diameter client and the Diameter server. An incoming QoS reservation request received at the transport plane element invokes sending of QoS-Authorization- Request message {QAR) to the Authorization server. Server replies with QoS-Authorization-Answer message (QAA), which grants reservation of certain resources. After the successful exchange of authorization QAR/QAA messages, the transport plane node starts an accounting session by sending an Accounting-Request message (ACR). The server replies with an Accounting-Answer message (ACA) that MAY include instructions for further handling of the accounting session, such as the Acc-Interim-Period AVP. A possible client-side re-authorization caused by expiration of the authorization lifetime initiates a QAR/ QAA message exchange. After successful re-authorization an accounting message ACR SHOULD be sent. The server relpies to the ACR with an ACA message. In this example, the Application server initiates a session termination. To do this it sends an Abort- Session-Request message (ASR). The client responds with an ASA message and a Session-Termination-Request message {STR). After receiving the STA message sent by the server, which finalizes the authorization session, the client sends final accounting information with the ACR message. The ACA message from the server also terminates the accounting session. Alfano, et al. Expires January 19, 2006 [Page 29] Internet-Draft Diameter QoS Application July 2005 Router(Diameter client) Diameter Server -----------> | | QOS | QoS-Request | reservation |------------------------------------------->| request | | | QoS-Answer/QoS-Auth-Res./ | |<-------------------------------------------| | | Start |Acc-Request/Start,QoS Acc-Msess-ID.../ | Accounting |------------------------------------------->| | Acc-Answer/...Acc-Interim-Period.../ | |<-------------------------------------------| | | Authorization| | LifeTime | | Expires: | | Re- | QoS-Request | Authorization|------------------------------------------->| | QoS-Answer/QoS-Auth-Res./ | |<-------------------------------------------| | Acc-Request/Interim, Acc-Msess-ID.../ | |------------------------------------------->| | Acc-Answer/...Acc-Interim-Period.../ | |<-------------------------------------------| ..................... | | Session | | Term. | |initiate | |by Server | Abort-Session-Request |<-------- |<-------------------------------------------| | Abort-Session-Answer | |------------------------------------------->| | Session-Termination-Request | |------------------------------------------->| | Session-Termination-Answer | |<-------------------------------------------| Accounting | Acc-Request/Final,Acc-Msess-ID.../ | end |------------------------------------------->| | Acc-Answer /Final,.../ | |<-------------------------------------------| Figure 17: Diameter QoS Application Session Figure 18 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 Alfano, et al. Expires January 19, 2006 [Page 30] Internet-Draft Diameter QoS Application July 2005 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 QoS 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 1 and in Section 3.6 of [I-D.ietf-nsis-qos-nslp]. The Diameter QoS Authorization Request (QAR), which includes the authorization token and QoS information, is forwarded to the administrative domain of the application domain for verification. As a response, the authorization decision is returned with the Diameter QoS Answer (QAA) message. 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 further along the path. Otherwise, the QoS NSLP returns an error message to the end host (such as 'Authorization denied'). Alfano, et al. Expires January 19, 2006 [Page 31] Internet-Draft Diameter QoS Application July 2005 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 18: Message flow with NSIS and Diameter QoS Application A future version of this document will describe scenarios with other authorization models. Alfano, et al. Expires January 19, 2006 [Page 32] Internet-Draft Diameter QoS Application July 2005 9. Security Considerations This document describes a mechanism for performing authorization of a QoS reservation at a third party entity. Therefore, 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 can be authorized, such as in the 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]). Please note that authentication is not provided to the QoS NSLP router but torwards the users home network. 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]. Alfano, et al. Expires January 19, 2006 [Page 33] Internet-Draft Diameter QoS Application July 2005 10. Contributors Alfano, et al. Expires January 19, 2006 [Page 34] Internet-Draft Diameter QoS Application July 2005 11. Acknowledgements Add your name here. Alfano, et al. Expires January 19, 2006 [Page 35] Internet-Draft Diameter QoS Application July 2005 12. Open Issues During our work on this document we identified the following open issues: 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 8 currently addresses only the third party approach using authorization tokens. Further work is needed to describe the details of a generic three party scenario. o Section 4.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 transport plane 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 transport plane signaling protocol does not support it. o The terminology regarding the 'transport plane node' needs further refinement. Alfano, et al. Expires January 19, 2006 [Page 36] Internet-Draft Diameter QoS Application July 2005 13. References 13.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 13.2 Informative References [ETSI-OSP] European Telecommunications Standards Institute, "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Open Settlement Protocol (OSP) for Inter-domain pricing, authorization, and usage exchange", TS 101 321. [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., "Diameter Session Initiation Protocol (SIP) Application", draft-ietf-aaa-diameter-sip-app-07 (work in progress), March 2005. [I-D.ietf-aaa-eap] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", draft-ietf-aaa-eap-10 (work in progress), November 2004. [I-D.ietf-nsis-ntlp] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Alfano, et al. Expires January 19, 2006 [Page 37] Internet-Draft Diameter QoS Application July 2005 Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-06 (work in progress), May 2005. [I-D.ietf-nsis-qos-nslp] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in progress), February 2005. [I-D.ietf-nsis-qspec] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-05 (work in progress), July 2005. [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. [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. [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. Alfano, et al. Expires January 19, 2006 [Page 38] Internet-Draft Diameter QoS Application July 2005 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, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Tseno Tsenov Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: tseno.tsenov@mytum.de Alfano, et al. Expires January 19, 2006 [Page 39] Internet-Draft Diameter QoS Application July 2005 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 (2005). 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 19, 2006 [Page 40]