One document matched: draft-ietf-dime-app-design-guide-06.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2629 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY rfc4006 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4006.xml'>
<!ENTITY rfc3588 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
<!ENTITY I-D.asveren-dime-dupcons PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.asveren-dime-dupcons.xml'>
<!ENTITY I-D.ietf-dime-mip6-integrated PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-mip6-integrated.xml'>
<!ENTITY I-D.ietf-dime-mip6-split PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-mip6-split.xml'>
<!ENTITY I-D.ietf-dime-diameter-qos PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-diameter-qos.xml'>
<!ENTITY I-D.ietf-dime-qos-attributes PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-qos-attributes.xml'>
<!ENTITY I-D.ietf-dime-rfc3588bis PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-rfc3588bis.xml'>
]>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc category="info" ipr="full3978" docName="draft-ietf-dime-app-design-guide-06.txt">
<front>
<title>Diameter Applications Design Guidelines</title>
<!-- ************** VICTOR FAJARDO *************** -->
<author role="editor" initials="V." surname="Fajardo" fullname="Victor Fajardo">
<organization>Toshiba America Research Inc.</organization>
<address>
<postal>
<street>One Telcordia Drive, #1S222</street>
<city>Piscataway</city>
<region>NJ</region>
<code>08854</code>
<country>USA</country>
</postal>
<email>vfajardo@tari.toshiba.com</email>
</address>
</author>
<!-- ************** TOLGA ASVEREN *************** -->
<author initials="T." surname="Asveren" fullname="Tolga Asveren">
<organization>Sonus Network</organization>
<address>
<postal>
<street>4400 Route 9 South</street>
<city>Freehold</city>
<region>NJ</region>
<code>07728</code>
<country>USA</country>
</postal>
<email>tasveren@sonusnet.com</email>
</address>
</author>
<!-- ************** HANNES TSCHOFENIG *************** -->
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization abbrev="Nokia Siemens Networks">Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<phone>+49 89 636 40390</phone>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<!-- ************** GLENN MCGREGOR *************** -->
<author initials="G." surname="McGregor" fullname="Glenn McGregor">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>3461 Robin Ln Ste 1</street>
<city>Cameron Park</city>
<region>CA</region>
<code>95682</code>
<country>USA</country>
</postal>
<email>glenn@aaa.lucent.com</email>
</address>
</author>
<!-- ************** JOHN LOUGHNEY *************** -->
<author initials="J." surname="Loughney" fullname="John Loughney">
<organization>Nokia Research Center</organization>
<address>
<postal>
<street>955 Page Mill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>
<phone>1-650-283-8068</phone>
<email>john.loughney@nokia.com</email>
</address>
</author>
<date year="2008"/>
<area>Operations and Management Area</area>
<workgroup>Diameter Maintanence and Extensions (DIME)</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t> 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 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. </t>
</abstract>
</front>
<middle>
<!-- ***** Introduction ******* -->
<section anchor="intro" title="Introduction">
<t> The Diameter Base protocol document defines rules on how one would extend Diameter
(see Section 1.2 of <xref target="I-D.ietf-dime-rfc3588bis"/>). In the context of this document,
extending Diameter means one of the following:<vspace blankLines="1"/>
<list style="numbers">
<t>A new functionality is being added to an existing Diameter
application without defining a new application.<vspace blankLines="1"/></t>
<t>A new Diameter application is being defined by reusing an existing application.
<vspace blankLines="1"/></t>
<t>A completely new application is being defined that has no dependencies to
any existing applications.<vspace blankLines="1"/></t>
<t>A new generic functionality is being defined that can be reused across
different applications.<vspace blankLines="1"/></t>
</list>
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:<vspace blankLines="1"/>
<list style="symbols">
<t>Clarify updated Diameter extensibility rules in the Diameter Base Protocol.
<vspace blankLines="1"/></t>
<t>Clarify usage of certain Diameter functionality which are not explicitly
described in the Diameter Base specification.<vspace blankLines="1"/></t>
<t>Discuss design choices and provide guidelines when defining applications.
<vspace blankLines="1"/></t>
<t>Present tradeoffs of design choices.<vspace blankLines="1"/></t>
</list>
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.</t>
<t>Along with the gained experience however, additional bad practices have developed
as well. Continuing the example above, the decision 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
<xref target="new-element-rules-cmd-alloc"/>).</t>
<t>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. </t>
</section>
<section title="Terminology">
<t> This document reuses the terminology used in <xref target="I-D.ietf-dime-rfc3588bis"/>. </t>
</section>
<section anchor="model" title="Brief Overview of the Diameter Application Model">
<t> 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 <xref
target="I-D.ietf-dime-rfc3588bis"/>). 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. </t>
</section>
<section anchor="reuse-rules" title="Rules on Extending Diameter">
<t>Extending Diameter can mean the reuse of commands, AVPs and AVP values
in any combination for the purpose of inheriting the features of an existing
Diameter applications. This section discusses the rules on how such reuse
can be done.</t>
<t>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:<vspace blankLines="1"/>
<list style="numbers">
<t>Minimal - which typically means adding optional AVPs to existing commands.
<vspace blankLines="1"/></t>
<t>Invasive - where addition or deletion of commands and/or AVPs, and/or
AVP values (in the case where the AVP is of type Enumerated).<vspace blankLines="1"/></t>
</list>
</t>
<t>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.</t>
<t>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 <xref target="reuse-cmd-add-avp"/>. 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.</t>
<section anchor="reuse-application" title="Reusing Existing Applications">
<t>This section discusses the reuse of existing applications by adding and/or deleting
commands from the application. This scenario is categorize as "Invasive" in
<xref target="reuse-rules"/> and would always result in the creation of a new
application when the rules are applied.</t>
<section anchor="reuse-app-new-cmd" title="Adding a new command">
<t>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 <xref target="new-element-rules-cmd-alloc"/>
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.<vspace blankLines="1"/>
A typical example would be the Diameter MIPv6 split scenario (see
<xref target="I-D.ietf-dime-mip6-split"/>) 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 <xref target="I-D.ietf-dime-diameter-qos"/>) would likely face
similar decisions.<vspace blankLines="1"/>
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:<vspace blankLines="1"/>
<list style="symbols">
<t>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.<vspace blankLines="1"/></t>
<t>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 <xref target="reuse-cmd-add-avp"/><vspace blankLines="1"/></t>
<t>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.<vspace blankLines="1"/></t>
<t>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.<vspace blankLines="1"/></t>
<t>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 <xref target="I-D.ietf-dime-mip6-split"/>)
where authorization and authentication is separated.</t>
</list><vspace blankLines="1"/>
Note that accounting commands normally require special treatment and would not
necessarily fall into this category. See <xref target="other-accounting"/>.
</t>
</section>
<section anchor="reuse-app-del-cmd" title="Deleting a command">
<t>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 <xref target="reuse-app-new-cmd"/> 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 <xref target="other-app-updates"/>
should apply instead.</t>
</section>
</section>
<section anchor="reuse-commands" title="Reusing Existing Commands">
<t>This section deals with a little more granularity than <xref target="reuse-application"/>.
Specifically, it discusses rules in adding and/or deleting AVPs from an existing command
of an existing application. Unlike <xref target="reuse-application"/>, 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.</t>
<section anchor="reuse-cmd-add-avp" title="Adding AVPs to a command">
<t>Based on the rules in <xref target="I-D.ietf-dime-rfc3588bis"/>, AVPs that are added to
an existing command can be categorized into:<vspace blankLines="1"/>
<list style="symbols">
<t>Mandatory to understand AVPs. As defined in <xref target="I-D.ietf-dime-rfc3588bis"/>,
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. See <xref target="other-mandatory-flag"/>
for details on the use of the M-bit.<vspace blankLines="1"/></t>
<t>Non-mandatory AVPs that are also optional in the commands ABNF.</t>
</list></t>
<t>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. <xref target="I-D.ietf-dime-rfc3588bis"/>
states that doing so would require the definition of a new application. This falls into
the "Invasive" category described in <xref target="reuse-rules"/>. 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:
<vspace blankLines="1"/>
<list style="symbols">
<t>Do the AVPs change the state machine of the application ?<vspace blankLines="1"/></t>
<t>Would the presence of the AVPs cause additional message round-trips; effectively
changing the state machine of the application ?<vspace blankLines="1"/></t>
<t>Will the AVP be used to fulfill new required functionality ?<vspace blankLines="1"/></t>
<t>Would the AVP be used to differentiate between old and new versions
of the same application ?<vspace blankLines="1"/></t>
<t>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 ?</t>
</list></t>
<t>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.</t>
<t>The rules are less restrictive when adding non-mandatory, optional AVPs. This falls into
the "Minimal" category described in <xref target="reuse-rules"/>. 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:<vspace blankLines="1"/>
<list style="symbols">
<t>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.
<vspace blankLines="1"/></t>
<t>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.<vspace blankLines="1"/></t>
<t>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.<vspace blankLines="1"/></t>
<t>Adding one or more optional AVPs and indicating (usually within
descriptive text for the command) that at least one of them has to be
present in the command. This essentially circumventing the ABNF and
is equivalent to adding a mandatory AVPs to the command.<vspace blankLines="1"/></t>
</list>
All of these practices generally result in interoperability problems so they
should be avoided as much as possible.</t>
</section>
<section anchor="reuse-cmd-del-avp" title="Deleting AVPs from a command">
<t>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 <xref target="reuse-cmd-add-avp"/>.</t>
<t>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 <xref target="I-D.ietf-dime-rfc3588bis"/>,
deletion of mandatory AVP would require the definition of a new application
since it dictates changes in the behavior and semantics of an application.</t>
<t>Instead of deleting AVPs, 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
<xref target="I-D.ietf-dime-rfc3588bis"/>) where they are being used by many different
applications.</t>
<t>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 <xref target="I-D.ietf-dime-rfc3588bis"/>. However,
there may be existing applications that do not follow the new restrictions in
<xref target="I-D.ietf-dime-rfc3588bis"/>. 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 have to be
corrected as well.</t>
<t>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.
</t>
</section>
</section>
<section anchor="reuse-avps" title="Reusing Existing AVPs">
<t>This section deals with even more granularity than <xref target="reuse-application"/>
and <xref target="reuse-commands"/>. Specifically, it discusses rules in adding, deleting
or modifying the specified values and/or flags 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 <xref target="reuse-rules"/>
and require definition of a new application. Note that designers should consider
<xref target="new-element-rules-justify"/> when contemplating on these types of changes.</t>
<t>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 <xref target="RFC4006"/>. 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 <xref target="reuse-commands"/>. So this affects the decision for
defining new applications as well.</t>
<t>When reusing AVPs in a new application, the AVP flags such as the mandatory flag ('M'-bit)
can be modified (turned on or off) within the application. In general, for AVPs defined outside
of the base protocol, its mandatory characteristics is tied to its role within an application.
Allowing the mandatory flag to be set or un-set by the application(s) makes the AVP more
reusable. Further details on the mandatory flag ('M'-bit) can be found in
<xref target="other-mandatory-flag"/>.</t>
</section>
</section>
<section anchor="new-element-rules" title="Rules for new Applications">
<t>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.</t>
<t>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 (<xref target='TS29.228'/> and
<xref target='TS29.229'/>), Sh (<xref target='TS29.328'/> and <xref target='TS29.329'/>)
etc.</t>
<t>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 where accounting will be used, the models described in
<xref target="other-accounting"/> 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.</t>
<section anchor="new-element-rules-cmd-alloc" title="Rules in Allocating new Command Codes">
<t>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 <xref target="RFC3588"/> 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 <xref target="I-D.ietf-dime-rfc3588bis"/> has
relaxed the process and introduced a vendor specific command code space that can be allocated
on a first-come first-serve basis.
</t>
</section>
<section anchor="new-element-rules-justify" title="Justifying the Allocation of Application-Id">
<t>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 <xref target="reuse-rules"/> as a basis for justifying allocation
of a new application ID.
</t>
</section>
<section anchor="new-element-rules-app-id" title="Use of Application-Id in a Message">
<t>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 <xref target="other-accounting"/>.
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. </t>
<t>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.</t>
<t>Additionally, application designs using 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.</t>
</section>
<section anchor="new-element-rules-fsm" title="Application Specific Session Statemachine">
<t>Section 8 of <xref target="I-D.ietf-dime-rfc3588bis"/> 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 <xref target="I-D.ietf-dime-rfc3588bis"/> 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.</t>
</section>
<section anchor="new-element-rules-e2e-cap" title="End-to-End Applications Capabilities Exchange">
<t>It is also possible that applications can use optional AVPs to exchange application
specific capabilities and features. These AVPs are exchanged on an end-to-end basis and
understood only by the application supporting them. The use of such AVPs must be limited
to convey application functionality. Examples of this can be found in
<xref target="I-D.ietf-dime-mip6-split"/> and <xref target="I-D.ietf-dime-diameter-qos"/>.</t>
<t>This method can be used to resolve some of the problems described in
<xref target="other-app-updates"/> and <xref target="other-generic"/>. 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 <xref target="reuse-cmd-add-avp"/>. Such end-to-end capabilities
AVPs can aid in the following cases:<vspace blankLines="1"/>
<list style="symbols">
<t>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.
<vspace blankLines="1"/></t>
<t>Provide a way to further negotiate capabilities if allowed by the applications.
<vspace blankLines="1"/></t>
<t>Applications that do not understand these AVP can discard 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.<vspace blankLines="1"/></t>
</list>
Note that this list is not meant to be comprehensive.
</t>
</section>
</section>
<section anchor="other" title="Other Design Considerations">
<t>The following are some of the design considerations that apply
to a Diameter application.
</t>
<section anchor="other-accounting" title="Diameter Accounting Support">
<t>
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:<vspace blankLines="1"/>
<list style="hanging">
<t hangText="Split Accounting Model"><vspace blankLines="1"/>
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:
<vspace blankLines="1"/>
<list style="symbols">
<t>The application itself will not define its own unique accounting
commands.<vspace blankLines="1"/></t>
<t>The overall system architecture permits the use of centralized
accounting for one or more Diameter applications.</t>
</list><vspace blankLines="1"/>
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 recommended.
<vspace blankLines="1"/>
</t>
<t hangText="Coupled Accounting Model"><vspace blankLines="1"/>
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:<vspace blankLines="1"/>
<list style="symbols">
<t>The system architecture or deployment will not provide an
accounting server that supports Diameter.<vspace blankLines="1"/></t>
<t>The system architecture or deployment requires that the
accounting service for the specific application should be
handled by the application itself.<vspace blankLines="1"/></t>
<t>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.<vspace blankLines="1"/></t>
</list>
In all cases above, there will generally be no direct Diameter access
to the accounting server.<vspace blankLines="1"/></t>
</list>
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.
</t>
</section>
<section anchor="other-generic" title="Generic Diameter Extensions">
<t>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 <xref target="I-D.calhoun-diameter-res-mgmt"/>),
improvements in duplicate detection scheme (see <xref target="I-D.asveren-dime-dupcons"/>),
and piggybacking of QoS attributes (see <xref target="I-D.ietf-dime-qos-attributes"/>).</t>
<t>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:<vspace blankLines="1"/>
<list style="symbols">
<t>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.<vspace blankLines="1"/></t>
<t>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.
<vspace blankLines="1"/></t>
<t>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.<vspace blankLines="1"/></t>
</list>
</t>
<t>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.
</t>
<t>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 Cx / Dx
interfaces (<xref target='TS29.228'/> and <xref target='TS29.229'/>). 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.
</t>
</section>
<section anchor="other-app-updates" title="Updating an existing Application">
<t> An application that is being upgraded must follow the same rules mentioned
<xref target="reuse-rules"/>. Even if the new version is fundamentally
the same application, allocation of a new application ID is possible
if it meets those criteria.</t>
<t>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
<xref target="reuse-cmd-add-avp"/></t>
<t>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 <xref target="new-element-rules-app-id"/>.</t>
<t>Acceptable techniques can be used to provide feature upgrades to existing
applications. One of these is described in <xref target="new-element-rules-e2e-cap"/>.</t>
</section>
<section anchor="other-mandatory-flag" title="Use of Mandatory (M-bit) flags">
<t>
There has always been some confusion on the usage of an AVPs mandatory
flag, M-bit, especially when it relates to the optional or required
settings of the AVP within an ABNF. As a rule, the M-bit specifies whether
the receiver of the AVP is required to understand and interpret the AVP
and its content. This is regardless of whether the AVP is optional to appear
in a message or not. However, there is some redundancy and overlap in this
rule mainly because if the AVP is non-optional in the ABNF then it is obvious
that the application must understands it. And even if the AVP is optional,
i.e. it is defined with "[AVP-Name]", it is reasonable to imply that the
application would have to understand this AVP since it is explicit about its
presence in the ABNF and even perhaps its usage. Given this, it is reasonable
to assume that the M-bit is set only for AVPs explicitly appearing in an
applications ABNF. The following practices can be applied when deciding whether
to set the mandatory (M-bit) flag on an AVP:<vspace blankLines="1"/>
<list style="symbols">
<t>AVPs appearing explicitly in an applications ABNF must have it's
M-bit set. These application must have been allocated its own
application-Id.
<vspace blankLines="1"/></t>
<t>AVPs designed to be added to existing applications and not
explicitly appearing on those applications must not have its
M-bit set. These are AVPs defined outside of the applications
that can carry it. Examples can be found in
<xref target="I-D.ietf-dime-mip6-split"/>,
<xref target="I-D.ietf-dime-mip6-integrated"/> and
<xref target="I-D.ietf-dime-qos-attributes"/>.<vspace blankLines="1"/></t>
</list>
This practice somewhat degrades the usefulness of the mandatory AVP concept which
may have flaws to begin with. However, it greatly simplifies how to define which
AVPs are required to be understood and which are not.
</t>
</section>
<section anchor="other-app-network" title="System Architecture and Deployment">
<t>The following are some of the architecture considerations that applications
designers should contemplate when defining new applications:<vspace blankLines="1"/>
<list style="symbols">
<t>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.<vspace blankLines="1"/></t>
<t>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.<vspace blankLines="1"/></t>
<t>Security Considerations. Application designers should take into
account that there is no end-to-end authentication built into
Diameter.<vspace blankLines="1"/></t>
<t>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.<vspace blankLines="1"/></t>
<t>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.
<vspace blankLines="1"/></t>
<t>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 <xref target="RFC4006"/>. In cases where the extensions needs
to define new AVPs, it is recommended that the new AVPs be used only for this
purpose.</t>
</list>
</t>
</section>
</section>
<section title="IANA Considerations">
<t> This document does not require actions by IANA. </t>
</section>
<section title="Security Considerations">
<t> This document does provides guidelines and considerations for extending Diameter and
Diameter applications. It does not define nor address security related protocols or schemes.
</t>
</section>
<section anchor="acks" title="Acknowledgments">
<t> We greatly appreciate the insight provided by Diameter implementers who have highlighted
the issues and concerns being addressed by this document. </t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc4006;
&rfc3588;
&I-D.ietf-dime-mip6-split;
&I-D.ietf-dime-mip6-integrated;
&I-D.ietf-dime-diameter-qos;
&I-D.ietf-dime-qos-attributes;
&I-D.ietf-dime-rfc3588bis;
<reference anchor='TS29.228'>
<front>
<title>
IMS Cx and Dx interfaces : signalling flows and message contents
</title>
<author>
<organization>
3GPP
</organization>
</author>
</front>
<seriesInfo name="3GPP TS 29.228 Version 7.0.0" value="2006" />
</reference>
<reference anchor='TS29.229'>
<front>
<title>
IMS Cx and Dx interfaces based on the Diameter protocol; Protocol details
</title>
<author>
<organization>
3GPP
</organization>
</author>
</front>
<seriesInfo name="3GPP TS 29.229 Version 7.0.0" value="2006" />
</reference>
<reference anchor='TS29.328'>
<front>
<title>
IMS Sh interface : signalling flows and message content
</title>
<author>
<organization>
3GPP
</organization>
</author>
</front>
<seriesInfo name="3GPP TS 29.328 Version 6.8.0" value="2005" />
</reference>
<reference anchor='TS29.329'>
<front>
<title>
IMS Sh interface based on the Diameter protocol; Protocol details
</title>
<author>
<organization>
3GPP
</organization>
</author>
</front>
<seriesInfo name="3GPP TS 29.329 Version 6.6.0" value="2005" />
</reference>
</references>
<references title="Informative References">
&I-D.asveren-dime-dupcons;
<reference
anchor="I-D.calhoun-diameter-res-mgmt">
<front>
<title>Diameter Resource Management Extensions</title>
<author initials="P." surname="Calhoun" fullname="Pat Calhoun">
<organization/>
</author>
<date month="March" year="2001"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-calhoun-diameter-res-mgmt-08.txt"/>
<format type="TXT" target="http://tools.ietf.org/id/draft-calhoun-diameter-res-mgmt-08.txt"
/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:34:57 |