Diameter Routing Extensions (draft-tsou-dime-base-routing-ext -03.txt)

1. Diameter Routing Extensions(draft-tsou-dime-base-routing-ext-03.txt) tena@huawei.com ; vfajardo@toshiba.comjouni.korhonen@teliasonera.com ; tasveren@sonusnet.com IETF70 DIME WG

2. Overview • Refresher • Ability for intermediaries to stay in the Diameter signaling path during a session (e.g. an outgoing gateway for a domain enforcing policy) • Updates since IETF 68/69 • Proposes new “workarounds” to provide explicit routing without using new routing AVPs • Introduce intermediate proxy nodes that are session stateful • Session stateful nodes can select the next hop node to send session messages to • Retain old scheme • Use new routing AVPs that keep track of nodes to visit • Added more use case scenarios; i.e. 3GPP IETF70 DIME WG

3. Comparisons of current explicit routing schemes • Stateful node acting as diameter back-to-back server-relay • Advantage • Can be used without adding/changing AVPs in messages; easily backward compatible • Back-to-back server retains the burden of maintaining session-based routing scheme • End-point receivers (and maybe transmitters) of the messages need not know about explicit routing • Requires that the back-to-back server acts as separate Diameter server for all service/domain pairs • If security procedures on application level are employed, the back-to-back server should proxy them • Disadvantage • An agent that is not stateful and residing one-hop or more prior to the stateful proxy node can re-route session messages away from the stateful proxy • Requires that the back-to-back performs endpoint procedures, e.g. duplicate detection • Use of routing AVPs • Advantage • Nodes that need to be visited are explicitly tracked from end-to-end • Disadvantage • Requires new routing AVPs to be piggybacked on session messages • Requires support from all participants (sender, intermediate nodes and receiver) IETF70 DIME WG

4. Use case #1: TISPAN NASS UAAF UAAF UAAF UAAF UAAF UAAF • E5 interface is a diameter cloud which typically has relays • For each sessions, a3 can use any available UAAF • Problem: Server messages (Home to visited) for a session • needs to pass through the same UAAF in the visited network IETF70 DIME WG

5. Use case #2: 3G I-WLAN 3GPP AAA Proxy 3GPP AAA Proxy 3GPP AAA Proxy • Wd interface is a diameter cloud which typically has relays • For each sessions, Wd can use any available 3GPP AAA Proxy • Problem: 3GPP AAA Server messages (Home to visited) for a session • needs to pass through the same 3GPP AAA proxy in the visited network • Problem: Current 3GPP scheme uses decorated NAI in the User-Name • to define a type of source routing IETF70 DIME WG

6. Use Case #3: Diameter MIPV6 Application Mobility Service Authorizer Mobility Service Provider IKEv2-EAP AAA-MSP Server AAA-MSA Server Home Agent AAA Cloud AAA Cloud AAA-MSP Server AAA-MSP Server • Multiple AAA-MSP can exist in the service provider network • Diameter clouds can contain stateless relays • Problem: Server messages (Authorizer to provider) for a session • needs to pass through the same MSP in the provider network IETF70 DIME WG