< draft-ietf-dime-app-design-guide-19.txt   draft-ietf-dime-app-design-guide-20.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: December 28, 2013 Expires: April 07, 2014
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
June 26, 2013 October 04, 2013
Diameter Applications Design Guidelines Diameter Applications Design Guidelines
draft-ietf-dime-app-design-guide-19 draft-ietf-dime-app-design-guide-20
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 December 28, 2013. This Internet-Draft will expire on April 07, 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . 9
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . 10
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 . . . . . . . . . . 11
5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 12 5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 12
5.7. Application-Specific Message Routing . . . . . . . . . . 12 5.7. Application-Specific Message Routing . . . . . . . . . . 13
5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 13 5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 13
5.9. End-to-End Application Capabilities Exchange . . . . . . 14 5.9. End-to-End Application Capabilities Exchange . . . . . . 14
5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 14 5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 15
5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 16 5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 16
6. Defining Generic Diameter Extensions . . . . . . . . . . . . 16 6. Defining Generic Diameter Extensions . . . . . . . . . . . . 17
7. Guidelines for Registrations of Diameter Values . . . . . . . 17 7. Guidelines for Registrations of Diameter Values . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
12. Informative References . . . . . . . . . . . . . . . . . . . 20 12. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 7, line 8 skipping to change at page 7, line 8
applications. Although reuse of existing commands is still applications. Although reuse of existing commands is still
recommended, protocol designers can consider defining a new command recommended, protocol designers can consider defining a new command
when it provides a solution more suitable than the twisting of an when it provides a solution more suitable than the twisting of an
existing command's use and applications. existing command's use and applications.
4.3.1. Adding AVPs to a Command 4.3.1. Adding AVPs to a Command
Based on the rules in [RFC6733], AVPs that are added to an existing Based on the rules in [RFC6733], AVPs that are added to an existing
command can be categorized into: command can be categorized into:
o Mandatory (to understand) AVPs. As defined in [RFC6733], these o Mandatory (to understand) AVPs. As defined in [RFC6733], these
are AVPs with the M-bit flag set, which means that a Diameter node are AVPs with the M-bit flag set in this command, which means that
receiving them is required to understand not only their values but a Diameter node receiving them is required to understand not only
also their semantics. Failure to do so will cause an message their values but also their semantics. Failure to do so will
handling error. This is regardless of whether these AVPs are cause an message handling error. This is regardless of whether
required or optional as specified by the command's Command Code these AVPs are required or optional as specified by the command's
Format (CCF) syntax . Command Code Format (CCF) syntax .
o Optional (to understand) AVPs. As defined in [RFC6733], these are o Optional (to understand) AVPs. As defined in [RFC6733], these are
AVPs with the M-bit flag cleared. A Diameter node receiving these AVPs with the M-bit flag cleared in this command. A Diameter node
AVPs can simply ignore them if it does not support them. receiving these AVPs can simply ignore them if it does not support
them.
The rules are strict in the case where the AVPs to be added are NOTE: As stated in RFC6733, the M-bit setting for a given AVP is
mandatory to understand, i.e., they have the M-bit set. A mandatory relevant to an application and each command within that
AVP cannot be added to an existing command without defining a new application that includes the AVP.
Diameter application, as stated in [RFC6733]. This falls into the
"Major Extensions" category. Despite the clarity of the rule, The rules are strict in the case where the AVPs to be added in an
ambiguity still arises when evaluating whether a new AVP being added exiting command are mandatory to understand, i.e., they have the
should be mandatory to begin with. Application designers should M-bit set. A mandatory AVP cannot be added to an existing command
consider the following questions when deciding about the M-bit for a without defining a new Diameter application, as stated in [RFC6733].
new AVP: This falls into the "Major Extensions" category. Despite the clarity
of the rule, ambiguity still arises when evaluating whether a new AVP
being added should be mandatory to begin with. Application designers
should consider the following questions when deciding about the M-bit
for a new AVP:
o Would it be required for the receiving side to be able to process o Would it be required for the receiving side to be able to process
and understand the AVP and its content? and understand the AVP and its content?
o Would the new AVPs change the state machine of the application? o Would the new AVPs change the state machine of the application?
o Would the presence of the new AVP lead to a different number of o Would the presence of the new AVP lead to a different number of
round-trips, effectively changing the state machine of the round-trips, effectively changing the state machine of the
application? application?
skipping to change at page 8, line 27 skipping to change at page 8, line 32
o Adding one or more optional AVPs and indicating (usually within o Adding one or more optional AVPs and indicating (usually within
descriptive text for the command) that at least one of them has to descriptive text for the command) that at least one of them has to
be present in the command. This essentially circumventing the be present in the command. This essentially circumventing the
ABNF and is equivalent to adding a mandatory AVP to the command. ABNF and is equivalent to adding a mandatory AVP to the command.
These practices generally result in interoperability issues and These practices generally result in interoperability issues and
should be avoided as much as possible. should be avoided as much as possible.
4.3.2. Deleting AVPs from a Command 4.3.2. Deleting AVPs from a Command
Application designers may want to reuse an existing command but some
of the AVP present in the command's CCF syntax specification may be
irrelevant for the functionality foreseen to be supported by this
command. It may be then tempting to delete those AVPs from the
command.
The impacts of deleting an AVP from a command depends on its command The impacts of deleting an AVP from a command depends on its command
code format specification and M-bit setting: code format specification and M-bit setting:
o Deleting an AVP that is indicated as { AVP } in the command's CCF o Deleting an AVP that is indicated as { AVP } in the command's CCF
syntax specification (regardless of the M-bit setting). syntax specification (regardless of the M-bit setting).
In this case, a new command code and subsequently a new Diameter In this case, a new command code and subsequently a new Diameter
application have to be specified. application have to be specified.
o Deleting an AVP, which has the M-bit set, and is indicated as [ o Deleting an AVP, which has the M-bit set, and is indicated as [
skipping to change at page 9, line 23 skipping to change at page 9, line 35
the mandatory flag ('M'-bit), has to be re-evaluated for a new the mandatory flag ('M'-bit), has to be re-evaluated for a new
Diameter application and, if necessary, even for every command within Diameter application and, if necessary, even for every command within
the application. In general, for AVPs defined outside of the the application. In general, for AVPs defined outside of the
Diameter base protocol, the characteristics of an AVP are tied to its Diameter base protocol, the characteristics of an AVP are tied to its
role within an application and the commands. role within an application and the commands.
All other AVP flags shall remain unchanged. All other AVP flags shall remain unchanged.
4.4.2. Reuse of AVP of Type Enumerated 4.4.2. Reuse of AVP of Type Enumerated
When modifying the set of values supported by an AVP of type When reusing an AVP of type Enumerated in a command for a new
Enumerated, this means defining a new AVP. Modifying the set of application, it is recommended to avoid modifying the set of valid
Enumerated values includes adding a value or deprecating the use of a values defined for this AVP. Modifying the set of Enumerated values
value defined initially for the AVP. Defining a new AVP will avoid includes adding a value or deprecating the use of a value defined
interoperability issues. initially for the AVP. Modifying the set of values will impact the
application defining this AVP and all the applications using this AVP
with potential interoperability issues. When the full range of
values defined for this Enumerated AVP is not suitable for the new
application, it is recommended to define a new AVP to avoid backwards
compatibility issues with existing implementations.
5. Defining New Diameter Applications 5. Defining New Diameter Applications
5.1. Introduction 5.1. Introduction
This section discusses the case where new applications have This section discusses the case where new applications have
requirements that cannot be fulfilled by existing applications and requirements that cannot be fulfilled by existing applications and
would require definition of completely new commands, AVPs and/or AVP would require definition of completely new commands, AVPs and/or AVP
values. Typically, there is little ambiguity about the decision to values. Typically, there is little ambiguity about the decision to
create these types of applications. Some examples are the interfaces create these types of applications. Some examples are the interfaces
defined for the IP Multimedia Subsystem of 3GPP, e.g., Cx/Dx defined for the IP Multimedia Subsystem of 3GPP, e.g., Cx/Dx
([TS29.228] and [TS29.229]), Sh ([TS29.328] and [TS29.329]) etc. ([TS29.228] and [TS29.229]), Sh ([TS29.328] and [TS29.329]) etc.
skipping to change at page 12, line 41 skipping to change at page 13, line 11
designers are encouraged to use Unsigned32 or Unsigned64 AVP type as designers are encouraged to use Unsigned32 or Unsigned64 AVP type as
bit mask whose bit settings are described in the relevant Diameter bit mask whose bit settings are described in the relevant Diameter
application specification. Such AVPs can be reused and extended application specification. Such AVPs can be reused and extended
without major impact on the Diameter application. The bit mask without major impact on the Diameter application. The bit mask
should leave room for future additions. Examples of AVPs that use should leave room for future additions. Examples of AVPs that use
bit masks are the Session-Binding AVP defined in [RFC6733] and the bit masks are the Session-Binding AVP defined in [RFC6733] and the
MIP6-Feature-Vector AVP defined in [RFC5447]. MIP6-Feature-Vector AVP defined in [RFC5447].
5.7. Application-Specific Message Routing 5.7. Application-Specific Message Routing
Diameter request message routing usually relies on the Destination- As described in [RFC6733], a Diameter request that needs to be sent
Realm AVP and the Application Id present in the request message to a home server serving a specific realm, but not to a specific
header. However, some applications may need to rely on the User-Name server (such as the first request of a series of round trips), will
AVP or any other application-specific AVP present in the request to contain a Destination-Realm AVP and no Destination-Host AVP.
determine the final destination of a request, e.g., to find the
target AAA server hosting the authorization information for a given For such a request, the message routing usually relies only on the
user when multiple AAA servers are addressable in the realm. Destination- Realm AVP and the Application Id present in the request
message header. However, some applications may need to rely on the
User-Name AVP or any other application-specific AVP present in the
request to determine the final destination of a request, e.g., to
find the target AAA server hosting the authorization information for
a given user when multiple AAA servers are addressable in the realm.
In such a context, basic routing mechanisms described in [RFC6733] In such a context, basic routing mechanisms described in [RFC6733]
are not fully suitable, and additional application-level routing are not fully suitable, and additional application-level routing
mechanisms have to be described in the application documentation to mechanisms have to be described in the application documentation to
provide such specific AVP-based routing. Such functionality will be provide such specific AVP-based routing. Such functionality will be
basically hosted by an application-specific proxy agent that will be basically hosted by an application-specific proxy agent that will be
responsible for routing decisions based on the received specific responsible for routing decisions based on the received specific
AVPs. AVPs.
Examples of such application-specific routing functions can be found Examples of such application-specific routing functions can be found
skipping to change at page 15, line 19 skipping to change at page 15, line 44
accounting for one or more Diameter applications. accounting for one or more Diameter applications.
Centralizing accounting may have advantages but there are also Centralizing accounting may have advantages but there are also
drawbacks. The model assumes that the accounting server can drawbacks. The model assumes that the accounting server can
differentiate received accounting messages. Since the received differentiate received accounting messages. Since the received
accounting messages can be for any application and/or service, the accounting messages can be for any application and/or service, the
accounting server has to have a method to match accounting accounting server has to have a method to match accounting
messages with applications and/or services being accounted for. messages with applications and/or services being accounted for.
This may mean defining new AVPs, checking the presence, absence or This may mean defining new AVPs, checking the presence, absence or
contents of existing AVPs, or checking the contents of the contents of existing AVPs, or checking the contents of the
accounting record itself. But in general, there is no clean and accounting record itself. One of these means could be to insert
generic scheme for sorting these messages. Therefore, the use of into the request sent to the accounting server an Auth-
this model is recommended only when all received accounting Application-Id AVP containing the identifier of the application
messages can be clearly identified and sorted. For most cases, for which the accounting request is sent. But in general, there
the use of Coupled Accounting Model is recommended. is no clean and generic scheme for sorting these messages.
Therefore, the use of this model is recommended only when all
received accounting messages can be clearly identified and sorted.
For most cases, the use of Coupled Accounting Model is
recommended.
Coupled Accounting Model: Coupled Accounting Model:
In this model, the accounting messages will use the Application Id In this model, the accounting messages will use the Application Id
of the application using the accounting service. The design of the application using the accounting service. The design
implication for this is that the accounting messages are tightly implication for this is that the accounting messages are tightly
coupled with the application itself; meaning that accounting coupled with the application itself; meaning that accounting
messages will be routed like the other application messages. It messages will be routed like the other application messages. It
would then be the responsibility of the application server would then be the responsibility of the application server
(application entity receiving the ACR message) to send the (application entity receiving the ACR message) to send the
skipping to change at page 20, line 46 skipping to change at page 21, line 30
o Dave Frascone o Dave Frascone
We would like to thank Tolga Asveren, Glenn McGregor, and John We would like to thank Tolga Asveren, Glenn McGregor, and John
Loughney for their contributions as co-authors to earlier versions of Loughney for their contributions as co-authors to earlier versions of
this document. this document.
11. Acknowledgments 11. Acknowledgments
We greatly appreciate the insight provided by Diameter implementers We greatly appreciate the insight provided by Diameter implementers
who have highlighted the issues and concerns being addressed by this who have highlighted the issues and concerns being addressed by this
document. The authors would also like to thank Jean Mahoney and Ben document. The authors would also like to thank Jean Mahoney, Ben
Campbell for their invaluable detailed review and comments on this Campbell and Sebastien Decugis for their invaluable detailed reviews
document. and comments on this document.
12. Informative References 12. Informative References
[I-D.asveren-dime-dupcons] [I-D.asveren-dime-dupcons]
Asveren, T., "Diameter Duplicate Detection Cons.", draft- Asveren, T., "Diameter Duplicate Detection Cons.", draft-
asveren-dime-dupcons-00 (work in progress), August 2006. asveren-dime-dupcons-00 (work in progress), August 2006.
[I-D.calhoun-diameter-res-mgmt] [I-D.calhoun-diameter-res-mgmt]
Calhoun, P., "Diameter Resource Management Extensions", Calhoun, P., "Diameter Resource Management Extensions",
draft-calhoun-diameter-res-mgmt-08.txt (work in progress), draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
 End of changes. 18 change blocks. 
52 lines changed or deleted 76 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/