IP Packet Tunneling and Routing in UMB March 26 th, 2007 Qualcomm/Alcatel-Lucent/Hitachi Notice Contributors grant a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. Contributors are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by the contributors to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on the contributors. Contributors specifically reserve the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of the contributors other than provided in the copyright statement above.

Overview IP packet tunneling mechanisms (between AN- AN and AGW-AN) tie with how packets are routed to/from AT between the RAN and AGW and how IP addresses are assigned End-to-end system investigation is needed to determine the appropriate solution

Objectives Support overlapping IPv4 addresses with MIPv4 FA/CoA –Requires additional info besides AT IP address to identify the AT Support dual stack AT Support on-demand, host-driven IP address allocation –Requires ICMP messages to be exchanged between AN/AT and AGW before IP address is assigned Limit the number of “keys” which identifies the tunnel for ATs –The number of dynamic, per-AT, per direction, AN-AN tunnel keys can be large when Route Set size > 1 Limit or eliminate tunnel setup/ teardown for AN-AN tunnels in the Route Set Support both RLSA directly tunnel RL IP packets to AGW and RLSA tunnel RL packets to DAP

Solution AGW-AN tunnel –GRE tunnel with per AT key to support overlapping addresses Same key is used in both direction and assigned by AGW Dual stack AT uses same binding and key for IPv4 and IPv6 –Optional GRE sequence number assigned by AGW for packet re- ordering at the FLSA AN-AN tunnel –L2TPv3 IP tunnel contains Per AT key and AGW address from AGW-AN tunnel to identify AT –This key is known as part of the network context that all AN receives when added into the Route Set – so no need to negotiate “Direction” bit to specify whether FL or RL, in case packet needs to reverse-tunnel back to DAP Optional sequence number received in AGW-DAP GRE tunnel

Packet Headers (Simple IPv4 AT)

Packet Headers (Mobile IPv4 AT)

Packet Headers (Simple IPv6 AT)

Packet Headers (Mobile IPv6 AT bidirectional Tunnel)

Packet Headers (Mobile IPv6 AT Route Optimization)

L2TPv3 overview L2TPv3 [RFC3931] provides an extensible control protocol for the dynamic setup, maintenance and teardown of multiple tunnels between two logical endpoints. These sessions are called dynamic sessions –Dynamic sessions are not used for UMB L2TPv3 also allows for the creation of static sessions whose signaling is outside of the scope of RFC The dynamic SessionID space does not include the static SessionIDs. Allowing peaceful coexistence (if necessary) between static and dynamic sessions –Static SessionIDs can be specified in 3GPP2 to identify Link- Layer tunnel or IP tunnel –Control Connection signaling is not required for static session L2TPv3 is agnostic of the data it is transporting L2TPv3 is transported directly over IP L2TPv3 has a 4 byte packet header

Inter-AN IP tunnel in GRE or L2TPv3? While having receiving end of the tunnel dynamically assigned a unique ID (e.g., GRE key) per AT works, there are following drawbacks: –Memory and processing requirements to index and store keys increase with the # of ANs in the Route Set (if keys from each AN can be anything) –Need to pre-setup tunnel to exchange keys Even if “known” key is used to reduce number of keys required and eliminate pre-setup tunnel, L2TPv3 is better suited than GRE because: –We need AGW address and “direction” bit if RL IP packets need to be tunneled back to DAP first –Current GRE header as specified by RFC cannot carry these information Either we add 3GPP2 attributes or make GRE header non RFC-compliant –GRE in AN needs to process both “standard” GRE from AGW-AN and “3GPP2” GRE between AN-AN On the other hand, we have freedom to specify L2TPv3 sublayer header the way we like –If L2TPv3 is used for RLP tunnel between ANs, additional cost for supporting IP tunnel is marginal Enable easy segregation of data processing and IOS signaling processing

L2TPv3 Sublayer Header for UMB IP Forwarding

L2TPv3 Header Fields for IP Forwarding Version : 3 bit field which gives the version of the header V : 1 bit field which is set to “0” for an IPv4 AGW address, “1” for an IPv6 AGW address. S : 1 bit field which is set if AGW Sequence Number is present. TTL : 3 bit field for the time to live for the packets CRC : 16 bit CRC covering the L2TPv3 header computed using the polynomial x 0 + x 1 + x 2 + x 4 + x 5 + x 7 + x 8 + x 10 + x 11 + x 12 + x 16 + x 22 + x 23 + x 26 + x 32. AGW IPv4/6 Addr : The IP address of AGW the AT is associated with AGW Mobile Key : The GRE Key assigned by the AGW for this AT AGW Sequence Number : optional 32 bit sequence number stamped by the AGW

Recommendation Decision to use GRE tunnel between AGW-AN does not imply A10/A11 is needed –A large majority of A10/A11 functionalities are not needed –PMIP signaling messages can include option to carry GRE key as well PMIP should be used for AGW-AN tunnel in UMB L2TPv3 should be used for AN-AN IP tunnel in UMB