[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-dime-app-design-guide

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
                                                             J. Loughney
                                                   Nokia Research Center
                                                       February 25, 2007

                Diameter Applications Design Guidelines

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 29, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   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

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

   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

   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

   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

   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.


      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

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

   Email: vfajardo@tari.toshiba.com

   Tolga Asveren (editor)
   Ulticom Inc.
   1020 Briggs Road
   Mount Laurel, NJ, 08054

   Email: asveren@ulticom.com

   Hannes Tschofenig
   Siemens Networks GmbH & Co KG
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739

   Phone: +49 89 636 40390
   Email: Hannes.Tschofenig@siemens.com
   URI:   http://www.tschofenig.com

   Glenn McGregor

   Email: glenn@aaa.lucent.com

   John Loughney
   Nokia Research Center

   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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Fajardo, et al.          Expires August 29, 2007               [Page 15]

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