Session-Specific Explicit Diameter Request Routing
RFC 6159
Document | Type | RFC - Informational (April 2011; No errata) | |
---|---|---|---|
Authors | Tina Tsou , Glen Zorn , Tom Taylor | ||
Last updated | 2015-10-14 | ||
Stream | ISE | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | ISE state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 6159 (Informational) | |
Action Holders |
(None)
|
||
Telechat date | |||
Responsible AD | Dan Romascanu | ||
Send notices to | (None) |
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 otherShow full document text