DIME Working Group M. Liebsch
Internet-Draft G. Punz
Intended status: Standards Track NEC
Expires: December 26, 2011 June 24, 2011
Diameter General Purpose Session
draft-liebsch-dime-diameter-gps-02.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 December 26, 2011.
Copyright Notice
Copyright (c) 2011 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 December 26, 2011 [Page 1]
Internet-Draft Diameter General Purpose Session June 2011
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
Appendix A. Change Notes . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Liebsch & Punz Expires December 26, 2011 [Page 2]
Internet-Draft Diameter General Purpose Session June 2011
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 December 26, 2011 [Page 3]
Internet-Draft Diameter General Purpose Session June 2011
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 December 26, 2011 [Page 4]
Internet-Draft Diameter General Purpose Session June 2011
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 December 26, 2011 [Page 5]
Internet-Draft Diameter General Purpose Session June 2011
+----+
| 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 December 26, 2011 [Page 6]
Internet-Draft Diameter General Purpose Session June 2011
+=========+
| 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 December 26, 2011 [Page 7]
Internet-Draft Diameter General Purpose Session June 2011
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 December 26, 2011 [Page 8]
Internet-Draft Diameter General Purpose Session June 2011
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 December 26, 2011 [Page 9]
Internet-Draft Diameter General Purpose Session June 2011
+-----+
|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 December 26, 2011 [Page 10]
Internet-Draft Diameter General Purpose Session June 2011
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 December 26, 2011 [Page 11]
Internet-Draft Diameter General Purpose Session June 2011
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 December 26, 2011 [Page 12]
Internet-Draft Diameter General Purpose Session June 2011
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 December 26, 2011 [Page 13]
Internet-Draft Diameter General Purpose Session June 2011
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.
+---------------------+
| |
| <GPSession-ID> |
| [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 December 26, 2011 [Page 14]
Internet-Draft Diameter General Purpose Session June 2011
+---------------------+
| |
| <GPSession-ID> |
| 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: |
| |
| <GPSession-ID> |
| 1*[grouped AVP] |
| |
| Format of the grouped AVP: |
| |
| <Session-ID> |
| 1*[AVP] |
| |
+-----------------------------------------------------------------+
Figure 9: AVPs are grouped to an individual user, which is identified
by a user Session-ID
Liebsch & Punz Expires December 26, 2011 [Page 15]
Internet-Draft Diameter General Purpose Session June 2011
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 December 26, 2011 [Page 16]
Internet-Draft Diameter General Purpose Session June 2011
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 December 26, 2011 [Page 17]
Internet-Draft Diameter General Purpose Session June 2011
9. Acknowledgments
Many thanks to Avi Lior, Mark Jones, Jouni Korhonen, Frank Brockners,
Glen Zorn and Qin Wu for their feedback to previous versions of this
document.
Liebsch & Punz Expires December 26, 2011 [Page 18]
Internet-Draft Diameter General Purpose Session June 2011
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", <http://www.3gpp.org>.
[3GPP-EPC]
"3GPP TS 23.401 General Packet Radio Service (GPRS)
enhancements for Evolved Universal Terrestrial Radio
Access Network (E-UTRAN) access", <http://www.3gpp.org>.
[3GPP-PCRFFR]
"3GPP TS 29.816 3GPP TS 29.272 Study on PRCF Failure and
Restoration", <http://www.3gpp.org>.
[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 December 26, 2011 [Page 19]
Internet-Draft Diameter General Purpose Session June 2011
Appendix A. Change Notes
Changes in version 01:
o Includes more details about shared Session
o Includes proposal about migration steps to deploy Diameter GPS in
other SDOs, e.g. in 3GPP
o Includes analysis and first proposal about grouping AVPs for bulk
signaling
Changes in version 02:
o Editorial revision
Liebsch & Punz Expires December 26, 2011 [Page 20]
Internet-Draft Diameter General Purpose Session June 2011
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 December 26, 2011 [Page 21]