Diameter Applications Design Guidelines
draft-ietf-dime-app-design-guide-06.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 July 26, 2008.

Abstract

The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to 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
2.  Terminology
3.  Brief Overview of the Diameter Application Model
4.  Rules on Extending Diameter
    4.1.  Reusing Existing Applications
        4.1.1.  Adding a new command
        4.1.2.  Deleting a command
    4.2.  Reusing Existing Commands
        4.2.1.  Adding AVPs to a command
        4.2.2.  Deleting AVPs from a command
    4.3.  Reusing Existing AVPs
5.  Rules for new Applications
    5.1.  Rules in Allocating new Command Codes
    5.2.  Justifying the Allocation of Application-Id
    5.3.  Use of Application-Id in a Message
    5.4.  Application Specific Session Statemachine
    5.5.  End-to-End Applications Capabilities Exchange
6.  Other Design Considerations
    6.1.  Diameter Accounting Support
    6.2.  Generic Diameter Extensions
    6.3.  Updating an existing Application
    6.4.  Use of Mandatory (M-bit) flags
    6.5.  System Architecture and Deployment
7.  IANA Considerations
8.  Security Considerations
9.  Acknowledgments
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

The Diameter Base protocol document defines rules on how one would extend Diameter (see Section 1.2 of [1] (Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, “Diameter Base Protocol,” April 2010.)). 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:

• Clarify updated Diameter extensibility rules in the Diameter Base Protocol.
  
  
• Clarify usage of certain Diameter functionality which are not explicitly described in the Diameter Base specification.
  
  
• Discuss design choices and provide guidelines when defining applications.
  
  
• Present tradeoffs of design choices.
  
  

These guidelines are necessary since the existing rules do not cover the ambiguity that exists when some of the design choices overlap. A typical example would be deciding between item one(1) and two(2) above when an application designer requires a new application functionality which has many things in common with an existing application. Certain ambiguous aspects of such cases were not foreseen in the existing extensibility rules; e.g., use of optional AVPs to differentiate new functionality in the old application versus defining a new application and importing the existing set of commands. In this example, it was only based on collective experiences of application designers that the decision to create a new application (item two(2)) is now seen as the cleanest approach.

Along with the gained experience however, additional bad practices have developed as well. Continuing the example above, the decision 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 (Rules in Allocating new Command Codes)).

The basic issue is that the rules defined in the Diameter Base protocol are not comprehensive enough that one can easily derive good design decisions from them. The effect of this can be seen in various attempts to extend Diameter applications where designers have no clear answer on whether to even define a new application or not. At worst, some existing Diameter applications that had been purposely derived from another existing application resulted in some in-appropriate design decision where both the existing application and the derived applications are no longer interoperable under certain conditions. Note that it is not always possible to offer a complete and concise answer to certain design choices, but at the least, this document can be used as a guide to Diameter extensibility.

2.  Terminology

This document reuses the terminology used in [1] (Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, “Diameter Base Protocol,” April 2010.).

3.  Brief Overview of the Diameter Application Model

As it is currently interpreted and practiced, the Diameter Base protocol is a two-layer protocol. The lower layer is mainly responsible for managing connections between neighboring peers and for message routing. The upper layer is where the Diameter applications reside. This model is in line with a Diameter node having an application layer and a peer-to-peer delivery layer. The Diameter Base protocol document completely defines the architecture and behavior of the message delivery layer and then provides the framework for designing Diameter applications on the application layer. This framework includes definitions of application sessions and accounting support (see Section 8 and 9 of [1] (Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, “Diameter Base Protocol,” April 2010.)). 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 of an existing Diameter applications. This section discusses the rules on how such reuse can be done.

When reusing existing applications, the requirements of the new applications are typically not completely unique and there are existing applications that can be reused to solve some or all of the new application requirements. Therefore, there is a greater likelihood of ambiguity on how much of the existing application can be reused and what would be the implications for both the new and existing application. To broadly categorize, the rules for reusing existing applications can be either:

1. Minimal - which typically means adding optional AVPs to existing commands.
   
   
2. Invasive - where addition or deletion of commands and/or AVPs, and/or AVP values (in the case where the AVP is of type Enumerated).
   
   

