1 / 15

Network Localized Mobility Management using DHCP

Network Localized Mobility Management using DHCP. draft-templin-autoconf-netlmm-dhcp-04 fred.l.templin@boeing.com IETF67 –DHCP wg. Global Internet. NETLMM Domain A. NETLMM Domain A. NETLMM Domain B. Mobile Nodes. localized mobility. NETLMM Problem Space. global mobility

wardell
Download Presentation

Network Localized Mobility Management using DHCP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Network Localized Mobility Management using DHCP draft-templin-autoconf-netlmm-dhcp-04 fred.l.templin@boeing.com IETF67 –DHCP wg

  2. Global Internet NETLMM Domain A NETLMM Domain A NETLMM Domain B Mobile Nodes localized mobility NETLMM Problem Space global mobility (out-of-scope)

  3. Problem Statement and Goals • support NETLMM domains as small as a home network or as large a major operator network, e.g., metropolitan region WiFi, cellular, etc. • MNs keep same addresses/prefixes as they move within a NETLMM domain (global mobility out-of-scope) • support session continuity across mobility events • reduce routing churn (avoid tracking MNs via IGP) • Problem Statement: draft-ietf-netlmm-nohost-ps-05.txt • Goals: draft-ietf-netlmm-nohost-req-05.txt • TODO: match up NETLMM/DHCP proposal with goals

  4. NETLMM Domain Backhaul Network Access Rtrs (ARs) Mobility Anchor Point(s) (MAPs) Access Networks Mobile Nodes (MNs)

  5. NETLMM Using DHCP • Let each MN be a DHCP client • Let each AR be a DHCP Relay • Let each MAP be associated with a DHCP server (no need for them to be co-located)

  6. Route/Tunnel Configuration after MN config’s address/prefix via AR1 MN1AR1 AR1tunnel MN1on-link AR1 AR2 MN1

  7. MN1 Route/Tunnel Configuration After MN moves to AR2 MN1AR2 AR2tunnel AR1 AR2 MN1on-link

  8. New since -02 version(current version is -04) • AR now has DHCP client co-resident with DHCP relay • Fast/reliable mechanism for deleting stale state in old AR (missing in -02) • Network-initiated handovers • Support for SLAAC-only Mobile Nodes (aka “Proxy-DHCP”) • (Only discussing IPv6 here, but IPv4 also supported)

  9. DHCP Client DHCP Relay lo0 Access Router Backhaul network Access network eth0 eth1 AR Client/Relay Configuration • DHCP client/relay co-resident; use lo0 interface • Relay responsible for managing IP forwarding table (examines messages for RAAN options, aka CSRs) • Client responsible for reliable exchanges, network-initiated handovers and address registration proxy for non-DHCP MNs

  10. Deleting State in Old AR • MAP performs handover exchange with new AR via MN’s Confirm/Rebind (or network-initiated handover) • MAP sends Reconfigure to old AR • Old AR’s client function sends Information-Request to MAP wrapped in Relay-forward message • MAP sends Reply with CSR options to old AR’s client function via old AR’s relay function

  11. Network-initiated handovers • New AR detects MN coming onto its link via L2 signal • New AR’s client function sends immediate Information-request to MAP (wrapped in Relay-forward message) with CSR option that includes Client ID option with DUID for client • MAP sends Reply to new AR’s client function with CSR options for MN via new AR’s relay function • MAP sends simultaneous Reconfigure to old AR’s client function to delete old state

  12. Support for SLAAC-only MNs(aka “Proxy-DHCP”) • SLAAC-only MN sends NS(DAD) for tentative address • AR’s client function sends immediate Information-request to MAP (wrapped in Relay-forward message) with CSR option with IA_NA that encapsulates the tentative address and Client ID for client • MAP sends Reply to AR’s client function with CSR options for MN via new AR’s relay function • Proxy-DAD needed in case MAP detects duplicate (TBD)

  13. Notes • Use Server Reply Sequence Number (SRSN) wherever RAAN options are used • Allow AR’s client function to act as both “Responder” for NETLMM signaling and ordinary client for AR auto-configuration • Need to specify proxy/relay-DAD so that MNs using SEND/CGA that configure duplicate addresses will be detected

  14. Technical Questions • Can we rename RAAN as “Classless Static Route (CSR) option for DHCPv6”? Reasons: • symmetry with DHCPv4 • “promotes” existing DHCPv4 option to DHCPv6 • simplifies documentation (“CSR” used for both DHCPv6; DHCPv4) • Can Reconfigure message carry CSR options (instead of waiting for Info-request/Reply)? • Can Solicit/Reply be used instead of Info-request/Reply for “Proxy-DHCP”?

  15. Big-Picture Questions • Should there be a DHCP wg liaison to the NETLMM wg? • Can this work be combined with the NETLMM design team specification as input for a possible DHCPv6(bis) effort? • Can this work be taken as a DHCP wg item?

More Related