Internet Research Task Force (IRTF) T. Li, Ed.
Request for Comments: 6227 Cisco Systems, Inc.
Category: Informational May 2011
ISSN: 2070-1721
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
可扩展Internet路由的设计目标
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.
人们普遍认为，Internet路由和寻址体系结构在可扩展性、移动性、多主和域间流量工程方面面临挑战。路由研究小组正在研究一种替代体系结构来应对这些挑战。本文档包括目标体系结构的设计目标的优先列表。
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.
本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表了互联网研究任务组（IRTF）路由研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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 ....................................................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
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.
人们普遍认为，Internet路由和寻址体系结构在域间可扩展性、移动性、多主和域间流量工程方面面临挑战[RFC4984]。路由研究组（RRG）的目标是设计一种替代体系结构来应对这些挑战。本文档提供了目标体系结构的设计目标的优先列表。
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.
此处提出的目标最初是在RRG关于修改后的路由架构的工作开始时提出和讨论的，并在该架构的工作完成后重新讨论和最终确定。因此，这既代表了RRG开始时的目标，也代表了基于我们对空间的进一步理解对这些目标的修订。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
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.
期望：解决方案应支持此目标。
[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.
[RFC1958]提供了互联网原始架构原则的列表。我们通过引用将它们合并到这里，作为我们期望的设计目标的一部分。
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.
长期的域间路由经验表明，全局BGP路由表继续快速增长[BGPGrowth]。在域间路由协议中承载如此大量的状态是昂贵的，并且给网络参与者带来了不必要的成本负担，这些网络参与者不一定从路由表大小的增加中获得价值。因此，第一个需要的目标是显著提高域间路由子系统的可伸缩性。强烈希望使路由子系统的规模独立于互联网用户数量的增长。如果用户群的规模和路由子系统的规模之间存在耦合，那么很难保持任何可伸缩性的外观。如果解决方案包括支持替代路由以支持更快的收敛，则替代路由还应考虑到路由子系统的可伸缩性。
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.
流量工程是指沿着非正常IGP/EGP路由计算的路径引导流量的能力。如今，域间流量工程通常是通过向全局路由表中注入更具体的前缀来完成的，这会对路由可伸缩性产生负面影响。为实现流量工程而注入的额外前缀增加了路由体系结构的可伸缩性负担。同时，对流量工程能力的需求对网络运营至关重要。因此，迫切需要一种可扩展的域间流量工程解决方案。
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.
多主机是指一个组织通过多个其他组织连接到Internet的能力。当前支持多归属的机制是让组织将一个或多个前缀发布到全局路由系统中，这同样会对路由可伸缩性产生负面影响。迫切需要更具可扩展性的多主机解决方案。
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.
许多消息来源指出，IP地址包含主机连接点信息和标识信息[IEN1]。这种过载导致了大量语义冲突，限制了Internet体系结构的灵活性。因此，需要一种将主机位置信息命名空间与标识命名空间分离的解决方案。
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.
这里必须注意清楚区分主机位置和标识信息的解耦，以及终端地址与全局可路由前缀的解耦；后者被认为是可扩展路由体系结构的方法之一。这两个问题的解决方案都是必需的，即：（1）主机位置和标识信息的解耦；（2）可伸缩的全局路由系统（其解决方案可能取决于或可能不取决于第二次解耦），并且要求它们的解决方案彼此兼容。
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
移动性是指主机、网络或组织在继续从Internet接收数据包的同时，改变其相对于Internet其余部分的拓扑连接的能力。提供移动支持的现有机制包括
1. renumbering the mobile entity as it changes its topological attachment point(s) to the Internet;
1. 当移动实体更改其到互联网的拓扑连接点时，对其重新编号；
2. renumbering and creating a tunnel from the entity's new topological location back to its original location; and
2. 重新编号并创建从实体的新拓扑位置返回其原始位置的隧道；和
3. letting the mobile entity announce its prefixes from its new attachment point(s).
3. 让移动实体从其新的连接点宣布其前缀。
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.
仅第一种方法被认为是不令人满意的，因为IP地址的更改可能会中断那些使用IP地址作为标识符的协议的现有传输或更高级别的连接。第二种方法需要部署“归属代理”，以跟踪移动实体的当前位置，并增加相关路由器的开销，以及延长入站数据包的路径。前两种方法都不会影响路由可伸缩性。然而，第三种方法在移动实体移动时向全局路由系统注入动态更新。需要有助于提供更高效和可扩展的移动支持的机制，特别是当它们可以与安全性（特别是隐私）结合在一起，并且支持高速率的拓扑变化时。理想情况下，这种机制应该将移动性与路由完全解耦。
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.
如今，许多终端站点从其互联网服务提供商（ISP）处获得IP地址分配。当这样一个站点改变提供商时，为了使路由更具规模，该站点必须重新编号为其新ISP分配的新地址块。这可能代价高昂、容易出错且痛苦[RFC5887]。自动化工具一旦开发出来，有望在减少重新编号痛苦方面提供重大帮助。预计重新编号不会完全自动化，因为更改最后一英里链路可能需要一些手动重新配置。然而，重新编号的总成本应该大大降低。
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
除了配置到主机和路由器中（自动重新编号工具可以提供帮助），IP地址还经常用于其他目的，如访问控制列表。它们有时还硬编码到应用程序中，用于DNS故障可能是灾难性的环境（例如，某些远程应用程序）
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.
监控应用程序）。虽然重新编号可能会对某些站点造成轻微不便，并且已经制定了在没有卖旗日的情况下重新编号网络的指南[RFC4192]，但对于其他站点，必要的更改非常困难，因此无法有效地重新编号。强烈希望一种新的体系结构允许终端站点以显著较少的中断对其网络进行重新编号，或者，如果可以消除重新编号，则新的体系结构必须证明如何经济地改变拓扑以适应寻址。
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.
由此产生的网络应始终完全近似于当前尽力而为的互联网连接模型，并且还应预测该模型的变化，例如，未来多个差异化和/或保证的服务级别。
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.
路由子系统负责计算从Internet上任何一点到Internet上任何其他点的路径。计算的路由的质量可以通过许多度量来衡量，例如收敛性、稳定性和拉伸。
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].
拉伸系数是由路由方案计算的路由长度与连接同一对节点的最短路径长度之间的最大比率[JACM89]。
A solution is strongly desired to provide routing quality equivalent to what is available today, or better.
强烈需要一种解决方案来提供与当前可用的路由质量相当或更好的路由质量。
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.
目前，路由子系统是通过一些不同强度和适用性的协议特定机制来保护的。任何新体系结构都需要提供至少与部署新体系结构时相同的安全级别。
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.
从技术角度来看，一个可行的解决方案需要是可部署的。此外，考虑到当今互联网广泛的部署基础，需要一个可增量部署的解决方案。这意味着解决方案必须继续支持当前路由子系统中实际使用的功能。这包括但不限于基于策略控制路由的能力。
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 |
+------------------------+------------------+
+------------------------+------------------+
| 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 |
+------------------------+------------------+
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.
所有解决方案都需要提供至少与现有Internet路由和寻址体系结构一样强大的安全性。本文档不建议任何默认体系结构或协议，因此本文档不会引入新的安全问题。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，Ed.“互联网的架构原则”，RFC19581996年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]Baker，F.，Lear，E.，和R.Droms，“在没有国旗日的情况下对IPv6网络重新编号的程序”，RFC 41922005年9月。
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
[RFC4984]Meyer，D.，Ed.，Zhang，L.，Ed.，和K.Fall，Ed.，“IAB路由和寻址研讨会报告”，RFC 4984，2007年9月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887]Carpenter，B.，Atkinson，R.，和H.Flinck，“重新编号仍然需要工作”，RFC 5887，2010年5月。
[BGPGrowth] Huston, G., "BGP Routing Table Analysis Reports", <http://bgp.potaroo.net/>.
[BGPGrowth]Huston，G.，“BGP路由表分析报告”<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>.
[IEN1]Bennett，C.，Edge，S.和A.Hinchley，“数据报网络互连中的问题”，互联网实验说明（IEN）1，INDRA注释637，PSPWN 76，1977年7月<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>.
[JACM89]Peleg，D.和E.Upfal，“路由表的空间和效率之间的权衡”，《ACM杂志》第36卷，第3期，1989年7月<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
Tony Li（编辑）Cisco Systems，Inc.170 W.Tasman Dr.San Jose，CA 95134美国
Phone: +1 408 853 9317
EMail: tli@cisco.com
Phone: +1 408 853 9317
EMail: tli@cisco.com