Download Localized Routing

PMIPv6 Localized Routing
Problem Statement
draft-liebsch-netext-pmip6-ro-ps-01.txt
Marco Liebsch, Sangjin Jeong, Qin Wu
IETF75 - Stockholm
NetExt WG, 30th July 2009
PMIPv6 Localized Routing
• Objective:
Establish and maintain (during handover) local
forwarding of packets for two MNs without traversing the
MNs’ LMA(s)
• Motivation
– Using the default path through the MNs’ mobility anchor(s) may
be sub-optimal for local communications inside a PMIPv6
domain
– Using a more direct path allows for
• Reducing the load from LMAs
• Potentially improves the end-to-end performance
(delay, packet loss)
Problem description
• Mobile nodes have no control on setting up localized
routes
– Fundamental difference to host mobility, such as Mobile IPv6
route optimization
• Infrastructure components need to take over the role to
set up and maintain states for localized routing
– Detection of when to set up localized routing
– Initiation of signaling to set up routing states
– Possibly discovery of relevant stateful entities to address
signaling for localized routing
– Control about updating localized routing states in case of
handover
– Termination of localized routing
Reference architecture
LMA1
Relevant network
and interfaces for
the protocol
solution!
LMA2
Non-optimized
data path
Optimized
data path
MAG1
MAG2
Forwarding Tunnel
data [MNCN]
MN
CN
Reference architecture (cont’d)
LMA1
LMA2
Relevant network
and interfaces for
the protocol
solution!
Non-optimized
data path
MAG1
Forwarding Tunnel
data
[MNCN]
Optimized
data path
MN
CN
Changes in version 01
• Added note about RFC5213 understanding of localized
routing and relevance in NetExt (Carlos)
• Added functional requirement to terminate localize
routing states (Hidetoshi)
• Some editorial revision
• Added chapter about IPv4 considerations
Before entering the solution
space…
...we need to agree on a couple of things
Agree on term
•
•
•
•
Localized Routing vs. Route Optimization
Different understanding (MAG-local, Domain-local)
Even charter mixes both
So far agreement to stick to Localized Routing...
– ...but includes optimized routing path beyond a single MAG!
Agree on scope
• Functional Use cases
– Single MAG
– Multiple MAGs
– Multiple LMAs
• IPv4 considerations
–
–
–
–
Localized Routing between IPv4 HoAs
IPv4 Address space overlap
IPv4 Transport Network issues
NAT presence issues
IPv4 HoA Localized Routing
Requirements
• Encapsulation of IPv4 packets at MAG
• Routing state for each MN-CN pair
• Source/Dest routing for localized routing of uplink
packets at MAGs
General question
• Encapsulation mode negotiation between MAGs?
– Proposal: Lightweight capabilty exchange with selection
IPv4 Transport Network
• MAGs may use different transport to LMA
• Negotiate transport between MN‘s and CN‘s MAG?
IPv4 Address space overlap
• Same HoA assigned to multiple MNs (different
operators) from an overlapping address space
• Destination MAG (MAG1) issue
– Both MNs attached to the
same MAG
– Dispatch downlink traffic
LMA1
• Source MAG (MAG2) issue
– Both MNs attach to
different MAGs
– Select correct tunnel
• GRE Key negotiation
phase in scope of
protocol solution?
LMA2
BA
MAG1
MAG2
BA
MNa MNb
IP: A IP: A
CN
IP: B
NAT presence
• NAT between MAGs
– Real issue for LR in single PMIPv6 domain?
– NAT detection and NAT traversal mechanism in scope of
solution?
• NAT between LMAs
– Real issue for LR in single PMIPv6 domain?
– NAT detection and NAT traversal mechanism in scope of
solution?
Last but not least…
• Status: Problem statement document mature and covers
all discussed items
– Anything missing?
– More comments?
• WG indicated interest in having an Informational PS for
Localized Routing
• Make this draft a WG document?