Diameter Maintenance and D. Sun Extensions (DIME) Z. Zeltsan Internet Draft Alcatel-Lucent Expires: September 2007 March 2, 2007 Towards the Specification of a Diameter Resource Control Application: gaps, functional requirements and models, and implementations draft-sun-dime-diameter-resource-control-requirements-01.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 September 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Sun Expires September 2007 [Page 1] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application Abstract This I-D is to analyze the gaps in the ongoing work of the QoS application in the DIME WG, discuss the extension of the scope of QoS application to a generic resource control application for a variety of network technologies and use cases, and investigate potential mechanisms to support additional resource control scenarios. The current Diameter Quality of Service Application (draft-tschofenig- dime-diameter-qos-01.txt) is limited to an environment where network elements triggered by certain mechanisms (e.g. path-coupled QoS signaling such as RSVP or NSIS initiated by end-hosts) can request QoS authorization of network resources. It does not address environments where end-hosts and/or network elements is unable to issue a resource request initiatively. In such environments, a different mode of operations is needed to allow an authorizing entity to not just authorize QoS resources upon the receipt of the request from network elements but also directly authorize resources and dictate routers/switches to enforce the decisions without the request from network elements. 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. Sun Expires September 2007 [Page 2] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application Table of Contents 1. Terminology....................................................4 2. Functional models and requirements.............................6 2.1. Implications of end user capabilities and QoS mechanisms..6 2.1.1. End user equipment capabilities......................6 2.1.2. QoS mechanisms.......................................7 2.2. Resource control models...................................7 2.3. Functional requirements...................................9 2.4. Functional framework......................................9 2.5. Schematic examples of use cases..........................11 3. New Commands and AVPs of Diameter resource control application for Push model.......................................................14 3.1. Command codes............................................14 3.1.1. Policy-Install-Request command......................15 3.1.2. Policy-Install-Answer command.......................15 3.2. New AVPs.................................................16 3.2.1. PI-Request-Type AVP.................................16 3.2.2. PI-Request-Number AVP...............................16 3.2.3. Other resource control AVPs.........................17 4. Procedures....................................................17 4.1. Session initiation.......................................18 4.1.1. Session initiation for Push Model...................18 4.1.2. Session initiation for Pull Model...................21 4.2. Session modification.....................................23 4.3. Session termination......................................25 4.4. Specific event actions...................................27 5. Selection and binding mechanisms..............................27 6. IANA Considerations...........................................27 6.1. Command Codes............................................27 6.2. AVP Codes................................................27 6.3. Application Identifier...................................28 7. Security Considerations.......................................28 8. Acknowledgments...............................................28 9. References....................................................29 9.1. Normative References.....................................29 9.2. Informative References...................................29 Authors' Addresses...............................................31 Intellectual Property Statement..................................31 Disclaimer of Validity...........................................32 Copyright Statement..............................................32 Acknowledgment...................................................32 Sun Expires September 2007 [Page 3] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application 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 to a generic resource control application for a variety of network technologies and use cases, and investigate potential mechanisms to support additional resource control scenarios. The current Diameter Quality of Service Application [draft- tschofenig-dime-diameter-qos-01.txt] and its predecessors is limited to an environment where network elements triggered by certain mechanisms (e.g. path-coupled QoS signaling such as RSVP or NSIS initiated by end-hosts) can request QoS authorization of network resources. It does not address environments where end-hosts and/or network elements is unable to issue a resource request initiatively. In such environments, a different mode of operations is needed to allow an authorizing entity (the policy decision point in the [draft- tschofenig-dime-diameter-qos-01.txt] nomenclature) to not just authorize QoS resources upon the receipt of the request from network elements but also directly authorize resources and dictate routers/switches to enforce the decisions without the request from network elements. Current frameworks and mechanisms defined in [draft-tschofenig-dime-diameter-qos-01.txt] are not sufficient to support those scenarios and further extension and enhancement is needed to support a universal resource control framework. 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]. This I-D analyzes the relationship between QoS mechanisms/end user equipment's capabilities and resource control modes, and discusses functional requirements and functional framework 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 framework for different types of end user equipments and quality of service mechanisms offered in the same network. 1. 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]. Sun Expires September 2007 [Page 4] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application 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 interacting 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 Enforcement Entity 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 changes in local network conditions received trigger the resource control session. The Resource Control Decision Entity then pushes the resource control decisions to the client. The Diameter resource control application shall support this mode. Resource Control Enforcement Entity The Resource Control Enforcement Entity (RCE) is a functional entity responsible for enforcing resource control decisions on gate operation (open/close the gate) and other QoS resources and network resources, i.e. policy enforcement point (PEP) as defined in [RFC2753]. A Diameter client collocates with the RCE in the same network element for a Diameter resource control session. Resource Control Decision Entity Sun Expires September 2007 [Page 5] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application The Resource Control Decision Entity (RCD) 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, i.e. policy decision point (PDP) as defined in [RFC2753]. A Diameter server collocates with the RCD in the same network element 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. 2. Functional models and requirements 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. 2.1. Implications of end user capabilities and QoS mechanisms 2.1.1. End user equipment capabilities The end user equipment's (UE) capabilities are varied in relation to resource control, which can be categorized as follows: o Category 1: No resource control capability in both 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/QoS requirements either through application layer signaling 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 attributes), 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). Sun Expires September 2007 [Page 6] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application 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. 2.1.2. QoS mechanisms 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. It is obvious that the QoS mechanisms have some correlation with the UEs capability in terms of resource control process. Since category 1 and 2 UEs cannot initiate the resource requests through the network layer signaling, the intserv model is not applicable to them in general. Category 3 UEs may decide whether or not to use the network layer signaling for requesting the resource or not based on network requirements and operator's configuration. The diversity of QoS capabilities of UEs and networks results in differences in how the resource control system interacts with underlying network elements. In the intserv model, the resource control session is typically initiated by network element when a trigger such as the network layer signaling is received from the end user equipment, and resource authorization decisions are produced upon the request of the network element (i.e. Resource Control Enforcement Entity). In the diffserv model, since the network element is unable to initiatively request the resource authorization, 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 Decision Entity) to the network element without explicit request. 2.2. Resource control models According to the above analysis, two resource control models are needed in support of different combinations of QoS mechanisms and UE's capabilities. Sun Expires September 2007 [Page 7] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application o Push model: 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 model can be further divided into two types: - UE initiated push model - Network initiated push model 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. o Pull model: The resource control session is triggered by the network layer signaling received from end user equipments or by the local event in the network element according to pre-configured policies, 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 [draft-tschofenig-dime-diameter-qos-01.txt]. All of them can be regarded as use cases of Pull model. The similar resource control models are also addressed in [ITU-T RACF]. The Pull model is applicable to GPRS networks as defined in [3GPP PCC] or Intserv enabled IP networks; the Pull model 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]. The different resource control models are required in support of distinctive capabilities of end user equipments. For category 1 and 2 of UEs, the Push model is mandated, in which the resource control operations are triggered by the application functions, and the resource control decisions are pushed from the Resource Control Decision Entity down to the Resource Control Enforcement Entity. For category 3 of UE, either push model or pull mode is doable, the operation of Push model is the same as that of category 1/2; in the Pull model, the resource control operations are triggered by the network layer signaling received from UEs, and the resource control Sun Expires September 2007 [Page 8] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application decisions are pulled from the Resource Control Decision Entity by the Resource Control Enforcement Entity. However, it is expected that the resource control trends towards the Push model for all types of UE and network technologies, since the Pull model requires extra QoS mechanism and interaction in the network elements that may lead to complexity, scalability and cost- effectiveness issues. 2.3. Functional requirements It is worth pointing out that in pull model, the decision function is still allowed to push down updated decisions, as needed, of an existing resource control session. Similarly, in push model, the network element is also allowed to request (pull) the re- authorization of an existing resource control session. Therefore, the functional requirements and framework have to take into both models 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 models can be supported within the same functional framework. 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. 2.4. Functional framework A generic functional framework of Diameter resource control application is illustrated in figure 1. The Resource Control Decision Entity (RCD) (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 Enforcement Entity (RCE) (i.e. Sun Expires September 2007 [Page 9] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application 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, SIP proxy or video headend of IPTV) are responsible for initiating the resource request and populating the service information into a resource request message. In this functional framework the Resource Control Decision Entity (RCD) acts as a Diameter server and the Resource Control Enforcement Entity (RCE) acts as a Diameter client. The Resource Control Decision Entity and application functions can be collocated in the same physical box within the same provider domain or distributed throughout the network between different provider domains. The interaction of the Resource Control Decision Entity and application functions is outside the scope of this document. The Resource Control Decision Entity and Resource Control Enforcement Entity typically shall be located in the same provider's network domain. There can be multiple Resource Control Decision Entities in the system for supporting different instances of application functions. For each service request, only one RCD 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. Sun Expires September 2007 [Page 10] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application +-----------+ +-------------------->|Application| | |Functions | | +-----------+ | ^ | | | v | +----------+ | | Resource | | | Control | | | Decision | | | Entity | | |(Diameter | | | Server) | | +----------+ | |^ | Resource control || | Protocol || | (Diameter) || v v| +-----------+ +---------------+ | End | | Resource | | User |<------------>| Control | | Equipment| | Enforcement | +-----------+ | Entity | |(Diameter | | Client) | +---------------+ Network Element Figure 1 Resource control functional framework 2.5. Schematic examples of use cases The schematic examples of use cases for Pull and Push models are illustrated as follows. 1. Use case for Push model Sun Expires September 2007 [Page 11] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application +-----------+ +-------------------->|Application| | |Functions | | +-----+-----+ | | | |(2) | v | +----------+ | | Resource | | | Control | |(1) | Decision | | | Entity | | |(Diameter | | | Server) | | +-----+----+ | | | Resource Control | | Protocol |(3) | (Diameter) | | v +-----------+ +---------------+ | End | | Resource | | User |<------------>| Control | | Equipment| | Enforcement | +-----------+ | Entity | |(Diameter | | Client) | +---------------+ Network Element Figure 2 Use case for Push model (1) The End User Equipment requests an application-specific service by sending a service request (e.g. SIP Invite, HTTP Get,) to Application Functions. The service request may or may not contain any explicit parameters for service quality requirement. (2) The application functions derive resource requirements and populate service information (e.g. bandwidth, media type and application description etc.), and send a request to the RCD. (3) Upon receipt of the request from the AF, the RCD performs the initial authorization, establishes a new resource control session (i.e. a Diameter session), makes and pushes down initial resource control decisions to corresponding RCE node according to the indication received from the AF or local policies. The RCE enforces the decisions accordingly to reserve and/or commit network resources. Sun Expires September 2007 [Page 12] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application 2. Use case for Push Model +-----------+ +-------------------->|Application| | |Functions | | +-----+-----+ | |^ | (2)||(3) | v| | +----------+ | | Resource | | | Control | |(1) | Decision | | | Entity | | |(Diameter | | | Server) | | +----------+ | ^| | Resource Control || | Protocol (5) ||(6) | (Diameter) || | |v +-----------+ +------+--------+ | End | (4) | Resource | | User |<------------>| Control | | Equipment| | Enforcement | +-----------+ | Entity | |(Diameter | | Client) | +---------------+ Network Element Figure 3 Use case for Pull model (1) The End User Equipment requests an application-specific service by sending a service request .e.g. SIP Invite, HTTP Get,.to the Application Functions. The service request may or may not contain any explicit (application) service quality requirements. (2) The application functions derive resource requirements and populate service information (e.g. bandwidth, media type and application description etc.), and send a request to the RCD. (3) The Resource Control Decision Entity checks authorization based on network policy rules etc. If the resources are authorized, an authorization token (RFC 3520) may be assigned to this service and informed to the End User Equipment. (The use of authorization token Sun Expires September 2007 [Page 13] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application is optional. It is possible to perform authorization without the use of a token.) (4) The End User Equipment initiates an explicit QoS request for resource reservation to the Resource Control Enforcement Entity. This QoS request contains the explicit transport QoS requirement parameters for an application-specific service. It may also contain an authorization token assigned at the first phase. (5) On receipt of the QoS request, the Resource Control Enforcement Entity sends a request to Resource Control Decision Entity for resource reservation and admission control that may contain the authorization token as an option. (6) The Resource Control Decision Entity makes the final decision of reservation and admission control. If the request is granted, the Resource Control Decision Entity provides the decisions to the Resource Control Enforcement Entity. The Resource Control Enforcement Entity enforces the decisions accordingly. 3. New Commands and AVPs of Diameter resource control application for Push model This section defines a pair of new command codes and several new mandatory AVPs and describes the usage of these command codes and AVPs for Diameter resource control application in order to support the push model. 3.1. Command codes Section 3.1.1 and 3.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 3.1.1 Policy-Install-Answer PIA xxx 3.1. 2 Sun Expires September 2007 [Page 14] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application 3.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 RCD to the RCE for originating a resource control session from the RCD (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 RCD 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 } [ 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. 3.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 RCE to the RCD in response to the PIR command. Message Format: ::= < Diameter Header: xxx, PXY > Sun Expires September 2007 [Page 15] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application < Session-Id > { Origin-Host } { Origin-Realm } { PI-Request-Type } { PI-Request-Number } [ Result-Code ] [ Origin-State-Id ] *[ Proxy-Info ] *[ AVP ] (note) 3.2. New AVPs 3.2.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. 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. 3.2.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 Sun Expires September 2007 [Page 16] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application 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. 3.2.3. 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) 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. Procedures This section elaborates on the example call flows of resource control application based on aforementioned new command codes, and existing command codes from the Diameter Base protocol [RFC3588] and the credit-control application [RFC4006] as follows (other valid command codes are FFS, such as AAR/AAA [RFC4005], DER/DEA [RFC4072], ACR/ACA): Sun Expires September 2007 [Page 17] Internet-Draft Towards the Specification of a March 2007 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 The procedures for Push model and Pull model are quite similar. The main difference is for the session initiation, i.e., the RCD will initiate a new session in the Push model; instead, the RCE will initiate a new session in the Pull model. The session modification and termination procedures are identical for Push and Pull models. 4.1. Session initiation 4.1.1. Session initiation for Push Model When the RCD receives a resource control request from the AF, it shall translate the service information (e.g. media type, media flow 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 RCD 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 RCD if for all IP media flows in the session, all conditions are satisfied. The RCD may determine the necessary QoS resources (e.g. maximum allowed bandwidth) and resource control operations as one of following options: Sun Expires September 2007 [Page 18] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application o Reserve network resources only (gate status is closed or disabled) o Reserve and commit network resource (gate status is open or enabled) In the Push model, the RCD shall support a selection mechanism to identify the corresponding RCE and the binding mechanism to correlate the resource request from the AF with relevant subscriber profile and IP media flows; and then the RCD shall send a Policy-Install-Request message with the PI-Request-Type set to "INITIAL_REQUEST" to the RCE with all decision data. The RCD may include the authorization lifetime that allows the RCE to determine how long the authorization decision is valid for this particular QoS reservation. In addition, if the RCD 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 RCE 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 RCE shall enforce the resource control decisions of PIR message received from the RCD. For example, if the resource control decisions indicate the gate should be open, the RCE shall allocate the requested bandwidth and open the gate according to IP flow description (e.g. IP 5-tuple). The final result of the resource control enforcement is provided in the Result-Code AVP of the Policy-Install-Answer message sent by the RCE, in case of successful authorization, the Result-Code is set to DIAMETER_LIMITED_SUCCESS, (see [RFC3588])). Sun Expires September 2007 [Page 19] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application End user Resource control Resource control Application Equipment Enforcement Entity Decision Entity Functions (Diameter Client) (Diameter Server) | | | | | | (1. Trigger)<------- + | | + | | | +------------+----------+ | | | | 2. Authorize request | | | | | Produce decision data| | | | | Keep session data | | | | |/Authz-time,Session-Id/| | | | +------------+----------+ | | | | | | |< -------- (3. PIR) -----+ | | |(INITIAL_REQUEST, | | | | Decision(QoS-Resources), | | | | Authz-time) | | | +-------+------------+ | | | |4. Install decisions| | | | | + | | | | | Authz. session | | | | | /Authz-time/ | | | | +-------+------------+ | | | | | | | +--------- (5. PIA) ------>| | | | (Result-Code) | | | | | | | | | | |=====================(Data Flow)=======================> | | | | Figure 4 Session initiation for Push Model 1. A resource control session is initiated by the RCD when a trigger is received. The trigger can be a resource request from the AF or a local event due to network policies/conditions. 2. The RCD stores the service information received from the AF and authorizes the request based on service information, network resource availability, end user's transport subscription and provisioned network policies, and determines the resource reservation operation mode (e.g. reservation only, or reservation + commitment). 3. The RCD discovers pertinent RCCs and pushes down policy decisions to those RCCs using PIR command with the PI-Request-Type set to "INITIAL-REQUEST". Sun Expires September 2007 [Page 20] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application 4. The RCE installs policy decisions, and performs policy enforcement operations as needed, e.g., enforcing the authorized QoS and enabling or disabling IP media flows according to the corresponding policy decision (e.g. the flow status). 5. The RCE sends PIA to RCD to acknowledge the receipt of PIR. 4.1.2. Session initiation for Pull Model When the RCE receives the path-coupled QoS signaling from UE or the trigger of a local event, it initiates a new resource control session and sends a resource request message to the RCD. Upon receipt of the request from the RCE, the RCD will perform the resource control operation, which is same as described in section 4.1.1. Since the session is initiated from the RCE side, the RCD does not need to perform the selection of RCE instance. But the RCE should maintain the linkage with corresponding RCD. Sun Expires September 2007 [Page 21] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application End user Resource control Resource control Application Equipment Enforcement Entity Decision Entity Functions (Diameter Client) (Diameter Server) |)------> + | | | (1. Trigger) ----(CCR)---------> + | | | +------------+----------+ | | | | 2. Authorize request | | | | | Produce decision data| | | | | Keep session data | | | | |/Authz-time,Session-Id/| | | | +------------+----------+ | | | | | | |< ------- (3. CCA) ------+ | | |(INITIAL_REQUEST, | | | | Decision(QoS-Resources), | | | | Authz-time) | | | +-------+------------+ | | | |4. Install decisions| | | | | + | | | | | Authz. session | | | | | /Authz-time/ | | | | +-------+------------+ | | | | | | |<-----(5)+ | | | | | | | | |=====================(Data Flow)=======================> | | | | Figure 5 Session initiation for Pull Model 1. Upon receipt of path-coupled QoS signaling or the trigger of local event, the RCE initiates a new resource control session and sends a CCR command with the CC-Request-Type AVP set to the value "INITIAL_REQUEST" (other options e.g. AAR are FFS). 2. This step is the same as step 2 of Push model. 3. The RCD sends the policy decisions to the RCE using CCA command, including authorized QoS, event triggers etc. 4. This step is the same as step 4 of Push model. 5. The RCE sends path-coupled QoS signaling to the UE to acknowledge the reservation and may send back a confirmation to RCD. Sun Expires September 2007 [Page 22] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application 4.2. Session modification The session modification procedure for Push and Pull models is identical, i.e., the same command codes, AVPs and procedures can be used for both of them. The session modification can be triggered by the update request received from the AF or local network condition (e.g. time of day), or by the request from the RCE upon the change of network status according to the specific event indication received from the RCD in the session initiation (e.g. retrieve and re-authorize the resource control decisions). When one of triggers occurs, the RCD 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 RCD produces a set of updated resource control decisions and sends to the RCE through the RAR command (another option is to use PIR with the PI-Request-Type set to UPDATE-REQUEST). Upon receipt of RAR with an existing session ID (or a PIR message with the PI-Request-Type set to UPDATE-REQUEST), the RCE shall treat it as a modification request. The RCE 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). Sun Expires September 2007 [Page 23] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application 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 RCE (or RAA message), in case of successful authorization, the Result-Code is set to DIAMETER_LIMITED_SUCCESS, (see [RFC3588])). When the RCE is triggered by the change of network status, it may send a CCR message with requested specific action to the RCD. The RCD shall provide the updated decision data through the CCA message. End user Resource control Resource control Application Equipment Enforcement Entity Decision Entity Functions (Diameter Client) (Diameter Server) | | | | |======================(Data Flow)======================> |(------>)| | | | QoS-Res +(----- (CCR)_-------->)(1. Trigger)<------ + | | + | | | +------------+----------+ | | | | 2. Authorize request | | | | | Update decision data | | | | | Keep session data | | | | |/Authz-time,Session-Id/| | | | +------------+----------+ | | | | | | |< -----(3. RAR/CCA)-------+ | | |(UPDATE_REQUEST, | | | | Decision(QoS-Resources), | | | | Authz-time) | | | +----------+---------+ | | | |4. Update decisions | | | | | + | | | | | Authz. session | | | | | /Authz-time/ | | | | +-------+------------+ | | | | | | | +--------- (5. RAA) ------>| | | | (Result-Code) | | | | | | | | | | |=======================Data Flow=======================> | | | | Figure 6 Session modification for Push and Pull models Sun Expires September 2007 [Page 24] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application 1. The resource modification can be triggered by the request from AF or local event, and by the request from RCE (using CCR command). 2. The RCD re-evaluates the policies and updates policy decisions if needed, and determines the affected IP media flows, and corresponding QoS and gate operations. 3. The RCD identifies the affected RCCs and forwards the updated policy decisions using a Diameter RAR or CCA (the use of PIR in this case is FFS). 4. The RCE updates policy decisions, and performs policy enforcement operations as needed, e.g., enforcing the authorized QoS and enabling or disabling IP media flows according to the modified policy decision (e.g. the flow status). 5. The RCE responds RAA command to acknowledge the RAR. 4.3. Session termination The session termination procedure for Push and Pull models is identical, i.e., the same command codes, AVPs and procedures can be used for both of them. 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 RCE 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 RCD shall send a ASR message with existing session ID (or send a PIR message with PI-Request-Type set to "TERMINATION- REQUEST"), the RCE 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 RCE shall send a CCR message with CC-Request-Type set to "TERMINATION-REQUEST", the RCD shall release all network resources and return a CCA. In addition, the RCD shall release all resources and notify the AF for affected application sessions. Sun Expires September 2007 [Page 25] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application End user Resource control Resource control Application Equipment Enforcement Entity Decision Entity Functions (Diameter Client) (Diameter Server) | | | | |=======================Data Flow=======================> |(------>)| | | | QoS-Res +(----- (CCR)_---->)(1. Trigger)<---------- + | | + | | | +------------+----------+ | | | | 2. Authorize request | | | | | Release session data | | | | |/Authz-time,Session-Id/| | | | +------------+----------+ | | | | | | |< ----(3. ASR/CCA)--------+ | | |(TERMINIAT_REQUEST) | | | +-------+---------+ | | | | 4. Release | | | | | session state | | | | +-------+---------+ | | | | | | | +--------- (5. ASA) ------>| | | | (Result-Code) | | | | | | Figure 7 Session termination 1. The session termination can be triggered by the request from AF or local event, and by the request from RCE (using CCR command). 2. The RCD determines the affected IP media flows and releases all resources. 3. The RCD sends ASR to terminate the session if the request is triggered by AF or local event. or uses CCA to indicate the release if the request is from the RCE (the use of PIR in this case is FFS). 4. The RCE releases all local resources. 5. The RCE responds ASA command to acknowledge the ASR as needed. Sun Expires September 2007 [Page 26] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application 4.4. Specific event actions The RCD 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 RCD through PIR or RAR occurs, the RCE shall send a CCR command to the RCD containing: o The value of the indication of specific event action, indicating the event that occurred; and o Optionally, the appropriate Cause value. 5. Selection and binding mechanisms The detailed selection 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 September 2007 [Page 27] Internet-Draft Towards the Specification of a March 2007 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 September 2007 [Page 28] Internet-Draft Towards the Specification of a March 2007 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 September 2007 [Page 29] Internet-Draft Towards the Specification of a March 2007 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. [draft-tschofenig-dime-diameter-qos-01.txt] Alfano, F., McCann, P., H. Tschofenig, H., Tsenov T. and T. Tsou, "Diameter Quality of Service Application", April 2007. [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 September 2007 [Page 30] Diameter Maintenance and D. Sun Extensions (DIME) Z. Zeltsan Internet Draft Alcatel-Lucent Expires: September 2007 March 2, 2007 Authors' Addresses Dong Sun Bell Labs, Alcatel-Lucent 101 Crawfords Corner Rd Holmdel, NJ 07733 USA Email: dongsun@alcatel-lucent.com Zachary Zeltsan Alcatel-Lucent 101 Crawfords Corner Rd Holmdel, NJ 07733 USA Email: zeltsan@alcatel-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 Sun Expires September 2007 [Page 31] Internet-Draft Towards the Specification of a March 2007 Diameter Resource Control Application 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, THE IETF TRUST 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 IETF Trust (2007). 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 September 2007 [Page 32]