One document matched: draft-tsou-dime-base-routing-ext-00.txt
DIME Working Group T. Tsou
Internet-Draft Huawei
Expires: December 8, 2006 V. Fajardo
TARI
June 6, 2006
Diameter Routing Extensions
draft-tsou-dime-base-routing-ext-00
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-
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 December 8, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes two(2) an extension to the current diameter
routing scheme. The first extension describes a strict source
routing mechanism that MAY be employed by Diameter nodes to allow
stateful Diameter proxies to remain in the path of all messages
exchanges constituting a Diameter session. The second extension
describes the a realm based redirection scheme as an alternative to
host based redirection descrbied in [RFC3588].
Tsou & Fajardo Expires December 8, 2006 [Page 1]
Internet-Draft Diameter Routing Extensions June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Diameter Strict Source Routing . . . . . . . . . . . . . . 3
1.2. Redirect Realm Indication . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Diameter Strict Source Routing (SSR) . . . . . . . . . . . . . 6
3.1. Originating a request (SSR-Originator) . . . . . . . . . . 6
3.2. Relaying and Proxying Requests (SSR-Proxy) . . . . . . . . 8
3.3. Receiving Requests (SSR-Destination) . . . . . . . . . . . 9
3.4. Diameter answer processing . . . . . . . . . . . . . . . . 10
3.5. Failover and Failback Considerations . . . . . . . . . . . 10
3.6. Proxy-Path-Record AVP . . . . . . . . . . . . . . . . . . 10
3.6.1. Proxy-Realm AVP . . . . . . . . . . . . . . . . . . . 11
3.7. Proxy-Path AVP . . . . . . . . . . . . . . . . . . . . . . 11
3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11
3.9. Example Message Flows . . . . . . . . . . . . . . . . . . 12
4. Redirect Realm Indication . . . . . . . . . . . . . . . . . . 15
4.1. Redirect-Realm AVP . . . . . . . . . . . . . . . . . . . . 16
5. RADIUS/Diameter Protocol Interactions . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Tsou & Fajardo Expires December 8, 2006 [Page 2]
Internet-Draft Diameter Routing Extensions June 2006
1. Introduction
The following sections provides an overview of the routing extensions
proposed in this document.
1.1. Diameter Strict Source Routing
In [RFC3588], routing of request messages from source to the
destination is based solely on the routing decision made by each node
along the path. In a topology where multiple paths are possible from
source to destination, it is not guaranteed that all messages
constituting a session will take the same path. For a proxy node
residing along a path that maintains stateful information for a
session, it is desirable that it remains in the routing path of all
message exchanges of that a session.
In general, a session which comprises of multiple message exchanges
and requires intermediary proxy functions will require strict routing
for all request messages within that session. Consider the WLAN 3GPP
IP access [TS23.234]. The WLAN Access Network (WLAN AN) can use
Diameter EAP with the 3GPP AAA server or proxy for authentication &
authorization. In the roaming case, the WLAN AN is communicating
with a 3GPP AAA Proxy in the visited network over the Wa reference
point. The 3GPP AAA proxy is connected to the 3GPP Server in the
home network over the Wd reference point. The 3GPP AAA Proxy among
its many functions will enforce local policies on access based on
agreement with the 3GPP Home Network and with the WLAN operator. It
will also send per user charging information for the session to the
Offline Charging system. This necessitates the proxy to maintain the
session state information and hence remain in-path for the entire
session.
In [RFC3588], it is possible to use static routing between the source
and the proxy to ensure all message exchanges traverses the proxy in
question. However, static routing in general, introduces many
limitations.
o Static routing implies that all messages, regardless of session,
will have to traverse the same proxy. This introduces a single
point of failure in the routing path and affects any and all
sessions regardless of whether the session is of interest to the
proxy.
o It compromises failover procedure in the node adjacent to the
proxy and preceding it in the request forwarding path. This
becomes apparent if the adjacent node explicitly and statically
routes only towards the proxy.
Tsou & Fajardo Expires December 8, 2006 [Page 3]
Internet-Draft Diameter Routing Extensions June 2006
o In the event of more complex topologies where multiple proxies are
traversed between source and destination, the administrative
burden of static configuration along the path may be considerable.
o No provision for load balancing as all the nodes in the path will
be subjected to static routing.
Considering these limitations, an alternative and more dynamic method
of establishing a strict route is proposed.
1.2. Redirect Realm Indication
The redirect process in [RFC3588] describes a diameter client
receiving a redirect indication in the answer message which contains
one or more Redirect-Host AVP(s). This allows the diameter client to
forward the request to an alternative destination. This document
describes a mechanism by which the client MAY perform request routing
on upon receiving a redirect indication using realm based routing.
A possible application of this scheme is when the diameter client and
redirect agent is in one realm and the destination is in another
realm. The use of realm based redirection in liue of host based
redirection provides greater topological flexibility than what is
currently provided in [RFC3588]. Consider an operator taking over
the subscribers and services of another operator. A redirect agent
MAY be employed in the old operator's realm to redirect AAA requests
to the server in the new operator's realm without knowing the
specific identity of the destination. This remedies the hardcoding
of destination identities in the redirect agent of the old operator.
Tsou & Fajardo Expires December 8, 2006 [Page 4]
Internet-Draft Diameter Routing Extensions June 2006
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 defines the functionality and participants of the
routing extensions described in this document.
SSR
Diameter strict source routing scheme.
SSR-Originator
A diameter node initiating a session and sending the requests.
The originator can be any diameter node sending a request, i.e.
client, server or proxy capable of initiating sessions. The
originator is also capable of participating in an SSR.
AAA Relays
Diameter nodes in between the proxies, originator or receiver.
These nodes represent existing diameter agents and proxies that do
not participate in an SSR and do not recognize Proxy-Path AVPs.
SSR-Proxy
Diameter proxies participating in an SSR and is capable of
processing Proxy-Path AVPs.
SSR-Destination
Diameter node which will ultimately consume the request sent by an
SSR-Originator. The receiver is capable of participating in an
SSR.
Tsou & Fajardo Expires December 8, 2006 [Page 5]
Internet-Draft Diameter Routing Extensions June 2006
3. Diameter Strict Source Routing (SSR)
This section outlines a Diameter SSR mechanism by which SSR
participants can remain in the path of all request messages for a
specific session. A new Proxy-Path AVP has been defined to allow
diameter nodes participating in an SSR to manipulate the Destination-
Host and/or Destination-Realm AVP of request messages.
The following sections describe the extensions to the request routing
in [RFC3588] to implement the SSR mechanism. The proposed extensions
utilized existing routing strategies in [RFC3588] and does not
mandate modifications to it.
3.1. Originating a request (SSR-Originator)
A diameter node acting as an SSR-Originator for a particular session
MUST maintain a local cache which enumerates all the diameter
identities of the SSR-Proxies that the request messages MUST traverse
along the path to the SSR-Destination. The identity of a diameter
node is defined in [RFC3588]. The local cache may also include the
nodes realm. The data structure of the cache is left up to the
implementation and should persist as part of the session attributes
or properties.
A SSR-Originator sending request messages MUST add a Proxy-Path AVP
to these requests. The contents of the cache SHOULD be used to
populate the Proxy-Path AVP where each cached entry is represented by
Proxy-Path-Record AVP. SSR-Proxies along the path of the request
message MUST review the contents of the Proxy-Path AVP and make
routing adjustments based on records it contains. An example of the
message flow is shown in Section 3.9. Note that the SSR-Originator
can be any diameter node, i.e. client, server or proxy.
The SSR-Proxy identities enumerated in the local cache SHOULD be
maintained in the same order as they are traversed along the request
routing path from the originator to destination. The same ordering
should also exist in the enumeration of Proxy-Path-Records
representing each SSR-Proxy identity in the Proxy-Path AVP.
The SSR-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 SSR-Proxies along the routing
path. The later scheme is known as Proxy-Path discovery. The
contents of the cache can be pre-configured if the SSR-Originator has
explicit knowledge of the SSR-Proxy(ies) the request messages has to
traverse otherwise it can use Proxy-Path discovery.
Proxy-Path discovery can be used if the identities of the SSR-Proxies
Tsou & Fajardo Expires December 8, 2006 [Page 6]
Internet-Draft Diameter Routing Extensions June 2006
proxies are not known or if there are several SSR capable proxies (a
cluster of proxies) that can be dynamically chosen based on other
routing policies. In Proxy-Path discovery, the cache of the SSR-
originator is initially empty. When the SSR-Originator sends the
first request message of a session, the Proxy-Path AVP will contain
only a Proxy-Path-Record with the identity and/or the realm of the
SSR-Originator. The Destination-Host and/or Destination-Realm AVPs
of the request message is set to the identity and/or the realm of the
SSR-Destination respectively as specified in [RFC3588]. As the
request message is received and processed by an SSR-Proxy, the SSR-
Proxy MUST append a new Proxy-Path-Record containing its own identity
and/or realm to the Proxy-Path AVP prior to forwarding the message.
Subsequent SSR-Proxies along the path that wishes to participate in
the SSR MUST also append their own Proxy-Path-Record in the same
manner (Section 3.2). When the request reaches the SSR-Destination,
it MUST append its a new Proxy-Path-Record to the Proxy-Path AVP in a
similar manner. The SSR-Destination MUST also copy the resulting
Proxy-Path AVP to the answer message (Section 3.3). Once the answer
message reaches the SSR-Originator, the Proxy-Path AVP would have
contained several Proxy-Path-Records containing its the SSR-
Originator identity, the identities of all participating SSR-Proxies
and the identity of the SSR-Destination. The SSR-Originator SHOULD
then populate its local cache with the contents of the Proxy-Path
AVP.
If the answer message does not contain a Proxy-Path AVP or the
Result-Code AVP is set to DIAMETER_SSR_NOT_AVAILABLE Section 3.8, it
is an indication to the SSR-Originator that the destination of the
request does not support SSR and that the SSR-Originator SHOULD avoid
sending a Proxy-Path AVP in subsequent request messages.
If after performing Proxy-Path discovery and the Proxy-Path AVP in
the answer message contains only the Proxy-Path-Record of the SSR-
Originator and SSR-Destination then this SHOULD be an indication to
the SSR-Originator that there are no diameter proxies capable of
participating in an SSR along the path and that the SSR-Originator
MAY avoid sending a Proxy-Path AVP in subsequent request messages.
Certain failover situations MAY cause this indication as described in
Section 3.5. In such cases, the situation maybe transient and
subsequent Proxy-Path discovery in succeeding sessions may find
participating proxies. It is left up to the SSR-Originator to decide
if subsequent Proxy-Path discovery should be attempted in succeeding
sessions.
Once the SSR-Originator's local cache has been populated, whether
pre-configured or through Proxy-Path discovery, all request messages
for the session MUST include the Proxy-Path AVP using the contents of
the local cache. The Proxy-Path AVP MUST contain the Proxy-Path-
Tsou & Fajardo Expires December 8, 2006 [Page 7]
Internet-Draft Diameter Routing Extensions June 2006
Records of all the nodes enumerated in its cache except its own. The
identities enumerated in the Proxy-Path AVP MUST appear in the order
they will be traversed in the routing path. The last entry in the
Proxy-Path AVP MUST be the Proxy-Path-Record of the SSR-Destination.
In addition, the value of the Destination-Host and/or Destination-
Realm AVPs of the request messages MUST be set to the value of the
Proxy-Host and/or Proxy-Realm of the first Proxy-Path-Record AVP
present in the Proxy-Path AVP. This ensures that the SSR-Originator
as well as any AAA relays in between the SSR-Originator and the first
SSR-Proxy will route the message towards the first SSR-Proxy as
specified in [RFC3588]. Subsequent actions taken by the first SSR-
Proxy upon receipt of the message is described in Section 3.2 and
will mimic a similar action.
Answer messages received by the SSR-Originator to subsequent request
messages after the SSR path has been established SHOULD not have a
Proxy-Path AVP. Otherwise, this SHOULD be considered a suspect
condition that maybe caused by a mis-behaving SSR participant. It is
left up to the SSR-Originator to continue using SSR scheme when such
condition arises or attempt another Proxy-Path discovery on
subsequent sessions.
3.2. Relaying and Proxying Requests (SSR-Proxy)
An SSR-Proxy is not required to keep local state or cache state
regarding the strict routing procedure. However, it MUST check
whether an incoming request contains a Proxy-Path AVP. If an
incoming request does not contain a Proxy-Path AVP then it MUST
process and forward the request as specified in [RFC3588]. If the
incoming request contains a Proxy-Path AVP, it MUST check whether its
identity is present in the Proxy-Path AVP. Determining whether its
identity is present can be done by matching its identity to the
Proxy-Host AVPs contained in each Proxy-Path-Record. If its identity
is not present and it wishes to participate in strict source routing,
it MUST append its a new Proxy-Path-Record in the Proxy-Path AVP
prior to forwarding the request. The new Proxy-Path-Record MUST
contain at the least a Proxy-Host AVP set to the proxies identity.
This scenario is part of the Proxy-Path discovery scheme in
Section 3.1.
However, if the SSR-Proxy does not wish to participate in the SSR, it
SHOULD not modify the Proxy-Path AVP and simply forward the request
as specified in [RFC3588] using the existing value of Destination-
Host and/or Destination-Realm AVP. The same scenario applies to non
SSR-proxies and relays that does not support SSR and does not
recognize Proxy-Path AVP.
If the identity of the SSR-Proxy is present in the Proxy-Path AVP,
Tsou & Fajardo Expires December 8, 2006 [Page 8]
Internet-Draft Diameter Routing Extensions June 2006
then it MUST be the first Proxy-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 SSR-
Originator Section 3.8. If the identity of the SSR-Proxy matches the
first Proxy-Path-Record, the SSR-Proxy MUST remove this record from
Proxy-Path AVP and set the Destination-Host and/or Destination-Realm
AVP to the next Proxy-Path-Record present in the Proxy-Path AVP.
Setting the Destination-Host and/or Destination-Realm AVP will ensure
that the SSR-Proxy as well as all AAA relays in between the current
SSR-Proxy and the next SSR-Proxy enumerated in the Proxy-Path AVP
will route the message towards the next SSR-Proxy. The process of
removing the SSR-Proxies record is synonymous to removing an entry in
a stack represented by the Proxy-Path AVP. Note that in the case of
the SSR-Destination, the Proxy-Path AVP MUST be empty once its own
record is removed Section 3.3. Note also that the behavior specified
above applies to a diameter node acting as a relay agent and
participates in the SSR scheme.
3.3. Receiving Requests (SSR-Destination)
A diameter node that locally processes request sent by the SSR-
Originator Section 3.1 and is able to support SSR MUST check for the
presence of a Proxy-Path AVP in the request message. If an incoming
request does not contain a Proxy-Path AVP then it is an indication
that messages belonging to this session will not use SSR. It SHOULD
process the request for local consumption and formulate an answer
message as specified in [RFC3588]. If the incoming request contains
a Proxy-Path AVP, it MUST check whether its identity is present in
the Proxy-Path AVP. If its identity is not present in the Proxy-Path
and it wishes to participate in the SSR, it MUST append its a new
Proxy-Path-Record in the Proxy-Path AVP. The new Proxy-Path-Record
MUST contain at the least a Proxy-Host AVP set to the SSR-
Destinations identity. The SSR-Destination MUST then copy the
resulting Proxy-Path AVP in the subsequent answer message. This
scenario is part of the proxy path discovery scheme in Section 3.1.
However, if the SSR-Destination supports SSR but does not wish to or
cannot participate, it MAY send a Result-Code AVP set to
DIAMETER_SSR_NOT_AVAILABLE as defined in Section 3.8. The SSR-
Destination SHOULD not include any Proxy-Path AVP in the subsequent
answer. The same scenario applies to SSR-destinations that does not
support SSR and do not recognize Proxy-Path AVP and is a hint to the
SSR-Originator that the destination does not support SSR.
If the identity of the SSR-Destination matches a record in the Proxy-
Path AVP, then it MUST be the only Proxy-Path-Record present in the
Proxy-Path AVP otherwise, this SHOULD be considered an error and an
answer message with the e-bit set and the Result-Code set to
Tsou & Fajardo Expires December 8, 2006 [Page 9]
Internet-Draft Diameter Routing Extensions June 2006
DIAMETER_INVALID_PROXY_PATH_STACK MUST be sent back to the SSR-
Originator Section 3.8. If the identity of the of the SSR-
Destination matches the only existing Proxy-Path-Record, then this is
an indication of a successful SSR. The SSR-Destination SHOULD NOT
copy the Proxy-Path AVP into the subsequent answer message.
3.4. Diameter answer processing
The diameter nodes participating in SSR does not require special
handling or routing of answer messages. Answer messages SHOULD be
processed normally as specified in [RFC3588]. However, a diameter
node acting an SSR-Destination MUST formulate a proper Proxy-Path AVP
in answer messages as described in Section 3.3.
3.5. Failover and Failback Considerations
In the event that failover occurs in a diameter node preceding an
SSR-Proxy and the SSR-Proxy is a likely target of a Proxy-Path
discovery, it is possible that the Proxy-Path AVP will not include
the targeted SSR-Proxy if the initial request involved in the Proxy-
Path discovery is re-routed away from the SSR-Proxy. In the case
that there are no other SSR-Proxy along the re-routed path, it is
also possible that the resulting answer message will have a Proxy-
Path AVP that contains only the Proxy-Route-Record of the SSR-
Originator and the SSR-Destination indicating that there is no SSR
support found in diameter nodes along the path. It is left to the
SSR-Originator to continue with processing of the request without SSR
support or abandon the transaction. The SSR-Originator SHOULD not
attempt to perform Proxy-Path discovery in subsequent request
messages of the session in such cases so as to protect against
failback conditions where an SSR-Proxy may suddenly appear in the
path and attempts to add a new Proxy-Path-Record for request messages
other than the initial request. However, based on certain policy, it
is also possible for the SSR-Originator to attempt Proxy-Path
discovery in subsequent sessions.
If a failover occurs in diameter node preceding an SSR-Proxy when the
SSR path is already established, it is possible that an
DIAMETER_UNABLE_TO_DELIVER error will be received by the SSR-
Originator if there no other alternative path towards the SSR-proxy.
In such a case, it is left to the SSR-Originator to handle the error
as specified in diameter application or in [RFC3588].
3.6. Proxy-Path-Record AVP
The Proxy-Path-Record AVP (AVP Code TBD) is of type Group. The
identity added in this AVP MUST be the same as the one advertised by
a diameter node in the Origin-Host during the Capabilities Exchange
Tsou & Fajardo Expires December 8, 2006 [Page 10]
Internet-Draft Diameter Routing Extensions June 2006
messages. Proxy-Host and Proxy-State is as defined in [RFC3588].
Proxy-State AVP SHOULD be treated as opaque data and can be used by
participating SSR nodes to relay session related information among
themselves.
Proxy-Path-Record ::= < AVP Header: TBD >
{ Proxy-Host }
[ Proxy-Realm ]
[ Proxy-State ]
* [ AVP ]
Figure 1: Proxy-Path-Record AVP
3.6.1. Proxy-Realm AVP
The Proxy-Realm AVP (AVP Code TBD) is of type DiameterIdentity, and
contains the realm the SSR node inserting the record. This AVP is
used in conjunction with Proxy-Host AVP.
It is recommended that the Proxy-Host AVP is present and used to
uniquely identify an SSR-Proxy within the AAA realm being traversed
by a request. Otherwise, SSR will need to rely on realm routing.
Realm routing would require a well know topology for SSR 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 SSR-Proxy of the realm.
When a Proxy-Host AVP is present in the Proxy-Path-Record AVP, the
realm name included in the hostname MUST correspond to the identity
present of the Proxy-Realm AVP.
3.7. Proxy-Path AVP
The Proxy-Path AVP (AVP Code TBD) is of type Group. This AVP SHOULD
be present in all request and answer messages performing SSR.
Proxy-Path ::= < AVP Header: XXX >
1* [ Proxy-Path-Record ]
* [ AVP ]
Figure 2: Proxy-Path AVP
3.8. Error Handling
The following are error conditions that are possible with SSR. These
errors fall within the Protocol Error category SHOULD be treated on a
per-hop basis, and Diameter proxies MAY attempt to correct the error,
if it is possible. Note that these and only these errors MUST only
Tsou & Fajardo Expires December 8, 2006 [Page 11]
Internet-Draft Diameter Routing Extensions June 2006
be used in answer messages whose 'E' bit is set.
DIAMETER_INVALID_PROXY_PATH_STACK
A request message received by an SSR-Proxy or SSR-Destination
after an SSR path has been established has the first or only
Proxy-Path-Record AVP not matching the SSR-Proxy or the SSR-
Destinations identity. The same error applies to SSR-Destinations
receiving a Proxy-Path-AVP containing more than one Proxy-Path-
Record or a Proxy-Path-AVP with only on Proxy-Path-Record not
matching its own identity.
This error value SHOULD be considered a protocol failure.
Diameter nodes sending this error indication MUST have the e-bit
set in the answer message and MUST confom to Section 7.2 of
[RFC3588].
DIAMETER_SSR_NOT_AVAILABLE
An SSR-Destination which supports SSR 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 SSR
attempts MAY succeed.
3.9. Example Message Flows
The example presented here illustrates the flow of Diameter messages
with the typical attributes present in the SSR scenario.
The SSR-Originator in the example in below shows the use of Proxy-
Path discovery with the first request. However, the SSR-Originator
may also use a pre-configure cache. The SSR-Originator can be any
diameter node sending a request, i.e. client, server or proxy. In
this scenario, the local cache of the SSR-Originator is initially
empty.
The AAA relays in between the SSR-Proxies, SSR-Originator and SSR-
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 SSR scheme. The AAA relays also depicts
existing diameter relays or proxies that do not recognize Proxy-Path
AVPs and therefore do not participate in SSR.
SSR- SSR- SSR- SSR-
Originator AAA relays proxy1 AAA relays proxy2 Destination
(o.realm1 (p.realm1 (p.realm2 (d.realm2
.com) .com) .com) .com)
Tsou & Fajardo Expires December 8, 2006 [Page 12]
Internet-Draft Diameter Routing Extensions June 2006
| | | | |
cache=(empty) | | | | |
------------->|--------->| | | |
(1st request of the session)| | | |
Proxy-Path= | | | |
record1=o.realm1.com,reaml1.com | | |
dest-host=d.realm2.com | | | |
dest-realm=realm2.com | | | |
| | | | |
| |--------->|--------->| |
| | (forwarded request)| |
| | Proxy-Path= | |
| | record1=o.realm1.com,reaml1.com
| | record2=p.realm1.com,realm1.com
| | dest-host=d.realm2.com |
| | dest-realm=realm2.com |
| | | | |
| | | |--------->|
| | | (forwarded request)
| | | Proxy-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 Proxy-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 | | |
it's local cache can skip the | | |
exchange above and send the | | |
initial request as shown below | | |
| | | | |
------------->|--------->| | | |
(subsequent request of the session) | | |
Proxy-Path= | | | |
record1=p.realm1.com,realm1.com | | |
record2=p.realm2.com,realm2.com | | |
record3=d.realm2.com,realm2.com | | |
dest-host=p.realm1.com | | | |
Tsou & Fajardo Expires December 8, 2006 [Page 13]
Internet-Draft Diameter Routing Extensions June 2006
dest-realm=realm1.com | | | |
| |--------->|--------->| |
| | (forwarded request)| |
| | Proxy-Path= | |
| | record1=p.realm2.com,realm2.com
| | record2=d.realm2.com,realm2.com
| | dest-host=p.reaml2.com |
| | dest-realm=realm2.com |
| | | | |
| | | |--------->|
| | | (forwarded request)
| | | Proxy-Path=
| | | record1=d.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 * no Proxy-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 3: Example SSR Message Flow
Tsou & Fajardo Expires December 8, 2006 [Page 14]
Internet-Draft Diameter Routing Extensions June 2006
4. Redirect Realm Indication
A redirect agent MAY add a Redirect-Realm AVP to the redirect
indication sent to the client. If the redirect agent has added a
Redirect-Realm AVP to the indication, it MAY not add any Redirect-
Host AVP to it.
The client receiving a redirect indication with a Redirect-Realm AVP
MUST reconstruct the request using Redirect-Realm AVP as the
Destination-Realm AVP. If one (or more) Redirect-Host AVP(s) are
present in the indication, the client uses one of them as the
Destination-Host AVP in the reconstructed request. The processing of
this request at any Diameter node along the path will follow the
Request forwarding/routing procedures described in [RFC3588], i.e. if
the value in the Destination-Host AVP resolves to a peer to which the
node can directly communicate, the request is forwarded to the peer,
else the Destination-Realm AVP is used for request routing.
+------------------+
| Diameter |
| Redirect Agent |
|(agent.source.net)|
+------------------+
^ |
| | Redirect Indication
| | redirect-host=hms.example.net
| | redirect-realm=R-R:example.net
| v
+-------------+ +-------------+ +-----------+
| Client | | Proxy | | Server |
|client.source|----------->|proxy.example|--------->+hms.example|
| .net | | .net | | .net |
+-------------+ +-------------+ +-----------+
dest-host=hms.example.net dest-host=hms.example.net
dest-realm=example.net dest-realm=example.net
Figure 4: Redirection using host and realm information
In the figure above, the Redirect agent in realm source.net replies
to the client request with a redirect indication having a Redirect-
Host AVP set to "hms.examle.net" and Redirect-Realm AVP set to
"example.net". The client reconstructs the request and sets
Destination-Host and/or Destination-Realm to the value of the
Redirect-Host and/or Redirect-Realm AVP respectively. Since the
client has no direct peer connection with the server, request routing
is performed using realm routes [RFC3588]. In the scenario above,
the request is routed to an in-bound proxy of the realm example.net.
Since the proxy can directly communicate with the server, it forwards
Tsou & Fajardo Expires December 8, 2006 [Page 15]
Internet-Draft Diameter Routing Extensions June 2006
the request using the Destination-Host AVP which was set to the
servers identity (hms.example.net).
+------------------+
| Diameter |
| Redirect Agent |
|(agent.source.net)|
+------------------+
^ |
| | Redirect Indication
| | redirect-host=example.net
| v
+-------------+ +--------------+
| Client | | Server |
|client.source|------------->|server.example|
| .net | | .net |
+-------------+ +--------------+
dest-host=example.net
Figure 5: Redirection using only realm information
In the figure above, the Redirect agent in realm source.net replies
to the client request with a redirect indication having Redirect-
Realm AVP set to "example.net". The client reconstructs the request
and sets the Destination-Realm AVP to the value of the Redirect-Realm
AVP. The client follows realm routing procedures in [RFC3588] using
the Destination-Realm AVP and routes the request to a server in the
realm "example.net". Once the server receives the request, it can
process it for local consumption since it is responsible for diameter
request for that realm (Section 2.7 of [RFC3588]).
4.1. Redirect-Realm AVP
The Redirect-Realm AVP (AVP Code XXX_3) is of type DiameterIdentity.
Only one instance of this AVP MAY be present if the answer message
e-bit set and the Result-Code AVP is set to
DIAMETER_REDIRECT_INDICATION.
Tsou & Fajardo Expires December 8, 2006 [Page 16]
Internet-Draft Diameter Routing Extensions June 2006
5. RADIUS/Diameter Protocol Interactions
No actions need to be taken with regards to RADIUS/Diameter
interaction. The routing extensions introduced by this document is
transparent to any translation gateway and relevant only to diameter
routing.
Tsou & Fajardo Expires December 8, 2006 [Page 17]
Internet-Draft Diameter Routing Extensions June 2006
6. IANA Considerations
IANA is to assign new AVP codes for the following AVPs discussed in
this document: Proxy-Path, Proxy-Path-Record and Proxy-Realm AVP.
Tsou & Fajardo Expires December 8, 2006 [Page 18]
Internet-Draft Diameter Routing Extensions June 2006
7. Security Considerations
This document does not contain a security protocol; it describes
extensions to the existing Diameter protocol. All security issues of
DIAMETER protocol must be considered in implementing this
specification. These extension does not add any unique concerns.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[TS23.234]
3GPP, "3GPP system to Wireles Local Area Network (WLAN)
interworking; System description", 3GPP TS 23.234 Version
7.1.0 2006.
Tsou & Fajardo Expires December 8, 2006 [Page 19]
Internet-Draft Diameter Routing Extensions June 2006
Authors' Addresses
Tina Tsou
Huawei Technologies
Bantian, Longgang Disctrict
Shenzhen, 518129
China
Phone:
Email: tena@huawei.com
Victor Fajardo
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5368
Email: vfajardo@tari.toshiba.com
Tsou & Fajardo Expires December 8, 2006 [Page 20]
Internet-Draft Diameter Routing Extensions June 2006
Intellectual Property Statement
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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Tsou & Fajardo Expires December 8, 2006 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 02:49:38 |