Diameter Maintenance and Dong Sun Extensions (DIME) Bell Labs/Lucent Technologies Internet Draft Expires: April 2007 October 26, 2006 Towards the Specification of a Diameter Resource Control Application: gaps, functional requirements and models, and implementations draft-sun-dime-diameter-resource-control-requirements-00.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. This document may only be posted in an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 2007. Copyright Notice Copyright (C) The Internet Society (2006). sun Expires April 2007 [Page 1] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application Abstract This I-D is to address the gaps in the ongoing discussion of the QoS application in the DIME WG, discuss the extension of the scope of QoS application and investigate potential mechanisms to support additional resource control scenarios. The scope of diameter-qos- strawman-00.txt and its predecessors is limited to QoS authorization in an environment where end-hosts can directly request network resources through path-coupled QoS signaling such as RSVP or NSIS. It does not address environments where path-coupled QoS signaling is not supported by end user equipments or networks. In such environments, a different mode of operations is needed to allow an authorizing entity to not just authorize QoS requests triggered by the QoS signaling but also directly authorize and allocate resources, and dictate routers/switches to act. The new mode of operations also lends itself to address resource control in general. It can control resources for the purpose beyond QoS support, such as NAPT, media latching, and packet filtering. Table of Contents 1. Introduction...................................................4 2. Terminology....................................................5 3. Functional requirements and models.............................6 3.1. Implications of QoS mechanisms and end user capabilities..6 3.1.1. QoS mechanisms.......................................6 3.1.2. End user equipment capabilities......................7 3.2. Resource control modes....................................8 3.3. Functional requirements...................................8 3.4. Functional model..........................................9 4. Diameter resource control application in Push mode............11 4.1. Commands, AVPs...........................................11 4.1.1. Command codes.......................................11 4.1.1.1. Policy-Install-Request command.................12 4.1.1.2. Policy-Install-Answer command..................13 4.1.2. AVPs................................................13 4.1.2.1. New AVPs.......................................13 4.1.2.1.1. PI-Request-Type AVP.......................13 4.1.2.1.2. PI-Request-Number AVP.....................14 4.1.2.2. Other resource control AVPs....................14 4.2. Procedures...............................................15 4.2.1. High-level descriptions.............................15 4.2.2. Session initiation..................................15 4.2.3. Session modification................................17 sun Expires April 2007 [Page 2] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application 4.2.4. Session termination.................................20 4.2.5. Specific event actions..............................21 5. Discovery and binding mechanisms..............................21 6. IANA Considerations...........................................21 6.1. Command Codes............................................21 6.2. AVP Codes................................................21 6.3. Application Identifier...................................22 7. Security Considerations.......................................22 8. Acknowledgments...............................................22 9. References....................................................23 9.1. Normative References.....................................23 9.2. Informative References...................................23 Author's Addresses...............................................25 Intellectual Property Statement..................................25 Disclaimer of Validity...........................................25 Copyright Statement..............................................26 Acknowledgment...................................................26 sun Expires April 2007 [Page 3] Diameter Maintenance and Dong Sun Extensions (DIME) Bell Labs/Lucent Technologies Internet Draft Expires: April 2007 October 26, 2006 1. Introduction This I-D is to address the gaps in the ongoing discussion of the QoS application in the DIME WG, discuss the extension of the scope of QoS application and investigate potential mechanisms to support additional resource control scenarios. The scope of diameter-qos-strawman-00.txt and its predecessors [I- D.tschofenig-dime-diameter-qos] is limited to QoS authorization in an environment where end-hosts can directly request network resources through path-coupled QoS signaling such as RSVP or NSIS. It does not address environments where path-coupled QoS signaling is not supported by end user equipments or networks. In such environments, a different mode of operations is needed to allow an authorizing entity (a policy decision point in the [I-D.tschofenig-dime-diameter-qos] nomenclature) to not just authorize QoS requests triggered by the QoS signaling but also directly authorize and allocate resources and dictate routers/switches to act. The new mode of operations also lends itself to address resource control in general. It can control resources for the purpose beyond QoS support, such as NAPT, media latching, and packet filtering such as described in [ITU-T RACF] and [TISPAN RACS]. Current models and mechanisms defined in diameter-qos-strawman-00.txt and its predecessors [I-D.tschofenig-dime-diameter-qos] are not sufficient to support those scenarios and further extension and enhancement are needed to support a universal resource control framework. This I-D analyzes the relationship between QoS mechanisms/end user equipment's capabilities and resource control modes, and discusses functional requirements and functional models to ensure the completeness of the protocol development for purpose of general resource control. Finally, this document describes some enhancements of Diameter protocol for Push mode of resource control, which can also be extended to support Pull mode of resource control and leads to a universal functional model for different types of end user equipments and quality of service mechanisms offered in the same network. sun Expires April 2007 [Page 4] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application 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 Functions The application functions (AF) is a functional entity responsible for controlling the application layer session and interact with the end user equipment at the application level. It may extract/derive the end user resource request from the received application signaling message. The AF can be an application server or SIP proxy. Diameter Resource Control Application It is the AAA application protocol that is defined in this document and is used for the purpose of resource control. End User Equipment The end user equipment (UE) is a functional entity responsible for establishing a user application session with the network. Its resource control and signaling capabilities may vary. Pull Mode In this mode, the network layer signaling received from the end user equipment triggers the resource control session. The resource control client then pulls the resource control decisions from the server. The Diameter resource control application shall support this mode. Push Mode In this mode, application functions or local network conditions received trigger the resource control session. The resource control server then pushes the resource control decisions to the client. The Diameter resource control application shall support this mode. Resource Control Client The resource control client (RCC) is a functional entity responsible for enforcing resource control decisions on gate operation (open/close the gate) and other QoS resources and network resources. sun Expires April 2007 [Page 5] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application The RCC serves as a Diameter client for a Diameter resource control session. Resource Control Server The resource control server (RCS) is a functional entity responsible for making decisions on resource authorization, reservation and commitment according to a set of information such as service information, network policy, end user subscription and network resource availability. The RCS serves as a Diameter server for a Diameter resource control session. Resource Control Session This is a Diameter session that supports the Diameter resource control application. Resource Control Decision A set of information including the resource control actions and the relevant IP media flows to that these actions need to be applied. 3. Functional requirements and models This section discusses the implications of underlying network QoS mechanisms and various end user capabilities on policy based resource control approach, and summarizes functional models and requirements. 3.1. Implications of QoS mechanisms and end user capabilities 3.1.1. QoS mechanisms It is noted that a couple of different QoS mechanisms are employed commonly in packet networks. Those QoS mechanisms can be categorized into two models: intserv [RFC1633] and diffserv [RFC2475]. In the intserv model, network layer signaling e.g RSVP [2210], NSIS [I- D.ietf-nsis-qos-nslp], or link specific signaling is commonly used to initiate a request from end user equipment for desired QoS resource of a media flow. In the diffserv model, the QoS resources are provisioned based on some predefined QoS service classes rather than QoS requests on a per flow basis. These two models result in differences in how the resource control approaches interact with underlying network elements. In the intserv model, the resource control session is typically triggered by the network layer signaling received from the end user equipment, and then resource authorization are pulled down by the network element sun Expires April 2007 [Page 6] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application (i.e. resource control client). In the diffserv model, since the network layer signaling is not used for requesting the resources on a per flow basis, the resource control session is typically triggered by either application functions or resource control conditions defined by the operator, and then the authorization decisions are pushed by the decision function (i.e. resource control server). 3.1.2. End user equipment capabilities In addition, we have to take into account the end user equipment's (UE) resource control capability, which can be categorized as follows: o Category 1: No resource control capability in the application and network layers. This type of end user equipment may set up a connection through application layer signaling, but it is unable to provide specific resource requirements either through application layer e.g. SIP or through network layer signaling e.g. RSVP or NSIS (or does not support network layer signaling at all). o Category 2: Only has resource control capability in the application layer. This type of end user equipment is able to set up a connection through application layer signaling with certain resource requirements (e.g. application level service class), but it is unable to provide specific network level resource requirements (e.g., network QoS class) through network layer signaling e.g., RSVP or NSIS (or does not support network layer signaling at all). o Category 3: Has resource control capability in the network layer. This type of end user equipment may set up a connection through an application layer signaling and translate service characteristics into network level resource requirements (e.g. network QoS class) locally, and request the resources through network layer signaling e.g. RSVP or NSIS. It is obvious that the above categories of UEs have some correlation with the QoS mechanisms described in section 3.1.1. Since category 1 and 2 types of UEs cannot use the network layer signaling to request the resources, the intserv model is not applicable to them in general. Category 3 type of UE may decide to use the network layer signaling for requesting the resource or not based on network technologies and operator's configuration. sun Expires April 2007 [Page 7] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application 3.2. Resource control modes According to the above analysis, two resource control modes are needed in support of different combinations of QoS mechanisms and UE's capabilities. o Pull mode: The resource control session is triggered by the network layer signaling received from end user equipments, and resource control decisions are pulled by the network element. There are 3 types of modes described in [I-D.tschofenig-nsis-qos- authz-issues], and [I-D.tschofenig-dime-diameter-qos] and its successor. All them can be viewed as use cases of Pull mode. o Push mode: The resource control session is triggered by application functions or local network conditions (e.g. time of day on resource usage and QoS classes), and resource control decisions are pushed by the decision function. Moreover, the push mode can be further divided into two types: - UE initiated push mode - Network initiated push mode In the former, the resource control session is triggered by application functions due to the explicit request of UE through application layer signaling, e.g. SIP; in the latter, the resource control session is triggered by application functions without explicit request of UE. The similar resource control modes are also addressed in [ITU-T RACF]. The Pull mode is applicable to GPRS networks as defined in [3GPP PCC] or Intserv enabled IP networks; the Push mode is applicable to some other networks, for example, Cable network, DSL, Ethernet, Diffserv enabled IP/MPLS as defined in [CableLabs PCMM], [DSL Forum Policy Control Framework], [ITU-T RACF] and [TISPAN RACS]. 3.3. Functional requirements It is worth pointing out that in pull mode, the decision function is still allowed to push down updated decisions, as needed, of an existing resource control session. Similarly, in push mode, the network element is also allowed to request (pull) the re- authorization of an existing resource control session. sun Expires April 2007 [Page 8] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application Therefore, the functional requirements and models have to take into both modes as a whole when developing the protocol, mechanism and relevant parameters. The main functional requirements of Diameter resource control application are hence as follows: o Shall interwork with various QoS mechanisms and UEs for different network technologies, i.e., both pull and push modes can be supported within the same functional model. o Shall provide broad resource control functions spanning from network QoS resource control to network accessibility and security resource control and NAT traversal/NAPT resource control etc. o Shall perform the admission control on a per flow per subscriber basis according to multiple facets of network conditions, e.g. local network policies, resource availability and subscription. o Shall instruct the enforcement of resource control decisions on per flow basis. 3.4. Functional model A generic functional model of Diameter resource control application is illustrated in figure 1. The resource control server (RCS) (i.e. the decision function, serving the functionality of policy decision point as defined in [RFC2753][RFC3084]) is responsible for authorizing the resource request and formulating resource control decisions based on service information, network local policies, end user subscription and network resource availability etc. The resource control client (RCC) (i.e. network element, serving the functionality of policy enforcement point as defined in [RFC2753][RFC3084]) is responsible for enforcing the resource control decisions (e.g. opening/closing the gates of IP flows, limiting the traffic bandwidth, marking/remarking QoS class of IP packets, metering network resource usage); in addition, it may support other functions, e.g. media relay and address latching functions for NAT traversal and NAPT. The application functions (AF)(e.g. application server or SIP proxy) are responsible for initiating the resource request and populating the service information into a resource request message. In this functional model the resource control server (RCS) acts as a Diameter server and the resource control client (RCC) acts as a Diameter client. The resource control server and application functions can be collocated in the same physical box or distributed throughout the network within the same provider domain or different provider domain. sun Expires April 2007 [Page 9] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application The interaction of the resource control server and application functions is outside the scope of this document. The resource control server and resource control client typically shall be located in the same provider's network domain. There can be multiple resource control servers in the system for supporting different instances of application functions. For each service request, only one RCS should make the final resource control decision. However, the detailed architecture of the resource control system and its interfaces are implementation specific and are out of scope of this specification. +-----------+ +-------------------->|Application| | |Functions | | +-----------+ | ^ | | | v | +----------+ | | Resource | | | Control | | | Server | | |(Diameter | | | Server) | | +----------+ | |^ | Resource control || | Protocol || | (Diameter) || v v| +-----------+ +----------+ | End | | Resource | | User |<------------->| Control | | Equipment| | Client | +-----------+ |(Diameter | | Client) | +----------+ Network Element Figure 1 Resource control functional model The different resource control modes are required in support of distinctive capabilities of end user equipments. For category 1 and 2 of UEs, the push mode is needed, in which the resource control operations are triggered by the application functions, and the resource control decisions are pushed from the resource control sun Expires April 2007 [Page 10] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application server down to the resource control client. For category 3 of UE, the pull mode is needed, the resource control operations are triggered by the network layer signaling received from UEs, and the resource control decisions are pulled from the resource control server by the resource control client. 4. Diameter resource control application in Push mode This section mainly focuses on Push mode in support of category 1 and 2 of UEs at the moment, and it may be extended to support category 3 of UE in the future in conjunction with the draft [I-D.tschofenig- dime-diameter-qos] and its successor. 4.1. Commands, AVPs This section defines a pair of new command codes, and describes used command codes and AVPs for usage of Diameter resource control application in push mode. 4.1.1. Command codes Section 4.1.1.1 and 4.1.1.2 define new Diameter message Command-Code values that MUST be supported by all Diameter implementations that conform to this specification. The command codes are as follows: Command-Name Abbrev. Code Reference ----------------------------------------------------------- Policy-Install-Request PIR xxx 4.1.1.1 Policy-Install-Answer PIA xxx 4.1.1.2 The Base Diameter protocol, section 3.2 [RFC3588] defines in the section 3.2 the Command Code ABNF specification. These formats are observed in the new resource control messages. Other sections described re-used command codes from the Diameter Base protocol [RFC3588] and the credit-control application [RFC4006]. One example of these command codes are as follows (other valid command codes are FFS, such as AAR/AAA [RFC4005], DER/DEA [RFC4072], ACR/ACA): sun Expires April 2007 [Page 11] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application Command-Name Abbrev. Code Reference ----------------------------------------------------------- Credit-Control-Request CCR 272 RFC 4006 Credit-Control-Answer CCA 272 RFC 4006 Re-Auth-Request RAR 258 RFC 3588 Re-Auth-Answer RAA 258 RFC 3588 Session-Termination-Request STR 275 RFC 3588 Session-Termination-Answer STA 275 RFC 3588 Abort-Session-Request ASR 274 RFC 3588 Abort-Session-Answer ASA 274 RFC 3588 4.1.1.1. Policy-Install-Request command The Policy-Install-Request (PIR) message, indicated by the Command- Code field set to TBD and the 'R' bit set in the Command Flags field, is sent by the RCS to the RCC for originating a resource control session from the RCS (Diameter server) side with the PI-Request-Type set to INITIAL_REQUEST, and contains resource control decision information that is relevant to the initiation. In addition, it may also update or terminate an existing session from the RCS side with the PI-Request-Type set to UPDATE_REQUEST or TERMINATION_RQUEST. The Auth-Application-Id MUST be set to the value xxx, indicating the Diameter resource control application. Message Format: ::= < Diameter Header: xxx, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { PI-Request-Type } { PI-Request-Number } sun Expires April 2007 [Page 12] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application [ Origin-State-Id ] [ Auth-Session-State ] [ Authorization-Lifetime ] *[ Proxy-Info ] *[ Route-Record ] *[ AVP ] (note) Note: The relevant AVPs to QoS, resource control decisions are FFS. Some high level information is described in section 4.1.2.2. 4.1.1.2. Policy-Install-Answer command The PIA command, indicated by the Command-Code field set to TBD and the 'R' bit cleared in the Command Flags field, is sent by the RCC to the RCS in response to the PIR command. Message Format: ::= < Diameter Header: xxx, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { PI-Request-Type } { PI-Request-Number } [ Result-Code ] [ Origin-State-Id ] *[ Proxy-Info ] *[ AVP ] (note) 4.1.2. AVPs 4.1.2.1. New AVPs 4.1.2.1.1. PI-Request-Type AVP The PI-Request-Type AVP (AVP Code xxx) is of type Enumerated and contains the reason for sending the policy-install request command. It MUST be present in all Policy-Install-Request messages. The following values are defined for the PI-Request-Type AVP: INITIAL_REQUEST 1 An Initial request is used to initiate a resource control session from the Diameter Server side, and contains resource control information that is relevant to the initiation. sun Expires April 2007 [Page 13] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application UPDATE_REQUEST 2 An Update request contains resource-control information for an existing resource control session. Update Policy-Install requests SHOULD be sent every time at the expiry of the allocated quota or validity time. Further, additional service-specific events MAY trigger a spontaneous Update request. TERMINATION_REQUEST 3 A Termination request is sent to terminate a resource control session and contains resource control information relevant to the existing session. 4.1.2.1.2. PI-Request-Number AVP The PI-Request-Number AVP (AVP Code xxx) is of type Unsigned32 and identifies this request within one session. As Session-Id AVPs are globally unique, the combination of Session-Id and PI-Request-Number AVPs is also globally unique and can be used in matching policy install messages with confirmations. An easy way to produce unique numbers is to set the value to 0 for a policy-install request of type INITIAL_REQUEST and EVENT_REQUEST and to set the value to 1 for the first UPDATE_REQUEST, to 2 for the second, and so on until the value for TERMINATION_REQUEST is one more than for the last UPDATE_REQUEST. 4.1.2.2. Other resource control AVPs It is FFS the format and definition of resource control related AVPs such as QoS AVPs, flow descriptor etc. One option is to adopt the data structure defined by [I-D.tschofenig-dime-diameter-qos] and its successor; another option is to adopt the data structure defined by 3GPP Gx [29.212]. No matter what data structure is used, the following information shall be defined accordingly. o IP media flow description (e.g. IP 5-tuple (port number can be a range) and direction) o QoS information (e.g. authorized bandwidth, network service Class) o Resource control actions (e.g., gate opening/closing) o Other resource control information, e.g., o NAT traversal/NAPT information (e.g. address latching, address translation information) sun Expires April 2007 [Page 14] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application o Usage metering and statistics reporting Additional AVPs may be defined to further facilitate the resource control functions and procedure, e.g., o Network layer session Identifier (e.g. signaling session ID) o Reservation priority o Traffic descriptor (e.g. peak/committed date rate, peak/committed bucket size and excess bucket size) 4.2. Procedures 4.2.1. High-level descriptions In push mode, when a UE requests a new application session towards application functions (e.g. SIP proxy), the application functions shall derive resource requirements and populate service information (e.g. bandwidth, media type and application description etc.), and send a request to the RCS. Upon receipt of the request from the AF, the RCS shall perform the initial authorization, establish a new resource control session (i.e. a Diameter session), make and push down initial resource control decisions to corresponding RCC node according to the indication received from the AF or local policies. The resource control decisions may include QoS decision (e.g. authorized bandwidth, QoS class) and other information, e.g., address latching information for NAT traversal and NAPT). Once the RCC receives resource control decisions, it shall enforce the decisions accordingly to reserve and/or commit network resources. The resource authorization, reservation and commitment can be executed within one round of interaction or multiple rounds of interactions between AF, RCS and RCC, dependent on service characteristics and/or network policies. Note: The current descriptions of the procedures are only for stateful resource control process. In addition, the support of hard- state or soft-state session will be described in a later version. 4.2.2. Session initiation When the RCS receives a resource control request from the AF, it shall translate the service information (e.g. media type, media flow sun Expires April 2007 [Page 15] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application descriptions, application layer QoS (service class and bandwidth) into network layer information, evaluate network policies (e.g. time of day), examine UE's subscription (e.g. maximum allowed bandwidth), and check network resource availability. The resource availability check may be supported by an element, such as the Transport Resource Control Functional Entity (TRC-FE) [ITU-T RACF], which interacts with the RCS to ensure the availability of requested transport network resources. The detailed procedures for controlling other network resources e.g. NAT traversal are FFS. An initial authorization can be admitted by the RCS if for all IP media flows in the session, all conditions are satisfied. The RCS may determine the necessary QoS resources (e.g. maximum allowed bandwidth) and resource control operations as one of following options: o Reserve network resources only (gate status is closed or disabled) o Reserve and commit network resource (gate status is open or enabled) The RCS shall support a discovery mechanism to identify the corresponding RCC and the binding mechanism to correlate the resource request from the AF with relevant subscriber profile and IP media flows; and then the RCS shall send a Policy-Install-Request message with the PI-Request-Type set to "INITIAL_REQUEST" to the RCC with all decision data. The RCS may include the authorization lifetime that allows the RCC to determine how long the authorization decision is valid for this particular QoS reservation. In addition, if the RCS needs to maintain resource control session state in stateful operation (the stateless operation is FFS and subject to the discussion of DIME group), it should save certain information for management of the session (e.g. resource control session ID, resource control decision data etc.). When the RCC receive the PIR message with new Diameter session ID, it shall treat it as a new request and initiate a new Diameter session accordingly if the stateful operation is used. The RCC shall enforce the resource control decisions of PIR message received from the RCS. For example, if the resource control decisions indicate the gate should be open, the RCC shall allocate the requested bandwidth and open the gate according to IP flow description (e.g. IP 5-tuple). sun Expires April 2007 [Page 16] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application The final result of the resource control enforcement is provided in the Result-Code AVP of the Policy-Install-Answer message sent by the RCC, in case of successful authorization, the Result-Code is set to DIAMETER_LIMITED_SUCCESS, (see [RFC3588])). End user Resource control Resource control Application Equipment client server Functions (Diameter Client) (Diameter Server) | | | | | | (Trigger)<---------- + | | + | | | +------------+----------+ | | | | Authorize request | | | | | Produce decision data| | | | | Keep session data | | | | |/Authz-time,Session-Id/| | | | +------------+----------+ | | | | | | |< -------- (PIR) --------+ | | |(INITIAL_REQUEST, | | | | Decision(QoS-Resources), | | | | Authz-time) | | | +-------+---------+ | | | |Install decisions| | | | | + | | | | | Authz. session | | | | | /Authz-time/ | | | | +-------+---------+ | | | | | | | +--------- (PIA) --------->| | | | (Result-Code) | | | | | | | | | | |=====================(Data Flow)=======================> | | | | Figure 2 Session initiation 4.2.3. Session modification The session modification is triggered by the update request received from the AF or local network condition (e.g. time of day). In addition, the RCC may request specific event actions upon the change of network status according to the event indication received from the RCS in the session initiation (e.g. retrieve and re-authorize the resource control decisions). sun Expires April 2007 [Page 17] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application When one of triggers occurs, the RCS shall determine the operation of the session modification as one of follows: 1) Modification of requested resources; 2) Commitment of requested resources; 3) Removal of requested resources. The RCS shall produce a set of updated resource control decisions and push down to the RCC through the PIR with the PI-Request-Type set to UPDATE-REQUEST (another option is to send a RAR message with updated decision data). Upon receipt of a PIR message with the PI-Request-Type set to UPDATE- REQUEST (or RAR with an existing session ID), the RCC shall treat it as a modification request. The RCC shall determine the operations to enforce the updated decisions as one of follows: o Install decision for a new IP media flow without committing the requested resources if the flow/gate status is set to closed/DISABLED. o Install decision and commit the requested resources for a new IP media flow if the flow/gate status is set to open/ENABLED (e.g. open the gates). o Modify decision for an existing IP media flow without committing the requested resources if the flow/gate status is set to closed/DISABLED (e.g. increase or decrease the allocated bandwidth, but the RTCP gate may remain the opening status). o Modify decision and commit the requested resources for an existing IP media flow if the flow/gate status is set to open/ENABLED (e.g. open the gates with modified bandwidth). o Commit the requested resources for an existing IP media flow if the flow/gate status is set to open/ENABLED (e.g. open the gates with reserved bandwidth). o Revoke the installed decisions and release the committed or reserved resources for all related IP media flows if the flow/gate status is set to REMOVED. The final result of the resource control enforcement is provided in the Result-Code AVP of the Policy-Install-Answer message sent by the RCC (or RAA message), in case of successful authorization, the Result-Code is set to DIAMETER_LIMITED_SUCCESS, (see [RFC3588])). sun Expires April 2007 [Page 18] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application When the RCC is triggered by the change of network status, it may send a CCR message with requested specific action to the RCS. The RCS shall provide the updated decision data through the CCA message. End user Resource control Resource control Application Equipment client server Functions (Diameter Client) (Diameter Server) | | | | |======================(Data Flow)======================> |(------>)| | | | QoS-Res +(----- (CCR)_-------->)(Trigger)<--------- + | | + | | | +------------+----------+ | | | | Authorize request | | | | | Update decision data | | | | | Keep session data | | | | |/Authz-time,Session-Id/| | | | +------------+----------+ | | | | | | |< -------(PIR/RAR/CCA)----+ | | |(UPDATE_REQUEST, | | | | Decision(QoS-Resources), | | | | Authz-time) | | | +-------+---------+ | | | |Update decisions | | | | | + | | | | | Authz. session | | | | | /Authz-time/ | | | | +-------+---------+ | | | | | | | +--------- (PIA/RAA) ----->| | | | (Result-Code) | | | | | | | | | | |=======================Data Flow=======================> | | | | Figure 3 Session modification sun Expires April 2007 [Page 19] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application 4.2.4. Session termination End user Resource control Resource control Application equipment client server Functions (Diameter Client) (Diameter Server) | | | | |=======================Data Flow=======================> |(------>)| | | | QoS-Res +(----- (CCR/STR)_---->)(Trigger)<--------- + | | + | | | +------------+----------+ | | | | Authorize request | | | | | Release session data | | | | |/Authz-time,Session-Id/| | | | +------------+----------+ | | | | | | |< ----(PIR/ASR/CCA/STA)---+ | | |(TERMINIAT_REQUEST) | | | +-------+---------+ | | | | Release | | | | | session state | | | | +-------+---------+ | | | | | | | +--------- (PIA/ASA) ----->| | | | (Result-Code) | | | | | | Figure 4 Session termination The session termination can be triggered by the request received from the AF when an application session is released or by local network condition. In addition, the RCC may request the session termination according to the change of network status or expiry of a session. When the session termination is triggered by AF or local network condition, the RCS shall send a PIR message with PI-Request-Type set to "TERMINATION-REQUEST" (or send a ASR message with existing session ID), the RCC shall release all network resources and return a PIA (or ASA). When the session termination is triggered by the change of network status or expiry of a session, the RCC shall send a CCR message with PI-Request-Type set to "TERMINATION-REQUEST" (or send a STR message with existing session ID), the RCS shall release all network resources and return a CCA (or STA). In addition, the RCS shall release all resources and notify the AF for affected application sessions. sun Expires April 2007 [Page 20] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application 4.2.5. Specific event actions The RCS may indicate to be notified of certain events (e.g. bearer failure) by specifying them in the indication of specific event action through PIR or RAR message. If an event subscribed by the RCS through PIR or RAR occurs, the RCC shall send a CCR command to the RCS containing: o The value of the indication of specific event action, indicating the event that occurred; and o Optionally, the appropriate Cause value. 5. Discovery and binding mechanisms The detailed discovery and binding mechanisms is FFS. 6. IANA Considerations This document defines two new Diameter commands, several new AVPs and a new Diameter application. 6.1. Command Codes This document defines the following new command codes: Command-Name Abbrev. Code Reference ----------------------------------------------------------- Policy-Install-Request PIR xxx 4.1.1.1 Policy-Install-Answer PIA xxx 4.1.1.2 6.2. AVP Codes This document defines the following new AVPs: PI-Request-Type PI-Request-Number Other resource control AVPs: FFS. sun Expires April 2007 [Page 21] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application 6.3. Application Identifier This specification defines new Diameter application called "Diameter QoS Integrated application" i.e. QoS. The Application Identifier code for this application is set to TBD. 7. Security Considerations FFS. 8. Acknowledgments The author would like to thank Hui-Lan Lu and Ramesh Nagarajan for their inputs and comments to this document. sun Expires April 2007 [Page 22] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,"Diameter Network Access Server Application", RFC 4005, August 2005. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. 9.2. Informative References [3GPP PCC] 3GPP TS 23.203 version 1.2.0 (2006-09) (Release 7), Universal Mobile Telecommunications System (UMTS); Policy and Charging Control architecture. [3GPP 29.212] 3GPP TS 29.212 version 0.4.0 (2006-09) (Release 7), Universal Mobile Telecommunications System (UMTS); Policy and Charging Control over Gx reference point. [DSL Forum Policy Control Framework] DSL Forum, "Policy Control Framework for DSL", WT-134 Rev. 2, April 2006. [I-D.ietf-nsis-qos-nslp] Manner, J., "NSLP for Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-10 (work in progress), March 2006. [I-D.ietf-nsis-qspec] Ash, J., "QoS-NSLP QSPEC Template", draft- ietf-nsis-qspec-09 (work in progress), March 2006. [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. sun Expires April 2007 [Page 23] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application [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. [I-D.tschofenig-dime-diameter-qos] Alfano, F., McCann, P., and H. Tschofenig, "Diameter Quality of Service Application", February 2006. (and successor draft "diameter-qos-strawman-00.txt"). [ITU-T RACF] ITU-T Recommendation Y.2111, "Resource and admission control functions in Next Generation Networks", October 2006. [CableLabs PCMM] CableLabs, "PacketCable Multimedia Specification", PKT-SP-MM-I03-051221, December 21, 2005. [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview," IETF RFC 1633, June 1994. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services," IETF RFC 2475, December 1998. [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [RFC3084] Chan, K., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. [TISPAN RACS] ETSI ES 282 003: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control Sub system (RACS); Functional Architecture". sun Expires April 2007 [Page 24] Diameter Maintenance and Dong Sun Extensions (DIME) Bell Labs/Lucent Technologies Internet Draft Expires: April 2007 October 26, 2006 Author's Addresses Dong Sun Bell Labs/Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733 USA Email: dongsun@lucent.com 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 sun Expires April 2007 [Page 25] Internet-Draft Towards the Specification of a October 2006 Diameter Resource Control Application 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 (2006). 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. sun Expires April 2007 [Page 26]