Session-Specific Explicit Diameter Request Routing
RFC 6159

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

Independent Submission                                           T. Tsou
Request for Comments: 6159                     Huawei Technologies (USA)
Category: Informational                                          G. Zorn
ISSN: 2070-1721                                              Network Zen
                                                          T. Taylor, Ed.
                                                     Huawei Technologies
                                                              April 2011

           Session-Specific Explicit Diameter Request Routing

Abstract

   This document describes a mechanism to enable specific Diameter
   proxies to remain in the path of all message exchanges constituting a
   Diameter session.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6159.

IESG Note

   Techniques similar to those discussed in this document were discussed
   in the IETF Diameter Maintenance and Extensions (DIME) Working Group.
   The group had no consensus that the problems addressed by such work
   are a real concern in Diameter deployments.  Furthermore, there was
   no consensus that the proposed solutions are in line with the
   architectural principles of the Diameter protocol.  As a result, the
   working group decided not to undertake the work.  There has also not
   been a formal request for this functionality from any standards body.
   This RFC represents a continuation of the abandoned work.  Readers of
   this specification should be aware that the IETF has not reviewed
   this specification and cannot say anything about suitability for a
   particular purpose or compatibility with the Diameter architecture
   and other extensions.

Tsou, et al.                  Informational                     [Page 1]
RFC 6159                Diameter Explicit Routing             April 2011

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. The 3GPP Wireless LAN (WLAN) Access Architecture ................4
      3.1. Maintaining the Routing Path ...............................5
   4. Diameter Explicit Routing (ER) ..................................6
      4.1. Originating a Request (ER-Originator) ......................6
      4.2. Relaying and Proxying Requests (ER-Proxy) ..................8
      4.3. Receiving Requests (ER-Destination) .......................10
      4.4. Diameter Answer Processing ................................11
      4.5. Failover and Failback Considerations ......................12
      4.6. Attribute-Value Pairs .....................................12
           4.6.1. Explicit-Path-Record AVP ...........................12
                  4.6.1.1. Proxy-Host AVP ............................13
                  4.6.1.2. Proxy-Realm AVP ...........................13
           4.6.2. Explicit-Path AVP ..................................13
      4.7. Error Handling ............................................13
   5. Example Message Flow ...........................................14
   6. RADIUS/Diameter Protocol Interactions ..........................16
   7. Security Considerations ........................................17
   8. Acknowledgements ...............................................17
   9. References .....................................................18
      9.1. Normative References ......................................18
      9.2. Informative References ....................................18

1.  Introduction

   In the Diameter base protocol [RFC3588], the routing of request
   messages is based solely on the routing decisions made separately by
   each node along the path.  [RFC5729] has added the ability to force
   messages to pass through a specified set of realms through the use of
   Network Access Identifier (NAI) decoration.  However, no other