Internet Research Task Force                                  T. Li, Ed.
Internet-Draft                                                  Ericsson
Intended status: Informational                         December 26, 2009
Expires: June 29, 2010

               Recommendation for a Routing Architecture


   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 reports the Routing
   Research Group's prelimnary findings from its efforts towards
   developing a recommendation for a scalable routing architecture.

   This document is a work in progress.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on June 29, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal

Li                        Expires June 29, 2010                 [Page 1]

Internet-Draft             RRG Recommendation              December 2009

   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.   Structure of This Document  . . . . . . . . . . . . . . .  4
   2.  Locator Identifier Separation Protocol (LISP)  . . . . . . . .  4
     2.1.   Key Idea  . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.   Gains . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.   Costs . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Routing Architecture for the Next Generation Internet
       (RANGI)  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.   Key Idea  . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.   Gains . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.   Costs . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Internet Vastly Improved Plumbing (Ivip) . . . . . . . . . . .  7
     4.1.   Key Ideas . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.   Extensions  . . . . . . . . . . . . . . . . . . . . . . .  8
       4.2.1.  TTR Mobility . . . . . . . . . . . . . . . . . . . . .  8
       4.2.2.  Modified Header Forwarding . . . . . . . . . . . . . .  9
     4.3.   Gains . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.4.   Costs . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  hIPv4  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.   Key Idea  . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.2.   Gains . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.3.   Costs And Issues  . . . . . . . . . . . . . . . . . . . . 11
   6.  Name overlay (NOL) service for scalable Internet routing . . . 12
     6.1.   Key Idea  . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.2.   Gains . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.3.   Costs . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Compact routing in locator identifier mapping system . . . . . 14
     7.1.   Key Idea  . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.2.   Gains . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.3.   Costs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Layered mapping system (LMS) . . . . . . . . . . . . . . . . . 14
     8.1.   Key Ideas . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.2.   Gains . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.3.   Costs . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  2-phased mapping . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.   Considerations  . . . . . . . . . . . . . . . . . . . . . 16

Li                        Expires June 29, 2010                 [Page 2]

Internet-Draft             RRG Recommendation              December 2009

     9.2.   My contribution: a 2-phased mapping . . . . . . . . . . . 16
     9.3.   Gains . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.4.   Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17
   10. Global Locator, Local Locator, and Identifier Split
       (GLI-Split)  . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1.  Key Idea  . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.2.  Gains . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.3.  Costs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   11. Tunneled Inter-domain Routing (TIDR) . . . . . . . . . . . . . 18
     11.1.  Key Idea  . . . . . . . . . . . . . . . . . . . . . . . . 18
     11.2.  Gains . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     11.3.  Costs . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   12. Identifier-Locator Network Protocol (ILNP) . . . . . . . . . . 20
     12.1.  Key Ideas . . . . . . . . . . . . . . . . . . . . . . . . 20
     12.2.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . 20
     12.3.  Costs . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   13. Enhanced Efficiency of Mapping Distribution Protocols in
       Map-and-Encap Schemes  . . . . . . . . . . . . . . . . . . . . 22
     13.1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . 22
     13.2.  Management of Mapping Distribution of Subprefixes
            Spread Across Multiple ETRs . . . . . . . . . . . . . . . 22
     13.3.  Management of Mapping Distribution for Scenarios with
            Hierarchy of ETRs and Multi-Homing  . . . . . . . . . . . 24
   14. Evolution  . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     14.1.  Need for Evolution  . . . . . . . . . . . . . . . . . . . 24
     14.2.  Relation to Other RRG Proposals . . . . . . . . . . . . . 25
     14.3.  Aggregation with Increasing Scopes  . . . . . . . . . . . 25
   15. Name-Based Sockets . . . . . . . . . . . . . . . . . . . . . . 27
   16. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 29
   17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
   18. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
   19. Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     20.1.  Normative References  . . . . . . . . . . . . . . . . . . 29
     20.2.  Informative References  . . . . . . . . . . . . . . . . . 29
     20.3.  LISP References . . . . . . . . . . . . . . . . . . . . . 30
     20.4.  RANGI References  . . . . . . . . . . . . . . . . . . . . 30
     20.5.  Ivip References . . . . . . . . . . . . . . . . . . . . . 31
     20.6.  hIPv4 References  . . . . . . . . . . . . . . . . . . . . 32
     20.7.  Layered Mapping System References . . . . . . . . . . . . 32
     20.8.  GLI References  . . . . . . . . . . . . . . . . . . . . . 32
     20.9.  TIDR References . . . . . . . . . . . . . . . . . . . . . 32
     20.10. ILNP References . . . . . . . . . . . . . . . . . . . . . 33
     20.11. EEMDP References  . . . . . . . . . . . . . . . . . . . . 33
     20.12. Evolution References  . . . . . . . . . . . . . . . . . . 33
     20.13. Name Based Sockets References . . . . . . . . . . . . . . 33
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33

Li                        Expires June 29, 2010                 [Page 3]

Internet-Draft             RRG Recommendation              December 2009

1.  Introduction

   It is commonly recognized that the Internet routing and addressing
   architecture is facing challenges in scalability, multi-homing, and
   inter-domain traffic engineering.  The problem being addressed has
   been documented in [I-D.narten-radir-problem-statement], and the
   design goals that we have agreed to can be found in
   [I-D.irtf-rrg-design-goals].  This document reports the Routing
   Research Group's (RRG's) results from its efforts towards developing
   a recommendation for a scalable routing architecture.

   This document is a work in progress.

1.1.  Structure of This Document

   This document describes a number of the different possible approaches
   that could be taken in a new routing architecture, as well as a
   summary of the current thinking of the overall group regarding each

2.  Locator Identifier Separation Protocol (LISP)

2.1.  Key Idea

   Implements a locator-identifier separation mechanism using
   encapsulation between routers at the "edge" of the Internet.  Such a
   separation allows topological aggregation of the routeable addresses
   (locators) while providing stable and portable numbering of end
   systems (identifiers).

2.2.  Gains

   o  topological aggregation of numbering space (RLOCs) used for
      routing, which greatly reduces both the overall size and the
      "churn rate" of the information needed to operate the Internet
      global routing system

   o  seperate numbering space (EIDs) for end-systems, effectively
      allowing "PI for all" (no renumbering cost for connectivity
      changes) without adding state to the global routing system

   o  improved traffic engineering capabilities that explicitly do not
      add state to the global routing system and whose deployment will
      allow active removal of more-specific state currently used

   o  no changes required to end systems

Li                        Expires June 29, 2010                 [Page 4]

Internet-Draft             RRG Recommendation              December 2009

   o  no changes to Internet "core" routers

   o  minimal and straightforward changes to "edge" routers

   o  day-one advatanges for early adopters

   o  defined router-to-router protocol

   o  defined database mapping system

   o  defined deployment plan

   o  defined interoperability/interworking mechanisms

   o  defined scalable end-host mobility mechanisms

   o  prototype implementation already exists and undergoing testing

   o  production implementations in progress

