Session-Specific Explicit Diameter Request Routing
RFC 6159
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
Show full document text