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]