DIME Working Group M. Liebsch Internet-Draft G. Punz Intended status: Standards Track NEC Expires: April 29, 2011 October 26, 2010 Diameter General Purpose Session draft-liebsch-dime-diameter-gps-01.txt Abstract The Diameter protocol has specified and relies on the use of per-user sessions, which are established between a Diameter client and server during a user's authentication and authorization procedure. This document proposes an extension to the Diameter session concept to establish a general purpose Diameter session for signaling the context of multiple users, such as for group handling or application state restoration. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 29, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Liebsch & Punz Expires April 29, 2011 [Page 1] Internet-Draft Diameter General Purpose Session October 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Session Termination for a Group of Users . . . . . . . . . 5 3.2. PCRF Failure and Restoration . . . . . . . . . . . . . . . 5 3.3. Optimization for Group Handling . . . . . . . . . . . . . 6 3.4. Policy enforcement to subscriber groups . . . . . . . . . 7 4. Protocol Extension . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Enhancement to the Diameter Session Concept . . . . . . . 9 4.2. Setting up the General Purpose Session . . . . . . . . . . 10 5. Realization of the Extended Session Concept in Standardizations . . . . . . . . . . . . . . . . . . . . . . . 12 6. Coding Options for Bulk Signaling . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Liebsch & Punz Expires April 29, 2011 [Page 2] Internet-Draft Diameter General Purpose Session October 2010 1. Introduction Diameter [RFC3588] has received wide acceptance in large scale networking, e.g. in the 3rd Generation Partnership Project's (3GPP) Evolved Packet Core (EPC) network architecture [3GPP-EPC], based on applications like Network Access Server [RFC4005] and Credit-Control [RFC4006]. Such deployments also depend on application level defined, interoperable resilience schemes. It has been noticed that these could potentially be extended beyond the original Diameter session model by the concept of bulk handling. In this manner the efficiency of signaling can be enhanced significantly. A potential use case within 3GPP consists in optimization for bulk signaling, such as for bulk activation/de-activation and bulk registration update. Similarly, there are also mobility related scenarios where Diameter clients want to communicate with servers without reference to individual user sessions. One example is the enforcement of a policy to all or a group of users. This document describes exemplary use cases of a more general Diameter signaling (i.e. independent from individual Diameter User Sessions) in Section 3. In Section 4 the document defines an extension to the Diameter base protocol for such signaling using a General Purpose (GP) Diameter session. The proposed extension to Diameter enables signaling volume reduction for various specific use cases. Liebsch & Punz Expires April 29, 2011 [Page 3] Internet-Draft Diameter General Purpose Session October 2010 2. Conventions and 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 [RFC2119]. This document uses the terminology of [RFC3588]. The following additional terms are used in the context of this draft: o GP Session: General Purpose Session -- Diameter session between a Diameter client and server which is not related to an individual user, but can be used to signal multi-user or Diameter Application specific context. Liebsch & Punz Expires April 29, 2011 [Page 4] Internet-Draft Diameter General Purpose Session October 2010 3. Use Cases This section describes some use cases where Diameter signaling between a client and a server can benefit from a general purpose Diameter session. The use cases about Diameter node restoration and bulk signaling are relevant in current 3GPP work and reflect the need for more efficient Diameter signaling. 3.1. Session Termination for a Group of Users According to [RFC3588], a Diameter server can terminate an individual user session by means of a Session Termination Request (STR) command. The standard considers the use of a single mandatory Session-ID AVP, which follows the Diameter header, to identify the session to be terminated. Signaling load can be reduced when groups of sessions or even all sessions associated with the receiving Diameter client can be terminated with a single or a few protocol handshakes. A reason for termination of groups of sessions could be for example a controlled shutdown of the server. 3.2. PCRF Failure and Restoration A use case encountered in 3GPP's network architecture is the Policy and Charging Rules Function (PCRF) failure and restoration [3GPP-PCRFFR]. The PCRF is a control function interacting via Diameter with BBERF (Bearer Binding and Event Reporting Function) and PCEF (Policy Enforcement Function) in the bearer plane, as well as AF (Application Function) in the application plane; a simplified functional view is given in Figure 1. The PCRF appears as a central entity, keeping and coordinating states per mobile terminal; it is a Diameter server, whereas BBERF, PCEF and AF are Diameter clients. Note that in real network deployments all functions would be present in multiple instances (e.g. geographically distributed and including load balancing). Liebsch & Punz Expires April 29, 2011 [Page 5] Internet-Draft Diameter General Purpose Session October 2010 +----+ | AF | Application +----+ Plane | |....Diameter +=======+ | | PCRF |-----+ Control +=======+ Plane Diameter.../ \....Diameter / \ Mobile / \ Terminal/ +-------+ +-------+ User <========| BBERF |=============| PCEF |=======> Packet Data NW +-------+ +-------+ (Gateway) (Gateway) Bearer Plane Figure 1: Usage scenario of Diameter bulk signaling for PCRF restoration User sessions in the bearer plane are controlled by PCRF sessions, e.g. regarding Quality of Service, packet filters and charging parameters. Although a PCRF can certainly be implemented as a highly resilient node in itself, there is also the desire to provide resilience by network based means. In case of failure of one particular PCRF node this could mean that PCRF session state has to be restored on either the same PCRF node (after recovery), or on other, alternative PCRF nodes (during the downtime of the failed PCRF). Preferably this restoration procedure is performed in a bulk mode, e.g. for hundreds or thousands of user sessions. After detecting the failure of a PCRF, clients will have to send PCRF session state information of affected sessions to the alternative PCRF (the target for restoration). Obviously this signaling must be independent of any user sessions being currently handled on a target PCRF. Details about the restoration procedure are out of scope of this document, but are currently under study in 3GPP [3GPP-PCRFFR]. 3.3. Optimization for Group Handling One typical case (again for the EPC architecture [3GPP-EPC]) is depicted in Figure 2; the Mobility Management Entity (MME) communicates with Home Subscription Server (HSS) via Diameter for the purpose of performing location registration and download/update of subscription information. Liebsch & Punz Expires April 29, 2011 [Page 6] Internet-Draft Diameter General Purpose Session October 2010 +=========+ | HSS | Update Location +=========+ Request | ^ |...Diameter | | +-------+ | (S6a interface) | | Mobile / radio \ +------+ | | Terminal/ --| access |---- | MME | v User \ network / +------+ Update Location +-------+ Response Figure 2: Usage scenario of Diameter bulk signaling for group handling optimizations in EPC Especially for machine-type applications, external triggers may lead to a massive amount of attachments, or recurring applications may exhibit (almost) synchronized behavior, leading to massive amount of registration updates. Both may (and most likely do, see [3GPP-EPC]) require Diameter signaling exchanges between MME and HSS (Update Location Request/Response pairs, as part of the S6a application realized on top of Diameter). HSS is here in the role of a Diameter server, and MME acts as Diameter client. More details can be found in [3GPP-DIAM]. 3.4. Policy enforcement to subscriber groups A further use case for the GP Session is the signaling of group related context. As example, a Policy Control entity may comprise a Diameter server function, whereas a Diameter client is co-located with the entity implementing the Policy Enforcement engine. The Diameter client and server may have individual user sessions set up, but could consider grouping of multiple users and identification of groups according to a group key. Instead of applying the same policy to individual users one after the other by means of sequential handshakes, the Diameter server may use the GP Session and a RAR/RAA handshake to enforce the policy to a group of users. Figure 3 depicts policy enforcement to a group of users by means of a GP Session. The Diameter server identifies the group of users with the group key. Alternatively, the Diameter server could use the GP Session to enforce the policy to a sub-set of users by means of identifying the addressed users with user keys. The user key may be any user- individual AVP according to [RFC3588] or [RFC4005], such as the user name AVP, or a new AVP which serves as user identification. In case the Diameter client and server have individual Diameter User Session IDs set up for the users, the GP Session related signaling may Liebsch & Punz Expires April 29, 2011 [Page 7] Internet-Draft Diameter General Purpose Session October 2010 identify individual users also by means of appending multiple User Session ID AVPs as user keys. However, in such case the Diameter signaling context is identified by means of the GP Session ID, whereas a set of User Session IDs is used solely to identify individual users and apply an accompanying value to their policy settings. Details about group identification and individual user identification in the context of GP Session signaling are out of scope of this version of the document. +----------------+ | | | Policy Control | | | +----------------+ ^ | \___RAR/RAA(GPSessionID, groupkey, value) | RAR/RAA(GPSessionID, user1key, value1, | user2key, value2, | user3key, value3) | V +--------------------+ User1 | | User2 -------- | Policy Enforcement | ----------data traffic : | | UserN +--------------------+ Figure 3: Multi-User policy enforcement Liebsch & Punz Expires April 29, 2011 [Page 8] Internet-Draft Diameter General Purpose Session October 2010 4. Protocol Extension 4.1. Enhancement to the Diameter Session Concept The Diameter base protocol [RFC3588] explicitly distinguishes a Connection between a Diameter client and a Diameter server from Diameter Sessions. Whereas a connection provides transport service to convey Diameter messages between a particular client and a server, a session is referred to be a logical concept at the application layer. A connection is established between a client and a server and is used in a shared manner. A session is established on a per-user basis and is not shared to signal context of multiple users. This document proposes an enhancement to the original Diameter session concept and specifies the use of a dedicated Diameter session in the context of multiple users or application specific context. Figure 4 depicts one possible interpretation of the proposed Diameter GP Session. A Diameter client establishes user-specific sessions with the Diameter server. Each session is identified by a Session ID, which uniquely identifies a user. The Diameter GP Session is established without linking the session and the associated Session ID to a particular user. The Diameter client may make use of a virtual user and associated identifiers, keys etc. to open the GP Session with the Diameter server. Important is that client and server are aware of the meaning and use of the virtual user's session for general purpose signaling. Details about authentication and authorization of the virtual user behind the GP Session is out of scope of this version of the document. Liebsch & Punz Expires April 29, 2011 [Page 9] Internet-Draft Diameter General Purpose Session October 2010 +-----+ |User1|-+ +---------------+ +---------------+ +-----+ | | +----+ +----+ |===Session ID 1===| +----+ +----+ | | | |App1| |App2| |===Session ID 2 | |App1| |App2| | +-----+ +-------| +----+ +----+ | : | +----+ +----+ | |User2|---------|+-------------+| - -connection - -|+-------------+| +-----+ +-------|| Diameter || : || Diameter || : | || Client ||===Session ID N===|| Server || +-----+ | |+-------------+|===GPSession ID===|+-------------+| |UserN|-+ +---------------+ +---------------+ +-----+ <----------- User 1 context: Session ID 1 -------------> <----------- User 2 context: Session ID 2 -------------> <----------- User N context: Session ID N -------------> Client-Server Application & <----- multi-user context: ------> GPSession ID Figure 4: General Purpose Session in the context of the Diameter Client-Server association 4.2. Setting up the General Purpose Session In order to avoid breaking the Diameter User Session concept, a General Purpose Session is interpreted as an additional User Session between the Diameter Client and the Diameter Server, whereas the user behind this session is virtual. The GP Session ID can be administratively configured or well known (static GP Session). Alternatively, the Diameter client may bootstrap a GP Session by means of a authentication/authorization procedure, e.g. according to the authorization procedure specified in [RFC4005]. In such case, a unique and temporary Session ID is assigned to a GP Session. The Diameter client and server may add an Authorization-Lifetime AVP to the authorization signaling to negotiate a limited lifetime of the GP Session. The GP Session ID meets the format of the Diameter Session ID according to [RFC3588]. During dynamic set up of a GP Session according to the Authentication/Authorization procedure, the AAR/AAA may indicate the special type of Diameter session. The Diameter base specification as well as the NASREQ specification provide several means to allow such indication. For example, the Diameter Session AVP could carry an indicator in the optional value field, which Liebsch & Punz Expires April 29, 2011 [Page 10] Internet-Draft Diameter General Purpose Session October 2010 classifies the Session ID as GP Session. The set of high/low 64 bits identify the GP Session. Details about the setup as well as the indication of the Session ID type are out of scope of this version of the document and are for further study. Liebsch & Punz Expires April 29, 2011 [Page 11] Internet-Draft Diameter General Purpose Session October 2010 5. Realization of the Extended Session Concept in Standardizations For the sake of a smooth transition and fast enabling, it seems advantageous to develop the extensions for the general purpose session concept step by step. The first step consists in defining the signaling for GP session bootstrapping, as already outlined in Section 4.2. In a second step, as visualized in Figure 5, we envisage that deployment specific guidelines and specifications need to be developed by other SDOs e.g. by 3GPP, as they build their (higher layer) applications on top of (direct) Diameter applications like Credit Control and NASREQ. Bulk signaling would then be enabled by describing how the GP Session can be utilized (i.e. which commands and with which AVPs pertaining to them). In Figure 5 the arrows marked with (1) indicate this usage of a GP session for bulk signaling. In such a manner the mentioned (direct) Diameter applications can remain untouched and other SDOs can provide guidelines for implementations how to use the GP Session for bulk signaling. +-----------------------------------------------------+ | | | Deployment specific guidelines and | | specification, e.g by 3GPP | | ^ ^ | +-----------------------|--+--|-----------------------+ | | | | | | Credit Control | | | NASREQ | | RFC4006 (1) | (1) RFC4005 | | | | | | +--------------------+--|--+--|--+--------------------+ | | v GPS v | | | +-----------+ | | Diameter Base RFC 3588 | +-----------------------------------------------------+ Figure 5: Deployment specific guidelines for applications to use the GP Session for bulk signaling In a third step (requiring more time and more effort in IETF) it would be possible to extend also the specifications of individual Diameter applications for bulk signaling, as shown in Figure 6. E.g. new commands could be introduced to support failure recovery and bulk Liebsch & Punz Expires April 29, 2011 [Page 12] Internet-Draft Diameter General Purpose Session October 2010 signaling. In such a way the usage could be enabled for a much wider scope. Existing higher layer applications could migrate to such usage of a GP session whenever deemed suitable, whereas new ones would be designed according to the new functionality. Extensions to individual application may specify the use of existing messages to support bulk signaling using the GP Session (1). New commands, which could omit a Session-ID AVP according to their specification, may not need a GP Session (2), as for example explicit commands for failure recovery. +-----------------------------------------------------------------+ | Deployment by using RFC4006bis and RFC4006bis | | ^ ^ | +---------------|---------------------------------|---------------+ +---------------|----------------+----------------|---------------+ | v +-------+ | +-------+ v | | Credit Control |BulkExt| | |BulkExt| NASREQ | | RFC4006bis +-------+ | +-------+ RFC4005bis | | ^ ^ | ^ ^ | +------------------------|-+-|-------|-+-|------------------------+ | (2)|(1) | | | | | | | v GPS v | | | | v +-----------+ v | | Diameter Base RFC 3588 | +-----------------------------------------------------------------+ Figure 6: Revised Applications to provide support for bulk signaling and state restoration Liebsch & Punz Expires April 29, 2011 [Page 13] Internet-Draft Diameter General Purpose Session October 2010 6. Coding Options for Bulk Signaling Efficiency and benefit of bulk signaling depends on how much and which data can be shared between individual user sessions; this is reflected in the applicable coding schemes. Three efficiency classes have been identified, which are summarized in the following list. Subsequently, coding options for three different data structures are described, in descending order of their benefit from bulk signaling. o Most benefit -- Group-ID identifies multiple users, list of attribute/values applies to all users being identified by the Group-ID. o Medium benefit -- Lists of Session-IDs identifies a group of users, list of attribute/values applies to all users being identified by the Session-ID list. o Least benefit -- List of Session-ID identifies users, each Session-ID has a list of individual attribute/values accompanied, which is valid solely for a single user being identified by the Session-ID. The data structure with most benefit is shown in Figure 7: A group of user Session-IDs is identified by a Group-ID. The list of attribute/ values applies to all users being identified by the Group-ID. Such scheme can be very efficient for group handling, but may be disadvantageous for recovery of total node failures, as in most cases nodes will loose the binding information between the Group-ID and the associated user Session-IDs. +---------------------+ | | | | | [Group-ID] | | 1*[AVP] | | | +---------------------+ Figure 7: AVPs apply to a group of users being identified by a Group-ID The data structure given in Figure 8 has less benefit from bulk signaling: A group of users is identified by a list of Session-IDs. The list of attributes/values is valid for all users being identified by the list of Session-IDs. Such coding option may require the specification of a rule that applies all AVPs after the list of user Session-IDs to all users being identified by the list of Session-IDs. Liebsch & Punz Expires April 29, 2011 [Page 14] Internet-Draft Diameter General Purpose Session October 2010 +---------------------+ | | | | | 1*[Session-ID] | | 1*[AVP] | | | +---------------------+ Figure 8: AVPs apply to a group of users being identified by multiple user Session-IDs Least benefit from bulk signaling results for a data structure where each Session ID has different values associated, hence a list of attributes and values must be grouped and assigned to each Session ID. After the Diameter header and the mandatory Session-ID AVP, which identifies the GP Session, a list of individual user Session- IDs and attributes/values follows. Unambiguous association of attributes/values to a particular user Session-ID must be supported. Diameter provides the option for grouped AVPs. An example for a grouped AVP which can be used for bulk signaling with the GP Session is depicted in Figure 8. +-----------------------------------------------------------------+ | | | Grouped AVP header identifies each UE's Session ID and groups | | associated AVPs: | | | | | | 1*[grouped AVP] | | | | Format of the grouped AVP: | | | | | | 1*[AVP] | | | +-----------------------------------------------------------------+ Figure 9: AVPs are grouped to an individual user, which is identified by a user Session-ID Liebsch & Punz Expires April 29, 2011 [Page 15] Internet-Draft Diameter General Purpose Session October 2010 7. Security Considerations The GP Session concept relies on the trust relationship and associated security association between a Diameter client and a server. Hence, security considerations do not go beyond what is covered in [RFC3588]. Liebsch & Punz Expires April 29, 2011 [Page 16] Internet-Draft Diameter General Purpose Session October 2010 8. IANA Considerations If the option field in the Session ID AVP is being used to identify a GP Session, no additional IANA requirements will be added by this specification. Future details about the specification and message format definitions may require IANA actions. Liebsch & Punz Expires April 29, 2011 [Page 17] Internet-Draft Diameter General Purpose Session October 2010 9. Acknowledgments Many thanks to Avi Lior, Mark Taylor, Jouni Korhonen and Qin Wu for their feedback to the first version of this draft. Liebsch & Punz Expires April 29, 2011 [Page 18] Internet-Draft Diameter General Purpose Session October 2010 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 10.2. Informative References [3GPP-DIAM] "3GPP TS 29.272 Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol", . [3GPP-EPC] "3GPP TS 23.401 General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", . [3GPP-PCRFFR] "3GPP TS 29.816 3GPP TS 29.272 Study on PRCF Failure and Restoration", . [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. Liebsch & Punz Expires April 29, 2011 [Page 19] Internet-Draft Diameter General Purpose Session October 2010 Authors' Addresses Marco Liebsch NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 D-69115 Heidelberg, Germany Phone: +49 6221 4342146 Email: liebsch@neclab.eu Gottfried Punz NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 D-69115 Heidelberg, Germany Phone: +49 6221 4342119 Email: punz@neclab.eu Liebsch & Punz Expires April 29, 2011 [Page 20]