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 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:
> Reply-To:
> Date: Fri, 26 Feb 2010 18:30:02 -0800 (PST)
> To:
> 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 pre
