Re: [rrg] belated msg: further description of the recommendation process

[Patrick Frejborg <[e-mail]>]

On Fri, Dec 11, 2009 at 7:53 AM, Lixia Zhang <[e-mail]> wrote:
> sorry folks, day job crisis delayed this msg for a few days.
>
> Tony and I have had some discussions on how to collect the recommendation
> document.  One comment we have heard repeated from a number of people is
> that our recommendation should document the pros and cons of different
> approaches, which can be very valuable, even independent from whichever
> specific recommendations we may end up with.
>
> 1/ To steer efforts toward that goal, we would like each proposal to make a
> concise summary, preferably no longer than ~1000 words (it may contain
> pointer to more detailed document), that describes the key ideas of the
> proposal of exactly how it addresses routing scalability issue, where is its
> cost, and where is its gain.
>
Hi Lixia and Tony,

a summary of the hIPv4 framework follows

1. Key idea
The hierarchical IPv4 framework is adding scalability in the routing
architecture by introducing hierarchy in the IPv4 address space. The
hIPv4 addressing scheme is divided in 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 an IP option to the IPv4 header as
described in RFC 1385. Instead of creating a tunneling (i.e. overlay)
solution a new routing element is needed in every ALOC realm, a
Locator Swap Router - the current IPv4 forwarding plane remains
intact, also no new routing protocols or mapping systems 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 become 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 in 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 prefixes is
replaced. When the RIB of DFZ is compressed no longer an ingress
router knows if the destination prefix is available or not, only
attachment points (ALOC prefixes) of the destination prefix are
advertised in the DFZ. Thus the endpoints must take more
responsibility for their sessions. This can be achieved by using
multipath enabled transport protocols, such as SCTP and MPTCP, at the
endpoints. The multipath transport protocols also provides a session
identifier, i.e. verification tag/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, to resolve
the location of an endpoint it must have one ELOC value (current
A-record) and at least one ALOC value (in multi-homing solutions there
will be several ALOC values for an endpoint). The hIPv4 framework can
also be integrated to a map-and-encapsulate solution; the ITR/ETR
needs to incorporate the hIPv4 stack and might use a multipath enabled
transport protocol to serve the hIPv4/multipath transport protocol
enabled endpoints.

2. Gains:
1) Improved routing scalability: Adding hierarchy in the address space
enables a hierarchy in the routing architecture. Early adapters of an
ALOC realm will no longer carry the RIB of the DFZ – only ELOC
prefixes of directly attached networks and ALOC prefixes from other
service provider that have migrated.
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 of a
multi-homed site are advertised in the DFZ, DNS will inform the
requester how many attachment points the destination endpoint has. It
is the initiating endpoints choice/responsibility which attachment
point is used; 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 on the
endpoints.
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
mechanisms, only a swap of the IPv4 header and locator header at the
destination ALOC realm is required, thus current routing 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 (improved security)
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.

3. Costs and issues:
1) Upgrade of the stack at an endpoint or the endpoint should make use
of an ITR/XTR
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 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 global allocation of the current
IPv4 address block they have gained?
6) Co-ordination with MPTCP is highly desirable

http://tools.ietf.org/html/draft-frejborg-hipv4-04
(a description of how map-and-encapsulate can be integrated to the
hIPv4 framework is missing, it is on the to-do list and a presentation
has been sent to the rrg-list)

-- patte