Internet Research Task Force T. Li, Ed.
Internet-Draft Ericsson
Intended status: Informational January 21, 2010
Expires: July 25, 2010
Recommendation for a Routing Architecture
draft-irtf-rrg-recommendation-04
Abstract
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 preliminary 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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 25, 2010.
Copyright Notice
Copyright (c) 2010 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 July 25, 2010 [Page 1]
Internet-Draft RRG Recommendation January 2010
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Structure of This Document . . . . . . . . . . . . . . . 6
2. Locator Identifier Separation Protocol (LISP) . . . . . . . . 6
2.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 9
3. Routing Architecture for the Next Generation Internet
(RANGI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 12
4. Internet Vastly Improved Plumbing (Ivip) . . . . . . . . . . . 12
4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Extensions . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2.1. TTR Mobility . . . . . . . . . . . . . . . . . . . 13
4.1.2.2. Modified Header Forwarding . . . . . . . . . . . . 14
4.1.3. Gains . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.4. Costs . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 16
5. hIPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.3. Costs And Issues . . . . . . . . . . . . . . . . . . . 18
5.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 18
Li Expires July 25, 2010 [Page 2]
Internet-Draft RRG Recommendation January 2010
5.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 18
6. Name overlay (NOL) service for scalable Internet routing . . . 18
6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 18
6.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 21
6.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 21
7. Compact routing in locator identifier mapping system . . . . . 21
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 21
7.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 22
7.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 22
7.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 22
8. Layered mapping system (LMS) . . . . . . . . . . . . . . . . . 22
8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 22
8.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 23
8.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 24
8.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 24
9. 2-phased mapping . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1.1. Considerations . . . . . . . . . . . . . . . . . . . . 25
9.1.2. My contribution: a 2-phased mapping . . . . . . . . . 25
9.1.3. Gains . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 26
9.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 26
9.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 26
9.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 26
10. Global Locator, Local Locator, and Identifier Split
(GLI-Split) . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 26
10.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 28
10.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 28
10.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 29
10.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 29
11. Tunneled Inter-domain Routing (TIDR) . . . . . . . . . . . . . 29
11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 29
11.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 29
Li Expires July 25, 2010 [Page 3]
Internet-Draft RRG Recommendation January 2010
11.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 30
11.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 30
11.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 30
11.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 30
12. Identifier-Locator Network Protocol (ILNP) . . . . . . . . . . 30
12.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 31
12.1.2. Benefits . . . . . . . . . . . . . . . . . . . . . . . 31
12.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 33
12.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 33
12.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 34
12.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 34
13. Enhanced Efficiency of Mapping Distribution Protocols in
Map-and-Encap Schemes . . . . . . . . . . . . . . . . . . . . 34
13.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 34
13.1.2. Management of Mapping Distribution of Subprefixes
Spread Across Multiple ETRs . . . . . . . . . . . . . 35
13.1.3. Management of Mapping Distribution for Scenarios
with Hierarchy of ETRs and Multi-Homing . . . . . . . 36
13.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 36
13.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 36
13.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 36
14. Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . 36
14.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 37
14.1.1. Need for Evolution . . . . . . . . . . . . . . . . . . 37
14.1.2. Relation to Other RRG Proposals . . . . . . . . . . . 37
14.1.3. Aggregation with Increasing Scopes . . . . . . . . . . 38
14.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 39
14.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 40
14.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 40
15. Name-Based Sockets . . . . . . . . . . . . . . . . . . . . . . 40
15.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 41
15.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 43
15.2.1. Deployment . . . . . . . . . . . . . . . . . . . . . . 43
15.2.2. Edge-networks . . . . . . . . . . . . . . . . . . . . 43
15.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 44
15.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 44
16. Routing and Addressing in Next-Generation EnteRprises
(RANGER) . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
16.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 44
16.1.1. Gains . . . . . . . . . . . . . . . . . . . . . . . . 44
16.1.2. Costs . . . . . . . . . . . . . . . . . . . . . . . . 45
16.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . 45
16.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . 45
16.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . 45
17. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 45
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
Li Expires July 25, 2010 [Page 4]
Internet-Draft RRG Recommendation January 2010
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
20. Security Considerations . . . . . . . . . . . . . . . . . . . 46
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
21.1. Normative References . . . . . . . . . . . . . . . . . . 46
21.2. Informative References . . . . . . . . . . . . . . . . . 46
21.3. LISP References . . . . . . . . . . . . . . . . . . . . . 46
21.4. RANGI References . . . . . . . . . . . . . . . . . . . . 47
21.5. Ivip References . . . . . . . . . . . . . . . . . . . . . 47
21.6. hIPv4 References . . . . . . . . . . . . . . . . . . . . 48
21.7. Layered Mapping System References . . . . . . . . . . . . 48
21.8. GLI References . . . . . . . . . . . . . . . . . . . . . 49
21.9. TIDR References . . . . . . . . . . . . . . . . . . . . . 49
21.10. ILNP References . . . . . . . . . . . . . . . . . . . . . 49
21.11. EEMDP References . . . . . . . . . . . . . . . . . . . . 49
21.12. Evolution References . . . . . . . . . . . . . . . . . . 49
21.13. Name Based Sockets References . . . . . . . . . . . . . . 50
21.14. RANGER References . . . . . . . . . . . . . . . . . . . . 50
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 50
Li Expires July 25, 2010 [Page 5]
Internet-Draft RRG Recommendation January 2010
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 surveys the many of the proposals that were brought
forward for discussion in this activity. For some of the proposals,
this document also includes additional analysis showing some of the
concerns with specific proposals, and how some of those concerns may
be addressed. Readers are cautioned not to draw any conclusions
about the degree of interest or endorsement by the RRG from the
presence of any proposals in this document, or the amount of analysis
devoted to specific proposals.
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
approach.
2. Locator Identifier Separation Protocol (LISP)
2.1. Summary
2.1.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.1.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
Li Expires July 25, 2010 [Page 6]
Internet-Draft RRG Recommendation January 2010
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
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.1.3. Costs
o mapping system infrastructure (map servers, map resolvers, ALT
routers) (new potential business opportunity)
o Interworking infrastructure (proxy ITRs) (new potential business
opportunity)
o overhead for determining/maintaining locator/path liveness (common
issue for all id/loc separation proposals)
2.2. Critique
LISP-ALT distributes mapping to ITRs via (optional, local,
potentially-caching) Map Resolvers and with globally distributed
query servers: ETRs and optional Map Servers.
A fundamental problem with any global query server network is that
the frequently long paths and greater risk of packet loss cause ITRs
to drop or significantly delay the initial packets of many new
sessions. ITRs drop the packet(s) they have no mapping for. After
the mapping arrives, the ITR waits for a resent packet and will
Li Expires July 25, 2010 [Page 7]
Internet-Draft RRG Recommendation January 2010
tunnel that packet correctly. These "initial packet delays" reduce
performance and so create a major barrier to voluntary adoption on
wide enough basis to solve the routing scaling problem.
ALT's delays are compounded by its structure being "aggressively
aggregated", without regard to the geographic location of the
routers. Tunnels between ALT routers will often span
intercontinental distances and traverse many Internet routers.
The many levels to which a query typically ascends in the ALT
hierarchy before descending towards its destination will often
involve excessively long geographic paths and so worsen initial
packet delays.
No solution has been proposed for these problems or for the
contradiction between the need for high aggregation while making the
ALT structure robust against single points of failure.
LISP's ITRs multihoming service restoration depends on them
determining reachability of end-user networks via two or more ETRs.
Large numbers of ITRs doing this is inefficient and may overburden
ETRs.
Testing reachability of the ETRs is complex and costly - and
insufficient. ITRs cannot test network reachability via each ETR,
since the ITRs have no address of a device in that network. So ETRs
must report network un-reachability to ITRs.
LISP involves complex communication between ITRs and ETRs, with UDP
and 64-bit LISP headers in all traffic packets.
The advantage of LISP+ALT is that its ability to handle billions of
EIDs is not constrained by the need to transmit or store the mapping
to any one location. Such numbers, beyond a few tens of millions of
EIDs, will only result if the system is used for Mobility. Yet the
concerns just mentioned about ALT's structure arise from the millions
of ETRs which would be needed just for non-mobile networks.
In LISP's mobility approach each MN needs an RLOC address to be its
own ETR, meaning the MN cannot be behind NAT. Mapping changes must
be sent instantly to all relevant ITRs every time the MN gets a new
address - which LISP cannot achieve.
In order to enforce ISP filtering of incoming packets by source
address, LISP ITRs would have to implement the same filtering on each
decapsulated packet. This may be prohibitively expensive.
LISP monolithically integrates multihoming failure detection and
Li Expires July 25, 2010 [Page 8]
Internet-Draft RRG Recommendation January 2010
restoration decision-making processes into the core-edge separation
scheme itself. End-user networks must rely on the necessarily
limited capabilities which are built into every ITR.
LISP-ALT may be able to solve the routing scaling problem, but
alternative approaches would be superior because they eliminate the
initial packet delay problem and give end-user networks real-time
control over ITR tunneling.
2.3. Rebuttal
2.4. Counterpoint
3. Routing Architecture for the Next Generation Internet (RANGI)
3.1. Summary
3.1.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
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.1.2. Gains
RANGI achieves almost all of goals set by RRG as follows:
1. Routing Scalability: Scalability is achieved by decoupling
identifiers from locators.
Li Expires July 25, 2010 [Page 9]
Internet-Draft RRG Recommendation January 2010
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
greatly.
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
versa.
3.1.3. Costs
1. Host change is required
2. First-hop LDBR change is required to support site-controlled
traffic-engineering capability.
3. The ID->Locator mapping system is a new infrastructure to be
deployed.
4. Proxy needs to be deployed for communication between RANGI-aware
hosts and legacy hosts.
3.2. Critique
RANGI is an ID/locator split protocol that, like HIP, places a
cryptographically signed ID between the network layer (IPv6) and
transport. Unlike the HIP ID, the RANGI ID has a hierarchical
structure that allows it to support ID->locator lookups. This
hierarchical structure addresses two weaknesses of the flat HIP ID:
the difficulty of doing the ID->locator lookup, and the
Li Expires July 25, 2010 [Page 10]
Internet-Draft RRG Recommendation January 2010
administrative scalability of doing firewall filtering on flat IDs.
The usage of this hierarchy is overloaded: it serves to make the ID
unique, to drive the lookup process, and possibly other things like
firewall filtering. More thought is needed as to what constitutes
these levels with respect to these various roles.
The RANGI draft suggests FQDN->ID lookup through DNS, and separately
an ID->locator lookup which may be DNS or may be something else (a
hierarchy of DHTs). It would be more efficient if the FQDN lookup
produces both ID and locators (as does ILNP). Probably DNS alone is
sufficient for the ID->locator lookup since individual DNS servers
can hold very large numbers of mappings.
RANGI provides strong sender identification, but at the cost of
computing crypto. Many hosts (public web servers) may prefer to
forgo the crypto at the expense of losing some functionality
(receiver mobility or dynamic multihome load balance). While RANGI
doesn't require that the receiver validate the sender, it may be good
to have a mechanism whereby the receiver can signal to the sender
that it is not validating, so that the sender can avoid locator
changes.
Architecturally there are many advantages to putting the mapping
function at the end host (versus at the edge). This simplifies the
neighbor aliveness and delayed first packet problems, and avoids
stateful middleboxes. Unfortunately, the early-adopter incentive for
host upgrade may not be adequate (HIP's lack of uptake being an
example).
RANGI does not have an explicit solution for the mobility race
condition (there is no mention of a home-agent like device).
However, host-to-host notification combined with fallback on the
ID->locators lookup (assuming adequate dynamic update of the lookup
system) may be good enough for the vast majority of mobility
situations.
RANGI uses proxies to deal with both legacy IPv6 and IPv4 sites.
RANGI proxies have no mechanisms to deal with the edge-to-edge
aliveness problem. The edge-to-edge proxy approach dirties-up an
otherwise clean end-to-end model.
RANGI exploits existing IPv6 transition technologies (ISATAP and
softwire). These transition technologies are in any event being
pursued outside of RRG and do not need to be specified in RANGI
drafts per se. RANGI only needs to address how it interoperates with
IPv4 and legacy IPv6, which through proxies it appears to do
adequately well.
Li Expires July 25, 2010 [Page 11]
Internet-Draft RRG Recommendation January 2010
3.3. Rebuttal
3.4. Counterpoint
4. Internet Vastly Improved Plumbing (Ivip)
4.1. Summary
4.1.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
devices.
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 July 25, 2010 [Page 12]
Internet-Draft RRG Recommendation January 2010
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.1.2. Extensions
4.1.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 July 25, 2010 [Page 13]
Internet-Draft RRG Recommendation January 2010
4.1.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.1.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.1.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 July 25, 2010 [Page 14]
Internet-Draft RRG Recommendation January 2010
4.2. Critique
Looking at 1000 feet level, Ivip shares the basic design approaches
with LISP and a number of other Map-n-Encap designs based on the
core-edge separation. However the details differ substantially.
Ivip design takes a bold assumption that, with technology advances,
one could afford to maintain a real time distributed global mapping
database for all networks and hosts. Ivip proposes that multiple
parties collaborate to build a mapping distribution system which
pushes all mapping information and updates to local, full database
query servers located in all ISPs within a few seconds. The system
has no single point of failure, and uses end-to end authentication.
"Real time, globally synchronized mapping database" is a critical
assumption in Ivip. Using that as a foundation, Ivip design avoids
several challenging design issues that LISP team has studied
extensively, which include
1. special considerations of mobility support which adds additional
complexity to the overall system;
2. prompt detection of ETR failures and notification to all relevant
ITRs, which turn out to be a rather difficult problem; and
3. development of LISP-ALT lookup sub-system. Ivip assumes the
existence of local query servers with full database with the
latest mapping information changes.
However to be considered as a viable solution to Internet routing
scalability problem, Ivip faces two fundamental questions. First, it
is an entirely open question whether a global-scale system is able to
achieve real time synchronized operations as assumed by Ivip. Past
experiences suggest otherwise.
The second question concerns incremental rollout. Ivip represents an
ambitious approach, with real-time mapping and local full database
query servers - which many people regard as impossible. Developing
and implementing Ivip may take fair amount of resources, yet there is
an open question regarding how to *quantify* the gains by first
movers - both those who will provide the Ivip infrastructure and
those which will use it. Significant global routing table reduction
only happens when a large enough number of parties have adopted Ivip.
The same question arises for most other proposals as well.
One belief is that Ivip's more ambitious mapping system makes a good
design tradeoff for the greater benefits for end-user networks and
for those which develop the infrastructure. Another belief is that
this ambitious design is not viable.
Li Expires July 25, 2010 [Page 15]
Internet-Draft RRG Recommendation January 2010
4.3. Rebuttal
4.4. Counterpoint
5. hIPv4
5.1. Summary
5.1.1. Key Idea
The hierarchical IPv4 framework is adding scalability in the routing
architecture by introducing hierarchy in the IPv4 address space. The
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.
Li Expires July 25, 2010 [Page 16]
Internet-Draft RRG Recommendation January 2010
5.1.2. Gains
1. Improved routing scalability: Adding hierarchy in the address
space enables a hierarchy in the routing architecture. Early
adapters of an ALOC realm will no longer carry the RIB of the DFZ
- only ELOC prefixes of directly attached networks and ALOC
prefixes from other service provider that have migrated.
2. Scalable support for traffic engineering: Multipath enabled
transport protocols are recommended to achieve dynamic load-
balancing of a session. Support for Valiant Load-balancing
schemes has been added to the framework; more research work is
required around VLB switching.
3. Scalable support for multi-homing: Only attachment points of a
multi-homed site are advertised in the DFZ, DNS will inform the
requester how many attachment points the destination endpoint
has. It is the initiating endpoints choice/responsibility which
attachment point is used; endpoints using multipath enabled
transport protocols can make use of several attachment points for
a session.
4. Simplified Renumbering: When changing provider, the local ELOC
prefixes remains intact, only the ALOC prefix is changed on the
endpoints.
5. Decoupling Location and Identifier: The verification tag (SCTP)
and token (MPTCP) can be considered to have the characteristics
of a session identifier and thus a session layer is created
between the transport and application layer in the TCP/IP model
6. Routing quality: The hIPv4 framework introduce no tunneling
mechanisms, only a swap of the IPv4 header and locator header at
the destination ALOC realm is required, thus current routing
algorithms are preserved as such. Valiant Load-balancing might
be used as a new forwarding mechanism.
7. Routing Security: Similar as with today's DFZ, except that ELOC
prefixes can not be high-jacked (by injecting a longest match
prefix) outside an ALOC realm (improved security)
8. Deployability: The hIPv4 framework is an evolution of the current
IPv4 framework and is backwards compatible with the current IPv4
framework. Sessions in a local network and inside an ALOC realm
might in the future still use the current IPv4 framework.
Li Expires July 25, 2010 [Page 17]
Internet-Draft RRG Recommendation January 2010
5.1.3. Costs And Issues
1. Upgrade of the stack at an endpoint or the endpoint should make
use of an ITR/XTR
2. In a multi-homing solution the border routers should be able to
apply policy based routing upon the ALOC value in the locator
header
3. New policies must be set by the RIRs
4. Short timeframe before the expected depletion of the IPv4 address
space occurs
5. Will enterprises give up their global allocation of the current
IPv4 address block they have gained?
6. Co-ordination with MPTCP is highly desirable
5.2. Critique
No critique for this proposal was submitted.
5.3. Rebuttal
5.4. Counterpoint
6. Name overlay (NOL) service for scalable Internet routing
6.1. Summary
6.1.1. Key Idea
The basic idea is to add a name overlay (NOL) on the existing TCP/IP
stack.
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
Li Expires July 25, 2010 [Page 18]
Internet-Draft RRG Recommendation January 2010
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.1.2. Gains
1. Reduce routing table size: Prevent edge network PI address into
transit netwok by deploying gateway NTR
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.
Li Expires July 25, 2010 [Page 19]
Internet-Draft RRG Recommendation January 2010
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.1.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 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.
3. Address translating/rewriting costs on NTRs.
6.2. Critique
1. Applications on hosts need to be rebuilt based on name overlay
library to be NOL-enabled. The legacy softwares that are not
maintained any more will not contribute benefits for routing
scalability in the core-edge elimination situation. In the core-
edge separation scheme, a new gateway NTR (Name Transfer Relay)
is deployed to prevent edge specific PI prefixes into transit
core. It doesn't impede the legacy ends behind the NTR to access
the outside Internet, but the legacy ends cannot or is difficult
to access the ends behind a NTR without the help of NOL.
2. In the scenario of core-edge elimination, the end site will
assigned to multiple PA address space, which lead to renumbering
troubles on switching to other upstream providers. Upgrading
ends to support NOL doesn't give any benefits to edge networks.
It has little incentives to use NOL in the core-edge elimination,
and the same to other host-based ID/locator split proposals. I
believe that the edge networks prefer PI address space to PA
address space whether they are IPv4 or IPv6 networks.
Li Expires July 25, 2010 [Page 20]
Internet-Draft RRG Recommendation January 2010
3. In the scenario of core-edge separation, the additional gateway
NTR is to prevent the specific prefixes from the edge networks,
just like a NAT or the ITR/ETR of LISP. A NTR gateway is can be
seen as an extension of NAT (Network Address Translation).
Although NATs are deployed widely, upgrading them to support NOL
extension or deploying additional new gateway NTRs at the edge
networks are on a voluntary basis and have few economic
incentives.
4. The stateful or stateless translating for each packet traversing
a NTR will require the cost of the CPU and memory of NTRs, and
increase forwarding delay. Thus, it is not appropriated to
deploy NTRs at the high-level transit networks where aggregated
traffic maybe cause the congestion at the NTRs.
5. In the scenario of core-edge separation, the requirement of
multi-homing and inter-domain traffic engineering will make end
sites accessible via multiple different NTRs. For the
reliability, all of the association between multiple NTRs and the
end site name will be kept in DNS, which may increase the load of
DNS.
6. In the support for mobility, it is necessary for the DNS to
update the corresponding name-NTR mapping records in time when an
end system move from behind one NTR to other NTRs. The NOL-
enabled end relies on NOL layer to keep the continuity of
applications data transport, while the underlying TCP/UDP
transport session would be broken when the IP address changed.
6.3. Rebuttal
6.4. Counterpoint
7. Compact routing in locator identifier mapping system
7.1. Summary
7.1.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.
Li Expires July 25, 2010 [Page 21]
Internet-Draft RRG Recommendation January 2010
7.1.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.1.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.
7.2. Critique
No critique for this proposal was submitted.
7.3. Rebuttal
7.4. Counterpoint
8. Layered mapping system (LMS)
8.1. Summary
8.1.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
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.
Li Expires July 25, 2010 [Page 22]
Internet-Draft RRG Recommendation January 2010
8.1.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.1.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.
8.2. Critique
LMS is a mapping mechanism and based on edge-core separations. In
fact, any proposal that needs a global mapping system with keys of
similar properties of that "edge address" in the edge-core separation
can use such a mechanism. This means that those keys are globally
Li Expires July 25, 2010 [Page 23]
Internet-Draft RRG Recommendation January 2010
unique (by authorization or just statistically), at the disposal of
edge users, and may have several satisfied mappings (with different
weights, maybe). Once a proposal that needs mapping but doesn't
specify the mapping mechanism, is used to solve the scalability
problem, LMS can be used to strengthen its function.
The key idea of LMS is similar to LISP+ALT that the mapping system
should be hierarchically organized, to gain scalability in the
storage and update sense and to achieve quick index for mapping
lookup. However, LMS advocates an ISP-independent mapping system and
ETRs are not the authorities of mapping data. ETRs or edge-sites
report their mapping data to related mapping servers.
Though LMS assumes that mapping servers can be incrementally deployed
in that a server may not be constructed if none of its administered
edge addresses are allocated, and that mapping servers can charge for
their services, which provides the economic reason for their
existence, how this brand-new system can be constructed is still not
clear. Explicit layering is only an ideal state, and it rather
analyzes the layering limits and feasibility, than provide a
practical way for deployment.
The drawbacks of LMS's feasibility analysis also include 1) based on
current PC power and may not represent future circumstances
(especially for IPv6); 2) does not consider the variability of
address utilization. Some IP address spaces may be effectively
allocated and used while some may not, causing some mapping servers
overloaded while others poorly utilized. More thoughts are needed as
to the flexibility of the layer design.
LMS doesn't fit well for mobility. It does not solve the problem
when hosts move faster that the mapping updates and propagations
between relative mapping servers. On the other hand, mobile hosts
moving across ASes and changing their attach points (core addresses)
is less frequent than hosts moving within an AS.
I personally advocate that separation needs two planes: edge-core
separation, which is to gain routing table scalability; identity-
location separation, which is to achieve mobility. GLI does a good
clarification and in that case, LMS can be used to provide identity-
to-core address mapping. Of course, other schemes may be competent
and LMS can be incorporate with it if it has globally seen keys and
needs to map them to other namespaces.
8.3. Rebuttal
8.4. Counterpoint
Li Expires July 25, 2010 [Page 24]
Internet-Draft RRG Recommendation January 2010
9. 2-phased mapping
9.1. Summary
9.1.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.1.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.1.3. Gains
1. Any prefixes reconfiguration (aggregation/ deaggregation) within
an AS will not be notified to mapping system.
Li Expires July 25, 2010 [Page 25]
Internet-Draft RRG Recommendation January 2010
2. Possible highly efficient aggregation of the local prefixes (in
the form of an IP space range).
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.1.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
designs.
3. The 2-phased mapping scheme is adaptable to any core/edge split
based proposals.
9.2. Critique
This is a simple idea on how to scale mapping. However personally I
feel the design is too incomplete to be considered a serious input to
RRG. Take the following 2 issues as example:
First, in this 2-phase scheme, an AS is essentially the unit of
destinations (i.e. sending ITRs find out destination AS D, then send
data to one of of D's ETR). This does not offer much choice for
traffic engineering.
Second, there is no consideration whatsoever on failure detection and
handling.
9.3. Rebuttal
9.4. Counterpoint
10. Global Locator, Local Locator, and Identifier Split (GLI-Split)
10.1. Summary
10.1.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
Li Expires July 25, 2010 [Page 26]
Internet-Draft RRG Recommendation January 2010
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.1.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)
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
Li Expires July 25, 2010 [Page 27]
Internet-Draft RRG Recommendation January 2010
have the option to migrate their nodes gradually from non-GLI stacks
to GLI-stacks.
10.1.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)
10.2. Critique
GLI-Split makes a clear distinction between two separation planes:
the separation between identifier and locator, which is to meet end-
users needs including mobility; the separation between local and
global locator, to make the global routing table scalable. The
distinction is needed since ISPs and hosts have different
requirements, also make the changes inside and outside GLI-domains
invisible to their opposites.
A main drawback of GLI-Split is that it puts much burden on hosts.
Before routing a packet received from upper layers, network stacks in
hosts firstly need resolve the DNS name to an IP address; if the IP
address is GLI-formed, it may look up the map from the identifier
extracted from the IP address to the local locator. If the
communication is between different GLI-domains, hosts may further
look up the map from the identifier to the global locator the local
mapping system forwarding requests to the global mapping system for
hosts is just an option. Though host lookup may ease the burden of
intermediate nodes which would otherwise to perform the mapping
lookup, the three lookups by hosts in the worst case may lead to
large delays unless a very efficient mapping mechanism is devised.
The work may also become unpractical for low-powered hosts. On one
hand, GLI-split can provide backward compatibility where classic and
upgraded IPv6 hosts can communicate, which is its big virtue; while
the upgrades may be costly to against hosts enthusiasm to change,
compared to the benefits they would gain.
GLI-split provides additional features to improve TE and to improve
resilience, e.g., exerting multipath routing. However the cost is
that more burdens are placed on hosts, e.g. they may need more lookup
actions and route selections. However, the kind of tradeoffs between
costs and gains exists in most proposals.
I think one improvement of GLI-Split on its support for mobility is
Li Expires July 25, 2010 [Page 28]
Internet-Draft RRG Recommendation January 2010
to update DNS data as GLI-hosts move across GLI-domains. Through
this GLI-corresponding-node can query DNS to get valid global locator
of the GLI-mobile-node and need not to query the global mapping
system (unless it wants to do multipath routing), giving more
incentives for nodes to become GLI-kind. The merit of GLI-Split,
simplified-mobility-handover provision, well supports this
improvement.
GLI-Split claims to use rewriting instead of tunneling for
conversions between local and global locators, when packets span GLI-
domains. The major advantage is that this kind of rewriting needs no
extra states to maintain, since local and global locators need not to
map to each other. Many other rewriting mechanisms instead need to
maintain extra states. It also avoids the MTU problem faced by the
tunneling methods. However, GLI-Split achieves this only by
compressing the namespace size of each attribute (identifier, local
and global locator). GLI-Split codes two terms (identifier and
local/global locator) into an IPv6 address, each has space size of
2^64 or less, while map-and-encaps proposals assume that identifier
and locator each occupies 128 bits space, in the IPv6 scene.
10.3. Rebuttal
10.4. Counterpoint
11. Tunneled Inter-domain Routing (TIDR)
11.1. Summary
11.1.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
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.1.2. Gains
Li Expires July 25, 2010 [Page 29]
Internet-Draft RRG Recommendation January 2010
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.1.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"
11.2. Critique
No critique for this proposal was submitted.
11.3. Rebuttal
11.4. Counterpoint
12. Identifier-Locator Network Protocol (ILNP)
Li Expires July 25, 2010 [Page 30]
Internet-Draft RRG Recommendation January 2010
12.1. Summary
12.1.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.1.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 July 25, 2010 [Page 31]
Internet-Draft RRG Recommendation January 2010
o ILNP improves resilience and network availability while reducing
the global routing state (as compared with the currently deployed
Internet).
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 July 25, 2010 [Page 32]
Internet-Draft RRG Recommendation January 2010
12.1.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.)
12.2. Critique
The primary issue for ILNP is how the deployment incentives and
benefits line up with the RRG goal of reducing the rate of growth of
entries and churn in the core routing table. If a site is currently
using PI space, it can only stop advertising that space when the
entire site is ILNP capable. This needs at least clear elucidation
of the incentives for ILNP which are not related to routing scaling,
in order for there to be a path for this to address the RRG needs.
Similarly, the incentives for upgrading hosts need to align with the
value for those hosts.
A closely related question is whether this mechanism actually
addresses the sites need for PI addresses. Assuming ILNP is
deployed, the site does achieve flexible, resilient, communication
using all of its Internet connections. While the proposal address
the host updates when the host learns of provider changes, there are
other aspects of provider change that are not addressed. This
includes renumbering router, subnets, and certain servers. (It is
presumed that most servers, once the entire site has moved to ILNP,
will not be concerned if their locator changes. However, some
servers must have known locators, such as the DNS server.) The
issues described in draft-carpenter-renum-needs-work-04 will be
ameliorated, but not resolved. To be able to adopt this proposal,
and have sites use it, we need to address these issues. When a site
changes points of attachment only a small amount of DNS provisioning
should be required. The LP record is apparently intended to help
with this. It is also likely that the use of dynamic DNS will help
this.
The ILNP mechanism is described as being suitable for use in
conjunction with mobility. This raises the question of race
conditions. To the degree that mobility concerns are valid at this
time, it is worth asking how communication can be established if a
node is sufficiently mobile that it is moving faster than the DNS
update and DNS fetch cycle can effectively propagate changes.
This proposal does presume that all communication using this
mechanism is tied to DNS names. while it is true that most
Li Expires July 25, 2010 [Page 33]
Internet-Draft RRG Recommendation January 2010
communication does start from a DNS name, it is not the case that all
exchanges have this property. Some communication initiation and
referral can be done with an explicit I/L pair. This does appear to
require some extensions to the existing mechanism (for both sides
adding locators). In general, some additional clarity on the
assumptions regarding DNS, particularly for low end devices, would
seem appropriate.
One issue that this proposal shares with many others is the question
of how to determine which locator pairs (local and remote) are
actually functional. This is an issue both for initial
communications establishment, and for robustly maintaining
communication. While it is likely that a combination of monitoring
of traffic (in the host, where this is tractable), coupled with other
active measures, can address this. ICMP is clearly insufficient.
12.3. Rebuttal
12.4. Counterpoint
13. Enhanced Efficiency of Mapping Distribution Protocols in Map-and-
Encap Schemes
13.1. Summary
13.1.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].
Li Expires July 25, 2010 [Page 34]
Internet-Draft RRG Recommendation January 2010
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.1.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
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
Li Expires July 25, 2010 [Page 35]
Internet-Draft RRG Recommendation January 2010
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.
13.1.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.
13.2. Critique
No critique for this proposal was submitted.
13.3. Rebuttal
13.4. Counterpoint
14. Evolution
Li Expires July 25, 2010 [Page 36]
Internet-Draft RRG Recommendation January 2010
14.1. Summary
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.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
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.
14.1.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
Li Expires July 25, 2010 [Page 37]
Internet-Draft RRG Recommendation January 2010
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.1.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
is needed, nor any change to existing protocols. This brings
scalability relief to individual routers with only a software
upgrade.
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.
Li Expires July 25, 2010 [Page 38]
Internet-Draft RRG Recommendation January 2010
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
edge network is not reported unless and until there are data
packets that are heading towards the failed link.
14.2. Critique
All the RRG proposals that scale the routing share one fundamental
approach, route aggregation, in different forms, e.g., LISP removes
"edge prefixes" using encapsulation at ITRs, ILNP achieves the goal
by locator rewrite. In this evolutionary path proposal, each stage
of the evolution applies aggregation with increasing scopes to solve
a specific scalability problem, and eventually the path leads towards
global routing scalability. E.g., it uses FIB aggregation at single
router level, virtual aggregation at network level, then between
neighbor networks at inter-domain level.
Compared to others, this proposal has the lowest hurdle to
deployment, because it does not require all networks move to use a
global mapping system or to upgrade all hosts, and it is designed for
each individual network to get immediate benefits after its own
deployment.
Critiques to this proposal fall into two types. The first type
concerns several potential issues in the technical design as listed
below:
1. FIB aggregation, at level-3 and level-4, may introduce extra
routable space. Concerns are raised about the potential routing
Li Expires July 25, 2010 [Page 39]
Internet-Draft RRG Recommendation January 2010
loops resulted from forwarding otherwise non-routable packets,
and potential impact on RPF checking. These concerns can be
addressed by choosing a lower level of aggregation and by adding
null routes to minimize the extra space, at the cost of reduced
aggregation gain.
2. Virtual Aggregation changes the traffic paths in an ISP network,
hence introduces path stretch. Changing the traffic path may
also impact the reverse path checking practice used to filter out
packets from spoofed sources. More analysis is need to identify
the potential side-effects of VA and to address
3. The current Virtual aggregation description is difficult to
understand, due to its multiple options for encapsulation and
popular prefix configurations, which makes the mechanism look
over-complicated. More thought is needed to simplify the design
and description.
4. FIB Aggregation and Virtual Aggregation may require additional
operational cost. There may be new design trade-offs that the
operators need to understand in order to select the best option
for their networks. More analysis is needed to identify and
quantify all potential operational costs.
5. Different from a number of other proposals, this solution does
not provide mobility support. It remains an open question
whether the routing system should handle mobility.
The second type of critique concerns whether deploying quick fixes
like FIB aggregation would alleviate scalability problems in the
short term and reduce the incentives for deployong a new
architecture; and whether an evolutionary approach would end up with
adding more and more patches on the old architecture, and not lead to
a fundamentally new architecture as the proposal had expected.
Though this solution may get rolled out more easily and quicker, a
new architecture, if/once deployed, could solve more problems with
cleaner solutions.
14.3. Rebuttal
14.4. Counterpoint
15. Name-Based Sockets
Li Expires July 25, 2010 [Page 40]
Internet-Draft RRG Recommendation January 2010
15.1. Summary
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
applications.
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
Li Expires July 25, 2010 [Page 41]
Internet-Draft RRG Recommendation January 2010
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.
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
scalability.
A more comprehensive description of name-based sockets can be found
in [Name Based Sockets].
Li Expires July 25, 2010 [Page 42]
Internet-Draft RRG Recommendation January 2010
15.2. Critique
Name-based sockets contribution to the routing scalability problem is
to decrease the reliance on PI addresses, allowing a greater use of
PA addresses, and thus a less fragmented routing table. It provides
end hosts with an API which makes the applications address-agnostic.
The name abstraction allows the hosts to use any type of locator,
independent of format or provider. This increases the motivation and
usability of PA addresses. Some applications, in particular
bootstrapping applications, may still require hard coded IP
addresses, and as such will still motivate the use of PI addresses.
15.2.1. Deployment
The main incentives and drivers are geared towards the transition of
applications to the name-based sockets. Adoption by applications
will be driven by benefits in terms of reduced application
development cost. Legacy applications are expected to migrate to the
new API in a slower pace, as the name-based sockets are backwards
compatible, this can happen in an per-host fashion. Also, not all
applications can be ported to a FQDN dependent infrastructure, e.g.
DNS functions. This hurdle is manageable, and may not be a definite
obstacle for the transition of a whole domain, but it needs to be
taken into account when striving for mobility/multi-homing of an
entire site. The transition of functions on individual hosts may be
trivial, either through upgrades/changes to the OS or as linked
libraries. This can still happen incrementally and disjoint, as
compatibility is not affected by the use of name-based sockets.
15.2.2. Edge-networks
The name-based sockets rely on the transition of individual
applications, the name-based sockets are backwards compatible, hence
it does not require bilateral upgrades. This does allow each host to
migrate its applications independently. Name-based sockets may make
an individual client agnostic to the networking medium, be it PA/PI
IP-addresses or in a the future an entirely different networking
medium. However, an entire edge-network, with internal and external
services will not be able to make a complete transition in the near
future. Hence, even if a substantial fraction of the hosts in an
edge-network use name-based sockets, PI addresses may still be
required by the edge-network. In short, new services may be
implemented using name-based sockets, old services may be ported.
Name-based sockets provide an increased motivation to move to PA-
addresses as actual provider independence relies less and less on PI-
addressing.
Li Expires July 25, 2010 [Page 43]
Internet-Draft RRG Recommendation January 2010
15.3. Rebuttal
15.4. Counterpoint
16. Routing and Addressing in Next-Generation EnteRprises (RANGER)
16.1. Summary
RANGER is a locator-identifier separation approach that uses IP-in-IP
encapsulation to connect edge networks across transit networks such
as the global Internet. End systems use endpoint interface
identifier (EID) addresses that may be routable within edge networks
but do not appear in transit network routing tables. EID to Routing
Locator (RLOC) address bindings are instead maintained in mapping
tables and also cached in default router FIBs (i.e., very much the
same as for the global DNS and its associated caching resolvers).
RANGER enterprise networks are organized in a recursive hierarchy
with default mappers connecting lower layers to the next higher layer
in the hierarchy. Default mappers forward initial packets and push
mapping information to lower-tier routers and end systems through
secure redirection.
RANGER is an architectural framework derived from the Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP).
16.1.1. Gains
o provides scalable routing system alternative in instances where
dynamic routing protocols are impractical
o naturally supports a recursively-nested "network-of-networks" (or,
"enterprise-within-enterprise") hierarchy
o uses asymmetric securing mechanisms (i.e., secure neighbor
discovery) to secure router discovery and the redirection
mechanism
o can quickly detect path failures and pick alternate routes
o naturally supports provider-independent addressing
o support for site multihoming and traffic engineering
o ingress filtering for multi-homed sites
o mobility-agile through explicit cache invalidation (much more
reactive than DynDns)
Li Expires July 25, 2010 [Page 44]
Internet-Draft RRG Recommendation January 2010
o supports neighbor discovery and neighbor unreachability detection
over tunnels
o no changes to end systems
o no changes to most routers
o supports IPv6 transition
o compatible with true identity/locator split mechansims such as HIP
(i.e., packets contain HIP HIT as end system identifier, IPv6
address as endpoint Interface iDentifier (EID) in inner IP header
and IPv4 address as Routing LOCator (RLOC) in outer IP header)
o prototype code available
16.1.2. Costs
o new code needed in enterprise border routers
o locator/path liveness detection using RFC4861 neighbor
unreachability detection (i.e., extra control messages, but data-
driven)
16.2. Critique
No critique for this proposal was submitted.
16.3. Rebuttal
16.4. Counterpoint
17. Recommendation
18. 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.
19. IANA Considerations
This memo includes no requests to IANA.
Li Expires July 25, 2010 [Page 45]
Internet-Draft RRG Recommendation January 2010
20. Security Considerations
All solutions are required to provide security that is at least as
strong as the existing Internet routing and addressing architecture.
21. References
21.1. Normative References
[I-D.irtf-rrg-design-goals]
Li, T., "Design Goals for Scalable Internet Routing",
draft-irtf-rrg-design-goals-01 (work in progress),
July 2007.
[I-D.narten-radir-problem-statement]
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.
21.2. Informative References
[I-D.carpenter-renum-needs-work]
Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
still needs work", draft-carpenter-renum-needs-work-05
(work in progress), January 2010.
21.3. LISP References
[I-D.farinacci-lisp-lig]
Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
draft-farinacci-lisp-lig-01 (work in progress), May 2009.
[I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-05 (work in progress), September 2009.
[I-D.ietf-lisp-alt]
Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-01
(work in progress), May 2009.
[I-D.ietf-lisp-interworking]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
Li Expires July 25, 2010 [Page 46]
Internet-Draft RRG Recommendation January 2010
"Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-00 (work in progress),
May 2009.
[I-D.ietf-lisp-ms]
Fuller, V. and D. Farinacci, "LISP Map Server",
draft-ietf-lisp-ms-04 (work in progress), October 2009.
[I-D.meyer-lisp-mn]
Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
Mobility Architecture", draft-meyer-lisp-mn-00 (work in
progress), July 2009.
[I-D.meyer-loc-id-implications]
Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", draft-meyer-loc-id-implications-01
(work in progress), January 2009.
21.4. RANGI References
[I-D.xu-rangi]
Xu, X., "Routing Architecture for the Next Generation
Internet (RANGI)", draft-xu-rangi-01 (work in progress),
July 2009.
[I-D.xu-rangi-proxy]
Xu, X., "Transition Mechanisms for Routing Architecture
for the Next Generation Internet (RANGI)",
draft-xu-rangi-proxy-01 (work in progress), July 2009.
[RANGI] Xu, X., "Routing Architecture for the Next-Generation
Internet (RANGI)",
<http://www.ietf.org/proceedings/09nov/slides/RRG-1.ppt>.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
21.5. Ivip References
[I-D.whittle-ivip-db-fast-push]
Whittle, R., "Ivip Mapping Database Fast Push",
draft-whittle-ivip-db-fast-push-03 (work in progress),
January 2010.
[I-D.whittle-ivip4-etr-addr-forw]
Whittle, R., "Ivip4 ETR Address Forwarding",
draft-whittle-ivip4-etr-addr-forw-01 (work in progress),
August 2008.
Li Expires July 25, 2010 [Page 47]
Internet-Draft RRG Recommendation January 2010
[Ivip Constraints]
Whittle, R., "List of constraints on a successful scalable
routing solution which result from the need for widespread
voluntary adoption",
<http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/>.
[Ivip Mobility]
Whittle, R., "TTR Mobility Extensions for Core-Edge
Separation Solutions to the Internet's Routing Scaling
Problem",
<http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf>.
[Ivip PMTUD]
Whittle, R., "IPTM - Ivip's approach to solving the
problems with encapsulation overhead, MTU, fragmentation
and Path MTU Discovery",
<http://www.firstpr.com.au/ip/ivip/pmtud-frag/>.
[Ivip Summary]
Whittle, R., "Ivip (Internet Vastly Improved Plumbing)
Conceptual Summary and Analysis",
<http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf>.
[Ivip6] Whittle, R., "Ivip6 - instead of map-encap, use the 20 bit
Flow Label as a Forwarding Label",
<http://www.firstpr.com.au/ip/ivip/ivip6/>.
21.6. hIPv4 References
[I-D.frejborg-hipv4]
Frejborg, P., "Hierarchical IPv4 Framework",
draft-frejborg-hipv4-04 (work in progress), November 2009.
21.7. Layered Mapping System References
[LMS] Letong, S., Xia, Y., ZhiLiang, W., and W. Jianping, "A
Layered Mapping System For Scalable Routing", <http://
docs.google.com/
fileview?id=0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM0LTg5ZjktN
mFkYzBhNWJhMWEy&hl=en>.
[LMS Summary]
Sun, C., "A Layered Mapping System (Summary)", <http://
docs.google.com/
Doc?docid=0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi&hl=en>.
Li Expires July 25, 2010 [Page 48]
Internet-Draft RRG Recommendation January 2010
21.8. GLI References
[GLI] Menth, M., Hartmann, M., and D. Klein, "Global Locator,
Local Locator, and Identifier Split (GLI-Split)", <http://
www3.informatik.uni-wuerzburg.de/~menth/Publications/
papers/Menth-GLI-Split.pdf>.
21.9. TIDR References
[I-D.adan-idr-tidr]
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",
<http://www.ops.ietf.org/lists/rrg/2008/msg00716.html>.
[TIDR and LISP]
Adan, J., "LISP etc architecture",
<http://www.ops.ietf.org/lists/rrg/2007/msg00902.html>.
[TIDR identifiers]
Adan, J., "TIDR using the IDENTIFIERS attribute", <http://
www.ietf.org/mail-archive/web/ram/current/msg01308.html>.
21.10. ILNP References
[ILNP Site]
Atkinson, R., Bhatti, S., Hailes, S., Rehunathan, D., and
M. Lad, "ILNP - Identifier/Locator Network Protocol",
<http://ilnp.cs.st-andrews.ac.uk>.
21.11. EEMDP References
[EEMDP Considerations]
Sriram, K., Kim, Y., and D. Montgomery, "Architectural
Considerations for Mapping Distribution Protocols",
<http://www.antd.nist.gov/~ksriram/NGRA_map_mgmt.pdf>.
[EEMDP Presentation]
Sriram, K., Kim, Y., and D. Montgomery, "Architectural
Considerations for Mapping Distribution Protocols", <http:
//www.antd.nist.gov/~ksriram/MDP_Dublin_KS_Slides.pdf>.
21.12. Evolution References
[Evolution Grow Presenatation]
Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
Li Expires July 25, 2010 [Page 49]
Internet-Draft RRG Recommendation January 2010
L. Zhang, "Virtual Aggregation (VA)",
<http://tools.ietf.org/agenda/76/slides/grow-5.pdf>.
[I-D.zhang-evolution]
Zhang, B. and L. Zhang, "Evolution Towards Global Routing
Scalability", draft-zhang-evolution-02 (work in progress),
October 2009.
21.13. Name Based Sockets References
[Name Based Sockets]
Vogt, C., "Simplifying Internet Applications Development
With A Name-Based Sockets Interface", <http://
christianvogt.mailup.net/pub/
vogt-2009-name-based-sockets.pdf>.
21.14. RANGER References
[I-D.russert-rangers]
Russert, S., Fleischman, E., and F. Templin, "RANGER
Scenarios", draft-russert-rangers-01 (work in progress),
September 2009.
[I-D.templin-intarea-seal]
Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", draft-templin-intarea-seal-08 (work in
progress), January 2010.
[I-D.templin-intarea-vet]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-intarea-vet-06 (work in progress),
January 2010.
[I-D.templin-ranger]
Templin, F., "Routing and Addressing in Next-Generation
EnteRprises (RANGER)", draft-templin-ranger-09 (work in
progress), October 2009.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
Li Expires July 25, 2010 [Page 50]
Internet-Draft RRG Recommendation January 2010
Author's Address
Tony Li (editor)
Ericsson
300 Holger Way
San Jose, CA 95134
USA
Phone: +1 408 750 5160
Email: tony.li@tony.li
Li Expires July 25, 2010 [Page 51]
