summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6227.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6227.txt')
-rw-r--r--doc/rfc/rfc6227.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc6227.txt b/doc/rfc/rfc6227.txt
new file mode 100644
index 0000000..6782478
--- /dev/null
+++ b/doc/rfc/rfc6227.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Research Task Force (IRTF) T. Li, Ed.
+Request for Comments: 6227 Cisco Systems, Inc.
+Category: Informational May 2011
+ISSN: 2070-1721
+
+
+ Design Goals for Scalable Internet Routing
+
+Abstract
+
+ It is commonly recognized that the Internet routing and addressing
+ architecture is facing challenges in scalability, mobility, multi-
+ homing, and inter-domain traffic engineering. The Routing Research
+ Group is investigating an alternate architecture to meet these
+ challenges. This document consists of a prioritized list of design
+ goals for the target architecture.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Research Task Force
+ (IRTF). The IRTF publishes the results of Internet-related research
+ and development activities. These results might not be suitable for
+ deployment. This RFC represents the consensus of the Routing
+ Research Group of the Internet Research Task Force (IRTF). Documents
+ approved for publication by the IRSG are not a candidate for any
+ level of Internet Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6227.
+
+Copyright Notice
+
+ Copyright (c) 2011 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
+ 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.
+
+
+
+
+
+
+Li Informational [Page 1]
+
+RFC 6227 Scalable Routing Design Goals May 2011
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Requirements Language ......................................3
+ 1.2. Priorities .................................................3
+ 2. General Design Goals Collected from the Past ....................3
+ 3. Design Goals for a New Routing Architecture .....................3
+ 3.1. Improved Routing Scalability ...............................3
+ 3.2. Scalable Support for Traffic Engineering ...................4
+ 3.3. Scalable Support for Multi-Homing ..........................4
+ 3.4. Decoupling Location and Identification .....................4
+ 3.5. Scalable Support for Mobility ..............................5
+ 3.6. Simplified Renumbering .....................................5
+ 3.7. Modularity, Composability, and Seamlessness ................6
+ 3.8. Routing Quality ............................................6
+ 3.9. Routing Security ...........................................7
+ 3.10. Deployability .............................................7
+ 3.11. Summary of Priorities .....................................7
+ 4. Security Considerations .........................................7
+ 5. References ......................................................8
+ 5.1. Normative References .......................................8
+ 5.2. Informative References .....................................8
+
+1. Introduction
+
+ It is commonly recognized that the Internet routing and addressing
+ architecture is facing challenges in inter-domain scalability,
+ mobility, multi-homing, and inter-domain traffic engineering
+ [RFC4984]. The Routing Research Group (RRG) aims to design an
+ alternate architecture to meet these challenges. This document
+ presents a prioritized list of design goals for the target
+ architecture.
+
+ These goals should be taken as guidelines for the design and
+ evaluation of possible architectural solutions. The expectation is
+ that these goals will be applied with good judgment.
+
+ The goals presented here were initially presented and discussed at
+ the start of the RRG work on a revised routing architecture, and were
+ revisited and finalized after the work on that architecture was
+ complete. As such, this represents both the goals that the RRG
+ started with, and revisions to those goals based on our increased
+ understanding of the space.
+
+
+
+
+
+
+
+
+Li Informational [Page 2]
+
+RFC 6227 Scalable Routing Design Goals May 2011
+
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1.2. Priorities
+
+ Each design goal in this document has been assigned a priority, which
+ is one of the following: 'required', 'strongly desired', or
+ 'desired'.
+
+ Required:
+ The solution is REQUIRED to support this goal.
+
+ Strongly desired:
+ The solution SHOULD support this goal, unless there exist
+ compelling reasons showing that it is unachievable, extremely
+ inefficient, or impractical.
+
+ Desired:
+ The solution SHOULD support this goal.
+
+2. General Design Goals Collected from the Past
+
+ [RFC1958] provides a list of the original architectural principles of
+ the Internet. We incorporate them here by reference, as part of our
+ desired design goals.
+
+3. Design Goals for a New Routing Architecture
+
+3.1. Improved Routing Scalability
+
+ Long experience with inter-domain routing has shown that the global
+ BGP routing table is continuing to grow rapidly [BGPGrowth].
+ Carrying this large amount of state in the inter-domain routing
+ protocols is expensive and places undue cost burdens on network
+ participants that do not necessarily get value from the increases in
+ the routing table size. Thus, the first required goal is to provide
+ significant improvement to the scalability of the inter-domain
+ routing subsystem. It is strongly desired to make the routing
+ subsystem scale independently from the growth of the Internet user
+ population. If there is a coupling between the size of the user base
+ and the scale of the routing subsystem, then it will be very
+ difficult to retain any semblance of scalability. If a solution
+ includes support for alternative routes to support faster
+ convergence, the alternative routes should also factor into routing
+ subsystem scalability.
+
+
+
+Li Informational [Page 3]
+
+RFC 6227 Scalable Routing Design Goals May 2011
+
+
+3.2. Scalable Support for Traffic Engineering
+
+ Traffic engineering is the capability of directing traffic along
+ paths other than those that would be computed by normal IGP/EGP
+ routing. Inter-domain traffic engineering today is frequently
+ accomplished by injecting more-specific prefixes into the global
+ routing table, which results in a negative impact on routing
+ scalability. The additional prefixes injected to enable traffic
+ engineering place an added burden on the scalability of the routing
+ architecture. At the same time, the need for traffic engineering
+ capabilities is essential to network operations. Thus, a scalable
+ solution for inter-domain traffic engineering is strongly desired.
+
+3.3. Scalable Support for Multi-Homing
+
+ Multi-homing is the capability of an organization to be connected to
+ the Internet via more than one other organization. The current
+ mechanism for supporting multi-homing is to let the organization
+ advertise one prefix or multiple prefixes into the global routing
+ system, again resulting in a negative impact on routing scalability.
+ More scalable solutions for multi-homing are strongly desired.
+
+3.4. Decoupling Location and Identification
+
+ Numerous sources have noted that an IP address embodies both host
+ attachment point information and identification information [IEN1].
+ This overloading has caused numerous semantic collisions that have
+ limited the flexibility of the Internet architecture. Therefore, it
+ is desired that a solution separate the host location information
+ namespace from the identification namespace.
+
+ Caution must be taken here to clearly distinguish the decoupling of
+ host location and identification information, and the decoupling of
+ end-site addresses from globally routable prefixes; the latter has
+ been proposed as one of the approaches to a scalable routing
+ architecture. Solutions to both problems, i.e., (1) the decoupling
+ of host location and identification information and (2) a scalable
+ global routing system (whose solution may, or may not, depend on the
+ second decoupling) are required, and it is required that their
+ solutions are compatible with each other.
+
+
+
+
+
+
+
+
+
+
+
+Li Informational [Page 4]
+
+RFC 6227 Scalable Routing Design Goals May 2011
+
+
+3.5. Scalable Support for Mobility
+
+ Mobility is the capability of a host, network, or organization to
+ change its topological connectivity with respect to the remainder of
+ the Internet, while continuing to receive packets from the Internet.
+ Existing mechanisms to provide mobility support include
+
+ 1. renumbering the mobile entity as it changes its topological
+ attachment point(s) to the Internet;
+
+ 2. renumbering and creating a tunnel from the entity's new
+ topological location back to its original location; and
+
+ 3. letting the mobile entity announce its prefixes from its new
+ attachment point(s).
+
+ The first approach alone is considered unsatisfactory, as the change
+ of IP address may break existing transport or higher-level
+ connections for those protocols using IP addresses as identifiers.
+ The second requires the deployment of a 'home agent' to keep track of
+ the mobile entity's current location and adds overhead to the routers
+ involved, as well as adding stretch to the path of an inbound packet.
+ Neither of the first two approaches impacts the routing scalability.
+ The third approach, however, injects dynamic updates into the global
+ routing system as the mobile entity moves. Mechanisms that help to
+ provide more efficient and scalable mobility support are desired,
+ especially when they can be coupled with security -- especially
+ privacy -- and support topological changes at a high rate. Ideally,
+ such mechanisms should completely decouple mobility from routing.
+
+3.6. Simplified Renumbering
+
+ Today, many of the end-sites receive their IP address assignments
+ from their Internet Service Providers (ISPs). When such a site
+ changes providers, for routing to scale, the site must renumber into
+ a new address block assigned by its new ISP. This can be costly,
+ error-prone, and painful [RFC5887]. Automated tools, once developed,
+ are expected to provide significant help in reducing the renumbering
+ pain. It is not expected that renumbering will be wholly automated,
+ as some manual reconfiguration is likely to be necessary for changing
+ the last-mile link. However, the overall cost of renumbering should
+ be drastically lowered.
+
+ In addition to being configured into hosts and routers, where
+ automated renumbering tools can help, IP addresses are also often
+ used for other purposes, such as access control lists. They are also
+ sometimes hard-coded into applications used in environments where
+ failure of the DNS could be catastrophic (e.g., certain remote
+
+
+
+Li Informational [Page 5]
+
+RFC 6227 Scalable Routing Design Goals May 2011
+
+
+ monitoring applications). Although renumbering may be considered a
+ mild inconvenience for some sites, and guidelines have been developed
+ for renumbering a network without a flag day [RFC4192], for others,
+ the necessary changes are sufficiently difficult so as to make
+ renumbering effectively impossible. It is strongly desired that a
+ new architecture allow end-sites to renumber their network with
+ significantly less disruption, or, if renumbering can be eliminated,
+ the new architecture must demonstrate how the topology can be
+ economically morphed to fit the addressing.
+
+3.7. Modularity, Composability, and Seamlessness
+
+ A new routing architecture should be modular: it should subdivide
+ into multiple composable, extensible, and orthogonal subsystems. The
+ interfaces between modules should be natural and seamless, without
+ special cases or restrictions. Similarly, the primitives and
+ abstractions in the architecture should be suitably general, with
+ operations equally applicable to abstractions and concrete entities,
+ and without deleterious side-effects that might hinder communication
+ between endpoints in the Internet. These properties are strongly
+ desired in a solution.
+
+ As an example, if tunneling were used as a part of a solution,
+ tunneling should be completely transparent to both of the endpoints,
+ without requiring new mechanisms for determining the correct maximum
+ datagram size.
+
+ The resulting network should always fully approximate the current
+ best-effort Internet connectivity model, and it should also
+ anticipate changes to that model, e.g., for multiple differentiated
+ and/or guaranteed levels of service in the future.
+
+3.8. Routing Quality
+
+ The routing subsystem is responsible for computing a path from any
+ point in the Internet to any other point in the Internet. The
+ quality of the routes that are computed can be measured by a number
+ of metrics, such as convergence, stability, and stretch.
+
+ The stretch factor is the maximum ratio between the length of a
+ route computed by the routing scheme and that of a shortest path
+ connecting the same pair of nodes [JACM89].
+
+ A solution is strongly desired to provide routing quality equivalent
+ to what is available today, or better.
+
+
+
+
+
+
+Li Informational [Page 6]
+
+RFC 6227 Scalable Routing Design Goals May 2011
+
+
+3.9. Routing Security
+
+ Currently, the routing subsystem is secured through a number of
+ protocol-specific mechanisms of varying strength and applicability.
+ Any new architecture is required to provide at least the same level
+ of security as is deployed as of when the new architecture is
+ deployed.
+
+3.10. Deployability
+
+ A viable solution is required to be deployable from a technical
+ perspective. Furthermore, given the extensive deployed base of
+ today's Internet, a solution is required to be incrementally
+ deployable. This implies that a solution must continue to support
+ those functions in today's routing subsystem that are actually used.
+ This includes, but is not limited to, the ability to control routing
+ based on policy.
+
+3.11. Summary of Priorities
+
+ The following table summarizes the priorities of the design goals
+ discussed above.
+
+ +------------------------+------------------+
+ | Design goal | Priority |
+ +------------------------+------------------+
+ | Scalability | Strongly desired |
+ | Traffic engineering | Strongly desired |
+ | Multi-homing | Strongly desired |
+ | Loc/id separation | Desired |
+ | Mobility | Desired |
+ | Simplified renumbering | Strongly desired |
+ | Modularity | Strongly desired |
+ | Routing quality | Strongly desired |
+ | Routing security | Required |
+ | Deployability | Required |
+ +------------------------+------------------+
+
+4. Security Considerations
+
+ All solutions are required to provide security that is at least as
+ strong as the existing Internet routing and addressing architecture.
+ This document does not suggest any default architecture or protocol,
+ and thus this document introduces no new security issues.
+
+
+
+
+
+
+
+Li Informational [Page 7]
+
+RFC 6227 Scalable Routing Design Goals May 2011
+
+
+5. References
+
+5.1. Normative References
+
+ [RFC1958] Carpenter, B., Ed., "Architectural Principles of the
+ Internet", RFC 1958, June 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
+ Renumbering an IPv6 Network without a Flag Day",
+ RFC 4192, September 2005.
+
+ [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed.,
+ "Report from the IAB Workshop on Routing and
+ Addressing", RFC 4984, September 2007.
+
+ [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
+ Still Needs Work", RFC 5887, May 2010.
+
+5.2. Informative References
+
+ [BGPGrowth] Huston, G., "BGP Routing Table Analysis Reports",
+ <http://bgp.potaroo.net/>.
+
+ [IEN1] Bennett, C., Edge, S., and A. Hinchley, "Issues in the
+ Interconnection of Datagram Networks", Internet
+ Experiment Note (IEN) 1, INDRA Note 637, PSPWN 76,
+ July 1977, <http://www.postel.org/ien/pdf/ien001.pdf>.
+
+ [JACM89] Peleg, D. and E. Upfal, "A trade-off between space and
+ efficiency for routing tables", Journal of the
+ ACM Volume 36, Issue 3, July 1989,
+ <http://portal.acm.org/citation.cfm?id=65953>.
+
+Author's Address
+
+ Tony Li (editor)
+ Cisco Systems, Inc.
+ 170 W. Tasman Dr.
+ San Jose, CA 95134
+ USA
+
+ Phone: +1 408 853 9317
+ EMail: tli@cisco.com
+
+
+
+
+
+Li Informational [Page 8]
+