Internet Research Task Force (IRTF) A. Doria
Request for Comments: 5772 LTU
Category: Historic E. Davies
ISSN: 2070-1721 Folly Consulting
F. Kastenholz
BBN Technologies
February 2010
Internet Research Task Force (IRTF) A. Doria
Request for Comments: 5772 LTU
Category: Historic E. Davies
ISSN: 2070-1721 Folly Consulting
F. Kastenholz
BBN Technologies
February 2010
A Set of Possible Requirements for a Future Routing Architecture
未来路由体系结构的一组可能需求
Abstract
摘要
The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group (RRG) in 2001, with some editorial updates up to 2006. The two sub-groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future.
本文件中描述的路由体系结构要求由IRTF路由研究组（RRG）下属的两个小组于2001年提出，并在2006年之前进行了一些编辑更新。这两个小组独立工作，产生的需求代表了问题和解决问题所需的两种不同观点。本文档可作为推荐阅读的一部分，供将来从事互联网路由体系结构设计的人员参考。
The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication.
该文件在IRTF RRG的支持下发布，作为当时完成工作的记录，但有一项谅解，即该文件不一定代表发布之日研究小组的最新技术理解或技术共识。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for the historical record.
本文件不是互联网标准跟踪规范；它是为了历史记录而出版的。
This document defines a Historic Document for the Internet community. 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 individual opinion(s) of one or more members 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/rfc5772.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5772.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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. Background ......................................................4
2. Results from Group A ............................................5
2.1. Group A - Requirements for a Next Generation Routing and
Addressing Architecture ....................................5
2.1.1. Architecture ........................................6
2.1.2. Separable Components ................................6
2.1.3. Scalable ............................................7
2.1.4. Lots of Interconnectivity ..........................10
2.1.5. Random Structure ...................................10
2.1.6. Multi-Homing .......................................11
2.1.7. Multi-Path .........................................11
2.1.8. Convergence ........................................12
2.1.9. Routing System Security ............................14
2.1.10. End Host Security .................................16
2.1.11. Rich Policy .......................................16
2.1.12. Incremental Deployment ............................19
2.1.13. Mobility ..........................................19
2.1.14. Address Portability ...............................20
2.1.15. Multi-Protocol ....................................20
2.1.16. Abstraction .......................................20
2.1.17. Simplicity ........................................21
2.1.18. Robustness ........................................21
2.1.19. Media Independence ................................22
2.1.20. Stand-Alone .......................................22
2.1.21. Safety of Configuration ...........................23
2.1.22. Renumbering .......................................23
2.1.23. Multi-Prefix ......................................23
2.1.24. Cooperative Anarchy ...............................23
2.1.25. Network-Layer Protocols and Forwarding Model ......23
2.1.26. Routing Algorithm .................................23
2.1.27. Positive Benefit ..................................24
2.1.28. Administrative Entities and the IGP/EGP Split .....24
2.2. Non-Requirements ..........................................25
2.2.1. Forwarding Table Optimization ......................25
1. Background ......................................................4
2. Results from Group A ............................................5
2.1. Group A - Requirements for a Next Generation Routing and
Addressing Architecture ....................................5
2.1.1. Architecture ........................................6
2.1.2. Separable Components ................................6
2.1.3. Scalable ............................................7
2.1.4. Lots of Interconnectivity ..........................10
2.1.5. Random Structure ...................................10
2.1.6. Multi-Homing .......................................11
2.1.7. Multi-Path .........................................11
2.1.8. Convergence ........................................12
2.1.9. Routing System Security ............................14
2.1.10. End Host Security .................................16
2.1.11. Rich Policy .......................................16
2.1.12. Incremental Deployment ............................19
2.1.13. Mobility ..........................................19
2.1.14. Address Portability ...............................20
2.1.15. Multi-Protocol ....................................20
2.1.16. Abstraction .......................................20
2.1.17. Simplicity ........................................21
2.1.18. Robustness ........................................21
2.1.19. Media Independence ................................22
2.1.20. Stand-Alone .......................................22
2.1.21. Safety of Configuration ...........................23
2.1.22. Renumbering .......................................23
2.1.23. Multi-Prefix ......................................23
2.1.24. Cooperative Anarchy ...............................23
2.1.25. Network-Layer Protocols and Forwarding Model ......23
2.1.26. Routing Algorithm .................................23
2.1.27. Positive Benefit ..................................24
2.1.28. Administrative Entities and the IGP/EGP Split .....24
2.2. Non-Requirements ..........................................25
2.2.1. Forwarding Table Optimization ......................25
2.2.2. Traffic Engineering ................................25
2.2.3. Multicast ..........................................25
2.2.4. Quality of Service (QoS) ...........................26
2.2.5. IP Prefix Aggregation ..............................26
2.2.6. Perfect Safety .....................................26
2.2.7. Dynamic Load Balancing .............................27
2.2.8. Renumbering of Hosts and Routers ...................27
2.2.9. Host Mobility ......................................27
2.2.10. Backward Compatibility ............................27
3. Requirements from Group B ......................................27
3.1. Group B - Future Domain Routing Requirements ..............28
3.2. Underlying Principles .....................................28
3.2.1. Inter-Domain and Intra-Domain ......................29
3.2.2. Influences on a Changing Network ...................29
3.2.3. High-Level Goals ...................................31
3.3. High-Level User Requirements ..............................35
3.3.1. Organizational Users ...............................35
3.3.2. Individual Users ...................................37
3.4. Mandated Constraints ......................................38
3.4.1. The Federated Environment ..........................39
3.4.2. Working with Different Sorts of Networks ...........39
3.4.3. Delivering Resilient Service .......................39
3.4.4. When Will the New Solution Be Required? ............40
3.5. Assumptions ...............................................40
3.6. Functional Requirements ...................................42
3.6.1. Topology ...........................................43
3.6.2. Distribution .......................................44
3.6.3. Addressing .........................................48
3.6.4. Statistics Support .................................50
3.6.5. Management Requirements ............................50
3.6.6. Provability ........................................51
3.6.7. Traffic Engineering ................................52
3.6.8. Support for Middleboxes ............................54
3.7. Performance Requirements ..................................54
3.8. Backward Compatibility (Cutover) and Maintainability ......55
3.9. Security Requirements .....................................56
3.10. Debatable Issues .........................................57
3.10.1. Network Modeling ..................................58
3.10.2. System Modeling ...................................58
3.10.3. One, Two, or Many Protocols .......................59
3.10.4. Class of Protocol .................................59
3.10.5. Map Abstraction ...................................59
3.10.6. Clear Identification for All Entities .............60
3.10.7. Robustness and Redundancy .........................60
3.10.8. Hierarchy .........................................60
3.10.9. Control Theory ....................................61
3.10.10. Byzantium ........................................61
3.10.11. VPN Support ......................................61
2.2.2. Traffic Engineering ................................25
2.2.3. Multicast ..........................................25
2.2.4. Quality of Service (QoS) ...........................26
2.2.5. IP Prefix Aggregation ..............................26
2.2.6. Perfect Safety .....................................26
2.2.7. Dynamic Load Balancing .............................27
2.2.8. Renumbering of Hosts and Routers ...................27
2.2.9. Host Mobility ......................................27
2.2.10. Backward Compatibility ............................27
3. Requirements from Group B ......................................27
3.1. Group B - Future Domain Routing Requirements ..............28
3.2. Underlying Principles .....................................28
3.2.1. Inter-Domain and Intra-Domain ......................29
3.2.2. Influences on a Changing Network ...................29
3.2.3. High-Level Goals ...................................31
3.3. High-Level User Requirements ..............................35
3.3.1. Organizational Users ...............................35
3.3.2. Individual Users ...................................37
3.4. Mandated Constraints ......................................38
3.4.1. The Federated Environment ..........................39
3.4.2. Working with Different Sorts of Networks ...........39
3.4.3. Delivering Resilient Service .......................39
3.4.4. When Will the New Solution Be Required? ............40
3.5. Assumptions ...............................................40
3.6. Functional Requirements ...................................42
3.6.1. Topology ...........................................43
3.6.2. Distribution .......................................44
3.6.3. Addressing .........................................48
3.6.4. Statistics Support .................................50
3.6.5. Management Requirements ............................50
3.6.6. Provability ........................................51
3.6.7. Traffic Engineering ................................52
3.6.8. Support for Middleboxes ............................54
3.7. Performance Requirements ..................................54
3.8. Backward Compatibility (Cutover) and Maintainability ......55
3.9. Security Requirements .....................................56
3.10. Debatable Issues .........................................57
3.10.1. Network Modeling ..................................58
3.10.2. System Modeling ...................................58
3.10.3. One, Two, or Many Protocols .......................59
3.10.4. Class of Protocol .................................59
3.10.5. Map Abstraction ...................................59
3.10.6. Clear Identification for All Entities .............60
3.10.7. Robustness and Redundancy .........................60
3.10.8. Hierarchy .........................................60
3.10.9. Control Theory ....................................61
3.10.10. Byzantium ........................................61
3.10.11. VPN Support ......................................61
3.10.12. End-to-End Reliability ...........................62
3.10.13. End-to-End Transparency ..........................62
4. Security Considerations ........................................62
5. IANA Considerations ............................................63
6. Acknowledgments ................................................63
7. Informative References .........................................65
3.10.12. End-to-End Reliability ...........................62
3.10.13. End-to-End Transparency ..........................62
4. Security Considerations ........................................62
5. IANA Considerations ............................................63
6. Acknowledgments ................................................63
7. Informative References .........................................65
In 2001, the IRTF Routing Research Group (IRTF RRG) chairs, Abha Ahuja and Sean Doran, decided to establish a sub-group to look at requirements for inter-domain routing (IDR). A group of well-known routing experts was assembled to develop requirements for a new routing architecture. Their mandate was to approach the problem starting from a blank slate. This group was free to take any approach, including a revolutionary approach, in developing requirements for solving the problems they saw in inter-domain routing.
2001年，IRTF路由研究组（IRTF RRG）主席Abha Ahuja和Sean Doran决定成立一个小组，研究域间路由（IDR）的要求。一组著名的路由专家被召集起来，为新的路由架构开发需求。他们的任务是从一张白纸开始处理这个问题。这个团队可以自由地采取任何方法，包括革命性的方法，来开发解决域间路由问题的需求。
Simultaneously, an independent effort was started in Sweden with a similar goal. A team, calling itself Babylon, with participation from vendors, service providers, and academia assembled to understand the history of inter-domain routing, to research the problems seen by the service providers, and to develop a proposal of requirements for a follow-on to the current routing architecture. This group's remit required an evolutionary approach starting from current routing architecture and practice. In other words, the group limited itself to developing an evolutionary strategy. The Babylon group was later folded into the IRTF RRG as Sub-Group B to distinguish it from the original RRG Sub-Group A.
与此同时，瑞典也开始了一项独立的努力，目标与此类似。一个自称为巴比伦的团队，来自供应商、服务提供商和学术界，他们聚集在一起，了解域间路由的历史，研究服务提供商所看到的问题，并为当前路由架构的后续发展提出需求建议。该团队的职责要求从当前的路由架构和实践出发，采用一种渐进的方法。换句话说，该集团仅限于发展一种进化战略。巴比伦群后来被折叠成IRTF RRG，作为B亚群，以区别于原始RRG亚群A。
One of the questions that arose while the groups were working in isolation was whether there would be many similarities between their sets of requirements. That is, would the requirements that grew from a blank sheet of paper resemble those that started with the evolutionary approach? As can be seen from reading the two sets of requirements, there were many areas of fundamental agreement but some areas of disagreement.
当这些小组单独工作时出现的一个问题是，他们的需求集之间是否有许多相似之处。也就是说，从一张白纸上产生的需求是否与从进化方法开始的需求相似？从阅读这两组需求可以看出，有许多方面基本一致，但也有一些方面存在分歧。
There were suggestions within the RRG that the two teams should work together to create a single set of requirements. Since these requirements are only guidelines to future work, however, some felt that doing so would risk losing content without gaining any particular advantage. It is not as if any group, for example, the IRTF RRG or the IETF Routing Area, was expected to use these requirements as written and to create an architecture that met these requirements. Rather, the requirements were in practice strong
RRG内部建议两个团队合作创建一套单一的需求。然而，由于这些要求只是未来工作的指导方针，一些人认为这样做可能会导致内容丢失，而不会获得任何特殊优势。这并不是说任何组织，例如IRTF RRG或IETF路由区域，都会按照书面要求使用这些需求，并创建满足这些需求的体系结构。相反，这些要求在实践中非常严格
recommendations for a way to proceed in creating a new routing architecture. In the end, the decision was made to include the results of both efforts, side by side, in one document.
关于创建新路由体系结构的方法的建议。最后，决定将这两项努力的结果并排列入一份文件。
This document contains the two requirement sets produced by the teams. The text has received only editorial modifications; the requirements themselves have been left unaltered. Whenever the editors felt that conditions had changed in the few years since the text was written, an editors' note has been added to the text.
本文档包含两个团队生成的需求集。文本仅接受编辑修改；需求本身没有改变。每当编辑们觉得文本编写后的几年里情况发生了变化时，就会在文本中添加一条编辑注释。
In reading this document, it is important to keep in mind that all of these requirements are suggestions, which are laid out to assist those interested in developing new routing architectures. It is also important to remember that, while the people working on these suggestions have done their best to make intelligent suggestions, there are no guarantees. So a reader of this document should not treat what it says as absolute, nor treat every suggestion as necessary. No architecture is expected to fulfill every "requirement". Hopefully, though, future architectures will consider what is offered in this document.
在阅读本文档时，请务必记住，所有这些需求都是建议，旨在帮助那些对开发新路由体系结构感兴趣的人。同样重要的是要记住，尽管研究这些建议的人已经尽了最大努力提出了明智的建议，但没有任何保证。因此，本文件的读者不应将其内容视为绝对的，也不应将所有建议视为必要的。没有任何体系结构能够满足所有“需求”。然而，希望未来的架构将考虑本文档中提供的内容。
The IRTF RRG supported publication of this document as a historical record of the work completed on the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the time of publication. The document has had substantial review by members of the two teams, other members of the IRTF RRG, and additional experts over the years.
IRTF RRG支持将本文件作为已完成工作的历史记录出版，但前提是，本文件不一定代表出版时研究小组的最新技术理解或技术共识。多年来，两个小组的成员、IRTF RRG的其他成员和其他专家对该文件进行了实质性审查。
Finally, this document does not make any claims that it is possible to have a practical solution that meets all the listed requirements.
最后，本文件并未声称有可能获得满足所有列出要求的实用解决方案。
This section presents the results of the work done by Sub-Group A of the IRTF RRG during 2001-2002. The work originally appeared under the title: "Requirements For a Next Generation Routing and Addressing Architecture" and was edited by Frank Kastenholz.
本节介绍了IRTF RRG A小组在2001-2002年期间所做工作的结果。这部作品最初的标题是：“下一代路由和寻址体系结构的需求”，由Frank Kastenholz编辑。
2.1. Group A - Requirements for a Next Generation Routing and Addressing Architecture
2.1. A组-下一代路由和寻址体系结构的要求
The requirements presented in this section are not presented in any particular order.
本节中提出的要求未按任何特定顺序提出。
The new routing and addressing protocols, data structures, and algorithms need to be developed from a clear, well thought-out, and documented architecture.
新的路由和寻址协议、数据结构和算法需要从一个清晰、经过深思熟虑且有文档记录的体系结构中开发。
The new routing and addressing system must have an architectural specification that describes all of the routing and addressing elements, their interactions, what functions the system performs, and how it goes about performing them. The architectural specification does not go into issues such as protocol and data structure design.
新的路由和寻址系统必须有一个体系结构规范，描述所有路由和寻址元素、它们的交互、系统执行的功能以及如何执行它们。体系结构规范不涉及协议和数据结构设计等问题。
The architecture should be agnostic with regard to specific algorithms and protocols.
对于特定的算法和协议，架构应该是不可知的。
Doing architecture before doing detailed protocol design is good engineering practice. This allows the architecture to be reviewed and commented upon, with changes made as necessary, when it is still easy to do so. Also, by producing an architecture, the eventual users of the protocols (the operations community) will have a better understanding of how the designers of the protocols meant them to be used.
在进行详细的协议设计之前先进行架构设计是良好的工程实践。这允许对架构进行审查和评论，并在仍然容易进行更改时根据需要进行更改。此外，通过生成一个体系结构，协议的最终用户（操作社区）将更好地理解协议的设计者打算如何使用它们。
The architecture must place different functions into separate components.
体系结构必须将不同的功能放在不同的组件中。
Separating functions, capabilities, and so forth into individual components and making each component "stand alone" is generally considered by system architects to be "A Good Thing". It allows individual elements of the system to be designed and tuned to do their jobs "very well". It also allows for piecemeal replacement and upgrading of elements as new technologies and algorithms become available.
系统架构师通常认为，将功能、能力等分离为单个组件并使每个组件“独立”是“一件好事”。它允许对系统的各个元素进行设计和调整，以“非常好地”完成它们的工作。随着新技术和算法的出现，它还允许零碎地更换和升级元件。
The architecture must have the ability to replace or upgrade existing components and to add new ones, without disrupting the remaining parts of the system. Operators must be able to roll out these changes and additions incrementally (i.e., no "flag days"). These abilities are needed to allow the architecture to evolve as the Internet changes.
体系结构必须能够更换或升级现有组件并添加新组件，而不会中断系统的其余部分。运营商必须能够以增量方式推出这些更改和添加（即，无“卖旗日”）。这些能力是允许体系结构随着互联网的变化而发展所必需的。
The architecture specification shall define each of these components, their jobs, and their interactions.
架构（architecture）规范应定义这些组件中的每一个、它们的工作以及它们之间的相互作用。
Some thoughts to consider along these lines are:
沿着这些线考虑的一些想法是：
o Making topology and addressing separate subsystems. This may allow highly optimized topology management and discovery without constraining the addressing structure or physical topology in unacceptable ways.
o 创建拓扑结构并寻址独立的子系统。这可能允许高度优化的拓扑管理和发现，而不会以不可接受的方式限制寻址结构或物理拓扑。
o Separate "fault detection and healing" from basic topology. From Mike O'Dell:
o 将“故障检测和修复”与基本拓扑分离。迈克·奥戴尔：
Historically the same machinery is used for both. While attractive for many reasons, the availability of exogenous topology information (i.e., the intended topology) should, it seems, make some tasks easier than the general case of starting with zero knowledge. It certainly helps with recovery in the case of constraint satisfaction. In fact, the intended topology is a powerful way to state certain kinds of policy. [ODell01]
历史上，两者都使用相同的机械。尽管出于许多原因具有吸引力，但外部拓扑信息（即预期拓扑）的可用性似乎会使某些任务比从零知识开始的一般情况更容易。在满足约束的情况下，它当然有助于恢复。事实上，预期的拓扑结构是说明某些类型策略的一种强大方式。[ODell01]
o Making policy definition and application a separate subsystem, layered over the others.
o 使策略定义和应用程序成为一个独立的子系统，分层于其他子系统之上。
The architecture should also separate topology, routing, and addressing from the application that uses those components. This implies that applications such as policy definition, forwarding, and circuit and tunnel management are separate subsystems layered on top of the basic topology, routing, and addressing systems.
该体系结构还应该将拓扑、路由和寻址与使用这些组件的应用程序分开。这意味着策略定义、转发、电路和隧道管理等应用程序是在基本拓扑、路由和寻址系统之上分层的独立子系统。
Scaling is the primary problem facing the routing and addressing architecture today. This problem must be solved and it must be solved for the long term.
可伸缩性是当今路由和寻址体系结构面临的主要问题。这个问题必须解决，而且必须长期解决。
The architecture must support a large and complex network. Ideally, it will serve our needs for the next 20 years. Unfortunately:
该体系结构必须支持大型复杂网络。理想情况下，它将满足我们未来20年的需求。不幸的是：
1. we do not know how big the Internet will grow over that time, and
1. 我们不知道互联网将在这段时间内增长到多大，以及
2. the architecture developed from these requirements may change the fundamental structure of the Internet and therefore its growth patterns. This change makes it difficult to predict future growth patterns of the Internet.
2. 根据这些需求开发的体系结构可能会改变互联网的基本结构，从而改变其增长模式。这种变化使得人们很难预测互联网未来的增长模式。
As a result, we can't quantify the requirement in any meaningful way. Using today's architectural elements as a mechanism for describing things, we believe that the network could grow to:
因此，我们无法以任何有意义的方式量化需求。使用当今的架构元素作为描述事物的机制，我们相信网络可以发展到：
1. tens of thousands of ASs
1. 数万头驴
Editors' Note: As of 2005, this level had already been reached.
编者按：截至2005年，这一水平已经达到。
2. tens to hundreds of millions of prefixes, during the lifetime of this architecture.
2. 在这个体系结构的生命周期中，有数千万到数亿个前缀。
These sizes are given as a "flavor" for how we expect the Internet to grow. We fully believe that any new architecture may eliminate some current architectural elements and introduce new ones.
这些尺寸是作为我们期望互联网如何发展的“味道”给出的。我们完全相信，任何新的架构都可能会消除一些现有的架构元素，并引入新的架构元素。
A new routing and addressing architecture designed for a specific network size would be inappropriate. First, the cost of routing calculations is based only in part on the number of ASs or prefixes in the network. The number and locations of the links in the network are also significant factors. Second, past predictions of Internet growth and topology patterns have proven to be wildly inaccurate, so developing an architecture to a specific size goal would at best be shortsighted.
为特定网络规模设计的新路由和寻址体系结构是不合适的。首先，路由计算的成本仅部分基于网络中ASs或前缀的数量。网络中链路的数量和位置也是重要因素。第二，过去对互联网增长和拓扑模式的预测被证明是极不准确的，因此开发一个特定规模目标的架构充其量只是短视。
Editors' Note: At the time of these meetings, the BGP statistics kept at sites such as www.routeviews.org either did not exist or had been running for only a few months. After 5 years of recording public Internet data trends in AS growth, routing table growth can be observed (past) with some short-term prediction. As each year of data collection continues, the ability to observe and predict trends improves. This architecture work pointed out the need for such statistics to improve future routing designs.
编者按：在这些会议召开时，BGP在www.routeviews.org等网站上保存的统计数据要么不存在，要么仅仅运行了几个月。在记录了5年的AS增长的公共互联网数据趋势后，可以通过一些短期预测来观察（过去）路由表的增长。随着每年数据收集的继续，观察和预测趋势的能力有所提高。该体系结构工作指出需要此类统计数据来改进未来的路由设计。
Therefore, we will not make the scaling requirement based on a specific network size. Instead, the new routing and addressing architecture should have the ability to constrain the increase in load (CPU, memory space and bandwidth, and network bandwidth) on ANY SINGLE ROUTER to be less than these specific functions:
因此，我们不会根据特定的网络规模提出扩展要求。相反，新的路由和寻址体系结构应该能够限制任何单个路由器上负载（CPU、内存空间和带宽以及网络带宽）的增加，使其小于以下特定功能：
1. The computational power and memory sizes required to execute the routing protocol software and to contain the tables must grow more slowly than hardware capabilities described by Moore's Law, doubling every 18 months. Other observations indicate that memory sizes double every 2 years or so.
1. 执行路由协议软件和包含表所需的计算能力和内存大小必须比摩尔定律描述的硬件能力增长得慢，每18个月翻一番。其他观察表明，大约每两年内存大小就会翻一番。
2. Network bandwidth and latency are some key constraints on how fast routing protocol updates can be disseminated (and therefore how fast the routing system can adapt to changes). Raw network bandwidth seems to quadruple every 3 years or so. However, it seems that there are some serious physics problems in going faster than 40 Gbit/s (OC768); we should not expect raw network
2. 网络带宽和延迟是影响路由协议更新传播速度（以及路由系统适应变化的速度）的一些关键约束。原始网络带宽似乎每3年左右就会翻两番。然而，当速度超过40gbit/s（OC768）时，似乎存在一些严重的物理问题；我们不应该期望原始网络
link speed to grow much beyond OC768. On the other hand, for economic reasons, large swathes of the core of the Internet will still operate at lower speeds, possibly as slow as DS3.
链接速度将大大超过OC768。另一方面，出于经济原因，大部分互联网核心仍将以较低的速度运行，速度可能与DS3一样慢。
Editors' Note: Technology is running ahead of imagination and higher speeds are already common.
编者按：科技已经超越想象，更高的速度已经司空见惯。
Furthermore, in some sections of the Internet, even lower speed links are found. Corporate access links are often T1, or slower. Low-speed radio links exist. Intra-domain links may be T1 or fractional-T1 (or slower).
此外，在互联网的某些部分，甚至可以找到速度更低的链接。公司访问链接通常为T1或更慢。存在低速无线电链路。域内链路可以是T1或分数T1（或更慢）。
Therefore, the architecture must not make assumptions about the bandwidth available.
因此，体系结构不能对可用带宽进行假设。
3. The speeds of high-speed RAMs (Static RAMs (SRAMs), used for caches and the like) are growing, though slowly. Because of their use in caches and other very specific applications, these RAMs tend to be small, a few megabits, and the size of these RAMs is not increasing very rapidly.
3. 高速ram（用于缓存等的静态ram）的速度正在增长，尽管速度很慢。由于它们在缓存和其他非常特殊的应用中的使用，这些ram往往很小，只有几兆比特，而且这些ram的大小没有快速增长。
On the other hand, the speed of "large" memories (Dynamic RAMs (DRAMs)) is increasing even slower than that for the high-speed RAMs. This is because the development of these RAMs is driven by the PC market, where size is very important, and low speed can be made up for by better caches.
另一方面，“大”存储器（动态RAM（DRAM））的速度增长甚至比高速RAM的速度还要慢。这是因为这些RAM的发展是由PC市场推动的，在PC市场上，大小非常重要，低速可以通过更好的缓存来弥补。
Memory access rates should not be expected to increase significantly.
内存访问率预计不会显著增加。
Editors' Note: Various techniques have significantly increased memory bandwidth. 800 MHz is now possible, compared with less than 100 MHz in the year 2000. This does not, however, contradict the next paragraph, but rather just extends the timescales somewhat.
编者按：各种技术显著增加了内存带宽。800兆赫现在是可能的，而2000年不到100兆赫。然而，这并不与下一段相矛盾，只是在一定程度上延长了时间尺度。
The growth in resources available to any one router will eventually slow down. It may even stop. Even so, the network will continue to grow. The routing and addressing architecture must continue to scale in even this extreme condition. We cannot continue to add more computing power to routers forever. Other strategies must be available. Some possible strategies are hierarchy, abstraction, and aggregation of topology information.
任何一台路由器可用资源的增长最终都会放缓。它甚至可能停止。即便如此，网络仍将继续增长。即使在这种极端情况下，路由和寻址体系结构也必须继续扩展。我们不能永远继续给路由器增加更多的计算能力。必须有其他战略。一些可能的策略是拓扑信息的层次、抽象和聚合。
The new routing and addressing architecture must be able to cope with a high degree of interconnectivity in the Internet. That is, there are large numbers of alternate paths and routes among the various elements. Mechanisms are required to prevent this interconnectivity (and continued growth in interconnectivity) from causing tables, compute time, and routing protocol traffic to grow without bound. The "cost" to the routing system of an increase in complexity must be limited in scope; sections of the network that do not see, or do not care about, the complexity ought not pay the cost of that complexity.
新的路由和寻址体系结构必须能够处理Internet中的高度互连。也就是说，在各种元素之间存在大量备用路径和路由。需要一些机制来防止这种互连（以及互连的持续增长）导致表、计算时间和路由协议流量无限制地增长。路由系统复杂性增加的“成本”必须限制在范围内；网络中看不到或不关心复杂性的部分不应支付复杂性的成本。
Over the past several years, the Internet has seen an increase in interconnectivity. Individual end sites (companies, customers, etc.), ISPs, exchange points, and so on, all are connecting to more "other things". Companies multi-home to multiple ISPs, ISPs peer with more ISPs, and so on. These connections are made for many reasons, such as getting more bandwidth, increased reliability and availability, policy, and so on. However, this increased interconnectivity has a price. It leads to more scaling problems as it increases the number of AS paths in the networks.
在过去几年中，互联网的互联性有所增加。各个终端站点（公司、客户等）、ISP、交换点等等，都在连接到更多的“其他东西”。公司多家多个ISP，ISP与更多ISP对等，等等。建立这些连接有很多原因，例如获得更多带宽、提高可靠性和可用性、策略等。然而，这种增加的互联性是有代价的。随着网络中as路径数量的增加，它会导致更多的缩放问题。
Any new architecture must assume that the Internet will become a denser mesh. It must not assume, nor can it dictate, certain patterns or limits on how various elements of the network interconnect.
任何新的架构都必须假设互联网将成为一个更密集的网络。它不能假设，也不能规定网络中各种元素如何互连的特定模式或限制。
Another facet of this requirement is that there may be multiple valid, loop-free paths available to a destination. See Section 2.1.7 for a further discussion.
该要求的另一个方面是，可能有多个有效的、无循环的路径可用于一个目的地。有关进一步讨论，请参见第2.1.7节。
We wryly note that one of the original design goals of IP was to support a large, heavily interconnected network, which would be highly survivable (such as in the face of a nuclear war).
我们挖苦地注意到，IP最初的设计目标之一是支持一个大型、高度互联的网络，该网络将具有很高的生存能力（例如在面对核战争时）。
The routing and addressing architecture must not place any constraints on or make assumptions about the topology or connectedness of the elements comprising the Internet. The routing and addressing architecture must not presume any particular network structure. The network does not have a "nice" structure. In the past, we used to believe that there was this nice "backbone/tier-1/ tier-2/end-site" sort of hierarchy. This is not so. Therefore, any new architecture must not presume any such structure.
路由和寻址体系结构不得对构成互联网的元素的拓扑或连接性施加任何约束或作出任何假设。路由和寻址体系结构不得假定任何特定的网络结构。网络没有“好”的结构。在过去，我们曾经相信存在这种很好的“主干/第1层/第2层/终端站点”层次结构。事实并非如此。因此，任何新的体系结构都不能假定有这样的结构。
Some have proposed that a geographic addressing scheme be used, requiring exchange points to be situated within each geographic "region". There are many reasons why we believe this to be a bad approach, but those arguments are irrelevant. The main issue is that the routing architecture should not presume a specific network structure.
一些人建议使用地理寻址方案，要求交换点位于每个地理“区域”内。我们之所以认为这是一种糟糕的方法，有很多原因，但这些论点都无关紧要。主要问题是，路由体系结构不应假定特定的网络结构。
The architecture must provide multi-homing for all elements of the Internet. That is, multi-homing of hosts, subnetworks, end-sites, "low-level" ISPs, and backbones (i.e., lots of redundant interconnections) must be supported. Among the reasons to multi-home are reliability, load sharing, and performance tuning.
该体系结构必须为互联网的所有元素提供多主服务。也就是说，必须支持主机、子网、终端站点、“低级别”ISP和主干网（即大量冗余互连）的多宿主。多家庭的原因包括可靠性、负载共享和性能调整。
The term "multi-homing" may be interpreted in its broadest sense -- one "place" has multiple connections or links to another "place".
“多归宿”一词可以从最广泛的意义上进行解释——一个“地方”与另一个“地方”有多个连接或链接。
The architecture must not limit the number of alternate paths to a multi-homed site.
体系结构不得限制多宿主站点的备用路径数量。
When multi-homing is used, it must be possible to use one, some (more than one but less than all), or all of the available paths to the multi-homed site. The multi-homed site must have the ability to declare which path(s) are used and under what conditions (for example, one path may be declared "primary" and the other "backup" and to be used only when the primary fails).
当使用多宿主时，必须能够使用一条、一些（多于一条但少于全部）或所有到多宿主站点的可用路径。多宿主站点必须能够声明使用了哪些路径以及在什么条件下使用（例如，一条路径可以声明为“主路径”，另一条路径可以声明为“备份路径”，并且仅在主路径出现故障时使用）。
A current problem in the Internet is that multi-homing leads to undue increases in the size of the BGP routing tables. The new architecture must support multi-homing without undue routing table growth.
目前互联网上的一个问题是，多归属导致BGP路由表的大小过度增加。新的体系结构必须支持多主，而不会过度增加路由表。
As a corollary to multi-homing, the architecture must allow for multiple paths from a source to a destination to be active at the same time. These paths need not have the same attributes. Policies are to be used to disseminate the attributes and to classify traffic for the different paths.
作为多归宿的必然结果，该体系结构必须允许从源到目的地的多条路径同时处于活动状态。这些路径不必具有相同的属性。策略用于传播属性，并对不同路径的流量进行分类。
There must be a rich "language" for specifying the rules for classifying the traffic and assigning classes of traffic to different paths (or prohibiting it from certain paths). The rules should allow traffic to be classified based upon, at least, the following:
必须有一种丰富的“语言”来指定对流量进行分类的规则，并将流量类别分配给不同的路径（或禁止在某些路径中使用）。规则应允许至少根据以下内容对流量进行分类：
o IPv6 FlowIDs,
o IPv6流ID，
o Diffserv Code Point (DSCP) values,
o 区分服务代码点（DSCP）值，
o source and/or destination prefixes, or
o 源和/或目标前缀，或
o random selections at some probability.
o 以某种概率随机选择。
A mechanism is needed that allows operators to plan and manage the traffic load on the various paths. To start, this mechanism can be semi-automatic or even manual. Eventually, it ought to become fully automatic.
需要一种机制，使运营商能够规划和管理各种路径上的流量负载。首先，该机构可以是半自动的，甚至是手动的。最终，它应该变成全自动的。
When multi-path forwarding is used, options must be available to preserve packet ordering where appropriate (such as for individual TCP connections).
当使用多路径转发时，必须提供选项，以便在适当的情况下保留数据包顺序（例如针对单个TCP连接）。
Please refer to Section 2.2.7 for a discussion of dynamic load-balancing and management over multiple paths.
有关多路径动态负载平衡和管理的讨论，请参阅第2.2.7节。
The speed of convergence (also called the "stabilization time") is the time it takes for a router's routing processes to reach a new, stable, "solution" (i.e., forwarding information base) after a change someplace in the network. In effect, what happens is that the output of the routing calculations stabilizes -- the Nth iteration of the software produces the same results as the N-1th iteration.
收敛速度（也称为“稳定时间”）是指在网络中某个地方发生变化后，路由器的路由过程达到新的、稳定的“解决方案”（即转发信息库）所需的时间。实际上，路由计算的输出是稳定的——软件的第N次迭代产生与第N-1次迭代相同的结果。
The speed of convergence is generally considered to be a function of the number of subnetworks in the network and the amount of connections between those networks. As either number grows, the time it takes to converge increases.
收敛速度通常被认为是网络中子网络数量和这些网络之间连接数量的函数。随着任意一个数字的增长，收敛所需的时间也会增加。
In addition, a change can "ripple" back and forth through the system. One change can go through the system, causing some other router to change its advertised connectivity, causing a new change to ripple through. These oscillations can take a while to work their way out of the network. It is also possible that these ripples never die out. In this situation, the routing and addressing system is unstable; it never converges.
此外，变更可能会在系统中来回“涟漪”。一个变化会贯穿整个系统，导致其他路由器改变其公布的连接，导致新的变化波及整个系统。这些振荡可能需要一段时间才能从网络中消失。这些涟漪也有可能永远不会消失。在这种情况下，路由和寻址系统是不稳定的；它永远不会收敛。
Finally, it is more than likely that the routers comprising the Internet never converge simply because the Internet is so large and complex. Assume it takes S seconds for the routers to stabilize on a solution for any one change to the network. Also, assume that changes occur, on average, every C seconds. Because of the size and complexity of the Internet, C is now less than S. Therefore, if a
最后，很可能组成互联网的路由器永远不会聚合，因为互联网如此庞大和复杂。假设路由器在网络发生任何一次变化的情况下稳定在一个解决方案上需要S秒。另外，假设更改平均每C秒发生一次。由于互联网的规模和复杂性，C现在比S小
change, C1, occurs at time T, the routing system would stabilize at time T+S, but a new change, C2, will occur at time T+C, which is before T+S. The system will start processing the new change before it's done with the old.
更改C1发生在时间T，路由系统将在时间T+S稳定，但新更改C2将发生在时间T+C，即T+S之前。系统将在处理旧更改之前开始处理新更改。
This is not to say that all routers are constantly processing changes. The effects of changes are like ripples in a pond. They spread outward from where they occur. Some routers will be processing just C1, others C2, others both C1 and C2, and others neither.
这并不是说所有的路由器都在不断地处理变化。变化的效果就像池塘里的涟漪。它们从它们出现的地方向外扩散。一些路由器将只处理C1，其他的是C2，其他的同时处理C1和C2，而其他的则两者都不处理。
We have two separate scopes over which we can set requirements with respect to convergence:
我们有两个单独的范围，可以在这两个范围内设置有关收敛的要求：
1. Single Change: In this requirement, a single change of any type (link addition or deletion, router failure or restart, etc.) is introduced into a stabilized system. No additional changes are introduced. The system must re-stabilize within some measure of bounded time. This requirement is a fairly abstract one as it would be impossible to test in a real network. Definition of the time constraints remains an open research issue.
1. 单一变更：在该要求中，任何类型的单一变更（链路添加或删除、路由器故障或重启等）都会引入稳定系统。没有引入其他更改。系统必须在一定的有界时间内重新稳定。这是一个相当抽象的要求，因为不可能在真实的网络中进行测试。时间限制的定义仍然是一个开放的研究问题。
2. System-Wide: Defining a single target for maximum convergence time for the real Internet is absurd. As we mentioned earlier, the Internet is large enough and diverse enough so that it is quite likely that new changes are introduced somewhere before the system fully digests old ones.
2. 全系统：为真正的互联网定义一个最大融合时间的单一目标是荒谬的。正如我们前面提到的，互联网足够大，足够多样化，因此很有可能在系统完全消化旧的变化之前，在某处引入新的变化。
So, the first requirement here is that there must be mechanisms to limit the scope of any one change's visibility and effects. The number of routers that have to perform calculations in response to a change is kept small, as is the settling time.
因此，这里的第一个要求是必须有机制来限制任何一个变化的可见性和影响的范围。为了响应变化而必须执行计算的路由器的数量保持在很小的范围内，就像稳定时间一样。
The second requirement is based on the following assumptions:
第二项要求基于以下假设：
- the scope of a change's visibility and impact can be limited. That is, routers within that scope know of the change and recalculate their tables based on the change. Routers outside of the scope don't see it at all.
- 变更的可视性和影响范围是有限的。也就是说，该范围内的路由器知道更改，并根据更改重新计算其表。范围之外的路由器根本看不到它。
- Within any scope, S, network changes are constantly occurring and the average inter-change interval is Tc seconds.
- 在任何范围内，S、网络变化不断发生，平均变化间隔为Tc秒。
- There are Rs routers within scope S.
- 在S范围内有Rs路由器。
- A subset of the destinations known to the routers in S, Ds, are impacted by a given change.
- S、Ds中路由器已知的目的地子集受到给定更改的影响。
- We can state that for Z% of the changes, within Y% of Tc seconds after a change, C, X% of the Rs routers have their routes to Ds settled to a useful answer (useful meaning that packets can get to Ds, though perhaps not by the optimal path -- this allows some "hunting" for the optimal solution).
- 我们可以说明，对于Z%的变化，在变化后的Tc秒的Y%内，C，X%的Rs路由器将其到Ds的路由确定为一个有用的答案（有用的意思是数据包可以到达Ds，尽管可能不是通过最佳路径——这允许一些“搜索”最优解决方案）。
X, Y, and Z are yet to be defined. Their definition remains a research issue.
十、 Y和Z尚未定义。它们的定义仍然是一个研究问题。
This requirement implies that the scopes can be kept relatively small in order to minimize Rs and maximize Tc.
这一要求意味着范围可以保持相对较小，以最小化Rs和最大化Tc。
The growth rate of the convergence time must not be related to the growth rate of the Internet as a whole. This implies that the convergence time either:
融合时间的增长速度不得与整个互联网的增长速度相关。这意味着收敛时间：
1. not be a function of basic network elements (such as prefixes and links/paths), and/or
1. 不是基本网络元素（例如前缀和链接/路径）的函数，和/或
2. that the Internet be continuously divisible into chunks that limit the scope and effect of a change, thereby limiting the number of routers, prefixes, links, and so on, involved in the new calculations.
2. 互联网可以不断地被划分成若干块，这些块限制了变化的范围和影响，从而限制了新计算中涉及的路由器、前缀、链接等的数量。
The security of the Internet's routing system is paramount. If the routing system is compromised or attacked, the entire Internet can fail. This is unacceptable. Any new architecture must be secure.
互联网路由系统的安全性至关重要。如果路由系统遭到破坏或攻击，整个互联网可能会失败。这是不能接受的。任何新的架构都必须是安全的。
Architectures by themselves are not secure. It is the implementation of an architecture, its protocols, algorithms, and data structures that are secure. These requirements apply primarily to the implementation. The architecture must provide the elements that the implementation needs to meet these security requirements. Also, the architecture must not prevent these security requirements from being met.
体系结构本身并不安全。它是架构、协议、算法和数据结构的安全实现。这些要求主要适用于实施。体系结构必须提供实现满足这些安全需求所需的元素。此外，体系结构不能阻止满足这些安全需求。
Security means different things to different people. In order for this requirement to be useful, we must define what we mean by security. We do this by identifying the attackers and threats we wish to protect against. They are:
安全对不同的人意味着不同的东西。为了使这个需求有用，我们必须定义安全性的含义。我们通过识别我们希望防范的攻击者和威胁来做到这一点。他们是：
Masquerading The system, including its protocols, must be secure against intruders adopting the identity of other known, trusted elements of the routing system and then using that position of trust for carrying out other attacks. Protocols must use cryptographically strong authentication.
伪装系统（包括其协议）必须能够防止入侵者采用路由系统中其他已知、受信任元素的身份，然后使用该信任位置进行其他攻击。协议必须使用加密强身份验证。
Denial-of-Service (DoS) Attacks The architecture and protocols should be secure against DoS attacks directed at the routers.
拒绝服务（DoS）攻击该体系结构和协议应能防止针对路由器的DoS攻击。
The new architecture and protocols should provide as much information as it can to allow administrators to track down sources of DoS and Distributed DOS (DDoS) attacks.
新的体系结构和协议应提供尽可能多的信息，使管理员能够追踪DoS和分布式DoS（DDoS）攻击的来源。
No Bad Data Any new architecture and protocols must provide protection against the introduction of bad, erroneous, or misleading data by attackers. Of particular importance, an attacker must not be able to redirect traffic flows, with the intent of:
无不良数据任何新的体系结构和协议都必须提供保护，防止攻击者引入不良、错误或误导性数据。特别重要的是，攻击者不得出于以下目的重定向流量：
o directing legitimate traffic away from a target, causing a denial-of-service attack by preventing legitimate data from reaching its destination,
o 引导合法流量远离目标，通过阻止合法数据到达其目的地而导致拒绝服务攻击，
o directing additional traffic (going to other destinations that are "innocent bystanders") to a target, causing the target to be overloaded, or
o 将额外流量（前往“无辜旁观者”的其他目的地）导向目标，导致目标超载，或
o directing traffic addressed to the target to a place where the attacker can copy, snoop, alter, or otherwise affect the traffic.
o 将指向目标的流量定向到攻击者可以复制、窥探、更改或以其他方式影响流量的位置。
Topology Hiding Any new architecture and protocols must provide mechanisms to allow network owners to hide the details of their internal topologies, while maintaining the desired levels of service connectivity and reachability.
拓扑隐藏任何新的体系结构和协议都必须提供允许网络所有者隐藏其内部拓扑细节的机制，同时保持所需的服务连接性和可达性级别。
Privacy By "privacy" we mean privacy of the routing protocol exchanges between routers.
“隐私”是指路由器之间路由协议交换的隐私。
When the routers are on point-to-point links, with routers at each end, there may not be any need to encrypt the routing protocol traffic as the possibility of a third party
当路由器位于点对点链路上，且路由器位于每一端时，可能不需要加密路由协议流量，因为可能存在第三方
intercepting the traffic is limited, though not impossible. We do believe, however, that it is important to have the ability to protect routing protocol traffic in two cases:
拦截流量是有限的，但并非不可能。但是，我们确实认为，在两种情况下，具有保护路由协议流量的能力非常重要：
1. When the routers are on a shared network, it is possible that there are hosts on the network that have been compromised. These hosts could surreptitiously monitor the protocol traffic.
1. 当路由器位于共享网络上时，网络上可能存在已被破坏的主机。这些主机可以秘密监视协议流量。
2. When two routers are exchanging information "at a distance" (over intervening routers and, possibly, across administrative domain boundaries). In this case, the security of the intervening routers, links, and so on, cannot be assured. Thus, the ability to encrypt this traffic is important.
2. 当两个路由器“远距离”交换信息时（通过中间路由器，可能跨越管理域边界）。在这种情况下，无法保证介入路由器、链路等的安全性。因此，加密此流量的能力非常重要。
Therefore, we believe that the option to encrypt routing protocol traffic is required.
因此，我们认为需要加密路由协议流量的选项。
Data Consistency A router should be able to detect and recover from any data that is received from other routers that is inconsistent. That is, it must not be possible for data from multiple routers, none of which is malicious, to "break" another router.
数据一致性路由器应该能够检测并恢复从其他路由器接收到的任何不一致数据。也就是说，来自多个路由器（没有恶意路由器）的数据不可能“破坏”另一个路由器。
Where security mechanisms are provided, they must use methods that are considered to be cryptographically secure (e.g., using cryptographically strong encryption and signatures -- no cleartext passwords!).
在提供安全机制的地方，它们必须使用被认为是加密安全的方法（例如，使用加密强加密和签名——没有明文密码！）。
Use of security features should not be optional (except as required above). This may be "social engineering" on our part, but we believe it to be necessary. If a security feature is optional, the implementation of the feature must default to the "secure" setting.
安全功能的使用不应是可选的（上述要求除外）。这可能是我们的“社会工程”，但我们认为这是必要的。如果安全功能是可选的，则该功能的实现必须默认为“安全”设置。
The architecture must not prevent individual host-to-host communications sessions from being secured (i.e., it cannot interfere with things like IPsec).
该体系结构不得阻止单个主机对主机通信会话的安全性（即，它不能干扰IPsec之类的事情）。
Before setting out policy requirements, we need to define the term. Like "security", "policy" means different things to different people. For our purposes, "policy" is the set of administrative influences that alter the path determination and next-hop selection procedures of the routing software.
在制定政策要求之前，我们需要定义术语。就像“安全”一样，“政策”对不同的人意味着不同的东西。出于我们的目的，“策略”是改变路由软件的路径确定和下一跳选择过程的一组管理影响。
The main motivators for influencing path and next-hop selection seem to be transit rules, business decisions, and load management.
影响路径和下一跳选择的主要动机似乎是运输规则、业务决策和负载管理。
The new architecture must support rich policy mechanisms. Furthermore, the policy definition and dissemination mechanisms should be separated from the network topology and connectivity dissemination mechanisms. Policy provides input to and controls the generation of the forwarding table and the abstraction, filtering, aggregation, and dissemination of topology information.
新架构必须支持丰富的政策机制。此外，策略定义和传播机制应与网络拓扑和连通性传播机制分离。策略为转发表的生成以及拓扑信息的抽象、过滤、聚合和传播提供输入并进行控制。
Note that if the architecture is properly divided into subsystems, then at a later time, new policy subsystems that include new features and capabilities could be developed and installed as needed.
请注意，如果将体系结构正确地划分为子系统，那么以后可以根据需要开发和安装包含新特性和功能的新策略子系统。
We divide the general area of policy into two sub-categories: routing information and traffic control. Routing Information Policies control what routing information is disseminated or accepted, how it is disseminated, and how routers determine paths and next-hops from the received information. Traffic Control Policies determine how traffic is classified and assigned to routes.
我们将政策的一般领域分为两个子类：路由信息和流量控制。路由信息策略控制哪些路由信息被传播或接受，如何传播，以及路由器如何根据接收到的信息确定路径和下一跳。交通控制策略确定如何对交通进行分类并将其分配给路线。
There must be mechanisms to allow network administrators, operators, and designers to control receipt and dissemination of routing information. These controls include, but are not limited to:
必须有机制允许网络管理员、操作员和设计者控制路由信息的接收和传播。这些控制措施包括但不限于：
- Selecting to which other routers routing information will be transmitted.
- 选择将向哪些其他路由器发送路由信息。
- Specifying the "granularity" and type of transmitted information. The length of IPv4 prefixes is an example of granularity.
- 指定传输信息的“粒度”和类型。IPv4前缀的长度是粒度的一个示例。
- Selection and filtering of topology and service information that is transmitted. This gives different "views" of internal structure and topology to different peers.
- 选择和过滤传输的拓扑和服务信息。这为不同的对等方提供了不同的内部结构和拓扑“视图”。
- Selecting the level of security and authenticity for transmitted information.
- 选择传输信息的安全性和真实性级别。
- Being able to cause the level of detail that is visible for some portion of the network to reduce the farther you get from that part of the network.
- 能够使网络某个部分可见的详细程度降低，从而使您离该部分网络越远。
- Selecting from whom routing information will be accepted. This control should be "provisional" in the sense of "accept routes from "foo" only if there are no others available".
- 选择将从谁处接受路由信息。这种控制应该是“临时的”，即“只有在没有其他可用的情况下才接受来自“foo”的路由”。
- Accepting or rejecting routing information based on the path the information traveled (using the current system as an example, this would be filtering routes based on an AS appearing anywhere in the AS path). This control should be "use only if there are no other paths available".
- 根据信息所经过的路径接受或拒绝路由信息（以当前系统为例，这将基于as路径中任何位置出现的as来过滤路由）。此控件应为“仅在没有其他可用路径时使用”。
- Selecting the desired level of granularity for received routing information (this would include, but is not limited to, things similar in nature to the prefix-length filters widely used in the current routing and addressing system).
- 为接收到的路由信息选择所需的粒度级别（这将包括但不限于与当前路由和寻址系统中广泛使用的前缀长度过滤器性质相似的内容）。
- Selecting the level of security and authenticity of received information in order for that information to be accepted.
- 选择接收信息的安全性和真实性级别，以便接受该信息。
- Determining the treatment of received routing information based on attributes supplied with the information.
- 根据随信息一起提供的属性确定对接收到的路由信息的处理。
- Applying attributes to routing information that is to be transmitted and then determining treatment of information (e.g., sending it "here" but not "there") based on those tags.
- 将属性应用于要传输的路由信息，然后根据这些标记确定信息的处理方式（例如，将其发送到“此处”，而不是“那里”）。
- Selection and filtering of topology and service information that is received.
- 选择和筛选接收到的拓扑和服务信息。
The architecture should provide mechanisms that allow network operators to manage and control the flow of traffic. The traffic controls should include, but are not limited to:
该体系结构应提供允许网络运营商管理和控制流量的机制。交通管制应包括但不限于：
- The ability to detect and eliminate congestion points in the network (by redirecting traffic around those points).
- 能够检测并消除网络中的拥塞点（通过重定向这些点周围的流量）。
- The ability to develop multiple paths through the network with different attributes and then assign traffic to those paths based on some discriminators within the packets (discriminators include, but are not limited to, IP addresses or prefixes, IPv6 flow ID, DSCP values, and MPLS labels).
- 通过网络开发具有不同属性的多条路径，然后根据数据包中的一些鉴别器（鉴别器包括但不限于IP地址或前缀、IPv6流ID、DSCP值和MPLS标签）将流量分配给这些路径的能力。
- The ability to find and use multiple, equivalent paths through the network (i.e., they would have the "same" attributes) and allocate traffic across the paths.
- 通过网络查找和使用多条等效路径（即，它们具有“相同”属性）并跨路径分配流量的能力。
- The ability to accept or refuse traffic based on some traffic classification (providing, in effect, transit policies).
- 基于某些交通分类（提供有效的交通政策）接受或拒绝交通的能力。
Traffic classification must at least include the source and destination IP addresses (prefixes) and the DSCP value. Other fields may be supported, such as:
流量分类必须至少包括源和目标IP地址（前缀）以及DSCP值。可能支持其他字段，例如：
* Protocol and port-based functions,
* 基于协议和端口的功能，
* DSCP/QoS (Quality of Service) tuple (such as ports),
* DSCP/QoS（服务质量）元组（如端口），
* Per-host operations (i.e., /32 s for IPv4 and /128 s for IPv6), and
* 每主机操作（即IPv4为/32秒，IPv6为/128秒），以及
* Traffic matrices (e.g., traffic from prefix X and to prefix Y).
* 流量矩阵（例如，从前缀X到前缀Y的流量）。
The reality of the Internet is that there can be no Internet-wide cutover from one architecture and protocol to another. This means that any new architecture and protocol must be incrementally deployable; ISPs must be able to set up small sections of the new architecture, check it out, and then slowly grow the sections. Eventually, these sections will "touch" and "squeeze out" the old architecture.
互联网的现实是，从一个架构和协议到另一个架构和协议之间不可能有互联网范围的转换。这意味着任何新的架构和协议都必须是可增量部署的；ISP必须能够设置新体系结构的小部分，检查它，然后慢慢扩展这些部分。最终，这些部分将“接触”和“挤出”旧建筑。
The protocols that implement the architecture must be able to interoperate at "production levels" with currently existing routing protocols. Furthermore, the protocol specifications must define how the interoperability is done.
实现该体系结构的协议必须能够在“生产级别”与当前现有的路由协议进行互操作。此外，协议规范必须定义如何实现互操作性。
We also believe that sections of the Internet will never convert over to the new architecture. Thus, it is important that the new architecture and its protocols be able to interoperate with "old architecture" regions of the network indefinitely.
我们还相信，互联网的各个部分永远不会转换为新的架构。因此，新体系结构及其协议必须能够无限期地与网络的“旧体系结构”区域进行互操作。
The architecture's addressing system must not force existing address allocations to be redone: no renumbering!
体系结构的寻址系统不得强制重做现有的地址分配：不得重新编号！
There are two kinds of mobility: host mobility and network mobility. Host mobility is when an individual host moves from where it was to where it is. Network mobility is when an entire network (or subnetwork) moves.
移动性有两种：主机移动性和网络移动性。主机移动性是指单个主机从原来的位置移动到现在的位置。网络移动性是指整个网络（或子网络）移动。
The architecture must support network-level mobility. Please refer to Section 2.2.9 for a discussion of host mobility.
该体系结构必须支持网络级移动性。有关主机移动性的讨论，请参阅第2.2.9节。
Editors' Note: Since the time of this work, the Network Mobility (NEMO) extensions to Mobile-IP [RFC3963] to accommodate mobile networks have been developed.
编者按：自这项工作开始以来，已经开发了移动IP[RFC3963]的网络移动性（NEMO）扩展，以适应移动网络。
One of the big "hot items" in the current Internet political climate is portability of IP addresses (both v4 and v6). The short explanation is that people do not like to renumber when changing connection point or provider and do not trust automated renumbering tools.
当前互联网政治气候中的一大“热点”是IP地址的可移植性（v4和v6）。简单的解释是，人们不喜欢在更改连接点或提供程序时重新编号，也不信任自动重新编号工具。
The architecture must provide complete address portability.
该体系结构必须提供完整的地址可移植性。
The Internet is expected to be "multi-protocol" for at least the next several years. IPv4 and IPv6 will co-exist in many different ways during a transition period. The architecture must be able to handle both IPv4 and IPv6 addresses. Furthermore, protocols that supplant IPv4 and IPv6 may be developed and deployed during the lifetime of the architecture. The architecture must be flexible and extensible enough to handle new protocols as they arise.
预计互联网至少在未来几年内将是“多协议”的。在过渡期内，IPv4和IPv6将以多种不同的方式共存。该体系结构必须能够处理IPv4和IPv6地址。此外，可以在体系结构的生命周期内开发和部署替代IPv4和IPv6的协议。该体系结构必须具有足够的灵活性和可扩展性，以便在出现新协议时处理它们。
Furthermore, the architecture must not assume any given relationships between a topological element's IPv4 address and its IPv6 address. The architecture must not assume that all topological elements have IPv4 addresses/prefixes, nor can it assume that they have IPv6 addresses/prefixes.
此外，体系结构不得假定拓扑元素的IPv4地址与其IPv6地址之间存在任何给定关系。体系结构不能假设所有拓扑元素都具有IPv4地址/前缀，也不能假设它们具有IPv6地址/前缀。
The architecture should allow different paths to the same destination to be used for different protocols, even if all paths can carry all protocols.
该体系结构应允许同一目的地的不同路径用于不同的协议，即使所有路径都可以承载所有协议。
In addition to the addressing technology, the architecture need not be restricted to only packet-based multiplexing/demultiplexing technology (such as IP); support for other multiplexing/ demultiplexing technologies may be added.
除了寻址技术之外，架构不需要仅限于基于分组的复用/解复用技术（例如IP）；可以添加对其他复用/解复用技术的支持。
The architecture must provide mechanisms for network designers and operators to:
该体系结构必须为网络设计师和运营商提供以下机制：
o Group elements together for administrative control purposes,
o 出于管理控制目的，将元素组合在一起，
o Hide the internal structure and topology of those groupings for administrative and security reasons,
o 出于管理和安全原因，隐藏这些分组的内部结构和拓扑结构，
o Limit the amount of topology information that is exported from the groupings in order to control the load placed on external routers,
o 限制从分组导出的拓扑信息量，以控制外部路由器上的负载，
o Define rules for traffic transiting or terminating in the grouping.
o 定义分组中传输或终止流量的规则。
The architecture must allow the current Autonomous System structure to be mapped into any new abstraction schemes.
该体系结构必须允许将当前的自治系统结构映射到任何新的抽象方案中。
Mapping mechanisms, algorithms, and techniques must be specified.
必须指定映射机制、算法和技术。
The architecture must be simple enough so that someone who is extremely knowledgeable in routing and who is skilled at creating straightforward and simple explanations can explain all the important concepts in less than an hour.
该体系结构必须足够简单，以便在布线方面非常有知识的人以及善于创建简单明了的解释的人能够在不到一小时的时间内解释所有重要概念。
This criterion has been chosen since developing an objective measure of complexity for an architecture can be very difficult and is out of scope for this document.
之所以选择此标准，是因为为体系结构开发客观的复杂性度量可能非常困难，并且超出了本文档的范围。
The requirement is that the routing architecture be kept as simple as possible. This requires careful evaluation of possible features and functions with a merciless weeding out of those that "might be nice" but are not necessary.
要求路由体系结构尽可能简单。这需要仔细评估可能的特性和功能，无情地剔除那些“可能很好”但不必要的特性和功能。
By keeping the architecture simple, the protocols and software used to implement the architecture are simpler. This simplicity in turn leads to:
通过保持体系结构简单，用于实现体系结构的协议和软件更简单。这种简单性反过来导致：
1. Faster implementation of the protocols. If there are fewer bells and whistles, then there are fewer things that need to be implemented.
1. 更快地实现协议。如果钟声和口哨声越来越少，那么需要实施的事情就会越来越少。
2. More reliable implementations. With fewer components, there is less code, reducing bug counts, and fewer interactions between components that could lead to unforeseen and incorrect behavior.
2. 更可靠的实现。组件越少，代码就越少，bug数量也就越少，组件之间的交互也就越少，从而导致不可预见和不正确的行为。
The architecture, and the protocols implementing it, should be robust. Robustness comes in many different flavors. Some considerations with regard to robustness include (but are not limited to):
体系结构和实现它的协议应该是健壮的。健壮性有很多不同的特点。关于稳健性的一些考虑包括（但不限于）：
o Continued correct operation in the face of:
o 在以下情况下继续正确操作：
* Defective (even malicious) trusted routers.
* 有缺陷（甚至恶意）的受信任路由器。
* Network failures. Whenever possible, valid alternate paths are to be found and used.
* 网络故障。只要可能，应找到并使用有效的备用路径。
o Failures must be localized. That is, the architecture must limit the "spread" of any adverse effects of a misconfiguration or failure. Badness must not spread.
o 故障必须本地化。也就是说，架构必须限制错误配置或故障的任何不利影响的“传播”。恶不能蔓延。
Of course, the general robustness principle of being liberal in what's accepted and conservative in what's sent must also be applied.
当然，在被接受的事物上保持自由，在被发送的事物上保持保守，这一普遍的稳健性原则也必须适用。
Original Editor's Note: Some of the contributors to this section have argued that robustness is an aspect of security. I have exercised editor's discretion by making it a separate section. The reason for this is that to too many people "security" means "protection from break-ins" and "authenticating and encrypting data". This requirement goes beyond those views.
原始编者注：本节的一些贡献者认为健壮性是安全性的一个方面。我已行使编辑的自由裁量权，将其作为一个单独的部分。原因是，对太多人来说，“安全”意味着“防止入侵”和“验证和加密数据”。这一要求超越了这些观点。
While it is an article of faith that IP operates over a wide variety of media (such as Ethernet, X.25, ATM, and so on), IP routing must take an agnostic view toward any "routing" or "topology" services that are offered by the medium over which IP is operating. That is, the new architecture must not be designed to integrate with any media-specific topology management or routing scheme.
虽然IP在多种介质（如以太网、X.25、ATM等）上运行是一个信条，但IP路由必须以不可知的眼光看待IP运行介质提供的任何“路由”或“拓扑”服务。也就是说，新体系结构的设计不得与任何特定于介质的拓扑管理或路由方案集成。
The routing architecture must assume, and must work over, the simplest possible media.
路由体系结构必须采用最简单的介质，并且必须采用最简单的介质。
The routing and addressing architecture can certainly make use of lower-layer information and services, when and where available, and to the extent that IP routing wishes.
路由和寻址体系结构当然可以利用较低层的信息和服务，无论何时何地，只要IP路由愿意。
The routing architecture and protocols must not rely on other components of the Internet (such as DNS) for their correct operation. Routing is the fundamental process by which data "finds its way around the Internet" and most, if not all, of those other components rely on routing to properly forward their data. Thus, routing cannot rely on any Internet systems, services, or capabilities that in turn rely on routing. If it did, a dependency loop would result.
路由体系结构和协议不得依赖于Internet的其他组件（如DNS）进行正确操作。路由是数据“在互联网上找到自己的路径”的基本过程，而大多数（如果不是全部的话）其他组件都依赖路由来正确转发数据。因此，路由不能依赖于任何反过来依赖于路由的互联网系统、服务或功能。如果它这样做了，就会产生一个依赖循环。
The architecture, protocols, and standard implementation defaults must be such that a router installed "out of the box" with no configuration, etc., by the operators will not cause "bad things" to happen to the rest of the routing system (e.g., no dial-up customers advertising routes to 18/8!).
体系结构、协议和标准实现默认值必须确保由运营商“开箱即用”安装的路由器（无配置等）不会导致路由系统的其余部分发生“坏事情”（例如，没有拨号客户宣传18/8的路由！）。
The routing system must allow topological entities to be renumbered.
布线系统必须允许对拓扑实体重新编号。
The architecture must allow topological entities to have multiple prefixes (or the equivalent under the new architecture).
体系结构必须允许拓扑实体具有多个前缀（或新体系结构下的等效前缀）。
As RFC 1726[RFC1726] states:
正如RFC 1726[RFC1726]所述：
A major contributor to the Internet's success is the fact that there is no single, centralized, point of control or promulgator of policy for the entire network. This allows individual constituents of the network to tailor their own networks, environments, and policies to suit their own needs. The individual constituents must cooperate only to the degree necessary to ensure that they interoperate.
互联网成功的一个主要因素是，整个网络没有单一的、集中的控制点或政策发布者。这使得网络的各个组成部分能够根据自己的需要定制自己的网络、环境和策略。各个组成部分必须仅在确保其互操作所必需的程度上进行合作。
This decentralization, called "cooperative anarchy", is still a key feature of the Internet today. The new routing architecture must retain this feature. There can be no centralized point of control or promulgator of policy for the entire Internet.
这种被称为“合作无政府状态”的权力下放仍然是当今互联网的一个关键特征。新的路由体系结构必须保留此功能。整个互联网不可能有集中的控制点或政策的发布者。
For the purposes of backward compatibility, any new routing and addressing architecture and protocols must work with IPv4 and IPv6 using the traditional "hop-by-hop" forwarding and packet-based multiplex/demultiplex models. However, the architecture need not be restricted to these models. Additional forwarding and multiplex/ demultiplex models may be added.
为了向后兼容，任何新的路由和寻址体系结构和协议都必须使用传统的“逐跳”转发和基于数据包的多路复用/解复用模型与IPv4和IPv6配合使用。然而，体系结构不需要局限于这些模型。可以添加额外的转发和多路复用/解复用模型。
The architecture should not require a particular routing algorithm family. That is to say, the architecture should be agnostic about link-state, distance-vector, or path-vector routing algorithms.
该体系结构不需要特定的路由算法系列。也就是说，该体系结构应该不知道链路状态、距离向量或路径向量路由算法。
Finally, the architecture must show benefits in terms of increased stability, decreased operational costs, and increased functionality and lifetime, over the current schemes. This benefit must remain even after the inevitable costs of developing and debugging the new protocols, enduring the inevitable instabilities as things get shaken out, and so on.
最后，在当前方案中，体系结构必须在提高稳定性、降低运营成本、增加功能性和使用寿命方面显示出优势。即使在开发和调试新协议的不可避免的成本之后，这种好处也必须保持不变，在事情发生变化时忍受不可避免的不稳定性，等等。
We explicitly recognize that the Internet consists of resources under control of multiple administrative entities. Each entity must be able to manage its own portion of the Internet as it sees fit. Moreover, the constraints that can be imposed on routing and addressing on the portion of the Internet under the control of one administration may not be feasibly extended to cover multiple administrations. Therefore, we recognize a natural and inevitable split between routing and addressing that is under a single administrative control and routing and addressing that involves multiple administrative entities. Moreover, while there may be multiple administrative authorities, the administrative authority boundaries may be complex and overlapping, rather than being a strict hierarchy.
我们明确承认，互联网由多个管理实体控制的资源组成。每个实体必须能够在其认为合适的情况下管理其自己的互联网部分。此外，在一个管理层控制下的互联网部分上对路由和寻址施加的限制可能无法扩展到涵盖多个管理层。因此，我们认识到在单一管理控制下的路由和寻址与涉及多个管理实体的路由和寻址之间存在着自然和不可避免的分离。此外，虽然可能有多个行政当局，但行政当局的边界可能是复杂和重叠的，而不是严格的等级制度。
Furthermore, there may be multiple levels of administration, each with its own level of policy and control. For example, a large network might have "continental-level" administrations covering its European and Asian operations, respectively. There would also be that network's "inter-continental" administration covering the Europe-to-Asia links. Finally, there would be the "Internet" level in the administrative structure (analogous to the "exterior" concept in the current routing architecture).
此外，可能有多个管理级别，每个级别都有自己的政策和控制级别。例如，一个大型网络可能有“大陆级”管理机构，分别覆盖其欧洲和亚洲业务。还将有该网络的“跨大陆”管理机构负责欧洲到亚洲的联系。最后，在管理结构中会有“Internet”级别（类似于当前路由架构中的“外部”概念）。
Thus, we believe that the administrative structure of the Internet must be extensible to many levels (more than the two provided by the current IGP/EGP split). The interior/exterior property is not absolute. The interior/exterior property of any point in the network is relative; a point on the network is interior with respect to some points on the network and exterior with respect to others.
因此，我们认为，互联网的管理结构必须扩展到多个层面（超过当前IGP/EGP拆分所提供的两个层面）。内部/外部属性不是绝对属性。网络中任何点的内部/外部属性都是相对的；网络上的点相对于网络上的某些点而言是内部的，相对于其他点而言是外部的。
Administrative entities may not trust each other; some may be almost actively hostile toward each other. The architecture must accommodate these models. Furthermore, the architecture must not require any particular level of trust among administrative entities.
行政实体不得相互信任；有些人可能会对彼此充满敌意。体系结构必须适应这些模型。此外，架构不得要求管理实体之间有任何特定级别的信任。
The following are not required or are non-goals. This should not be taken to mean that these issues must not be addressed by a new architecture. Rather, addressing these issues or not is purely an optional matter for the architects.
以下内容不是必需的或不是目标。这并不意味着这些问题不能由新的体系结构来解决。相反，对于架构师来说，是否解决这些问题纯粹是一个可选的问题。
We believe that it is not necessary for the architecture to minimize the size of the forwarding tables (FIBs). Current memory sizes, speeds, and prices, along with processor and Application-specific Integrated Circuit (ASIC) capabilities allow forwarding tables to be very large, O(E6), and allow fast (100 M lookups/second) tables to be built with little difficulty.
我们认为架构没有必要最小化转发表（FIB）的大小。当前的内存大小、速度和价格，以及处理器和专用集成电路（ASIC）功能允许转发表非常大，O（E6），并允许轻松构建快速（100 M查找/秒）表。
"Traffic engineering" is one of those terms that has become terribly overloaded. If one asks N people what traffic engineering is, one would get something like N! disjoint answers. Therefore, we elect not to require "traffic engineering", per se. Instead, we have endeavored to determine what the ultimate intent is when operators "traffic engineer" their networks and then make those capabilities an inherent part of the system.
“交通工程”是那些已经严重超载的术语之一。如果一个人问N个人什么是交通工程，他会得到N！不相交的答案。因此，我们选择不要求“交通工程”本身。相反，我们努力确定运营商“流量工程师”其网络的最终目的是什么，然后使这些功能成为系统的固有部分。
The new architecture is not designed explicitly to be an inter-domain multicast routing architecture. However, given the notable lack of a viable, robust, and widely deployed inter-domain multicast routing architecture, the architecture should not hinder the development and deployment of inter-domain multicast routing without an adverse effect on meeting the other requirements.
新的体系结构没有明确设计为域间多播路由体系结构。然而，鉴于明显缺乏可行、健壮且广泛部署的域间多播路由体系结构，该体系结构不应妨碍域间多播路由的开发和部署，而不会对满足其他要求产生不利影响。
We do note however that one respected network sage [Clark91] has said (roughly):
然而，我们确实注意到，一位受人尊敬的网络智者[Clark91]曾（粗略地）说过：
When you see a bunch of engineers standing around congratulating themselves for solving some particularly ugly problem in networking, go up to them, whisper "multicast", jump back, and watch the fun begin...
当你看到一群工程师站在周围祝贺他们自己解决了网络中一些特别难看的问题时，走到他们跟前，低声说“多播”，跳回去，看着有趣的开始。。。
The architecture concerns itself primarily with disseminating network topology information so that routers may select paths to destinations and build appropriate forwarding tables. Quality of Service (QoS) is not a part of this function and we make no requirements with respect to QoS.
该体系结构主要关注传播网络拓扑信息，以便路由器可以选择到目的地的路径并建立适当的转发表。服务质量（QoS）不是该功能的一部分，我们对QoS没有任何要求。
However, QoS is an area of great and evolving interest. It is reasonable to expect that in the not too distant future, sophisticated QoS facilities will be deployed in the Internet. Any new architecture and protocols should be developed with an eye toward these future evolutions. Extensibility mechanisms, allowing future QoS routing and signaling protocols to "piggy-back" on top of the basic routing system are desired.
然而，QoS是一个备受关注的领域。可以合理预期，在不久的将来，互联网上将部署先进的QoS设施。任何新的架构和协议的开发都应该着眼于这些未来的发展。扩展性机制，允许未来的QoS路由和信令协议“背驮”在基本路由系统之上是需要的。
We do require the ability to assign attributes to entities and then do path generation and selection based on those attributes. Some may call this QoS.
我们确实需要能够将属性分配给实体，然后基于这些属性进行路径生成和选择。有些人称之为QoS。
There is no specific requirement that CIDR-style (Classless Inter-Domain Routing) IP prefix aggregation be done by the new architecture. Address allocation policies, societal pressure, and the random growth and structure of the Internet have all conspired to make prefix aggregation extraordinarily difficult, if not impossible. This means that large numbers of prefixes will be sloshing about in the routing system and that forwarding tables will grow quite big. This is a cost that we believe must be borne.
没有具体要求新体系结构完成CIDR风格（无类域间路由）的IP前缀聚合。地址分配政策、社会压力以及互联网的随机增长和结构都使得前缀聚合变得异常困难（如果不是不可能的话）。这意味着大量前缀将在路由系统中晃动，转发表将变得相当大。这是我们认为必须承担的代价。
Nothing in this non-requirement should be interpreted as saying that prefix aggregation is explicitly prohibited. CIDR-style IP prefix aggregation might be used as a mechanism to meet other requirements, such as scaling.
此非要求中的任何内容都不应解释为明确禁止前缀聚合。CIDR风格的IP前缀聚合可以作为一种机制来满足其他需求，例如扩展。
Making the system impossible to misconfigure is, we believe, not required. The checking, constraints, and controls necessary to achieve this could, we believe, prevent operators from performing necessary tasks in the face of unforeseen circumstances.
我们认为，不需要让系统不被误解。我们认为，实现这一目标所需的检查、约束和控制可能会阻止操作员在不可预见的情况下执行必要的任务。
However, safety is always a "good thing", and any results from research in this area should certainly be taken into consideration and, where practical, incorporated into the new routing architecture.
然而，安全始终是一件“好事”，这一领域的任何研究结果都应该得到考虑，并在可行的情况下纳入新的路由体系结构。
History has shown that using the routing system to perform highly dynamic load balancing among multiple more-or-less-equal paths usually ends up causing all kinds of instability, etc., in the network. Thus, we do not require such a capability.
历史表明，使用路由系统在多条或多或少相等的路径之间执行高度动态负载平衡，通常会导致网络中的各种不稳定性等。因此，我们不需要这种能力。
However, this is an area that is ripe for additional research, and some believe that the capability will be necessary in the future. Thus, the architecture and protocols should be "malleable" enough to allow development and deployment of dynamic load-balancing capabilities, should we ever figure out how to do it.
然而，这是一个需要进一步研究的领域，一些人认为这一能力在未来是必要的。因此，架构和协议应该具有足够的“可塑性”，以便我们能够开发和部署动态负载平衡功能。
We believe that the routing system is not required to "do renumbering" of hosts and routers. That's an IP issue.
我们相信路由系统不需要对主机和路由器进行“重新编号”。这是一个IP问题。
Of course, the routing and addressing architecture must be able to deal with renumbering when it happens.
当然，路由和寻址体系结构必须能够在重新编号时进行处理。
In the Internet architecture, host mobility is handled on a per-host basis by a dedicated, Mobile-IP protocol [RFC3344]. Traffic destined for a mobile-host is explicitly forwarded by dedicated relay agents. Mobile-IP [RFC3344] adequately solves the host-mobility problem and we do not see a need for any additional requirements in this area. Of course, the new architecture must not impede or conflict with Mobile-IP.
在互联网体系结构中，主机移动性通过专用的移动IP协议（RFC3344）以每台主机为基础进行处理。目的地为移动主机的流量由专用中继代理显式转发。移动IP[RFC3344]充分解决了主机移动性问题，我们认为在这方面不需要任何额外的要求。当然，新的体系结构决不能妨碍移动IP或与之冲突。
For the purposes of development of the architecture, we assume that there is a "clean slate". Unless specified in Section 2.1, there are no explicit requirements that elements, concepts, or mechanisms of the current routing architecture be carried forward into the new one.
出于架构开发的目的，我们假设存在“干净的板岩”。除非第2.1节另有规定，否则没有明确要求将当前路由体系结构的元素、概念或机制带入新的路由体系结构。
The following is the result of the work done by Sub-Group B of the IRTF RRG in 2001-2002. It was originally released under the title: "Future Domain Routing Requirements" and was edited by Avri Doria and Elwyn Davies.
以下是IRTF RRG B小组在2001-2002年所做工作的结果。它最初以“未来域路由需求”的标题发布，由Avri Doria和Elwyn Davies编辑。
It is generally accepted that there are major shortcomings in the inter-domain routing of the Internet today and that these may result in meltdown within an unspecified period of time. Remedying these shortcomings will require extensive research to tie down the exact failure modes that lead to these shortcomings and identify the best techniques to remedy the situation.
人们普遍认为，当今互联网的域间路由存在重大缺陷，这些缺陷可能会在未指定的时间内导致崩溃。纠正这些缺点需要进行广泛的研究，以确定导致这些缺点的确切故障模式，并确定纠正这种情况的最佳技术。
Reviewer's Note: Even in 2001, there was a wide difference of opinion across the community regarding the shortcomings of inter-domain routing. In the years between writing and publication, further analysis, changes in operational practice, alterations to the demands made on inter-domain routing, modifications made to BGP, and a recognition of the difficulty of finding a replacement may have altered the views of some members of the community.
评论员注：即使在2001年，对于域间路由的缺点，整个社区的意见也有很大差异。在写作和出版之间的几年里，进一步的分析、操作实践的改变、对域间路由的要求的改变、对BGP的修改以及对难以找到替代者的认识可能改变了社区一些成员的观点。
Changes in the nature and quality of the services that users want from the Internet are difficult to provide within the current framework, as they impose requirements never foreseen by the original architects of the Internet routing system.
在当前的框架内，用户希望从互联网获得的服务的性质和质量的变化是很难提供的，因为它们强加了互联网路由系统的原始架构师从未预见到的要求。
The kind of radical changes that have to be accommodated are epitomized by the advent of IPv6 and the application of IP mechanisms to private commercial networks that offer specific service guarantees beyond the best-effort services of the public Internet. Major changes to the inter-domain routing system are inevitable to provide an efficient underpinning for the radically changed and increasingly commercially-based networks that rely on the IP protocol suite.
IPv6的出现和IP机制在私有商业网络中的应用是必须适应的根本性变化的一个缩影，这些私有商业网络提供公共互联网尽力而为服务之外的特定服务保证。域间路由系统的重大变化是不可避免的，它为依赖IP协议套件的网络提供了一个有效的基础，这些网络已经发生了根本性的变化，并且越来越商业化。
Although inter-domain routing is seen as the major source of problems, the interactions with intra-domain routing, and the constraints that confining changes to the inter-domain arena would impose, mean that we should consider the whole area of routing as an integrated system. This is done for two reasons:
虽然域间路由被视为问题的主要来源，但与域内路由的相互作用和限制域间变化的约束将被强加，意味着我们应该考虑整个路由区域作为一个集成系统。这样做有两个原因：
- Requirements should not presuppose the solution. A continued commitment to the current definitions and split between inter-domain and intra-domain routing would constitute such a presupposition. Therefore, this part of the document uses the name Future Domain Routing (FDR).
- 需求不应以解决方案为前提。继续遵守当前的定义并在域间和域内路由之间进行划分将构成这样一个前提。因此，文档的这一部分使用了未来域路由（FDR）的名称。
- It is necessary to understand the degree to which inter-domain and intra-domain routing are related within today's routing architecture.
- 在当今的路由体系结构中，有必要了解域间和域内路由的关联程度。
We are aware that using the term "domain routing" is already fraught with danger because of possible misinterpretation due to prior usage. The meaning of "domain routing" will be developed implicitly throughout the document, but a little advance explicit definition of the word "domain" is required, as well as some explanation on the scope of "routing".
我们知道，使用术语“域路由”已经充满了危险，因为先前的使用可能导致误解。“域路由”的含义将在整个文件中含蓄地阐述，但需要对“域”一词作一点预先明确的定义，并对“路由”的范围作一些解释。
This document uses "domain" in a very broad sense, to mean any collection of systems or domains that come under a common authority that determines the attributes defining, and the policies controlling, that collection. The use of "domain" in this manner is very similar to the concept of region that was put forth by John Wroclawski in his Metanet model [Wroclawski95]. The idea includes the notion that certain attributes will characterize the behavior of the systems within a domain and that there will be borders between domains. The idea of domain presented here does not presuppose that two domains will have the same behavior. Nor does it presuppose anything about the hierarchical nature of domains. Finally, it does not place restrictions on the nature of the attributes that might be used to determine membership in a domain. Since today's routing domains are an example of the concept of domains in this document, there has been no attempt to create a new term.
本文档在非常广泛的意义上使用了“域”，指的是属于共同权限的任何系统或域的集合，该权限决定了定义该集合的属性以及控制该集合的策略。以这种方式使用“域”与John Wroclawski在其元网模型[Wroclawski95]中提出的区域概念非常相似。该思想包括这样一个概念，即某些属性将表征域内系统的行为，域之间将存在边界。这里提出的域概念并不是假设两个域具有相同的行为。它也没有预先假定域的层次性。最后，它不会对可能用于确定域中成员身份的属性的性质设置限制。由于今天的路由域是本文档中域概念的一个示例，因此没有尝试创建一个新术语。
Current practice in routing-system design stresses the need to separate the concerns of the control plane and the forwarding plane in a router. This document will follow this practice, but we still use the term "routing" as a global portmanteau to cover all aspects of the system. Specifically, however, "routing" will be used to mean the process of discovering, interpreting, and distributing information about the logical and topological structure of the network.
路由系统设计的当前实践强调需要分离路由器中控制平面和转发平面的关注点。本文档将遵循这种做法，但我们仍然使用术语“路由”作为全局端口，以涵盖系统的所有方面。然而，具体而言，“路由”将用于指发现、解释和分发有关网络逻辑和拓扑结构的信息的过程。
Throughout this section, the terms "intra-domain" and "inter-domain" will be used. These should be understood as relative terms. In all cases of domains, there will be a set of network systems that are within that domain; routing between these systems will be termed "intra-domain". In some cases there will be routing between domains, which will be termed "inter-domain". It is possible that the routing exchange between two network systems can be viewed as intra-domain from one perspective and as inter-domain from another perspective.
在本节中，将使用术语“域内”和“域间”。这些应该被理解为相对术语。在所有域的情况下，将有一组网络系统在该域内；这些系统之间的路由将被称为“域内路由”。在某些情况下，域之间会有路由，称为“域间路由”。两个网络系统之间的路由交换可能从一个角度被视为域内交换，从另一个角度被视为域间交换。
The development of the Internet is likely to be driven by a number of changes that will affect the organization and the usage of the network, including:
互联网的发展可能受到影响网络组织和使用的许多变化的推动，包括：
- Ongoing evolution of the commercial relationships between (connectivity) service providers, leading to changes in the way in which peering between providers is organized and the way in which transit traffic is routed.
- （连接性）服务提供商之间商业关系的持续演变，导致提供商之间的对等组织方式和中转流量路由方式发生变化。
- Requirements for traffic engineering within and between domains including coping with multiple paths between domains.
- 域内和域之间的流量工程要求，包括处理域之间的多条路径。
- Addition of a second IP addressing technique, in the form of IPv6.
- 以IPv6的形式添加第二种IP寻址技术。
- The use of VPNs and private address space with IPv4 and IPv6.
- 在IPv4和IPv6中使用VPN和专用地址空间。
- Evolution of the end-to-end principle to deal with the expanded role of the Internet, as discussed in [Blumenthal01]: this paper discusses the possibility that the range of new requirements, especially the social and techno-political ones that are being placed on the future, may compromise the Internet's original design principles. This might cause the Internet to lose some of its key features, in particular, its ability to support new and unanticipated applications. This discussion is linked to the rise of new stakeholders in the Internet, especially ISPs; new government interests; the changing motivations of the ever growing user base; and the tension between the demand for trustworthy overall operation and the inability to trust the behavior of individual users.
- 如[Blumenthal01]中所述，为应对互联网作用的扩大，端到端原则的演变：本文讨论了一系列新要求，特别是未来的社会和技术政治要求，可能会损害互联网的原始设计原则。这可能会导致互联网失去一些关键功能，特别是它支持新的和意外的应用程序的能力。这一讨论与互联网上新的利益相关者，特别是互联网服务提供商的崛起有关；新政府利益；不断增长的用户群不断变化的动机；以及对可信任的整体操作的需求与无法信任单个用户行为之间的紧张关系。
- Incorporation of alternative forwarding techniques such as the explicit routing (pipes) supplied by the MPLS [RFC3031] and GMPLS [RFC3471] environments.
- 采用替代转发技术，如MPLS[RFC3031]和GMPLS[RFC3471]环境提供的显式路由（管道）。
- Integration of additional constraints into route determination from interactions with other layers (e.g., Shared Risk Link Groups [InferenceSRLG]). This includes the concern that redundant routes should not fate-share, e.g., because they physically run in the same trench.
- 通过与其他层的交互（例如，共享风险链接组[推论SRLG]），将附加约束集成到路线确定中。这包括担心冗余路由不应共享命运，例如，因为它们实际运行在同一个沟渠中。
- Support for alternative and multiple routing techniques that are better suited to delivering types of content organized in ways other than into IP-addressed packets.
- 支持替代和多种路由技术，这些技术更适合于以IP寻址数据包以外的方式组织的内容类型的交付。
Philosophically, the Internet has the mission of transferring information from one place to another. Conceptually, this information is rarely organized into conveniently sized, IP-addressed packets, and the FDR needs to consider how the information (content) to be carried is identified, named, and addressed. Routing techniques can then be adapted to handle the expected types of content.
从哲学上讲，互联网的使命是将信息从一个地方传输到另一个地方。从概念上讲，这种信息很少被组织成方便大小、IP地址的数据包，而FDR需要考虑如何识别、命名和处理要携带的信息（内容）。然后可以调整路由技术以处理预期类型的内容。
This section attempts to answer two questions:
本节试图回答两个问题：
- What are we trying to achieve in a new architecture?
- 在一个新的体系结构中，我们试图实现什么？
- Why should the Internet community care?
- 互联网社区为什么要关心？
There is a third question that needs to be answered as well, but that has seldom been explicitly discussed:
还有第三个问题也需要回答，但很少被明确讨论：
- How will we know when we have succeeded?
- 我们怎么知道我们什么时候成功了？
Many of today's routing problems are caused by a routing system that is not well matched to the organization and policies that it is trying to support. Our goal is to develop a routing architecture where even a domain organization that is not envisioned today can be served by a routing architecture that matches its requirements. We will know when this goal is achieved when the desired policies, rules, and organization can be mapped into the routing system in a natural, consistent, and easily understood way.
今天的许多路由问题都是由路由系统与它试图支持的组织和策略不匹配引起的。我们的目标是开发一个路由体系结构，在这个体系结构中，即使是今天还没有设想的领域组织，也可以由一个符合其需求的路由体系结构来提供服务。当所需的策略、规则和组织能够以自然、一致且易于理解的方式映射到路由系统中时，我们将知道这一目标何时实现。
Today's routing protocols only support a single data forwarding service that is typically used to deliver a best-effort service in the public Internet. On the other hand, Diffserv for example, can construct a number of different bit transport services within the network. Using some of the per-domain behaviors (PDB)s that have been discussed in the IETF, it is possible to construct services such as Virtual Wire [DiffservVW] and Assured Rate [DiffservAR].
今天的路由协议只支持一个数据转发服务，该服务通常用于在公共互联网上提供尽力而为的服务。另一方面，例如Diffserv可以在网络中构造许多不同的比特传输服务。使用IETF中讨论过的一些每域行为（PDB），可以构造虚拟线[DiffServw]和保证速率[DiffservAR]等服务。
Providers today offer rudimentary promises about traffic handling in the network, for example, delay and long-term packet loss guarantees. As time goes on, this becomes even more relevant. Communicating the service characteristics of paths in routing protocols will be necessary in the near future, and it will be necessary to be able to route packets according to their service requirements.
如今，提供商提供了有关网络流量处理的基本承诺，例如延迟和长期丢包保证。随着时间的推移，这一点变得更加重要。在不久的将来，在路由协议中传输路径的服务特性将是必要的，并且有必要能够根据服务需求路由数据包。
Thus, a goal of this architecture is to allow adequate information about path service characteristics to be passed between domains and consequently, to allow the delivery of bit transport services other than the best-effort datagram connectivity service that is the current common denominator.
因此，该架构的目标是允许在域之间传递关于路径服务特征的足够信息，从而允许比特传输服务的交付，而不是作为当前公分母的尽力而为数据报连接服务。
Any proposed FDR system should scale beyond the size and performance we can foresee for the next ten years. The previous IDR proposal as implemented by BGP, has, with some massaging, held up for over ten years. In that time the Internet has grown far beyond the predictions that were implied by the original requirements.
任何拟议的FDR系统的规模和性能都应该超出我们在未来十年所能预见的规模和性能。BGP之前实施的IDR提案，经过一些推敲，已经坚持了十多年。在这段时间里，互联网的发展远远超出了最初需求所暗示的预测。
Unfortunately, we will only know if we have succeeded in this goal if the FDR system survives beyond its design lifetime without serious massaging. Failure will be much easier to spot!
不幸的是，只有当FDR系统在没有严重按摩的情况下超过其设计寿命时，我们才能知道我们是否成功实现了这一目标。失败会更容易发现！
With the advent of circuit-based technologies (e.g., MPLS [RFC3031] and GMPLS [RFC3471]) managed by IP routers there are forwarding mechanisms other than the datagram service that need to be supported by the routing architecture.
随着由IP路由器管理的基于电路的技术（例如MPLS[RFC3031]和GMPLS[RFC3471]）的出现，除了数据报服务之外，还存在路由架构需要支持的转发机制。
An explicit goal of this architecture is to add support for forwarding mechanisms other then the current hop-by-hop datagram forwarding service driven by globally unique IP addresses.
此体系结构的明确目标是添加对转发机制的支持，而不是由全局唯一IP地址驱动的当前逐跳数据报转发服务。
It is envisioned that an organization can support multiple services within a single network. These services can, for example, be of different quality, of different connectivity type, or of different protocols (e.g., IPv4 and IPv6). For all these services, there may be common domain topology, even though the policies controlling the routing of information might differ from service to service. Thus, a goal with this architecture is to support separation between creation of a domain (or organization) topology map and service creation.
设想一个组织可以在一个网络中支持多个服务。例如，这些服务可以具有不同的质量、不同的连接类型或不同的协议（例如，IPv4和IPv6）。对于所有这些服务，可能存在公共域拓扑，即使控制信息路由的策略可能因服务而异。因此，此体系结构的目标是支持域（或组织）拓扑图的创建和服务创建之间的分离。
The architecture of a router is composed of two main separable parts: control and forwarding. These components, while inter-dependent, perform functions that are largely independent of each other. Control (routing, signaling, and management) is typically done in software while forwarding typically is done with specialized ASICs or network processors.
路由器的体系结构由两个主要的可分离部分组成：控制和转发。这些组件虽然相互依赖，但执行的功能在很大程度上彼此独立。控制（路由、信令和管理）通常由软件完成，而转发通常由专用ASIC或网络处理器完成。
The nature of an IP-based network today is that control and data protocols share the same network and forwarding regime. This may not always be the case in future networks, and we should be careful to avoid building in this sharing as an assumption in the FDR.
当今基于IP的网络的本质是控制协议和数据协议共享相同的网络和转发机制。在未来的网络中，情况可能并不总是如此，我们应该小心避免将这种共享作为罗斯福的一种假设。
A goal of this architecture is to support full separation of control and forwarding, and to consider what additional concerns might be properly considered separately (e.g., adjacency management).
这种架构的目标是支持完全分离的控制和转发，并考虑什么额外的关注，可以适当考虑单独（例如，邻接管理）。
3.2.3.7. Different Routing Paradigms in Different Areas of the Same Network
3.2.3.7. 同一网络不同区域的不同路由模式
A number of routing paradigms have been used or researched, in addition to the conventional shortest-path-by-hop-count paradigm that is the current mainstay of the Internet. In particular, differences in underlying transport networks may mean that other kinds of routing are more relevant, and the perceived need for traffic engineering will certainly alter the routing chosen in various domains.
除了传统的按跳计数的最短路径范例（目前互联网的主流）之外，已经使用或研究了许多路由范例。特别是，底层传输网络的差异可能意味着其他类型的路由更具相关性，而对流量工程的感知需求肯定会改变在不同领域中选择的路由。
Explicitly, one of these routing paradigms should be the current routing paradigm, so that the new paradigms will inter-operate in a backward-compatible way with today's system. This will facilitate a migration strategy that avoids flag days.
明确地说，其中一个路由范例应该是当前的路由范例，这样新的范例将以向后兼容的方式与今天的系统交互操作。这将有助于制定一种迁移策略，避免出现卖旗日。
3.2.3.8. Protection against Denial-of-Service and Other Security Attacks
3.2.3.8. 防止拒绝服务和其他安全攻击
Currently, existence of a route to a destination effectively implies that anybody who can get a packet onto the network is entitled to use that route. While there are limitations to this generalization, this is a clear invitation to denial-of-service attacks. A goal of the FDR system should be to allow traffic to be specifically linked to whole or partial routes so that a destination or link resources can be protected from unauthorized use.
目前，到目的地的路由的存在实际上意味着任何能够将数据包接入网络的人都有权使用该路由。虽然这种泛化存在局限性，但这显然会引发拒绝服务攻击。FDR系统的一个目标应该是允许通信量专门链接到整个或部分路由，以便保护目的地或链路资源不被未经授权的使用。
Editors' Note: When sections like this one and the previous ones on quality differentiation were written, the idea of separating traffic for security or quality was considered an unqualified advantage. Today, however, in the midst of active discussions on Network Neutrality, it is clear that such issues have a crucial policy component that also needs to be understood. These, and other similar issues, are open to further research.
编者按：当这一节和之前关于质量差异化的章节被编写时，为了安全或质量而分离流量的想法被认为是一个绝对的优势。然而，今天，在关于网络中立性的积极讨论中，很明显，这些问题有一个重要的政策组成部分，也需要理解。这些问题以及其他类似问题有待进一步研究。
It has been shown both analytically, by Griffin, et al. (see [Griffin99]), and practically (see [RFC3345]) that BGP will not converge stably or is only meta-stable (i.e., will not re-converge in the face of a single failure) when certain types of policy constraint are applied to categories of network topology. The addition of policy to the basic distance-vector algorithm invalidates the proofs of convergence that could be applied to a policy-free implementation.
Griffin等人（见[Griffin 99]）和实际（见[RFC3345]）都表明，当某些类型的策略约束应用于网络拓扑类别时，BGP不会稳定收敛或仅是亚稳定的（即，在单一故障情况下不会重新收敛）。将策略添加到基本距离向量算法中会使可应用于无策略实现的收敛性证明无效。
It has also been argued that global convergence may no longer be a necessary goal and that local convergence may be all that is required.
还有人认为，全球趋同可能不再是一个必要的目标，而局部趋同可能是所需要的一切。
A goal of the FDR should be to achieve provable convergence of the protocols used that may involve constraining the topologies and domains subject to convergence. This will also require vetting the policies imposed to ensure that they are compatible across domain boundaries and result in a consistent policy set.
FDR的一个目标应该是实现所用协议的可证明收敛性，该协议可能涉及约束要收敛的拓扑和域。这还需要审查强加的策略，以确保它们跨域边界兼容，并形成一致的策略集。
Editors' Note: This requirement is very optimistic in that it implies that it is possible to get operators to cooperate even it is seen by them to be against their business practices. Though perhaps Utopian, this is a good goal.
编者按：这一要求非常乐观，因为它意味着即使运营商认为这违反了他们的商业惯例，他们也有可能进行合作。尽管这可能是一个乌托邦，但这是一个很好的目标。
From time to time in the history of the Internet, there have been occurrences where misconfigured routers have destroyed global connectivity.
在互联网的历史上，不时会出现错误配置的路由器破坏全球连接的情况。
A goal of the FDR is to be more robust to configuration errors and failures. This should probably involve ensuring that the effects of misconfiguration and failure can be confined to some suitable locality of the failure or misconfiguration.
FDR的目标是对配置错误和故障具有更强的鲁棒性。这可能包括确保错误配置和故障的影响可以限制在故障或错误配置的某个适当位置。
The policy work ([rap-charter02], [snmpconf-charter02], and [policy-charter02]) that has been done at IETF provides an architecture that standardizes and simplifies management of QoS. This kind of simplicity is needed in a Future Domain Routing architecture and its protocols.
IETF已经完成的策略工作（[rap-charter02]、[snmpconf-charter02]和[policy-charter02]）提供了一种标准化和简化QoS管理的体系结构。在未来的域路由体系结构及其协议中需要这种简单性。
A goal of this architecture is to make configuration and management of inter-domain routing as simple as possible.
该体系结构的目标是使域间路由的配置和管理尽可能简单。
Editors' Note: Snmpconf and rap are the hopes of the past. Today, configuration and policy hope is focused on netconf [netconf-charter].
编者按：Snmpconf和rap是过去的希望。今天，配置和政策希望集中在netconf[netconf宪章]上。
RFC 1126 outlined a set of requirements that were used to guide the development of BGP. While the network has changed in the years since 1989, many of the same requirements remain. A future domain routing solution has to support, as its base requirement, the level of function that is available today. A detailed discussion of RFC 1126
RFC1126概述了一组用于指导BGP开发的需求。虽然自1989年以来，网络发生了变化，但许多相同的要求仍然存在。未来的域路由解决方案必须支持当前可用的功能级别，这是其基本要求。RFC1126的详细讨论
and its requirements can be found in [RFC5773]. Those requirements, while specifically spelled out in that document, are subsumed by the requirements in this document.
其要求见[RFC5773]。这些要求虽然在该文件中有明确规定，但包含在本文件的要求中。
This section considers the requirements imposed by the target audience of the FDR both in terms of organizations that might own networks that would use FDR, and the human users who will have to interact with the FDR.
本节考虑了FDR目标受众对可能拥有使用FDR的网络的组织和必须与FDR交互的人类用户提出的要求。
The organizations that own networks connected to the Internet have become much more diverse since RFC 1126 [RFC1126] was published. In particular, major parts of the network are now owned by commercial service provider organizations in the business of making profits from carrying data traffic.
自RFC 1126[RFC1126]出版以来，拥有连接到互联网的网络的组织变得更加多样化。特别是，网络的主要部分现在归商业服务提供商组织所有，从事从数据传输中获利的业务。
The routing system must take into account the commercial service provider's need for secrecy and security, as well as allowing them to organize their business as flexibly as possible.
路由系统必须考虑到商业服务提供商对保密性和安全性的需求，并允许他们尽可能灵活地组织业务。
Service providers will often wish to conceal the details of the network from other connected networks. So far as is possible, the routing system should not require the service providers to expose more details of the topology and capability of their networks than is strictly necessary.
服务提供商通常希望对其他连接的网络隐藏网络的详细信息。在可能的情况下，路由系统不应要求服务提供商公开其网络拓扑和能力的详细信息，而不是严格必要的信息。
Many service providers will offer contracts to their customers in the form of Service Level Agreements (SLAs). The routing system must allow the providers to support these SLAs through traffic engineering and load balancing as well as multi-homing, providing the degree of resilience and robustness that is needed.
许多服务提供商将以服务水平协议（SLA）的形式向其客户提供合同。路由系统必须允许提供商通过流量工程和负载平衡以及多主来支持这些SLA，提供所需的弹性和健壮性。
Service providers can be categorized as:
服务提供商可分为以下几类：
- Global Service Providers (GSPs) whose networks have a global reach. GSPs may, and usually will, wish to constrain traffic between their customers to run entirely on their networks. GSPs will interchange traffic at multiple peering points with other GSPs, and they will need extensive policy-based controls to control the interchange of traffic. Peering may be through the use of dedicated private lines between the partners or, increasingly, through Internet Exchange Points.
- 网络覆盖全球的全球服务提供商（GSP）。GSP可能，而且通常希望限制客户之间的通信量，使其完全在其网络上运行。GSP将在多个对等点与其他GSP交换流量，他们将需要广泛的基于策略的控制来控制流量交换。对等可以通过合作伙伴之间的专用专线进行，或者越来越多地通过互联网交换点进行。
- National, or regional, Service Providers (NSPs) that are similar to GSPs but typically cover one country. NSPs may operate as a federation that provides similar reach to a GSP and may wish to be able to steer traffic preferentially to other federation members to achieve global reach.
- 与GSP类似但通常覆盖一个国家的国家或地区服务提供商（NSP）。NSPs可以作为一个联邦运行，提供与GSP类似的覆盖范围，并且可能希望能够优先于其他联邦成员引导交通，以实现全球覆盖。
- Local Internet Service Providers (ISPs) operate regionally. They will typically purchase transit capacity from NSPs or GSPs to provide global connectivity, but they may also peer with neighboring, and sometimes distant, ISPs.
- 本地互联网服务提供商（ISP）在区域内运营。他们通常会从NSP或GSP处购买运输能力，以提供全球连接，但他们也可能与相邻的、有时是遥远的ISP对等。
The routing system should be sufficiently flexible to accommodate the continually changing business relationships of the providers and the various levels of trustworthiness that they apply to customers and partners.
路由系统应具有足够的灵活性，以适应提供商不断变化的业务关系，以及它们适用于客户和合作伙伴的各种级别的可信度。
Service providers will need to be involved in accounting for Internet usage and monitoring the traffic. They may be involved in government action to tax the usage of the Internet, enforce social mores and intellectual property rules, or apply surveillance to the traffic to detect or prevent crime.
服务提供商需要参与计算互联网使用情况和监控流量。他们可能参与政府的行动，对互联网的使用征税，强制执行社会习俗和知识产权规则，或者对流量进行监控，以发现或预防犯罪。
The leaves of the network domain graph are in many cases networks supporting a single enterprise. Such networks cover an enormous range of complexity. Some multi-national companies own networks that rival the complexity and reach of a GSP, whereas many fall into the Small Office-Home Office (SOHO) category. The routing system should allow simple and robust configuration and operation for the SOHO category, while effectively supporting the larger enterprise.
网络域图的叶子在许多情况下是支持单个企业的网络。这类网络覆盖了巨大的复杂性范围。一些跨国公司拥有的网络可以与普惠制的复杂性和覆盖范围相媲美，而许多公司属于小型办公室-家庭办公室（SOHO）类别。路由系统应允许对SOHO类别进行简单而稳健的配置和操作，同时有效地支持大型企业。
Enterprises are particularly likely to lack the capability to configure and manage a complex routing system, and every effort should be made to provide simple configuration and operation for such networks.
企业尤其可能缺乏配置和管理复杂路由系统的能力，因此应尽一切努力为此类网络提供简单的配置和操作。
Enterprises will also need to be able to change their service provider with ease. While this is predominantly a naming and addressing issue, the routing system must be able to support seamless changeover; for example, if the changeover requires a change of address prefix, the routing system must be able to cope with a period when both sets of addresses are in use.
企业还需要能够轻松地更换其服务提供商。虽然这主要是一个命名和寻址问题，但路由系统必须能够支持无缝切换；例如，如果转换需要更改地址前缀，则路由系统必须能够处理两组地址同时使用的时间段。
Enterprises will wish to be able to multi-home to one or more providers as one possible means of enhancing the resilience of their network.
企业将希望能够向一个或多个提供商提供多家服务，作为增强其网络弹性的一种可能手段。
Enterprises will also frequently need to control the trust that they place both in workers and external connections through firewalls and similar mid-boxes placed at their external connections.
企业还经常需要通过防火墙和放置在外部连接处的类似中间盒来控制对员工和外部连接的信任。
Increasingly domestic, i.e., non-business home, networks are likely to be 'always on' and will resemble SOHO enterprises networks with no special requirements on the routing system.
越来越多的家庭网络，即非商业家庭网络，很可能“始终开启”，类似于SOHO企业网络，对路由系统没有特殊要求。
The routing system must also continue to support dial-up users.
路由系统还必须继续支持拨号用户。
Peering of service providers, academic networks, and larger enterprises is happening increasingly at specific Internet Exchange Points where many networks are linked together in a relatively small physical area. The resources of the exchange may be owned by a trusted third party or owned jointly by the connecting networks. The routing systems should support such exchange points without requiring the exchange point to either operate as a superior entity with every connected network logically inferior to it or by requiring the exchange point to be a member of one (or all) connected networks. The connecting networks have to delegate a certain amount of trust to the exchange point operator.
服务提供商、学术网络和大型企业的对等越来越多地发生在特定的互联网交换点，在这些交换点上，许多网络在一个相对较小的物理区域内连接在一起。交易所的资源可以由受信任的第三方拥有，也可以由连接网络共同拥有。路由系统应支持此类交换点，而无需交换点作为上级实体运行，且每个连接的网络在逻辑上都低于该交换点，或要求交换点成为一个（或所有）连接网络的成员。连接网络必须将一定数量的信任委托给交换点运营商。
Content providers are at one level a special class of enterprise, but the desire to deliver content efficiently means that a content provider may provide multiple replicated origin servers or caches across a network. These may also be provided by a separate content delivery service. The routing system should facilitate delivering content from the most efficient location.
内容提供商在某种程度上是一种特殊的企业类别，但高效交付内容的愿望意味着内容提供商可以跨网络提供多个复制的源服务器或缓存。这些也可以由单独的内容交付服务提供。路由系统应便于从最高效的位置传送内容。
This section covers the most important human users of the FDR and their expected interactions with the system.
本节介绍FDR最重要的人类用户及其与系统的预期交互。
The routing system must continue to deliver the current global connectivity service (i.e., any unique address to any other unique address, subject to policy constraints) that has always been the basic aim of the Internet.
路由系统必须继续提供当前的全球连接服务（即，任何唯一地址到任何其他唯一地址，受政策约束），这一直是互联网的基本目标。
End user applications should be able to request, or have requested on their behalf by agents and policy mechanisms, end-to-end communication services with QoS characteristics different from the best-effort service that is the foundation of today's Internet. It should be possible to request both a single service channel and a bundle of service channels delivered as a single entity.
终端用户应用程序应该能够通过代理和策略机制来请求或请求代理，端到端的通信服务具有不同于尽力而为服务的QoS特性，这是当今互联网的基础。应该可以请求单个服务通道和作为单个实体交付的服务通道包。
The routing system should allow network planners to plan and implement a network that can be proved to be stable and will meet their traffic engineering requirements.
路由系统应允许网络规划者规划和实施一个可以证明稳定并满足其流量工程要求的网络。
The routing system should, so far as is possible, be simple to configure, operate and troubleshoot, behave in a predictable and stable fashion, and deliver appropriate statistics and events to allow the network to be managed and upgraded in an efficient and timely fashion.
路由系统应尽可能简单地配置、操作和故障排除，以可预测和稳定的方式运行，并提供适当的统计数据和事件，以便以高效和及时的方式管理和升级网络。
The routing system must support mobile end users. It is clear that mobility is becoming a predominant mode for network access.
路由系统必须支持移动终端用户。很明显，移动性正在成为网络接入的主要模式。
While many of the requirements to which the protocol must respond are technical, some aren't. These mandated constraints are those that are determined by conditions of the world around us. Understanding these requirements requires an analysis of the world in which these systems will be deployed. The constraints include those that are determined by:
虽然协议必须响应的许多要求是技术性的，但有些要求不是。这些强制性约束是由我们周围世界的条件决定的。了解这些需求需要对部署这些系统的世界进行分析。这些约束包括由以下因素确定的约束：
- environmental factors,
- 环境因素,，
- geography,
- 地理
- political boundaries and considerations, and
- 政治边界和考虑因素，以及
- technological factors such as the prevalence of different levels of technology in the developed world compared to those in the developing or undeveloped world.
- 技术因素，如发达国家与发展中国家或不发达国家相比，不同技术水平的普及率。
The graph of the Internet network, with routers and other control boxes as the nodes and communication links as the edges, is today partitioned administratively into a large number of disjoint domains.
以路由器和其他控制盒为节点、以通信链路为边缘的互联网网络图，如今被行政地划分为大量不相交的域。
A common administration may have responsibility for one or more domains that may or may not be adjacent in the graph.
公共管理可能负责一个或多个域，这些域在图中可能相邻，也可能不相邻。
Commercial and policy constraints affecting the routing system will typically be exercised at the boundaries of these domains where traffic is exchanged between the domains.
影响路由系统的商业和政策约束通常将在这些域的边界上执行，在这些域之间交换流量。
The perceived need for commercial confidentiality will seek to minimize the control information transferred across these boundaries, leading to requirements for aggregated information, abstracted maps of connectivity exported from domains, and mistrust of supplied information.
对商业机密性的感知需求将寻求最大限度地减少跨越这些边界传输的控制信息，从而导致对聚合信息、从域导出的连接抽象地图的需求，以及对所提供信息的不信任。
The perceived desire for anonymity may require the use of zero-knowledge security protocols to allow users to access resources without exposing their identity.
感知到的匿名性需求可能需要使用零知识安全协议，以允许用户在不暴露其身份的情况下访问资源。
The requirements should provide the ability for groups of peering domains to be treated as a complex domain. These complex domains could have a common administrative policy.
这些需求应提供将对等域组视为复杂域的能力。这些复杂的域可以有一个通用的管理策略。
The diverse Layer 2 networks, over which the Layer 3 routing system is implemented, have typically been operated totally independently from the Layer 3 network and often with their own routing mechanisms. Consideration needs to be given to the desirable degree and nature of interchange of information between the layers. In particular, the need for guaranteed robustness through diverse routing layers implies knowledge of the underlying networks.
实现第三层路由系统的各种第二层网络通常完全独立于第三层网络运行，并且通常具有自己的路由机制。需要考虑各层之间信息交换的理想程度和性质。特别是，需要通过不同的路由层保证健壮性，这意味着需要了解底层网络。
Mobile access networks may also impose extra requirements on Layer 3 routing.
移动接入网络还可能对第3层路由提出额外要求。
The routing system operates at Layer 3 in the network. To achieve robustness and resilience at this layer requires that, where multiple diverse routes are employed as part of delivering the resilience, the routing system at Layer 3 needs to be assured that the Layer 2 and lower routes are really diverse. The "diamond problem" is the
路由系统在网络的第3层运行。为了在这一层实现健壮性和弹性，需要在使用多种多样的路由作为提供弹性的一部分的情况下，第3层的路由系统需要确保第2层和更低层的路由是真正多样的。“钻石问题”是最重要的问题
simplest form of this problem -- a Layer 3 provider attempting to provide diversity buys Layer 2 services from two separate providers who in turn buy Layer 1 services from the same provider:
这个问题的最简单形式是——一个试图提供多样性的第3层提供商从两个独立的提供商处购买第2层服务，而这两个提供商又从同一个提供商处购买第1层服务：
Layer 3 service
/ \
/ \
Layer 2 Layer 2
Provider A Provider B
\ /
\ /
Layer 1 Provider
Layer 3 service
/ \
/ \
Layer 2 Layer 2
Provider A Provider B
\ /
\ /
Layer 1 Provider
Now, when the backhoe cuts the trench, the Layer 3 provider has no resilience unless he had taken special steps to verify that the trench wasn't common. The routing system should facilitate avoidance of this kind of trap.
现在，当反铲挖沟时，第3层供应商没有恢复力，除非他采取特殊步骤验证沟渠不常见。路由系统应便于避免此类陷阱。
Some work is going on to understand the sort of problems that stem from this requirement, such as the work on Shared Risk Link Groups [InferenceSRLG]. Unfortunately, the full generality of the problem requires diversity be maintained over time between an arbitrarily large set of mutually distrustful providers. For some cases, it may be sufficient for diversity to be checked at provisioning or route instantiation time, but this remains a hard problem requiring research work.
一些工作正在进行中，以了解这一需求产生的问题类型，例如关于共享风险链接组的工作[推论SRLG]。不幸的是，问题的普遍性要求在任意大的相互不信任的提供者之间保持多样性。在某些情况下，在供应或路由实例化时检查多样性就足够了，但这仍然是一个需要研究的难题。
There is a full range of opinion on this subject. An informal survey indicates that the range varies from 2 to 6 years. And while there are those, possibly outliers, who think there is no need for a new routing architecture as well as those who think a new architecture was needed years ago, the median seems to lie at around 4 years. As in all projections of the future, this is not provable at this time.
在这个问题上有各种各样的意见。一项非正式调查表明，这一范围从2年到6年不等。虽然有些人，可能是离群者，认为不需要新的路由架构，也有人认为几年前需要新的架构，但中位数似乎在4年左右。正如所有对未来的预测一样，这在目前是无法证明的。
Editors' Note: The paragraph above was written in 2002, yet could be written without change in 2006. As with many technical predictions and schedules, the horizon has remained fixed through this interval.
编者按：上述段落写于2002年，但在2006年可以不加修改地写成。与许多技术预测和时间表一样，在这段时间间隔内，地平线保持不变。
In projecting the requirements for the Future Domain Routing, a number of assumptions have been made. The requirements set out should be consistent with these assumptions, but there are doubtless a number of other assumptions that are not explicitly articulated here:
在预测未来域路由的需求时，已经做出了一些假设。规定的要求应与这些假设一致，但毫无疑问，还有许多其他假设未在此处明确阐述：
1. The number of hosts today is somewhere in the area of 100 million. With dial-in, NATs, and the universal deployment of IPv6, this is likely to become up to 500 million users (see [CIDR]). In a number of years, with wireless accesses and different appliances attaching to the Internet, we are likely to see a couple of billion (10^9) "users" on the Internet. The number of globally addressable hosts is very much dependent on how common NATs will be in the future.
1. 今天的主机数量大约在1亿台左右。随着拨号、NAT和IPv6的普遍部署，这很可能成为5亿用户（参见[CIDR]）。在若干年内，随着无线接入和不同的设备连接到互联网，我们可能会在互联网上看到数十亿（10^9）“用户”。全球可寻址主机的数量在很大程度上取决于未来NAT的普及程度。
2. NATs, firewalls, and other middle-boxes exist, and we cannot assume that they will cease being a presence in the networks.
2. NAT、防火墙和其他中间盒是存在的，我们不能假设它们将不再存在于网络中。
3. The number of operators in the Internet will probably not grow very much, as there is a likelihood that operators will tend to merge. However, as Internet-connectivity expands to new countries, new operators will emerge and then merge again.
3. 互联网运营商的数量可能不会有太大增长，因为运营商可能会倾向于合并。然而，随着互联网连接扩展到新的国家，新的运营商将出现，然后再次合并。
4. At the beginning of 2002, there are around 12000 registered ASs. With current use of ASs (e.g., multi-homing) the number of ASs could be expected to grow to 25000 in about 10 years [Broido02]. This is down from a previously reported growth rate of 51% per year [RFC3221]. Future growth rates are difficult to predict.
4. 2002年初，大约有12000头注册的ASs。随着目前ASs的使用（例如，多宿主），ASs的数量有望在大约10年内增长到25000头[Broidoo2]。这低于之前报告的每年51%的增长率[RFC3221]。未来的增长率很难预测。
Editors' Note: In the routing report table of August 2006, the total number of ASs present in the Internet Routing Table was 23000. In 4 years, this is substantial progress on the prediction of 25000 ASs. Also, there are significantly more ASs registered than are visibly active, i.e., in excess of 42000 in mid-2006. It is possible, however, that many are being used internally.
编者注：在2006年8月的路由报告表中，互联网路由表中的ASs总数为23000。在4年内，这是预测25000头ASs的重大进展。此外，登记的ASs明显多于活跃的ASs，即2006年年中超过42000头。然而，也可能有许多是在内部使用的。
5. In contrast to the number of operators, the number of domains is likely to grow significantly. Today, each operator has different domains within an AS, but this also shows in SLAs and policies internal to the operator. Making this globally visible would create a number of domains; 10-100 times the number of ASs, i.e., between 100,000 and 1,000,000.
5. 与运算符的数量相比，域的数量可能会显著增加。如今，每个运营商在AS中都有不同的域，但这也体现在运营商内部的SLA和策略中。使其全球可见将创建许多域；ASs数量的10-100倍，即100000到1000000之间。
6. With more and more capacity at the edge of the network, the IP network will expand. Today, there are operators with several thousands of routers, but this is likely to be increased. Some domains will probably contain tens of thousands of routers.
6. 随着网络边缘的容量越来越大，IP网络将不断扩展。今天，有运营商拥有数千台路由器，但这可能会增加。一些域可能包含数以万计的路由器。
7. The speed of connections in the (fixed) access will technically be (almost) unconstrained. However, the cost for the links will not be negligible so that the apparent speed will be effectively bounded. Within a number of years, some will have multi-gigabit speed in the access.
7. 从技术上讲，（固定）接入的连接速度将（几乎）不受限制。然而，链路的成本将不可忽略，因此表观速度将有效限制。在若干年内，一些设备的接入速度将达到数千兆位。
8. At the same time, the bandwidth of wireless access still has a strict upper-bound. Within the foreseeable future each user will have only a tiny amount of resources available compared to fixed accesses (10 kbps to 2 Mbps for a Universal Mobile Telecommunications System (UMTS) with only a few achieving the higher figure as the bandwidth is shared between the active users in a cell and only small cells can actually reach this speed, but 11 Mbps or more for wireless LAN connections). There may also be requirements for effective use of bandwidth as low as 2.4 Kbps or lower, in some applications.
8. 同时，无线接入的带宽仍然有严格的上限。在可预见的未来，与固定接入（通用移动通信系统（UMTS）的10 kbps到2 Mbps）相比，每个用户仅有少量可用资源由于带宽在小区中的活跃用户之间共享，只有少数几个小区达到了更高的速度，而且只有小的小区才能达到这个速度，但无线局域网连接的速度为11 Mbps或更高）。在某些应用中，可能还需要有效使用低至2.4 Kbps或更低的带宽。
9. Assumptions 7 and 8 taken together suggest a minimum span of bandwidth between 2.4 kbps to 10 Gbps.
9. 假设7和8加在一起表明带宽的最小跨度在2.4 kbps到10 Gbps之间。
10. The speed in the backbone has grown rapidly, and there is no evidence that the growth will stop in the coming years. Terabit-speed is likely to be the minimum backbone speed in a couple of years. The range of bandwidths that need to be represented will require consideration on how to represent the values in the protocols.
10. 主干网的增长速度很快，没有证据表明这种增长会在未来几年停止。太比特速度可能是几年内的最低主干速度。需要表示的带宽范围需要考虑如何表示协议中的值。
11. There have been discussions as to whether Moore's Law will continue to hold for processor speed. If Moore's Law does not hold, then communication circuits might play a more important role in the future. Also, optical routing is based on circuit technology, which is the main reason for taking "circuits" into account when designing an FDR.
11. 关于摩尔定律是否会继续适用于处理器速度，已经有过讨论。如果摩尔定律不成立，那么通信电路在未来可能扮演更重要的角色。此外，光路由基于电路技术，这是设计FDR时考虑“电路”的主要原因。
12. However, the datagram model still remains the fundamental model for the Internet.
12. 然而，数据报模型仍然是互联网的基本模型。
13. The number of peering points in the network is likely to grow, as multi-homing becomes important. Also, traffic will become more locally distributed, which will drive the demand for local peering.
13. 随着多归属变得越来越重要，网络中的对等点数量可能会增加。此外，流量将变得更加本地分布，这将推动对本地对等的需求。
Editors' Note: On the other hand, peer-to-peer networking may shift the balance in demand for local peering.
编者按：另一方面，点对点网络可能会改变对本地对等的需求平衡。
14. The FDR will achieve the same degree of ubiquity as the current Internet and IP routing.
14. FDR将实现与当前互联网和IP路由相同程度的普遍性。
This section includes a detailed discussion of new requirements for a Future Domain Routing architecture. The nth requirement carries the label "R(n)". As discussed in Section 3.2.3.12, a new architecture
本节详细讨论了未来域路由体系结构的新需求。第n项要求带有标签“R（n）”。如第3.2.3.12节所述，新体系结构
must build upon the requirements of the past routing framework and must not reduce the functionality of the network. A discussion and analysis of the RFC 1126 requirements can be found in [RFC5773].
必须建立在过去路由框架的要求之上，并且不得降低网络的功能。有关RFC 1126要求的讨论和分析，请参见[RFC5773]。
3.6.1.1. Routers Should Be Able to Learn and to Exploit the Domain Topology
3.6.1.1. 路由器应该能够学习和利用域拓扑
R(1) Routers must be able to acquire and hold sufficient information on the underlying topology of the domain to allow the establishment of routes on that topology.
R（1）路由器必须能够获取并保存有关域的底层拓扑的足够信息，以允许在该拓扑上建立路由。
R(2) Routers must have the ability to control the establishment of routes on the underlying topology.
R（2）路由器必须能够控制基础拓扑上路由的建立。
R(3) Routers must be able, where appropriate, to control Sub-IP mechanisms to support the establishment of routes.
R（3）路由器必须能够在适当的情况下控制子IP机制，以支持建立路由。
The OSI Inter-Domain Routing Protocol (IDRP) [ISO10747] allowed a collection of topologically related domains to be replaced by an aggregate domain object, in a similar way to the Nimrod [Chiappa02] domain hierarchies. This allowed a route to be more compactly represented by a single collection instead of a sequence of individual domains.
OSI域间路由协议（IDRP）[ISO10747]允许用聚合域对象替换拓扑相关域的集合，类似于Nimrod[Chiapa02]域层次结构。这使得路由由单个集合而不是单个域序列更紧凑地表示。
R(4) Routers must, where appropriate, be able to construct abstractions of the topology that represent an aggregation of the topological features of some area of the topology.
R（4）在适当的情况下，路由器必须能够构造拓扑的抽象，这些抽象表示拓扑某个区域的拓扑特征的集合。
3.6.1.2. The Same Topology Information Should Support Different Path Selection Ideas
3.6.1.2. 相同的拓扑信息应支持不同的路径选择思想
The same topology information needs to provide the more flexible spectrum of path selection methods that we might expect to find in a future Internet, including distributed techniques such as hop-by-hop, shortest path, local optimization constraint-based, class of service, source address routing, and destination address routing, as well as the centralized, global optimization constraint-based "traffic engineering" type. Allowing different path selection techniques will produce a much more predictable and comprehensible result than the "clever tricks" that are currently needed to achieve the same results. Traffic engineering functions need to be combined.
同样的拓扑信息需要提供我们在未来互联网中可能会发现的更灵活的路径选择方法，包括分布式技术，如逐跳、最短路径、基于局部优化约束、服务类别、源地址路由和目标地址路由，以及集中式、基于全局优化约束的“交通工程”类型。允许使用不同的路径选择技术将产生比目前实现相同结果所需的“聪明技巧”更可预测和更易理解的结果。交通工程功能需要结合起来。
R(5) Routers must be capable of supporting a small number of different path selection algorithms.
R（5）路由器必须能够支持少量不同的路径选择算法。
3.6.1.3. Separation of the Routing Information Topology from the Data Transport Topology
3.6.1.3. 路由信息拓扑与数据传输拓扑的分离
R(6) The controlling network may be logically separate from the controlled network.
R（6）控制网络可以在逻辑上与受控网络分离。
The two functional "planes" may physically reside in the same nodes and share the same links, but this is not the only possibility, and other options may sometimes be necessary. An example is a pure circuit switch (that cannot see individual IP packets) combined with an external controller. Another example may be multiple links between two routers, where all the links are used for data forwarding but only one is used for carrying the routing session.
两个功能“平面”可能物理上位于相同的节点中并共享相同的链接，但这不是唯一的可能性，有时可能需要其他选项。例如，与外部控制器组合的纯电路交换机（无法看到单个IP数据包）。另一个示例可以是两个路由器之间的多个链路，其中所有链路用于数据转发，但只有一个用于承载路由会话。
R(7) Relevant changes in the state of the network, including modifications to the topology and changes in the values of dynamic capabilities, must be distributed to every entity in the network that needs them, in a reliable and trusted way, at the earliest appropriate time after the changes have occurred.
R（7）网络状态的相关变化，包括拓扑结构的修改和动态能力值的变化，必须在变化发生后的最早适当时间以可靠和可信的方式分发给网络中需要这些变化的每个实体。
R(8) Information must not be distributed outside areas where it is needed, or believed to be needed, for the operation of the routing system.
R（8）信息不得分布在路由系统运行需要或认为需要的区域之外。
R(9) Information must be distributed in such a way that it minimizes the load on the network, consistent with the required response time of the network to changes.
R（9）信息的分布方式必须使网络负载最小化，与网络对变化的响应时间一致。
R(10) The router must be able to acquire and store additional static and dynamic information that relates to the capabilities of the topology and its component nodes and links and that can subsequently be used by path selection methods.
R（10）路由器必须能够获取并存储与拓扑及其组件节点和链路的能力相关的额外静态和动态信息，这些信息随后可由路径选择方法使用。
The inter-domain routing system must be able to advertise more kinds of information than just connectivity and domain paths.
域间路由系统必须能够发布更多种类的信息，而不仅仅是连接性和域路径。
R(11) The routing system must support service specifications, e.g., the Service Level Specifications (SLSs) developed by the Differentiated Services working group [RFC3260].
R（11）路由系统必须支持服务规范，例如由区分服务工作组[RFC3260]制定的服务级别规范（SLS）。
Careful attention should be paid to ensuring that the distribution of additional information with path advertisements remains scalable as domains and the Internet get larger, more numerous, and more diversified.
当域和Internet变得更大、更多、更多样化时，应注意确保路径广告中附加信息的分发保持可伸缩性。
R(12) The distribution mechanism used for distributing network state information must be scalable with respect to the expected size of domains and the volume and rate of change of dynamic state that can be expected.
R（12）用于分发网络状态信息的分发机制必须能够根据预期的域大小以及预期的动态状态的变化量和速率进行伸缩。
The combination of R(9) and R(12) may result in a compromise between the responsiveness of the network to change and the overhead of distributing change notifications. Attempts to respond to very rapid changes may damage the stability of the routing system.
R（9）和R（12）的组合可导致网络对变更的响应性和分发变更通知的开销之间的折衷。试图对快速变化做出响应可能会损害路由系统的稳定性。
Possible examples of additional capability information that might be carried include:
可能携带的其他能力信息的可能示例包括：
- QoS information
- 服务质量信息
To allow an ISP to sell predictable end-to-end QoS service to any destination, the routing system should have information about the end-to-end QoS. This means that:
为了允许ISP向任何目的地销售可预测的端到端QoS服务，路由系统应该具有关于端到端QoS的信息。这意味着：
R(13) The routing system must be able to support different paths for different services.
R（13）路由系统必须能够支持不同服务的不同路径。
R(14) The routing system must be able to forward traffic on the path appropriate for the service selected for the traffic, either according to an explicit marking in each packet (e.g., MPLS labels, Diffserv Per-Hop Behaviors (PHBs) or DSCP values) or implicitly (e.g., the physical or logical port on which the traffic arrives).
R（14）路由系统必须能够根据每个分组中的明确标记（例如，MPLS标签、区分服务每跳行为（PHB）或DSCP值）或隐含标记（例如，流量到达的物理或逻辑端口），在适合于为流量选择的服务的路径上转发流量。
R(15) The routing system should also be able to carry information about the expected (or actually, promised) characteristics of the entire path and the price for the service.
R（15）路由系统还应能够携带有关整个路径的预期（或实际承诺）特征和服务价格的信息。
(If such information is exchanged at all between network operators today, it is through bilateral management interfaces, and not through the routing protocols.)
（如果这些信息今天在网络运营商之间进行交换，那么它是通过双边管理接口，而不是通过路由协议。）
This would allow for the operator to optimize the choice of path based on a price/performance trade-off.
这将允许运营商根据价格/性能权衡优化路径选择。
In addition to providing dynamic QoS information, the system should be able to use static class-of-service information.
除了提供动态QoS信息外，系统还应该能够使用静态服务类信息。
- Security information
- 安全信息
Security characteristics of other domains referred to by advertisements can allow the routing entity to make routing decisions based on political concerns. The information itself is assumed to be secure so that it can be trusted.
广告引用的其他域的安全特性可以允许路由实体基于政治考虑做出路由决策。假定信息本身是安全的，因此可以信任它。
- Usage and cost information
- 使用和成本信息
Usage and cost information can be used for billing and traffic engineering. In order to support cost-based routing policies for customers (i.e., peer ISPs), information such as "traffic on this link or path costs XXX per Gigabyte" needs to be advertised, so that the customer can choose a more or a less expensive route.
使用情况和成本信息可用于计费和流量工程。为了支持客户（即对等ISP）基于成本的路由策略，需要公布诸如“此链路上的流量或路径成本为每GB XXX”之类的信息，以便客户可以选择成本更高或更低的路由。
- Monitored performance
- 监控性能
Performance information such as delay and drop frequency can be carried. (This may only be suitable inside a domain because of trust considerations.) This should support at least the kind of delay-bound contractual terms that are currently being offered by service providers. Note that these values refer to the outcome of carrying bits on the path, whereas the QoS information refers to the proposed behavior that results in this outcome.
可以携带延迟和下降频率等性能信息。（出于信任考虑，这可能仅适用于域内。）这至少应支持服务提供商目前提供的受延迟约束的合同条款。请注意，这些值指的是在路径上承载位的结果，而QoS信息指的是导致此结果的建议行为。
- Multicast information
- 多播信息
R(16) The routing system must provide information needed to create multicast distribution trees. This information must be provided for one-to-many distribution trees and should be provided for many-to-many distribution trees.
R（16）路由系统必须提供创建多播分发树所需的信息。必须为一对多分布树提供此信息，并应为多对多分布树提供此信息。
The actual construction of distribution trees is not necessarily done by the routing system.
配电树的实际构造不一定由路由系统完成。
R(17) The new network architecture must be stable without needing global convergence, i.e., convergence is a local property.
R（17）新的网络结构必须是稳定的，而不需要全局收敛，即收敛是局部性质。
The degree to which this is possible and the definition of "local" remain research topics. Restricting the requirement for convergence to localities will have an effect on all of the other requirements in this section.
这在多大程度上是可能的，“本地”的定义仍然是研究课题。将衔接要求限制在地方将对本节中的所有其他要求产生影响。
R(18) The distribution and the rate of distribution of changes must not affect the stability of the routing information. For example, commencing redistribution of a change before the previous one has settled must not cause instability.
R（18）变化的分布和分布率不得影响路由信息的稳定性。例如，在前一个变更解决之前开始重新分配变更不得导致不稳定。
R(19) The routing system must minimize oscillations in route advertisements.
R（19）路由系统必须最小化路由广告中的振荡。
In line with the separation of routing and forwarding concerns:
根据路由和转发问题的分离：
R(20) The distribution of routing information must be, so far as is possible, loop-free.
R（20）路由信息的分布必须尽可能无环路。
R(21) The forwarding information created from this routing information must seek to minimize persistent loops in the data-forwarding paths.
R（21）根据该路由信息创建的转发信息必须寻求最小化数据转发路径中的持久循环。
It is accepted that transient loops may occur during convergence of the protocol and that there are trade-offs between loop avoidance and global scalability.
在协议的收敛过程中可能会出现瞬态循环，并且在避免循环和全局可伸缩性之间存在权衡。
R(22) The routing system must provide means for detecting failures of node equipment or communication links.
R（22）路由系统必须提供检测节点设备或通信链路故障的方法。
R(23) The routing system should be able to coordinate failure indications from Layer 3 mechanisms, from nodal mechanisms built into the routing system, and from lower-layer mechanisms that propagate up to Layer 3 in order to determine the root cause of the failure. This will allow the routing system to react correctly to the failure by activating appropriate mitigation and repair mechanisms if required, while ensuring that it does not react if lower-layer repair mechanisms are able to repair or mitigate the fault.
R（23）布线系统应能够协调来自第3层机制、内置于布线系统中的节点机制以及传播至第3层的下层机制的故障指示，以确定故障的根本原因。这将允许路由系统通过激活适当的缓解和修复机制（如果需要）对故障做出正确反应，同时确保在下层修复机制能够修复或缓解故障时不会做出反应。
Most Layer 3 routing protocols have utilized keepalives or "hello" protocols as a means of detecting failures at Layer 3. The keepalive mechanisms are often complemented by analog mechanisms (e.g., laser-light detection) and hardware mechanisms (e.g., hardware/software watchdogs) that are built into routing nodes and communication links. Great care must be taken to make the best possible use of the various failure repair methods available while ensuring that only one repair mechanism at a time is allowed to repair any given fault.
大多数第3层路由协议都使用keepalives或“hello”协议作为检测第3层故障的手段。keepalive机制通常由内置于路由节点和通信链路中的模拟机制（如激光检测）和硬件机制（如硬件/软件看门狗）补充。必须非常小心地尽可能最好地利用各种可用的故障修复方法，同时确保一次只允许一种修复机制修复任何给定的故障。
Interactions between, for example, fast reroute mechanisms at Layer 3 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/ SDH) repair at Layer 1 are highly undesirable and are likely to cause problems in the network.
例如，第3层的快速重路由机制与第1层的同步光网络/同步数字体系（SONET/SDH）修复之间的交互是非常不可取的，并且可能在网络中引起问题。
R(24) Where a network topology and routing system contains multiple fault repair mechanisms, the responses of these systems to a detected failure should be coordinated so that the fault is repaired by the most appropriate means, and no extra repairs are initiated.
R（24）如果网络拓扑和路由系统包含多个故障修复机制，则应协调这些系统对检测到的故障的响应，以便通过最合适的方式修复故障，并且不启动额外的修复。
R(25) Where specialized packet exchange mechanisms (e.g., Layer 3 keepalive or "hello" protocol mechanisms) are used to detect failures, the routing system must allow the configuration of the rate of transmission of these keepalives. This must include the capability to turn them off altogether for links that are deliberately broken when no real user or control traffic is present (e.g., ISDN links).
R（25）如果使用专门的数据包交换机制（例如，第3层keepalive或“hello”协议机制）来检测故障，则路由系统必须允许配置这些keepalive的传输速率。这必须包括在不存在实际用户或控制流量（例如ISDN链路）的情况下，对故意断开的链路完全关闭它们的能力。
This will allow the operator to compromise between the speed of failure detection and the proportion of link bandwidth dedicated to failure detection.
这将允许运营商在故障检测速度和专用于故障检测的链路带宽比例之间进行折衷。
R(26) The routing system must support a mix of different kinds of addresses.
R（26）路由系统必须支持不同类型地址的混合。
This mix will include at least IPv4 and IPv6 addresses, and preferably various types of non-IP addresses, too. For instance, networks like SDH/SONET and Wavelength Division Multiplexing (WDM) may prefer to use non-IP addresses. It may also be necessary to support multiple sets of "private" (e.g., RFC 1918) addresses when dealing with multiple customer VPNs.
这种混合将至少包括IPv4和IPv6地址，最好也包括各种类型的非IP地址。例如，像SDH/SONET和波分复用（WDM）这样的网络可能更喜欢使用非IP地址。在处理多个客户VPN时，可能还需要支持多组“专用”（例如RFC 1918）地址。
R(27) The routing system should support the use of a single topology representation to generate routing and forwarding tables for multiple address families on the same network.
R（27）路由系统应支持使用单一拓扑表示为同一网络上的多个地址族生成路由和转发表。
This capability would minimize the protocol overhead when exchanging routes.
此功能将使交换路由时的协议开销最小化。
R(28) If a domain is subject to address reassignment that would cause forwarding interruption, then the routing system should support readdressing (e.g., when a new prefix is given to an old network, and the change is known in advance) by maintaining routing during the changeover period [RFC2071] [RFC2072].
R（28）如果域受到地址重新分配的影响，这将导致转发中断，那么路由系统应该通过在切换期间维护路由[RFC2071][RFC2072]来支持重新调整（例如，当一个新的前缀被赋予一个旧的网络时，并且改变是预先知道的）。
R(29) The routing system must support multicast addressing, both within a domain and across multiple domains.
R（29）路由系统必须支持域内和跨多个域的多播寻址。
R(30) The routing system should support anycast addressing within a domain. The routing system may support anycast addressing across domains.
R（30）路由系统应支持域内的选播寻址。路由系统可以支持跨域的选播寻址。
An open question is whether it is possible or useful to support anycast addressing between cooperating domains.
一个悬而未决的问题是，支持协作域之间的选播寻址是否可能或有用。
R(31) The routing system must support scoping of unicast addresses, and it should support scoping of multicast and anycast address types.
R（31）路由系统必须支持单播地址的作用域，并且应该支持多播和选播地址类型的作用域。
The unicast address scoping that is being designed for IPv6 does not seem to cause any special problems for routing. IPv6 inter-domain routing handles only IPv6 global addresses, while intra-domain routing also needs to be aware of the scope of private addresses.
为IPv6设计的单播地址范围似乎不会对路由造成任何特殊问题。IPv6域间路由仅处理IPv6全局地址，而域内路由还需要了解专用地址的范围。
Editors' Note: the original reference was to site-local addresses, but these have been deprecated by the IETF. Link-local addresses are never routed at all.
编者注：最初引用的是站点本地地址，但IETF已不推荐使用这些地址。链路本地地址永远不会路由。
More study may be needed to identify the requirements and solutions for scoping in a more general sense and for scoping of multicast and anycast addresses.
可能需要进行更多的研究，以确定更一般意义上的范围界定以及多播和选播地址范围界定的要求和解决方案。
R(32) The routing system must support system mobility. The term "system" includes anything from an end system to an entire domain.
R（32）路由系统必须支持系统移动性。术语“系统”包括从终端系统到整个域的任何内容。
We observe that the existing solutions based on renumbering and/or tunneling are designed to work with the current routing, so they do not add any new requirements to future routing. But the requirement is general, and future solutions may not be restricted to the ones we have today.
我们观察到，基于重新编号和/或隧道的现有解决方案设计用于当前路由，因此不会对未来路由添加任何新要求。但这一要求是普遍的，未来的解决方案可能并不局限于我们今天拥有的解决方案。
R(33) Both the routing and forwarding parts of the routing system must maintain statistical information about the performance of their functions.
R（33）路由系统的路由和转发部分都必须维护有关其功能性能的统计信息。
While the tools of management are outside the scope of routing, the mechanisms to support the routing architecture and protocols are within scope.
虽然管理工具不在路由范围内，但支持路由体系结构和协议的机制也在范围内。
R(34) Mechanisms to support Operational, Administrative, and Management control of the routing architecture and protocols must be designed into the original fabric of the architecture.
R（34）支持路由架构和协议的操作、管理和管理控制的机制必须设计到架构的原始结构中。
The basic aims of this specification are:
本规范的基本目标是：
- to require less manual configuration than today, and
- 需要比现在更少的手动配置，以及
- to satisfy the requirements for both easy handling and maximum control. That is:
- 以满足易于操作和最大控制的要求。即:
- All the information should be available,
- 所有信息都应可用，
- but should not be visible except for when necessary.
- 但除非必要，否则不应可见。
- Policies themselves should be advertised and not only the result of policy, and
- 应宣传政策本身，而不仅仅是政策的结果，以及
- policy-conflict resolution must be provided.
- 必须提供政策冲突解决方案。
R(35) The routing system must provide management of the system by means of policies. For example, policies that can be expressed in terms of the business and services implemented on the network and reflect the operation of the network in terms of the services affected.
R（35）路由系统必须通过策略提供对系统的管理。例如，可以根据网络上实施的业务和服务来表示的策略，并根据受影响的服务反映网络的运行。
Editors' Note: This requirement is optimistic in that it implies that it is possible to get operators to cooperate even if it is seen by them to be against their business practices.
编者按：这一要求是乐观的，因为它意味着即使运营商认为这违反了他们的商业惯例，也有可能让他们合作。
R(36) The distribution of policies must be amenable to scoping to protect proprietary policies that are not relevant beyond the local set of domains.
R（36）策略的分发必须服从范围界定，以保护在本地域集合之外不相关的专有策略。
A major problem in today's networks is the need to perform initial configuration on routers from a local interface before a remote management system can take over. It is not clear that this imposes any requirements on the routing architecture beyond what is needed for a ZeroConf host.
当今网络中的一个主要问题是，在远程管理系统接管之前，需要从本地接口对路由器执行初始配置。除了ZeroConf主机所需的功能外，这是否对路由体系结构提出了任何要求尚不清楚。
Similarly, maintenance and upgrade of routers can cause major disruptions to the network routing because the routing system and management of routers is not organized to minimize such disruption. Some improvements have been made, such as graceful restart mechanisms in protocols, but more needs to be done.
类似地，路由器的维护和升级可能会对网络路由造成重大干扰，因为路由系统和路由器的管理没有组织起来以尽量减少此类干扰。已经做了一些改进，例如协议中的优雅重启机制，但还需要做更多的工作。
R(37) The routing system and routers should provide mechanisms that minimize the disruption to the network caused by maintenance and upgrades of software and hardware. This requirement recognizes that some of the capabilities needed are outside the scope of the routing architecture (e.g., minimum impact software upgrade).
R（37）路由系统和路由器应提供将软件和硬件的维护和升级对网络造成的中断降至最低的机制。该要求认识到所需的某些功能不在路由体系结构的范围内（例如，影响最小的软件升级）。
R(38) The routing system and its component protocols must be demonstrated to be locally convergent under the permitted range of parameter settings and policy options that the operator(s) can select.
R（38）必须证明路由系统及其组件协议在操作员可选择的允许参数设置和策略选项范围内是局部收敛的。
There are various methods for demonstration and proof that include, but are not limited to: mathematical proof, heuristic, and pattern recognition. No requirement is made on the method used for demonstrating local convergence properties.
演示和证明有多种方法，包括但不限于：数学证明、启发式和模式识别。对用于证明局部收敛性的方法没有要求。
R(39) Routing protocols employed by the routing system and the overall routing system should be resistant to bad routing policy decisions made by operators.
路由系统和整个路由系统采用的R（39）路由协议应能抵抗运营商做出的错误路由策略决策。
Tools are needed to check compatibility of routing policies. While these tools are not part of the routing architecture, the mechanisms to support such tools are.
需要工具来检查路由策略的兼容性。虽然这些工具不是路由体系结构的一部分，但支持这些工具的机制是。
Routing policies are compatible if their interaction does not cause instability. A domain or group of domains in a system is defined as being convergent, either locally or globally, if and only if, after an exchange of routing information, routing tables reach a stable state that does not change until the routing policies or the topology changes again.
如果路由策略的交互不会导致不稳定，则它们是兼容的。系统中的一个域或一组域被定义为局部收敛或全局收敛，当且仅当路由表在交换路由信息后达到稳定状态，直到路由策略或拓扑再次改变时才会改变。
To achieve the above-mentioned goals:
为实现上述目标：
R(40) The routing system must provide a mechanism to publish and communicate policies so that operational coordination and fault isolation are possible.
R（40）路由系统必须提供发布和通信策略的机制，以便能够进行操作协调和故障隔离。
Tools are required that verify the stability characteristics of the routing system in specified parts of the Internet. The tools should be efficient (fast) and have a broad scope of operation (check large portions of Internet). While these tools are not part of the architecture, developing them is in the interest of the architecture and should be defined as a Routing Research Group activity while research on the architecture is in progress.
需要使用工具来验证Internet指定部分中路由系统的稳定性特征。这些工具应该是高效的（快速的），并且具有广泛的操作范围（检查互联网的大部分）。虽然这些工具不是体系结构的一部分，但开发它们符合体系结构的利益，并且应该在体系结构研究进行中定义为路由研究组的活动。
Tools analyzing routing policies can be applied statically or (preferably) dynamically. A dynamic solution requires tools that can be used for run time checking for oscillations that arise from policy conflicts. Research is needed to find an efficient solution to the dynamic checking of oscillations.
分析路由策略的工具可以静态应用，也可以（最好）动态应用。动态解决方案需要可用于运行时检查策略冲突引起的振荡的工具。需要进行研究，以找到一种有效的解决方案来动态检查振动。
The ability to do traffic engineering and to get the feedback from the network to enable traffic engineering should be included in the future domain architecture. Though traffic engineering has many definitions, it is, at base, another alternative or extension for the path selection mechanisms of the routing system. No fundamental changes to the requirements are needed, but the iterative processes involved in traffic engineering may require some additional capabilities and state in the network.
在未来的领域架构中，应包括进行流量工程和从网络获得反馈以实现流量工程的能力。虽然流量工程有很多定义，但它基本上是路由系统路径选择机制的另一种选择或扩展。不需要对需求进行根本性的更改，但流量工程中涉及的迭代过程可能需要网络中的一些附加功能和状态。
Traffic engineering typically involves a combination of off-line network planning and administrative control functions in which the expected and measured traffic flows are examined, resulting in changes to static configurations and policies in the routing system.
流量工程通常涉及离线网络规划和管理控制功能的组合，其中检查预期和测量的流量，从而改变路由系统中的静态配置和策略。
During operations, these configurations control the actual flow of traffic and affect the dynamic path selection mechanisms; the results are measured and fed back into further rounds of network planning.
在操作期间，这些配置控制实际的交通流，并影响动态路径选择机制；测量结果并反馈到下一轮网络规划中。
At present, there is an almost total lack of effective traffic engineering tools, whether in real time for network control or off-line for network planning. The routing system should encourage the provision of such tools.
目前，几乎完全缺乏有效的流量工程工具，无论是用于网络控制的实时工具还是用于网络规划的离线工具。路由系统应鼓励提供此类工具。
R(41) The routing system must generate statistical and accounting information in such a way that traffic engineering and network planning tools can be used in both real-time and off-line planning and management.
R（41）路由系统必须生成统计和会计信息，以便流量工程和网络规划工具可用于实时和离线规划和管理。
R(42) The routing system must support the controlled distribution over multiple links or paths of traffic toward the same destination. This applies to domains with two or more connections to the same neighbor domain, and to domains with connections to more than one neighbor domain. The paths need not have the same metric.
R（42）路由系统必须支持通过多个链路或通向同一目的地的业务路径的受控分布。这适用于与同一邻居域有两个或多个连接的域，以及与多个邻居域有连接的域。路径不必具有相同的度量。
R(43) The routing system must support forwarding over multiple parallel paths when available. This support should extend to cases where the offered traffic is known to exceed the available capacity of a single link, and to the cases where load is to be shared over paths for cost or resiliency reasons.
R（43）当可用时，路由系统必须支持通过多个并行路径进行转发。这种支持应该扩展到已知提供的流量超过单个链路的可用容量的情况，以及出于成本或弹性原因通过路径共享负载的情况。
R(44) Where traffic is forwarded over multiple parallel paths, the routing system must, so far as is possible, avoid the reordering of packets in individual micro-flows.
R（44）在多条并行路径上转发业务的情况下，路由系统必须尽可能避免在单个微流中重新排序数据包。
R(45) The routing system must have mechanisms to allow the traffic to be reallocated back onto a single path when multiple paths are not needed.
R（45）当不需要多条路径时，路由系统必须具有允许流量重新分配回单个路径的机制。
R(46) The routing system must support peer-level connectivity as well as hierarchical connections between domains.
R（46）路由系统必须支持对等级连接以及域之间的分层连接。
The network is becoming increasingly complex, with private peering arrangements set up between providers at every level of the hierarchy of service providers and even by certain large enterprises, in the form of dedicated extranets.
该网络正变得越来越复杂，在服务提供商的每一层级的提供商之间，甚至由某些大型企业以专用外联网的形式建立了私有对等安排。
R(47) The routing system must facilitate traffic engineering of peer routes so that traffic can be readily constrained to travel as the network operators desire, allowing optimal use of the available connectivity.
R（47）路由系统必须有助于对等路由的流量工程，以便流量可以根据网络运营商的需要随时限制在移动范围内，从而实现可用连接的最佳利用。
One of our assumptions is that NATs and other middle-boxes such as firewalls, web proxies, and address family translators (e.g., IPv4 to IPv6) are here to stay.
我们的一个假设是NAT和其他中间设备，如防火墙、web代理和地址族转换器（如IPv4到IPv6）将继续存在。
R(48) The routing system should work in conjunction with middle-boxes, e.g., NAT, to aid in bi-directional connectivity without compromising the additional opacity and privacy that the middle-boxes offer.
R（48）路由系统应与中间盒（如NAT）一起工作，以帮助实现双向连接，而不损害中间盒提供的额外不透明性和隐私。
This problem is closely analogous to the abstraction problem, which is already under discussion for the interchange of routing information between domains.
这个问题与抽象问题非常相似，抽象问题已经在讨论域之间的路由信息交换。
Over the past several years, the performance of the routing system has frequently been discussed. The requirements that derive from those discussions are listed below. The specific values for these performance requirements are left for further discussion.
在过去的几年中，路由系统的性能经常被讨论。下面列出了从这些讨论中得出的要求。这些性能要求的具体值留待进一步讨论。
R(49) The routing system must support domains of at least N systems. A system is taken to mean either an individual router or a domain.
R（49）路由系统必须支持至少N个系统的域。系统是指单个路由器或域。
R(50) Local convergence should occur within T units of time.
R（50）局部收敛应在T个时间单位内发生。
R(51) The routing system must be measurably reliable. The measure of reliability remains a research question.
R（51）路由系统必须是可测量的可靠的。可靠性的度量仍然是一个研究问题。
R(52) The routing system must be locally stable to a measured degree. The degree of measurability remains a research issue.
R（52）路由系统必须在一定程度上保持局部稳定。可测量的程度仍然是一个研究问题。
R(53) The routing system must be globally stable to a measured degree. The degree of measurability remains a research issue.
R（53）路由系统必须在一定程度上是全局稳定的。可测量的程度仍然是一个研究问题。
R(54) The routing system should scale to an indefinitely large number of domains.
R（54）路由系统应扩展到无限多个域。
There has been very little data or statistical evidence for many of the performance claims made in the past. In recent years, several efforts have been initiated to gather data and do the analyses required to make scientific assessments of performance issues and requirements. In order to complete this section of the requirements analysis, the data and analyses from these studies needs to be gathered and collated into this document. This work has been started but has yet to be completed.
对于过去提出的许多性能要求，几乎没有数据或统计证据。近年来，已经开展了几项工作来收集数据并进行必要的分析，以便对性能问题和要求进行科学评估。为了完成本节的需求分析，需要收集这些研究中的数据和分析，并整理到本文档中。这项工作已经开始，但尚未完成。
Editors' Note: This work was never completed due to corporate reorganizations.
编者按：由于公司重组，这项工作从未完成。
This area poses a dilemma. On one hand, it is an absolute requirement that:
这一领域造成了一个两难局面。一方面，绝对要求：
R(55) The introduction of the routing system must not require any flag days.
R（55）引入路由系统不得要求任何卖旗日。
R(56) The network currently in place must continue to run at least as well as it does now while the new network is being installed around it.
R（56）当新网络安装在其周围时，当前的网络必须至少像现在一样继续运行。
However, at the same time, it is also an requirement that:
但是，同时，还要求：
R(57) The new architecture must not be limited by the restrictions that plague today's network.
R（57）新的体系结构不能受到困扰当今网络的限制。
It has to be admitted that R(57) is not a well-defined requirement, because we have not fully articulated what the restrictions might be. Some of these restrictions can be derived by reading the discussions for the positive requirements above. It would be a useful exercise to explicitly list all the restrictions and irritations with which we wish to do away. Further, it would be useful to determine if these restrictions can currently be removed at a reasonable cost or whether we are actually condemned to live with them.
必须承认，R（57）不是一个定义明确的要求，因为我们还没有完全阐明限制可能是什么。通过阅读上述积极需求的讨论，可以得出其中一些限制。明确列出我们希望消除的所有限制和刺激是一种有益的做法。此外，确定目前是否可以以合理的成本取消这些限制，或者我们是否真的被迫接受这些限制，将是有益的。
Those restrictions cannot be allowed to become permanent baggage on the new architecture. If they do, the effort to create a new system will come to naught. It may, however, be necessary to live with some of them temporarily for practical reasons while providing an architecture that will eventually allow them to be removed. The last three requirements have significance not only for the transition
不能允许这些限制成为新架构的永久包袱。如果他们这样做，创建新系统的努力将付诸东流。然而，出于实际原因，可能有必要暂时与其中一些人住在一起，同时提供一个最终允许他们被移除的架构。最后三项要求不仅对过渡具有重要意义
strategy but also for the architecture itself. They imply that it must be possible for an internet such as today's BGP-controlled network, or one of its ASs, to exist as a domain within the new FDR.
战略，但也为架构本身。它们意味着，像今天的BGP控制网络这样的互联网，或者说它的ASs，在新的FDR中作为一个域存在是可能的。
As previously discussed, one of the major changes that has overtaken the Internet since its inception is the erosion of trust between end users making use of the net, between those users and the suppliers of services, and between the multiplicity of providers. Hence, security, in all its aspects, will be much more important in the FDR.
如前所述，互联网自诞生以来所发生的一个重大变化是使用网络的最终用户之间、这些用户与服务供应商之间以及众多供应商之间的信任度下降。因此，安全在所有方面都将在罗斯福中更加重要。
It must be possible to secure the routing communication.
必须能够确保路由通信的安全。
R(58) The communicating entities must be able to identify who sent and who received the information (authentication).
R（58）通信实体必须能够识别谁发送和谁接收信息（认证）。
R(59) The communicating entities must be able to verify that the information has not been changed on the way (integrity).
R（59）通信实体必须能够验证信息在途中没有改变（完整性）。
Security is more important in inter-domain routing where the operator has no control over the other domains, than in intra-domain routing where all the links and the nodes are under the administration of the operator and can be expected to share a trust relationship. This property of intra-domain trust, however, should not be taken for granted:
在域间路由中，安全性比在域内路由中更重要，在域间路由中，运营商对其他域没有控制权，而在域内路由中，所有链路和节点都由运营商管理，并且可以预期共享信任关系。但是，域内信任的这一属性不应被视为理所当然：
R(60) Routing communications must be secured by default, but an operator must have the option to relax this requirement within a domain where analysis indicates that other means (such as physical security) provide an acceptable alternative.
R（60）路由通信在默认情况下必须是安全的，但运营商必须有权在分析表明其他手段（如物理安全）提供可接受替代方案的领域内放宽这一要求。
R(61) The routing communication mechanism must be robust against denial-of-service attacks.
R（61）路由通信机制必须对拒绝服务攻击具有鲁棒性。
R(62) It should be possible to verify that the originator of the information was authorized to generate the information.
R（62）应能够验证信息的发起人是否有权生成信息。
Further considerations that may impose further requirements include:
可能提出进一步要求的进一步考虑包括：
- whether no one else but the intended recipient is able to access (privacy) or understand (confidentiality) the information,
- 除预期接收人外，其他任何人是否能够访问（隐私）或理解（保密）信息，
- whether it is possible to verify that all the information has been received and that the two parties agree on what was sent (validation and non-repudiation),
- 是否有可能验证是否已收到所有信息，以及双方是否同意发送的信息（验证和不可否认），
- whether there is a need to separate security of routing from security of forwarding, and
- 是否需要将路由安全性与转发安全性分开，以及
- whether traffic flow security is needed (i.e., whether there is value in concealing who can connect to whom, and what volumes of data are exchanged).
- 是否需要交通流安全（即，隐藏谁可以连接谁以及交换的数据量是否有价值）。
Securing the BGP session, as done today, only secures the exchange of messages from the peering domain, not the content of the information. In other words, we can confirm that the information we got is what our neighbor really sent us, but we do not know whether or not this information (that originated in some remote domain) is true.
正如今天所做的那样，保护BGP会话只保护来自对等域的消息交换，而不保护信息内容。换句话说，我们可以确认我们得到的信息是邻居真正发送给我们的，但我们不知道这些信息（源自某个远程域）是否真实。
A decision has to be made on whether to rely on chains of trust (we trust our peers who trust their peers who..), or whether we also need authentication and integrity of the information end-to-end. This information includes both routes and addresses. There has been interest in having digital signatures on originated routes as well as countersignatures by address authorities to confirm that the originator has authority to advertise the prefix. Even understanding who can confirm the authority is non-trivial, as it might be the provider who delegated the prefix (with a whole chain of authority back to ICANN) or it may be an address registry. Where a prefix delegated by a provider is being advertised through another provider as in multi-homing, both may have to be involved to confirm that the prefix may be advertised through the provider who doesn't have any interest in the prefix!
必须决定是否依赖信任链（我们信任那些信任他们的同行的同行，他们…），或者我们是否还需要端到端的信息验证和完整性。此信息包括路由和地址。人们一直有兴趣在始发路线上进行数字签名，并由地址当局进行会签，以确认始发人有权公布前缀。即使了解谁可以确认权限也不是小事，因为可能是提供商授权了前缀（将整个权限链返还给ICANN），也可能是地址注册。如果一个提供者委托的前缀通过另一个提供者（如在多主定位中）进行广告，则两者都必须参与，以确认前缀可以通过对前缀不感兴趣的提供者进行广告！
R(63) The routing system must cooperate with the security policies of middle-boxes whenever possible.
R（63）路由系统必须尽可能配合中间盒的安全策略。
This is likely to involve further requirements for abstraction of information. For example, a firewall that is seeking to minimize interchange of information that could lead to a security breach. The effect of such changes on the end-to-end principle should be carefully considered as discussed in [Blumenthal01].
这可能涉及对信息抽象的进一步要求。例如，试图最小化可能导致安全漏洞的信息交换的防火墙。如[Blumenthal01]所述，应仔细考虑此类变更对端到端原则的影响。
R(64) The routing system must be capable of complying with local legal requirements for interception of communication.
R（64）路由系统必须能够遵守当地有关截取通信的法律要求。
This section covers issues that need to be considered and resolved in deciding on a Future Domain Routing architecture. While they can't be described as requirements, they do affect the types of solution that are acceptable. The discussions included below are very open-ended.
本节介绍在决定未来的域路由体系结构时需要考虑和解决的问题。虽然它们不能被描述为需求，但它们确实会影响可接受的解决方案类型。下面的讨论是非常开放的。
The mathematical model that underlies today's routing system uses a graph representation of the network. Hosts, routers, and other processing boxes are represented by nodes and communications links by arcs. This is a topological model in that routing does not need to directly model the physical length of the links or the position of the nodes; the model can be transformed to provide a convenient picture of the network by adjusting the lengths of the arcs and the layout of the nodes. The connectivity is preserved and routing is unaffected by this transformation.
当今路由系统的数学模型使用网络的图形表示。主机、路由器和其他处理盒由节点表示，通信链路由弧表示。这是一种拓扑模型，因为路由不需要直接建模链路的物理长度或节点的位置；通过调整弧的长度和节点的布局，可以对模型进行转换，以提供网络的方便图片。连接被保留，路由不受此转换的影响。
The routing algorithms in traditional routing protocols utilize a small number of results from graph theory. It is only recently that additional results have been employed to support constraint-based routing for traffic engineering.
传统路由协议中的路由算法利用了少量图论的结果。直到最近，才有更多的结果被用于支持交通工程中基于约束的路由。
The naturalness of this network model and the "fit" of the graph theoretical methods may have tended to blind us to alternative representations and inhibited us from seeking alternative strands of theoretical thinking that might provide improved results.
这种网络模型的自然性和图论方法的“契合性”可能会使我们看不到替代性表示，并阻止我们寻找可能提供改进结果的替代性理论思维。
We should not allow this habitual behavior to stop us from looking for alternative representations and algorithms; topological revolutions are possible and allowed, at least in theory.
我们不应该让这种习惯性行为阻止我们寻找替代的表达和算法；拓扑革命是可能的，也是允许的，至少在理论上是如此。
The assumption that object modeling of a system is an essential first step to creating a new system is still novel in this context. Frequently, the object modeling effort becomes an end in itself and does not lead to system creation. But there is a balance, and a lot that can be discovered in an ongoing effort to model a system such as the Future Domain Routing system. It is recommended that this process be included in the requirements. It should not, however, be a gating event to all other work.
在这种情况下，系统的对象建模是创建新系统必不可少的第一步的假设仍然是新颖的。通常，对象建模工作本身就是目的，不会导致系统创建。但是，在对一个系统（如未来的域路由系统）进行建模的过程中，有一个平衡点，可以发现很多东西。建议将该过程包括在要求中。然而，它不应该成为所有其他工作的门控事件。
Some of the most important realizations will occur during the process of determining the following:
在确定以下各项的过程中，将出现一些最重要的实现：
- Object classification
- 对象分类
- Relationships and containment
- 关系与遏制
- Roles and Rules
- 角色和规则
There has been a lot of discussion of whether the FDR protocol solution should consist of one (probably new) protocol, two (intra-and inter-domain) protocols, or many protocols. While it might be best to have one protocol that handles all situations, this seems improbable. On the other hand, maintaining the "strict" division evident in the network today between the IGP and EGP may be too restrictive an approach. Given this, and the fact that there are already many routing protocols in use, the only possible answer seems to be that the architecture should support many protocols. It remains an open issue, one for the solution, to determine if a new protocol needs to be designed in order to support the highest goals of this architecture. The expectation is that a new protocol will be needed.
关于FDR协议解决方案应该由一个（可能是新的）协议、两个（域内和域间）协议还是多个协议组成，已经有很多讨论。虽然最好有一个协议来处理所有情况，但这似乎是不可能的。另一方面，维持目前网络中IGP和EGP之间明显的“严格”划分可能是一种限制性太强的做法。考虑到这一点，并且已经有许多路由协议在使用，唯一可能的答案似乎是该体系结构应该支持许多协议。确定是否需要设计一个新的协议以支持此体系结构的最高目标仍然是一个悬而未决的问题，也是解决方案的问题。人们的期望是需要一个新的协议。
If a new protocol is required to support the FDR architecture, the question remains open as to what kind of protocol this ought to be. It is our expectation that a map distribution protocol will be required to augment the current path-vector protocol and shortest path first protocols.
如果需要一个新的协议来支持FDR体系结构，那么应该是哪种协议的问题仍然悬而未决。我们期望，将需要map分发协议来扩充当前路径向量协议和最短路径优先协议。
Assuming that a map distribution protocol, as defined in [RFC1992] is required, what are the requirements on this protocol? If every detail is advertised throughout the Internet, there will be a lot of information. Scalable solutions require abstraction.
假设需要[RFC1992]中定义的map分发协议，该协议的要求是什么？如果每一个细节都在互联网上公布，将会有很多信息。可伸缩的解决方案需要抽象。
- If we summarize too much, some information will be lost on the way.
- 如果我们总结得太多，一些信息会在途中丢失。
- If we summarize too little, then more information than required is available, contributing to scaling limitations.
- 如果我们总结得太少，那么就可以获得比所需更多的信息，从而导致伸缩限制。
- One can allow more summarization, if there also is a mechanism to query for more details within policy limits.
- 如果还有一种在策略限制内查询更多详细信息的机制，则可以允许更多摘要。
- The basic requirement is not that the information shall be advertised, but rather that the information shall be available to those who need it. We should not presuppose a solution where advertising is the only possible mechanism.
- 基本要求不是要公布信息，而是向需要的人提供信息。我们不应该预设一个解决方案，即广告是唯一可能的机制。
As in all other fields, the words used to refer to concepts and to describe operations about routing are important. Rather than describe concepts using terms that are inaccurate or rarely used in the real world of networking, it is necessary to make an effort to use the correct words. Many networking terms are used casually, and the result is a partial or incorrect understanding of the underlying concept. Entities such as nodes, interfaces, subnetworks, tunnels, and the grouping concepts such as ASs, domains, areas, and regions, need to be clearly identified and defined to avoid confusion.
与所有其他领域一样，用于指代路由概念和描述路由操作的词语非常重要。与其使用不准确或在现实网络世界中很少使用的术语来描述概念，不如努力使用正确的词语。许多网络术语被随意使用，其结果是对基本概念的部分或不正确理解。节点、接口、子网、隧道等实体以及ASs、域、区域和区域等分组概念需要明确标识和定义，以避免混淆。
There is also a need to separate identifiers (what or who) from locators (where) from routes (how to reach).
还需要将标识符（什么或谁）与定位器（何处）和路线（如何到达）分开。
Editors' Note: Work was undertaken in the shim6 working group of the IETF on this sort of separation. This work needs to be taken into account in any new routing architecture.
编者注：IETF的shim6工作组就这种分离进行了工作。这项工作需要在任何新的路由架构中加以考虑。
The routing association between two domains should survive even if some individual connection between two routers goes down.
即使两个路由器之间的某个单独连接中断，两个域之间的路由关联也应该存在。
The "session" should operate between logical "routing entities" on each domain side, and not necessarily be bound to individual routers or addresses. Such a logical entity can be physically distributed over multiple network elements. Or, it can reside in a single router, which would default to the current situation.
“会话”应在每个域侧的逻辑“路由实体”之间运行，而不必绑定到单个路由器或地址。这样的逻辑实体可以物理上分布在多个网元上。或者，它可以驻留在单个路由器中，这将默认为当前情况。
A more flexible hierarchy with more levels and recursive groupings in both upward and downward directions allows more structured routing. The consequence is that no single level will get too big for routers to handle.
更灵活的层次结构（具有更多级别）和向上和向下的递归分组允许更结构化的路由。其结果是，没有一个级别会变得太大，路由器无法处理。
On the other hand, it appears that the real-world Internet is becoming less hierarchical, so that it will be increasingly difficult to use hierarchy to control scaling.
另一方面，现实世界的互联网似乎越来越没有层次性，因此越来越难以使用层次结构来控制规模。
Note that groupings can look different depending on which aspect we use to define them. A Diffserv area, an MPLS domain, a trusted domain, a QoS area, a multicast domain, etc., do not always coincide; nor are they strict hierarchical subsets of each other. The basic distinction at each level is "this grouping versus everything outside".
请注意，分组的外观可能会有所不同，这取决于我们用来定义分组的方面。区分服务区域、MPLS域、可信域、QoS区域、多播域等并不总是一致的；它们之间也不是严格的层次子集。每个级别的基本区别是“这种分组与外部的一切”。
Is it possible to apply a control theory framework to analyze the stability of the control system of the whole network domain, with regard to, e.g., convergence speed and the frequency response, and then use the results from that analysis to set the timers and other protocol parameters?
是否可以应用控制理论框架来分析整个网络域控制系统的稳定性，例如收敛速度和频率响应，然后使用分析结果来设置定时器和其他协议参数？
Control theory could also play a part in QoS routing, by modifying current link-state protocols with link costs dependent on load and feedback. Control theory is often used to increase the stability of dynamic systems.
控制理论也可以在QoS路由中发挥作用，通过修改当前的链路状态协议，使链路成本取决于负载和反馈。控制理论常被用来提高动态系统的稳定性。
It might be possible to construct a new, totally dynamic routing protocol solely on a control theoretic basis, as opposed to the current protocols that are based in graph theory and static in nature.
与当前基于图论和静态的协议不同，完全基于控制论的基础上构建一个新的、完全动态的路由协议是可能的。
Is solving the Byzantine Generals problem a requirement? This is the problem of reaching a consensus among distributed units if some of them give misleading answers. The current intra-domain routing system is, at one level, totally intolerant of misleading information. However, the effect of different sorts of misleading or incorrect information has vastly varying results, from total collapse to purely local disconnection of a single domain. This sort of behavior is not very desirable.
解决拜占庭将军问题是一项要求吗？这是分布式单位之间达成共识的问题，如果其中一些单位给出了误导性的答案。目前的域内路由系统在某种程度上完全不能容忍误导性信息。然而，不同类型的误导性或不正确信息的影响有着千差万别的结果，从整体崩溃到单一领域的纯粹局部断开。这种行为不太可取。
There are, possibly, other network robustness issues that must be researched and resolved.
可能还有其他必须研究和解决的网络健壮性问题。
Today, BGP is also used for VPNs, for example, as described in RFC 4364 [RFC4364].
今天，BGP也用于VPN，例如，如RFC 4364[RFC4364]中所述。
Internet routing and VPN routing have different purposes and most often exchange different information between different devices. Most Internet routers do not need to know VPN-specific information. The concepts should be clearly separated.
Internet路由和VPN路由有不同的用途，通常在不同的设备之间交换不同的信息。大多数Internet路由器不需要知道VPN特定的信息。这些概念应该明确分开。
But when it comes to the mechanisms, VPN routing can share the same protocol as ordinary Internet routing; it can use a separate instance of the same protocol or it can use a different protocol. All variants are possible and have their own merits. These requirements are silent on this issue.
但就机制而言，VPN路由可以与普通Internet路由共享相同的协议；它可以使用同一协议的单独实例，也可以使用不同的协议。所有变体都是可能的，并且都有各自的优点。这些要求在这个问题上没有提及。
The existing Internet architecture neither requires nor provides end-to-end reliability of control information dissemination. There is, however, already a requirement for end-to-end reliability of control information distribution, i.e., the ends of the VPN established need to have an acknowledgment of the success in setting up the VPN. While it is not necessarily the function of a routing architecture to provide end-to-end reliability for this kind of purpose, we must be clear that end-to-end reliability becomes a requirement if the network has to support such reliable control signaling. There may be other requirements that derive from requiring the FDR to support reliable control signaling.
现有的互联网架构既不要求也不提供控制信息传播的端到端可靠性。然而，已经存在对控制信息分布的端到端可靠性的要求，即，所建立的VPN的端部需要具有成功建立VPN的确认。虽然为这种目的提供端到端可靠性不一定是路由体系结构的功能，但我们必须清楚，如果网络必须支持这种可靠的控制信令，则端到端可靠性成为一项要求。要求FDR支持可靠的控制信令可能会产生其他要求。
The introduction of private addressing schemes, Network Address Translators, and firewalls has significantly reduced the end-to-end transparency of the network. In many cases, the network is also no longer symmetric, so that communication between two addresses is possible if the communication session originates from one end but not from the other. This impedes the deployment of new peer-to-peer services and some "push" services where the server in a client-server arrangement originates the communication session. Whether a new routing system either can or should seek to restore this transparency is an open issue.
私有寻址方案、网络地址转换器和防火墙的引入大大降低了网络的端到端透明度。在许多情况下，网络也不再是对称的，因此，如果通信会话来自一端而不是另一端，则两个地址之间的通信是可能的。这妨碍了新的对等服务和一些“推送”服务的部署，其中客户端-服务器安排中的服务器发起通信会话。一个新的路由系统是否能够或应该寻求恢复这种透明度是一个悬而未决的问题。
A related issue is the extent to which end-user applications should seek to control the routing of communications to the rest of the network.
一个相关的问题是最终用户应用程序应在多大程度上控制到网络其余部分的通信路由。
We address security issues in the individual requirements. We do require that the architecture and protocols developed against this set of requirements be "secure". Discussion of specific security issues can be found in the following sections:
我们在单个需求中解决安全问题。我们确实要求针对这组需求开发的体系结构和协议是“安全的”。具体安全问题的讨论可在以下章节中找到：
o Group A: Routing System Security - Section 2.1.9
o A组：路由系统安全-第2.1.9节
o Group A: End Host Security - Section 2.1.10
o A组：终端主机安全-第2.1.10节
o Group A: Routing Information Policies - Section 2.1.11.1
o A组：路由信息策略-第2.1.11.1节
o Group A: Abstraction - Section 2.1.16
o A组：抽象-第2.1.16节
o Group A: Robustness - Section 2.1.18
o A组：稳健性-第2.1.18节
o Group B: Protection against Denial-of-Service and Other Security Attacks - Section 3.2.3.8
o B组：针对拒绝服务和其他安全攻击的保护-第3.2.3.8节
o Group B: Commercial Service Providers - Section 3.3.1.1
o B组：商业服务提供商-第3.3.1.1节
o Group B: The Federated Environment - Section 3.4.1
o B组：联邦环境-第3.4.1节
o Group B: Path Advertisement - Section 3.6.2.2
o B组：路径广告-第3.6.2.2节
o Group B: Security Requirements - Section 3.9
o B组：安全要求-第3.9节
This document is a set of requirements from which a new routing and addressing architecture may be developed. From that architecture, a new protocol, or set of protocols, may be developed.
本文档是一组需求，可根据这些需求开发新的路由和寻址体系结构。根据该体系结构，可以开发一个新的协议或一组协议。
While this note poses no new tasks for IANA, the architecture and protocols developed from this document probably will have issues to be dealt with by IANA.
虽然本说明没有为IANA提出新的任务，但根据本说明开发的体系结构和协议可能会有IANA需要解决的问题。
This document is the combined effort of two groups in the IRTF. Group A, which was formed by the IRTF Routing Research chairs, and Group B, which was self-formed and later was folded into the IRTF Routing Research Group. Each group has it own set of acknowledgments.
本文件是IRTF中两个小组的共同努力。A组由IRTF路由研究主席组成，B组由自行组成，后来被并入IRTF路由研究组。每个组都有自己的一组确认。
Group A Acknowledgments
A组确认
This originated in the IRTF Routing Research Group's sub-group on Inter-domain routing requirements. The members of the group were:
这起源于IRTF路由研究小组的域间路由需求小组。小组成员包括：
Abha Ahuja Danny McPherson J. Noel Chiappa David Meyer Sean Doran Mike O'Dell JJ Garcia-Luna-Aceves Andrew Partan Susan Hares Radia Perlman Geoff Huston Yakov Rehkter Frank Kastenholz John Scudder Dave Katz Curtis Villamizar Tony Li Dave Ward
阿哈·阿赫亚·丹尼·麦克弗森J.诺埃尔·奇帕·大卫·迈耶·肖恩·多兰·迈克·奥戴尔JJ·加西亚·卢纳·阿塞维斯·安德鲁·帕坦·苏珊·哈雷斯·拉迪亚·帕尔曼·杰夫·休斯顿·亚科夫康复中心弗兰克·卡斯滕霍尔兹·约翰·斯卡德尔·戴夫·卡茨·柯蒂斯·维拉米扎·托尼·李·戴夫·沃德
We also appreciate the comments and review received from Ran Atkinson, Howard Berkowitz, Randy Bush, Avri Doria, Jeffery Haas, Dmitri Krioukov, Russ White, and Alex Zinin. Special thanks to Yakov Rehkter for contributing text and to Noel Chiappa.
我们还感谢Ran Atkinson、Howard Berkowitz、Randy Bush、Avri Doria、Jeffery Haas、Dmitri Krioukov、Russ White和Alex Zinin的评论和评论。特别感谢亚科夫·雷克特对本文的贡献和诺埃尔·基亚帕。
Group B Acknowledgments
B组确认
The document is derived from work originally produced by Babylon. Babylon was a loose association of individuals from academia, service providers, and vendors whose goal was to discuss issues in Internet routing with the intention of finding solutions for those problems.
该文件来源于最初由巴比伦制作的作品。巴比伦是来自学术界、服务提供商和供应商的松散团体，他们的目标是讨论互联网路由问题，并为这些问题找到解决方案。
The individual members who contributed materially to this document are: Anders Bergsten, Howard Berkowitz, Malin Carlzon, Lenka Carr Motyckova, Elwyn Davies, Avri Doria, Pierre Fransson, Yong Jiang, Dmitri Krioukov, Tove Madsen, Olle Pers, and Olov Schelen.
对本文件作出重大贡献的个人成员有：安德斯·伯格斯滕、霍华德·伯克维茨、马林·卡尔松、伦卡·卡尔·莫蒂科娃、埃尔温·戴维斯、阿夫里·多里亚、皮埃尔·弗兰松、蒋勇、德米特里·克里乌科夫、托夫·马德森、奥勒·珀斯和奥洛夫·舍伦。
Thanks also go to the members of Babylon and others who did substantial reviews of this material. Specifically, we would like to acknowledge the helpful comments and suggestions of the following individuals: Loa Andersson, Tomas Ahlstrom, Erik Aman, Thomas Eriksson, Niklas Borg, Nigel Bragg, Thomas Chmara, Krister Edlund, Owe Grafford, Torbjorn Lundberg, Jeremy Mineweaser, Jasminko Mulahusic, Florian-Daniel Otel, Bernhard Stockman, Tom Worster, and Roberto Zamparo.
也要感谢巴比伦的成员和其他人，他们对这些材料做了大量的评论。具体而言，我们要感谢以下个人的有益意见和建议：洛亚·安德森、托马斯·艾尔斯特罗姆、埃里克·阿曼、托马斯·埃里克森、尼古拉斯·博格、奈杰尔·布拉格、托马斯·奇马拉、克里斯特·埃德隆德、奥夫·格拉福德、托尔比约恩·伦德伯格、杰里米·米韦瑟、贾斯明科·穆拉胡西奇、弗洛里安·丹尼尔·奥特尔、伯恩哈德·斯托克曼、汤姆·伍斯特、，还有罗伯托·赞帕罗。
In addition, the authors are indebted to the folks who wrote all the references we have consulted in putting this paper together. This includes not only the references explicitly listed below, but also those who contributed to the mailing lists we have been participating in for years.
此外，作者还要感谢那些撰写了我们在撰写本文时参考的所有参考文献的人。这不仅包括下面明确列出的参考资料，还包括那些对我们参与多年的邮件列表作出贡献的人。
The editors thank Lixia Zhang, as IRSG document shepherd, for her help and her perseverance, without which this document would never have been published.
编辑们感谢作为IRSG文件守护者的张丽霞，感谢她的帮助和毅力，没有这些，本文件将永远不会出版。
Finally, it is the editors who are responsible for any lack of clarity, any errors, glaring omissions or misunderstandings.
最后，编辑应对任何不清晰、错误、明显的遗漏或误解负责。
[Blumenthal01] Blumenthal, M. and D. Clark, "Rethinking the design of the Internet: The end to end arguments vs. the brave new world", May 2001, <http://dspace.mit.edu/handle/1721.1/1519>.
[Blumenthal01]Blumenthal，M.和D.Clark，“重新思考互联网的设计：端到端的争论与勇敢的新世界”，2001年5月<http://dspace.mit.edu/handle/1721.1/1519>.
[Broido02] Broido, A., Nemeth, E., Claffy, K., and C. Elves, "Internet Expansion, Refinement and Churn", February 2002.
[Broidoo2]Broido，A.，Nemeth，E.，Claffy，K.，和C.Elves，“互联网扩展，完善和搅动”，2002年2月。
[CIDR] Telcordia Technologies, "CIDR Report", <http://www.cidr-report.org/>.
[CIDR]Telcordia Technologies，“CIDR报告”<http://www.cidr-report.org/>.
[Chiappa02] Chiappa, N., "A New IP Routing and Addressing Architecture", July 1991, <http://ana-3.lcs.mit.edu/~jnc/nimrod/overview.txt>.
[Chiapa02]Chiapa，N.，“一种新的IP路由和寻址架构”，1991年7月<http://ana-3.lcs.mit.edu/~jnc/nimrod/overview.txt>。
[Clark91] Clark, D., "Quote reportedly from IETF Plenary discussion", 1991.
[Clark91]Clark，D.，“据报道引自IETF全体讨论”，1991年。
[DiffservAR] Seddigh, N., Nandy, B., and J. Heinanen, "An Assured Rate Per-Domain Behaviour for Differentiated Services", Work in Progress, July 2001.
[DiffservAR]Seddigh，N.，Nandy，B.，和J.Heinanen，“区分服务的每个域行为的保证速率”，正在进行的工作，2001年7月。
[DiffservVW] Jacobson, V., Nichols, K., and K. Poduri, "The 'Virtual Wire' Per-Domain Behavior", Work in Progress, July 2000.
[Diffservw]Jacobson，V.，Nichols，K.，和K.Poduri，“每个域的“虚拟线路”行为”，正在进行的工作，2000年7月。
[Griffin99] Griffin, T. and G. Wilfong, "An Analysis of BGP Convergence Properties", SIGCOMM 1999.
[Griffin 99]Griffin，T.和G.Wilfong，“BGP收敛性分析”，SIGCOMM 1999。
[ISO10747] ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs", International Standard 10747 ISO/IEC JTC 1, Switzerland, 1993.
[ISO10747]ISO/IEC，“支持ISO 8473 PDU转发的中间系统间域间路由信息交换协议”，国际标准10747 ISO/IEC JTC 1，瑞士，1993年。
[InferenceSRLG] Papadimitriou, D., Poppe, F., J. Jones, J., S. Venkatachalam, S., S. Dharanikota, S., Jain, R., Hartani, R., and D. Griffith, "Inference of Shared Risk Link Groups", Work in Progress, November 2001.
[推论SRLG]帕帕迪米特里欧，D.，波普，F.，J.琼斯，J.，S.文卡塔查兰，S.，S.达拉尼科塔，S.，杰恩，R.，哈塔尼，R.，和D.格里菲斯，“共享风险联系组的推论”，正在进行的工作，2001年11月。
[ODell01] O'Dell, M., "Private Communication", 2001.
[ODell01]O'Dell，M.，“私人通信”，2001年。
[RFC1126] Little, M., "Goals and functional requirements for inter-autonomous system routing", RFC 1126, October 1989.
[RFC1126]Little，M.“自治系统间路由的目标和功能要求”，RFC1126，1989年10月。
[RFC1726] Partridge, C. and F. Kastenholz, "Technical Criteria for Choosing IP The Next Generation (IPng)", RFC 1726, Dec 1994.
[RFC1726]Partridge，C.和F.Kastenholz，“选择下一代IP的技术标准（IPng）”，RFC 17261994年12月。
[RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996.
[RFC1992]Castineyra，I.，Chiapa，N.，和M.Steenstrup，“Nimrod路由架构”，RFC 1992，1996年8月。
[RFC2071] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.
[RFC2071]Ferguson，P.和H.Berkowitz，“网络重新编号概述：我为什么想要它以及它到底是什么？”，RFC 2071，1997年1月。
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[RFC2072]Berkowitz，H.，“路由器重新编号指南”，RFC 2072，1997年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221]Huston，G.“互联网中域间路由的评论”，RFC3221，2001年12月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]Grossman，D.“区分服务的新术语和澄清”，RFC 3260，2002年4月。
[RFC3344] Perkins, C., "IP Mobility Support.", RFC 3344, August 2002.
[RFC3344]Perkins，C.，“IP移动支持”，RFC33442002年8月。
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.
[RFC3345]McPherson，D.，Gill，V.，Walton，D.，和A.Retana，“边界网关协议（BGP）持续路由振荡条件”，RFC 33452002年8月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963]Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC5773] Davies, E. and A. Doria, "Analysis of Inter-Domain Routing Requirements and History", RFC 5773, February 2010.
[RFC5773]Davies，E.和A.Doria，“域间路由需求和历史分析”，RFC 5773，2010年2月。
[Wroclawski95] Wroclowski, J., "The Metanet White Paper - Workshop on Research Directions for the Next Generation Internet", 1995.
[Wroclawski95]Wroclowski，J.，“Metanet白皮书-下一代互联网研究方向研讨会”，1995年。
[netconf-charter] Internet Engineering Task Force, "IETF Network Configuration working group", 2005, <http://www.ietf.org/html.charters/netconf-charter.html>.
[netconf宪章]互联网工程任务组，“IETF网络配置工作组”，2005年<http://www.ietf.org/html.charters/netconf-charter.html>.
[policy-charter02] Internet Engineering Task Force, "IETF Policy working group", 2002, <http://www.ietf.org/html.charters/OLD/ policy-charter.html>.
[policy-charter02]互联网工程任务组，“IETF政策工作组”，2002年<http://www.ietf.org/html.charters/OLD/ policycharter.html>。
[rap-charter02] Internet Engineering Task Force, "IETF Resource Allocation Protocol working group", 2002, <http://www.ietf.org/html.charters/OLD/rap-charter.html>.
[rap-02]互联网工程任务组，“IETF资源分配协议工作组”，2002年<http://www.ietf.org/html.charters/OLD/rap-charter.html>.
[snmpconf-charter02] Internet Engineering Task Force, "IETF Configuration management with SNMP working group", 2002, <http:// www.ietf.org/html.charters/OLD/snmpconf-charter.html>.
[snmpconf-charter02]互联网工程任务组，“IETF配置管理与SNMP工作组”，2002年，<http://www.IETF.org/html.charters/OLD/snmpconf charter.html>。
Authors' Addresses
作者地址
Avri Doria LTU Lulea 971 87 Sweden
Avri Doria LTU Lulea 971 87瑞典
Phone: +46 73 277 1788
EMail: avri@ltu.se
Phone: +46 73 277 1788
EMail: avri@ltu.se
Elwyn B. Davies Folly Consulting Soham, Cambs UK
Elwyn B.Davies Folly Consulting Soham，英国剑桥
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Frank Kastenholz BBN Technologies 10 Moulton St. Cambridge, MA 02183 USA
Frank Kastenholz BBN Technologies美国马萨诸塞州剑桥莫尔顿街10号，邮编02183
Phone: +1 617 873 8047
EMail: frank@bbn.com
Phone: +1 617 873 8047
EMail: frank@bbn.com