1 / 26

Network Localized Mobility Management using DHCP

Network Localized Mobility Management using DHCP. fred.l.templin@boeing.com. Global Internet. NETLMM Domain A. NETLMM Domain A. NETLMM Domain B. Mobile Nodes. localized mobility. NETLMM Problem Space. global mobility (out-of-scope). NETLMM Goals.

heath
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 fred.l.templin@boeing.com

  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. NETLMM Goals • support NETLMM domains as small as a home network or as large a major operator network, e.g., metropolitan region WiFi • MNs keep same addresses/prefixes as they move within a NETLMM domain (global mobility out-of-scope) • support session continuity across mobility events • avoid routing churn by having Mobility Anchor Points that aggregate the NETLMM domain (as opposed to tracking node mobility via a routing protocol)

  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. Model of Operation • MN discovers ARs via RFC2461 Router Advertisements (RAs) • If RAs contain prefix options, MN can configure addresses using RFC2462, then “register” them with the network by sending DHCP Solicit/Request with IP address options • If RAs contain no prefix options, or if prefix delegation is desired, MN requests prefixes by sending DHCP Solicit/Request per RFC3633 • AR relays DHCP Solicit/Request to a DHCP server associated with a MAP

  7. Model of Operation (cont’d) • DHCP server registers addresses/prefixes, then issues “create tunnel”; “route add” to update MAP IP forwarding table(s) • DHCP server sends reply to MN which is intercepted by AR; AR performs a local “route add” • Now, traffic from the Internet destined to MN flows through the MAP(s) and is directed to the correct AR • If MN moves to a new AR, MN issues a DHCP Confirm which causes the MAPs and ARs to update their IP forwarding tables

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

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

  10. Additional Considerations • Works with IPv4 as well as IPv6 (IPv6 has some advantages) • Supports DHCPv6 prefix delegation (delegated prefixes move along with the MN) • tunnels from MAPs to ARs can be unidirectional • Explicit messaging between MAPs and ARs might be better than implicit route add/delete based on DHCP messages – being worked in IETF NETLMM wg

  11. Additional Considerations (cont’d) • With multiple ARs on the link, ambiguous as to which AR is selected in MAP forwarding tables – MN can assert AR selection by sending L3 multicast DHCP Solicit/Request to unicast L2 address of a specific AR • global addressing goes through MAPs, but efficient local communications can be supported using IPv6 ULAs (could result in dropped calls) • Since MNs can move freely between access networks, Redirects could cause dropped calls. ARs on NETLMM links should therefore not send redirects.

  12. Issues • can DHCP Confirm be used to test whether a delegated prefix is appropriate for the new link. If not, why not? • with all global addresses/prefixes delegated by DHCP server, no need for DAD on NETLMM links? • link-local addresses can also be registered with DHCP server. Again, no need for DAD?

  13. MANET Autoconfiguration using DHCP fred.l.templin@boeing.com

  14. Provide Network(s) MANET Gateways (MGs) MANETs MANET Routers MANET Autoconf Problem Space

  15. MANET Routing Alternatives • MANET routing as a L2 mechanism w/no L2 multicast flooding – MANET looks like an NBMA link that connects routers/gateways (no gateway discovery; not considered further) • MANET routing as a L2 mechanism w/L2 multicast flooding - MANET looks like a bridged campus LAN (no special MANET Autoconf extensions needed) • MANET routing as a L3 mechanism w/no L3 multicast flooding – MANET looks like multiple links w/no multicast (no gateway discovery; not considered further) • MANET routing as a L3 mechanism w/L3 multicast flooding – MANET looks like multiple links w/MANET-wide (site-scoped) multicast (subject of this proposal)

  16. MANET Autoconf Goals • MANET Routers (MRs) must be able to discover MANET Gateways (MGs) even if they are multiple L3 hops away • MRs must be able to obtain global IP address/prefix delegations • support for multiple MGs • support for intra- and inter-MANET mobility for MRs • Support for both IPv6 and IPv4

  17. MANET Autoconf Using DHCP • Let each MR and MG configure a MANET Local Address (MLA) for routing protocol operation; local communications (for IPv6, likely to be RFC4193 ULAs) • Let each MR be a DHCP client • Let each MG be a DHCP Relay/Server • Let there be a means for MRs and MGs to send “Extended” RS, RA and DHCP messages

  18. Extended RS, RA and DHCP Msgs • normal RS/RA/DHCP message configured per RFC2461, RFC3315, RFC3633 • message encapsulated in outer IP header with: • src = MLA of sender • dst = Site-scoped multicast, or MLA of target • Hop Limit = small integer value (e.g., 2, 5, 10) • message “tunneled” to one or more recipients

  19. Extended RS, RA and DHCP Msgs Normal RS/RA/DHCP Message Message src=LL/Unspec dst=All_*_Multicast Hop Limit = 255 Inner IP header src=MLA(sender) dst=Site-scope Multicast or MLA(target) Hop Limit = 2,5,10,etc Outer IP header

  20. Model of Operation • MR discovers MGs via Extended RAs (ERAs) (MR sends ERSs if necessary) • If ERAs contain prefix options, MR can configure addresses using RFC2462, then “register” them with the network by sending Extended DHCP Solicit/Request with IP address options • If ERAs contain no prefix options, or if prefix delegation is desired, MR requests prefixes by sending Extended DHCP Solicit/Request per RFC3633 • MG decapsulates the Extended DHCP Solicit/Request and relays it to a local DHCP server or a server in the provider network

  21. Model of Operation (cont’d) • DHCP server sends reply to MR which is intercepted by MG; MG performs a “route add” and “create tunnel” for MR • MR receives the DHCP reply and performs a “route add” and “create tunnel” for MG • Now, packets from the Internet destined to MR are directed to MG which tunnels them to MR, and packets from MR destined to the Internet are tunneled to MG • If MR moves to new MG, it sends an Extended DHCP Confirm which causes MGs to update their IP forwarding tables

  22. Route/Tunnel Configuration after MR1 conf’s address/prefix via MG1 MG2 MG1 MR1 defaultMLA(MG1) MLA(MG1)tunnel MR1MLA(MR1) MLA(MR1)tunnel

  23. Route/Tunnel Configuration after MR1 moves within MANET MG2 MG1 MR1 defaultMLA(MG1) MLA(MG1)tunnel MR1MLA(MR1) MLA(MR1)tunnel

  24. Route/Tunnel Configuration after move to MG2 in same MANET MG2 MR1MLA(MR1) MLA(MR1)tunnel MR1 defaultMLA(MG2) MLA(MG2)tunnel MG1

  25. Route/Tunnel Configuration after move to MG3 in new MANET MG2 MG2, MG3 connected to same provider MG1 MG3 MR1MLA(MR1) MLA(MR1)tunnel MR1 defaultMLA(MG3) MLA(MG3)tunnel

  26. Additional Considerations • Compatible with “NETLMM using DHCP” • Works with IPv4 as well as IPv6 (IPv6 has some advantages) • For IPv4, need a new option (“MLA Option”) to inform relay of MR’s MLA for last-hop forwarding purposes • Supports DHCPv6 prefix delegation (delegated prefixes move along with the MN) • tunnels from MGs to MRs are bi-directional (but, tunneling from MR to MG can be omitted if “default” is propagated through MANET)

More Related