Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


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


 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

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
 ( 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
 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",
 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
    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.
    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

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",
 [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, <>.
 [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,

Author's Address

 Tony Li (editor)
 Cisco Systems, Inc.
 170 W. Tasman Dr.
 San Jose, CA  95134
 Phone: +1 408 853 9317

Li Informational [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6227.txt · Last modified: 2011/05/07 00:06 (external edit)