< draft-ietf-dime-app-design-guide-21.txt   draft-ietf-dime-app-design-guide-22.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: Best Current Practice V. Fajardo
Expires: June 22, 2014 Expires: October 17, 2014 Independent
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
December 19, 2013 April 15, 2014
Diameter Applications Design Guidelines Diameter Applications Design Guidelines
draft-ietf-dime-app-design-guide-21 draft-ietf-dime-app-design-guide-22
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 June 22, 2014. This Internet-Draft will expire on October 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . 7
4.3.1. Adding AVPs to a Command . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . 10
4.4.2. Reuse of AVP of Type Enumerated . . . . . . . . . . . 9 4.4.2. Reuse of AVP of Type Enumerated . . . . . . . . . . . 10
5. Defining New Diameter Applications . . . . . . . . . . . . . 10 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 . . . . . . . . . . . 11 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 . . . . . . . 12
5.5. Session-Id AVP and Session Management . . . . . . . . . . 12 5.5. Session-Id AVP and Session Management . . . . . . . . . . 12
5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 12 5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 13
5.7. Application-Specific Message Routing . . . . . . . . . . 14 5.7. Application-Specific Message Routing . . . . . . . . . . 15
5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 15 5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 15
5.9. End-to-End Application Capabilities Exchange . . . . . . 15 5.9. End-to-End Application Capabilities Exchange . . . . . . 16
5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 16 5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 17
5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 18 5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 18
6. Defining Generic Diameter Extensions . . . . . . . . . . . . 18 6. Defining Generic Diameter Extensions . . . . . . . . . . . . 19
7. Guidelines for Registrations of Diameter Values . . . . . . . 19 7. Guidelines for Registrations of Diameter Values . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
12. Informative References . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 3, line 46 skipping to change at page 3, line 48
Diameter base protocol. Diameter base protocol.
o Discuss design choices and provide guidelines when defining new o Discuss design choices and provide guidelines when defining new
applications. applications.
o Present trade-off choices. o Present trade-off choices.
2. Terminology 2. Terminology
This document reuses the terminology defined in [RFC6733]. This document reuses the terminology defined in [RFC6733].
Additionally, the following terms and acronyms are used in this
application:
Application Extension of the Diameter base protocol [RFC6733] via
the addition of new commands or AVPs. Each application is
uniquely identified by an IANA-allocated application identifier
value.
Command Diameter request or answer carrying AVPs between Diameter
endpoints. Each command is uniquely identified by a IANA-
allocated command code value and is described by a Command Code
Format (CCF) for an application.
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].
3. Overview 3. Overview
As designed, the Diameter base protocol [RFC6733] can be seen as a As designed, the Diameter base protocol [RFC6733] can be seen as a
two-layer protocol. The lower layer is mainly responsible for two-layer protocol. The lower layer is mainly responsible for
managing connections between neighboring peers and for message managing connections between neighboring peers and for message
routing. The upper layer is where the Diameter applications reside. routing. The upper layer is where the Diameter applications reside.
This model is in line with a Diameter node having an application This model is in line with a Diameter node having an application
layer and a peer-to-peer delivery layer. The Diameter base protocol layer and a peer-to-peer delivery layer. The Diameter base protocol
document defines the architecture and behavior of the message document defines the architecture and behavior of the message
skipping to change at page 4, line 28 skipping to change at page 4, line 47
summary, Diameter can be extended by: summary, Diameter can be extended by:
1. Defining new AVP values 1. Defining new AVP values
2. Creating new AVPs 2. Creating new AVPs
3. Creating new commands 3. Creating new commands
4. Creating new applications 4. Creating new applications
As a main guiding principle, the recommendation is: "try to re-use as As a main guiding principle, application designers SHOULD follow the
much as possible!". It will reduce the time to finalize following recommendation: "try to re-use as much as possible!". It
specification writing, and it will lead to a smaller implementation will reduce the time to finalize specification writing, and it will
effort as well as reduce the need for testing. In general, it is lead to a smaller implementation effort as well as reduce the need
clever to avoid duplicate effort when possible. for testing. In general, it is clever to avoid duplicate effort when
possible.
However, re-use is not appropriate when the existing functionality However, re-use is not appropriate when the existing functionality
does not fit the new requirement and/or the re-use leads to does not fit the new requirement and/or the re-use leads to
ambiguity. ambiguity.
The impact on extending existing applications can be categorized into The impact on extending existing applications can be categorized into
two groups: two groups:
Minor Extension: Enhancing the functional scope of an existing Minor Extension: Enhancing the functional scope of an existing
application by the addition of optional features to support. Such application by the addition of optional features to support. Such
enhancement has no backward compatibility issue with the existing enhancement has no backward compatibility issue with the existing
application. application.
A typical example would be the definition of a new optional AVP A typical example would be the definition of a new optional AVP
for use in an existing command. Diameter implementations for use in an existing command. Diameter implementations
supporting the existing application but not the new AVP will supporting the existing application but not the new AVP will
simply ignore it, without consequences for the Diameter message simply ignore it, without consequences for the Diameter message
handling. The standardization effort will be fairly small. handling, as described in [RFC6733]. The standardization effort
will be fairly small.
Major Extension: Enhancing an application that requires the Major Extension: Enhancing an application that requires the
definition of a new Diameter application. definition of a new Diameter application. Such enhancement causes
backward compatibility issue with existing implementations
supporting the application.
Typical examples would be the creation of a new command for Typical examples would be the creation of a new command for
providing functionality not supported by existing applications or providing functionality not supported by existing applications or
the definition of a new AVP with the M-bit set to be carried in an the definition of a new AVP to be carried in an existing command
existing command. For such extension, a significant specification with the M-bit set in the AVP flags (see Section 4.1 of [RFC6733]
effort is required and a careful approach is recommended. for definition of the "M-bit"). For such extension, a significant
specification effort is required and a careful approach is
We would also like to remind that the definition of a new Diameter recommended.
application and the definition of a new command should be something
to avoid as much as possible. In the past, there has been some
reluctance to define new commands and new applications. With the
modified extensibility rules provided by [RFC6733], registering new
commands and new applications does not lead to additional overhead
for the specification author in terms of standardization process.
Registering new functionality (new commands, new AVPs, new
applications, etc.) with IANA remains important to avoid namespace
collisions, which will likely lead to deployment problems.
4. Reusing Existing Diameter Applications 4. Reusing Existing Diameter Applications
An existing application may need to be enhanced to fulfill new An existing application may need to be enhanced to fulfill new
requirements and these modifications can be at the command level and/ requirements and these modifications can be at the command level and/
or at the AVP level. The following sections describe the possible or at the AVP level. The following sections describe the possible
modifications that can be performed on existing applications and modifications that can be performed on existing applications and
their related impact. their related impact.
4.1. Adding a New Command 4.1. Adding a New Command
Adding a new command is considered as a major extension and requires Adding a new command to an existing application is considered as a
a new Diameter application to be defined. Adding a new command to an major extension and requires a new Diameter application to be
application means either defining a completely new command or defined. Adding a new command means either defining a completely new
importing the command's Command Code Format (CCF) syntax from another command or importing the command's Command Code Format (CCF) syntax
application whereby the new application inherits some or all of the from another application whereby the new application inherits some or
functionality of the application where the command came from. In the all of the functionality of the application where the command came
former case, the decision to create a new application is from. In the former case, the decision to create a new application
straightforward since this is typically a result of adding a new is straightforward since this is typically a result of adding a new
functionality that does not exist yet. For the latter, the decision functionality that does not exist yet. For the latter, the decision
to create a new application will depend on whether importing the to create a new application will depend on whether importing the
command in a new application is more suitable than simply using the command in a new application is more suitable than simply using the
existing application as it is in conjunction with any other existing application as it is in conjunction with any other
application. Therefore, a case by case study of each application application. Therefore, a case by case study of each application
requirement should be applied. requirement SHOULD be applied.
An example considers the Diameter EAP application [RFC4072] and the An example considers the Diameter EAP application [RFC4072] and the
Diameter NASREQ application [RFC4005]. When network access Diameter Network Access Server application [RFC7155]. When network
authentication using EAP is required, the Diameter EAP commands access authentication using EAP is required, the Diameter EAP
(Diameter-EAP-Request/Diameter-EAP-Answer) are used; otherwise the commands (Diameter-EAP-Request/Diameter-EAP-Answer) are used;
NASREQ application will be used. When the Diameter EAP application otherwise the Diameter Network Access Server application will be
is used, the accounting exchanges defined in Diameter NASREQ may be used. When the Diameter EAP application is used, the accounting
used. exchanges defined in the Diameter Network Access Server may be used.
However, in general, it is difficult to come to a hard guideline, and However, in general, it is difficult to come to a hard guideline, and
so a case-by-case study of each application requirement should be so a case-by-case study of each application requirement should be
applied. Before adding or importing a command, application designers applied. Before adding or importing a command, application designers
should consider the following: should consider the following:
o Can the new functionality be fulfilled by creating a new command o Can the new functionality be fulfilled by creating a new command
independent from any existing command? In this case, the independent from any existing command? In this case, the
resulting new application and the existing application can work resulting new application and the existing application can work
independent of, but cooperating with each other. independent of, but cooperating with each other.
o Can the existing command be reused without major extensions and o Can the existing command be reused without major extensions and
therefore without the need for the definition of a new therefore without the need for the definition of a new
application, e.g., new functionality introduced by the creation of application, e.g. new functionality introduced by the creation of
new optional AVPs. new optional AVPs.
Note: Importing commands too liberally could result in a monolithic Note: Importing commands too liberally could result in a monolithic
and hard to manage application supporting too many different and hard to manage application supporting too many different
features. features.
4.2. Deleting an Existing Command 4.2. Deleting an Existing Command
Although this process is not typical, removing a command from an Although this process is not typical, removing a command from an
application requires a new Diameter application to be defined. This application requires a new Diameter application to be defined and
is due to the fact that the reception of the deleted command would then it is considered as a major extension. This is due to the fact
systematically result in a protocol error (i.e., that the reception of the deleted command would systematically result
DIAMETER_COMMAND_UNSUPPORTED). in a protocol error (i.e., DIAMETER_COMMAND_UNSUPPORTED).
It is unusual to delete an existing command from an application for It is unusual to delete an existing command from an application for
the sake of deleting it or the functionality it represents. This the sake of deleting it or the functionality it represents. This
normally indicates of a flawed design. An exception might be if the normally indicates of a flawed design. An exception might be if the
intent of the deletion is to create a newer version of the same intent of the deletion is to create a newer variance of the same
application that is somehow simpler than the previous version. application that is somehow simpler than the application initially
specified.
4.3. Reusing Existing Commands 4.3. Reusing Existing Commands
This section discusses rules in adding and/or deleting AVPs from an This section discusses rules in adding and/or deleting AVPs from an
existing command of an existing application. The cases described in existing command of an existing application. The cases described in
this section may not necessarily result in the creation of new this section may not necessarily result in the creation of new
applications. applications.
From a historical point of view, it is worth to note that there was a From a historical point of view, it is worth to note that there was a
strong recommendation to re-use existing commands in the [RFC3588] to strong recommendation to re-use existing commands in the [RFC3588] to
prevent rapid depletion of code values available for vendor-specific prevent rapid depletion of code values available for vendor-specific
commands. However, [RFC6733] has relaxed the allocation policy and commands. However, [RFC6733] has relaxed the allocation policy and
enlarged the range of available code values for vendor-specific enlarged the range of available code values for vendor-specific
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 MAY 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 in this command, which means that are AVPs with the M-bit flag set in this command, which means that
a Diameter node receiving them is required to understand not only a Diameter node receiving them is required to understand not only
their values but also their semantics. Failure to do so will their values but also their semantics. Failure to do so will
cause an message handling error. This is regardless of whether cause an message handling error.
these AVPs are required or optional as specified by the command's
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 in this command. A Diameter node AVPs with the M-bit flag cleared in this command. A Diameter node
receiving these AVPs can simply ignore them if it does not support receiving these AVPs can simply ignore them if it does not support
them. them.
It is important to note that the definition given above are
independent of whether these AVPs are required or optional in the
command as specified by the command's Command Code Format (CCF)
syntax [RFC6733].
NOTE: As stated in RFC6733, the M-bit setting for a given AVP is NOTE: As stated in RFC6733, the M-bit setting for a given AVP is
relevant to an application and each command within that relevant to an application and each command within that
application that includes the AVP. application that includes the AVP.
The rules are strict in the case where the AVPs to be added in an The rules are strict in the case where the AVPs to be added in an
exiting command are mandatory to understand, i.e., they have the exiting command are mandatory to understand, i.e., they have the
M-bit set. A mandatory AVP cannot be added to an existing command M-bit set. A mandatory AVP MUST NOT be added to an existing command
without defining a new Diameter application, as stated in [RFC6733]. without defining a new Diameter application, as stated in [RFC6733].
This falls into the "Major Extensions" category. Despite the clarity This falls into the "Major Extensions" category. Despite the clarity
of the rule, ambiguity still arises when evaluating whether a new AVP of the rule, ambiguity still arises when evaluating whether a new AVP
being added should be mandatory to begin with. Application designers being added should be mandatory to begin with. Application designers
should consider the following questions when deciding about the M-bit SHOULD consider the following questions when deciding about the M-bit
for a new AVP: 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?
o Would the new AVP be used to differentiate between old and new o Would the new AVP be used to differentiate between old and new
versions of the same application whereby the two versions are not variances of the same application whereby the two variances are
backward compatible? not backward compatible?
o Would the new AVP have duality in meaning, i.e., be used to carry o Would the new AVP have duality in meaning, i.e., be used to carry
application-related information as well as to indicate that the application-related information as well as to indicate that the
message is for a new application? message is for a new application?
If the answer to at least one of the questions is "yes" then the If the answer to at least one of the questions is "yes" then the
M-bit has to be set for the new AVP. This list of questions is non- M-bit MUST be set for the new AVP. This list of questions is non-
exhaustive and other criteria can be taken into account in the exhaustive and other criteria MAY be taken into account in the
decision process. decision process.
If application designers are instead contemplating the use of If application designers are instead contemplating the use of
optional AVPs, i.e., with the M-bit cleared, then the following are optional AVPs, i.e., with the M-bit cleared, then the following are
some of the pitfalls that should be avoided: some of the pitfalls that SHOULD be avoided:
o Use of optional AVPs with intersecting meaning. One AVP has o Use of optional AVPs with intersecting meaning. One AVP has
partially the same usage and meaning as another AVP. The presence partially the same usage and meaning as another AVP. The presence
of both can lead to confusion. of both can lead to confusion.
o An optional AVPs with dual purpose, i.e., to carry application o An optional AVPs with dual purpose, i.e., to carry application
data as well as to indicate support for one or more features. data as well as to indicate support for one or more features.
This has a tendency to introduce interpretation issues. This has a tendency to introduce interpretation issues.
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.
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 Application designers may want to reuse an existing command but some
of the AVP present in the command's CCF syntax specification may be of the AVP present in the command's CCF syntax specification may be
irrelevant for the functionality foreseen to be supported by this irrelevant for the functionality foreseen to be supported by this
command. It may be then tempting to delete those AVPs from the command. It may be then tempting to delete those AVPs from the
command. 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 a required AVP (noted as
syntax specification (regardless of the M-bit setting). {AVP}) in the command's CCF 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 MUST 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
AVP ] in the command's CCF syntax specification. optional AVP (noted as [AVP]) in the command CCF) in the command's
CCF syntax specification.
No new command code has to be specified but the definition of a No new command code has to be specified but the definition of a
new Diameter application is required. new Diameter application is REQUIRED.
o Deleting an AVP, which has the M-bit cleared, and is indicated as o Deleting an AVP, which has the M-bit cleared, and is indicated as
[ AVP ] in the command's CCF syntax specification. [ AVP ] in the command's CCF syntax specification.
In this case, the AVP can be deleted without consequences. In this case, the AVP can be deleted without consequences.
If possible, application designers should attempt the reuse the Application designers SHOULD attempt the reuse the command's CCF
command's CCF syntax specification without modification and simply syntax specification without modification and simply ignore (but not
ignore (but not delete) any optional AVP that will not be used. This delete) any optional AVP that will not be used. This is to maintain
is to maintain compatibility with existing applications that will not compatibility with existing applications that will not know about the
know about the new functionality as well as maintain the integrity of new functionality as well as maintain the integrity of existing
existing dictionaries. dictionaries.
4.4. Reusing Existing AVPs 4.4. Reusing Existing AVPs
This section discusses rules in reusing existing AVP when reusing an This section discusses rules in reusing existing AVP when reusing an
existing command or defining a new command in a new application. existing command or defining a new command in a new application.
4.4.1. Setting of the AVP Flags 4.4.1. Setting of the AVP Flags
When reusing AVPs in a new application, the AVP flag setting, such as When reusing AVPs in a new application, the AVP flag setting, such as
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 MUST remain unchanged.
4.4.2. Reuse of AVP of Type Enumerated 4.4.2. Reuse of AVP of Type Enumerated
When reusing an AVP of type Enumerated in a command for a new When reusing an AVP of type Enumerated in a command for a new
application, it is recommended to avoid modifying the set of valid application, it is RECOMMENDED to avoid modifying the set of valid
values defined for this AVP. Modifying the set of Enumerated values values defined for this AVP. Modifying the set of Enumerated values
includes adding a value or deprecating the use of a value defined includes adding a value or deprecating the use of a value defined
initially for the AVP. Modifying the set of values will impact the initially for the AVP. Modifying the set of values will impact the
application defining this AVP and all the applications using this AVP application defining this AVP and all the applications using this AVP
with potential interoperability issues. When the full range of with potential interoperability issues. When the full range of
values defined for this Enumerated AVP is not suitable for the new values defined for this Enumerated AVP is not suitable for the new
application, it is recommended to define a new AVP to avoid backwards application, it is RECOMMENDED to define a new AVP to avoid backwards
compatibility issues with existing implementations. 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.
Application designers should try to import existing AVPs and AVP Application designers SHOULD try to import existing AVPs and AVP
values for any newly defined commands. In certain cases where values for any newly defined commands. In certain cases where
accounting will be used, the models described in Section 5.10 should accounting will be used, the models described in Section 5.10 SHOULD
also be considered. also be considered.
Additional considerations are described in the following sections. Additional considerations are described in the following sections.
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 RECOMMENDED 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. Code
re-use lead to a smaller implementation effort as well as reduce the
need for testing.
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 slightly 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 SHOULD only
advised to clearly state the condition of presence of these AVPs and clearly state the condition of presence of these AVPs and properly
properly define the corresponding behaviour of the Diameter nodes define the corresponding behaviour of the Diameter nodes when these
when these AVPs are absent from the command. 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
to carefully read through the accompanying text in the specification. necessary to carefully read through the accompanying text in the
specification.
In the same way, the CCF syntax specification should be defined such In the same way, the CCF syntax specification SHOULD be defined such
that it will be possible to add any arbitrary optional AVPs with the that it will be possible to add any arbitrary optional AVPs with the
M-bit cleared (including vendor-specific AVPs) without modifying the M-bit cleared (including vendor-specific AVPs) without modifying the
application. For this purpose, it is strongly recommended to add "* application. For this purpose, "* [AVP]" SHOULD be added in the
[AVP]" in the command's CCF, which allows the addition of any command's CCF, which allows the addition of any arbitrary AVP as
arbitrary AVP as described in [RFC6733]. described in [RFC6733].
5.3. Use of Application-Id in a Message 5.3. Use of Application-Id in a Message
When designing new applications, designers should specify that the When designing new applications, application designers SHOULD specify
Application Id carried in all session-level messages must be the that the Application Id carried in all session-level messages is the
Application Id of the application using those messages. This Application Id of the application using those messages. This
includes the session-level messages defined in Diameter base includes the session-level messages defined in Diameter base
protocol, i.e., RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the protocol, i.e., RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the
coupled accounting model, see Section 5.10. Some existing coupled accounting model, see Section 5.10. Some existing
specifications do not adhere to this rule for historical reasons. specifications do not adhere to this rule for historical reasons.
However, this guidance should be followed to avoid routing problems. However, this guidance SHOULD be followed by new applications to
avoid routing problems.
In general, when a new application has been allocated with a new When a new application has been allocated with a new Application Id
Application Id and it also reuses existing commands with or without and it also reuses existing commands with or without modifications,
modifications, it must use the newly allocated Application Id in the the commands SHOULD use the newly allocated Application Id in the
header and in all relevant Application Id AVPs (Auth-Application-Id header and in all relevant Application Id AVPs (Auth-Application-Id
or Acct-Application-Id) present in the commands message body. or Acct-Application-Id) present in the commands message body.
Additionally, application designs using Vendor-Specific-Application- Additionally, application designers using Vendor-Specific-
Id AVP should not use the Vendor-Id AVP to further dissect or Application-Id AVP SHOULD not use the Vendor-Id AVP to further
differentiate the vendor-specification Application Id. Diameter dissect or differentiate the vendor-specification Application Id.
routing is not based on the Vendor-Id. As such, the Vendor-Id should
not be used as an additional input for routing or delivery of Diameter routing is not based on the Vendor-Id. As such, the Vendor-
messages. The Vendor-Id AVP is an informational AVP only and kept Id SHOULD not be used as an additional input for routing or delivery
of messages. The Vendor-Id AVP is an informational AVP only and kept
for backward compatibility reasons. for backward compatibility reasons.
5.4. Application-Specific Session State Machines 5.4. Application-Specific Session State Machines
Section 8 of [RFC6733] provides session state machines for Section 8 of [RFC6733] provides session state machines for
authentication, authorization and accounting (AAA) services and these authentication, authorization and accounting (AAA) services and these
session state machines are not intended to cover behavior outside of session state machines are not intended to cover behavior outside of
AAA. If a new application cannot clearly be categorized into any of AAA. If a new application cannot clearly be categorized into any of
these AAA services, it is recommended that the application defines these AAA services, it is RECOMMENDED that the application defines
its own session state machine. Support for server-initiated request its own session state machine. Support for server-initiated request
is a clear example where an application-specific session state is a clear example where an application-specific session state
machine would be needed, for example, the Rw interface for ITU-T push machine would be needed, for example, the Rw interface for ITU-T push
model (cf.[Q.3303.3]). model (cf.[Q.3303.3]).
5.5. Session-Id AVP and Session Management 5.5. Session-Id AVP and Session Management
Diameter applications are usually designed with the aim of managing Diameter applications are usually designed with the aim of managing
user sessions (e.g., Diameter network access session (NASREQ) user sessions (e.g., Diameter network access session (NASREQ)
application [RFC4005]) or specific service access session (e.g., application [RFC4005]) or specific service access session (e.g.,
skipping to change at page 12, line 29 skipping to change at page 12, line 46
instead to correlate Diameter messages. Indeed, the User-Name AVP or instead to correlate Diameter messages. Indeed, the User-Name AVP or
any other specific AVP can be present in every Diameter message and any other specific AVP can be present in every Diameter message and
used therefore for message correlation. Some applications might not used therefore for message correlation. Some applications might not
require the notion of Diameter session concept at all. For such require the notion of Diameter session concept at all. For such
applications, the Auth-Session-State AVP is usually set to applications, the Auth-Session-State AVP is usually set to
NO_STATE_MAINTAINED in all Diameter messages and these applications NO_STATE_MAINTAINED in all Diameter messages and these applications
are therefore designed as a set of stand-alone transactions. Even if are therefore designed as a set of stand-alone transactions. Even if
an explicit access session termination is required, application- an explicit access session termination is required, application-
specific commands are defined and used instead of the Session- specific commands are defined and used instead of the Session-
Termination-Request/Answer (STR/STA) or Abort-Session-Request/Answer Termination-Request/Answer (STR/STA) or Abort-Session-Request/Answer
(ASR/ASA) defined in the Diameter base protocol. In such a case, the (ASR/ASA) defined in the Diameter base protocol [RFC6733]. In such a
Session-Id is not significant. case, the Session-Id is not significant.
Based on these considerations, protocol designers should carefully Based on these considerations, protocol designers SHOULD carefully
appraise whether the application currently defined relies on it's own appraise whether the application currently defined relies on its own
session management concept or whether the Session-Id defined in the session management concept or whether the Session-Id defined in the
Diameter base protocol would be used for correlation of messages Diameter base protocol would be used for correlation of messages
related to the same session. If not, the protocol designers could related to the same session. If not, the protocol designers MAY
decide to define application commands without the Session-Id AVP. If decide to define application commands without the Session-Id AVP. If
any session management concept is supported by the application, the any session management concept is supported by the application, the
application documentation must clearly specify how the session is application documentation MUST clearly specify how the session is
handled between client and server (as possibly Diameter agents in the handled between client and server (as possibly Diameter agents in the
path). path).
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.
As described in the section 4.4.2 above, defining an AVP of type As described in the section 4.4.2 above, defining an AVP of type
Enumerated presents some limitations in term of extensibility and Enumerated presents some limitations in term of extensibility and
reusability. Indeed, the finite set of valid values defined at the reusability. Indeed, the finite set of valid values defined at the
definition of the AVP of type Enumerated cannot be modified in definition of the AVP of type Enumerated cannot be modified in
practice without causing backward compatibility issues with existing practice without causing backward compatibility issues with existing
implementations. As a consequence, AVPs of Type Enumerated cannot be implementations. As a consequence, AVPs of Type Enumerated MUST NOT
extended by adding new values to support new capabilities. Diameter be extended by adding new values to support new capabilities.
protocol designers are then strongly advised to carefully consider Diameter protocol designers SHOULD carefully consider before defining
before defining an Enumerated AVP whether the set of values will an Enumerated AVP whether the set of values will remain unchanged or
remain unchanged or new values may be required in a near future. If new values may be required in a near future. If such extension is
such extension is foreseen or cannot be avoided, it is recommended to foreseen or cannot be avoided, it is RECOMMENED to rather define AVPs
rather define AVPs of type Unsigned32 or Unsigned64 in which the data of type Unsigned32 or Unsigned64 in which the data field would
field would contain an address space representing "values" that would contain an address space representing "values" that would have the
have the same use of Enumerated values. same use of Enumerated values.
For instance, an AVP describing possible access networks would be For illustration, an AVP describing possible access networks would be
defined as follow: defined as follow:
Access-Network-Type AVP (XXX) is of type Unsigned32 and contains an Access-Network-Type AVP (XXX) is of type Unsigned32 and contains an
32-bit address space representing types of access networks. This 32-bit address space representing types of access networks. This
application defines the following classes of access networks, all application defines the following classes of access networks, all
identified by the thousands digit in the decimal notation: identified by the thousands digit in the decimal notation:
o 1xxx (Mobile Access Networks) o 1xxx (Mobile Access Networks)
o 2xxx (Fixed Access Network) o 2xxx (Fixed Access Network)
skipping to change at page 14, line 13 skipping to change at page 14, line 43
Diameter endpoints. Diameter endpoints.
In the same line, AVPs of type Enumerated are too often used as a In the same line, AVPs of type Enumerated are too often used as a
simple Boolean flag, indicating for instance a specific permission or 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, with by a new AVP or new Enumerated value of the already defined AVP, with
the backward compatibility issues described above. Instead of using the backward compatibility issues described above. Instead of using
an Enumerated AVP for a Boolean flag, protocol designers are again an Enumerated AVP for a Boolean flag, protocol designers SHOULD use
encouraged to use AVPs of type Unsigned32 or Unsigned64 AVP in which AVPs of type Unsigned32 or Unsigned64 AVP in which the data field
the data field would be defined as bit mask whose bit settings are would be defined as bit mask whose bit settings are described in the
described in the relevant Diameter application specification. Such relevant Diameter application specification. Such AVPs can be reused
AVPs can be reused and extended without major impact on the Diameter and extended without major impact on the Diameter application. The
application. The bit mask should leave room for future additions. bit mask SHOULD leave room for future additions. Examples of AVPs
Examples of AVPs that use bit masks are the Session-Binding AVP that use bit masks are the Session-Binding AVP defined in [RFC6733]
defined in [RFC6733] and the MIP6-Feature-Vector AVP defined in and the 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
message header. However, some applications may need to rely on the message header. However, some applications may need to rely on the
User-Name AVP or any other application-specific AVP present in 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 request to determine the final destination of a request, e.g., to
find the target AAA server hosting the authorization information for find the target AAA server hosting the authorization information for
a given user when multiple AAA servers are addressable in the realm. 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 MUST 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
in the Cx/Dx applications ([TS29.228] and [TS29.229]) of the 3GPP IP in the Cx/Dx applications ([TS29.228] and [TS29.229]) of the 3GPP IP
Multimedia Subsystem, in which the proxy agent (Subscriber Location Multimedia Subsystem, in which the proxy agent (Subscriber Location
Function aka SLF) uses specific application-level identities found in Function aka SLF) uses specific application-level identities found in
the request to determine the final destination of the message. the request to determine the final destination of the message.
Whatever the criteria used to establish the routing path of the Whatever the criteria used to establish the routing path of the
request, the routing of the answer has to follow the reverse path of request, the routing of the answer MUST follow the reverse path of
the request, as described in [RFC6733], with the answer being sent to the request, as described in [RFC6733], with the answer being sent to
the source of the received request, using transaction states and hop- the source of the received request, using transaction states and hop-
by-hop identifier matching. In particular, this ensures that the by-hop identifier matching. In particular, this ensures that the
Diameter Relay or Proxy agents in the request routing path will be Diameter Relay or Proxy agents in the request routing path will be
able to release the transaction state upon receipt of the able to release the transaction state upon receipt of the
corresponding answer, avoiding unnecessary failover. Application corresponding answer, avoiding unnecessary failover. Application
designers are strongly dissuaded from modifying the answer-routing designers SHOULD NOT modify the answer-routing principles described
principles described in [RFC6733] when defining a new application. in [RFC6733] when defining a new application.
5.8. Translation Agents 5.8. Translation Agents
As defined in [RFC6733], a translation agent is a device that As defined in [RFC6733], a translation agent is a device that
provides interworking between Diameter and another protocol (e.g., provides interworking between Diameter and another AAA protocol, such
RADIUS). as RADIUS .
In the case of RADIUS, it was initially thought that defining the In the case of RADIUS, it was initially thought that defining the
translation function would be straightforward by adopting few basic translation function would be straightforward by adopting few basic
principles, e.g., by the use of a shared range of code values for principles, e.g., by the use of a shared range of code values for
RADIUS attributes and Diameter AVPs. Guidelines for implementing a RADIUS attributes and Diameter AVPs. Guidelines for implementing a
RADIUS-Diameter translation agent were put into RFC 4005 ([RFC4005]). RADIUS-Diameter translation agent were put into the Diameter NASREQ
Application ([RFC4005]).
However, it was acknowledged that such translation mechanism was not However, it was acknowledged that such translation mechanism was not
so obvious and deeper protocol analysis was required to ensure so obvious and deeper protocol analysis was required to ensure
efficient interworking between RADIUS and Diameter. Moreover, the efficient interworking between RADIUS and Diameter. Moreover, the
interworking requirements depend on the functionalities provided by interworking requirements depend on the functionalities provided by
the Diameter application under specification, and a case-by-case the Diameter application under specification, and a case-by-case
analysis will be required. analysis is required. As a consequence, all the material related to
RADIUS-to-Diameter translation is removed from the new version of the
Diameter NASREQ application specification [RFC4005bis], (see
[RFC7155]) which deprecates the RFC4005 ([RFC4005]).
Therefore, protocol designers cannot assume the availability of a Therefore, protocol designers SHOULD NOT assume the availability of a
"standard" Diameter-to-RADIUS gateways agent when planning to "standard" Diameter-to-RADIUS gateways agent when planning to
interoperate with the RADIUS infrastructure. They should specify the interoperate with the RADIUS infrastructure. They SHOULD specify the
required translation mechanism along with the Diameter application, required translation mechanism along with the Diameter application,
if needed. This recommendation applies for any kind of translation. if needed. This recommendation applies for any kind of translation.
5.9. End-to-End Application Capabilities Exchange 5.9. End-to-End Application Capabilities Exchange
New Diameter applications can rely on optional AVPs to exchange New Diameter applications can rely on optional AVPs to exchange
application-specific capabilities and features. These AVPs can be application-specific capabilities and features. These AVPs can be
exchanged on an end-to-end basis at the application layer. Examples exchanged on an end-to-end basis at the application layer. Examples
of this can be found with the MIP6-Feature-Vector AVP in [RFC5447] of this can be found with the MIP6-Feature-Vector AVP in [RFC5447]
and the QoS-Capability AVP in [RFC5777]. and the QoS-Capability AVP in [RFC5777].
skipping to change at page 16, line 12 skipping to change at page 16, line 45
for it. Applications that do not understand these AVPs can discard for it. Applications that do not understand these AVPs can discard
them upon receipt. Receivers of these AVPs can discover the them upon receipt. Receivers of these AVPs can discover the
additional functionality supported by the end-point originating the additional functionality supported by the end-point originating the
request and behave accordingly when processing the request. Senders request and behave accordingly when processing the request. Senders
of these AVPs can safely assume the receiving end-point does not of these AVPs can safely assume the receiving end-point does not
support any functionality carried by the AVP if it is not present in support any functionality carried by the AVP if it is not present in
corresponding response. This is useful in cases where deployment corresponding response. This is useful in cases where deployment
choices are offered, and the generic design can be made available for choices are offered, and the generic design can be made available for
a number of applications. a number of applications.
When used in a new application, protocol designers should clearly When used in a new application, protocol designers SHOULD clearly
specify this end-to-end capabilities exchange and the corresponding specify this end-to-end capabilities exchange and the corresponding
behaviour of the Diameter nodes supporting the application. behaviour of the Diameter nodes supporting the application.
It is also important to note that this end-to-end capabilities It is also important to note that this end-to-end capabilities
exchange relies on the use of optional AVPs is not meant as a generic exchange relying on the use of optional AVPs is not meant as a
mechanism to support extensibility of Diameter applications with generic mechanism to support extensibility of Diameter applications
arbitrary functionality. When the added features drastically change with arbitrary functionality. When the added features drastically
the Diameter application or when Diameter agents have to be upgraded change the Diameter application or when Diameter agents must be
to support the new features, a new application should be defined. upgraded to support the new features, a new application SHOULD be
defined.
5.10. Diameter Accounting Support 5.10. Diameter Accounting Support
Accounting can be treated as an auxiliary application that is used in Accounting can be treated as an auxiliary application that is used in
support of other applications. In most cases, accounting support is support of other applications. In most cases, accounting support is
required when defining new applications. This document provides two required when defining new applications. This document provides two
possible models for using accounting: possible models for using accounting:
Split Accounting Model: Split Accounting Model:
skipping to change at page 17, line 4 skipping to change at page 17, line 37
* The application itself does not define its own accounting * The application itself does not define its own accounting
commands. commands.
* The overall system architecture permits the use of centralized * The overall system architecture permits the use of centralized
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 MUST have a method to match accounting messages
messages with applications and/or services being accounted for. with applications and/or services being accounted for. This may
This may mean defining new AVPs, checking the presence, absence or mean defining new AVPs, checking the presence, absence or contents
contents of existing AVPs, or checking the contents of the of existing AVPs, or checking the contents of the accounting
accounting record itself. One of these means could be to insert record itself. One of these means could be to insert into the
into the request sent to the accounting server an Auth- request sent to the accounting server an Auth-Application-Id AVP
Application-Id AVP containing the identifier of the application containing the identifier of the application for which the
for which the accounting request is sent. But in general, there accounting request is sent. But in general, there is no clean and
is no clean and generic scheme for sorting these messages. generic scheme for sorting these messages. Therefore, the use of
Therefore, the use of this model is recommended only when all this model is NOT RECOMMENDED when all received accounting
received accounting messages can be clearly identified and sorted. messages cannot be clearly identified and sorted. For most cases,
For most cases, the use of Coupled Accounting Model is the use of Coupled Accounting Model is RECOMMENDED.
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
accounting records carried by the accounting messages to the accounting records carried by the accounting messages to the
proper accounting server. The application server is also proper accounting server. The application server is also
responsible for formulating a proper response (ACA). A coupled responsible for formulating a proper response (ACA). A coupled
accounting model is a good design choice when: accounting model is a good design choice when:
* The system architecture or deployment does not provide an * The system architecture or deployment does not provide an
accounting server that supports Diameter. Consequently, the accounting server that supports Diameter. Consequently, the
application server has to be provisioned to use a different application server MUST be provisioned to use a different
protocol to access the accounting server, e.g., via LDAP, SOAP protocol to access the accounting server, e.g., via LDAP, SOAP
etc. This case includes the support of older accounting etc. This case includes the support of older accounting
systems that are not Diameter aware. systems that are not Diameter aware.
* The system architecture or deployment requires that the * The system architecture or deployment requires that the
accounting service for the specific application should be accounting service for the specific application should be
handled by the application itself. handled by the application itself.
In all cases above, there will generally be no direct Diameter In all cases above, there will generally be no direct Diameter
access to the accounting server. access to the accounting server.
These models provide a basis for using accounting messages. These models provide a basis for using accounting messages.
Application designers may obviously deviate from these models Application designers may obviously deviate from these models
provided that the factors being addressed here have also been taken provided that the factors being addressed here have also been taken
into account. Although it is not recommended, an application may into account. An application MAY define a new set of commands to
define a new set of commands to carry application-specific accounting carry application-specific accounting records but it is NOT
records. RECOMMENDED to do so.
5.11. Diameter Security Mechanisms 5.11. Diameter Security Mechanisms
As specified in [RFC6733], the Diameter message exchange should be As specified in [RFC6733], the Diameter message exchange SHOULD be
secured between neighboring Diameter peers using TLS/TCP or DTLS/ secured between neighboring Diameter peers using TLS/TCP or DTLS/
SCTP. However, IPsec can also be deployed to secure communication SCTP. However, IPsec MAY also be deployed to secure communication
between Diameter peers. When IPsec is used instead of TLS or DTLS, between Diameter peers. When IPsec is used instead of TLS or DTLS,
the following recommendations apply. the following recommendations apply.
IPsec ESP [RFC4301] in transport mode with non-null encryption and IPsec ESP [RFC4301] in transport mode with non-null encryption and
authentication algorithms is used to provide per-packet authentication algorithms MUST be used to provide per-packet
authentication, integrity protection and confidentiality, and support authentication, integrity protection and confidentiality, and support
the replay protection mechanisms of IPsec. IKEv2 [RFC5996] is the replay protection mechanisms of IPsec. IKEv2 [RFC5996] SHOULD be
recommended for performing mutual authentication and for establishing used for performing mutual authentication and for establishing and
and maintaining security associations (SAs). maintaining security associations (SAs).
IKEv1 [RFC2409] was used with RFC 3588 [RFC3588] and for easier IKEv1 [RFC2409] was used with RFC 3588 [RFC3588] and for easier
migration from IKEv1 based implementations both RSA digital migration from IKEv1 based implementations both RSA digital
signatures and pre-shared keys should be supported in IKEv2. signatures and pre-shared keys SHOULD be supported in IKEv2.
However, if IKEv1 is used, implementers should follow the guidelines However, if IKEv1 is used, implementers SHOULD follow the guidelines
given in Section 13.1 of RFC 3588 [RFC3588]. given in Section 13.1 of RFC 3588 [RFC3588].
6. Defining Generic Diameter Extensions 6. Defining Generic Diameter Extensions
Generic Diameter extensions are AVPs, commands or applications that Generic Diameter extensions are AVPs, commands or applications that
are designed to support other Diameter applications. They are are designed to support other Diameter applications. They are
auxiliary applications meant to improve or enhance the Diameter auxiliary applications meant to improve or enhance the Diameter
protocol itself or Diameter applications/functionality. Some protocol itself or Diameter applications/functionality. Some
examples include the extensions to support auditing and redundancy examples include the extensions to support realm-based redirection of
(see [I-D.calhoun-diameter-res-mgmt]), improvements in duplicate Diameter requests (see [RFC7075]), convey a specific set of priority
detection scheme (see [I-D.asveren-dime-dupcons]), and the support parameters influencing the distribution of resources (see [RFC6735]),
for QoS AVPs (see [RFC5777]). and the support for QoS AVPs (see [RFC5777]).
Since generic extensions may cover many aspects of Diameter and Since generic extensions may cover many aspects of Diameter and
Diameter applications, it is not possible to enumerate all scenarios. Diameter applications, it is not possible to enumerate all scenarios.
However, some of the most common considerations are as follows: However, some of the most common considerations are as follows:
Backward Compatibility: Backward Compatibility:
With the design of generic extensions an protocol designer has to When defining generic extensions designed to be supported by
consider with potential concerns about how existing applications existing Diameter applications, protocol designers MUST consider
deal with the new extension they do not understand. Designers the potential impacts of the introduction of the new extension on
also have to make sure that new extensions do not break expected the behavior of node that would not be yet upgraded to support/
message delivery layer behavior. understand this new extension. Designers MUST also ensure that
new extensions do not break expected message delivery layer
behavior.
Forward Compatibility: Forward Compatibility:
Protocol designers need to make sure that their design will not Protocol designers MUST ensure that their design will not
introduce undue restrictions for future applications. introduce undue restrictions for future applications.
Trade-off in Signaling: Trade-off in Signaling:
Designers may have to choose between the use of optional AVPs Designers may have to choose between the use of optional AVPs
piggybacked onto existing commands versus defining new commands piggybacked onto existing commands versus defining new commands
and applications. Optional AVPs are simpler to implement and may and applications. Optional AVPs are simpler to implement and may
not need changes to existing applications. However, this ties the not need changes to existing applications. However, this ties the
sending of extension data to the application's transmission of a sending of extension data to the application's transmission of a
message. This has consequences if the application and the message. This has consequences if the application and the
extensions have different timing requirements. The use of extensions have different timing requirements. The use of
commands and applications solves this issue, but the trade-off is commands and applications solves this issue, but the trade-off is
the additional complexity of defining and deploying a new the additional complexity of defining and deploying a new
application. It is left up to the designer to find a good balance application. It is left up to the designer to find a good balance
among these trade-offs based on the requirements of the extension. among these trade-offs based on the requirements of the extension.
In practice, generic extensions often use optional AVPs because they In practice, generic extensions often use optional AVPs because they
are simple and non-intrusive to the application that would carry are simple and non-intrusive to the application that would carry
them. Peers that do not support the generic extensions need not them. Peers that do not support the generic extensions need not
understand nor recognize these optional AVPs. However, it is understand nor recognize these optional AVPs. However, it is
recommended that the authors of the extension specify the context or RECOMMENDED that the authors of the extension specify the context or
usage of the optional AVPs. As an example, in the case that the AVP usage of the optional AVPs. As an example, in the case that the AVP
can be used only by a specific set of applications then the can be used only by a specific set of applications then the
specification must enumerate these applications and the scenarios specification MUST enumerate these applications and the scenarios
when the optional AVPs will be used. In the case where the optional when the optional AVPs will be used. In the case where the optional
AVPs can be carried by any application, it is should be sufficient to AVPs can be carried by any application, it SHOULD be sufficient to
specify such a use case and perhaps provide specific examples of specify such a use case and perhaps provide specific examples of
applications using them. applications using them.
In most cases, these optional AVPs piggybacked by applications would In most cases, these optional AVPs piggybacked by applications would
be defined as a Grouped AVP and it would encapsulate all the be defined as a Grouped AVP and it would encapsulate all the
functionality of the generic extension. In practice, it is not functionality of the generic extension. In practice, it is not
uncommon that the Grouped AVP will encapsulate an existing AVP that uncommon that the Grouped AVP will encapsulate an existing AVP that
has previously been defined as mandatory ('M'-bit set) e.g., 3GPP IMS has previously been defined as mandatory ('M'-bit set) e.g., 3GPP IMS
Cx/Dx interfaces ([TS29.228] and [TS29.229]). Cx/Dx interfaces ([TS29.228] and [TS29.229]).
skipping to change at page 20, line 4 skipping to change at page 20, line 40
As summarized in the Section 3 of this document and further described As summarized in the Section 3 of this document and further described
in the Section 1.3 of [RFC6733], there are four main ways to extend in the Section 1.3 of [RFC6733], there are four main ways to extend
Diameter. The process for defining new functionality slightly varies Diameter. The process for defining new functionality slightly varies
based on the different extensions. This section provides protocol based on the different extensions. This section provides protocol
designers with some guidance regarding the definition of values for designers with some guidance regarding the definition of values for
possible Diameter extensions and the necessary interaction with IANA possible Diameter extensions and the necessary interaction with IANA
to register the new functionality. to register the new functionality.
a. Defining new AVP values a. Defining new AVP values
The specifications defining AVPs and AVP values provide guidance
for defining new values and the corresponding policy for adding The specifications defining AVPs and AVP values MUST provide
these values. For example, the RFC 5777 [RFC5777] defines the guidance for defining new values and the corresponding policy for
Treatment-Action AVP which contains a list of valid values adding these values. For example, the RFC 5777 [RFC5777] defines
the Treatment-Action AVP which contains a list of valid values
corresponding to pre-defined actions (drop, shape, mark, permit). corresponding to pre-defined actions (drop, shape, mark, permit).
This set of values can be extended following the Specification This set of values can be extended following the Specification
Required policy defined in [RFC5226]. As a second example, the Required policy defined in [RFC5226]. As a second example, the
Diameter base specification [RFC6733] defines the Result-Code AVP Diameter base specification [RFC6733] defines the Result-Code AVP
that contains a 32-bit address space used to identity possible that contains a 32-bit address space used to identity possible
errors. According to the Section 11.3.2 of [RFC6733], new values errors. According to the Section 11.3.2 of [RFC6733], new values
can be assigned by IANA via an IETF Review process [RFC5226]. can be assigned by IANA via an IETF Review process [RFC5226].
b. Creating new AVPs b. Creating new AVPs
skipping to change at page 20, line 36 skipping to change at page 21, line 25
with a private enterprise number, which can be used within the with a private enterprise number, which can be used within the
Vendor-Id field of the vendor-specific AVP. This enterprise Vendor-Id field of the vendor-specific AVP. This enterprise
number delimits a private namespace in which the vendor is number delimits a private namespace in which the vendor is
responsible for vendor-specific AVP code value assignment. The responsible for vendor-specific AVP code value assignment. The
absence of a Vendor-Id or a Vendor-Id value of zero (0) in the AVP absence of a Vendor-Id or a Vendor-Id value of zero (0) in the AVP
header identifies standard AVPs from the IETF AVP Codes namespace header identifies standard AVPs from the IETF AVP Codes namespace
managed by IANA. The allocation of code values from the IANA- managed by IANA. The allocation of code values from the IANA-
managed namespace is conditioned by an Expert Review of the managed namespace is conditioned by an Expert Review of the
specification defining the AVPs or an IETF review if a block of specification defining the AVPs or an IETF review if a block of
AVPs needs to be assigned. Moreover, the remaining bits of the AVPs needs to be assigned. Moreover, the remaining bits of the
AVP Flags field of the AVP header can be also assigned via AVP Flags field of the AVP header are also assigned via Standard
Standard Action if the creation of new AVP Flags is desired. Action if the creation of new AVP Flags is desired.
c. Creating new commands c. Creating new commands
Unlike the AVP Code namespace, the Command Code namespace is flat Unlike the AVP Code namespace, the Command Code namespace is flat
but the range of values is subdivided into three chunks with but the range of values is subdivided into three chunks with
distinct IANA registration policies: distinct IANA registration policies:
* A range of standard Command Code values that can be allocated * A range of standard Command Code values that are allocated via
via IETF review; IETF review;
* A range of vendor-specific Command Code values that can be * A range of vendor-specific Command Code values that are
allocated on a First-Come/First-Served basis; allocated on a First-Come/First-Served basis;
* A range of values reserved only for experimental and testing * A range of values reserved only for experimental and testing
purposes. purposes.
As for AVP Flags, the remaining bits of the Command Flags field of As for AVP Flags, the remaining bits of the Command Flags field of
the Diameter header can also be assigned via a Standards Action to the Diameter header are also assigned via a Standards Action to
create new Command Flags if required. create new Command Flags if required.
d. Creating new applications d. Creating new applications
Similarly to the Command Code namespace, the Application-Id Similarly to the Command Code namespace, the Application-Id
namespace is flat but divided into two distinct ranges: namespace is flat but divided into two distinct ranges:
* A range of values reserved for standard Application-Ids * A range of values reserved for standard Application-Ids
allocated after Expert Review of the specification defining the allocated after Expert Review of the specification defining the
standard application; standard application;
skipping to change at page 21, line 33 skipping to change at page 22, line 21
The IANA AAA parameters page can be found at http://www.iana.org/ The IANA AAA parameters page can be found at http://www.iana.org/
assignments/aaa-parameters/aaa-parameters.xml and the enterprise assignments/aaa-parameters/aaa-parameters.xml and the enterprise
number IANA page is available at http://www.iana.org/assignments/ number IANA page is available at http://www.iana.org/assignments/
enterprise-numbers. More details on the policies followed by IANA enterprise-numbers. More details on the policies followed by IANA
for namespace management (e.g. First-Come/First-Served, Expert for namespace management (e.g. First-Come/First-Served, Expert
Review, IETF Review, etc.) can be found in [RFC5226]. Review, IETF Review, etc.) can be found in [RFC5226].
NOTE: NOTE:
When the same functionality/extension is used by more than one When the same functionality/extension is used by more than one
vendor, it is recommended to define a standard extension. vendor, it is RECOMMENDED to define a standard extension.
Moreover, the registration of vendor-specific extension is Moreover, a vendor-specific extension SHOULD be registered to
encouraged to avoid interoperability issues in the same network. avoid interoperability issues in the same network. With this aim,
With this aim, the registration policy of vendor-specific the registration policy of vendor-specific extension has been
extension has been simplified with the publication of [RFC6733] simplified with the publication of [RFC6733] and the namespace
and the namespace reserved for vendor-specific extensions is large reserved for vendor-specific extensions is large enough to avoid
enough to avoid exhaustion. exhaustion.
8. IANA Considerations 8. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
9. Security Considerations 9. Security Considerations
This document provides guidelines and considerations for extending This document provides guidelines and considerations for extending
Diameter and Diameter applications. Although such an extension may Diameter and Diameter applications. Although such an extension may
related to a security functionality, the document does not explicitly be related to a security functionality, the document does not
give guidance on enhancing Diameter with respect to security. explicitly give guidance on enhancing Diameter with respect to
security.
10. Contributors 10. Contributors
The content of this document was influenced by a design team created The content of this document was influenced by a design team created
to revisit the Diameter extensibility rules. The team consisting of to revisit the Diameter extensibility rules. The team was formed in
the members listed below was formed in February 2008 and finished its February 2008 and finished its work in June 2008. Except the
work in June 2008. authors, the design team members were:
o Avi Lior o Avi Lior
o Glen Zorn o Glen Zorn
o Jari Arkko o Jari Arkko
o Jouni Korhonen
o Lionel Morand
o Mark Jones o Mark Jones
o Victor Fajardo
o Tolga Asveren o Tolga Asveren
o Jouni Korhonen
o Glenn McGregor o Glenn McGregor
o Hannes Tschofenig
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, Ben document. The authors would also like to thank Jean Mahoney, Ben
Campbell and Sebastien Decugis for their invaluable detailed reviews Campbell, Sebastien Decugis and Benoit Claise for their invaluable
and comments on this document. detailed reviews and comments on this document.
12. Informative References 12. References
[I-D.asveren-dime-dupcons] 12.1. Normative References
Asveren, T., "Diameter Duplicate Detection Cons.", draft-
asveren-dime-dupcons-00 (work in progress), August 2006.
[I-D.calhoun-diameter-res-mgmt] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Calhoun, P., "Diameter Resource Management Extensions", Requirement Levels", BCP 14, RFC 2119, March 1997.
draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
March 2001. [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
12.2. Informative References
[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.
[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.
skipping to change at page 24, line 12 skipping to change at page 24, line 42
Service (QoS) Attributes for Diameter", RFC 5777, February Service (QoS) Attributes for Diameter", RFC 5777, February
2010. 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"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.
[RFC6735] Carlberg, K. and T. Taylor, "Diameter Priority Attribute-
Value Pairs", RFC 6735, October 2012.
[RFC7075] Tsou, T., Hao, R., and T. Taylor, "Realm-Based Redirection
In Diameter", RFC 7075, November 2013.
[RFC7155] Zorn, G., "Diameter Network Access Server Application",
RFC 7155, April 2014.
[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;
skipping to change at page 25, line 4 skipping to change at page 25, line 43
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
Phone: +33145296257 Phone: +33145296257
Email: lionel.morand@orange.com Email: lionel.morand@orange.com
Victor Fajardo Victor Fajardo
Independent
Email: vf0213@gmail.com Email: vf0213@gmail.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
 End of changes. 108 change blocks. 
245 lines changed or deleted 280 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/