Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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 [MNCN] MN CN Reference architecture (cont’d) LMA1 LMA2 Relevant network and interfaces for the protocol solution! Non-optimized data path MAG1 Forwarding Tunnel data [MNCN] 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 BA MAG1 MAG2 BA 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?