Tony, my apologizes for being late with an update for hIPv4.
Since the IP option isn't doable I had to move the extensions to a shim header, thus the text needs be updated. I also had to remove the text mentioning that hIPv4 might be integrated to a map&encap solution - I think it is still possible but haven't explained how - my day work has and is taking all time. -- patte On Sat, Feb 27, 2010 at 5:59 AM, Tony Li <tony...@tony.li> wrote: > > FYI... > > This is just a working draft. > > Please recall that our deadline for a 'counterpoint' contribution is Mar. 2, > next Tues. And our final deadline for document submission prior to IETF is > Mar. 8. I can make no promises for anything to be included that is received > after Mar. 2. > > Regards, > Tony > > > > ------ Forwarded Message > From: <internet-dra...@ietf.org> > Reply-To: <internet-dra...@ietf.org> > Date: Fri, 26 Feb 2010 18:30:02 -0800 (PST) > To: <i-d-annou...@ietf.org> > Subject: I-D Action:draft-irtf-rrg-recommendation-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Recommendation for a Routing Architecture > Author(s) : T. Li > Filename : draft-irtf-rrg-recommendation-05.txt > Pages : 62 > Date : 2010-02-26 > > It is commonly recognized that the Internet routing and addressing > architecture is facing challenges in scalability, multi-homing, and > inter-domain traffic engineering. This document surveys many of the > proposals that were brought forward for discussion in this activity, > as well as some of the subsequent analysis. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-irtf-rrg-recommendation-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > ------ End of Forwarded Message > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > >
5. hIPv4 5.1. Summary 5.1.1. Key Idea The hierarchical IPv4 framework is adding scalability in the routing architecture by introducing hierarchy in the IPv4 address space. The IPv4 addressing scheme is divided into two parts, the Area Locator (ALOC) address space which is globally unique and the Endpoint Locator (ELOC) address space which is only regionally unique. The ALOC and ELOC prefixes are added as a shim header between the IP header and transport protocol header, the shim header is identified with a new protocol number in the IP header. Instead of creating a tunneling (i.e. overlay) solution a new routing element is needed in the service providers routing domain (called ALOC realm) - a Locator Swap Router. The current IPv4 forwarding plane remains intact, also no new routing protocols, mapping systems or caching solutions are required. The control plane of the ALOC realm routers needs some modification in order for ICMP to be compatible with the hIPv4 framework. When an area (one or several AS) of an ISP has transformed into an ALOC realm only ALOC prefixes are exchanged with other ALOC realms. Directly attached ELOC prefixes are only inserted to the RIB of the local ALOC realm, ELOC prefixes are not distributed to the DFZ. Multi-homing can be achieved in two ways, either the enterprise request an ALOC prefix from the RIR (this is not recommended) or the enterprise receive the ALOC prefixes from their upstream ISPs ELOC prefixes are PI addresses and remains intact when a upstream ISP is changed, only the ALOC prefix is replaced. When the RIB of DFZ is compressed (containing only ALOC prefixes) no longer an ingress router knows the availability of the destination prefix, thus the endpoints must take more responsibility for their sessions. This can be achieved by using multipath enabled transport protocols, such as SCTP (RFC 4960) and Multipath TCP (MPTCP), at the endpoints. The multipath transport protocols also provides a session identifier, i.e. verification tag or token, thus the location and identifier split is carried out - site mobility, endpoint mobility and mobile site mobility is achieved. DNS needs to be upgraded, in order to resolve the location of an endpoint the endpoint must have one ELOC value (current A-record) and at least one ALOC value in DNS (in multi-homing solutions there will be several ALOC values for an endpoint). 5.1.2. Gains 1. Improved routing scalability: Adding hierarchy in the address space enables a new hierarchy in the routing architecture. Early adapters of an ALOC realm will no longer carry the current RIB of the DFZ - only ELOC prefixes of their directly attached networks and ALOC prefixes from other service provider that have migrated are installed in the ALOC realms RIB. 2. Scalable support for traffic engineering: Multipath enabled transport protocols are recommended to achieve dynamic load-balancing of a session. Support for Valiant Load-balancing schemes has been added to the framework; more research work is required around VLB switching. 3. Scalable support for multi-homing: Only attachment points (ALOC prefix) of a multi-homed site are advertised in the DFZ, DNS will inform the requester on how many attachment points the destination endpoint has. It is the initiating endpoints choice/responsibility which attachment point is used for the session; endpoints using multipath enabled transport protocols can make use of several attachment points for a session. 4. Simplified Renumbering: When changing provider, the local ELOC prefixes remains intact, only the ALOC prefix is changed at the endpoints. The ALOC prefix is not used for routing or forwarding decisions in the local network. 5. Decoupling Location and Identifier: The verification tag (SCTP) and token (MPTCP) can be considered to have the characteristics of a session identifier and thus a session layer is created between the transport and application layer in the TCP/IP model. 6. Routing quality: The hIPv4 framework introduce no tunneling or caching mechanisms, only a swap of the content in the IPv4 header and locator header at the destination ALOC realm is required, thus current routing and forwarding algorithms are preserved as such. Valiant Load-balancing might be used as a new forwarding mechanism. 7. Routing Security: Similar as with today's DFZ, except that ELOC prefixes can not be high-jacked (by injecting a longest match prefix) outside an ALOC realm. 8. Deployability: The hIPv4 framework is an evolution of the current IPv4 framework and is backwards compatible with the current IPv4 framework. Sessions in a local network and inside an ALOC realm might in the future still use the current IPv4 framework. 5.1.3. Costs And Issues 1. Upgrade of the stack at an endpoint that is establishing sessions outside the local ALOC realm. 2. In a multi-homing solution the border routers should be able to apply policy based routing upon the ALOC value in the locator header. 3. New IP allocation policies must be set by the RIRs. 4. Short timeframe before the expected depletion of the IPv4 address space occurs. 5. Will enterprises give up their current globally unique IPv4 address block allocation they have gained? 6. Coordination with MPTCP is highly desirable.
_______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
