Presentation on theme: "Hierarchical IPv4 Framework Patrick Frejborg 18 Dec 2009."— Presentation transcript:
Hierarchical IPv4 Framework Patrick Frejborg firstname.lastname@example.org 18 Dec 2009
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.
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
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.
The hIPv4 header IPv4 header still valid, new IP option added – idea similar as in MPTCP and RFC1385 New IP option called locator header
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 is capable 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.
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
Integrating hIPv4 with map-and- encapsulate solutions
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!
The new routing architecture 172.16.0.3 /32 172.16.0.4 /32 172.16.0.5 /32 10.1.1.0 /24 192.168.0.0 /21 192.168.8.0 /21 192.168.16.0 /21 172.16.0.3 /32 172.16.0.4 /32 172.16.0.5 /32 10.2.2.0 /24 192.168.0.0 /21 192.168.8.0 /21 192.168.16.0 /21 Advertizing whole RIB of the ALOC realm, generating 0.0.0.0/0 towards DFZ Advertizing only ALOC prefixes
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
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
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
Cost and issues Upgrade of the stack at an endpoint or the endpoint should make use of an ITR/XTR In a multi-homing solution the border routers should be able to apply 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
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