DIME Working Group M. Liebsch
Internet-Draft G. Punz
Intended status: Standards Track NEC
Expires: December 31, 2010 June 29, 2010
Diameter General Purpose Session
draft-liebsch-dime-diameter-gps-00.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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 31, 2010.
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
Liebsch & Punz Expires December 31, 2010 [Page 1]
Internet-Draft Diameter General Purpose Session June 2010
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
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. PCRF Failure and Restoration . . . . . . . . . . . . . . . 5
3.2. Optimization for Mass Handling . . . . . . . . . . . . . . 6
3.3. 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. Message Extensions . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Liebsch & Punz Expires December 31, 2010 [Page 2]
Internet-Draft Diameter General Purpose Session June 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.
Another potential use case within 3GPP consists in optimization for
mass handling, (mass activation/de-activation, mass 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 31, 2010 [Page 3]
Internet-Draft Diameter General Purpose Session June 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 December 31, 2010 [Page 4]
Internet-Draft Diameter General Purpose Session June 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
mass handling are relevant in current 3GPP work and reflect the need
for more efficient Diameter signaling.
3.1. 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).
+----+
| 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.
Liebsch & Punz Expires December 31, 2010 [Page 5]
Internet-Draft Diameter General Purpose Session June 2010
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.2. Optimization for Mass 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.
+=========+
| 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 mass 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].
Liebsch & Punz Expires December 31, 2010 [Page 6]
Internet-Draft Diameter General Purpose Session June 2010
3.3. 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
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.
Liebsch & Punz Expires December 31, 2010 [Page 7]
Internet-Draft Diameter General Purpose Session June 2010
+----------------+
| |
| 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 31, 2010 [Page 8]
Internet-Draft Diameter General Purpose Session June 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 December 31, 2010 [Page 9]
Internet-Draft Diameter General Purpose Session June 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 December 31, 2010 [Page 10]
Internet-Draft Diameter General Purpose Session June 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 December 31, 2010 [Page 11]
Internet-Draft Diameter General Purpose Session June 2010
5. Message Extensions
Details about extensions to Diameter messages and associated AVPs to
handle GP Sessions are for further study and will be described in
future versions of this document.
Liebsch & Punz Expires December 31, 2010 [Page 12]
Internet-Draft Diameter General Purpose Session June 2010
6. 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 31, 2010 [Page 13]
Internet-Draft Diameter General Purpose Session June 2010
7. 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 31, 2010 [Page 14]
Internet-Draft Diameter General Purpose Session June 2010
8. References
8.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.
8.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 31, 2010 [Page 15]
Internet-Draft Diameter General Purpose Session June 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 December 31, 2010 [Page 16]