idnits 2.17.1 draft-tsou-dime-base-routing-ext-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 952. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 963. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 970. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 976. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3588]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 206 has weird spacing: '...r-A.com serv...' == Line 214 has weird spacing: '...r-A.com ser...' == Line 691 has weird spacing: '... relays prox...' == Line 726 has weird spacing: '...lm2.com rec...' == Line 727 has weird spacing: '...lm2.com rec...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Answer messages received by the ER-Originator to subsequent request messages after the ER path has been established SHOULD not have a Explicit-Path AVP. Otherwise, this SHOULD be considered a suspect condition that maybe caused by a mis-behaving ER participant. It is left up to the ER-Originator to continue using ER scheme when such condition arises or attempt another Explicit-Path discovery on subsequent sessions. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: However, if 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. The same scenario applies to non ER-proxies and relays that do not support ER and do not recognize Explicit-Path AVP. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A diameter node that locally processes request sent by the ER-Originator Section 3.1 and is able to support ER MUST check for the presence of a Explicit-Path AVP in the request message. If an incoming request does not contain a 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]. If the incoming request contains a Explicit-Path AVP, it MUST check whether its identity is present in the Explicit-Path AVP. 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 in the subsequent answer message. This scenario is part of the proxy path discovery scheme in Section 3.1. However, if 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 3.8. 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In the event that failover occurs in a diameter node preceding an ER-Proxy and the ER-Proxy is a likely target of a Explicit-Path discovery, it is possible that the Explicit-Path AVP will not include the targeted ER-Proxy if the initial request involved in the Explicit-Path discovery is re-routed away from the ER-Proxy. In the case that there is no other ER-Proxy along the re-routed path, it is also possible that the resulting answer message will have a Explicit-Path AVP that contains only the Explicit-Route-Record 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 abandon the transaction. 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 29, 2008) is 5749 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DIME Working Group T. Tsou 3 Internet-Draft Huawei 4 Expires: January 29, 2009 V. Fajardo 5 TARI 6 J. Korhonen 7 TeliaSonera 8 T. Asveren 9 Sonus 10 July 29, 2008 12 Diameter Routing Extensions 13 draft-tsou-dime-base-routing-ext-04 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 29, 2009. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document describes two(2) extensions to the current diameter 47 routing scheme. The first extension describes an explicit routing 48 mechanism that MAY be employed by Diameter nodes to allow specific 49 stateful Diameter proxies to remain in the path of all messages 50 exchanges constituting a Diameter session. The second extension 51 describes a realm based redirection scheme as an alternative to host 52 based redirection described in [RFC3588]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Diameter Explicit Routing . . . . . . . . . . . . . . . . 3 58 1.2. Workarounds . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.2.1. Consistent Next-Hop Routing . . . . . . . . . . . . . 5 60 1.2.2. Service Access Point Proxying . . . . . . . . . . . . 5 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 3. Diameter Explicit Routing (ER) . . . . . . . . . . . . . . . . 10 63 3.1. Originating a request (ER-Originator) . . . . . . . . . . 10 64 3.2. Relaying and Proxying Requests (ER-Proxy) . . . . . . . . 12 65 3.3. Receiving Requests (ER-Destination) . . . . . . . . . . . 13 66 3.4. Diameter answer processing . . . . . . . . . . . . . . . . 14 67 3.5. Failover and Failback Considerations . . . . . . . . . . . 14 68 3.6. Explicit-Path-Record AVP . . . . . . . . . . . . . . . . . 15 69 3.6.1. Proxy-Realm AVP . . . . . . . . . . . . . . . . . . . 15 70 3.7. Explicit-Path AVP . . . . . . . . . . . . . . . . . . . . 16 71 3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . . 16 72 3.9. Example Message Flows . . . . . . . . . . . . . . . . . . 17 73 4. Redirect Realm Indication . . . . . . . . . . . . . . . . . . 20 74 4.1. Redirect-Realm AVP . . . . . . . . . . . . . . . . . . . . 21 75 5. RADIUS/Diameter Protocol Interactions . . . . . . . . . . . . 22 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 79 9. Normative References . . . . . . . . . . . . . . . . . . . . . 26 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 81 Intellectual Property and Copyright Statements . . . . . . . . . . 28 83 1. Introduction 85 The following sections provides an overview of the routing extensions 86 proposed in this document. 88 1.1. Diameter Explicit Routing 90 In [RFC3588], routing of request messages from source to the 91 destination is based solely on the routing decision made by each node 92 along the path. In a topology where multiple paths are possible from 93 source to destination, it is not guaranteed that all messages 94 constituting a session will take the same path. For a proxy node 95 residing along a path that maintains stateful information for a 96 session, it is desirable that it remains in the routing path of all 97 message exchanges of that a session. 99 In general, a session that is comprised of multiple message exchanges 100 and requires intermediary proxy functions will require explicit 101 routing for all request messages within that session. An example of 102 a stateful proxies are in the WLAN 3GPP IP access [TS23.234]. The 103 WLAN Access Network (WLAN AN) can use Diameter EAP with the 3GPP AAA 104 server or proxy for authentication & authorization. In the roaming 105 case, the WLAN AN is communicating with a 3GPP AAA Proxy in the 106 visited network over the Wa or the Wm reference points. The 3GPP AAA 107 proxy is then connected to the 3GPP Server in the home network over 108 the Wd reference point. The 3GPP AAA Proxy among its many functions 109 will enforce local policies on access based on agreement with the 110 3GPP Home Network and with the WLAN operator either over the Wa or 111 the Wg references points. It will also send per user charging 112 information for the session to the Offline Charging system. This 113 necessitates that the proxy maintains the session state information 114 and hence it needs to remain in-path for the entire session. 116 Given that there are cases where a stateful proxies need to be in the 117 routing path of a session, a generic description of the problem is 118 shown in Figure 1. In this scenario there is a relay in the visited 119 network (Relay1) and two(2) proxies in the home network (Proxy1 and 120 Proxy2). Relay1 is connected to Proxy1 and Proxy2 for scalability 121 and/or redundancy. If a session is composed of several request/ 122 answer exchanges it is possible that each request of the session 123 takes different paths towards the Home Server. As an example, if 124 Relay1 can route messages via Proxy1 or Proxy2 based on some policy 125 independent of the session then the first message of the session can 126 take the path Client->Relay1->Proxy1->Home Server while subsequent 127 message can take the path Client->Relay1->Proxy2->Home Server. In 128 this case if Proxy1 is stateful then it expects to process not only 129 the first message but subsequent request as well. 131 VISITED NETWORK | HOME NETWORK 132 | 133 +--------+ +--------+ | +--------+ 134 | Client |<--->| Relay1 |<----->| Proxy1 | 135 +--------+ +--------+ | +--------+\ 136 \ | \+-------------+ 137 \ | | Home Server | 138 \| /+-------------+ 139 \ +--------+/ 140 |---| Proxy2 | 141 | +--------+ 143 Figure 1: Generic Stateful Proxy Problem 145 In larger deployments, the issue can be aggrevated when there are a 146 greater number of proxy nodes in both visited and home networks in 147 Figure 1. Further escalation of the problem occurs if the deployment 148 adds stateless relays preceding any of the proxy nodes in Figure 1. 150 In [RFC3588], it is possible to use static routing between the source 151 and the proxy to ensure all message exchanges traverses the proxy in 152 question. However, static routing in general, introduces many 153 limitations. 155 o Static routing implies that all messages, regardless of session, 156 will have to traverse the same proxy. This introduces a single 157 point of failure in the routing path and affects any and all 158 sessions regardless of whether the session is of interest to the 159 proxy. 161 o It compromises failover procedure in the node adjacent to the 162 proxy and preceding it in the request forwarding path. This 163 becomes apparent if the adjacent node explicitly and statically 164 routes only towards the proxy. 166 o In the event of more complex topologies where multiple proxies are 167 traversed between source and destination, the administrative 168 burden of static configuration along the path may be considerable. 170 o No provision for load balancing as all the nodes in the path will 171 be subjected to static routing. 173 Considering these limitations, an alternative and more dynamic method 174 of establishing an explicit route is proposed. 176 1.2. Workarounds 178 This section describes two methods, which can be used to provide a 179 workaround for the problem described above. These methods are 180 relying on existing Diameter base protocol functionality and should 181 not be considered as a normative part of this document. 183 1.2.1. Consistent Next-Hop Routing 185 If all entities in the signaling path are session stateful, they can 186 select the same next-hop entity, when routing requests for a 187 particular session. 189 It should be noted that Diameter Base Protocol does not mandate that 190 all requests for the same session need to be routed to the same 191 intermediary next-hop, even if a Diameter node has that capability. 193 1.2.2. Service Access Point Proxying 195 If a stateful intermediary node wants to stay in the message path 196 during the whole session for a specific service, it may advertise 197 itself as the entity providing that service. 199 +----------+ 200 | | 201 | Client | 202 | | 203 +----------+ 204 client.example.com 206 service1-1.provider-A.com service1-2.provider-A.com 207 +----------+ +----------+ 208 | Stateful | | Stateful | 209 | Agent-1 | | Agent-2 | 210 | | | | 211 +----------+ +----------+ 212 gateway1.example.com gateway2.example.com 214 server-1.provider-A.com server-2.provider-A.com 215 +----------+ +----------+ 216 | | | | 217 | Server-1 | | Server-2| 218 | | | | 219 +----------+ +----------+ 221 Figure 2: Addresses used for Service Access Point Proxying 223 An intermediary, proxying the Service Access Point would terminate 224 the session from client side and initiate a corresponding session to 225 the server. Values for certain fields could be reused for this 226 second session depending on the service message flow. For example, 227 the same Session-Id AVP value could be used for both of these 228 sessions. If the message flow does not contain requests from server 229 to client, Origin-Host AVP value could be directly copied as well. 231 Client Stateful Agent Server 232 | | | | 233 | | | | 234 |----REQ-1---------------->| | | 235 | App-Id=X | |-----REQ-1-------------->| 236 | | | App-Id=X | 237 | Session-Id=Id1 | | | 238 | | | Session-Id=Id2 | 239 | Originating-Host= | | | 240 | client.example.com | | Originating-Host= | 241 | | | gateway1.example.com | 242 | Originating-Realm= | | | 243 | example.com | | Originating-Realm= | 244 | | | example.com | 245 | Destination-Host= | | | 246 | | | Destination-Host= | 247 | Destination-Realm= | | server-1.provider-A.com| 248 | provider-A.com | | | 249 | | | Destination-Realm= | 250 | | | provider-A.com | 251 | | | | 252 | | | | 253 | | | <-------------ANS-1-----| 254 | | | App-Id=X | 255 | | | | 256 | | | Session-Id=Id2 | 257 | | | | 258 | | | Originating-Host= | 259 | | | server-1.provider-A.com| 260 | | | | 261 | | | Originating-Realm= | 262 | | | provider-A.com | 263 | | | | 264 |<--------------ANS-1------| | | 265 | App-Id=X | | | 266 | | | | 267 | Session-Id=Id1 | | | 268 | | | | 269 | Originating-Host= | | | 270 | service-1-1.prover-A.com | | | 271 | | | | 272 | Originating-Realm= | | | 273 | provider-A.com | | | 274 | | | | 276 Figure 3: Messages used for Service Access Point Proxying 278 This approach requires that stateful agent provides service access 279 point proxying for all service/domain combinations by advertising a 280 different Diameter identity and may not scale well if the number of 281 such combinations is high. Stateful agent should perform all 282 Diameter endpoint procedures, e.g. duplicate detection. Furthermore, 283 if end-to-end security is desired, either the stateful agent needs to 284 have enough logic to proxy the end-to-end security service as well or 285 this model should not be used. 287 2. Terminology 289 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 290 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 291 document are to be interpreted as described in [RFC2119]. 293 The following terms defines the functionality and participants of the 294 routing extensions described in this document. 296 ER 298 Diameter explicit routing scheme. 300 ER-Originator 302 A diameter node initiating a session and sending the requests. 303 The originator can be any diameter node sending a request, i.e. 304 client, server or proxy capable of initiating sessions. The 305 originator is also capable of participating in explicit routing. 307 AAA Relays 309 Diameter nodes in between the proxies, originator or receiver. 310 These nodes represent existing diameter agents and proxies that do 311 not participate in an ER and do not recognize Explicit-Path AVPs. 313 ER-Proxy 315 Diameter proxies participating in an ER and is capable of 316 processing Explicit-Path AVPs. 318 ER-Destination 320 Diameter node which will ultimately consume the request sent by an 321 ER-Originator. The receiver is capable of participating in an ER. 323 3. Diameter Explicit Routing (ER) 325 This section outlines a Diameter ER mechanism by which ER 326 participants can remain in the path of all request messages for a 327 specific session. A new Explicit-Path AVP has been defined to allow 328 diameter nodes participating in an ER to manipulate the Destination- 329 Host and/or Destination-Realm AVP of request messages. 331 The following sections describe the extensions to the request routing 332 in [RFC3588] to implement the ER mechanism. The proposed extensions 333 utilized existing routing strategies in [RFC3588] and do not mandate 334 modifications to it. The scheme also differs from existing strict 335 source routing scheme where all hops in the path to have to 336 participate. In the ER mechanism, only diameter nodes interested in 337 participating in the ER scheme will be involved in it. 339 3.1. Originating a request (ER-Originator) 341 A diameter node acting as an ER-Originator for a particular session 342 MUST maintain a local cache which enumerates all the diameter 343 identities of the ER-Proxies that the request messages MUST traverse 344 along the path to the ER-Destination. The identity of a diameter 345 node is defined in [RFC3588]. The local cache may also include the 346 nodes realm. The data structure of the cache is left up to the 347 implementation and should persist as part of the session attributes 348 or properties. 350 A ER-Originator sending request messages MUST add a Explicit-Path AVP 351 to these requests. The contents of the cache SHOULD be used to 352 populate the Explicit-Path AVP where each cached entry is represented 353 by Explicit-Path-Record AVP. ER-Proxies along the path of the 354 request message MUST review the contents of the Explicit-Path AVP and 355 make routing adjustments based on records it contains. An example of 356 the message flow is shown in Section 3.9. Note that the ER- 357 Originator can be any diameter node, i.e. client, server or proxy. 359 The ER-Proxy identities enumerated in the local cache SHOULD be 360 maintained in the same order as they are traversed along the request 361 routing path from the originator to destination. The same ordering 362 should also exist in the enumeration of Explicit-Path-Records 363 representing each ER-Proxy identity in the Explicit-Path AVP. 365 The ER-Originator can populate the cache either by pre-configuring 366 its contents or by using the first request message of the session to 367 gather identities of participating ER-Proxies along the routing path. 368 The later scheme is known as Explicit-Path discovery. The contents 369 of the cache can be pre-configured if the ER-Originator has explicit 370 knowledge of the ER-Proxy(ies) the request messages has to traverse 371 otherwise it can use Explicit-Path discovery. It is recommended that 372 Explicit-Path discovery is used whenever possible since pre- 373 configuration is less flexible by nature. 375 Explicit-Path discovery can be used if the identities of the ER- 376 Proxies proxies are not known or if there are several ER capable 377 proxies (a cluster of proxies) that can be dynamically chosen based 378 on other routing policies. In Explicit-Path discovery, the cache of 379 the ER-originator is initially empty. When the ER-Originator sends 380 the first request message of a session, the Explicit-Path AVP will 381 contain only a Explicit-Path-Record with the identity and/or the 382 realm of the ER-Originator. The Destination-Host and/or Destination- 383 Realm AVPs of the request message is set to the identity and/or the 384 realm of the ER-Destination respectively as specified in [RFC3588]. 385 It should be noted that ER-Originator initial request message routing 386 steps and the Destination-Realm population MAY be affected by the 387 User-Name AVP NAI decoration [RFC4282]. The NAI decoration is a form 388 of request message source routing and defines realms that the request 389 message MUST traverse through before routing towards the ER- 390 Destination. Diameter nodes participating to the request message 391 routing must examine and process the User-Name AVP, and modify the 392 Destination-Realm AVP accordingly as long as there are realms left in 393 the decorated NAI. The NAI decaration based source routing does not 394 affect the Explicit-Path discovery as defined in this document. 396 As the request message is received and processed by an ER-Proxy, the 397 ER-Proxy MUST append a new Explicit-Path-Record containing its own 398 identity and/or realm to the Explicit-Path AVP prior to forwarding 399 the message. Subsequent ER-Proxies along the path that wishes to 400 participate in the ER MUST also append their own Explicit-Path-Record 401 in the same manner (Section 3.2). When the request reaches the ER- 402 Destination, it MUST append its a new Explicit-Path-Record to the 403 Explicit-Path AVP in a similar manner. The ER-Destination MUST also 404 copy the resulting Explicit-Path AVP to the answer message 405 (Section 3.3). Once the answer message reaches the ER-Originator, 406 the Explicit-Path AVP will contain several Explicit-Path-Records 407 containing its the ER-Originator identity, the identities of all 408 participating ER-Proxies and the identity of the ER-Destination. The 409 ER-Originator SHOULD then populate its local cache with the contents 410 of the Explicit-Path AVP. 412 If the answer message does not contain a Explicit-Path AVP or the 413 Result-Code AVP is set to DIAMETER_ER_NOT_AVAILABLE Section 3.8, it 414 is an indication to the ER-Originator that the destination of the 415 request does not support ER and that the ER-Originator SHOULD avoid 416 sending a Explicit-Path AVP in subsequent request messages. 418 If after performing Explicit-Path discovery and the Explicit-Path AVP 419 in the answer message contains only the Explicit-Path-Record of the 420 ER-Originator and ER-Destination then this SHOULD be an indication to 421 the ER-Originator that there are no diameter proxies capable of 422 participating in an ER along the path and that the ER-Originator MAY 423 avoid sending a Explicit-Path AVP in subsequent request messages. 424 Certain failover situations MAY cause this indication as described in 425 Section 3.5. In such cases, the situation maybe transient and 426 subsequent Explicit-Path discovery in succeeding sessions may find 427 participating proxies. It is left up to the ER-Originator to decide 428 if subsequent Explicit-Path discovery should be attempted in 429 succeeding sessions. 431 Once the ER-Originator's local cache has been populated, whether pre- 432 configured or through Explicit-Path discovery, all request messages 433 for the session MUST include the Explicit-Path AVP using the contents 434 of the local cache. The Explicit-Path AVP MUST contain the Explicit- 435 Path-Records of all the nodes enumerated in its cache except its own. 436 The identities enumerated in the Explicit-Path AVP MUST appear in the 437 order they will be traversed in the routing path. The last entry in 438 the Explicit-Path AVP MUST be the Explicit-Path-Record of the ER- 439 Destination. In addition, the value of the Destination-Host and/or 440 Destination-Realm AVPs of the request messages MUST be set to the 441 value of the Proxy-Host and/or Proxy-Realm of the first Explicit- 442 Path-Record AVP present in the Explicit-Path AVP. This ensures that 443 the ER-Originator as well as any AAA relays in between the ER- 444 Originator and the first ER-Proxy will route the message towards the 445 first ER-Proxy as specified in [RFC3588]. Subsequent actions taken 446 by the first ER-Proxy upon receipt of the message is described in 447 Section 3.2 and will mimic a similar action. 449 Answer messages received by the ER-Originator to subsequent request 450 messages after the ER path has been established SHOULD not have a 451 Explicit-Path AVP. Otherwise, this SHOULD be considered a suspect 452 condition that maybe caused by a mis-behaving ER participant. It is 453 left up to the ER-Originator to continue using ER scheme when such 454 condition arises or attempt another Explicit-Path discovery on 455 subsequent sessions. 457 3.2. Relaying and Proxying Requests (ER-Proxy) 459 The basic action taken by an ER-Proxy upon receiving a request is to 460 check whether explicity routing is supported in the request and if 461 so, check whether it is already a participant in explicit routing for 462 the said request. Being an existing participant would require the 463 ER-Proxy to pop/remove the Explicit-Path-Record AVP pertaining to 464 itself in the Explicit-Path AVP and then use the next Explicit-Path- 465 Record AVP for subsequent routing. Details of this operation are as 466 follows. 468 An ER-Proxy is not required to keep local state or cache state 469 regarding the explicit routing procedure. However, it MUST check 470 whether an incoming request contains a Explicit-Path AVP. If an 471 incoming request does not contain a Explicit-Path AVP then it MUST 472 process and forward the request as specified in [RFC3588]. If the 473 incoming request contains a Explicit-Path AVP, it MUST check whether 474 its identity is present in the Explicit-Path AVP. Determining 475 whether its identity is present can be done by matching its identity 476 to the Proxy-Host AVPs contained in each Explicit-Path-Record. If 477 its identity is not present and it wishes to participate in explicit 478 routing, it MUST append a new Explicit-Path-Record in the Explicit- 479 Path AVP prior to forwarding the request. The new Explicit-Path- 480 Record MUST be added as the last AVP in the Explicit-Path AVP and 481 MUST contain at the least a Proxy-Host AVP set to the proxies 482 identity. This scenario is part of the Explicit-Path discovery 483 scheme in Section 3.1. 485 However, if the ER-Proxy does not wish to participate in the ER, it 486 SHOULD not modify the Explicit-Path AVP and simply forward the 487 request as specified in [RFC3588] using the existing value of 488 Destination-Host and/or Destination-Realm AVP. The same scenario 489 applies to non ER-proxies and relays that do not support ER and do 490 not recognize Explicit-Path AVP. 492 If the identity of the ER-Proxy is present in the Explicit-Path AVP, 493 then it MUST be the first Explicit-Path-Record in the AVP otherwise, 494 this SHOULD be considered an error and an answer message with the 495 e-bit set and the Result-Code set to 496 DIAMETER_INVALID_PROXY_PATH_STACK must be sent back to the ER- 497 Originator Section 3.8. If the identity of the ER-Proxy matches the 498 first Explicit-Path-Record, the ER-Proxy MUST remove this record from 499 Explicit-Path AVP and set the Destination-Host and/or Destination- 500 Realm AVP to the next Explicit-Path-Record present in the Explicit- 501 Path AVP. Setting the Destination-Host and/or Destination-Realm AVP 502 will ensure that the ER-Proxy as well as all AAA relays in between 503 the current ER-Proxy and the next ER-Proxy enumerated in the 504 Explicit-Path AVP will route the message towards the next ER-Proxy. 505 The process of removing the ER-Proxies record is synonymous to 506 removing an entry in a stack represented by the Explicit-Path AVP. 507 Note that in the case of the ER-Destination, the Explicit-Path AVP 508 MUST be empty once its own record is removed Section 3.3. Note also 509 that the behavior specified above applies to a diameter node acting 510 as a relay agent and participates in the ER scheme. 512 3.3. Receiving Requests (ER-Destination) 514 A diameter node that locally processes request sent by the ER- 515 Originator Section 3.1 and is able to support ER MUST check for the 516 presence of a Explicit-Path AVP in the request message. If an 517 incoming request does not contain a Explicit-Path AVP then it is an 518 indication that messages belonging to this session will not use ER. 519 It SHOULD process the request for local consumption and formulate an 520 answer message as specified in [RFC3588]. If the incoming request 521 contains a Explicit-Path AVP, it MUST check whether its identity is 522 present in the Explicit-Path AVP. If its identity is not present in 523 the Explicit-Path and it wishes to participate in the ER, it MUST 524 append its a new Explicit-Path-Record in the Explicit-Path AVP. The 525 new Explicit-Path-Record MUST contain at the least a Proxy-Host AVP 526 set to the ER-Destinations identity. The ER-Destination MUST then 527 copy the resulting Explicit-Path AVP in the subsequent answer 528 message. This scenario is part of the proxy path discovery scheme in 529 Section 3.1. However, if the ER-Destination supports ER but does not 530 wish to or cannot participate, it MAY send a Result-Code AVP set to 531 DIAMETER_ER_NOT_AVAILABLE as defined in Section 3.8. The ER- 532 Destination SHOULD not include any Explicit-Path AVP in the 533 subsequent answer. The same scenario applies to ER-destinations that 534 does not support ER and do not recognize Explicit-Path AVP and is a 535 hint to the ER-Originator that the destination does not support ER. 537 If the identity of the ER-Destination matches a record in the 538 Explicit-Path AVP, then it MUST be the only Explicit-Path-Record 539 present in the Explicit-Path AVP otherwise, this SHOULD be considered 540 an error and an answer message with the e-bit set and the Result-Code 541 set to DIAMETER_INVALID_PROXY_PATH_STACK MUST be sent back to the ER- 542 Originator Section 3.8. If the identity of the of the ER-Destination 543 matches the only existing Explicit-Path-Record, then this is an 544 indication of a successful ER. The ER-Destination SHOULD NOT copy 545 the Explicit-Path AVP into the subsequent answer message. 547 3.4. Diameter answer processing 549 The diameter nodes participating in ER do not require special 550 handling or routing of answer messages. Answer messages SHOULD be 551 processed normally as specified in [RFC3588]. However, a diameter 552 node acting an ER-Destination MUST formulate a proper Explicit-Path 553 AVP in answer messages as described in Section 3.3. 555 3.5. Failover and Failback Considerations 557 In the event that failover occurs in a diameter node preceding an ER- 558 Proxy and the ER-Proxy is a likely target of a Explicit-Path 559 discovery, it is possible that the Explicit-Path AVP will not include 560 the targeted ER-Proxy if the initial request involved in the 561 Explicit-Path discovery is re-routed away from the ER-Proxy. In the 562 case that there is no other ER-Proxy along the re-routed path, it is 563 also possible that the resulting answer message will have a Explicit- 564 Path AVP that contains only the Explicit-Route-Record of the ER- 565 Originator and the ER-Destination indicating that there is no ER 566 support found in diameter nodes along the path. It is left to the 567 ER-Originator to continue with processing of the request without ER 568 support or abandon the transaction. The ER-Originator SHOULD not 569 attempt to perform Explicit-Path discovery in subsequent request 570 messages of the session in such cases so as to protect against 571 failback conditions where an ER-Proxy may suddenly appear in the path 572 and attempts to add a new Explicit-Path-Record for request messages 573 other than the initial request. However, based on certain policy, it 574 is also possible for the ER-Originator to attempt Explicit-Path 575 discovery in subsequent sessions. 577 If a failover occurs in diameter node preceding an ER-Proxy when the 578 ER path is already established, it is possible that an 579 DIAMETER_UNABLE_TO_DELIVER error will be received by the ER- 580 Originator if there no other alternative path towards the ER-proxy. 581 In such a case, it is left to the ER-Originator to handle the error 582 as specified in diameter application or in [RFC3588]. 584 3.6. Explicit-Path-Record AVP 586 The Explicit-Path-Record AVP (AVP Code TBD) is of type Group. The 587 identity added in this AVP MUST be the same as the one advertised by 588 a diameter node in the Origin-Host during the Capabilities Exchange 589 messages. Proxy-Host is as defined in [RFC3588]. 591 Explicit-Path-Record ::= < AVP Header: TBD > 592 { Proxy-Host } 593 [ Proxy-Realm ] 594 * [ AVP ] 596 Figure 4: Explicit-Path-Record AVP 598 This AVP MAY be sent with the default AVP flags settings defined in 599 Sec 4.1 of [RFC3588] where 'M' bit MUST be set and 'V' bit MUST NOT 600 be set. If the 'M' bit is set then the recommendations in Sec 4.1 of 601 [RFC3588] regarding preservation of interoperability SHOULD be 602 followed. 604 3.6.1. Proxy-Realm AVP 606 The Proxy-Realm AVP (AVP Code TBD) is of type DiameterIdentity, and 607 contains the realm the ER node inserting the record. This AVP is 608 used in conjunction with Proxy-Host AVP. 610 It is recommended that the Proxy-Host AVP is present and used to 611 uniquely identify an ER-Proxy within the AAA realm being traversed by 612 a request. Otherwise, ER will need to rely on realm routing. Realm 613 routing would require a well known topology for ER scheme to work 614 properly since the hostname of the proxy is not specified. In such a 615 case, the Proxy-Realm AVP MUST be present and is used to identify the 616 ER-Proxy of the realm. 618 When a Proxy-Host AVP is present in the Explicit-Path-Record AVP, the 619 realm name included in the hostname MUST correspond to the identity 620 present of the Proxy-Realm AVP. 622 3.7. Explicit-Path AVP 624 The Explicit-Path AVP (AVP Code TBD) is of type Group. This AVP 625 SHOULD be present in all request and answer messages performing ER. 627 Explicit-Path ::= < AVP Header: XXX > 628 1* [ Explicit-Path-Record ] 629 * [ AVP ] 631 Figure 5: Explicit-Path AVP 633 This AVP MAY be sent with the default AVP flags settings defined in 634 Sec 4.1 of [RFC3588] where 'M' bit MUST be set and 'V' bit MUST NOT 635 be set. If the 'M' bit is set then the recommendations in Sec 4.1 of 636 [RFC3588] regarding preservation of interoperability SHOULD be 637 followed. 639 3.8. Error Handling 641 The following are error conditions that are possible with ER. These 642 errors fall within the Protocol Error category SHOULD be treated on a 643 per-hop basis, and Diameter proxies MAY attempt to correct the error, 644 if it is possible. Note that these and only these errors MUST only 645 be used in answer messages whose 'E' bit is set. 647 DIAMETER_INVALID_PROXY_PATH_STACK 649 A request message received by an ER-Proxy or ER-Destination after 650 an ER path has been established has the first or only Explicit- 651 Path-Record AVP not matching the ER-Proxy or the ER-Destinations 652 identity. The same error applies to ER-Destinations receiving a 653 Explicit-Path-AVP containing more than one Explicit-Path-Record or 654 a Explicit-Path-AVP with only on Explicit-Path-Record not matching 655 its own identity. 657 This error value SHOULD be considered a protocol failure. 658 Diameter nodes sending this error indication MUST have the e-bit 659 set in the answer message and MUST confom to Section 7.2 of 661 [RFC3588]. 663 DIAMETER_ER_NOT_AVAILABLE 665 An ER-Destination which supports ER routing but is unable to 666 comply for unknown reasons MAY send an answer message with the 667 Result-Code AVP set to this error code. This error value SHOULD 668 be considered a transient failure indicating that subsequent ER 669 attempts MAY succeed. 671 3.9. Example Message Flows 673 The example presented here illustrates the flow of Diameter messages 674 with the typical attributes present in the ER scenario. 676 The ER-Originator in the example in below shows the use of Explicit- 677 Path discovery with the first request. However, the ER-Originator 678 may also use a pre-configure cache. The ER-Originator can be any 679 diameter node sending a request, i.e. client, server or proxy. In 680 this scenario, the local cache of the ER-Originator is initially 681 empty. 683 The AAA relays in between the ER-Proxies, ER-Originator and ER- 684 Destination may or may not be present and are shown here to depict 685 routing paths that the requests may take prior to being processed by 686 nodes participating in the ER scheme. The AAA relays also depicts 687 existing diameter relays or proxies that do not recognize Explicit- 688 Path AVPs and therefore do not participate in ER. 690 ER- ER- ER- ER- 691 Originator AAA relays proxy1 AAA relays proxy2 Destination 692 (o.realm1 (p.realm1 (p.realm2 (d.realm2 693 .com) .com) .com) .com) 694 | | | | | 695 cache=(empty) | | | | | 696 ------------->|--------->| | | | 697 (1st request of the session)| | | | 698 Explicit-Path= | | | | 699 record1=o.realm1.com,reaml1.com | | | 700 dest-host=d.realm2.com | | | | 701 dest-realm=realm2.com | | | | 702 | | | | | 703 | |--------->|--------->| | 704 | | (forwarded request)| | 705 | | Explicit-Path= | | 706 | | record1=o.realm1.com,reaml1.com 707 | | record2=p.realm1.com,realm1.com 708 | | dest-host=d.realm2.com | 709 | | dest-realm=realm2.com | 710 | | | | | 711 | | | |--------->| 712 | | | (forwarded request) 713 | | | Explicit-Path= 714 | | | record1=o.realm1.com, 715 | | | realm1.com 716 | | | record2=p.realm1.com, 717 | | | realm1.com 718 | | | record3=p.realm2.com, 719 | | | realm2.com 720 | | | dest-host=d.realm2.com 721 | | | dest-realm=realm2.com 722 | | | | | 723 cache= |<---------|<---------|<---------|<---------| 724 record1=o.realm1.com,realm1.com (answer) | 725 record2=p.realm1.com,realm1.com Explicit-Path= 726 record3=p.realm2.com,realm2.com record1=o.realm1.com,realm1.com 727 record4=d.realm2.com,realm2.com record2=p.realm1.com,realm1.com 728 | | record3=p.realm2.com,realm2.com 729 | | record4=d.realm2.com,realm2.com 730 Note: An originator pre-configuring | | | 731 it's local cache can skip the | | | 732 exchange above and send the | | | 733 initial request as shown below | | | 734 | | | | | 735 ------------->|--------->| | | | 736 (subsequent request of the session) | | | 737 Explicit-Path= | | | | 738 record1=p.realm1.com,realm1.com | | | 739 record2=p.realm2.com,realm2.com | | | 740 record3=d.realm2.com,realm2.com | | | 741 dest-host=p.realm1.com | | | | 742 dest-realm=realm1.com | | | | 743 | |--------->|--------->| | 744 | | (forwarded request)| | 745 | | Explicit-Path= | | 746 | | record1=p.realm2.com,realm2.com 747 | | record2=d.realm2.com,realm2.com 748 | | dest-host=p.reaml2.com | 749 | | dest-realm=realm2.com | 750 | | | | | 751 | | | |--------->| 752 | | | (forwarded request) 753 | | | Explicit-Path 754 | | | record1=d.realm2.com, 755 | | | realm2.com 756 | | | dest-host=d.realm2.com 757 | | | dest-realm=realm2.com 758 | | | | | 759 cache= |<---------|<---------|<---------|<---------| 760 record1=o.realm1.com,realm1.com (answer) | | 761 record2=p.realm1.com,realm1.com * no Explicit-Path-AVP present 762 record3=p.realm2.com,realm2.com | | | 763 record4=d.realm2.com,realm2.com | | | 764 | | | | | 765 | | | | | 766 (subsequent request of the session will repeat the process above) 767 | | | | | 768 | | | | | 770 Figure 6: Example ER Message Flow 772 4. Redirect Realm Indication 774 A redirect agent MAY add a Redirect-Realm AVP to the redirect 775 indication sent to the client. If the redirect agent has added a 776 Redirect-Realm AVP to the indication, it MAY not add any Redirect- 777 Host AVP to it. 779 The client receiving a redirect indication with a Redirect-Realm AVP 780 MUST reconstruct the request using Redirect-Realm AVP as the 781 Destination-Realm AVP. If one (or more) Redirect-Host AVP(s) are 782 present in the indication, the client uses one of them as the 783 Destination-Host AVP in the reconstructed request. The processing of 784 this request at any Diameter node along the path will follow the 785 Request forwarding/routing procedures described in [RFC3588], i.e. if 786 the value in the Destination-Host AVP resolves to a peer to which the 787 node can directly communicate, the request is forwarded to the peer, 788 else the Destination-Realm AVP is used for request routing. 790 +------------------+ 791 | Diameter | 792 | Redirect Agent | 793 |(agent.source.net)| 794 +------------------+ 795 ^ | 796 | | Redirect Indication 797 | | redirect-host=hms.example.com 798 | | redirect-realm=example.com 799 | v 800 +-------------+ +-------------+ +-----------+ 801 | Client | | Proxy | | Server | 802 |client.source|----------->|proxy.example|--------->+hms.example| 803 | .net | | .com | | .com | 804 +-------------+ +-------------+ +-----------+ 805 dest-host=hms.example.com dest-host=hms.example.com 806 dest-realm=example.com dest-realm=example.com 808 Figure 7: Redirection using host and realm information 810 In the figure above, the Redirect agent in realm source.net replies 811 to the client request with a redirect indication having a Redirect- 812 Host AVP set to "hms.examle.com" and Redirect-Realm AVP set to 813 "example.com". The client reconstructs the request and sets 814 Destination-Host and/or Destination-Realm to the value of the 815 Redirect-Host and/or Redirect-Realm AVP respectively. Since the 816 client has no direct peer connection with the server, request routing 817 is performed using realm routes [RFC3588]. In the scenario above, 818 the request is routed to an in-bound proxy of the realm example.com. 819 Since the proxy can directly communicate with the server, it forwards 820 the request using the Destination-Host AVP which was set to the 821 servers identity (hms.example.com). 823 +------------------+ 824 | Diameter | 825 | Redirect Agent | 826 |(agent.source.net)| 827 +------------------+ 828 ^ | 829 | | Redirect Indication 830 | | redirect-realm=example.com 831 | v 832 +-------------+ +--------------+ 833 | Client | | Server | 834 |client.source|------------->|server.example| 835 | .net | | .com | 836 +-------------+ +--------------+ 837 dest-realm=example.com 839 Figure 8: Redirection using only realm information 841 In the figure above, the Redirect agent in realm source.net replies 842 to the client request with a redirect indication having Redirect- 843 Realm AVP set to "example.com". The client reconstructs the request 844 and sets the Destination-Realm AVP to the value of the Redirect-Realm 845 AVP. The client follows realm routing procedures in [RFC3588] using 846 the Destination-Realm AVP and routes the request to a server in the 847 realm "example.com". Once the server receives the request, it can 848 process it for local consumption since it is responsible for diameter 849 request for that realm (Section 2.7 of [RFC3588]). 851 4.1. Redirect-Realm AVP 853 The Redirect-Realm AVP (AVP Code XXX_3) is of type DiameterIdentity. 854 Only one instance of this AVP MAY be present if the answer message 855 e-bit set and the Result-Code AVP is set to 856 DIAMETER_REDIRECT_INDICATION. 858 5. RADIUS/Diameter Protocol Interactions 860 No actions need to be taken with regards to RADIUS/Diameter 861 interaction. The routing extensions introduced by this document is 862 transparent to any translation gateway and relevant only to diameter 863 routing. The assumption is that if there is a RADIUS proxy chain 864 between Diameter translation agents the route between translation 865 agents remains stable during the session and does not cause an 866 invalidation of the proxy path stack. 868 6. IANA Considerations 870 IANA is to assign new AVP codes for the following AVPs discussed in 871 this document: Explicit-Path, Explicit-Path-Record and Proxy-Realm 872 AVP. 874 7. Security Considerations 876 This document does not contain a security protocol; it describes 877 extensions to the existing Diameter protocol. All security issues of 878 DIAMETER protocol must be considered in implementing this 879 specification. These extension does not add any unique concerns. 881 8. Acknowledgements 883 The author gratefully acknowledges the contributions of: Avi Lior, 884 Tolga Asveren, Tony Zhang, Rajith R. 886 9. Normative References 888 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 889 Requirement Levels", BCP 14, RFC 2119, March 1997. 891 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 892 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 894 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 895 Network Access Identifier", RFC 4282, December 2005. 897 [TS23.234] 898 3GPP, "3GPP system to Wireles Local Area Network (WLAN) 899 interworking; System description", 3GPP TS 23.234 Version 900 7.4.0 2006. 902 Authors' Addresses 904 Tina Tsou 905 Huawei Technologies 906 Bantian, Longgang Disctrict 907 Shenzhen, 518129 908 China 910 Phone: 911 Email: tena@huawei.com 913 Victor Fajardo 914 Toshiba America Research, Inc. 915 1 Telcordia Drive 916 Piscataway, NJ 08854 917 USA 919 Phone: +1 732 699 5368 920 Email: vfajardo@tari.toshiba.com 922 Jouni Korhonen 923 TeliaSonera Corporation. 924 P.O.Box 970 925 FIN-00051 Sonera 926 Finland 928 Email: jouni.korhonen@teliasonera.com 930 Tolga Asveren 931 Sonus Networks 932 4400 Route 9 South 933 Freehold, NJ 07728 934 USA 936 Email: tasveren@sonusnet.com 938 Full Copyright Statement 940 Copyright (C) The IETF Trust (2008). 942 This document is subject to the rights, licenses and restrictions 943 contained in BCP 78, and except as set forth therein, the authors 944 retain all their rights. 946 This document and the information contained herein are provided on an 947 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 948 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 949 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 950 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 951 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 952 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 954 Intellectual Property 956 The IETF takes no position regarding the validity or scope of any 957 Intellectual Property Rights or other rights that might be claimed to 958 pertain to the implementation or use of the technology described in 959 this document or the extent to which any license under such rights 960 might or might not be available; nor does it represent that it has 961 made any independent effort to identify any such rights. Information 962 on the procedures with respect to rights in RFC documents can be 963 found in BCP 78 and BCP 79. 965 Copies of IPR disclosures made to the IETF Secretariat and any 966 assurances of licenses to be made available, or the result of an 967 attempt made to obtain a general license or permission for the use of 968 such proprietary rights by implementers or users of this 969 specification can be obtained from the IETF on-line IPR repository at 970 http://www.ietf.org/ipr. 972 The IETF invites any interested party to bring to its attention any 973 copyrights, patents or patent applications, or other proprietary 974 rights that may cover technology that may be required to implement 975 this standard. Please address the information to the IETF at 976 ietf-ipr@ietf.org. 978 Acknowledgment 980 Funding for the RFC Editor function is provided by the IETF 981 Administrative Support Activity (IASA).