Because it can fundamentally change the application, the latter approach has strict repercussions. Specifically, it would result in the definition of a new application and therefore allocation of a new application ID is required. Discussion about the specific Diameter Base protocol rules associated with this approach are covered subsequent sections.

The former approach, although simple, has pitfalls. The problems arise when there is a tendency by applications designers to keep adding optional AVPs to existing command so they can circumvent the rules associated with the latter approach. Specifically, some designers want to circumvent the standardization process associated with these rules and not necessarily the rules themselves. The pitfalls associated with this approach are described further in Section 4.2.1 (Adding AVPs to a command). 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 (Rules on Extending Diameter) and would always result in the creation of a new application when the rules are applied.

4.1.1.  Adding a new command

The rules are strict in this case. Adding a command to an application is not allowed and doing so will force a definition of a new application. However, if this is the intent, then the new application can be created by defining a new command for an existing application or importing an existing command from another application so as to inherit some or all of the functionality of that application. In the former case, the decision is straightforward since this is typically a result of adding new functionality that does not yet exist. See Section 5.1 (Rules in Allocating new Command Codes) 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] (Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, “Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction,” April 2009.)) 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] (Sun, D., McCann, P., Tschofenig, H., ZOU), T., Doria, A., and G. Zorn, “Diameter Quality of Service Application,” March 2010.)) would likely face similar decisions.

In general, it is difficult to come to a hard and fast guideline, and so a case by case study of each application requirement should be applied. Before adding or importing a command, application designers should consider the following:

• 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.
  
  
• Can the existing application be reused as is without fundamental changes; e.g., a non-mandatory optional AVP is sufficient to indicate support for new optional functionality, if any. There are pitfalls to this approach as well. See Section 4.2.1 (Adding AVPs to a command)
  
  
• 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.
  
  
• 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.
  
  
• 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] (Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, “Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction,” April 2009.)) 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 (Diameter Accounting Support).

4.1.2.  Deleting a command

Although this is not typical, deleting an command from an existing application is fundamentally changing the application. In general, the implications of this approach are the same as Section 4.1.1 (Adding a new command) regardless of whether new commands will also be added to the resulting application. In general, it is unusual to delete an existing command from an existing application for the sake of deleting it or the functionality it represents. This design decision would normally be an indication of a flawed design. An exception might be if the intent of the deletion is to create a newer version of the same application which is somehow simpler than the previous version. In that case, the considerations in Section 6.3 (Updating an existing Application) should apply instead.

4.2.  Reusing Existing Commands

This section deals with a little more granularity than Section 4.1 (Reusing Existing Applications). Specifically, it discusses rules in adding and/or deleting AVPs from an existing command of an existing application. Unlike Section 4.1 (Reusing Existing Applications), the cases in this section may not necessarily result in the creation of new application(s). In some cases, there are a lot of ambiguity. So design considerations have been outlined to ease the decision making process.

4.2.1.  Adding AVPs to a command

Based on the rules in [1] (Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, “Diameter Base Protocol,” April 2010.), AVPs that are added to an existing command can be categorized into:

• Mandatory to understand AVPs. As defined in [1] (Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, “Diameter Base Protocol,” April 2010.), 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 Section 6.4 (Use of Mandatory (M-bit) flags) for details on the use of the M-bit.
  
  
• Non-mandatory AVPs that are also optional in the commands ABNF.

The rules are strict in the case where the AVPs to be added are mandatory. A mandatory AVP cannot be added to or deleted from an existing command. [1] (Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, “Diameter Base Protocol,” April 2010.) states that doing so would require the definition of a new application. This falls into the "Invasive" category described in Section 4 (Rules on Extending Diameter). 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:

• Do the AVPs change the state machine of the application ?
  
  
• Would the presence of the AVPs cause additional message round-trips; effectively changing the state machine of the application ?
  
  
• Will the AVP be used to fulfill new required functionality ?
  
  
• Would the AVP be used to differentiate between old and new versions of the same application ?
  
  
• Will it have duality in meaning; i.e., be used to carry application related information as well as be used to indicate that the message is for a new application ?

