Diameter Maintanence and V. Fajardo, Ed.
Extensions (DIME) Toshiba America Research Inc.
Internet-Draft T. Asveren
Intended status: Informational Sonus Network
Expires: May 16, 2008 H. Tschofenig
Nokia Siemens Networks
G. McGregor
Alcatel-Lucent
November 13, 2007
Diameter Applications Design Guidelines
draft-ietf-dime-app-design-guide-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 16, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The Diameter Base protocol provides updated rules on how to extend
Diameter by modifying and/or deriving from existing applications or
creating entirely new applications. This is a companion document to
Fajardo, et al. Expires May 16, 2008 [Page 1]
Internet-Draft Diameter Applications Design Guidelines November 2007
the Diameter Base protocol which further explains and/or clarify
these rules. It is meant as a guidelines document and therefore it
does not add, remove or change existing rules.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Brief Overview of the Diameter Application Model . . . . . . . 4
4. Rules on Extending Diameter . . . . . . . . . . . . . . . . . 4
4.1. Reusing Existing Applications . . . . . . . . . . . . . . 5
4.1.1. Adding a new command . . . . . . . . . . . . . . . . . 6
4.1.2. Deleting a command . . . . . . . . . . . . . . . . . . 7
4.2. Reusing Existing Commands . . . . . . . . . . . . . . . . 7
4.2.1. Adding AVPs to a command . . . . . . . . . . . . . . . 7
4.2.2. Deleting AVPs from a command . . . . . . . . . . . . . 9
4.3. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . 10
5. Rules for new Applications . . . . . . . . . . . . . . . . . . 10
5.1. Rules in Allocating new Command Codes . . . . . . . . . . 11
5.2. Justifying the Allocation of Application-Id . . . . . . . 11
5.3. Use of Application-Id in a Message . . . . . . . . . . . . 11
5.4. Application Specific Session Statemachine . . . . . . . . 12
5.5. End-to-End Applications Capabilities Exchange . . . . . . 12
6. Other Design Considerations . . . . . . . . . . . . . . . . . 13
6.1. Diameter Accounting Support . . . . . . . . . . . . . . . 13
6.2. Generic Diameter Extensions . . . . . . . . . . . . . . . 14
6.3. Updating an existing Application . . . . . . . . . . . . . 16
6.4. System Architecture and Deployment . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Fajardo, et al. Expires May 16, 2008 [Page 2]
Internet-Draft Diameter Applications Design Guidelines November 2007
1. Introduction
The Diameter Base protocol document defines rules on how one would
extend Diameter (see Section 1.2 of [1]). In the context of this
document, extending Diameter means one of the following:
1. A new functionality is being added to an existing Diameter
application without defining a new application.
2. A new Diameter application is being defined by reusing an
existing application.
3. A completely new application is being defined that has no
dependencies to any existing applications.
4. A new generic functionality is being defined that can be reused
across different applications.
All of these choices are design decisions that can done by any
combination of reusing existing or defining new commands, AVPs or AVP
values. The objective of this document is the following:
o Clarify updated Diameter extensibility rules in the Diameter Base
Protocol.
o Clarify usage of certain Diameter functionality which are not
explicitly described in the Diameter Base specification.
o Discuss design choices and provide guidelines when defining
applications.
o Present tradeoffs of design choices.
These guidelines are necessary since the existing rules do not cover
the ambiguity that exists when some of the design choices overlap. A
typical example would be deciding between item one(1) and two(2)
above when an application designer requires a new application
functionality which has many things in common with an existing
application. Certain ambiguous aspects of such cases were not
foreseen in the existing extensibility rules; e.g., use of optional
AVPs to differentiate new functionality in the old application versus
defining a new application and importing the existing set of
commands. In this example, it was only based on collective
experiences of application designers that the decision to create a
new application (item two(2)) is now seen as the cleanest approach.
Along with the gained experience however, additional bad practices
have developed as well. Continuing the example above, the decision
Fajardo, et al. Expires May 16, 2008 [Page 3]
Internet-Draft Diameter Applications Design Guidelines November 2007
to create a new application would result in the allocation of a new
application ID which often times is foreseen as cumbersome by
application designers because of the lengthy process. Designers
therefore tend to circumvent the better approach leading to many
compromises in the design that eventually lead to interoperability
issues (See Section 5.1).
The basic issue is that the rules defined in the Diameter Base
protocol are not comprehensive enough that one can easily derive good
design decisions from them. The effect of this can be seen in
various attempts to extend Diameter applications where designers have
no clear answer on whether to even define a new application or not.
At worst, some existing Diameter applications that had been purposely
derived from another existing application resulted in some in-
appropriate design decision where both the existing application and
the derived applications are no longer interoperable under certain
conditions. Note that it is not always possible to offer a complete
and concise answer to certain design choices, but at the least, this
document can be used as a guide to Diameter extensibility.
2. Terminology
This document reuses the terminology used in [1].
3. Brief Overview of the Diameter Application Model
As it is currently interpreted and practiced, the Diameter Base
protocol is a two-layer protocol. The lower layer is mainly
responsible for managing connections between neighboring peers and
for message routing. The upper layer is where the Diameter
applications reside. This model is in line with a Diameter node
having an application layer and a peer-to-peer delivery layer. The
Diameter Base protocol document completely defines the architecture
and behavior of the message delivery layer and then provides the
framework for designing Diameter applications on the application
layer. This framework includes definitions of application sessions
and accounting support (see Section 8 and 9 of [1]). The remainder
of this document also treats a Diameter node as a single instance of
a Diameter message delivery layer and one or more Diameter
applications using it.
4. Rules on Extending Diameter
Extending Diameter can mean the reuse of commands, AVPs and AVP
values in any combination for the purpose of inheriting the features
Fajardo, et al. Expires May 16, 2008 [Page 4]
Internet-Draft Diameter Applications Design Guidelines November 2007
of an existing Diameter applications. This section discusses the
rules on how such reuse can be done.
When reusing existing applications, the requirements of the new
applications are typically not completely unique and there are
existing applications that can be reused to solve some or all of the
new application requirements. Therefore, there is a greater
likelihood of ambiguity on how much of the existing application can
be reused and what would be the implications for both the new and
existing application. To broadly categorize, the rules for reusing
existing applications can be either:
1. Minimal - which typically means adding optional AVPs to existing
commands.
2. Invasive - where addition or deletion of commands and/or AVPs,
and/or AVP values (in the case where the AVP is of type
Enumerated).
Because it can fundamentally change the application, the latter
approach has strict repercussions. Specifically, it would result in
the definition of a new application and therefore allocation of a new
application ID is required. Discussion about the specific Diameter
Base protocol rules associated with this approach are covered
subsequent sections.
The former approach, although simple, has pitfalls. The problems
arise when there is a tendency by applications designers to keep
adding optional AVPs to existing command so they can circumvent the
rules associated with the latter approach. Specifically, some
designers want to circumvent the standardization process associated
with these rules and not necessarily the rules themselves. The
pitfalls associated with this approach are described further in
Section 4.2.1. Additionally, if designers choose this approach, all
of the functionality of the existing application will be inherited,
even if the new usage has no intent of using some of the existing
features.
4.1. Reusing Existing Applications
This section discusses the reuse of existing applications by adding
and/or deleting commands from the application. This scenario is
categorize as "Invasive" in Section 4 and would always result in the
creation of a new application when the rules are applied.
Fajardo, et al. Expires May 16, 2008 [Page 5]
Internet-Draft Diameter Applications Design Guidelines November 2007
4.1.1. Adding a new command
The rules are strict in this case. Adding a command to an
application is not allowed and doing so will force a definition of a
new application. However, if this is the intent, then the new
application can be created by defining a new command for an existing
application or importing an existing command from another application
so as to inherit some or all of the functionality of that
application. In the former case, the decision is straightforward
since this is typically a result of adding new functionality that
does not yet exist. See Section 5.1 for rules on how to allocate new
command codes for new applications. The latter case would result in
a new application but it has a more subtle issue such as deciding
whether importing of commands and functionality is really better than
simply using the existing application as it is in conjunction with
any new application.
A typical example would be the Diameter MIPv6 split scenario (see
[2]) in which several application models would have been possible
during the design phase; one model would reuse existing Diameter EAP
application combined with a new Diameter MIPv6 application to form a
complete authentication and authorization scheme and another would be
to reuse Diameter EAP like commands within the new Diameter MIPv6
application to accomplish the same result. In this case, the latter
model was chosen which would permit the reuse of commands and/or AVPs
from one application to another. Other applications such as Diameter
QoS (see [3]) would likely face similar decisions.
In general, it is difficult to come to a hard and fast guideline, and
so a case by case study of each application requirement should be
applied. Before adding or importing a command, application designers
should consider the following:
o Can the new functionality be fulfilled by creating a new
application independent from the existing applications? In this
case, a deployment architecture could be designed such that both
old and new application can work independent of, but cooperating
with each other.
o Can the existing application be reused as is without fundamental
changes; e.g., a non-mandatory optional AVP is sufficient to
indicate support for new optional functionality, if any. There
are pitfalls to this approach as well. See Section 4.2.1
o Care should be taken to avoid a liberal method of importing many
commands that results in a monolithic and hard to manage
application which supports many different functionalities.
Fajardo, et al. Expires May 16, 2008 [Page 6]
Internet-Draft Diameter Applications Design Guidelines November 2007
o Will the new feature or functionality refer only to semantic or
statemachine changes in the application requiring extra message
round-trips? In such cases, definition of new commands may not be
necessary and use of existing commands maybe sufficient.
o Reuse of existing applications would result in a distributed
environment which may not be conducive to certain requirements of
the applications; i.e. security and or deployment difficulties -
because of Diameter routing, messages for different applications
providing service to the same user may end up in different servers
would then need to be co-related. This could mean extra signaling
between application servers. A typical example would be the
initial proposal for Diameter MIPv6 split scenario (see [2]) where
authorization and authentication is separated.
Note that accounting commands normally require special treatment and
would not necessarily fall into this category. See Section 6.1.
4.1.2. Deleting a command
Although this is not typical, deleting an command from an existing
application is fundamentally changing the application. In general,
the implications of this approach are the same as Section 4.1.1
regardless of whether new commands will also be added to the
resulting application. In general, it is unusual to delete an
existing command from an existing application for the sake of
deleting it or the functionality it represents. This design decision
would normally be an indication of a flawed design. An exception
might be if the intent of the deletion is to create a newer version
of the same application which is somehow simpler than the previous
version. In that case, the considerations in Section 6.3 should
apply instead.
4.2. Reusing Existing Commands
This section deals with a little more granularity than Section 4.1.
Specifically, it discusses rules in adding and/or deleting AVPs from
an existing command of an existing application. Unlike Section 4.1,
the cases in this section may not necessarily result in the creation
of new application(s). In some cases, there are a lot of ambiguity.
So design considerations have been outlined to ease the decision
making process.
4.2.1. Adding AVPs to a command
Based on the rules in [1], AVPs that are added to an existing command
can be categorized into:
Fajardo, et al. Expires May 16, 2008 [Page 7]
Internet-Draft Diameter Applications Design Guidelines November 2007
o Mandatory to understand AVPs. As defined in [1], these are AVPs
which has their M-bit flag set which means Diameter nodes that
receives these AVPs have to understand not only their values but
their semantics and usage as well. This is regardless of whether
these AVPs are required or optional to appear in the command; as
specified by the commands ABNF.
o Non-mandatory AVPs that are also optional in the commands ABNF.
The rules are strict in the case where the AVPs to be added are
mandatory. A mandatory AVP cannot be added to or deleted from an
existing command. [1] states that doing so would require the
definition of a new application. This falls into the "Invasive"
category described in Section 4. Despite the clarity of the rule,
ambiguity still arises when trying to decide whether a new AVP being
added should be mandatory to begin with. There are several questions
that application designers should contemplate when trying to decide:
o Do the AVPs change the state machine of the application ?
o Would the presence of the AVPs cause additional message round-
trips; effectively changing the state machine of the application ?
o Will the AVP be used to fulfill new required functionality ?
o Would the AVP be used to differentiate between old and new
versions of the same application ?
o Will it have duality in meaning; i.e., be used to carry
application related information as well as be used to indicate
that the message is for a new application ?
If one or more of the above conditions are true, the AVP is
considered mandatory. These questions are not comprehensive in any
way, but in all cases the semantics of the application must change to
justify the use of mandatory AVPs.
The rules are less restrictive when adding non-mandatory, optional
AVPs. This falls into the "Minimal" category described in Section 4.
However, care should also be taken when opting for optional AVPs
instead of mandatory AVPs simply to avoid the process of creating a
new applications. Optional AVPs that answers any of the questions
above also have consequences. Some of the issues associated with
using optional AVPs are:
o Use of optional AVPs with intersecting meaning; one AVP has
partially the same usage and/or meaning as another AVP. The
presence of both can lead to confusion.
Fajardo, et al. Expires May 16, 2008 [Page 8]
Internet-Draft Diameter Applications Design Guidelines November 2007
o An optional AVPs with dual purpose; i.e.; to carry applications
data as well as to indicate support for one or more features.
This has a tendency to introduce interpretation issues.
o Use of optional AVPs with a minimum occurrence of one(1) in the
command ABNF. This is generally contradictory. Application
designers should not use this scheme to circumvent definition of
mandatory AVPs.
All of these practices generally result in interoperability problems
so they should be avoided as much as possible.
4.2.2. Deleting AVPs from a command
Although this scenario is not as common, the deletion of AVPs from a
command ABNF is significant when trying to extend an existing
application. Deletion can again be categorized between mandatory and
non-mandatory optional AVPs described in Section 4.2.1.
In the unlikely event that an application designer would require that
mandatory AVPs must be deleted then it constitutes a fundamental
change to an existing application. Though not specified in [1],
deletion of mandatory AVP would require the definition of a new
application since it dictates changes in the behavior and semantics
of an application.
Instead of deleting commands, a better alternative would be to define
a new command that would represent the new behavior. Reusing the
same command code for different use cases can lead to more confusion,
since the command will have different semantics depending on usage.
This is especially true to base protocol commands (session related
commands, ASR/ASA, STR/STA, RAR/RAA defined in [1]) where they are
being used by many different applications.
The deletion of an optional AVP may not necessarily require the
allocation of a new application. Deletion of non-mandatory optional
AVPs with a zero(0) minimum occurrence in the commands ABNF would not
require a new application. The case where an optional AVP has a
minimum occurrence of at least one(1) is unusual and not allowed in
[1]. However, there may be existing applications that do not follow
the new restrictions in [1]. These applications may have defined
optional AVPs with a minimum occurrence of at least one(1) in their
command ABNFs. In this case, the deletion of the AVP would
effectively change the behavior of the application. It would be
similar to the deletion of mandatory AVPs. Such cases are highly
dubious to begin with since those AVPs already exhibits properties of
mandatory AVPs. Extra consideration should be given as to why it was
not defined as mandatory in the first place and that decision may
Fajardo, et al. Expires May 16, 2008 [Page 9]
Internet-Draft Diameter Applications Design Guidelines November 2007
have to be corrected as well.
In other cases, it is recommended that application designers reuse
the command ABNF without modification and simply ignore (but not
delete) any optional AVP that will not be used. This is to maintain
compatibility with existing applications that will not know about the
new functionality as well as maintain the integrity of existing
dictionaries.
4.3. Reusing Existing AVPs
This section deals with even more granularity than Section 4.1 and
Section 4.2. Specifically, it discusses rules in adding, deleting or
modifying the specified values of an AVP. The rules state that
modifying the value of an AVP is allowed only if it does not change
the semantics of the AVP and the application using it. Otherwise,
the change can be consider "Invasive" as described in Section 4 and
require definition of a new application. Note that designers should
consider Section 5.2 when contemplating on these types of changes.
Typically, the data types of the AVPs in question are scalar in
nature and each ordinal value represent a specific semantic behavior
of the application. An example is the CC-Request-Type AVP of [4].
Adding, deleting or modifying known values of this AVP can modify the
behavior of the application itself, and additionally, the mandatory
and optional AVPs rules are inherited from Section 4.2. So this
affects the decision for defining new applications as well.
5. Rules for new Applications
The general theme of Diameter extensibility is to reuse commands,
AVPs and AVP values as much as possible. However, some of the
extensibility rules described in the previous section also apply to
scenarios where a designer is trying to define a completely new
Diameter application.
This section discusses the case where new applications have
requirements that cannot be filled by existing applications and would
require definition of completely new commands, AVPs and/or AVP
values. Typically, there is little ambiguity about the decision to
create these types of applications. Some examples are the interfaces
defined for the IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([5] and
[6]), Sh ([7] and [8]) etc.
Application design should also follow the theme of Diameter
extensibility which in this case may mean the importing of existing
AVPs and AVP values for any newly defined commands. In certain cases
Fajardo, et al. Expires May 16, 2008 [Page 10]
Internet-Draft Diameter Applications Design Guidelines November 2007
where accounting will be used, the models described in Section 6.1
should also be considered. Though some decisions may be clear,
designers should also consider certain aspects of defining a new
application. Some of these are described in following sections.
5.1. Rules in Allocating new Command Codes
If the protocol design justifies the allocation of a new command code
then a new application as well as a new application ID is required.
One of the drawbacks of [9] was that it required application
designers to go through a lengthy expert review process in order to
be allocated with a new command code(s). This restricts designers
who has to follow strict deadlines for delivering their applications.
Some designers eventually reverted to sub-optimal application design
to circumvent this restriction. To fix this issue, revisions
introduced in [1] has relaxed the process and introduced a vendor
specific command code space that can be allocated on a first-come
first-serve basis.
5.2. Justifying the Allocation of Application-Id
Application designers should avoid justifying the allocation of an
application ID for every new functionality or every minor change that
is made to an existing application. Proliferation of applications
that are very similar can lead to confusion. Application designers
should always use Section 4 as a basis for justifying allocation of a
new application ID.
5.3. Use of Application-Id in a Message
When designing new applications, designers should specify that the
application ID carried in all session level messages must be the
application ID of the application using those messages. This
includes the session level messages defined in base protocol, i.e.,
RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the coupled
accounting model, see Section 6.1. Existing specifications may not
adhere to this rule for historical or other reasons. However, this
scheme should be followed to avoid possible routing problems for
these messages.
In general, when a new application has been allocated with a new
application id and it also reuses existing commands with or without
modifications (Sec 4.1), it must use the newly allocated application
id in the header and in all relevant application id AVPs (Auth-
Application-Id or Acct-Application-Id) present in the commands
message body.
Additionally, application designs using
Fajardo, et al. Expires May 16, 2008 [Page 11]
Internet-Draft Diameter Applications Design Guidelines November 2007
Vendor-Specific-Application-Id AVP should not use the Vendor-Id AVP
to further dissect or differentiate the vendor-specification
application id. The Vendor-Id should also not be used as an
additional input for routing or delivery of messages. In general,
the Vendor-Id AVP is an informational AVP only and kept for backward
compatibility reasons.
5.4. Application Specific Session Statemachine
Section 8 of [1] provides session statemachines for authentication,
authorization and accounting (AAA) services. When a new application
is being defined that cannot clearly be categorized into any of these
services it is recommended that the application itself define its own
session statemachine. The existing session statemachines defined by
[1] is not intended for general use beyond AAA services, therefore
any behavior not covered by that category would not fit well.
Support for server initiated request is a clear example where an
application specific session statemachine would be needed; i.e. Rw
interface for ITU-T push model.
5.5. End-to-End Applications Capabilities Exchange
It is also possible that applications can use a type of optional
capabilities exchange AVPs as a means to convey support for specific
application features. These AVPs are exchanged on an end-to-end
basis and known only by the application supporting them. The use of
such AVPs must obviously be limited to convey functionality of the
applications itself. Examples of this can be found in [2] and [3].
This method can be used to resolve some of the problems described in
Section 6.3 and Section 6.2. It is also useful in providing some
restrictions and/or guidelines on the how the other functionality
related AVPs can be include in a command to avoid issues described in
Section 4.2.1. Such end-to-end capabilities AVPs can aid in the
following cases:
o Formalizing the way new functionality is added to existing
applications by announcing support for it. This makes determining
support for one or more specific functionality less ambiguous.
o Provide a way to further negotiate capabilities if allowed by the
applications.
o Applications that do not understand the capabilities AVP can
safely ignore it upon receipt. In such case, senders of the AVP
can also safely assume the receiving end-point does not support
any functionality carried by the AVP if it is not present in
subsequent responses.
Fajardo, et al. Expires May 16, 2008 [Page 12]
Internet-Draft Diameter Applications Design Guidelines November 2007
Note that this list is not meant to be comprehensive.
6. Other Design Considerations
The following are some of the design considerations that apply to a
Diameter application.
6.1. Diameter Accounting Support
Accounting can be treated as an auxiliary application which is used
in support of other applications. In most cases, accounting support
is required when defining new applications. However, the lack of
clarity in the base protocol document has prevented easy use the base
accounting messages (ACR/ACA). This document provides two(2)
possible models for using accounting:
Split Accounting Model
In this model, the accounting messages will use the Diameter base
accounting application ID (value of 3). The design implication
for this is that the accounting is treated as an independent
application, especially during diameter routing. This means that
accounting commands emanating from an application may be routed
separately from the rest of the other application messages. This
also implies that the messages generally end up in a central
accounting server. A split accounting model is a good design
choice when:
* The application itself will not define its own unique
accounting commands.
* The overall system architecture permits the use of centralized
accounting for one or more Diameter applications.
Centralizing accounting may have advantages but there are also
drawbacks. The model assumes that the accounting server can
somehow differentiate received accounting messages. Since the
received accounting messages can be for any application and/or
service, the accounting server has to be have a method to uniquely
match accounting messages with applications and/or services being
accounted for. This may mean defining new AVPs, checking the
presence, absence or contents of existing AVPs or checking the
contents of the accounting records itself. But in general, there
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
Fajardo, et al. Expires May 16, 2008 [Page 13]
Internet-Draft Diameter Applications Design Guidelines November 2007
recommended.
Coupled Accounting Model
In this model, the accounting messages will use the application ID
of the application using the accounting service. The design
implication for this is that the accounting messages are tightly
coupled with the application itself; meaning that accounting
messages will be routed like any other application messages. It
would then be the responsibility of the application server
(application entity receiving the ACR message) to send the
accounting records carried by the accounting messages to the
proper accounting server. The application server is also
responsible for formulating a proper response (ACA). A coupled
accounting model is a good design choice when:
* The system architecture or deployment will not provide an
accounting server that supports Diameter.
* The system architecture or deployment requires that the
accounting service for the specific application should be
handled by the application itself.
* The application server is provisioned to use a different
protocol to access the accounting server; i.e., via LDAP, XML
etc. This includes attempting to support older accounting
systems that are not Diameter aware.
In all cases above, there will generally be no direct Diameter
access to the accounting server.
These models provide a basis for using accounting messages.
Application designers may obviously deviate from these models
provided that the factors being addressed here have also been taken
into account. Though it is not recommended, examples of other
methods might be defining a new set of commands to carry application
specific accounting records.
6.2. Generic Diameter Extensions
Generic Diameter extensions are AVPs, commands or applications that
are designed to support other Diameter applications. They are
auxiliary applications meant to improve or enhance the Diameter
protocol itself or Diameter applications/functionality. Some
examples include the extensions to support auditing and redundancy
(see [11]), improvements in duplicate detection scheme (see [12]),
and piggybacking of QoS attributes (see [10]).
Fajardo, et al. Expires May 16, 2008 [Page 14]
Internet-Draft Diameter Applications Design Guidelines November 2007
Since generic extensions can cover many aspects of Diameter and
Diameter applications, it is not possible to enumerate all the
probable scenarios in this document. However, some of the most
common considerations are as follows:
o Backward compatibility: Dealing with existing applications that do
not understand the new extension. Designers also have to make
sure that new extensions do not break expected message delivery
layer behavior.
o Forward compatibility: Making sure that the design will not
introduce undue restrictions for future applications. Future
applications attempting to support this feature should not have to
go through great lengths to implement any new extensions.
o Tradeoffs in signaling: Designers may have to choose between the
use of optional AVPs piggybacked onto existing commands versus
defining new commands and applications. Optional AVPs are simpler
to implement and may not need changes to existing applications;
i.e., use of proxy agents. However, the drawback is that the
timing of sending extension data will be tied to when the
application would be sending a message. This has consequences if
the application and the extensions have different timing
requirements. The use of commands and applications solves this
issue but the tradeoff is the additional complexity of defining
and deploying a new application. It is left up to the designer to
find a good balance among these tradeoffs based on the
requirements of the extension.
In practice, it is often the case that the generic extensions use
optional AVPs because it's simple and not intrusive to the
application that would carry it. Peers that do not support the
generic extensions need not understand nor recognize these optional
AVPs. However, it is 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 can be used only by a specific set of
applications then the specification must enumerate these applications
and the scenarios 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 specify such a use case and perhaps provide
specific examples of applications using them.
In most cases, these optional AVPs piggybacked by applications would
be defined as a Grouped AVP and it would encapsulate all the
functionality of the generic extension. In practice, it is not
uncommon that the Grouped AVP will encapsulate an existing AVP that
has previously been defined as mandatory ('M'-bit set); i.e. 3GPP IMS
Fajardo, et al. Expires May 16, 2008 [Page 15]
Internet-Draft Diameter Applications Design Guidelines November 2007
Cx / Dx interfaces ([5] and [6]). In previous revisions of the
Diameter base protocol, the Grouped AVP itself would also have to be
mandatory ('M'-bit set) which defeats the purpose of a non intrusive
optional AVP. This restriction has been lifted in the latest
revision of the Diameter base protocol. This gives more flexibility
to authors of generic extensions with regards to the use of optional
Grouped AVPs.
6.3. Updating an existing Application
An application that is being upgraded must follow the same rules
mentioned Section 4. Even if the new version is fundamentally the
same application, allocation of a new application ID is possible if
it meets those criteria.
Optional AVPs can also be used to indicate version differences. If
this approach is chosen, it is recommended that the optional AVP is
used specifically to indicate version information only and nothing
else. Additionally, the use of too many optional AVPs to carry
application enhancements should be avoided since such approach has a
tendency to become unmanageable and introduce interoperability
issues. These pitfalls are discussed in Section 4.2.1
For the same reason, care should be taken in attempting to justify
allocation of new application ID for every change. The pitfalls of
this approach is discussed in Section 5.3.
Acceptable techniques can be used to provide feature upgrades to
existing applications. One of these is described in Section 5.5.
6.4. System Architecture and Deployment
The following are some of the architecture considerations that
applications designers should contemplate when defining new
applications:
o For general AAA applications, Diameter requires more message
exchanges for the same set of services compared to RADIUS.
Therefore, application designers should consider scalability
issues during the design process.
o Application design should be agnostic to any Diameter topology.
Application designers should not always assume a particular
Diameter topology; i.e., assume that there will always be
application proxies in the path or assume that only intra-domain
routing is applicable.
Fajardo, et al. Expires May 16, 2008 [Page 16]
Internet-Draft Diameter Applications Design Guidelines November 2007
o Security Considerations. Application designers should take into
account that there is no end-to-end authentication built into
Diameter.
o Application design should consider some form of redundancy.
Session state information is the primary data necessary for
backup/recovering endpoints to continue processing for an
previously existing session. Carrying enough information in the
messages to reconstruct session state facilitates redundant
implementations and is highly recommended.
o Application design should segregate message delivery layer
processing from application level processing. An example is the
use of timers to detect lack of a response for a previously sent
requests. Although the Diameter base protocol defines a watchdog
timer Tw, its use on application level is discouraged since Tw is
a hop-by-hop timer and it would not be relevant for end-to-end
message delivery error detection. In such a case, it is
recommended that applications should define their own set of
timers for such purpose.
o Applications should specify AVPs which could be used to further
aid in duplication detection. In some cases, when extending an
application, existing AVPs can be reused to provide additional
duplication detection indicators; i.e., combination of Session-Id
and CC-Request-Number AVPs in the Diameter Credit Control
application [4]. In cases where the extensions needs to define
new AVPs, it is recommended that the new AVPs be used only for
this purpose.
7. IANA Considerations
This document does not require actions by IANA.
8. Security Considerations
This document does provides guidelines and considerations for
extending Diameter and Diameter applications. It does not define nor
address security related protocols or schemes.
9. Acknowledgments
We greatly appreciate the insight provided by Diameter implementers
who have highlighted the issues and concerns being addressed by this
document.
Fajardo, et al. Expires May 16, 2008 [Page 17]
Internet-Draft Diameter Applications Design Guidelines November 2007
10. References
10.1. Normative References
[1] Fajardo, V., "Diameter Base Protocol",
draft-ietf-dime-rfc3588bis-08 (work in progress), October 2007.
[2] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and
M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to
Diameter Server Interaction", draft-ietf-dime-mip6-split-05
(work in progress), September 2007.
[3] Zorn, G., "Diameter Quality of Service Application",
draft-ietf-dime-diameter-qos-01 (work in progress), July 2007.
[4] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
Loughney, "Diameter Credit-Control Application", RFC 4006,
August 2005.
[5] 3GPP, "IMS Cx and Dx interfaces : signalling flows and message
contents", 3GPP TS 29.228 Version 7.0.0 2006.
[6] 3GPP, "IMS Cx and Dx interfaces based on the Diameter protocol;
Protocol details", 3GPP TS 29.229 Version 7.0.0 2006.
[7] 3GPP, "IMS Sh interface : signalling flows and message
content", 3GPP TS 29.328 Version 6.8.0 2005.
[8] 3GPP, "IMS Sh interface based on the Diameter protocol;
Protocol details", 3GPP TS 29.329 Version 6.6.0 2005.
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[10] Korhonen, J., Tschofenig, H., and M. Arumaithurai, "Quality of
Service Attributes for Diameter",
draft-ietf-dime-qos-attributes-02 (work in progress),
September 2007.
10.2. Informative References
[11] Calhoun, P., "Diameter Resource Management Extensions",
draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
March 2001.
[12] Asveren, T., "Diameter Duplicate Detection Cons.",
draft-asveren-dime-dupcons-00 (work in progress), August 2006.
Fajardo, et al. Expires May 16, 2008 [Page 18]
Internet-Draft Diameter Applications Design Guidelines November 2007
Authors' Addresses
Victor Fajardo (editor)
Toshiba America Research Inc.
One Telcordia Drive, #1S222
Piscataway, NJ 08854
USA
Email: vfajardo@tari.toshiba.com
Tolga Asveren
Sonus Network
4400 Route 9 South
Freehold, NJ 07728
USA
Email: tasveren@sonusnet.com
Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Phone: +49 89 636 40390
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Glenn McGregor
Alcatel-Lucent
3461 Robin Ln Ste 1
Cameron Park, CA 95682
USA
Email: glenn@aaa.lucent.com
Fajardo, et al. Expires May 16, 2008 [Page 19]
Internet-Draft Diameter Applications Design Guidelines November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Fajardo, et al. Expires May 16, 2008 [Page 20]
