Diameter Maintanence and V. Fajardo, Ed. Extensions (DIME) Toshiba America Research Inc. Internet-Draft T. Asveren, Ed. Intended status: Informational Ulticom Inc. Expires: August 29, 2007 H. Tschofenig Siemens Networks GmbH & Co KG G. McGregor Alcatel-Lucent J. Loughney Nokia Research Center February 25, 2007 Diameter Applications Design Guidelines draft-fajardo-dime-app-design-guide-00.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 August 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The Diameter Base protocol provides rules on how to extend Diameter Fajardo, et al. Expires August 29, 2007 [Page 1] Internet-Draft Diameter Applications Design Guidelines February 2007 and to create new Diameter applications. This is a companion document to clarify these rules. This document does not intended to add, remove or change these rules, rather it helps protocol designers to extend Diameter. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Diameter Application Model . . . . . . . . . . . . . . . . . . 3 4. Rules on Diameter Extensibility . . . . . . . . . . . . . . . 4 4.1. How to Extend Diameter . . . . . . . . . . . . . . . . . . 4 4.2. When to Define New Applications . . . . . . . . . . . . . 5 5. Application Design Considerations . . . . . . . . . . . . . . 6 5.1. Extending Existing Applications . . . . . . . . . . . . . 7 5.2. Accounting Support . . . . . . . . . . . . . . . . . . . . 9 5.3. Generic Diameter Extensions . . . . . . . . . . . . . . . 9 5.4. Use of Application-Id in a Message . . . . . . . . . . . . 10 5.5. Updating an existing Applications . . . . . . . . . . . . 10 5.6. Use of optional AVPs . . . . . . . . . . . . . . . . . . . 11 5.7. Extending Existing Commands . . . . . . . . . . . . . . . 11 5.8. Documenting Command Contents . . . . . . . . . . . . . . . 11 5.9. Use of Application Layer Timers . . . . . . . . . . . . . 11 5.10. Support for Redundancy . . . . . . . . . . . . . . . . . . 11 5.11. AAA Considerations . . . . . . . . . . . . . . . . . . . . 12 5.12. Diameter User Sessions and Server Initiated Requests . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Fajardo, et al. Expires August 29, 2007 [Page 2] Internet-Draft Diameter Applications Design Guidelines February 2007 1. Introduction The Diameter Base protocol document defines guidelines on how one would extend Diameter and create new Diameter applications (see Section 1.2 of [1]). By themselves, these guidelines are not necessarily 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 where protocol 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 in which both applications are no longer interoperable in certain conditions. With this in mind, the intent of this document is to influence ongoing and future Diameter application design by providing the following content: o Clarify existing Diameter extensibility rules present 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 when defining new applications. o Present tradeoffs of design choices. Please note that it is not always possible to offer a concise and unique answer to certain design choices. There is, however, the believe that at a minimum, this document can be used as a guide to Diameter extensibility. 2. Terminology This document reuses the terminology used in [1]. 3. 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 falls more inline with a Diameter node having an application layer and a peer-to-peer delivery layer. The Diameter Base protocol document completely defines the Fajardo, et al. Expires August 29, 2007 [Page 3] Internet-Draft Diameter Applications Design Guidelines February 2007 architecture and behavior of the peer-to-peer delivery layer and then provides the framework for designing Diameter applications for the application layer. This framework includes definitions of user sessions and accounting support (see Section 8 and 9 of [1]) whose usage is the focus of this document. The remainder of this document also treats a Diameter node a single instance of a Diameter transport layer and one or more Diameter applications that uses it. 4. Rules on Diameter Extensibility 4.1. How to Extend Diameter The current rules for extending Diameter are specified in Section 1.2 of [1]. Diameter can be extended in the following ways: o Create new AVPs or new AVP values This implies that you can use this extensibility method in the following scenario: Add a new AVP to an existing application to either change its current semantic This generally requires that the new AVP is mandatory to be understood and interpreted by the new semantics. This means M-bit is set and most likely the new AVP is required to exists in command ABNF of the modified application. This also implies that a new application ID would need to be allocated. Add a new AVP value to an to an existing AVP in an application to change the applications current semantic In this case, it is implied that the AVP has the same properties as the first criteria above where the affected AVP is mandatory and required to be understood (M-bit set). Add a new AVP or a new AVP value to an existing AVP without changing the application semantic In this case, it is a less disruptive extension and it is implied that the AVP is optional. This also implies that it does not require its M-bit to be set. Thus, it will not require the allocation of a new application ID. The difficult engineering decision with these rules is when there is an intersection between any of the criteria above, i.e., when it's not clear how much influence the new AVP or new AVP values Fajardo, et al. Expires August 29, 2007 [Page 4] Internet-Draft Diameter Applications Design Guidelines February 2007 has in the semantics of the existing application to justify whether a new application has to be defined. Some of the design considerations regarding this are discussed in Section 5.1. o Creation of a new application with new command code The rules are well known in this case. There is no ambiguity about the decision to create a new application, a new set of command(s) and/or a new set of AVPs. Though some decisions maybe clear, designers should also consider aspects of the application itself. Some of these are described in Section 5. If accounting is to be used, then models described in Section 5.2 should be considered. 4.2. When to Define New Applications It is worthwhile noting that the rules defined in Section 1.2 of [1] had an assumption that there will be a small number of Diameter applications that would exist and that these applications mainly revolve around AAA functionality, i.e., as the next generation RADIUS. Therefore, the general theme of Diameter extensibility is to reuse AVPs, AVP values, commands and applications as much as possible. Despite the current proliferation of Diameter applications beyond AAA, the theme of reuse is still very relevant and it should be applied. As a rule, the fundamental reason to create a new application from an existing application is when there will be major changes to the application in question. The general criteria for a major change are, as taken from Section 1.2.3 [1]: o The changes require that a new AVP will be added to the command which have its "M" bit set. As described in Section 4.1, this means that the new AVP has to be understood, interpreted and used by the application to fall into this criteria. This also means that AVP introduces a new behavior in the application that changes it fundamentally. In some cases, however, it can be difficult to come to a conclusion whether the new AVP should have its M-bit set. o The changes require an existing command now has a different number of round trips to satisfy a request. This means the application is now required to send multiple messages exchanges in sequence using the same command. In general, it could also apply to multiple message exchanges with the same command staggered across the lifetime of the session. In all cases, this requires a fundamental change in the behavior of the application. Fajardo, et al. Expires August 29, 2007 [Page 5] Internet-Draft Diameter Applications Design Guidelines February 2007 o Requiring the addition of a new command. Typically, the decision that result in the definition a new command is clear and the criteria in Section 4.1 can be applied with little ambiguity. Application designers should also consult Section 5 so as not to rely too much in defining new commands for every new functionality. Note that these rules are explicit taken as is and would result in the allocation of new application IDs. The allocation of application IDs specified in Section 1.2.3 of [1] says: "In order to justify allocation of a new application identifier, Diameter applications MUST define one Command Code, or add new mandatory AVPs to the ABNF." In some cases the above-mentioned rules are not entirely obvious to apply. For example, an application has been updated and a newer version of the application now supports some feature that falls into one of the criteria above. Fundamentally, it is the same application with some new features but it is now required to be allocated a new application ID. It can be argued that this is an inappropriate or inefficient allocation of application IDs since application identifiers are being used for version control. A discussion about versioning pitfalls are discussed in detail in Section 5.5. Other pitfalls arise when there is a tendency by protocol designers to keep adding optional AVPs to an existing command so they can circumvent the M-bit criteria. This generally results in interoperability problems since there will be many interpretations of the application depending on which optional AVPs are present. Examples of this problem are discussed in Section 5.6. 5. Application Design Considerations There are multiple ways of extending Diameter and they fall into the following categories: Creation of a completely new Diameter application More than likely, this means the new application has a use case where there is no existing Diameter application that provides such functionality, even partially. Hence, the allocation of command code(s), AVP(s) and application ID is reasonable. The application design should also consider the use of accounting, if required. Fajardo, et al. Expires August 29, 2007 [Page 6] Internet-Draft Diameter Applications Design Guidelines February 2007 Extending an existing Diameter Application Typically, this would mean that a new Diameter application reuses parts of the functionality of the existing application. It could also mean that an existing application needs to be used in a different scenario not envisioned by its original designers. In either case, this has a very broad scope in terms of how much to reuse or how much changes is introduced and how it will affect existing functionality. Diameter Accounting Support Accounting is a special case Diameter application in the sense that it is used by other Diameter applications. One problem that has prevented easy usage of accounting was the lack of clarity in the Diameter Base protocol. It is further complicated by the fact that Diameter applications, which supported accounting, had different interpretations on how to use it. Section 5.2 provides some models for accounting support and pitfalls that current Diameter applications have encountered when using accounting. Generic Diameter Extensions These generic extensions aim to be available to all applications by either enhancing the Diameter Base protocol message delivery layer or the application layer framework. Examples include the generic support for auditing and redundancy, as described in [2], and improved duplicate detection, as described in [3]. More discussion on this topic can be found in Section 5.3. 5.1. Extending Existing Applications There are several factors to be considered when extending existing Diameter applications. Some of the major factors include: Message Routability It is essential to route the messages to an end point that is able to process them. If the extension does not add new mandatory functionality, end points that are able to handle messages for the extended application can process them as well. New mandatory functionality manifests itself as an addition of a new command, a new AVP with M-bit set or change in the application processing. Although the standard way of routing messages without the Destination-Host AVP is to make use of the Application-Id and the Destination-Realm AVP, for certain cases, the value and/or absence/presence of some other AVP may be utilized as well. Fajardo, et al. Expires August 29, 2007 [Page 7] Internet-Draft Diameter Applications Design Guidelines February 2007 Network Maintainability It is preferable to avoid/limit changes in the network topology due to extension of an application. Backward Compatibility Extensions of an application must not require changes to existing applications. This should be considered carefully when attempting to updated an existing application to a newer version (see Section 5.5). Namespace Maintainability Extensions should not require frequent updates to protocol namespaces, e.g., application identifier name space, which may lead to confusions and increase the probability for faulty provisioning. Application designers should avoid justifying the allocation of application IDs for every change that is made to an existing application. Usually it is not possible to extend an application in a way, where all these factors are satisfactorily addressed. For example if an extension introduces new mandatory functionality, allocating a new application identifier would be attractive from message routability perspective because it would not require non-standard routing procedures to be introduced. On the other hand, if similar extensions are expected in the future namespace maintainability may suffer. Typically, some of the unclear decisions comes when an existing application can be reused for a new application by simply adding a new value to an existing AVP to indicate the new purpose. Since the change seems small enough, it is not clear that it justifies the allocation of a new application ID. However, in this case, it is more preferable to allocate a new application rather than manipulate the meaning of an existing AVP since this normally leads to complex application semantics and possible interoperability problems. In general, following the rules in Section 4.2 should provide a basis on deciding when to allocate new applications. When it is clear that a new application is required, application designers should also take care in defining too many new commands or new AVPs. Existing commands and AVPs should be reused as much as possible. Fajardo, et al. Expires August 29, 2007 [Page 8] Internet-Draft Diameter Applications Design Guidelines February 2007 5.2. Accounting Support Each application should specify whether it follows the so-called "coupled" or the "split" accounting model. An indication makes it easier to decide about the routing of accounting messages by placing the appropriate Application-Id field in the message header and into the Acct-Application-Id AVP. Furthermore, accounting servers need to advertise application identifier for applications choosing split accounting model in Acct-Application-Id AVP during capability exchange procedure. The coupled accounting model relies only on Application-Id in the message header and Destination-Realm AVP value for routing messages that do not contain the Destination-Host AVP or if the host specified by the Destination-host AVP is not an adjacent node. Furthermore, the coupled accounting model requires Diameter application servers to process accounting messages in addition to the Diameter application specific messages. For the split accounting model accounting messages are routed to a separate accounting server (by considering the usage of the Acct- Application-Id AVP). This model is useful when a central accounting server is used by multiple Diameter applications. 5.3. Generic Diameter Extensions In general, generic Diameter extensions are either additional optional AVPs that are used between peer or end points for signaling non-application specific features. These features deal with functionality that is either common among applications such as auditing or used between peers for purposes like redundancy or congestion control. Extensions can also take the form of new commands or even new applications with semantics that affect other applications. When extensions use optional AVPs, a better design approach is to use a grouped AVP which encompasses all the functionality of the extension. The presence/absence of this grouped AVP may be used to indicate support for this extension. The presence of this AVP in a message should affect neither the behavior/semantics of the message nor the application using it. The design of generic extensions leading to a new application should follow the same rules described in Section 4 with no particular exceptions. In certain cases, however, the use of optional AVPs for generic extensions may not be possible if the applications specification lacks a catch all AVP rule ("* AVP" rule) in its message ABNF. Though this maybe rare and more likely due to mistakes in the Fajardo, et al. Expires August 29, 2007 [Page 9] Internet-Draft Diameter Applications Design Guidelines February 2007 application specification itself, designers should still take care in such cases. 5.4. Use of Application-Id in a Message When designing new applications, note 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 5.2. Existing specifications may not adhere to this rule for historical or other reasons but the model described in Section 3 clearly defines this rule. It is important that this scheme is followed to avoid possible routing problems for these session level messages belonging to an application. Also, as specified in [1], the application ID carried by any application ID AVP present in the message must match the application ID present in the header. With regards to Vendor-Specific- Application-Id AVP, the Vendor-Id AVP in that group normally should not be used as an additional discriminator. Given that the application ID space is flat, the Vendor-Specific-Application-Id must be treated like other application ID AVPs without regard to the Vendor-Id AVP. 5.5. Updating an existing Applications Use of a new application identifier should be the preferred way when the extension introduces completely new and mandatory functionality, e.g., defines a new command or introduces a new AVP with M-bit set. If the extension merely extends an existing functionality, e.g., introducing a new enumeration value for an existing AVP to avoid defining a new AVP is usually a better way. If that approach is used, the extension document should specify what AVP values/presence/ absence should be used to route messages to end points that support the extension. An optional AVP can also be used in the same manner to indicate version differences. If this approach is chosen, it is recommended that the optional AVP is used specifically to indicate version information only. It should not have any other purpose. Enhancements with too many optional AVPs can become unmanageable. In all cases, care should be taken as not to require changes to the existing application as it is defined and implemented. Fajardo, et al. Expires August 29, 2007 [Page 10] Internet-Draft Diameter Applications Design Guidelines February 2007 5.6. Use of optional AVPs The use of optional AVPs should be limited to optional application functionalities or generic Diameter extensions. In general, optional AVP(s) should not be used to circumvent the proper method of extending an existing application, i.e., wherein the presence/absence of the AVP(s) is used to indicate one application over another. As seen with existing specifications, this leads to unnecessary interoperability issues. Optional AVPs are meant to carry specific application data and should not be used for version control when updating applications (see Section 5.5). In general, the context of using optional AVPs should be within the boundary of application functionality only. 5.7. Extending Existing Commands When adding new AVPs to an existing command, no new mandatory AVPs, i.e., AVPs in {}, should be introduced to the command ABNF. This includes also defining an optional AVP with minimum occurrence of 1, i.e., AVPs in 1*[]. Similarly, when extending an existing command no existing mandatory AVP should be deleted. This is seen as necessary to preserve the original message semantics and to maintain integrity of dictionaries. 5.8. Documenting Command Contents Care should be taken when listing contents of the commands that are used for different scenarios with possibly different content. Either a different ABNF for each scenario or text clarifying the contents concretely for each scenario should be provided. 5.9. Use of Application Layer Timers It is common for applications to rely on timers to detect lack of a response for a previously sent request. Although the Diameter Base protocol defines a watchdog timer Tw, its use on application level is discouraged for reasons such as Tw being a hop-to-hop timer, not being able to control Tw provisioning in the whole message path, Tw timer value being common for all applications and restrictions on the provisioning limits for Tw. Applications should define application layer timers to guard against non-receipt of responses. 5.10. Support for 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 Fajardo, et al. Expires August 29, 2007 [Page 11] Internet-Draft Diameter Applications Design Guidelines February 2007 is encouraged. 5.11. AAA Considerations With the model stated in Section 3, it becomes more natural to segregate one Diameter application from another. In this case, the following considerations apply when adding new AAA functionality. Distributed Application Servers AAA services provided to a user generally require multiple different services each in different Diameter applications. Each of these services these needs to be associated with that user, e.g., authentication, authorization, accounting, MIPv6 bootstrapping, Quality of Service, Packet Filtering, etc. With the ability of the Diameter transport layer to route messages to different destinations or application server on a per-application basis, designers should take into account how such association can be accomplished. One example is that of the authentication being done is on a separate server from authorization. As an implication information about the previous authentication interaction has to be signaled to be made available to the authorization server to prevent security problems and assist during the authorization decision. In general, a distributed architecture offers greater flexibility but the tradeoff is additional complexity. It is difficult to achieve a good balance between flexibility and complexity and at the same time account for all the factors that affects or will affect an application design. Therefore, designs will typically require compromises to be built into it. Scalability It is given that there would be an increase in the total number of messages generated by Diameter applications to provide the same set of AAA services that Diameters' predecessor RADIUS generates. In RADIUS, the addition an of AVPs in a RADIUS message is sufficient to declare support for a new function. Since Diameter traffic is greater compared to RADIUS for the same set of service, care should be taken if scalability is going to be factor in the deployment of a specific Diameter application. The increased traffic generated by the Diameter applications is not a fault of the Diameter design but to accommodate features, such as reliability. From an application design standpoint, one should at least consider the number of messages exchanges Fajardo, et al. Expires August 29, 2007 [Page 12] Internet-Draft Diameter Applications Design Guidelines February 2007 necessary when designing the application as well as load and deployment scenarios. 5.12. Diameter User Sessions and Server Initiated Requests This section briefly discusses which diameter sessions (see Section 8 [1]) to use when an application requires a server entity to transmit request to a client entity. Note that a server or client entity is a function of the application and not necessarily synonymous to a Diameter client or server session. As defined in the Diameter Base protocol document, only Diameter client sessions can send requests towards a Diameter server session. To allow a server entity to send requests towards a client entity, the server entity can create Diameter client sessions and the client entity can create a corresponding Diameter server sessions. 6. IANA Considerations This document does not require actions by IANA. 7. 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. 8. Acknowledgments We greatly appreciate the insight provided by Diameter implementers who have highlighted the issues and concerns being addressed by this document. 9. References 9.1. Normative References [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 9.2. Informative References [2] Calhoun, P., "Diameter Resource Management Extensions", draft-calhoun-diameter-res-mgmt-08.txt (work in progress), March 2001. Fajardo, et al. Expires August 29, 2007 [Page 13] Internet-Draft Diameter Applications Design Guidelines February 2007 [3] 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 (editor) Ulticom Inc. 1020 Briggs Road Mount Laurel, NJ, 08054 USA Email: asveren@ulticom.com Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Phone: +49 89 636 40390 Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Glenn McGregor Alcatel-Lucent USA Email: glenn@aaa.lucent.com John Loughney Nokia Research Center USA Email: john.loughney@nokia.com Fajardo, et al. Expires August 29, 2007 [Page 14] Internet-Draft Diameter Applications Design Guidelines February 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 August 29, 2007 [Page 15]