If one or more of the above conditions are true, the AVP is considered mandatory. These questions are not comprehensive in any way, but in all cases the semantics of the application must change to justify the use of mandatory AVPs.

The rules are less restrictive when adding non-mandatory, optional AVPs. This falls into the "Minimal" category described in Section 4 (Rules on Extending Diameter). 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:

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

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 (Adding AVPs to a command).

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] (Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, “Diameter Base Protocol,” April 2010.), deletion of mandatory AVP would require the definition of a new application since it dictates changes in the behavior and semantics of an application.

Instead of deleting 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 [1] (Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, “Diameter Base Protocol,” April 2010.)) where they are being used by many different applications.

The deletion of an optional AVP may not necessarily require the allocation of a new application. Deletion of non-mandatory optional AVPs with a zero(0) minimum occurrence in the commands ABNF would not require a new application. The case where an optional AVP has a minimum occurrence of at least one(1) is unusual and not allowed in [1] (Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, “Diameter Base Protocol,” April 2010.). However, there may be existing applications that do not follow the new restrictions in [1] (Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, “Diameter Base Protocol,” April 2010.). 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.

In other cases, it is recommended that application designers reuse the command ABNF without modification and simply ignore (but not delete) any optional AVP that will not be used. This is to maintain compatibility with existing applications that will not know about the new functionality as well as maintain the integrity of existing dictionaries.

4.3.  Reusing Existing AVPs

This section deals with even more granularity than Section 4.1 (Reusing Existing Applications) and Section 4.2 (Reusing Existing 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 Section 4 (Rules on Extending Diameter) and require definition of a new application. Note that designers should consider Section 5.2 (Justifying the Allocation of Application-Id) when contemplating on these types of changes.

Typically, the data types of the AVPs in question are scalar in nature and each ordinal value represent a specific semantic behavior of the application. An example is the CC-Request-Type AVP of [4] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.). Adding, deleting or modifying known values of this AVP can modify the behavior of the application itself, and additionally, the mandatory and optional AVPs rules are inherited from Section 4.2 (Reusing Existing Commands). So this affects the decision for defining new applications as well.

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 Section 6.4 (Use of Mandatory (M-bit) flags).

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] (3GPP, “IMS Cx and Dx interfaces : signalling flows and message contents,” .) and [6] (3GPP, “IMS Cx and Dx interfaces based on the Diameter protocol; Protocol details,” .)), Sh ([7] (3GPP, “IMS Sh interface : signalling flows and message content,” .) and [8] (3GPP, “IMS Sh interface based on the Diameter protocol; Protocol details,” .)) etc.

Application design should also follow the theme of Diameter extensibility which in this case may mean the importing of existing AVPs and AVP values for any newly defined commands. In certain cases where accounting will be used, the models described in Section 6.1 (Diameter Accounting Support) should also be considered. Though some decisions may be clear, designers should also consider certain aspects of defining a new application. Some of these are described in following sections.

5.1.  Rules in Allocating new Command Codes

If the protocol design justifies the allocation of a new command code then a new application as well as a new application ID is required. One of the drawbacks of [9] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) was that it required application designers to go through a lengthy expert review process in order to be allocated with a new command code(s). This restricts designers who has to follow strict deadlines for delivering their applications. Some designers eventually reverted to sub-optimal application design to circumvent this restriction. To fix this issue, revisions introduced in [1] (Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, “Diameter Base Protocol,” April 2010.) has relaxed the process and introduced a vendor specific command code space that can be allocated on a first-come first-serve basis.

5.2.  Justifying the Allocation of Application-Id

Application designers should avoid justifying the allocation of an application ID for every new functionality or every minor change that is made to an existing application. Proliferation of applications that are very similar can lead to confusion. Application designers should always use Section 4 (Rules on Extending Diameter) 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 (Diameter Accounting Support). Existing specifications may not adhere to this rule for historical or other reasons. However, this scheme should be followed to avoid possible routing problems for these messages.

In general, when a new application has been allocated with a new application id and it also reuses existing commands with or without modifications (Sec 4.1), it must use the newly allocated application id in the header and in all relevant application id AVPs (Auth-Application-Id or Acct-Application-Id) present in the commands message body.

