One document matched: draft-irtf-rrg-recommendation-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1887 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1887.xml">
<!ENTITY RFC4423 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4423.xml">
<!ENTITY RFC5214 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5214.xml">
<!ENTITY I-D.narten-radir-problem-statement SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-radir-problem-statement.xml">
<!ENTITY I-D.irtf-rrg-design-goals SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-rrg-design-goals.xml">
<!ENTITY I-D.carpenter-renum-needs-work SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.carpenter-renum-needs-work.xml">
<!ENTITY I-D.ietf-lisp SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp.xml">
<!ENTITY I-D.ietf-lisp-alt SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-alt.xml">
<!ENTITY I-D.ietf-lisp-ms SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-ms.xml">
<!ENTITY I-D.ietf-lisp-interworking SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-interworking.xml">
<!ENTITY I-D.meyer-lisp-mn SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.meyer-lisp-mn.xml">
<!ENTITY I-D.farinacci-lisp-lig SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.farinacci-lisp-lig.xml">
<!ENTITY I-D.meyer-loc-id-implications SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.meyer-loc-id-implications.xml">
<!ENTITY I-D.xu-rangi SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.xu-rangi.xml"> <!ENTITY I-D.xu-rangi-proxy SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.xu-rangi-proxy.xml">
<!ENTITY I-D.whittle-ivip-db-fast-push SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.whittle-ivip-db-fast-push.xml">
<!ENTITY I-D.whittle-ivip4-etr-addr-forw SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.whittle-ivip4-etr-addr-forw.xml">
<!ENTITY I-D.frejborg-hipv4 SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.frejborg-hipv4.xml">
<!ENTITY I-D.adan-idr-tidr SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.adan-idr-tidr.xml">
<!ENTITY I-D.zhang-evolution SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhang-evolution.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-irtf-rrg-recommendation-03"
ipr="trust200811">
<front>
<title abbrev="RRG Recommendation">
Recommendation for a Routing Architecture
</title>
<author fullname="Tony Li" initials="T." role="editor"
surname="Li">
<organization>Ericsson</organization>
<address>
<postal>
<street>300 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 750 5160</phone>
<email>tony.li@tony.li</email>
</address>
</author>
<date month='December' day='26' year="2009" />
<area></area>
<workgroup>Internet Research Task Force</workgroup>
<keyword>routing</keyword>
<abstract>
<t>
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.
</t>
<t>
This document is a work in progress.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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
<xref target='I-D.narten-radir-problem-statement'/>, and the design
goals that we have agreed to can be found in
<xref target='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.
</t>
<t>
This document is a work in progress.
</t>
<section title="Structure of This Document">
<t>
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 approach.
</t>
</section>
</section>
<section title="Locator Identifier Separation Protocol (LISP)">
<section title="Key Idea">
<t>
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).
</t>
</section>
<section title="Gains">
<t>
<list style='symbols'>
<t>
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
</t>
<t>
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
</t>
<t>
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
</t>
<t>
no changes required to end systems
</t>
<t>
no changes to Internet "core" routers
</t>
<t>
minimal and straightforward changes to "edge" routers
</t>
<t>
day-one advatanges for early adopters
</t>
<t>
defined router-to-router protocol
</t>
<t>
defined database mapping system
</t>
<t>
defined deployment plan
</t>
<t>
defined interoperability/interworking mechanisms
</t>
<t>
defined scalable end-host mobility mechanisms
</t>
<t>
prototype implementation already exists and undergoing testing
</t>
<t>
production implementations in progress
</t>
</list>
</t>
</section>
<section title='Costs'>
<t>
<list style='symbols'>
<t>
mapping system infrastructure (map servers, map resolvers,
ALT routers) (new potential business opportunity)
</t>
<t>
Interworking infrastructure (proxy ITRs) (new potential
business opportunity)
</t>
<t>
overhead for determining/maintaining locator/path liveness
(common issue for all id/loc separation proposals)
</t>
</list>
</t>
</section>
</section>
<section title="Routing Architecture for the Next Generation Internet (RANGI)">
<section title="Key Idea">
<t>
Similar to HIP <xref target='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 locator could be used to realize 6over4
automatic tunneling (borrowing ideas from ISATAP
<xref target='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).
</t>
</section>
<section title='Gains'>
<t>
RANGI achieves almost all of goals set by RRG as follows:
<list style='numbers'>
<t>
Routing Scalability: Scalability is achieved by decoupling
identifiers from locators.
</t>
<t>
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.
</t>
<t>
Mobility and Multi-homing: Sessions will not be interrupted
due to locator change in cases of mobility or multi-homing.
</t>
<t>
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.
</t>
<t>
Decoupling Location and Identifier: Obvious.
</t>
<t>
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
greatly.
</t>
<t>
Routing Security: RANGI reuses the current routing system and
does not introduce any new security risk into the routing system.
</t>
<t>
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 versa.
</t>
</list>
</t>
</section>
<section title="Costs">
<t>
<list style='numbers'>
<t>
Host change is required
</t>
<t>
First-hop LDBR change is required to support site-controlled
traffic-engineering capability.
</t>
<t>
The ID->Locator mapping system is a new infrastructure to be
deployed.
</t>
<t>
Proxy needs to be deployed for communication between
RANGI-aware hosts and legacy hosts.
</t>
</list>
</t>
</section>
</section>
<section title="Internet Vastly Improved Plumbing (Ivip)">
<section title='Key Ideas'>
<t>
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
devices.
</t>
<t>
Ivip meets all the constraints imposed by the need for widespread
voluntary adoption <xref target='Ivip Constraints' />.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title='Extensions'>
<section title='TTR Mobility'>
<t>
The TTR approach to mobility <xref target='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.
</t>
<t>
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).
</t>
</section>
<section title='Modified Header Forwarding'>
<t>
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.
</t>
</section>
</section>
<section title='Gains'>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title='Costs'>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="hIPv4">
<section title='Key Idea'>
<t>
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.
</t>
</section>
<section title='Gains'>
<t>
<list style='numbers'>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Simplified Renumbering: When changing provider, the local ELOC
prefixes remains intact, only the ALOC prefix is changed on the
endpoints.
</t>
<t>
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
</t>
<t>
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.
</t>
<t>
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)
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title='Costs And Issues'>
<t>
<list style='numbers'>
<t>
Upgrade of the stack at an endpoint or the endpoint should make use
of an ITR/XTR
</t>
<t>
In a multi-homing solution the border routers should be able to
apply policy based routing upon the ALOC value in the locator header
</t>
<t>
New policies must be set by the RIRs
</t>
<t>
Short timeframe before the expected depletion of the IPv4 address
space occurs
</t>
<t>
Will enterprises give up their global allocation of the current
IPv4 address block they have gained?
</t>
<t>
Co-ordination with MPTCP is highly desirable
</t>
</list>
</t>
</section>
</section>
<section title='Name overlay (NOL) service for scalable Internet
routing'>
<section title='Key Idea'>
<t>
The basic idea is to add a name overlay (NOL) on the existing TCP/IP stack.
</t>
<t>
Its functions include:
<list style='numbers'>
<t>
host names configuration, registration and authentication;
</t>
<t>
Initiate and manage transport connection channels (i.e.,
TCP/IP connections) by name;
</t>
<t>
keep application data transport continuity for mobility.
</t>
</list>
</t>
<t>
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.
</t>
<t>
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.)
</t>
</section>
<section title='Gains'>
<t>
<list style='numbers'>
<t>
Reduce routing table size: Prevent edge network PI address
into transit netwok by deploying gateway NTR
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
No need to change TCP/IP stack, sockets and DNS system.
</t>
<t>
No need for extra mapping system.
</t>
<t>
NTR can be deployed unilaterally, just like NATs
</t>
<t>
NOL applications can communicate with legacy applications.
</t>
<t>
NOL can be compatible with existing solutions, such as APT,
LISP, Ivip, etc.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title='Costs'>
<t>
<list style='numbers'>
<t>
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.
</t>
<t>
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
hostname@domain.net. The needed DNS entries and query is just for
"domain.net", 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.
</t>
<t>
Address translating/rewriting costs on NTRs.
</t>
</list>
</t>
</section>
</section>
<section title='Compact routing in locator identifier mapping system'>
<section title='Key Idea'>
<t>
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.
</t>
</section>
<section title='Gains'>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title='Costs'>
<t>
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.
</t>
</section>
</section>
<section title='Layered mapping system (LMS)'>
<section title='Key Ideas'>
<t>
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 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.
</t>
</section>
<section title='Gains'>
<t>
<list style='numbers'>
<t>
Scalability
<list style='numbers'>
<t>
Distributed storage of mapping data avoids central
storage of massive data; restrict updates within local
areas;
</t>
<t>
Cache mechanism in ITR reduces request loads on mapping
system reasonably.
</t>
</list>
</t>
<t>
Deployability
<list style='numbers'>
<t>
No change on edge works; only tunneling in core routers;
new devices in core networks;
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
<t>
Low request delay: Low layer number of the mapping structure
and two-stage cache can well achieve low request delay.
</t>
<t>
Data consistency: Two-stage cache enables ITR to update data
in the map cache conveniently.
</t>
<t>
Traffic engineering support: Edge networks inform mapping
system their mappings with all upstream routers with
different priority, thus to control their ingress flows.
</t>
</list>
</t>
</section>
<section title='Costs'>
<t>
<list style='numbers'>
<t>
Deployment of LMS needs to be further discussed.
</t>
<t>
The structure of mapping system needs to be refined according
to practical circumstances.
</t>
</list>
</t>
</section>
</section>
<section title='2-phased mapping'>
<section title='Considerations'>
<t>
<list style='numbers'>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title='My contribution: a 2-phased mapping'>
<t>
<list style='numbers'>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title='Gains'>
<t>
<list style='numbers'>
<t>
Any prefixes reconfiguration (aggregation/ deaggregation) within an
AS will not be notified to mapping system.
</t>
<t>
Possible highly efficient aggregation of the local prefixes (in the
form of an IP space range).
</t>
<t>
Both phase I and phase II mapping can be stable.
</t>
<t>
A stable mapping system will reduce the update overhead
introduced by topology change/routing policy dynamics.ETR.
</t>
</list>
</t>
</section>
<section title='Summary'>
<t>
<list style='numbers'>
<t>
The 2-phased mapping scheme introduces AS# between the mapping
prefixes and ETRs.
</t>
<t>
The decoupling of direct mapping makes highly dynamic updates
stable, therefore it can be more scalable than any direct mapping
designs.
</t>
<t>
The 2-phased mapping scheme is adaptable to any core/edge split
based proposals.
</t>
</list>
</t>
</section>
</section>
<section
title='Global Locator, Local Locator, and Identifier Split (GLI-Split)'>
<section title='Key Idea'>
<t>
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.
</t>
</section>
<section title='Gains'>
<t>
The benefits of GLI-Split are
<list style='symbols'>
<t>
Hierarchical aggregation of routing information in the global
Internet through separation of edge and core routing
</t>
<t>
Provider changes not visible to nodes inside GLI-domains
(renumbering not needed)
</t>
<t>
Rearrangement of subnetworks within edge networks not visible
to the outside world (better support of large edge networks)
</t>
<t>
Transport connections survive both types of changes
</t>
<t>
Multihoming
</t>
<t>
Improved traffic engineering for incoming and outgoing
traffic
</t>
<t>
Multipath routing and load balancing for hosts
</t>
<t>
Improved resilience
</t>
<t>
Improved mobility support without home agents and triangle
routing
</t>
<t>
Interworking with the classic Internet
<list style='symbols'>
<t>
without triangle routing over proxy routers
</t>
<t>
without stateful NAT
</t>
</list>
</t>
</list>
</t>
<t>
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.
</t>
</section>
<section title='Costs'>
<t>
<list style='symbols'>
<t>
Local and global mapping system
</t>
<t>
Modified DHCP or similar mechanism
</t>
<t>
GLI-gateways with stateless locator rewriting in IPv6
addresses
</t>
<t>
Upgraded stacks (only for full GLI-mode)
</t>
</list>
</t>
</section>
</section>
<section title='Tunneled Inter-domain Routing (TIDR)'>
<section title='Key Idea'>
<t>
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 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.
</t>
</section>
<section title='Gains'>
<t>
<list style='symbols'>
<t>
Smooth deployment
</t>
<t>
Size Reduction of the Global RIB Table
</t>
<t>
Deterministic Customer Traffic Engineering for Incoming
Traffic
</t>
<t>
Numerous Forwarding Decisions for a Particular Address Prefix
</t>
<t>
TIDR Stops AS Number Space Depletion
</t>
<t>
Improved BGP Convergence
</t>
<t>
Protection of the Inter-domain Routing Infrastructure
</t>
<t>
Easy Separation of Control Traffic and Transit Traffic
</t>
<t>
Different Layer-2 Protocol-IDs for Transit and Non-Transit
Traffic
</t>
<t>
Multihoming Resilience
</t>
<t>
New Address Families and Tunneling Techniques
</t>
<t>
TIDR for IPv4 or IPv6, and Migration to IPv6
</t>
<t>
Scalability, Stability and Reliability
</t>
<t>
Faster Inter-domain Routing
</t>
</list>
</t>
</section>
<section title='Costs'>
<t>
<list style='symbols'>
<t>
Routers of the edge of the interdomain infrastructure will
need to be upgraded to hold the mapping database (i.e. the
TIB)
</t>
<t>
"Mapping updates" will need to be treated differently from
usual BGP "routing updates"
</t>
</list>
</t>
</section>
</section>
<section title='Identifier-Locator Network Protocol (ILNP)'>
<section title='Key Ideas'>
<t>
<list style='symbols'>
<t>
Provide crisp separation of Identifiers from Locators.
</t>
<t>
Identifiers name nodes, not interfaces.
</t>
<t>
Locators name subnetworks, rather than interfaces, so they
are equivalent to an IP routing prefix.
</t>
<t>
Identifiers are never used for network-layer routing, whilst
Locators are never used for Node Identity.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title='Benefits'>
<t>
<list style='symbols'>
<t>
The underlying protocol mechanisms support fully scalable
site multi-homing, node multi-homing, site mobility,
and node mobility.
</t>
<t>
ILNP enables topological aggregation of location information
while providing stable and topology-independent identities
for nodes.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
ILNP's mobility approach:
<list style='symbols'>
<t>
eliminates the need for special-purpose routers (e.g. Home
Agent and/or Foreign Agent now required by Mobile IP &
NEMO).
</t>
<t>
eliminates "triangle routing" in all cases.
</t>
<t>
supports both "make before break" and "break before make"
layer-3 handoffs.
</t>
</list>
</t>
<t>
ILNP improves resilience and network availability while
reducing the global routing state (as compared with the
currently deployed Internet).
</t>
<t>
ILNP is Incrementally Deployable:
<list style='symbols'>
<t>
No changes are required to existing IPv6 (or IPv4)
routers.
</t>
<t>
Upgraded nodes gain benefits immediately ("day one");
those benefits gain in value as more nodes are upgraded
(this follows Metcalfe's Law).
</t>
<t>
Incremental Deployment approach is documented.
</t>
</list>
</t>
<t>
ILNP is Backwards Compatible:
<list style='symbols'>
<t>
ILNPv6 is fully backwards compatible with IPv6
(ILNPv4 is fully backwards compatible with IPv4).
</t>
<t>
Reuses existing known-to-scale DNS mechanisms to provide
identifier/locator mapping.
</t>
<t>
Existing DNS Security mechanisms are reused without change.
</t>
<t>
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.
</t>
<t>
Backwards Compatibility approach is documented.
</t>
</list>
</t>
<t>
No new or additional overhead is required to determine
or to maintain locator/path liveness.
</t>
<t>
ILNP does not require locator rewriting (NAT);
ILNP permits and tolerates NAT should that be desirable
in some deployment(s).
</t>
<t>
Changes to upstream network providers do not require
node or subnetwork renumbering within end-sites.
</t>
<t>
Compatible with and can facilitiate transition from
current single-path TCP to multi-path TCP.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title='Costs'>
<t>
<list style='symbols'>
<t>
End systems need to be enhanced incrementally to support
ILNP in addition to IPv6 (or IPv4 or both).
</t>
<t>
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.)
</t>
</list>
</t>
</section>
</section>
<section title='Enhanced Efficiency of Mapping Distribution Protocols in Map-and-Encap Schemes'>
<section title='Introduction'>
<t>
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 <xref target='EEMDP Considerations'/> that was presented
at the RRG meeting in Dublin <xref
target='EEMDP Presentation'/>.
</t>
<t>
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.
</t>
</section>
<section title='Management of Mapping Distribution of Subprefixes
Spread Across Multiple ETRs'>
<t>
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 can contain partial and/or
regionally relevant mapping information.
</t>
<t>
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:
<list style='numbers'>
<t>
ILM-R provides the complete mapping information for a/20 to
ITR1 including all maps for relevant exception subprefixes.
</t>
<t>
ILM-R provides only the directly relevant map to ITR1 which
in this case is (a/20, ETR1).
</t>
</list>
</t>
<t>
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.
</t>
</section>
<section title='Management of Mapping Distribution for Scenarios with
Hierarchy of ETRs and Multi-Homing'>
<t>
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.
</t>
</section>
</section>
<section title='Evolution'>
<t>
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 <xref target='I-D.zhang-evolution' />.
</t>
<section title='Need for Evolution'>
<t>
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 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 first-mover.
</t>
</section>
<section title='Relation to Other RRG Proposals'>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title='Aggregation with Increasing Scopes'>
<t>
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.
<list style='numbers'>
<t>
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 is needed, nor any change to existing protocols. This
brings scalability relief to individual routers with only a
software upgrade.
</t>
<t>
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
<xref target='Evolution Grow Presenatation'/> for details.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 edge network is not reported unless and
until there are data packets that are heading towards the
failed link.
</t>
</list>
</t>
</section>
</section>
<section title='Name-Based Sockets'>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 applications.
</t>
<t>
Prerequisite for a positive effect of name-based sockets on Internet
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 transition.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 scalability.
</t>
<t>
A more comprehensive description of name-based sockets can be found
in <xref target='Name Based Sockets'/>.
</t>
</section>
<section title="Recommendation">
</section>
<section title="Acknowledgements">
<t>
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.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no requests to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>All solutions are required to provide security that is at least as
strong as the existing Internet routing and addressing architecture.</t>
</section>
</middle>
<back>
<references title="Normative References">
&I-D.narten-radir-problem-statement;
&I-D.irtf-rrg-design-goals;
&RFC1887;
</references>
<references title="Informative References">
&I-D.carpenter-renum-needs-work;
</references>
<references title="LISP References">
&I-D.ietf-lisp;
&I-D.ietf-lisp-alt;
&I-D.ietf-lisp-ms;
&I-D.ietf-lisp-interworking;
&I-D.meyer-lisp-mn;
&I-D.farinacci-lisp-lig;
&I-D.meyer-loc-id-implications;
</references>
<references title="RANGI References">
&RFC4423;
&RFC5214;
&I-D.xu-rangi;
&I-D.xu-rangi-proxy;
<reference anchor='RANGI'
target='http://www.ietf.org/proceedings/09nov/slides/RRG-1.ppt'>
<front>
<title>
Routing Architecture for the Next-Generation Internet (RANGI)
</title>
<author initials="X." surname='Xu' fullname='Xiaohu Xu'>
<organization>
Huawei
</organization>
</author>
</front>
<format type='PPT'
target='http://www.ietf.org/proceedings/09nov/slides/RRG-1.ppt' />
</reference>
</references>
<references title='Ivip References'>
&I-D.whittle-ivip-db-fast-push;
&I-D.whittle-ivip4-etr-addr-forw;
<reference anchor='Ivip Summary'
target='http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf'>
<front>
<title>
Ivip (Internet Vastly Improved Plumbing) Conceptual Summary and Analysis
</title>
<author initials='R.' surname='Whittle' fullname='Robin Whittle'>
<organization>
</organization>
</author>
</front>
<format type='PDF' target='http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf' />
</reference>
<reference anchor='Ivip PMTUD'
target='http://www.firstpr.com.au/ip/ivip/pmtud-frag/'>
<front>
<title>
IPTM - Ivip's approach to solving the problems with
encapsulation overhead, MTU, fragmentation and Path MTU
Discovery
</title>
<author initials='R.' surname='Whittle' fullname='Robin Whittle'>
<organization>
</organization>
</author>
</front>
<format type='HTML' target='http://www.firstpr.com.au/ip/ivip/pmtud-frag/' />
</reference>
<reference anchor='Ivip6' target='http://www.firstpr.com.au/ip/ivip/ivip6/'>
<front>
<title>
Ivip6 - instead of map-encap, use the 20 bit Flow Label as a Forwarding Label
</title>
<author initials='R.' surname='Whittle' fullname='Robin Whittle'>
<organization>
</organization>
</author>
</front>
<format type='HTML' target='http://www.firstpr.com.au/ip/ivip/ivip6/' />
</reference>
<reference anchor='Ivip Constraints'
target='http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/'>
<front>
<title>
List of constraints on a successful scalable routing solution
which result from the need for widespread voluntary adoption
</title>
<author initials='R.' surname='Whittle' fullname='Robin Whittle'>
<organization>
</organization>
</author>
</front>
<format type='HTML'
target='http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/' />
</reference>
<reference anchor='Ivip Mobility'
target='http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf'>
<front>
<title>
TTR Mobility Extensions for Core-Edge Separation
Solutions to the Internet's Routing Scaling Problem
</title>
<author initials='R.' surname='Whittle' fullname='Robin Whittle'>
<organization>
</organization>
</author>
</front>
<format type='PDF' target='http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf' />
</reference>
</references>
<references title='hIPv4 References'>
&I-D.frejborg-hipv4;
</references>
<references title='Layered Mapping System References'>
<reference anchor='LMS Summary'
target='http://docs.google.com/Doc?docid=0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi&hl=en'>
<front>
<title>
A Layered Mapping System (Summary)
</title>
<author initials='C.' surname='Sun' fullname='Charrie Sun'>
<organization>
</organization>
</author>
</front>
</reference>
<reference anchor='LMS'
target='http://docs.google.com/fileview?id=0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM0LTg5ZjktNmFkYzBhNWJhMWEy&hl=en'>
<front>
<title>
A Layered Mapping System For Scalable Routing
</title>
<author initials='S.' surname='Letong' fullname='Sun Letong'>
<organization>
</organization>
</author>
<author initials='Y.' surname='Xia' fullname='Yin Xia'>
<organization>
</organization>
</author>
<author initials='W.' surname='ZhiLiang' fullname='Wang
ZhiLiang'>
<organization>
</organization>
</author>
<author initials='W.' surname='Jianping' fullname='Wu Jianping'>
<organization>
</organization>
</author>
</front>
</reference>
</references>
<references title='GLI References'>
<reference anchor='GLI'
target='http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth-GLI-Split.pdf'>
<front>
<title>
Global Locator, Local Locator, and Identifier Split (GLI-Split)
</title>
<author initials='M.' surname='Menth' fullname='Michael Menth'>
<organization>
University of Wurzburg, Institute of Computer Science, Germany
</organization>
</author>
<author initials='M.' surname='Hartmann' fullname='Matthias Hartmann'>
<organization>
University of Wurzburg, Institute of Computer Science, Germany
</organization>
</author>
<author initials='D.' surname='Klein' fullname='Dominik Klein'>
<organization>
University of Wurzburg, Institute of Computer Science, Germany
</organization>
</author>
</front>
</reference>
</references>
<references title='TIDR References'>
&I-D.adan-idr-tidr;
<reference anchor='TIDR identifiers'
target='http://www.ietf.org/mail-archive/web/ram/current/msg01308.html'>
<front>
<title>
TIDR using the IDENTIFIERS attribute
</title>
<author initials='J.J.' surname='Adan' fullname='Juan-Jose Adan'>
<organization>
Gerencia de Informatica de la Seguridad Social (GISS)
</organization>
</author>
</front>
</reference>
<reference anchor='TIDR and LISP'
target='http://www.ops.ietf.org/lists/rrg/2007/msg00902.html'>
<front>
<title>
LISP etc architecture
</title>
<author initials='J.J.' surname='Adan' fullname='Juan-Jose Adan'>
<organization>
Gerencia de Informatica de la Seguridad Social (GISS)
</organization>
</author>
</front>
</reference>
<reference anchor='TIDR AS forwarding'
target='http://www.ops.ietf.org/lists/rrg/2008/msg00716.html'>
<front>
<title>
yetAnotherProposal: AS-number forwarding
</title>
<author initials='J.J.' surname='Adan' fullname='Juan-Jose Adan'>
<organization>
Gerencia de Informatica de la Seguridad Social (GISS)
</organization>
</author>
</front>
</reference>
</references>
<references title='ILNP References'>
<reference anchor='ILNP Site'
target='http://ilnp.cs.st-andrews.ac.uk'>
<front>
<title>
ILNP - Identifier/Locator Network Protocol
</title>
<author initials='R.' surname='Atkinson' fullname='Randall Atkinson'>
<organization>
Extreme Networks
</organization>
</author>
<author initials='S.' surname='Bhatti' fullname='Saleem Bhatti'>
<organization>
University of St. Andrews
</organization>
</author>
<author initials='S.' surname='Hailes' fullname='Stephen Hailes'>
<organization>
University College London
</organization>
</author>
<author initials='D.' surname='Rehunathan'
fullname='Devan Rehunathan'>
<organization>
University of St. Andrews
</organization>
</author>
<author initials='M.' surname='Lad' fullname='Manish Lad'>
<organization>
University College London
</organization>
</author>
</front>
</reference>
</references>
<references title='EEMDP References'>
<reference anchor='EEMDP Considerations'
target='http://www.antd.nist.gov/~ksriram/NGRA_map_mgmt.pdf'>
<front>
<title>
Architectural Considerations for Mapping Distribution Protocols
</title>
<author initials='K.' surname='Sriram' fullname='Kotikalapudi Sriram'>
<organization>
National Institute of Standards and Technology
</organization>
</author>
<author initials='Y.T.' surname='Kim' fullname='Young-Tak Kim'>
<organization>
National Institute of Standards and Technology
</organization>
</author>
<author initials='D' surname='Montgomery' fullname='Doug Montgomery'>
<organization>
National Institute of Standards and Technology
</organization>
</author>
</front>
</reference>
<reference anchor='EEMDP Presentation'
target='http://www.antd.nist.gov/~ksriram/MDP_Dublin_KS_Slides.pdf'>
<front>
<title>
Architectural Considerations for Mapping Distribution Protocols
</title>
<author initials='K.' surname='Sriram' fullname='Kotikalapudi Sriram'>
<organization>
National Institute of Standards and Technology
</organization>
</author>
<author initials='Y.T.' surname='Kim' fullname='Young-Tak Kim'>
<organization>
National Institute of Standards and Technology
</organization>
</author>
<author initials='D' surname='Montgomery' fullname='Doug Montgomery'>
<organization>
National Institute of Standards and Technology
</organization>
</author>
</front>
</reference>
</references>
<references title='Evolution References'>
&I-D.zhang-evolution;
<reference anchor='Evolution Grow Presenatation'
target='http://tools.ietf.org/agenda/76/slides/grow-5.pdf'>
<front>
<title>
Virtual Aggregation (VA)
</title>
<author initials='P.' surname='Francis' fullname='Paul Francis'>
<organization>
MPI-SWS
</organization>
</author>
<author initials='X.' surname='Xu' fullname='Xiaohu Xu'>
<organization>
Huawei
</organization>
</author>
<author initials='H.' surname='Ballani' fullname='Hitesh Ballani'>
<organization>
Cornell
</organization>
</author>
<author initials='D.' surname='Jen' fullname='Dan Jen'>
<organization>
UCLA
</organization>
</author>
<author initials='R.' surname='Raszuk' fullname='Robert Raszuk'>
<organization>
Cisco
</organization>
</author>
<author initials='L.' surname='Zhang' fullname='Lixia Zhang'>
<organization>
UCLA
</organization>
</author>
</front>
</reference>
</references>
<references title='Name Based Sockets References'>
<reference anchor='Name Based Sockets'
target='http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf'>
<front>
<title>
Simplifying Internet Applications Development With A Name-Based Sockets Interface
</title>
<author initials='C.' surname='Vogt' fullname='Christian Vogt'>
<organization>
Ericsson
</organization>
</author>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:56:13 |