Network Working Group T. Tsou
Internet-Draft Huawei Technologies
Intended status: Informational G. Zorn
Expires: September 5, 2009 Network Zen
March 4, 2009
Session-Specific Explicit Diameter Request Routing
draft-tsou-diameter-explicit-routing-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 September 5, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Tsou & Zorn Expires September 5, 2009 [Page 1]
Internet-Draft Diameter Explicit Routing March 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes a mechanism to enable specific Diameter
proxies to remain in the path of all message exchanges constituting a
Diameter session.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The 3GPP Wireless LAN (WLAN) Access Architecture . . . . . . . 4
3.1. Maintaining the Routing Path . . . . . . . . . . . . . . . 4
4. Diameter Explicit Routing (ER) . . . . . . . . . . . . . . . . 5
4.1. Originating a request (ER-Originator) . . . . . . . . . . 5
4.2. Relaying and Proxying Requests (ER-Proxy) . . . . . . . . 8
4.3. Receiving Requests (ER-Destination) . . . . . . . . . . . 9
4.4. Diameter answer processing . . . . . . . . . . . . . . . . 10
4.5. Failover and Failback Considerations . . . . . . . . . . . 11
4.6. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . 11
4.6.1. Explicit-Path-Record AVP . . . . . . . . . . . . . . . 11
4.6.1.1. Proxy-Realm AVP . . . . . . . . . . . . . . . . . 11
4.6.2. Explicit-Path AVP . . . . . . . . . . . . . . . . . . 12
4.7. Error Handling . . . . . . . . . . . . . . . . . . . . . . 12
4.8. Example Message Flow . . . . . . . . . . . . . . . . . . . 13
5. RADIUS/Diameter Protocol Interactions . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Tsou & Zorn Expires September 5, 2009 [Page 2]
Internet-Draft Diameter Explicit Routing March 2009
1. Introduction
In the Diameter base protocol [RFC3588], the routing of request
messages is based solely on the routing decisions made by each node
along the path. Therefore, in a topology where multiple paths exist
from source to destination, there is no guarantee that all messages
relating to a given session will take the same path. In general,
this has not caused problems, but some architectures (e.g., WLAN 3GPP
IP access [TS23.234]) require that certain agents process all the
messages for a session. This document briefly reviews the target
architecture and descrbes a simple solution to the problem.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The following terms are used to define the functionality and
participants in the routing extensions described in this document.
AAA Relays
Diameter nodes in between the proxies, originator or receiver.
These nodes represent existing Diameter agents and proxies that do
not participate in ER and do not recognize Explicit-Path AVPs
ER
Explicit Routing
ER-Destination
A Diameter node which is capable of participating in an ER and
will ultimately consume the request sent by an ER-Originator
ER-Originator
A Diameter node initiating a session and sending the requests.
The ER-Originator can be any Diameter node sending a request, i.e.
client, server or proxy capable of initiating sessions and
participating in ER
ER-Proxy
A Diameter proxy participating in an ER and capable of processing
Explicit-Path AVPs
Tsou & Zorn Expires September 5, 2009 [Page 3]
Internet-Draft Diameter Explicit Routing March 2009
3. The 3GPP Wireless LAN (WLAN) Access Architecture
One example of a system requiring that certain agents (stateful
proxies, in this case) remain in the forwarding path of all session
messages is the 3GPP WLAN IP access architecture [TS23.234]. The
3GPP WLAN interworking architecture extends 3GPP services to the WLAN
access side, enabling a 3GPP subscriber to use a WLAN to access 3GPP
services.
WLAN AAA provides access to the WLAN to be authenticated and
authorised through the 3GPP system. This access control can permit
or deny a subscriber the access to the WLAN system and/or the 3GPP
system.
There are two 3GPP WLAN interworking reference models:
1. In the non-roaming case, the model includes the WLAN access
network and the 3GPP AAA server in the home network. The 3GPP
AAA server is responsible for access control as well as charging.
2. In the roaming case, the model includes the WLAN access network,
the 3GPP AAA proxy in the visited network and the 3GPP AAA server
in the home network. The 3GPP AAA server is responsible for
access control. Charging records may be generated by the AAA
proxy and/or the AAA server. The AAA proxy relays access control
and charging messages to the AAA server. The AAA proxy will also
do offline charging, if required.
The roaming case presents two problems for which the Diameter routing
mechanism described in [RFC3588] does not offer any unambiguous and
standard solution.
Network Selection
Selecting an initial message path for the Diameter session through
(possibly many) alternative visited network(s) to the home
network.
Explicit Routing
Maintaining the selected message path for all messages in the
Diameter session.
The former is outside the scope of this document; the latter is
described in detail below.
3.1. Maintaining the Routing Path
After a successful authentication, a Diameter session is established
involving (at least) the following stateful entities:
Tsou & Zorn Expires September 5, 2009 [Page 4]
Internet-Draft Diameter Explicit Routing March 2009
o The Diameter client in the WLAN AN
o A Diameter proxy (the 3GPP AAA proxy) in the visited mobile
network, and
o A Diameter server in the user's home realm.
The functions assigned to the 3GPP AAA proxy include:
o Reporting charging information to the offline charging system in
the visited network
o Policy enforcement based on roaming agreements
o Service termination initiated by the visited network operator
These functions all require that state be maintained within the
visited network. The 3GPP choice is to maintain that state at the
3GPP AAA proxy. This means that the latter must remain in the
messaging path for all subsequent messages relating to the same
session.
4. Diameter Explicit Routing (ER)
This section outlines a Diameter ER mechanism by which Diameter nodes
participating in ER can remain in the path of all request messages
for a specific session. A new Explicit-Path AVP is defined to enable
ER participants to manipulate the Destination-Host and/or
Destination-Realm AVPs of request messages in order to esure the
correct routing behavior.
The following sections describe the extensions to the request routing
in [RFC3588] to implement the ER mechanism. The proposed extensions
utilize existing routing strategies in [RFC3588] and do not mandate
modifications to it. The scheme also differs from existing strict
source routing schemes in which all hops in the path have to
participate. In the ER mechanism, only Diameter nodes interested in
participating in the ER scheme will be involved in it.
4.1. Originating a request (ER-Originator)
A Diameter node acting as an ER-Originator for a particular session
MUST maintain a local cache which enumerates all the Diameter
identities of the ER-Proxies that the request messages must traverse
along the path to the ER-Destination. The identity of a Diameter
node is defined in [RFC3588]. The local cache may also include the
node's realm. The data structure of the cache is left up to the
Tsou & Zorn Expires September 5, 2009 [Page 5]
Internet-Draft Diameter Explicit Routing March 2009
implementation and should persist as part of the session attributes
or properties.
An ER-Originator sending request messages MUST add an Explicit-Path
AVP to these requests. The contents of the cache SHOULD be used to
populate the Explicit-Path AVP where each cached entry is represented
by a corresponding instance of the Explicit-Path-Record AVP. ER-
Proxies along the path of the request message MUST examine the
contents of the Explicit-Path AVP and make routing adjustments based
on records it contains. An example of the message flow is shown in
Section 4.8. Note that the ER-Originator can be any Diameter node,
i.e. client, server or proxy.
The ER-Proxy identities enumerated in the local cache SHOULD be
maintained in the same order as that in which they are traversed
along the request routing path from the originator to destination.
The corresponding Explicit-Path-Record AVP instances SHOULD be
enumerated in that same order in the Explicit-Path AVP.
The ER-Originator can populate the cache either by pre-configuring
its contents or by using the first request message of the session to
gather identities of participating ER-Proxies along the routing path.
The latter scheme is known as Explicit-Path discovery. The contents
of the cache can be pre-configured if the ER-Originator has explicit
knowledge of the ER-Proxies the request messages must traverse;
otherwise it can use Explicit-Path discovery. It is recommended that
Explicit-Path discovery be used whenever possible since pre-
configuration is less flexible by nature.
Explicit-Path discovery can be used if the identities of the ER-
Proxies are not known or if there are several ER capable proxies (a
cluster of proxies) that can be dynamically chosen based on other
routing policies. In Explicit-Path discovery, the cache of the ER-
originator is initially empty. When the ER-Originator sends the
first request message of a session, the Explicit-Path AVP will
contain only one Explicit-Path-Record AVP with the identity and/or
the realm of the ER-Originator. The Destination-Host and/or
Destination-Realm AVP of the request message is set to the identity
and/or the realm of the ER-Destination respectively as specified in
[RFC3588]. It should be noted that ER-Originator initial request
message routing steps and the Destination-Realm population MAY be
affected by the User-Name AVP NAI decoration [RFC4282]. NAI
decoration is a form of request message source routing and defines
realms that the request message must traverse through before routing
towards the ER-Destination. Diameter nodes participating to the
request message routing must examine and process the User-Name AVP,
and modify the Destination-Realm AVP accordingly as long as there are
realms left in the decorated NAI. Source routing based upon NAI
Tsou & Zorn Expires September 5, 2009 [Page 6]
Internet-Draft Diameter Explicit Routing March 2009
decoration does not affect the Explicit-Path discovery as defined in
this document.
When the request message is received and processed by an ER-Proxy,
the ER-Proxy MUST append a new Explicit-Path-Record containing its
own identity and/or realm to the Explicit-Path AVP prior to
forwarding the message. Subsequent ER-Proxies along the path that
wish to participate in the ER MUST also append their own Explicit-
Path-Record in the same manner (Section 4.2). When the request
reaches the ER-Destination, it MUST append a new Explicit-Path-Record
to the Explicit-Path AVP in a similar manner. The ER-Destination
MUST copy the resulting Explicit-Path AVP to the answer message
(Section 4.3). Once the answer message reaches the ER-Originator,
the Explicit-Path AVP will contain one or more Explicit-Path-Records
containing the ER-Originator's identity, the identities of all
participating ER-Proxies and the identity of the ER-Destination. The
ER-Originator SHOULD populate its local cache with the contents of
the Explicit-Path AVP received in this initial answer message.
If the answer message does not contain an Explicit-Path AVP or the
Result-Code AVP is set to Diameter_ER_NOT_AVAILABLE (Section 4.7), it
is an indication to the ER-Originator that the destination of the
request does not support ER and that the ER-Originator SHOULD avoid
sending an Explicit-Path AVP in subsequent request messages.
If, after performing Explicit-Path discovery, the Explicit-Path AVP
in the answer message contains only the Explicit-Path-Record of the
ER-Originator and ER-Destination then this SHOULD be an indication to
the ER-Originator that there are no Diameter proxies capable of
participating in ER along the path and that the ER-Originator may
avoid sending an Explicit-Path AVP in subsequent request messages.
Certain failover situations MAY cause this indication as described in
Section 4.5. In such cases, the situation maybe transient and
subsequent Explicit-Path discovery in succeeding sessions may find
participating proxies. It is left up to the ER-Originator to decide
if subsequent Explicit-Path discovery should be attempted in
succeeding sessions.
Once the ER-Originator's local cache has been populated, whether by
pre-configuration or through Explicit-Path discovery, all request
messages for the session MUST include the Explicit-Path AVP using the
contents of the local cache. The Explicit-Path AVP MUST contain the
Explicit-Path-Records of all the nodes enumerated in its cache except
its own. The identities enumerated in the Explicit-Path AVP MUST
appear in the order they will be traversed in the routing path. The
last entry in the Explicit-Path AVP MUST be the Explicit-Path-Record
of the ER-Destination. In addition, the value of the Destination-
Host and/or Destination-Realm AVP of the request messages MUST be set
Tsou & Zorn Expires September 5, 2009 [Page 7]
Internet-Draft Diameter Explicit Routing March 2009
to the value of the Proxy-Host and/or Proxy-Realm of the first
Explicit-Path-Record AVP present in the Explicit-Path AVP. This
ensures that the ER-Originator as well as any AAA relays in between
the ER-Originator and the first ER-Proxy will route the message
towards the first ER-Proxy as specified in RFC3588 [RFC3588].
Subsequent actions taken by the first ER-Proxy upon receipt of the
message are described in Section 4.2 and will mimic those of the ER-
Originator.
Answer messages received by the ER-Originator to subsequent request
messages after the ER path has been established SHOULD NOT have an
Explicit-Path AVP. Otherwise, this SHOULD be considered a suspect
condition that may be caused by a misbehaving ER participant. It is
left up to the ER-Originator whether to continue using the ER scheme
when such a condition arises or to attempt another Explicit-Path
discovery on subsequent sessions.
4.2. Relaying and Proxying Requests (ER-Proxy)
The basic action taken by an ER-Proxy upon receiving a request is to
check whether explicity routing is supported in the request and if
so, check whether it is already a participant in explicit routing for
the said request. If it is an existing participant, the ER-Proxy
MUST pop/remove the Explicit-Path-Record AVP pertaining to itself
from the Explicit-Path AVP and then use the next Explicit-Path-Record
AVP for subsequent routing. Details of this operation are as
follows.
An ER-Proxy is not required to keep local state or cache state
regarding the explicit routing procedure. However, it MUST check
whether an incoming request contains an Explicit-Path AVP.
1. If an incoming request does not contain an Explicit-Path AVP then
it MUST process and forward the request as specified in
[RFC3588].
2. If the incoming request contains an Explicit-Path AVP, it MUST
check whether its identity is present in the Explicit-Path AVP.
Determining whether its identity is present can be done by
matching its identity to the Proxy-Host AVPs contained in each
Explicit-Path-Record.
A. If its identity is not present and it wishes to participate
in explicit routing, it MUST append a new Explicit-Path-
Record as the last AVP in the Explicit-Path AVP prior to
forwarding the request. The new Explicit-Path-Record MUST
contain at the least a Proxy-Host AVP set to the proxy's
identity. This scenario is part of the Explicit-Path
Tsou & Zorn Expires September 5, 2009 [Page 8]
Internet-Draft Diameter Explicit Routing March 2009
discovery scheme described in Section 4.1.
B. However, if its identity is not present and the ER-Proxy does
not wish to participate in the ER, it SHOULD not modify the
Explicit-Path AVP and simply forward the request as specified
in [RFC3588] using the existing value of Destination-Host
and/or Destination-Realm AVP. Non ER-proxies and relays that
do not support ER and do not recognize Explicit-Path AVP will
take the same action.
C. If the identity of the ER-Proxy is present in the Explicit-
Path AVP, then it MUST be the first Explicit-Path-Record in
the AVP; otherwise, this SHOULD be considered an error and an
answer message with the e-bit set and the Result-Code set to
Diameter_INVALID_PROXY_PATH_STACK must be sent back to the
ER-Originator (Section 4.7). If the identity of the ER-Proxy
matches the first Explicit-Path-Record, the ER-Proxy MUST
remove this record from Explicit-Path AVP and set the
Destination-Host and/or Destination-Realm AVP to the next
Explicit-Path-Record present in the Explicit-Path AVP.
Setting the Destination-Host and/or Destination-Realm AVP
will ensure that the ER-Proxy as well as all AAA relays in
between the current ER-Proxy and the next ER-Proxy enumerated
in the Explicit-Path AVP will route the message towards the
next ER-Proxy. The process of removing the ER-Proxies record
is similar to removing an entry in a stack represented by the
Explicit-Path AVP.
Note that in the case of the ER-Destination, the Explicit-Path AVP
MUST be empty once its own record is removed (Section 4.3). Note
also that the behavior specified above applies to a Diameter node
acting as a relay agent and participates in the ER scheme.
4.3. Receiving Requests (ER-Destination)
A Diameter node that locally processes requests sent by the ER-
Originator (Section 4.1) and is able to support ER MUST check for the
presence of an Explicit-Path AVP in the request message.
1. If an incoming request does not contain an Explicit-Path AVP then
it is an indication that messages belonging to this session will
not use ER. It SHOULD process the request for local consumption
and formulate an answer message as specified in [RFC3588].
2. If the incoming request contains an Explicit-Path AVP, it MUST
check whether its identity is present in the Explicit-Path AVP.
Tsou & Zorn Expires September 5, 2009 [Page 9]
Internet-Draft Diameter Explicit Routing March 2009
A. If its identity is not present in the Explicit-Path and it
wishes to participate in the ER, it MUST append a new
Explicit-Path-Record to the Explicit-Path AVP in the received
message. The new Explicit-Path-Record MUST contain at the
least a Proxy-Host AVP set to the ER-Destinations identity.
The ER-Destination MUST then copy the resulting Explicit-Path
AVP to the subsequent answer message. This scenario is part
of the proxy path discovery scheme described in Section 4.1.
B. If its identity is not present in the Explicit-Path and it
wishes to participate in the ER, it MUST append its a new
Explicit-Path-Record in the Explicit-Path AVP. The new
Explicit-Path-Record MUST contain at the least a Proxy-Host
AVP set to the ER-Destinations identity. The ER-Destination
MUST then copy the resulting Explicit-Path AVP to the
subsequent answer message. This scenario is also part of the
proxy path discovery scheme described in Section 4.1.
C. If its identity is not present and the ER-Destination
supports ER but does not wish to or cannot participate, it
MAY send a Result-Code AVP set to Diameter_ER_NOT_AVAILABLE
as defined in Section 4.7. The ER-Destination SHOULD NOT
include any Explicit-Path AVP in the subsequent answer. The
same scenario applies to ER-destinations that does not
support ER and do not recognize Explicit-Path AVP and is a
hint to the ER-Originator that the destination does not
support ER.
D. If the identity of the ER-Destination matches a record in the
Explicit-Path AVP, then it MUST be the only Explicit-Path-
Record present in the Explicit-Path AVP otherwise, this
SHOULD be considered an error and an answer message with the
'E' bit set and containing an Experimental-Result-Code AVP
with the set to Diameter_INVALID_PROXY_PATH_STACK MUST be
sent back to the ER-Originator (Section 4.7). If the
identity of the of the ER-Destination matches the only
existing Explicit-Path-Record, then this is an indication of
a successful ER. The ER-Destination SHOULD NOT copy the
Explicit-Path AVP into the subsequent answer message.
4.4. Diameter answer processing
The Diameter nodes participating in ER do not require special
handling or routing of answer messages. Answer messages SHOULD be
processed normally as specified in [RFC3588]. However, a Diameter
node acting as an ER-Destination MUST formulate a proper Explicit-
Path AVP in answer messages as described in Section 4.3.
Tsou & Zorn Expires September 5, 2009 [Page 10]
Internet-Draft Diameter Explicit Routing March 2009
4.5. Failover and Failback Considerations
If there is no ER-Proxy along the selected path, the answer message
will contain an Explicit-Path AVP that contains only the Explicit-
Route-Records of the ER-Originator and the ER-Destination, indicating
that there is no ER support found in Diameter nodes along the path.
It is left to the ER-Originator to continue with processing of the
request without ER support or terminate the session. The ER-
Originator SHOULD NOT attempt to perform Explicit-Path discovery in
subsequent request messages of the session in such cases so as to
protect against failback conditions where an ER-Proxy may suddenly
appear in the path and attempts to add a new Explicit-Path-Record for
request messages other than the initial request. However, based on
certain policy, it is also possible for the ER-Originator to attempt
Explicit-Path discovery in subsequent sessions.
If a failover occurs in a Diameter node preceding an ER-Proxy when
the ER path is already established, it is possible that an
Diameter_UNABLE_TO_DELIVER error will be received by the ER-
Originator if there no other alternative path towards the ER-proxy.
In such a case, it is left to the ER-Originator to handle the error
as specified in Diameter application or in [RFC3588].
4.6. Attribute-Value Pairs
The following sections define the AVPs used in the ER process. All
of these AVPs MUST have the 'V' bit set and the 'M' bit cleared, with
the Vendor-ID field set to 2011.
4.6.1. Explicit-Path-Record AVP
The Explicit-Path-Record AVP (AVP Code 35001) is of type Group. The
identity added in the Proxy-Host [RFC3588] element of this AVP MUST
be the same as the one advertised by the Diameter node in the Origin-
Host AVP during the Capabilities Exchange messages.
Explicit-Path-Record ::= < AVP Header: 35001 >
{ Proxy-Host }
[ Proxy-Realm ]
4.6.1.1. Proxy-Realm AVP
The Proxy-Realm AVP (AVP Code 35002) is of type DiameterIdentity, and
contains the realm of the ER node inserting the record.
It is recommended that the Proxy-Host AVP be present and used to
uniquely identify an ER-Proxy within the AAA realm being traversed by
a request. Otherwise, ER will need to rely on realm routing. Realm
Tsou & Zorn Expires September 5, 2009 [Page 11]
Internet-Draft Diameter Explicit Routing March 2009
routing would require a well-known topology for the ER scheme to work
properly since the hostname of the proxy is not specified. In such a
case, the Proxy-Realm AVP MUST be present and is used to identify the
ER-Proxy of the realm.
When a Proxy-Host AVP is present in the Explicit-Path-Record AVP, the
realm name included in the hostname MUST correspond to the identity
present in the Proxy-Realm AVP.
4.6.2. Explicit-Path AVP
The Explicit-Path AVP (AVP Code 35003) is of type Grouped. This AVP
SHOULD be present in all request and answer messages performing ER.
Explicit-Path ::= < AVP Header: 35003 >
1* [ Explicit-Path-Record ]
* [ AVP ]
This AVP MAY be sent with the default AVP flags settings defined in
Sec 4.1 of [RFC3588] where 'M' bit MUST be set and 'V' bit MUST NOT
be set. If the 'M' bit is set then the recommendations in Sec 4.1 of
[RFC3588] regarding preservation of interoperability SHOULD be
followed.
4.7. Error Handling
The following error conditions may occur during ER processing. All
error indications MUST be encapsulated in an instance of the
Experimental-Result AVP [RFC3588] with the Vendor-Id AVP set to 2011
and the Experimental-Result-Code set as specified below.
DIAMETER_INVALID_PROXY_PATH_STACK 3501
A request message received by an ER-Proxy or ER-Destination after
an ER path has been established has the first or only Explicit-
Path-Record AVP not matching the ER-Proxy or the ER-Destinations
identity. The same error applies to ER-Destinations receiving a
Explicit-Path-AVP containing more than one Explicit-Path-Record or
an Explicit-Path-AVP with only one Explicit-Path-Record not
matching its own identity.
This error SHOULD be considered a protocol failure and SHOULD be
treated on a per-hop basis; Diameter proxies may attempt to
correct the error, if possible. Diameter answer messages
containing this error indication MUST have the 'E' bit set and
MUST confom to Section 7.2 of [RFC3588].
Tsou & Zorn Expires September 5, 2009 [Page 12]
Internet-Draft Diameter Explicit Routing March 2009
DIAMETER_ER_NOT_AVAILABLE 4501
An ER-Destination which supports ER routing but is unable to
comply for unknown reasons MAY send an answer message with the
Result-Code AVP set to this error code. This error value SHOULD
be considered a transient failure indicating that subsequent ER
attempts may succeed.
4.8. Example Message Flow
The example presented here illustrates the flow of Diameter messages
with the typical attributes present in the ER scenario.
The ER-Originator in the example below shows the use of Explicit-Path
discovery with the first request. However, the ER-Originator may
also use a pre-configured cache. The ER-Originator can be any
Diameter node sending a request, i.e. client, server or proxy. In
this scenario, the local cache of the ER-Originator is initially
empty.
The AAA relays in between the ER-Proxies, ER-Originator and ER-
Destination may or may not be present and are shown here to depict
routing paths that the requests may take prior to being processed by
nodes participating in the ER scheme. The AAA relays also depict
existing Diameter relays or proxies that do not recognize Explicit-
Path AVPs and therefore do not participate in ER.
ER- ER- ER- ER-
Originator AAA relays proxy1 AAA relays proxy2 Destination
(o.realm1 (p.realm1 (p.realm2 (d.realm2
.com) .com) .com) .com)
| | | | |
cache=(empty) | | | | |
------------->|--------->| | | |
(1st request of the session)| | | |
Explicit-Path= | | | |
record1=o.realm1.com,reaml1.com | | |
dest-host=d.realm2.com | | | |
dest-realm=realm2.com | | | |
| | | | |
| |--------->|--------->| |
| | (forwarded request)| |
| | Explicit-Path= | |
| | record1=o.realm1.com,reaml1.com
| | record2=p.realm1.com,realm1.com
| | dest-host=d.realm2.com |
| | dest-realm=realm2.com |
| | | | |
| | | |--------->|
Tsou & Zorn Expires September 5, 2009 [Page 13]
Internet-Draft Diameter Explicit Routing March 2009
| | | (forwarded request)
| | | Explicit-Path=
| | | record1=o.realm1.com,
| | | realm1.com
| | | record2=p.realm1.com,
| | | realm1.com
| | | record3=p.realm2.com,
| | | realm2.com
| | | dest-host=d.realm2.com
| | | dest-realm=realm2.com
| | | | |
cache= |<---------|<---------|<---------|<---------|
record1=o.realm1.com,realm1.com (answer) |
record2=p.realm1.com,realm1.com Explicit-Path=
record3=p.realm2.com,realm2.com record1=o.realm1.com,realm1.com
record4=d.realm2.com,realm2.com record2=p.realm1.com,realm1.com
| | record3=p.realm2.com,realm2.com
| | record4=d.realm2.com,realm2.com
Note: An originator pre-configuring | | |
its local cache can skip the | | |
exchange above and send the | | |
initial request as shown below | | |
| | | | |
------------->|--------->| | | |
(subsequent request of the session) | | |
Explicit-Path= | | | |
record1=p.realm1.com,realm1.com | | |
record2=p.realm2.com,realm2.com | | |
record3=d.realm2.com,realm2.com | | |
dest-host=p.realm1.com | | | |
dest-realm=realm1.com | | | |
| |--------->|--------->| |
| | (forwarded request)| |
| | Explicit-Path= | |
| | record1=p.realm2.com,realm2.com
| | record2=d.realm2.com,realm2.com
| | dest-host=p.reaml2.com |
| | dest-realm=realm2.com |
| | | | |
| | | |--------->|
| | | (forwarded request)
| | | Explicit-Path
| | | record1=d.realm2.com,
| | | realm2.com
| | | dest-host=d.realm2.com
| | | dest-realm=realm2.com
| | | | |
cache= |<---------|<---------|<---------|<---------|
Tsou & Zorn Expires September 5, 2009 [Page 14]
Internet-Draft Diameter Explicit Routing March 2009
record1=o.realm1.com,realm1.com (answer) | |
record2=p.realm1.com,realm1.com * no Explicit-Path-AVP present
record3=p.realm2.com,realm2.com | | |
record4=d.realm2.com,realm2.com | | |
| | | | |
| | | | |
(subsequent request of the session will repeat the process above)
| | | | |
| | | | |
Figure 1: Example ER Message Flow
5. RADIUS/Diameter Protocol Interactions
No actions need to be taken with regards to RADIUS/Diameter
interaction. The routing extension described in this document is
transparent to any translation gateway and relevant only to Diameter
routing. The assumption is that if there is a RADIUS proxy chain
between Diameter translation agents the route between translation
agents remains stable during the session and does not cause an
invalidation of the proxy path stack.
6. IANA Considerations
Because this document defines only vendor-specific AVPs, no IANA
actions are necessary.
7. Security Considerations
The extension described in this document does not create any new
vulnerabilities in the Diameter protocol.
8. Acknowledgements
The authors gratefully acknowledge the contributions of: Avi Lior,
Tony Zhang, Tom Taylor, Fortune Huang and Rajith R.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Tsou & Zorn Expires September 5, 2009 [Page 15]
Internet-Draft Diameter Explicit Routing March 2009
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
9.2. Informative References
[TS23.234]
3GPP, "3GPP system to Wireless Local Area Network (WLAN)
interworking; System description", TS 23.234 Version
7.4.0, 2006.
Authors' Addresses
Tina Tsou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: tena@huawei.com
Glen Zorn
Network Zen
1310 East Thomas Street
#306
Seattle, Washington 98102
USA
Phone: +1 (206) 377-9035
Email: gwz@net-zen.net
Tsou & Zorn Expires September 5, 2009 [Page 16]