Additionally, application designs using Vendor-Specific-Application-Id AVP should not use the Vendor-Id AVP to further dissect or differentiate the vendor-specification application id. The Vendor-Id should also not be used as an additional input for routing or delivery of messages. In general, the Vendor-Id AVP is an informational AVP only and kept for backward compatibility reasons.

5.4.  Application Specific Session Statemachine

Section 8 of [1] (Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, “Diameter Base Protocol,” April 2010.) provides session statemachines for authentication, authorization and accounting (AAA) services. When a new application is being defined that cannot clearly be categorized into any of these services it is recommended that the application itself define its own session statemachine. The existing session statemachines defined by [1] (Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, “Diameter Base Protocol,” April 2010.) 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 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 [2] (Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, “Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction,” April 2009.) and [3] (Sun, D., McCann, P., Tschofenig, H., ZOU), T., Doria, A., and G. Zorn, “Diameter Quality of Service Application,” March 2010.).

This method can be used to resolve some of the problems described in Section 6.3 (Updating an existing Application) and Section 6.2 (Generic Diameter Extensions). 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 (Adding AVPs to a command). Such end-to-end capabilities AVPs can aid in the following cases:

• 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.
  
  
• Provide a way to further negotiate capabilities if allowed by the applications.
  
  
• 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.
  
  

Note that this list is not meant to be comprehensive.

6.  Other Design Considerations

The following are some of the design considerations that apply to a Diameter application.

6.1.  Diameter Accounting Support

Accounting can be treated as an auxiliary application which is used in support of other applications. In most cases, accounting support is required when defining new applications. However, the lack of clarity in the base protocol document has prevented easy use the base accounting messages (ACR/ACA). This document provides two(2) possible models for using accounting:

Split Accounting Model

In this model, the accounting messages will use the Diameter base accounting application ID (value of 3). The design implication for this is that the accounting is treated as an independent application, especially during diameter routing. This means that accounting commands emanating from an application may be routed separately from the rest of the other application messages. This also implies that the messages generally end up in a central accounting server. A split accounting model is a good design choice when:

• The application itself will not define its own unique accounting commands.
  
  
• The overall system architecture permits the use of centralized accounting for one or more Diameter applications.

Centralizing accounting may have advantages but there are also drawbacks. The model assumes that the accounting server can somehow differentiate received accounting messages. Since the received accounting messages can be for any application and/or service, the accounting server has to be have a method to uniquely match accounting messages with applications and/or services being accounted for. This may mean defining new AVPs, checking the presence, absence or contents of existing AVPs or checking the contents of the accounting records itself. But in general, there is no clean and generic scheme for sorting these messages. Therefore, the use of this model is recommended only when all received accounting messages can be clearly identified and sorted. For most cases, the use of Coupled Accounting Model is recommended.

Coupled Accounting Model

In this model, the accounting messages will use the application ID of the application using the accounting service. The design implication for this is that the accounting messages are tightly coupled with the application itself; meaning that accounting messages will be routed like any other application messages. It would then be the responsibility of the application server (application entity receiving the ACR message) to send the accounting records carried by the accounting messages to the proper accounting server. The application server is also responsible for formulating a proper response (ACA). A coupled accounting model is a good design choice when:

• The system architecture or deployment will not provide an accounting server that supports Diameter.
  
  
• The system architecture or deployment requires that the accounting service for the specific application should be handled by the application itself.
  
  
• The application server is provisioned to use a different protocol to access the accounting server; i.e., via LDAP, XML etc. This includes attempting to support older accounting systems that are not Diameter aware.
  
  

In all cases above, there will generally be no direct Diameter access to the accounting server.

These models provide a basis for using accounting messages. Application designers may obviously deviate from these models provided that the factors being addressed here have also been taken into account. Though it is not recommended, examples of other methods might be defining a new set of commands to carry application specific accounting records.

6.2.  Generic Diameter Extensions

