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]