Upload
oswald-stokes
View
218
Download
0
Embed Size (px)
Citation preview
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