Generic Diameter extensions are AVPs, commands or applications that are designed to support other Diameter applications. They are auxiliary applications meant to improve or enhance the Diameter protocol itself or Diameter applications/functionality. Some examples include the extensions to support auditing and redundancy (see [12] (Calhoun, P., “Diameter Resource Management Extensions,” March 2001.)), improvements in duplicate detection scheme (see [13] (Asveren, T., “Diameter Duplicate Detection Cons.,” August 2006.)), and piggybacking of QoS attributes (see [10] (Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and A. Lior, “Traffic Classification and Quality of Service Attributes for Diameter,” December 2009.)).

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:

• 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.
  
  
• 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.
  
  
• Tradeoffs in signaling: Designers may have to choose between the use of optional AVPs piggybacked onto existing commands versus defining new commands and applications. Optional AVPs are simpler to implement and may not need changes to existing applications; i.e., use of proxy agents. However, the drawback is that the timing of sending extension data will be tied to when the application would be sending a message. This has consequences if the application and the extensions have different timing requirements. The use of commands and applications solves this issue but the tradeoff is the additional complexity of defining and deploying a new application. It is left up to the designer to find a good balance among these tradeoffs based on the requirements of the extension.
  
  

In practice, it is often the case that the generic extensions use optional AVPs because it's simple and not intrusive to the application that would carry it. Peers that do not support the generic extensions need not understand nor recognize these optional AVPs. However, it is recommended that the authors of the extension specify the context or usage of the optional AVPs. As an example, in the case that the AVP can be used only by a specific set of applications then the specification must enumerate these applications and the scenarios when the optional AVPs will be used. In the case where the optional AVPs can be carried by any application, it is should be sufficient to specify such a use case and perhaps provide specific examples of applications using them.

In most cases, these optional AVPs piggybacked by applications would be defined as a Grouped AVP and it would encapsulate all the functionality of the generic extension. In practice, it is not uncommon that the Grouped AVP will encapsulate an existing AVP that has previously been defined as mandatory ('M'-bit set); i.e. 3GPP IMS Cx / Dx interfaces ([5] (3GPP, “IMS Cx and Dx interfaces : signalling flows and message contents,” .) and [6] (3GPP, “IMS Cx and Dx interfaces based on the Diameter protocol; Protocol details,” .)). In previous revisions of the Diameter base protocol, the Grouped AVP itself would also have to be mandatory ('M'-bit set) which defeats the purpose of a non intrusive optional AVP. This restriction has been lifted in the latest revision of the Diameter base protocol. This gives more flexibility to authors of generic extensions with regards to the use of optional Grouped AVPs.

6.3.  Updating an existing Application

An application that is being upgraded must follow the same rules mentioned Section 4 (Rules on Extending Diameter). 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 (Adding AVPs to a command)

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 (Use of Application-Id in a Message).

Acceptable techniques can be used to provide feature upgrades to existing applications. One of these is described in Section 5.5 (End-to-End Applications Capabilities Exchange).

6.4.  Use of Mandatory (M-bit) flags

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:

• AVPs appearing explicitly in an applications ABNF must have it's M-bit set. These application must have been allocated its own application-Id.
  
  
• 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 [2] (Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, “Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction,” April 2009.), [11] (Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, “Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction,” January 2009.) and [10] (Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and A. Lior, “Traffic Classification and Quality of Service Attributes for Diameter,” December 2009.).
  
  

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.

6.5.  System Architecture and Deployment

The following are some of the architecture considerations that applications designers should contemplate when defining new applications:

• 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.
  
  
• 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.
  
  
• Security Considerations. Application designers should take into account that there is no end-to-end authentication built into Diameter.
  
  
• 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.
  
  
• 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.
  
  
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.). In cases where the extensions needs to define new AVPs, it is recommended that the new AVPs be used only for this purpose.

7.  IANA Considerations

This document does not require actions by IANA.

8.  Security Considerations

This document does provides guidelines and considerations for extending Diameter and Diameter applications. It does not define nor address security related protocols or schemes.

9.  Acknowledgments

We greatly appreciate the insight provided by Diameter implementers who have highlighted the issues and concerns being addressed by this document.

10.  References

10.1. Normative References

10.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

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.