1 / 40

Hierarchical IPv4 Framework

Hierarchical IPv4 Framework. Patrick Frejborg pfrejborg@gmail.com 18 Dec 2009. Why hIPv4 ?. Addressing RFC 4984

glenys
Download Presentation

Hierarchical IPv4 Framework

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. Hierarchical IPv4 Framework Patrick Frejborg pfrejborg@gmail.com 18 Dec 2009

  2. Why hIPv4 ? • Addressing RFC 4984 It is commonly recognized that today’s Internet routing and addressing system is facing serious scaling problems. The ever increasing user population, as well as multiple other factors including multi-homing, traffic engineering, and policy routing, have been driving the growth of the Default Free Zone (DFZ) routing table size at an increasing and potentially alarming rate. While it has been long recognized that the existing routing architecture may have serious scalability problems, effective solutions have yet to be identified, developed, and deployed.

  3. Influence sources • The Locator/Identifier Separation Protocol research work at RRG • MPLS solutions, mainly the shim header that made it possible to create new services on top of an IP backbone • Anycast Rendezvous Point (RP) with Multicast Source Discovery Protocol (MSDP) • PSTN hierarchical numbering scheme • Active participants on the RRG mailing-list • Multipath enabled transport protocols, SCTP and MTCP

  4. Adding scalability by introducing hierarchy in the address space • Global Locator Block (GLB) • An IPv4 address block that is globally unique. • Area Locator (ALOC) • An IPv4 address assigned to locate an ALOC realm in Internet. The ALOC is assigned by a RIR to a service provider or a multi-homed enterprise. The ALOC is globally unique because it is allocated from the GLB. • Endpoint Locator (ELOC) • An IPv4 address assigned to locate an endpoint in an ALOC realm. The ELOC block is assigned by a RIR to a service provider or to an enterprise. The ELOC block is only unique in a geographical region or globally unique in a business area defined by the RIRs. The final policy of uniqueness shall be defined by the RIRs.

  5. The hIPv4 header • IPv4 header still valid, new IP option added – idea similar as in MPTCP and RFC1385 • New IP option called locator header

  6. Fundamental elements • ALOC realm • An area in the Internet with at least one attached Locator Swap Router (LSR), also an ALOC must be assigned to the ALOC realm. The RIB of an ALOC realm holds both local ELOC prefixes and global ALOC prefixes. An ALOC realm exchanges only ALOC prefixes with other ALOC realms. • Locator Swap Router (LSR) • A router or node which iscapable to process the hIPv4 header; once the header is processed the LSR will forward the packet upon the IPv4 destination address. The LSR must have the ALOC assigned as its locator.

  7. LSR per packet tasks (the swap) • verify the received packet that it uses the locator header ID in the IP option field • verify IP and transport header checksums • replace the source address in the IPv4 header with the ALOC value of the locator header • replace the destination address in the IPv4 header with the ELOC value of the locator header • replace the ALOC value in the locator header with the destination IP address of the IPv4 header • replace the ELOC value in the locator header with the source IP address of the IPv4 header • set the S-field to 1 • decrease TTL value with one • calculate IP and transport protocol checksums • forward the packet upon the destination IP address of the IPv4 header • No FIB nor cache required at the LSR

  8. Life of a hIPv4 session

  9. Client -> server www.foo.com? S:10.1.1.1 D:10.2.2.2 SWAP S:10.1.1.1 D:172.16.0.5 A-record: 10.2.2.2ALOC: 172.16.0.5 A:172.16.0.3 E:10.2.2.2 S:172.16.0.3 D:10.2.2.2 A:172.16.0.5 E:10.1.1.1 S:172.16.0.3 D:10.2.2.2 S:10.1.1.1 D:10.2.2.2 A:172.16.0.5 E:10.1.1.1 S:10.1.1.1 D:172.16.0.5 A:172.16.0.3 E:10.2.2.2 IPv4 API IPv4 header Locator header

  10. Client -> server, return path S:10.2.2.2 D:10.1.1.1 S:10.2.2.2 D:172.16.0.3 S:10.2.2.2 D:10.1.1.1 S:172.16.0.5 D:10.1.1.1 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:172.16.0.3 A:172.16.0.3 E:10.2.2.2 S:172.16.0.5 D:10.1.1.1 A:172.16.0.5 E:10.1.1.1 A:172.16.0.3 E:10.2.2.2 SWAP IPv4 API IPv4 header Locator header

  11. Multi-homing and impact on DFZ

  12. The new routing architecture 172.16.0.5 /32172.16.0.1 /32172.16.0.4 /32172.16.0.5 /3210.2.2.0 /24 172.16.0.5 /32172.16.0.1 /32172.16.0.4 /32172.16.0.5 /3210.1.1.0 /24 172.16.0.5 /32172.16.0.1 /32172.16.0.4 /32172.16.0.5 /32 172.16.0.5 /32172.16.0.1 /32172.16.0.4 /32172.16.0.5 /3210.2.2.0 /24 Advertizing whole RIB of the ALOC realm, generating 0.0.0.0/0 towards DFZ Advertizing only ALOC prefixes

  13. Multi-homing becomes multi-pathing SWAP S:172.16.0.3 D:10.2.2.2 S:10.1.1.1 D:172.16.0.4 A:172.16.0.4 E:10.1.1.1 S:10.1.1.1 D:172.16.0.4 A:172.16.0.3 E:10.2.2.2 A:172.16.0.3 E:10.2.2.2 New subflowPolicy-based routing,Valiant load-balancing S:10.1.1.1 D:172.16.0.5 S:10.1.1.1 D:172.16.0.5 A:172.16.0.3 E:10.2.2.2 A:172.16.0.3 E:10.2.2.2 S:172.16.0.3 D:10.2.2.2 A:172.16.0.5 E:10.1.1.1 S:10.1.1.1 D:10.2.2.2 SWAP S:10.1.1.1 D:10.2.2.2 www.foo.com? IPv4 API A-record: 10.2.2.2ALOC: 172.16.0.5ALOC: 172.16.0.4 IPv4 header Locator header

  14. Integrating hIPv4 with map-and-encapsulate solutions

  15. Fundamental elements • Three types of locator is needed • Endpoint Locator, ELOC (regionally unique) • Area Locator, ALOC (globally unique) • Routing Locator, RLOC (globally unique) • DNS need to have two new records, for ALOC and RLOC but an endpoint have only one type of record (ALOC or RLOC) in DNS • MPTCP is used to achieve new type of multi-homing at hIPv4 enabled sites, i.e. migrating from multi-homing to multi-pathing • ITR/ETR should support MPTCP and the hIPV4 framework • Outcome is that the Internet citizen can choose the upgrade path that is most convenient for him • Note! Scenario not yet documented in draft-frejborg-hipv4!

  16. Legacy client -> hIPv4 server S:10.1.1.1.1 D:10.2.2.2 S:10.1.1.1 D:172.16.0.5 A:192.168.0.1 E:10.2.2.2 S:192.168.0.1 D:10.2.2.2 S:10.1.1.1 D:10.2.2.2 A:172.16.0.5 E:10.1.1.1 ReplyALOC 172.16.0.5ALOC 172.16.0.4 SWAP www.foo.com? S:192.168.0.1 D:10.2.2.2 Mapping RequestWhere is 10.2.2.2? A-record: 10.2.2.2 A:172.16.0.5 E:10.1.1.1 S:10.1.1.1 D:10.2.2.2 IPv4 API IPv4 header Locator header

  17. Legacy client -> hIPv4 server, return path S:10.2.2.2 D:192.168.0.1 S:10.2.2.2 D:10.1.1.1 S:10.2.2.2 D:192.168.0.1 A:172.16.0.5 E:10.1.1.1 A:172.16.0.5 E:10.1.1.1 S:10.1.1.1.1 D:10.2.2.2 S:10.1.1.1 D:172.16.0.5 A:192.168.0.1 E:10.2.2.2 S:10.2.2.2 D:192.168.0.1 S:10.2.2.2 D:10.1.1.1 A:172.16.0.5 E:10.1.1.1 S:192.168.0.1 D:10.2.2.2 S:10.1.1.1 D:10.2.2.2 A:172.16.0.5 E:10.1.1.1 ReplyALOC 172.16.0.5ALOC 172.16.0.4 SWAP www.foo.com? S:192.168.0.1 D:10.2.2.2 Mapping RequestWhere is 10.2.2.2? A-record: 10.2.2.2 A:172.16.0.5 E:10.1.1.1 S:10.1.1.1 D:10.2.2.2 IPv4 API S:10.2.2.2 D:10.1.1.1 IPv4 header Locator header

  18. Legacy client -> hIPv4 server, adding MPTCP subflow S:192.168.0.1 D:10.2.2.2 SWAP A:172.16.0.4 E:10.1.1.1 S:10.1.1.1 D:172.16.0.4 A:192.168.0.1 E:10.2.2.2 S:10.1.1.1.1 D:10.2.2.2 S:10.1.1.1 D:172.16.0.5 A:192.168.0.1 E:10.2.2.2 S:192.168.0.1 D:10.2.2.2 S:192.168.0.1 D:10.2.2.2 S:10.1.1.1 D:10.2.2.2 A:172.16.0.4 E:10.1.1.1 A:172.16.0.5 E:10.1.1.1 ReplyALOC 172.16.0.5ALOC 172.16.0.4 SWAP www.foo.com? S:192.168.0.1 D:10.2.2.2 Mapping RequestWhere is 10.2.2.2? A-record: 10.2.2.2 A:172.16.0.5 E:10.1.1.1 S:10.1.1.1 D:10.2.2.2 IPv4 API IPv4 header Locator header

  19. hIPv4 client -> legacy server S:10.2.2.2 D:10.1.1.1 www.foo.com? A-record: 10.1.1.1RLOC:192.168.0.1RLOC:192.168.0.2 S:10.2.2.2 D:192.168.0.1 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:10.1.1.1 S:10.2.2.2 D:10.1.1.1 IPv4 API IPv4 header Locator header

  20. hIPv4 client -> legacy server, return path SWAP S:10.1.1.1 D:172.16.0.5 S:10.1.1.1 D:10.2.2.2 A:192.168.0.1 E:10.2.2.2 S:192.168.0.1 D:10.2.2.2 S:10.2.2.2 D:10.1.1.1 www.foo.com? A:172.16.0.5 E:10.1.1.1 A-record: 10.1.1.1RLOC:192.168.0.1RLOC:192.168.0.2 S:10.2.2.2 D:192.168.0.1 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 S:10.1.1.1 D:10.2.2.2 A:172.16.0.5 E:10.1.1.1 S:10.1.1.1 D:10.2.2.2 S:10.2.2.2 D:10.1.1.1 S:10.2.2.2 D:10.1.1.1 IPv4 API IPv4 header Locator header

  21. hIPv4 client -> legacy server, adding MPTCP subflow S:10.2.2.2 D:192.168.0.1 A:172.16.0.4 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 A:172.16.0.4 E:10.1.1.1 S:10.2.2.2 D:10.1.1.1 www.foo.com? A-record: 10.1.1.1RLOC:192.168.0.1RLOC:192.168.0.2 S:10.2.2.2 D:192.168.0.1 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.0.1 A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:10.1.1.1 S:10.2.2.2 D:10.1.1.1 IPv4 API IPv4 header Locator header

  22. The new routing architecture 172.16.0.3 /32172.16.0.4 /32172.16.0.5 /3210.2.2.0 /24192.168.0.0 /21192.168.8.0 /21192.168.16.0 /21 172.16.0.3 /32172.16.0.4 /32172.16.0.5 /3210.1.1.0 /24192.168.0.0 /21192.168.8.0 /21192.168.16.0 /21 172.16.0.3 /32172.16.0.4 /32172.16.0.5 /3210.2.2.0 /24192.168.0.0 /21192.168.8.0 /21192.168.16.0 /21 Advertizing whole RIB of the ALOC realm, generating 0.0.0.0/0 towards DFZ Advertizing only ALOC prefixes

  23. Multicast

  24. Multicast considerations • Source address (S) for a group (G) is no longer visible outside the local ALOC realm (only GLB prefixes are seen), therefore Reverse Path Forwarding (RPF) is only valid within the local ALOC realm • In order to enable RPF globally for a (S,G), the multicast enabled LSR (mLSR) must at the source ALOC realm replace the source address with the local ALOC identifier • LSR in the source ALOC realm shall act as an Anycast RP with MSDP capabilities • The mLSR will decide which multicast groups are announced to other ALOC realms • The receiver will locate the source via MSDP, the shared tree can be established to the mLSR • Source Specific Multicast schema will need an extension, ALOC options shall be added to SSM

  25. Multicast forwarding S:10.1.1.1 G:225.5.5.5 S:10.1.1.1 D:225.5.5.5 S:10.1.1.1 D:225.5.5.5 S:172.16.0.3 D:225.5.5.5 S:172.16.0.3 D:225.5.5.5 A:172.16.0.3 l E:10.1.1.1 S:172.16.0.3 D:225.5.5.5 S:10.1.1.1 D:225.5.5.5 A:172.16.0.3 E:10.1.1.1 A:172.16.0.3 E:10.1.1.1 A:172.16.0.3 E:10.1.1.1 SWAP IPv4 API IPv4 header Locator header

  26. RTCP receiver reports S:10.1.1.1 D:225.5.5.5 S:10.1.1.1 G:225.5.5.5 S:10.2.2.2 D:172.16.0.3 S:10.2.2.2 D:172.16.0.3 A:172.16.0.5 E:10.1.1.1 S:172.16.0.5 D:10.1.1.1 A:172.16.0.5 E:10.1.1.1 S:172.16.0.5 D:10.1.1.1 A:172.16.0.3 E:10.2.2.2 A:172.16.0.3 E:10.2.2.2 SWAP IPv4 API IPv4 header Locator header

  27. Mobility

  28. Mobility considerations • Site mobility: a site wishes to changes its attachment point to the Internet without changing its IP address block • The change of attachment point is possible when PI addresses are allocated to the site. Only ALOC prefix(es) needs to be changed at the endpoints. • Endpoint mobility: an endpoint moves relatively rapidly between different networks, changing its IP layer network attachment point • SCTP or MPTCP is providing “session mobility” on the transport layer • Mobile site: mobile vehicles that are crossing RIR boundaries and the vehicle (e.g. aircraft, train, ferry etc) carries a local network. • Depending upon forthcoming RIR policies, NAT might be needed, see following slides

  29. Mobile site: client -> server behind NAT S:10.2.2.2 D:192.168.1.1 S:10.2.2.2 D:10.1.1.1 S:10.2.2.2 D:172.16.0.3 PLR: 111A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.1.1 NAT S:172.16.0.5 D:10.1.1.1 S:10.2.2.2 D:172.16.0.3 PLR: 111A:172.16.0.3 E:10.2.2.2 PLR: 111A:172.16.0.5 E:10.1.1.1 SWAP www.foo.com? A-record: 10.1.1.1ALOC: 172.16.0.3PLR: 111A-record: 10.3.3.3ALOC: 172.16.0.1PLR: 111 IPv4 API IPv4 header Locator header

  30. Mobile site: client -> server behind NAT, return path S:192.168.1.1 D:10.2.2.2 S:10.2.2.2 D:192.168.1.1 S:10.1.1.1 D:172.16.0.5 SWAP NAT PLR: 111A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:10.2.2.2 S:172.16.0.3 D:10.2.2.2 S:10.1.1.1 D:172.16.0.5 PLR: 111A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:10.1.1.1 PLR: 111A:172.16.0.3 E:10.2.2.2 S:192.168.1.1 D:10.2.2.2 S:10.2.2.2 D:172.16.0.3 PLR: 111A:172.16.0.5 E:10.1.1.1 S:10.2.2.2 D:192.168.1.1 NAT S:172.16.0.5 D:10.1.1.1 S:10.2.2.2 D:172.16.0.3 PLR: 111A:172.16.0.3 E:10.2.2.2 PLR: 111A:172.16.0.5 E:10.1.1.1 SWAP www.foo.com? A-record: 10.1.1.1ALOC: 172.16.0.3PLR: 111A-record: 10.3.3.3ALOC: 172.16.0.1PLR: 111 IPv4 API IPv4 header Locator header

  31. Mobile site: client -> server behind NAT, adding subflow S:10.3.3.3 D:172.16.0.5 S:192.168.1.1 D:10.2.2.2 PLR: 111A:172.16.0.1 E:10.2.2.2 SWAP NAT S:10.1.1.1 D:10.2.2.2 A:172.16.0.1 E:10.2.2.2 PLR: 111A:172.16.0.5 E:10.3.3.3 S:192.168.1.1 D:10.2.2.2 S:10.1.1.1 D:172.16.0.5 S:10.1.1.1 D:172.16.0.5 PLR: 111A:172.16.0.3 E:10.2.2.2 PLR: 111A:172.16.0.3 E:10.2.2.2 S:172.16.0.3 D:10.2.2.2 PLR: 111A:172.16.0.5 E:10.1.1.1 NAT SWAP www.foo.com? A-record: 10.1.1.1ALOC: 172.16.0.3PLR: 111A-record: 10.3.3.3ALOC: 172.16.0.1PLR: 111 IPv4 API IPv4 header Locator header

  32. Mobile site: client -> server behind NAT, roaming completed S:10.3.3.3 D:172.16.0.5 S:192.168.1.1 D:10.2.2.2 PLR: 111A:172.16.0.1 E:10.2.2.2 SWAP NAT S:10.1.1.1 D:10.2.2.2 A:172.16.0.1 E:10.2.2.2 PLR: 111A:172.16.0.5 E:10.3.3.3 S:192.168.1.1 D:10.2.2.2 www.foo.com? A-record: 10.1.1.1ALOC: 172.16.0.3PLR: 111A-record: 10.3.3.3ALOC: 172.16.0.1PLR: 111 IPv4 API IPv4 header Locator header

  33. Mobile site: client behind NAT -> server S:192.168.1.1 D:10.2.2.2 S:10.1.1.1 D:10.2.2.2 S:192.168.1.1 D:172.16.0.5 S:10.1.1.1 D:172.16.0.5 A:0.0.0.0 E:10.2.2.2 A:172.16.0.3 E:10.2.2.2 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 A:172.16.0.5 E:10.1.1.1 A:172.16.0.3 E:10.2.2.2 SWAP NAT www.foo.com? A-record: 10.2.2.2ALOC: 172.16.0.5 IPv4 API IPv4 header Locator header

  34. Mobile site: client behind NAT -> server, adding subflow S:192.168.1.1 D:10.2.2.2 S:10.3.3.3 D:172.16.0.5 SWAP A:172.16.0.1 E:10.2.2.2 NAT S:10.3.3.3 D:10.2.2.2 S:172.16.0.1 D:10.2.2.2 A:172.16.0.5 E:10.3.3.3 S:10.1.1.1 D:10.2.2.2 S:192.168.1.1 D:172.16.0.5 S:10.1.1.1 D:172.16.0.5 A:0.0.0.0 E:10.2.2.2 A:172.16.0.3 E:10.2.2.2 A:172.16.0.3 E:10.2.2.2 S:10.1.1.1 D:172.16.0.5 A:172.16.0.5 E:10.1.1.1 A:172.16.0.3 E:10.2.2.2 SWAP NAT www.foo.com? A-record: 10.2.2.2ALOC: 172.16.0.5 IPv4 API IPv4 header Locator header

  35. Mobile site: client behind NAT -> server, roaming completed S:192.168.1.1 D:10.2.2.2 S:10.3.3.3 D:172.16.0.5 SWAP A:172.16.0.1 E:10.2.2.2 NAT S:10.3.3.3 D:10.2.2.2 S:172.16.0.1 D:10.2.2.2 A:172.16.0.5 E:10.3.3.3 S:192.168.1.1 D:172.16.0.5 A:0.0.0.0 E:10.2.2.2 www.foo.com? A-record: 10.2.2.2ALOC: 172.16.0.5 IPv4 API IPv4 header Locator header

  36. Traffic Engineering

  37. Traffic Engineering considerations • Load balancing is influenced by the placement of LSRs within a ALOC realm; LSR provides a “nearest routing” scheme • A service provider might have several ALOC assigned; traffic engineering and filtering can be done upon ALOC addresses • If needed an ALOC identifier based Traffic Engineering solution might be developed. Establish explicit routing paths upon ALOC prefixes, that is create explicit paths that can be engineered via specific ALOC realms. • Valiant Load-Balancing can be added, more studies is required around this technology

  38. Summary

  39. Cost and issues • Upgrade of the stack at an endpoint or the endpoint should make useof an ITR/XTR • In a multi-homing solution the border routers should be able toapply policy based routing upon the ALOC value in the locator header • New policies must be set by the RIRs • Short timeframe before the expected depletion of the IPv4 address space occurs • Will enterprises give up their global allocation of the current IPv4 address block they have gained? • Co-ordination with MPTCP is highly desirable

  40. Carrots for everyone • Enterprises • No need to learn a totally new protocol • Minimize porting of applications to a new protocol, IPv4 socket API is extended • Achieve site mobility • MPTCP and SCTP supports endpoint mobility • Remove IPv4 address constraints • Internet Service Providers • No need to learn new routing protocols • Remove IPv4 address constraints • Hierarchical routing architecture, smaller RIB for each ALOC realm • Internal prefix flaps are not seen in other ALOC realms, only GLB state changes are reflected globally – “update churn” is reduced

More Related