2.3.  Costs

   o  mapping system infrastructure (map servers, map resolvers, ALT
      routers) (new potential business opportunity)

   o  Interworking infrastructure (proxy ITRs) (new potential business

   o  overhead for determining/maintaining locator/path liveness (common
      issue for all id/loc separation proposals)

3.  Routing Architecture for the Next Generation Internet (RANGI)

3.1.  Key Idea

   Similar to HIP [RFC4423], RANGI introduces a host identifier layer
   between the network layer and the transport layer, and the transport-
   layer associations (i.e., TCP connections) are no longer bound to IP
   addresses, but to host identifiers.  The major difference from the
   HIP is that the host identifier in RANGI is a 128-bit hierarchical
   and cryptographic identifier which has organizational structure.  As
   a result, the corresponding ID->locator mapping system for such
   identifiers has reasonable business model and clear trust boundaries.
   In addition, RANGI uses IPv4-embeded IPv6 addresses as locators.  The
   LD ID (i.e., the leftmost 96 bits) of this locator is a provider-
   assigned /96 IPv6 prefix, while the last four octets of this locator
   is a local IPv4 address (either public or private).  This special

Li                        Expires June 29, 2010                 [Page 5]

Internet-Draft             RRG Recommendation              December 2009

   locator could be used to realize 6over4 automatic tunneling
   (borrowing ideas from ISATAP [RFC5214]), which will reduce the
   deployment cost of this new routing architecture.  Within RANGI, the
   mappings from FQDN to host identifiers are stored in the DNS system,
   while the mappings from host identifiers to locators are stored in a
   distributed id/locator mapping system (e.g., a hierarchical
   Distributed Hash Table (DHT) system, or a reverse DNS system).

3.2.  Gains

   RANGI achieves almost all of goals set by RRG as follows:

   1.  Routing Scalability: Scalability is achieved by decoupling
       identifiers from locators.

   2.  Traffic Engineering: Hosts located in a multi-homed site can
       suggest the upstream ISP for outbound and inbound traffics, while
       the first-hop LDBR (i. e., site border router) has the final
       decision right on the upstream ISP selection.

   3.  Mobility and Multi-homing: Sessions will not be interrupted due
       to locator change in cases of mobility or multi-homing.

   4.  Simplified Renumbering: When changing providers, the local IPv4
       addresses of the site do not need to change.  Hence the internal
       routers within the site don't need renumbering.

   5.  Decoupling Location and Identifier: Obvious.

   6.  Routing Stability: Since the locators are topologically
       aggregatable and the internal topology within LD will not be
       disclosed outside, the routing stability could be improved

   7.  Routing Security: RANGI reuses the current routing system and
       does not introduce any new security risk into the routing system.

   8.  Incremental Deployability: RANGI allows easy transition from IPv4
       network to IPv6 network.  In addition, RANGI proxy allows RANGI-
       aware hosts to communicate to legacy IPv4 or IPv6 hosts, and vice

3.3.  Costs

   1.  Host change is required

   2.  First-hop LDBR change is required to support site-controlled
       traffic-engineering capability.

Li                        Expires June 29, 2010                 [Page 6]

Internet-Draft             RRG Recommendation              December 2009

   3.  The ID->Locator mapping system is a new infrastructure to be

   4.  Proxy needs to be deployed for communication between RANGI-aware
       hosts and legacy hosts.

4.  Internet Vastly Improved Plumbing (Ivip)

4.1.  Key Ideas

   Ivip (pr. eye-vip, est. 2007-06-15) is a core-edge separation scheme
   for IPv4 and IPv6.  It provides multihoming, portability of address
   space and inbound traffic engineering for end-user networks of all
   sizes and types, including those of corporations, SOHO and mobile

   Ivip meets all the constraints imposed by the need for widespread
   voluntary adoption [Ivip Constraints].

   Ivip's global fast-push mapping distribution network is structured
   like a cross-linked multicast tree.  This pushes all mapping changes
   to full database query servers (QSDs) within ISPs and end-user
   networks which have ITRs.  Each mapping change is sent to all QSDs
   within a few seconds.

   ITRs gain mapping information from these local QSDs within a few tens
   of milliseconds.  QSDs notify ITRs of changed mapping with similarly
   low latency.  ITRs tunnel all traffic packets to the correct ETR
   without significant delay.

   Ivip's mapping consists of a single ETR address for each range of
   mapped address space.  Ivip ITRs do not need to test reachability to
   ETRs because the mapping is changed in real-time to that of the
   desired ETR.

   End-user networks control the mapping, typically by contracting a
   specialized company to monitor the reachability of their ETRs and
   change the mapping to achieve multihoming and/or TE.  So the
   mechanisms which control ITR tunneling are controlled by the end-user
   networks in real-time and are completely separate from the core-edge
   separation scheme itself.

   ITRs can be implemented in dedicated servers or hardware-based
   routers.  The ITR function can also be integrated into sending hosts.
   ETRs are relatively simple and only communicate with ITRs rarely -
   for Path MTU management with longer packets.

Li                        Expires June 29, 2010                 [Page 7]

Internet-Draft             RRG Recommendation              December 2009

   Ivip-mapped ranges of end-user address space need not be subnets.
   They can be of any length, in units of IPv4 addresses or IPv6 /64s.

   Compared to conventional unscalable BGP techniques, and to the use of
   core-edge separation architectures with non-real-time mapping
   systems, end-user networks will be able to achieve more flexible and
   responsive inbound TE.  If inbound traffic is split into several
   streams, each to addresses in different mapped ranges, then real-time
   mapping changes can be used to steer the streams between multiple
   ETRs at multiple ISPs.

   Open ITRs in the DFZ (OITRDs, similar to LISP's PTRs) tunnel packets
   sent by hosts in networks which lack ITRs.  So multihoming,
   portability and TE benefits apply to all traffic.

   ITRs request mapping either directly from a local QSD or via one or
   more layers of caching query servers (QSCs) which in turn request it
   from a local QSD.  QSCs are optional but generally desirable since
   they reduce the query load on QSDs.

   ETRs may be in ISP or end-user networks.  IP-in-IP encapsulation is
   used, so there is no UDP or any other header.  PMTUD (Path MTU
   Discovery) management with minimal complexity and overhead will
   handle the problems caused by encapsulation, and adapt smoothly to
   jumboframe paths becoming available in the DFZ.  The outer header's
   source address is that of the sending host - which enables existing
   ISP BR filtering of source addresses to be extended to encapsulated
   traffic packets by the simple mechanism of the ETR dropping packets
   whose inner and outer source address do not match.

4.2.  Extensions

4.2.1.  TTR Mobility

   The TTR approach to mobility [Ivip Mobility] is applicable to all
   core-edge separation techniques and provides scalable IPv4 and IPv6
   mobility in which the MN keeps its own mapped IP address(es) no
   matter how or where it is physically connected, including behind one
   or more layers of NAT.

   Path-lengths are typically optimal or close to optimal and the MN
   communicates normally with all other non-mobile hosts (no stack or
   app changes), and of course other MNs.  Mapping changes are only
   needed when the MN uses a new TTR, which would typically be if the MN
   moved more than 1000km.  Mapping changes are not required when the MN
   changes its physical address(es).

Li                        Expires June 29, 2010                 [Page 8]

Internet-Draft             RRG Recommendation              December 2009

4.2.2.  Modified Header Forwarding

   Separate schemes for IPv4 and IPv6 enable tunneling from ITR to ETR
   without encapsulation.  This will remove the encapsulation overhead
   and PMTUD problems.  Both approaches involve modifying all routers
   between the ITR and ETR to accept a modified form of the IP header.
   These schemes require new FIB/RIB functionality in DFZ and some other
   routers but do not alter the BGP functions of DFZ routers.

4.3.  Gains

   Amenable to widespread voluntary adoption due to no need for host
   changes, complete support for packets sent from non-upgraded networks
   and no significant degradation in performance.

   Modular separation of the control of ITR tunneling behavior from the
   ITRs and the core-edge separation scheme itself: end-user networks
   control mapping in any way they like, in real-time.

   A small fee per mapping change deters frivolous changes and helps pay
   for pushing the mapping data to all QSDs.  End-user networks who make
   frequent mapping changes for inbound TE, should find these fees
   attractive considering how it improves their ability to utilize the
   bandwidth of multiple ISP links.

   End-user networks will typically pay the cost of OITRD forwarding to
   their networks.  This provides a business model for OITRD deployment
   and avoids unfair distribution of costs.

   Existing source address filtering arrangements at BRs of ISPs and
   end-user networks are prohibitively expensive to implement directly
   in ETRs, but with the outer header's source address being the same as
   the sending host's address, Ivip ETRs inexpensively enforce BR
   filtering on decapsulated packets.

4.4.  Costs

   QSDs receive all mapping changes and store a complete copy of the
   mapping database.  However, a worst case scenario is 10 billion IPv6
   mappings, each of 32 bytes, which fits on a consumer hard drive today
   and should fit in server DRAM by the time such adoption is reached.

   The maximum number of non-mobile networks requiring multihoming etc.
   is likely to be ~10M, so most of the 10B mappings would be for mobile
   devices.  However, TTR mobility does not involve frequent mapping
   changes since most MNs only rarely move more than 1000km.

Li                        Expires June 29, 2010                 [Page 9]

Internet-Draft             RRG Recommendation              December 2009

5.  hIPv4

5.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.

5.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

Li                        Expires June 29, 2010                [Page 10]

Internet-Draft             RRG Recommendation              December 2009

       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

   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.

5.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

Li                        Expires June 29, 2010                [Page 11]

Internet-Draft             RRG Recommendation              December 2009

   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

6.  Name overlay (NOL) service for scalable Internet routing

6.1.  Key Idea

   The basic idea is to add a name overlay (NOL) on the existing TCP/IP

   Its functions include:

   1.  host names configuration, registration and authentication;

   2.  Initiate and manage transport connection channels (i.e., TCP/IP
       connections) by name;

   3.  keep application data transport continuity for mobility.

   At the edge network, we introduce a new type of gateway NTR (Name
   Transfer Relay), which block the PI addresses of edge networks into
   upstream transit networks.  NTRs performs address and/or port
   translation between blocked PI addresses and globally routable
   addresses, which seem like today's widely used NAT/NAPT devices.
   Both legacy and NOL applications behind a NTR can access the outside
   as usual.  To access the hosts behind a NTR from outside, we need to
   use NOL traverse the NTR by name and initiate connections to the
   hosts behind it.

   Different from proposed host-based ID/Locator split solutions, such
   as HIP, Shim6, and name-oriented stack, NOL doesn't need to change
   the existing TCP/IP stack, sockets and their packet formats.  NOL can
   co-exist with the legacy infrastructure, the core-edges separation
   solutions (e.g., APT, LISP, Six/one, Ivip, etc.)

6.2.  Gains

   1.   Reduce routing table size: Prevent edge network PI address into
        transit netwok by deploying gateway NTR

Li                        Expires June 29, 2010                [Page 12]

Internet-Draft             RRG Recommendation              December 2009

   2.   Traffic Engineering: For legacy and NOL application initiating
        session, the incoming traffic can be directed to a specific NTR
        by DNS answer for names.  In addition, for NOL application, its
        initial session can be redirected from one NTR to other
        appropriate NTRs.  These mechanisms provide some support for
        traffic engineering.

   3.   Multi-homing: When a PI address network connects to Internet by
        multi-homing with several providers, it can deploy NTRs to block
        the PI addresses into provide networks.

   4.   And the NTRs can be allocated PA addresses from the upstream
        providers and store them in NTRs' address pool.  By DNS query or
        NOL session, any session that want to access the hosts behind
        the NTR can be delegated to a specific PA address in the NTR
        address pool.

   5.   Mobility: NOL layer manage the traditional TCP/IP transport
        connections, and keeps application data transport continue by
        setting breakpoints and sequence numbers in data stream.

   6.   No need to change TCP/IP stack, sockets and DNS system.

   7.   No need for extra mapping system.

   8.   NTR can be deployed unilaterally, just like NATs

   9.   NOL applications can communicate with legacy applications.

   10.  NOL can be compatible with existing solutions, such as APT,
        LISP, Ivip, etc.

   11.  End user controlled multi-path indirect routing based on
        distributed NTRs.  This will give benefits to the performance-
        aware applications, such as, MSN, Video streaming, etc.

6.3.  Costs

   1.  Legacy applications have trouble with initiating access to the
       servers behind NTR.  Such trouble can be resolved by deploying
       NOL proxy for legacy hosts, or delegating globally routable PA
       addresses in NTR address pool for these servers, or deploying
       server proxy outside NTR.

   2.  It may increase the number of entries of DNS, but not drastic,
       because it only increases DNS entries in domains granularity not
       hosts.  The name used in NOL, for example, just like email
       address  The needed DNS entries and query is

Li                        Expires June 29, 2010                [Page 13]

Internet-Draft             RRG Recommendation              December 2009

       just for "", and The NTR knows "hostnames".  The DNS
       entries will not only be increased, but its dynamic might be
       agitated as well.  However the scalability and performance of DNS
       is guaranteed by name hierarchy and cache mechanism.

   3.  Address translating/rewriting costs on NTRs.

7.  Compact routing in locator identifier mapping system

7.1.  Key Idea

   Builds a highly scalable locator identity mapping system using
   compact routing principles.  Provides means for dynamic topology
   adaption to facilitate efficient aggregation.  Map servers are
   assigned as cluster heads or landmarks based on their capability to
   aggregate EID announcements.

7.2.  Gains

   Minimizes the routing table sizes in at the system level (= map
   servers).  Provides clear upper bounds for routing stretch that
   defines the packet delivery delay of the map request/first packet.

   Organizes the mapping system based EID numbering space, minimizes the
   administrative of overhead of managing EID space.  No need for
   administratively planned hierarchical address allocation as the
   system will find convergence into a sets of EID allocations.

   Availability and robustness of the overall routing system (including
   xTRs and map servers) is improved because potential to use multiple
   map servers and direct routes without involvement of map servers.

7.3.  Costs

   The scalability gains will materialize only in large deployments.  If
   the stretch is required to be bound to those of compact routing
   (worst case stretch less or equal to 3, on average 1+epsilon) then
   xTRs need to have memory/cache for the mappings of its cluster.

8.  Layered mapping system (LMS)

8.1.  Key Ideas

   Build a hierarchical mapping system to support scalability, analyze
   the design constraints and present an explicit system structure;
   design a two-cache mechanism on ingress tunneling router (ITR) to

Li                        Expires June 29, 2010                [Page 14]

Internet-Draft             RRG Recommendation              December 2009

   gain low request delay and facilitate data validation.  Tunneling and
   mapping are done at core and no change needed on edge networks.
   Mapping system is run by interest groups independent of ISP, which
   conforms to economical model and can be voluntarily adopted by
   various networks.  Mapping system can also be constructed stepwise,
   especially in the IPv6 scenario.

8.2.  Gains

   1.  Scalability

       1.  Distributed storage of mapping data avoids central storage of
           massive data; restrict updates within local areas;

       2.  Cache mechanism in ITR reduces request loads on mapping
           system reasonably.

   2.  Deployability

       1.  No change on edge works; only tunneling in core routers; new
           devices in core networks;

       2.  Mapping system can be constructed stepwise: a mapping node
           needn't be constructed if none of its responsible ELOCs is
           allocated.  This makes sense especially for IPv6.

       3.  Conform to economic model: mapping system can profit from
           their services; core routers and edge networks are willing to
           join the circle, either to avoid router upgrades or realize
           traffic engineering.  Benefits from joining are independent
           of the scheme's implementation scale.

   3.  Low request delay: Low layer number of the mapping structure and
       two-stage cache can well achieve low request delay.

   4.  Data consistency: Two-stage cache enables ITR to update data in
       the map cache conveniently.

   5.  Traffic engineering support: Edge networks inform mapping system
       their mappings with all upstream routers with different priority,
       thus to control their ingress flows.

8.3.  Costs

   1.  Deployment of LMS needs to be further discussed.

   2.  The structure of mapping system needs to be refined according to
       practical circumstances.

Li                        Expires June 29, 2010                [Page 15]

Internet-Draft             RRG Recommendation              December 2009

9.  2-phased mapping

9.1.  Considerations

   1.  Mapping from prefixes to ETRs is an M:M mapping.  Any change of
       (prefix, ETR) pair should be updated timely which can be a heavy
       burden to any mapping systems if the relation changes frequently.

   2.  prefix<->ETR mapping system cannot be deployed efficiently if it
       is overwhelmed by the worldwide dynamics.  Therefore the mapping
       itself is not scalable with this direct mapping scheme.

9.2.  My contribution: a 2-phased mapping

   1.  Introduce AS number in the middle of the mapping, phase I mapping
       is prefix<->AS#, phase II mapping is AS#<->ETRs.  We have a M:1:M
       mapping model now.

   2.  My assumption is that all ASes know better their local prefixes
       (in the IGP) than others. and most likely local prefixes can be
       aggregated when map them to the AS#, which will make the mapping
       entry reduction possible, ASes also know clearly their ETRs on
       its border between core and edge.  So all mapping information can
       be collected locally.

   3.  A registry system will take care of the phase I mapping
       information.  Each AS should have a register agent to notify the
       local range of IP address space to the registry.  This system can
       be organized as a hierarchical infrastructure like DNS, or
       alternatively as a centralized registry like "whois" in each RIR.
       Phase II mapping information can be distributed between XTRs as a
       BGP extension.

   4.  A basic forwarding procedure is that ITR firstly get the
       destination AS# from phase I mapper (or from cache) when the
       packet is entering the "core".  Then it will check the closest
       ETR of destination AS#, since phase 2 mapping information has
       been "pushed" to it through BGP updates.  At last the ITR encap
       the packet and tunnel it to a corresponding ETR.

9.3.  Gains

   1.  Any prefixes reconfiguration (aggregation/ deaggregation) within
       an AS will not be notified to mapping system.

   2.  Possible highly efficient aggregation of the local prefixes (in
       the form of an IP space range).

Li                        Expires June 29, 2010                [Page 16]

Internet-Draft             RRG Recommendation              December 2009

   3.  Both phase I and phase II mapping can be stable.

   4.  A stable mapping system will reduce the update overhead
       introduced by topology change/routing policy dynamics.ETR.

9.4.  Summary

   1.  The 2-phased mapping scheme introduces AS# between the mapping
       prefixes and ETRs.

   2.  The decoupling of direct mapping makes highly dynamic updates
       stable, therefore it can be more scalable than any direct mapping

   3.  The 2-phased mapping scheme is adaptable to any core/edge split
       based proposals.

10.  Global Locator, Local Locator, and Identifier Split (GLI-Split)

10.1.  Key Idea

   GLI-Split implements a separation between global routing (in the
   global Internet outside edge networks) and local routing (inside edge
   networks) and using global and local locators (GLs, LLs).  In
   addition, a separate static identifier (ID) is used to identify
   communication endpoints (e.g. nodes or services) independently of any
   routing information.  Locators and IDs are encoded in IPv6 addresses
   to enable backwards-compatibility with the IPv6 Internet.  The higher
   order bits store either a GL or a LL while the lower order bits
   contain the ID.  A local mapping system maps IDs to LLs and a global
   mapping system maps IDs to GLs.  The full GLI-mode requires nodes
   with upgraded networking stacks and special GLI-gateways.  The GLI-
   gateways perform stateless locator rewriting in IPv6 addresses with
   the help of the local and global mapping system.  Non-upgraded IPv6
   nodes can also be accommodated in GLI-domains since an enhanced DHCP
   service and GLI-gateways compensate their missing GLI-functionality.
   This is an important feature for incremental deployability.

10.2.  Gains

   The benefits of GLI-Split are

   o  Hierarchical aggregation of routing information in the global
      Internet through separation of edge and core routing

   o  Provider changes not visible to nodes inside GLI-domains
      (renumbering not needed)

Li                        Expires June 29, 2010                [Page 17]

Internet-Draft             RRG Recommendation              December 2009

   o  Rearrangement of subnetworks within edge networks not visible to
      the outside world (better support of large edge networks)

   o  Transport connections survive both types of changes

   o  Multihoming

   o  Improved traffic engineering for incoming and outgoing traffic

   o  Multipath routing and load balancing for hosts

   o  Improved resilience

   o  Improved mobility support without home agents and triangle routing

   o  Interworking with the classic Internet

      *  without triangle routing over proxy routers

      *  without stateful NAT

   These benefits are available for upgraded GLI-nodes, but non-upgraded
   nodes in GLI-domains partially benefit from these advanced features,
   too.  This offers multiple incentives for early adopters and they
   have the option to migrate their nodes gradually from non-GLI stacks
   to GLI-stacks.

10.3.  Costs

   o  Local and global mapping system

   o  Modified DHCP or similar mechanism

   o  GLI-gateways with stateless locator rewriting in IPv6 addresses

   o  Upgraded stacks (only for full GLI-mode)

11.  Tunneled Inter-domain Routing (TIDR)

11.1.  Key Idea

   Provides a method for locator-identifier separation using tunnels
   between routers of the edge of the Internet transit infrastructure.
   It enrichs BGP protocol for distributing the identifier-to-locator
   mapping.  Using new BGP atributes "identifier prefixes" are assigned
   interdomain routing locators so that they will not be installed in
   the RIB and will be moved to a new table called Tunnel Information

Li                        Expires June 29, 2010                [Page 18]

Internet-Draft             RRG Recommendation              December 2009

   Base (TIB).  Afterwards, when routing a packet to the "identifier
   prefix", the TIB will be searched first to perform tunnel imposition,
   and secondly the RIB for actual routing.  After the edge router
   performs tunnel imposition, all routers in the middle will route this
   packet until the router being the tail-end of the tunnel.

11.2.  Gains

   o  Smooth deployment

   o  Size Reduction of the Global RIB Table

   o  Deterministic Customer Traffic Engineering for Incoming Traffic

   o  Numerous Forwarding Decisions for a Particular Address Prefix

   o  TIDR Stops AS Number Space Depletion

   o  Improved BGP Convergence

   o  Protection of the Inter-domain Routing Infrastructure

   o  Easy Separation of Control Traffic and Transit Traffic

   o  Different Layer-2 Protocol-IDs for Transit and Non-Transit Traffic

   o  Multihoming Resilience

   o  New Address Families and Tunneling Techniques

   o  TIDR for IPv4 or IPv6, and Migration to IPv6

   o  Scalability, Stability and Reliability

   o  Faster Inter-domain Routing

11.3.  Costs

   o  Routers of the edge of the interdomain infrastructure will need to
      be upgraded to hold the mapping database (i.e. the TIB)

   o  "Mapping updates" will need to be treated differently from usual
      BGP "routing updates"

Li                        Expires June 29, 2010                [Page 19]

Internet-Draft             RRG Recommendation              December 2009

12.  Identifier-Locator Network Protocol (ILNP)

12.1.  Key Ideas

   o  Provide crisp separation of Identifiers from Locators.

   o  Identifiers name nodes, not interfaces.

   o  Locators name subnetworks, rather than interfaces, so they are
      equivalent to an IP routing prefix.

   o  Identifiers are never used for network-layer routing, whilst
      Locators are never used for Node Identity.

   o  Transport-layer sessions (e.g.  TCP session state) use only
      Identifiers, never Locators, meaning that changes in location have
      no adverse impact on an IP session.

12.2.  Benefits

   o  The underlying protocol mechanisms support fully scalable site
      multi-homing, node multi-homing, site mobility, and node mobility.

   o  ILNP enables topological aggregation of location information while
      providing stable and topology-independent identities for nodes.

   o  In turn, this topological aggregation reduces both the routing
      prefix "churn" rate and the overall size of the Internet's global
      routing table, by eliminating the value and need for more-specific
      routing state currently carried throughout the global (default-
      free) zone of the routing system.

   o  ILNP enables improved Traffic Engineering capabilities without
      adding any state to the global routing system.  TE capabilities
      include both provider-driven TE and also end-site-controlled TE.

   o  ILNP's mobility approach:

      *  eliminates the need for special-purpose routers (e.g.  Home
         Agent and/or Foreign Agent now required by Mobile IP & NEMO).

      *  eliminates "triangle routing" in all cases.

      *  supports both "make before break" and "break before make"
         layer-3 handoffs.

Li                        Expires June 29, 2010                [Page 20]

Internet-Draft             RRG Recommendation              December 2009

   o  ILNP improves resilience and network availability while reducing
      the global routing state (as compared with the currently deployed

   o  ILNP is Incrementally Deployable:

      *  No changes are required to existing IPv6 (or IPv4) routers.

      *  Upgraded nodes gain benefits immediately ("day one"); those
         benefits gain in value as more nodes are upgraded (this follows
         Metcalfe's Law).

      *  Incremental Deployment approach is documented.

   o  ILNP is Backwards Compatible:

      *  ILNPv6 is fully backwards compatible with IPv6 (ILNPv4 is fully
         backwards compatible with IPv4).

      *  Reuses existing known-to-scale DNS mechanisms to provide
         identifier/locator mapping.

      *  Existing DNS Security mechanisms are reused without change.

      *  Existing IP Security mechanisms are reused with one minor
         change (IPsec Security Associations replace current use of IP
         Addresses with new use of Locator values).  NB: IPsec is also
         backwards compatible.

      *  Backwards Compatibility approach is documented.

   o  No new or additional overhead is required to determine or to
      maintain locator/path liveness.

   o  ILNP does not require locator rewriting (NAT); ILNP permits and
      tolerates NAT should that be desirable in some deployment(s).

   o  Changes to upstream network providers do not require node or
      subnetwork renumbering within end-sites.

   o  Compatible with and can facilitiate transition from current
      single-path TCP to multi-path TCP.

   o  ILNP can be implemented such that existing applications (e.g.
      applications using the BSD Sockets API) do NOT need any changes or
      modifications to use ILNP.

Li                        Expires June 29, 2010                [Page 21]

Internet-Draft             RRG Recommendation              December 2009

12.3.  Costs

   o  End systems need to be enhanced incrementally to support ILNP in
      addition to IPv6 (or IPv4 or both).

   o  DNS servers supporting upgraded end systems also should be
      upgraded to support new DNS resource records for ILNP.  (DNS
      protocol & DNS security do not need any changes.)

13.  Enhanced Efficiency of Mapping Distribution Protocols in Map-and-
     Encap Schemes

13.1.  Introduction

   We present some architectural principles pertaining to the mapping
   distribution protocols, especially applicable to map-and-encap (e.g.,
   LISP) type of protocols.  These principles enhance the efficiency of
   the map-and-encap protocols in terms of (1) better utilization of
   resources (e.g., processing and memory) at Ingress Tunnel Routers
   (ITRs) and mapping servers, and consequently, (2) reduction of
   response time (e.g., first packet delay).  We consider how Egress
   Tunnel Routers (ETRs) can perform aggregation of end-point ID (EID)
   address space belonging to their downstream delivery networks, in
   spite of migration/re-homing of some subprefixes to other ETRs.  This
   aggregation may be useful for reducing the processing load and memory
   consumption associated with map messages, especially at some
   resource-constrained ITRs and subsystems of the mapping distribution
   system.  We also consider another architectural concept where the
   ETRs are organized in a hierarchical manner for the potential benefit
   of aggregation of their EID address spaces.  The two key
   architectural ideas are discussed in some more detail below.  A more
   complete description can be found in a document [EEMDP
   Considerations] that was presented at the RRG meeting in Dublin
   [EEMDP Presentation].

   It will be helpful to refer to Figures 1, 2, and 3 in the document
   noted above for some of the discussions that follow here below.

13.2.  Management of Mapping Distribution of Subprefixes Spread Across
       Multiple ETRs

   To assist in this discussion, we start with the high level
   architecture of a map-and-encap approach (it would be helpful to see
   Fig. 1 in the document mentioned above).  In this architecture we
   have the usual ITRs, ETRs, delivery networks, etc.  In addition, we
   have the ID-Locator Mapping (ILM) servers which are repositories for
   complete mapping information, while the ILM-Regional (ILM-R) servers

Li                        Expires June 29, 2010                [Page 22]

Internet-Draft             RRG Recommendation              December 2009

   can contain partial and/or regionally relevant mapping information.

   While a large endpoint address space contained in a prefix may be
   mostly associated with the delivery networks served by one ETR, some
   fragments (subprefixes) of that address space may be located
   elsewhere at other ETRs.  Let a/20 denote a prefix that is
   conceptually viewed as composed of 16 subnets of /24 size that are
   denoted as a1/24, a2/24, :::, a16/24.  For example, a/20 is mostly at
   ETR1, while only two of its subprefixes a8/24 and a15/24 are
   elsewhere at ETR3 and ETR2, respectively (see Fig. 2 in the
   document).  From the point of view of efficiency of the mapping
   distribution protocol, it may be beneficial for ETR1 to announce a
   map for the entire space a/20 (rather than fragment it into a
   multitude of more-specific prefixes), and provide the necessary
   exceptions in the map information.  Thus the map message could be in
   the form of Map:(a/20, ETR1; Exceptions: a8/24, a15/24).  In
   addition, ETR2 and ETR3 announce the maps for a15/24 and a8/24,
   respectively, and so the ILMs know where the exception EID addresses
   are located.  Now consider a host associated with ITR1 initiating a
   packet destined for an address a7(1), which is in a7/24 that is not
   in the exception portion of a/20.  Now a question arises as to which
   of the following approaches would be the best choice:

   1.  ILM-R provides the complete mapping information for a/20 to ITR1
       including all maps for relevant exception subprefixes.

   2.  ILM-R provides only the directly relevant map to ITR1 which in
       this case is (a/20, ETR1).

   In the first approach, the advantage is that ITR1 would have the
   complete mapping for a/20 (including exception subnets), and it would
   not have to generate queries for subsequent first packets that are
   destined to any address in a/20, including a8/24 and a15/24.
   However, the disadvantage is that if there is a significant number of
   exception subprefixes, then the very first packet destined for a/20
   will experience a long delay, and also the processors at ITR1 and
   ILM-R can experience overload.  In addition, the memory usage at ITR1
   can be very inefficient as well.  The advantage of the second
   approach above is that the ILM-R does not overload resources at ITR1
   both in terms of processing and memory usage but it needs an enhanced
   map response in of the form Map:(a/20, ETR1, MS=1), where MS (more
   specific) indicator is set to 1 to indicate to ITR1 that not all
   subnets in a/20 map to ETR1.  The key idea is that aggregation is
   beneficial and subnet exceptions must be handled with additional
   messages or indicators in the maps.

Li                        Expires June 29, 2010                [Page 23]

Internet-Draft             RRG Recommendation              December 2009

13.3.  Management of Mapping Distribution for Scenarios with Hierarchy
       of ETRs and Multi-Homing

   Now we highlight another architectural concept related to mapping
   management (helpful here to refer to Fig. 3 in the document).  Here
   we consider the possibility that ETRs may be organized in a
   hierarchical manner.  For instance ETR7 is higher in hierarchy
   relative to ETR1, ETR2, and ETR3, and like-wise ETR8 is higher
   relative to ETR4, ETR5, and ETR6.  For instance, ETRs 1 through 3 can
   relegate locator role to ETR7 for their EID address space.  In
   essence, they can allow ETR7 to act as the locator for the delivery
   networks in their purview.  ETR7 keeps a local mapping table for
   mapping the appropriate EID address space to specific ETRs that are
   hierarchically associated with it in the level below.  In this
   situation, ETR7 can perform EID address space aggregation across ETRs
   1 through 3 and can also include its own immediate EID address space
   for the purpose of that aggregation.  The many details related to
   this approach and special circumstances involving multi-homing of
   subnets are discussed in detail in the detailed document noted
   earlier.  The hierarchical organization of ETRs and delivery networks
   should help in the future growth and scalability of ETRs and mapping
   distribution networks.  This is essentially recursive map-and-encap,
   and some of the mapping distribution and management functionality
   will remain local to topologically neighboring delivery networks
   which are hierarchically underneath ETRs.

14.  Evolution

   As the Internet continues its rapid growth, router memory size and
   CPU cycle requirements are outpacing feasible hardware upgrade
   schedules.  We propose to solve this problem by applying aggregation
   with increasing scopes to gradually evolve the routing system towards
   a scalable structure.  At each evolutionary step, our solution is
   able to interoperate with the existing system and provide immediate
   benefits to adopters to enable deployment.  This document summarizes
   the need for an evolutionary design, the relationship between our
   proposal and other revolutionary proposals and the steps of
   aggregation with increasing scopes.  Our detailed proposal can be
   found in [I-D.zhang-evolution].

14.1.  Need for Evolution

   Multiple different views exist regarding the routing scalability
   problem.  Networks differ vastly in goals, behavior, and resources,
   giving each a different view of the severity and imminence of the
   scalability problem.  Therefore we believe that, for any solution to
   be adopted, it will start with one or a few early adopters, and may

Li                        Expires June 29, 2010                [Page 24]

Internet-Draft             RRG Recommendation              December 2009

   not ever reach the entire Internet.  The evolutionary approach
   recognizes that changes to the Internet can only be a gradual process
   with multiple stages.  At each stage, adopters are driven by and
   rewarded with solving an immediate problem.  Each solution must be
   deployable by individual networks who deem it necessary at a time
   they deem it necessary, without requiring coordination from other
   networks, and the solution has to bring immediate relief to a single

14.2.  Relation to Other RRG Proposals

   Most proposals take a revolutionary approach that expects the entire
   Internet to eventually move to some new design whose main benefits
   would not materialize until the vast majority of the system has been
   upgraded; their incremental deployment plan simply ensures
   interoperation between upgraded and legacy parts of the system.  In
   contrast, the evolutionary approach depicts a picture where changes
   may happen here and there as needed, but there is no dependency on
   the system as a whole making a change.  Whoever takes a step forward
   gains the benefit by solving his own problem, without depending on
   others to take actions.  Thus, deployability includes not only
   interoperability, but also the alignment of costs and gains.

   The main differences between our approach and more revolutionary map-
   encap proposals are: (a) we do not start with a pre-defined boundary
   between edge and core; and (b) each step brings immediate benefits to
   individual first-movers.  Note that our proposal neither interferes
   nor prevents any revolutionary host-based solutions such as ILNP from
   being rolled out.  However, host-based solutions do not bring useful
   impact until a large portion of hosts have been upgraded.  Thus even
   if a host-based solution is rolled out in the long run, an
   evolutionary solution is still needed for the near term.

14.3.  Aggregation with Increasing Scopes

   Aggregating many routing entries to a fewer number is a basic
   approach to improving routing scalability.  Aggregation can take
   different forms and be done within different scopes.  In our design,
   the aggregation scope starts from a single router, then expands to a
   single network, and neighbor networks.  The order of the following
   steps is not fixed but merely a suggestion; it is under each
   individual network's discretion which steps they choose to take based
   on their evaluation of the severity of the problems and the
   affordability of the solutions.

   1.  FIB Aggregation (FA) in a single router.  A router
       algorithmically aggregates its FIB entries without changing its
       RIB or its routing announcements.  No coordinations among routers

Li                        Expires June 29, 2010                [Page 25]

Internet-Draft             RRG Recommendation              December 2009

       is needed, nor any change to existing protocols.  This brings
       scalability relief to individual routers with only a software

   2.  Enabling 'best external' on PEs, ASBRs, and RRs, and turning on
       next-hop-self on RRs.  For heirarchical networks, the RRs in each
       PoP can serve as a default gateway for nodes in the PoP, thus
       allowing the non-RR nodes in each PoP to maintain smaller routing
       tables that only include paths that egress out of that PoP.  This
       is known as 'topology-based mode' Virtual Aggregation, and can be
       done with existing hardware and configuration changes only.
       Please see [Evolution Grow Presenatation] for details.

   3.  Virtual Aggregation (VA) in a single network.  Within an AS, some
       fraction of existing routers are designated as Aggregation Point
       Routers (APRs).  These routers are either individually or
       collectively maintain the full FIB table.  Other routers may
       suppress entries from their FIBs, instead forwarding packets to
       APRs, which will then tunnel the packets to the correct egress
       routers.  VA can be viewed as an intra-domain map-encap system to
       provide the operators a control mechanism for the FIB size in
       their routers.

   4.  VA across neighbor networks.  When adjacent networks have VA
       deployed, they can go one step further by piggybacking egress
       router information on existing BGP announcements, so that packets
       can be tunneled directly to a neighbor network's egress router.
       This improves packet delivery performance by performing the
       encapsulation/decapsulation only once across these neighbor
       networks, as well as reducing the stretch of the path.

   5.  Reducing RIB Size by separating control plane from the data
       plane.  Although a router's FIB can be reduced by FA or VA, it
       usually still needs to maintain the full RIB in order for routing
       announcements to its neighbors.  To reduce the RIB size, a
       network can set up special boxes, which we call controllers, to
       take over the eBGP sessions from border routers.  The controllers
       receive eBGP announcements, make routing decisions, and then
       inform other routers in the same network of how to forward
       packets, while the regular routers just focus on the job of
       forwarding packets.  The controllers, not being part of the data
       path, can be scaled using commodity hardware.

   6.  Insulating forwarding routers from routing churns.  For routers
       with a smaller RIB, the rate of routing churns is naturally
       reduced.  Further reduction can be achieved by not announcing
       failures of customer prefixes into the core, but handling these
       failures in a data-driven fashion, e.g., a link failure to an

Li                        Expires June 29, 2010                [Page 26]

Internet-Draft             RRG Recommendation              December 2009

       edge network is not reported unless and until there are data
       packets that are heading towards the failed link.

15.  Name-Based Sockets

   Name-based sockets are an evolution of the existing address-based
   sockets, enabling applications to initiate and receive communication
   sessions by use of domain names in lieu of IP addresses.  Name-based
   sockets move the existing indirection from domain names to IP
   addresses from its current position in applications down to the IP
   layer.  As a result, applications communicate exclusively based on
   domain names, while the discovery, selection, and potentially in-
   session re-selection of IP addresses is centrally performed by the
   operating system.

   Name-based sockets help mitigate the Internet routing scalability
   problem by separating naming and addressing more consistently than
   what is possible with the existing address-based sockets.  This
   supports IP address aggregation because it simplifies the use of IP
   addresses with high topological significance, as well as the dynamic
   replacement of IP addresses during network-topological and host-
   attachment changes.

   A particularly positive effect of name-based sockets on Internet
   routing scalability is new incentives for edge network operators to
   use provider-assigned IP addresses, which are better aggregatable
   than the typically preferred provider-independent IP addresses.  Even
   though provider-independent IP addresses are harder to get and more
   expensive than provider-assigned IP addresses, many operators desire
   provider- independent addresses due to the high indirect cost of
   provider-assigned IP addresses.  This indirect cost comprises both,
   difficulties to multi- home, and tedious and largely manual
   renumbering upon provider changes.

   Name-based sockets reduce the indirect cost of provider-assigned IP
   addresses in three ways, and hence make the use of provider-assigned
   IP addresses more acceptable: (1) They enable fine-granular and
   responsive multi-homing. (2) They simplify renumbering by offering an
   easy means to replace IP addresses in referrals with domain names.
   This helps avoiding updates to application and operating system
   configurations, scripts, and databases during renumbering. (3) They
   facilitate low-cost solutions that eliminate renumbering altogether.
   One such low-cost solution is IP address translation, which in
   combination with name-based sockets loses its adverse impact on

   Prerequisite for a positive effect of name-based sockets on Internet

Li                        Expires June 29, 2010                [Page 27]

Internet-Draft             RRG Recommendation              December 2009

   routing scalability is their adoption in operating systems and
   applications.  Operating systems should be augmented to offer name-
   based sockets as a new alternative to the existing address-based
   sockets, and applications should use name-based sockets for their
   communications.  Neither an instantaneous, nor an eventually complete
   transition to name-based sockets is required, yet the positive effect
   on Interent routing scalability will grow with the extent of this

   Name-based sockets were hence designed with focus on deployment
   incentives, comprising both immediate deployment benefits as well as
   low deployment costs.  Name-based sockets provide a benefit to
   application developers because the alleviation of applications from
   IP address management responsibilities simplifies and expedites
   application development.  This benefit is immediate owing to the
   backwards compatibility of name-based sockets with legacy
   applications and legacy peers.  The appeal to application developers,
   in turn, is an immediate benefit for operating system vendors who
   adopt name-based sockets.

   Name-based sockets furthermore minimize deployment costs: Alternative
   techniques to separate naming and addressing provide applications
   with "surrogate IP addresses" that dynamically map onto regular IP
   addresses.  A surrogate IP address is indistinguishable from a
   regular IP address for applications, but does not have the
   topological significance of a regular IP address.  Mobile IP and the
   Host Identity Protocol are examples of such separation techniques.
   Mobile IP uses "home IP addresses" as surrogate IP addresses with
   reduced topological significance.  The Host Identity Protocol uses
   "host identifiers" as surrogate IP addresses without topological
   significance.  A disadvantage of surrogate IP addresses is their
   incurred cost in terms of extra administrative overhead and, for some
   techniques, extra infrastructure.  Since surrogate IP addresses must
   be resolvable to the corresponding regular IP addresses, they must be
   provisioned in the DNS or similar infrastructure.  Mobile IP uses a
   new infrastructure of home agents for this purpose, while the Host
   Identity Protocol populates DNS servers with host identities.  Name-
   based sockets avoid this cost because they function without surrogate
   IP addresses, and hence without the provisioning and infrastructure
   requirements that accompany those.

   Certainly, some edge networks will continue to use provider-
   independent addresses despite name-based sockets, perhaps simply due
   to inertia.  But name-based sockets will help reduce the number of
   those networks, and thus have a positive impact on Internet routing

   A more comprehensive description of name-based sockets can be found

Li                        Expires June 29, 2010                [Page 28]

Internet-Draft             RRG Recommendation              December 2009

   in [Name Based Sockets].

16.  Recommendation

17.  Acknowledgements

   This document represents a small portion of the overall work product
   of the Routing Research Group, who have developed all of these
   architectural approaches and many specific proposals within this
   solution space.

18.  IANA Considerations

   This memo includes no requests to IANA.

19.  Security Considerations

   All solutions are required to provide security that is at least as
   strong as the existing Internet routing and addressing architecture.

20.  References

20.1.  Normative References

              Li, T., "Design Goals for Scalable Internet Routing",
              draft-irtf-rrg-design-goals-01 (work in progress),
              July 2007.

              Narten, T., "Routing and Addressing Problem Statement",
              draft-narten-radir-problem-statement-04 (work in
              progress), December 2009.

   [RFC1887]  Rekhter, Y. and T. Li, "An Architecture for IPv6 Unicast
              Address Allocation", RFC 1887, December 1995.

20.2.  Informative References

              Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
              still needs work", draft-carpenter-renum-needs-work-04
              (work in progress), October 2009.

Li                        Expires June 29, 2010                [Page 29]

Internet-Draft             RRG Recommendation              December 2009

20.3.  LISP References

              Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
              draft-farinacci-lisp-lig-01 (work in progress), May 2009.

              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-05 (work in progress), September 2009.

              Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-01
              (work in progress), May 2009.

              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-00 (work in progress),
              May 2009.

              Fuller, V. and D. Farinacci, "LISP Map Server",
              draft-ietf-lisp-ms-04 (work in progress), October 2009.

              Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-00 (work in
              progress), July 2009.

              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID Separation", draft-meyer-loc-id-implications-01
              (work in progress), January 2009.

20.4.  RANGI References

              Xu, X., "Routing Architecture for the Next Generation
              Internet (RANGI)", draft-xu-rangi-01 (work in progress),
              July 2009.

              Xu, X., "Transition Mechanisms for Routing Architecture
              for the Next Generation Internet (RANGI)",
              draft-xu-rangi-proxy-01 (work in progress), July 2009.

Li                        Expires June 29, 2010                [Page 30]

Internet-Draft             RRG Recommendation              December 2009

   [RANGI]    Xu, X., "Routing Architecture for the Next-Generation
              Internet (RANGI)",

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

20.5.  Ivip References

              Whittle, R., "Ivip Mapping Database Fast Push",
              draft-whittle-ivip-db-fast-push-01 (work in progress),
              August 2008.

              Whittle, R., "Ivip4 ETR Address Forwarding",
              draft-whittle-ivip4-etr-addr-forw-01 (work in progress),
              August 2008.

   [Ivip Constraints]
              Whittle, R., "List of constraints on a successful scalable
              routing solution which result from the need for widespread
              voluntary adoption",

   [Ivip Mobility]
              Whittle, R., "TTR Mobility Extensions for Core-Edge
              Separation Solutions to the Internet's Routing Scaling

   [Ivip PMTUD]
              Whittle, R., "IPTM -  Ivip's approach to solving the
              problems with encapsulation overhead, MTU, fragmentation
              and Path MTU Discovery",

   [Ivip Summary]
              Whittle, R., "Ivip (Internet Vastly Improved Plumbing)
              Conceptual Summary and Analysis",

   [Ivip6]    Whittle, R., "Ivip6 - instead of map-encap, use the 20 bit
              Flow Label as a Forwarding Label",

Li                        Expires June 29, 2010                [Page 31]

Internet-Draft             RRG Recommendation              December 2009


20.6.  hIPv4 References

              Frejborg, P., "Hierarchical IPv4 Framework",
              draft-frejborg-hipv4-04 (work in progress), November 2009.

20.7.  Layered Mapping System References

   [LMS]      Letong, S., Xia, Y., ZhiLiang, W., and W. Jianping, "A
              Layered Mapping System For Scalable Routing", <http://

   [LMS Summary]
              Sun, C., "A Layered Mapping System (Summary)", <http://

20.8.  GLI References

   [GLI]      Menth, M., Hartmann, M., and D. Klein, "Global Locator,
              Local Locator, and Identifier Split (GLI-Split)", <http://

20.9.  TIDR References

              Adan, J., "Tunneled Inter-domain Routing (TIDR)",
              draft-adan-idr-tidr-01 (work in progress), December 2006.

   [TIDR AS forwarding]
              Adan, J., "yetAnotherProposal: AS-number forwarding",

   [TIDR and LISP]
              Adan, J., "LISP etc architecture",

   [TIDR identifiers]
              Adan, J., "TIDR using the IDENTIFIERS attribute", <http://

Li                        Expires June 29, 2010                [Page 32]

Internet-Draft             RRG Recommendation              December 2009

20.10.  ILNP References

   [ILNP Site]
              Atkinson, R., Bhatti, S., Hailes, S., Rehunathan, D., and
              M. Lad, "ILNP - Identifier/Locator Network Protocol",

20.11.  EEMDP References

   [EEMDP Considerations]
              Sriram, K., Kim, Y., and D. Montgomery, "Architectural
              Considerations for Mapping Distribution Protocols",

   [EEMDP Presentation]
              Sriram, K., Kim, Y., and D. Montgomery, "Architectural
              Considerations for Mapping Distribution Protocols", <http:

20.12.  Evolution References

   [Evolution Grow Presenatation]
              Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
              L. Zhang, "Virtual Aggregation (VA)",

              Zhang, B. and L. Zhang, "Evolution Towards Global Routing
              Scalability", draft-zhang-evolution-02 (work in progress),
              October 2009.

20.13.  Name Based Sockets References

   [Name Based Sockets]
              Vogt, C., "Simplifying Internet Applications Development
              With A Name-Based Sockets Interface", <http://

Li                        Expires June 29, 2010                [Page 33]

Internet-Draft             RRG Recommendation              December 2009

Author's Address

   Tony Li (editor)
   300 Holger Way
   San Jose, CA  95134

   Phone: +1 408 750 5160

Li                        Expires June 29, 2010                [Page 34]