Design Goals for Scalable Internet Routing
draft-irtf-rrg-design-goals-06

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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on July 7, 2011.

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. 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 Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Requirements Language
    1.2.  Priorities
2.  General Design Goals Collected from Past
3.  Design Goals for A New Routing Architecture
    3.1.  Improved routing scalability
    3.2.  Scalable support for traffic engineering
    3.3.  Scalable support for multi-homing
    3.4.  Decoupling location and identification
    3.5.  Scalable support for mobility
    3.6.  Simplified renumbering
    3.7.  Modularity, composability, and seamlessness
    3.8.  Routing quality
    3.9.  Routing security
    3.10.  Deployability
    3.11.  Summary of priorities
4.  IANA Considerations
5.  Security Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Author's Address

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] (Meyer, D., Zhang, L., and K. Fall, “Report from the IAB Workshop on Routing and Addressing,” September 2007.) 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 RG started with, plus revisions to those goals based on our increased understanding of the space.

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

1.2.  Priorities

Each design goal in this document has been assigned a priority, which is one of 'required', 'strongly desired', and 'desired'.

Required:

The solution is REQUIRED to support this goal.

Strongly desired:

The solution SHOULD support this goal unless there exist compelling reasons showing it is unachievable, extremely inefficient, or impractical.

Desired:

The solution SHOULD support this goal.

2.  General Design Goals Collected from Past

[RFC1958] (Carpenter, B., “Architectural Principles of the Internet,” June 1996.) 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] (Huston, G., “BGP Routing Table Analysis Reports,” .). 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.

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 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 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] (Bennett, C., Edge, S., and A. Hinchley, “Issues in the Interconnection of Datagram Networks,” July 1977.) 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.

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 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 (ISP). 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] (Carpenter, B., Atkinson, R., and H. Flinck, “Renumbering Still Needs Work,” May 2010.). 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 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] (Baker, F., Lear, E., and R. Droms, “Procedures for Renumbering an IPv6 Network without a Flag Day,” September 2005.), 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 upon levels of service in the future.

3.8.  Routing quality

The routing subsystem is responsible for computing a path from any point on 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 scheme and that of a shortest path connecting the same pair of nodes. [JACM89] (Peleg, D. and E. Upfal, “A trade-off between space and efficiency for routing tables,” July 1989.)

A solution is strongly desired to provide routing quality equivalent to what is available today or better.

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

4.  IANA Considerations

This memo includes no requests to IANA.

5.  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 default any architecture or any protocol, and thus this document introduces no new security issues.

6.  References

6.1. Normative References

6.2. Informative References

Author's Address