[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-fajardo-dime-app-design-guide) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 RFC 7423

Diameter Maintanence and                                 V. Fajardo, Ed.
Extensions (DIME)                          Toshiba America Research Inc.
Internet-Draft                                                T. Asveren
Intended status: Informational                             Sonus Network
Expires: April 3, 2008                                     H. Tschofenig
                                                  Nokia Siemens Networks
                                                             G. McGregor
                                                          Alcatel-Lucent
                                                             J. Loughney
                                                   Nokia Research Center
                                                         October 1, 2007


                Diameter Applications Design Guidelines
                draft-ietf-dime-app-design-guide-03.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 April 3, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The Diameter Base protocol provides updated rules on how to extend



Fajardo, et al.           Expires April 3, 2008                 [Page 1]


Internet-Draft   Diameter Applications Design Guidelines    October 2007


   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.


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  . . . . . . . . 11
     5.5.  End-to-End Applications Capabilities Exchange  . . . . . . 12
   6.  Other Design Considerations  . . . . . . . . . . . . . . . . . 12
     6.1.  Diameter Accounting Support  . . . . . . . . . . . . . . . 13
     6.2.  Generic Diameter Extensions  . . . . . . . . . . . . . . . 14
     6.3.  Updating an existing Application . . . . . . . . . . . . . 15
     6.4.  System Architecture and Deployment . . . . . . . . . . . . 15
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     10.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 20












Fajardo, et al.           Expires April 3, 2008                 [Page 2]


Internet-Draft   Diameter Applications Design Guidelines    October 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 exist 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 was not
   foreseen in the existing extensibility rules; i.e., 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 April 3, 2008                 [Page 3]


Internet-Draft   Diameter Applications Design Guidelines    October 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 purposely been
   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 inline 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 April 3, 2008                 [Page 4]


Internet-Draft   Diameter Applications Design Guidelines    October 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 application's that can be reused to solve some or all of the
   application requirements.  Therefore, there is a greater likelihood
   of ambiguity on how much of the existing application can be reused,
   to what extent and what 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.


   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 is 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 new applications when the rules are applied.







Fajardo, et al.           Expires April 3, 2008                 [Page 5]


Internet-Draft   Diameter Applications Design Guidelines    October 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 straight forward
   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 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; i.e. a non-mandatory optional AVP is sufficient to
      indicate support for new optional functionality if any.  There are
      pitfalls to this 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 functionality.




Fajardo, et al.           Expires April 3, 2008                 [Page 6]


Internet-Draft   Diameter Applications Design Guidelines    October 2007


   o  Will the new feature or functionality refers 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 is 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 for the sake of deleting it or the
   functionality it represents.  This design decision would normally be
   an indication of a flawed designed.  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 outline 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 April 3, 2008                 [Page 7]


Internet-Draft   Diameter Applications Design Guidelines    October 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 has 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 is
   mandatory.  A mandatory 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  Does 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 consider
   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 April 3, 2008                 [Page 8]


Internet-Draft   Diameter Applications Design Guidelines    October 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 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 indicate
   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.  In the case where an optional AVP has a
   minimum occurrence of at least one(1) in the commands ABNF, then
   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.

   In other cases, it is recommended that application designers reuse
   the command ABNF without modification and simply ignore (but not



Fajardo, et al.           Expires April 3, 2008                 [Page 9]


Internet-Draft   Diameter Applications Design Guidelines    October 2007


   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 CC-Request-Type AVP of [4].
   Adding, deleting or modifying known values of this AVP can modify the
   behavior of the application itself.  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 importing of existing AVPs
   and AVP values for any newly defined commands.  In certain cases
   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.



Fajardo, et al.           Expires April 3, 2008                [Page 10]


Internet-Draft   Diameter Applications Design Guidelines    October 2007


5.1.  Rules in Allocating new Command Codes

   [Editor's note: The expert review process for command code allocation
   is being introduced to hasten the allocation process itself.
   Hopefully this will lessen the tendency to circumvent this process.
   The core rules for this process will be introduced in rfc3588bis and
   full description will be added in this section in the next rev of
   this document]

5.2.  Justifying the Allocation of Application-Id

   Application designers should avoid justifying the allocation of an
   application ID for each new functionality or any change that is made
   to an existing application.  Proliferation of application ID can lead
   to confusion and an in-efficient use of the application ID
   namespaces.  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 is 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 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
   Vendor-Specific-Application-Id AVP should note use the Vendor-Id AVP
   to further dissect or differentiate the vendor-specification
   application id.  It should also not be used as an additional input
   for routing or delivery of messages.

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



Fajardo, et al.           Expires April 3, 2008                [Page 11]


Internet-Draft   Diameter Applications Design Guidelines    October 2007


   services it is recommended that the application itself defines 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 way 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.

   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.







Fajardo, et al.           Expires April 3, 2008                [Page 12]


Internet-Draft   Diameter Applications Design Guidelines    October 2007


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 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.

      From a Diameter architecture perspective, this model should be the
      typical design choice.  Note that when using this model, the
      accounting server must use the Acct-Application-Id AVP to
      determine which application is being accounted for.  Therefore,
      the application designer should specify the proper values used in
      Acct-Application-Id AVP when sending ACR messages.

   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 is 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:




Fajardo, et al.           Expires April 3, 2008                [Page 13]


Internet-Draft   Diameter Applications Design Guidelines    October 2007


      *  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 would be defining a new set of commands to carry application
   specific accounting records.

   Additionally, the application ID in the message header and
   Accounting-Application-Id AVP are populated depending on the
   accounting model used for a specific application, as described in
   [1].  Therefore, application designers have to specify the accounting
   model used to guarantee proper routing of accounting requests.

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 [9]), improvements in duplicate detection scheme (see [10]).

   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.





Fajardo, et al.           Expires April 3, 2008                [Page 14]


Internet-Draft   Diameter Applications Design Guidelines    October 2007


   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.


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:




Fajardo, et al.           Expires April 3, 2008                [Page 15]


Internet-Draft   Diameter Applications Design Guidelines    October 2007


   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.

   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.






Fajardo, et al.           Expires April 3, 2008                [Page 16]


Internet-Draft   Diameter Applications Design Guidelines    October 2007


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.


10.  References

10.1.  Normative References

   [1]   Fajardo, V., "Diameter Base Protocol",
         draft-ietf-dime-rfc3588bis-07 (work in progress),
         September 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.






Fajardo, et al.           Expires April 3, 2008                [Page 17]


Internet-Draft   Diameter Applications Design Guidelines    October 2007


10.2.  Informative References

   [9]   Calhoun, P., "Diameter Resource Management Extensions",
         draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
         March 2001.

   [10]  Asveren, T., "Diameter Duplicate Detection Cons.",
         draft-asveren-dime-dupcons-00 (work in progress), August 2006.


Authors' Addresses

   Victor Fajardo (editor)
   Toshiba America Research Inc.
   One Telcordia Drive
   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
   USA

   Email: glenn@aaa.lucent.com





Fajardo, et al.           Expires April 3, 2008                [Page 18]


Internet-Draft   Diameter Applications Design Guidelines    October 2007


   John Loughney
   Nokia Research Center
   USA

   Email: john.loughney@nokia.com














































Fajardo, et al.           Expires April 3, 2008                [Page 19]


Internet-Draft   Diameter Applications Design Guidelines    October 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 April 3, 2008                [Page 20]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/