Report about the Design Team on "Diameter Routing" http://tools. ietf Report about the Design Team on "Diameter Routing" http://tools.ietf.org/id/draft-tsou-dime-routing-problem-statement-00.txt (Tina Tsou)

Content Info to the group on where we are with the design team work. Discussion about the problem statement

+ WG Chairs: Dave Frascone and Hannes Tschofenig Design Team Members Tina Tsou Victor Fajardo Jouni Korhonen Tolga Asveren Mark Jones Avi Lior Glen Zorn Steve Norreys Lionel Morand + WG Chairs: Dave Frascone and Hannes Tschofenig

Dime Routing Problem Statement Team has agreed that work on decorated NAI should proceed on its own. http://tools.ietf.org/id/draft-korhonen-dime-nai-routing-02.txt Three challenges are described on the slides that follow.

Example of Problem 1: Initial Routing 3GPP home network WLAN Alternative 3GPP visited ntwks UE How to force signalling from client in WLAN to pass through the preferred 3GPP visited network en route to the home network? Decorated NAI is seen as the answer. Problem is stated in terms of 3GPP deployments, but this is just an example of deployments that could exist elsewhere.

Example of Problem 2: Subsequent Message Routing WLAN AAA Proxy UE AAA Server AAA Proxy Given that the AAA proxy in the 3GPP architecture must be stateful, how to force all messages for the same session through the same proxy? there can be intermediate nodes along the route with no desire to be stateful More than one node on the route may be stateful See backup slides for details on why proxy must be stateful. Problem is stated in terms of 3GPP deployments, but this is just an example of deployments that could exist elsewhere.

Third Problem: Application + Realm Based Routing OK App 1 for operators 1 and 2 Operator 1 Routing Cloud OK Operator 3 OK App 1 for operator 3 Operator 2 Failure Unrelated to the other two problems or the 3GPP WLAN case. Assume an operator deploys servers supporting particular applications only for specific source realms. How to provide routing based on the combination of application and realm? Static routing the obvious answer, but means no flexibility for adapting to load conditions and failures.

Next Steps When you look at the draft, do you think the problems have been identified? We have agreed the NAI work, can we agree on further work for solutions?

Backup Slides Stateful policy enforcement Stateful billing Service termination by the visited network operator

Stateful Policy Enforcement AAA proxy acts as Policy Server to visited network domain. Downloads policy to selected gateway to enable user flows. Need to signal session modification, session stop to the same AAA proxy so it can update policy accordingly. Close relationship to user flow accounting. Session start( *{FlowID, flow descriptor}, ...)‏ Session start( *{FlowID, flow descriptor}, ...)‏ AAA proxy AAA server Policy to enable flow(s)‏ Edge Router User flows

Stateful Billing Accounting is done in the visited network to supplement accounting in the home network, for purposes of revenue sharing between the two networks. The visited network also has to keep track of traffic between it and the WLAN. Different proxies may report accounting records to different billing servers. Records pertaining to the same user session could end up in different billing systems, increasing the effort required for record correlation. Billing Server 1 AAA Proxy 1 Start session AAA Server Stop session AAA Proxy 2 Billing Server 2

Service Termination By Visited Network Operator WLAN AN AAA Proxy AAA Server Wa Session Abort procedure Wd Session Terminate procedure H-PDG V-PDG Release Tunnel Release Tunnel When the visited realm operator initiates a service disconnect (blacklist, limited access list etc.), the AAA proxy should initiate a session abort procedure with the WLAN AN and a session terminate procedure with the AAA server in the home realm. Hence the proxy should maintain the session state.