Internet Engineering Task Force T. Tsou, Ed. Internet-Draft Huawei Technologies Intended status: Informational October 27, 2008 Expires: April 30, 2009 Diameter Routing Problem Statement draft-tsou-dime-routing-problem-statement-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 April 30, 2009. Abstract This document describes use cases that suggest requirements to be able to add constraints to the existing Diameter routing mechanisms. 1. Introduction 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. This document presents three different cases where the basic Diameter routing behaviour is not sufficient to meet the rquirements. It then provides three problem statements corresponding to the three cases. Further analysis is required to determine if the Tsou Expires April 30, 2009 [Page 1] Internet-Draft Diameter Routing Problem Statement October 2008 number of problems to be solved can be reduced. 2. Requirements Language This document contains no requirements language. 3. Use Cases 3.1. 3GPP Wireless LAN (WLAN) Access Architecture One example of a stateful proxy is in the 3GPP WLAN IP access architecture [TS23.234]. The 3GPP WLAN interworking architecture extends 3GPP services to the WLAN access side. It enables a 3GPP subscriber to use a WLAN to access 3GPP services. WLAN AAA provides access to the WLAN to be authenticated and authorised through the 3GPP system. This access control can permit or deny a subscriber the access to the WLAN system and/or the interworking with the 3GPP system. There are two WLAN interworking reference models: 1. In the non-roaming case, the model includes the WLAN access network and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control as well as charging. 2. In the roaming case, the model includes the WLAN access network, the 3GPP AAA proxy in the visited network and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control. Charging records may be generated by the AAA proxy and/or the AAA server. The AAA proxy relays access control and charging messages to the AAA server. The AAA proxy will also do offline charging, if required. The roaming case presents two problems for which the Diameter routing mechanism described in [RFC3588] does not offer any unambiguous and standard solution. 1. Network selection: Selecting an initial message path for the Diameter session through (possibly many) alternative visited network(s) to the home network. 2. Explicit Routing: Maintaining the selected message path for all messages in the Diameter session. These problems are discussed in detail in the following sections. Tsou Expires April 30, 2009 [Page 2] Internet-Draft Diameter Routing Problem Statement October 2008 3.1.1. Initial Selection of Routing Path In the 3GPP model we are considering, the WLAN access network is simply a substitute for the radio access network of a cellular operator. Two other operating entities are involved in providing IP service to the roaming user: a visited mobile network to which the WLAN access network is directly connected, and the user's home mobile network. Consider the realistic model where the WLAN access network is connected to multiple mobile networks with which the user's home network has roaming agreements. A particular visited network has to be selected for authentication. There are three possibilities: o the WLAN access network automatically selects a preferred routing; o the WLAN access network advertises the available networks to the UE, which makes an automatic selection based on pre-configured policy; o the WLAN access network advertises the available networks to the UE, which presents the choices to the user and asks the user to make a selection. Once the visited network has been selected, Diameter currently does not fully standardize the means by which the Diameter client in the WLAN access network ensures that its initial request passes through the 3GPP AAA proxy in the chosen network. 3.1.2. Maintaining the Routing Path After a successful authentication, a Diameter session is established involving (at least) the following stateful entities: o The Diameter client in the WLAN AN o a Diameter proxy (the 3GPP AAA proxy) in the selected visited mobile network, and o a Diameter server in the UE's home realm. The functions assigned to the 3GPP AAA proxy include: o reporting charging information to the offline charging system in the visited network; o enforcing policies based on roaming agreements; Tsou Expires April 30, 2009 [Page 3] Internet-Draft Diameter Routing Problem Statement October 2008 o service termination initiated by the visited network operator. These functions all require that state be maintained within the visited network. The 3GPP choice is to maintain that state at the 3GPP AAA proxy. This means that the latter must remain in the messaging path for all subsequent messages relating to the same session. 3.2. Ability To Direct Routing Based On the Combination of Application and Realm A different use case has been suggested in discussion. Although no concrete example of an intent to deploy the problematic configuration has been produced, the case is described here for consideration. The basic requirement of the case is that it be possible to direct Diameter messaging to a specific proxy based on the combination of application and realm. Two variants on this requirement were proposed: 1. a case where the operator wishes to limit the organizations to which specific proxies handling specific applications connect; 2. a case where the operator is providing hosted services on behalf of different organizations, and restricts the realms handled by the proxies to those of the operator's customers. To the basic requirement is added the need to be able to adapt routing based on the requirements of load management, and to adapt to network, device, or application failures. 4. Problem Statements This section provides problem statements for the three use cases described above. 4.1. Initial Network Selection Note: this problem statement is here for completeness. There is agremeent that work on decorated NAI will go forward to remedy this specific problem. This is the statement of the problem posed by the case presented in Section 3.1.1. 1. Existing Diameter message routing behaviour: it is possible to direct a message through a specific intermediate realm using the Tsou Expires April 30, 2009 [Page 4] Internet-Draft Diameter Routing Problem Statement October 2008 decorated NAI mechanism within the User Name AVP. However, [RFC3588] does not unambiguously specify how to handle the decorated NAI i.e. how the Diameter client and agents participating in request routing may use the decorated NAI to update the Destination-Realm AVP. 2. Undesirable behaviour in the existing method: unpredictable results since the required mechanism has not been fully standardized. 3. Desired behaviour: the intermediate realm specified in the decorated NAI is traversed first, followed by the home user realm. This is required whenever a decorated NAI is presented. Section 3.1.1 describes the sort of environment where this requirement could arise. 4.2. Path Maintenance This is the statement of the problem posed by the case presented in Section 3.1.2. 1. Existing Diameter message routing behaviour: each host along the path makes its own independent routing decisions. 2. Undesirable behaviour in the existing method: routing of all messages for a given session through the selected 3GPP AAA proxy is not guaranteed if the visited mobile network has multiple proxies or if there are other Diameter entities between the WLAN client and the target 3GPP proxy. 3. Desired behaviour: regardless of the intervening set of Diameter elements, all messages for a given session pass through the proxy initially selected. This is required for stateful proxies only. Section 3.1.2 describes the sort of environment where this requirement could arise. 4.3. Routing By a Combination of Realm and Application This is the statement of the problem posed by the case presented in Section 3.2. 1. Existing Diameter message routing behaviour: Supported applications are not tied to any realm during capability exchange procedure. Origin-Realm AVP provides information about the node itself and does not provide information about the realms for the applications for which the node can provide relaying/proxying capability. Tsou Expires April 30, 2009 [Page 5] Internet-Draft Diameter Routing Problem Statement October 2008 2. Undesirable behaviour in the existing method: messages will be routed to nodes that cannot handle them because the nodes are restricted in what realms they can handle. Static routing to get around the problem prevents adaptation to failures or for load balancing. It also introduces a single point of failure in the message path and imposes an administrative burden. 3. Desired behaviour: a node can indicate the set of realms to which it is capable of proxying or relaying Diameter messages for specific applications. This is required only in the particular case where such restrictions exist. 5. Acknowledgements Text on the 3GPP WLAN use cases was provided by Rajith R. The application-realm problem was described by Tolga Asveren. Glen Zorn provided the problem statement template used in Section 4. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations It is possible that there are security issues with the problems stated above, but they are not immediately evident. 8. References 8.1. Normative References [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 8.2. Informative References [TS23.234] 3GPP, "TS23.234v7.7.0, 3GPP system to Wireless Local Area Network (WLAN) interworking; System description", June 2008. Tsou Expires April 30, 2009 [Page 6] Internet-Draft Diameter Routing Problem Statement October 2008 Author's Address Tina Tsou (editor) Huawei Technologies Section F, Huawei Industrial Base Bantian Longgang, Shenzhen 518129 P.R. China Phone: +86 755 28972912 Email: tena@huawei.com Tsou Expires April 30, 2009 [Page 7] Internet-Draft Diameter Routing Problem Statement October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Tsou Expires April 30, 2009 [Page 8]