IP Packet Tunneling and Routing in UMB

March 26th, 2007

Qualcomm/Alcatel-Lucent/Hitachi

NoticeContributors 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)

MS/ATFLSA/RLSA

AGW CN

Src=RLSA IP Add

Dest=DAP IP AddSrc=MS IP Add

Dest=CN IP AddL2TPv3 (AGW add,

key1, dir = RL)

Src=MS IP Add

Dest=CN IP AddSrc=MS IP Add

Dest=CN IP Add

RL

Src=DAP IP Add

Dest=FLSA IP Add

Src=CN IP Add

Dest=MS IP Add

Src=CN IP Add

Dest=MS IP Add

FL

L2TPv3 (AGW add, key1, dir = FL)

Src=CN IP Add

Dest=MS IP Add

DAP

Src=DAP IP Add

Dest=AGW IP Add

GRE (key1)

Src=MS IP Add

Dest=CN IP Add

Src=AGW IP Add

Dest=DAP IP Add

GRE (key1)

Src=CN IP Add

Dest=MS IP Add

If RLSA directly tunnel to AGW, then it uses GRE (AGW add, key1) instead of L2TPv3

FLSA determines the AT based on(AGW add, key1)

Packet Headers (Mobile IPv4 AT)

MS/ATFLSA/RLSA

AGW CNHA

Src=RLSA IP Add

Dest=DAP IP AddSrc=MS HoA

Dest=CN IP AddL2TPv3 (AGW add,

key1, dir = RL)

Src=MS HoA

Dest=CN IP Add

Src=MS CoA

Dest=HA IP Add

Src=MS HoA

Dest=CN IP AddSrc=MS HoA

Dest=CN IP Add

FA CoA (RL)

Src=DAP IP Add

Dest=FLSA IP Add

Src=CN IP Add

Dest=MS HoA

Src=HA IP Add

Dest=MS CoA

Src=CN IP Add

Dest=MS HoA

Src=CN IP Add

Dest=MS HoAFA CoA

(FL)

L2TPv3 (AGW add, key1, dir = FL)

Src=CN IP Add

Dest=MS HoA

DAP

Src=DAP IP Add

Dest=AGW IP Add

GRE (key1)

Src=MS HoA

Dest=CN IP Add

Src=AGW IP Add

Dest=DAP IP Add

GRE (key1)

Src=CN IP Add

Dest=MS HoA

For overlapped HoA assigned by different HAs, AGW assigned different

key1 for each AT

If RLSA directly tunnel to AGW, then it uses GRE (AGW add, keys) instead of L2TPv3

FLSA determines the AT based on(AGW add, key1)

Packet Headers (Simple IPv6 AT)

MS/ATFLSA/RLSA

AGW CN

Src=RLSA IP Add

Dest=DAP IP AddSrc=MS IP Add

Dest=CN IP AddL2TPv3 (AGW addr,

key1, dir = RL)

Src=MS IP Add

Dest=CN IP AddSrc=MS IP Add

Dest=CN IP Add

RL

Src=DAP IP Add

Dest=FLSA IP Add

Src=CN IP Add

Dest=MS IP Add

Src=CN IP Add

Dest=MS IP Add

FL

L2TPv3 (AGW addr, key1, dir = FL)

Src=CN IP Add

Dest=MS IP Add

DAP

Src=DAP IP Add

Dest=AGW IP Add

Src=MS IP Add

Dest=CN IP Add

Src=AGW IP Add

Dest=DAP IP Add

Src=CN IP Add

Dest=MS IP Add

GRE (key1)

GRE (key1)

Use same GRE keybetween IPv4 and IPv6

Packet Headers (Mobile IPv6 AT bidirectional Tunnel)

MS/ATFLSA/RLSA

AGW CNHA

Src=RLSA IP Add

Dest=DAP IP Add

L2TPv3 (AGW addr, dir = RL)

Src=MS HoA

Dest=CN IP Add

Src=MS CoA

Dest=HA IP Add

Src=MS HoA

Dest=CN IP AddSrc=MS HoA

Dest=CN IP Add

RL

Src=DAP IP Add

Dest=FLSA IP Add

Src=CN IP Add

Dest=MS HoA

Src=HA IP Add

Dest=MS CoA

Src=CN IP Add

Dest=MS HoA

Src=CN IP Add

Dest=MS HoA

FL

L2TPv3 (AGW addr, dir = FL)

Src=CN IP Add

Dest=MS HoA

DAP

Src=AGW IP Add

Dest=DAP IP Add

Src=CN IP Add

Dest=MS HoA

Src=MS CoA

Dest=HA IP Add

Src=MS HoA

Dest=CN IP Add

Src=DAP IP Add

Dest=AGW IP Add

Src=MS CoA

Dest=HA IP Add

Src=MS HoA

Dest=CN IP Add

Src=MS CoA

Dest=HA IP Add

Src=HA IP Add

Dest=MS CoASrc=HA IP Add

Dest=MS CoA

Src=HA IP Add

Dest=MS CoA

GRE (key1)

GRE (key1)

Packet Headers (Mobile IPv6 AT Route Optimization)

MS/ATFLSA/RLSA

AGW CNHA

Src=RLSA IP Add

Dest=DAP IP Add

L2TPv3 (AGW address, dir = RL)

Src=MS CoA

Dest=CN IP Add

RL

Src=DAP IP Add

Dest=FLSA IP Add

Src=CN IP Add

Dest=MS CoA

...

Type 2 Routing Header: MS HoA

FLL2TPv3 (AGW

address, dir = FL)

DAP

Src=AGW IP Add

Dest=DAP IP Add

Src=MS CoA

Dest=CN IP Add

Src=DAP IP Add

Dest=AGW IP Add

Src=MS CoA

Dest=CN IP Add

Src=MS CoA

Dest=CN IP Add

Src=CN IP Add

Dest=MS CoASrc=CN IP Add

Dest=MS CoA

Src=CN IP Add

Dest=MS CoA

...

HAO in Dest Option Header: MS HoA ...

HAO in Dest Option Header: MS HoA

...

HAO in Dest Option Header: MS HoA

...

HAO in Dest Option Header: MS HoA

...

Type 2 Routing Header: MS HoA

...

Type 2 Routing Header: MS HoA

...

Type 2 Routing Header: MS HoA

GRE (key1)

GRE (key1)

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 3931. 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

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

VerTTL

V Reserved CRCS

AGW IPv4 (V=0)/IPv6 (V=1) Address

AGW Sequence Number (Optional)

AGW Mobile Key (GRE Key)

AGW IPv6 (V=1) Address (Cont)

AGW IPv6 (V=1) Address (Cont)

AGW IPv6 (V=1) Address (Cont)

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 x0 + x1 + x2 + x4 + x5 + x7 + x8 + x10 + x11 + x12 + x16 + x22 + x23 + x26 + x32 .

• 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