< draft-ietf-dime-app-design-guide-20.txt   draft-ietf-dime-app-design-guide-21.txt >
Diameter Maintenance and Extensions (DIME) L. Morand, Ed. Diameter Maintenance and Extensions (DIME) L. Morand, Ed.
Internet-Draft Orange Labs Internet-Draft Orange Labs
Intended status: Informational V. Fajardo Intended status: Informational V. Fajardo
Expires: April 07, 2014 Expires: June 22, 2014
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
October 04, 2013 December 19, 2013
Diameter Applications Design Guidelines Diameter Applications Design Guidelines
draft-ietf-dime-app-design-guide-20 draft-ietf-dime-app-design-guide-21
Abstract Abstract
The Diameter base protocol provides facilities for protocol The Diameter base protocol provides facilities for protocol
extensibility enabling to define new Diameter applications or modify extensibility enabling to define new Diameter applications or modify
existing applications. This document is a companion document to the existing applications. This document is a companion document to the
Diameter Base protocol that further explains and clarifies the rules Diameter Base protocol that further explains and clarifies the rules
to extend Diameter. It is meant as a guidelines document and to extend Diameter. It is meant as a guidelines document and
therefore as informative in nature. therefore as informative in nature.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 07, 2014. This Internet-Draft will expire on June 22, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Reusing Existing Diameter Applications . . . . . . . . . . . 5 4. Reusing Existing Diameter Applications . . . . . . . . . . . 5
4.1. Adding a New Command . . . . . . . . . . . . . . . . . . 5 4.1. Adding a New Command . . . . . . . . . . . . . . . . . . 5
4.2. Deleting an Existing Command . . . . . . . . . . . . . . 6 4.2. Deleting an Existing Command . . . . . . . . . . . . . . 6
4.3. Reusing Existing Commands . . . . . . . . . . . . . . . . 6 4.3. Reusing Existing Commands . . . . . . . . . . . . . . . . 6
4.3.1. Adding AVPs to a Command . . . . . . . . . . . . . . 6 4.3.1. Adding AVPs to a Command . . . . . . . . . . . . . . 7
4.3.2. Deleting AVPs from a Command . . . . . . . . . . . . 8 4.3.2. Deleting AVPs from a Command . . . . . . . . . . . . 8
4.4. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . 9 4.4. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . 9
4.4.1. Setting of the AVP Flags . . . . . . . . . . . . . . 9 4.4.1. Setting of the AVP Flags . . . . . . . . . . . . . . 9
4.4.2. Reuse of AVP of Type Enumerated . . . . . . . . . . . 9 4.4.2. Reuse of AVP of Type Enumerated . . . . . . . . . . . 9
5. Defining New Diameter Applications . . . . . . . . . . . . . 9 5. Defining New Diameter Applications . . . . . . . . . . . . . 10
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Defining New Commands . . . . . . . . . . . . . . . . . . 10 5.2. Defining New Commands . . . . . . . . . . . . . . . . . . 10
5.3. Use of Application-Id in a Message . . . . . . . . . . . 10 5.3. Use of Application-Id in a Message . . . . . . . . . . . 11
5.4. Application-Specific Session State Machines . . . . . . . 11 5.4. Application-Specific Session State Machines . . . . . . . 11
5.5. Session-Id AVP and Session Management . . . . . . . . . . 11 5.5. Session-Id AVP and Session Management . . . . . . . . . . 12
5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 12 5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 12
5.7. Application-Specific Message Routing . . . . . . . . . . 13 5.7. Application-Specific Message Routing . . . . . . . . . . 14
5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 13 5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 15
5.9. End-to-End Application Capabilities Exchange . . . . . . 14 5.9. End-to-End Application Capabilities Exchange . . . . . . 15
5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 15 5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 16
5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 16 5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 18
6. Defining Generic Diameter Extensions . . . . . . . . . . . . 17 6. Defining Generic Diameter Extensions . . . . . . . . . . . . 18
7. Guidelines for Registrations of Diameter Values . . . . . . . 18 7. Guidelines for Registrations of Diameter Values . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
12. Informative References . . . . . . . . . . . . . . . . . . . 21 12. Informative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The Diameter base protocol provides facilities to extend Diameter The Diameter base protocol provides facilities to extend Diameter
(see Section 1.3 of [RFC6733]) to support new functionality. In the (see Section 1.3 of [RFC6733]) to support new functionality. In the
context of this document, extending Diameter means one of the context of this document, extending Diameter means one of the
following: following:
1. Addition of new functionality to an existing Diameter application 1. Addition of new functionality to an existing Diameter application
without defining a new application. without defining a new application.
skipping to change at page 10, line 31 skipping to change at page 10, line 44
5.2. Defining New Commands 5.2. Defining New Commands
As a general recommendation, commands should not be defined from As a general recommendation, commands should not be defined from
scratch. It is instead recommend to re-use an existing command scratch. It is instead recommend to re-use an existing command
offering similar functionality and use it as a starting point. offering similar functionality and use it as a starting point.
Moreover, the new command's CCF syntax specification should be Moreover, the new command's CCF syntax specification should be
carefully defined when considering applicability and extensibility of carefully defined when considering applicability and extensibility of
the application. If most of the AVPs contained in the command are the application. If most of the AVPs contained in the command are
indicated as fixed or required, it might be difficult to reuse the indicated as fixed or required, it might be difficult to reuse the
same command and therefore the same application in a slighly changed same command and therefore the same application in a slightly changed
environment. Defining a command with most of the AVPs indicated as environment. Defining a command with most of the AVPs indicated as
optional must not be seen as a sub-optimal design introducing too optional must not be seen as a sub-optimal design introducing too
much flexibility in the protocol. The protocol designers are only much flexibility in the protocol. The protocol designers are only
advised to clearly state the condition of presence of these AVPs and advised to clearly state the condition of presence of these AVPs and
properly define the corresponding behaviour of the Diameter nodes properly define the corresponding behaviour of the Diameter nodes
when these AVPs are absent from the command. when these AVPs are absent from the command.
Note: As a hint for protocol designers, it is not sufficient to just Note: As a hint for protocol designers, it is not sufficient to just
look at the command's CCF syntax specification. It is also necessary look at the command's CCF syntax specification. It is also necessary
to carefully read through the accompanying text in the specification. to carefully read through the accompanying text in the specification.
skipping to change at page 12, line 40 skipping to change at page 13, line 5
5.6. Use of Enumerated Type AVPs 5.6. Use of Enumerated Type AVPs
The type Enumerated was initially defined to provide a list of valid The type Enumerated was initially defined to provide a list of valid
values for an AVP with their respective interpretation described in values for an AVP with their respective interpretation described in
the specification. For instance, AVPs of type Enumerated can be used the specification. For instance, AVPs of type Enumerated can be used
to provide further information on the reason for the termination of a to provide further information on the reason for the termination of a
session or a specific action to perform upon the reception of the session or a specific action to perform upon the reception of the
request. request.
However, AVPs of type Enumerated are too often used as a simple As described in the section 4.4.2 above, defining an AVP of type
Boolean flag, indicating for instance a specific permission or Enumerated presents some limitations in term of extensibility and
reusability. Indeed, the finite set of valid values defined at the
definition of the AVP of type Enumerated cannot be modified in
practice without causing backward compatibility issues with existing
implementations. As a consequence, AVPs of Type Enumerated cannot be
extended by adding new values to support new capabilities. Diameter
protocol designers are then strongly advised to carefully consider
before defining an Enumerated AVP whether the set of values will
remain unchanged or new values may be required in a near future. If
such extension is foreseen or cannot be avoided, it is recommended to
rather define AVPs of type Unsigned32 or Unsigned64 in which the data
field would contain an address space representing "values" that would
have the same use of Enumerated values.
For instance, an AVP describing possible access networks would be
defined as follow:
Access-Network-Type AVP (XXX) is of type Unsigned32 and contains an
32-bit address space representing types of access networks. This
application defines the following classes of access networks, all
identified by the thousands digit in the decimal notation:
o 1xxx (Mobile Access Networks)
o 2xxx (Fixed Access Network)
o 3xxx (Wireless Access Networks)
Values that fall within the Mobile Access Networks category are used
to inform a peer that a request has been sent for a user attached to
a mobile access networks. The following values are defined in this
application:
1001: 3GPP-GERAN
TBD.
1002: 3GPP-UTRAN-FDD
TBD.
Unlike Enumerated AVP, any new value can be added in the address
space defined by this Unsigned32 AVP without modifying the definition
of the AVP. There is therefore no risk of backward compatibility
issue, especially when intermediate nodes may be present between
Diameter endpoints.
In the same line, AVPs of type Enumerated are too often used as a
simple Boolean flag, indicating for instance a specific permission or
capability, and therefore only two values are defined, e.g., TRUE/ capability, and therefore only two values are defined, e.g., TRUE/
FALSE, AUTORIZED/UNAUTHORIZED or SUPPORTED/UNSUPPORTED. This is a FALSE, AUTORIZED/UNAUTHORIZED or SUPPORTED/UNSUPPORTED. This is a
sub-optimal design since it limits the extensibility of the sub-optimal design since it limits the extensibility of the
application: any new capability/permission would have to be supported application: any new capability/permission would have to be supported
by a new AVP or new Enumerated value of the already defined AVP, by a new AVP or new Enumerated value of the already defined AVP, with
causing backwards compatibility issues with existing implementations. the backward compatibility issues described above. Instead of using
an Enumerated AVP for a Boolean flag, protocol designers are again
Instead of using an Enumerated AVP for a Boolean flag, protocol encouraged to use AVPs of type Unsigned32 or Unsigned64 AVP in which
designers are encouraged to use Unsigned32 or Unsigned64 AVP type as the data field would be defined as bit mask whose bit settings are
bit mask whose bit settings are described in the relevant Diameter described in the relevant Diameter application specification. Such
application specification. Such AVPs can be reused and extended AVPs can be reused and extended without major impact on the Diameter
without major impact on the Diameter application. The bit mask application. The bit mask should leave room for future additions.
should leave room for future additions. Examples of AVPs that use Examples of AVPs that use bit masks are the Session-Binding AVP
bit masks are the Session-Binding AVP defined in [RFC6733] and the defined in [RFC6733] and the MIP6-Feature-Vector AVP defined in
MIP6-Feature-Vector AVP defined in [RFC5447]. [RFC5447].
5.7. Application-Specific Message Routing 5.7. Application-Specific Message Routing
As described in [RFC6733], a Diameter request that needs to be sent As described in [RFC6733], a Diameter request that needs to be sent
to a home server serving a specific realm, but not to a specific to a home server serving a specific realm, but not to a specific
server (such as the first request of a series of round trips), will server (such as the first request of a series of round trips), will
contain a Destination-Realm AVP and no Destination-Host AVP. contain a Destination-Realm AVP and no Destination-Host AVP.
For such a request, the message routing usually relies only on the For such a request, the message routing usually relies only on the
Destination- Realm AVP and the Application Id present in the request Destination- Realm AVP and the Application Id present in the request
skipping to change at page 22, line 5 skipping to change at page 23, line 15
draft-calhoun-diameter-res-mgmt-08.txt (work in progress), draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
March 2001. March 2001.
[Q.3303.3] [Q.3303.3]
3rd Generation Partnership Project, "ITU-T Recommendation 3rd Generation Partnership Project, "ITU-T Recommendation
Q.3303.3, "Resource control protocol no. 3 (rcp3): Q.3303.3, "Resource control protocol no. 3 (rcp3):
Protocol at the Rw interface between the Policy Decision Protocol at the Rw interface between the Policy Decision
Physical Entity (PD-PE) and the Policy Enforcement Physical Entity (PD-PE) and the Policy Enforcement
Physical Entity (PE-PE): Diameter"", 2008. Physical Entity (PE-PE): Diameter"", 2008.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005, "Diameter Network Access Server Application", RFC 4005,
August 2005. August 2005.
skipping to change at page 23, line 7 skipping to change at page 24, line 16
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010. 5996, September 2010.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012. "Diameter Base Protocol", RFC 6733, October 2012.
[TS29.228] [TS29.228]
3rd Generation Partnership Project, "3GPP TS 29.228; 3rd Generation Partnership Project, "3GPP TS 29.228;
Technical Specification Group Core Network and Terminals; Technical Specification Group Core Network and Terminals;
IP Multimedia (IM) Subsystem Cx and Dx Interfaces; IP Multimedia (IM) Subsystem Cx and Dx Interfaces;
Signalling flows and message contents", , Signalling flows and message contents",
<http://www.3gpp.org/ftp/Specs/html-info/29272.htm>. <http://www.3gpp.org/ftp/Specs/html-info/29272.htm>.
[TS29.229] [TS29.229]
3rd Generation Partnership Project, "3GPP TS 29.229; 3rd Generation Partnership Project, "3GPP TS 29.229;
Technical Specification Group Core Network and Terminals; Technical Specification Group Core Network and Terminals;
Cx and Dx interfaces based on the Diameter protocol; Cx and Dx interfaces based on the Diameter protocol;
Protocol details", , Protocol details",
<http://www.3gpp.org/ftp/Specs/html-info/29229.htm>. <http://www.3gpp.org/ftp/Specs/html-info/29229.htm>.
[TS29.328] [TS29.328]
3rd Generation Partnership Project, "3GPP TS 29.328; 3rd Generation Partnership Project, "3GPP TS 29.328;
Technical Specification Group Core Network and Terminals; Technical Specification Group Core Network and Terminals;
IP Multimedia (IM) Subsystem Sh interface; signalling IP Multimedia (IM) Subsystem Sh interface; signalling
flows and message content", , flows and message content",
<http://www.3gpp.org/ftp/Specs/html-info/29328.htm>. <http://www.3gpp.org/ftp/Specs/html-info/29328.htm>.
[TS29.329] [TS29.329]
3rd Generation Partnership Project, "3GPP TS 29.329; 3rd Generation Partnership Project, "3GPP TS 29.329;
Technical Specification Group Core Network and Terminals; Technical Specification Group Core Network and Terminals;
Sh Interface based on the Diameter protocol; Protocol Sh Interface based on the Diameter protocol; Protocol
details", , details",
<http://www.3gpp.org/ftp/Specs/html-info/29329.htm>. <http://www.3gpp.org/ftp/Specs/html-info/29329.htm>.
Authors' Addresses Authors' Addresses
Lionel Morand (editor) Lionel Morand (editor)
Orange Labs Orange Labs
38/40 rue du General Leclerc 38/40 rue du General Leclerc
Issy-Les-Moulineaux Cedex 9 92794 Issy-Les-Moulineaux Cedex 9 92794
France France
 End of changes. 19 change blocks. 
43 lines changed or deleted 100 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/