Network Working Group S. Deering
Request for Comments: 2902 Cisco Systems
Category: Informational S. Hares
Merit Networks
C. Perkins
Nokia Research Center
R. Perlman
Sun Microsystems Laboratories
August 2000
Network Working Group S. Deering
Request for Comments: 2902 Cisco Systems
Category: Informational S. Hares
Merit Networks
C. Perkins
Nokia Research Center
R. Perlman
Sun Microsystems Laboratories
August 2000
Overview of the 1998 IAB Routing Workshop
1998年IAB路由研讨会概述
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document is an overview of a Routing workshop held by the Internet Architecture Board (IAB) during March 25-27, 1998. The major points of discussion are listed, along with some conclusions and action items for many of the points of discussion.
本文件概述了互联网体系结构委员会（IAB）于1998年3月25日至27日举办的路由研讨会。列出了主要讨论点，以及许多讨论点的一些结论和行动项目。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conclusions and Action Items . . . . . . . . . . . . . . . . 3
2.1. Scaling of Unicast Routing and Addressing . . . . . . . 3
2.1.1. Unicast Routing - Conclusions . . . . . . . . . . . 3
2.1.2. Unicast Routing - Action Items . . . . . . . . . . 4
2.2. Levels of Addressing of Addressing and Routing . . . . 4
2.3. Network Address Translation (NAT) devices . . . . . . . 5
2.3.1. NAT devices - Conclusions . . . . . . . . . . . . . 5
2.3.2. NAT devices - Action Items . . . . . . . . . . . . 5
2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . 5
2.4.1. Multicast - Conclusions . . . . . . . . . . . . . . 5
2.4.2. Multicast - Action Items . . . . . . . . . . . . . 6
2.5. Routing Stability . . . . . . . . . . . . . . . . . . . 6
2.5.1. Routing Stability - Conclusions . . . . . . . . . . 6
2.5.2. Routing Stability - Action Items . . . . . . . . . 7
2.6. ToS/CoS/QoS . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conclusions and Action Items . . . . . . . . . . . . . . . . 3
2.1. Scaling of Unicast Routing and Addressing . . . . . . . 3
2.1.1. Unicast Routing - Conclusions . . . . . . . . . . . 3
2.1.2. Unicast Routing - Action Items . . . . . . . . . . 4
2.2. Levels of Addressing of Addressing and Routing . . . . 4
2.3. Network Address Translation (NAT) devices . . . . . . . 5
2.3.1. NAT devices - Conclusions . . . . . . . . . . . . . 5
2.3.2. NAT devices - Action Items . . . . . . . . . . . . 5
2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . 5
2.4.1. Multicast - Conclusions . . . . . . . . . . . . . . 5
2.4.2. Multicast - Action Items . . . . . . . . . . . . . 6
2.5. Routing Stability . . . . . . . . . . . . . . . . . . . 6
2.5.1. Routing Stability - Conclusions . . . . . . . . . . 6
2.5.2. Routing Stability - Action Items . . . . . . . . . 7
2.6. ToS/CoS/QoS . . . . . . . . . . . . . . . . . . . . . . 7
2.6.1. ToS/CoS/QoS - Action Items . . . . . . . . . . . . 8
2.7. Routing Protocol Security . . . . . . . . . . . . . . . 8
2.7.1. Routing Security - Conclusions . . . . . . . . . . 8
2.7.2. Routing Security - Action Items . . . . . . . . . . 8
2.8. Routing Policy . . . . . . . . . . . . . . . . . . . . 8
2.8.1. Routing Policy - Conclusions . . . . . . . . . . . 8
2.8.2. Routing Policy - Action Item . . . . . . . . . . . 9
2.9. Network to Host Flow of Information . . . . . . . . . . 9
2.9.1. Host Information - Conclusions . . . . . . . . . . 9
2.9.2. Host Information - Action Items . . . . . . . . . . 9
2.10. Shorter Topics . . . . . . . . . . . . . . . . . . . . 9
2.10.1. Multi-strand Trunking . . . . . . . . . . . . . . 9
2.10.2. Routing Diagnostic and Development Tools . . . . 10
2.10.3. Anycast . . . . . . . . . . . . . . . . . . . . . 10
2.10.4. Load Sensitive IGP routing for Best Effort Traffic 11
2.10.5. Geographical Addresses and Renumbering . . . . . 11
3. Summary of Action items . . . . . . . . . . . . . . . . . . . 11
3.1. Action Items for the IAB . . . . . . . . . . . . . . . 11
3.2. Action Items for IETF Working Group Chairs . . . . . . 11
3.3. Action Items for the IRTF Routing Research Group . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
A. Participants . . . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 16
2.6.1. ToS/CoS/QoS - Action Items . . . . . . . . . . . . 8
2.7. Routing Protocol Security . . . . . . . . . . . . . . . 8
2.7.1. Routing Security - Conclusions . . . . . . . . . . 8
2.7.2. Routing Security - Action Items . . . . . . . . . . 8
2.8. Routing Policy . . . . . . . . . . . . . . . . . . . . 8
2.8.1. Routing Policy - Conclusions . . . . . . . . . . . 8
2.8.2. Routing Policy - Action Item . . . . . . . . . . . 9
2.9. Network to Host Flow of Information . . . . . . . . . . 9
2.9.1. Host Information - Conclusions . . . . . . . . . . 9
2.9.2. Host Information - Action Items . . . . . . . . . . 9
2.10. Shorter Topics . . . . . . . . . . . . . . . . . . . . 9
2.10.1. Multi-strand Trunking . . . . . . . . . . . . . . 9
2.10.2. Routing Diagnostic and Development Tools . . . . 10
2.10.3. Anycast . . . . . . . . . . . . . . . . . . . . . 10
2.10.4. Load Sensitive IGP routing for Best Effort Traffic 11
2.10.5. Geographical Addresses and Renumbering . . . . . 11
3. Summary of Action items . . . . . . . . . . . . . . . . . . . 11
3.1. Action Items for the IAB . . . . . . . . . . . . . . . 11
3.2. Action Items for IETF Working Group Chairs . . . . . . 11
3.3. Action Items for the IRTF Routing Research Group . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
A. Participants . . . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 16
March 25 to March 27, 1998 the Internet Architecture Board (IAB) held a workshop on Routing. The workshop focused on current problems within the Internet and the long term solutions that should be addressed. This document summarizes the discussions the group had on routing, and lists the conclusions reached by the workshop. Section 2 lists the conclusions reached by the participants of the workshop and the suggestions for additional work or redirection of current work. Sections 2.1-2.10 attempt to extract the major points of what was, in actuality, many multifaceted discussions, sometimes occurring all at the same time. Appendix A contains a list of the participants who attended the workshop. The full body of the report can be found at http://www.iab.org.
1998年3月25日至27日，互联网架构委员会（IAB）举办了一次路由问题研讨会。讲习班重点讨论了互联网目前存在的问题和应解决的长期解决办法。本文件总结了工作组就路线问题进行的讨论，并列出了研讨会得出的结论。第2节列出了研讨会参与者得出的结论以及关于额外工作或当前工作方向的建议。第2.1-2.10节试图提取事实上是多方面讨论的要点，有时是同时发生的。附录A载有参加研讨会的与会者名单。报告的全文可在http://www.iab.org.
The topics covered at length during the IAB workshop were:
IAB研讨会期间详细讨论的主题包括：
1. Scaling of Unicast Routing and Addressing (section 2.1) 2. Unicast Addressing Issues (Section 2.2) 3. The Effect of extending IP version 4 in the Internet by using Network Address Transformation boxes (Section 2.3) 4. Multicast Routing (Section 2.4)
1. 单播路由和寻址的扩展（第2.1节）2。单播解决问题（第2.2节）3。使用网络地址转换框在Internet上扩展IP版本4的效果（第2.3节）4。多播路由（第2.4节）
5. Routing Instability (Section 2.5) 6. Quality of Service Routing (Section 2.6) 7. Routing Security (Section 2.7) 8. BGP Policy (Section 2.8) 9. Flows of information from network routing to hosts for improved services (Section 2.9)
5. 路由不稳定性（第2.5节）6。服务质量路由（第2.6节）7。路由安全（第2.7节）8。BGP政策（第2.8节）9。从网络路由到主机的信息流，以改进服务（第2.9节）
In addition the following topics were briefly covered:
此外，还简要介绍了以下主题：
a. Multi-strand trunking b. Better tools for monitoring and diagnosis of network problems c. Routing protocol bandwidth minimization d. Automatic renumbering and automatic organization e. Anycast f. Load-sensitive routing g. Geographical addressing
a. 多股中继b。用于监视和诊断网络问题的更好工具c。路由协议带宽最小化。自动重新编号和自动组织e。选播f。负载敏感路由g。地理地址
These shorter topics are contained in section 2.10.
这些较短的主题包含在第2.10节中。
It would be unrealistic to assume that the workshop had definitive answers to all the technical problems that were raised. The best that can be hoped is that we raised most of the relevant issues and gave opinions that were the best guess of the people at the meeting, keeping in mind that the attendees did not come armed with data to back up opinions. Much of the discussion amounted to an exploration of the intuition of the experts in attendance, intuition gained after years of experience in making the Internet work. More work is needed to validate the intuition and experience by way of scientific experimentation and analysis. Unfortunately, it's not so easy to find a spare collection of global Internets upon which one might perform controlled experiments.
假设讲习班对所提出的所有技术问题都有明确的答案是不现实的。最好的希望是，我们提出了大部分相关问题，并给出了与会者的最佳猜测意见，同时要记住，与会者并没有携带支持意见的数据。大部分讨论都是对与会专家直觉的探索，这种直觉是在多年的互联网工作经验后获得的。需要更多的工作通过科学实验和分析来验证直觉和经验。不幸的是，要找到一个备用的全球互联网的集合并不是那么容易，人们可以在这个集合上进行控制实验。
The participants came to a number of conclusions after the discussions referred to in sections 2.1-2.10. These conclusions, presented in this document, provide summary statements and action items for the IETF community.
在第2.1-2.10节所述的讨论之后，与会者得出了一些结论。本文件中给出的这些结论为IETF社区提供了总结说明和行动项目。
The participants of the workshop came to the following conclusions
讲习班与会者得出以下结论
1. Most of the current unicast routing stability problems can be fixed with improved implementation.
1. 大多数当前的单播路由稳定性问题可以通过改进的实现来解决。
2. Some long term systemic issues that may eventually overwhelm the unicast routing are:
2. 一些最终可能压倒单播路由的长期系统性问题包括：
- Flaps - which will only get worse unless work is undertaken - Multi-homing
- 襟翼-除非进行工作，否则只会变得更糟-多归航
3. We'd like more research into what's breaking; not just more data, but more analysis of the data
3. 我们希望更多地研究什么是破坏；不仅仅是更多的数据，还有更多的数据分析
The group reviewed the following potential solutions:
工作组审查了以下可能的解决办法：
- Architected NAT (improving the existing Network Address Translation schemes to provide better scaling) - IPv6 (deploying an IP version 6 infrastructure) - MAP/Encap (map to aggregatable addresses and encapsulate the original packet) - Do nothing - Aggressive renumbering (try to continue to encourage renumbering to improve utilization of the IP version 4 address space) - Metro addressing (use a geographical or metropolitan based addressing scheme)
- 体系结构NAT（改进现有网络地址转换方案以提供更好的扩展）-IPv6（部署IP版本6基础设施）-映射/封装（映射到可聚合地址并封装原始数据包）-不做任何事情-积极重新编号（尝试继续鼓励重新编号以提高IP版本4地址空间的利用率）-城域寻址（使用基于地理或城域的寻址方案）
We recommend that the IRTF Routing Research group should encourage more analysis of routing data, not just the collection of more data.
我们建议IRTF路由研究小组应该鼓励更多的路由数据分析，而不仅仅是收集更多的数据。
Levels of hierarchy do not matter to the customers. Address hierarchy must be distinguished from routing hierarchy. The group examined whether the current Internet has enough levels of hierarchy in Internet addresses or routing infrastructure. The group did not find that levels of hierarchy should be added to the Internet, at least for now. Flat routing at the AS level seems to be workable; if this changes in the future, hierarchy would need to be revisited, and studied with due consideration to convergence time for routing algorithms and trust management. There is no universal agreement that adding levels of hierarchy at this point in time provides a well-defined benefit. Furthermore, two levels is difficult for many people, and any more than that is difficult both to build and to use.
层级对客户来说并不重要。地址层次结构必须与路由层次结构区分开来。该小组研究了当前互联网在互联网地址或路由基础设施方面是否有足够的层次结构。该组织没有发现应该在互联网上增加等级制度，至少目前是这样。AS层的平面布线似乎可行；如果这种情况在未来发生变化，则需要重新审视层次结构，并充分考虑路由算法和信任管理的收敛时间。目前还没有普遍的共识，即在此时添加层次结构可以带来明确的好处。此外，对于许多人来说，两个级别都很难，而且任何级别都很难构建和使用。
Upon reviewing the NATs, the group
在审查NAT后，小组
1. Noted that NAT devices are fairly widely deployed 2. Identified various problems with the use of NAT devices within the internet 3. Discussed the interaction between NAT devices and applications 4. Listed the following options regarding NAT devices:
1. 注意NAT设备的部署相当广泛2。确定了在internet 3中使用NAT设备的各种问题。讨论了NAT设备和应用程序之间的相互作用。列出了有关NAT设备的以下选项：
- Eliminate NATs - Fix NATs to interact better with the rest of the Internet - Fix applications to interact better with NAT boxes - Don't do certain things -- like IP Security (IPSec)
- 消除NAT-修复NAT以更好地与Internet的其余部分交互-修复应用程序以更好地与NAT盒交互-不要做某些事情-例如IP安全（IPSec）
1. Forward our concerns, problems and suggestions to the appropriate working groups 2. Note architectural work outside the NAT working group 3. Suggest to the IAB that it continue to be concerned about the issues involving NATs
1. 向适当的工作组提出我们的关注、问题和建议2。注意NAT工作组3以外的建筑工程。建议IAB继续关注涉及NAT的问题
Since the multicast model was created, many multicast applications have been tried over the Internet multicast routing fabric. The group began to discuss the multicast model in terms of enabling multicast applications to run efficiently, and scale favorably with future growth. Multicast applications place varying requirements on multicast routing.
自从多播模型建立以来，许多多播应用已经在Internet多播路由结构上进行了尝试。该小组开始讨论多播模型，使多播应用程序能够高效运行，并随着未来的增长进行良好的扩展。多播应用程序对多播路由提出了不同的要求。
Multicast applications may have a variable:
多播应用程序可能有一个变量：
- number of sources, - number of receivers, - amount of data, - amount of data in a burst, and length of quiet periods - number of groups utilized per application or per set of cooperating applications, and - amount of time during which the group exists - topological distance between members of the group. - volatility of membership
- 源数、-接收器数、-数据量、-突发数据量和安静期长度-每个应用程序或每组协作应用程序使用的组数，以及-组存在的时间量-组成员之间的拓扑距离。-成员的不稳定性
Multicast routing must provide the flexibility to support the varying requirements of different multicast applications. The current multicast model establishes multicast routing paths upon reception of a data packet. The discussion on the viability of the multicast model examined the viability of the model in terms of the uses of multicast routing by applications and the scalability to full Internet usage. For example, providing for many groups of small conferences (a small number of widely-dispersed people) with global topological scope scales badly given the current multicast model.
多播路由必须提供灵活性，以支持不同多播应用程序的不同需求。当前的多播模型在接收数据包时建立多播路由路径。关于多播模型可行性的讨论从应用程序使用多播路由和可扩展到完全互联网使用的角度检查了该模型的可行性。例如，考虑到当前的多播模型，为许多具有全局拓扑范围的小型会议组（少量广泛分布的人）提供的服务非常糟糕。
The group felt the existing multicast protocols and multicast should be evaluated in terms of the requirements listed above. The group suggested that the evaluation should include the multicast protocols DVMRP [12], MOSPF [8], PIM [4], CBT [2], and Express [5], as well as the following mechanisms used by multicast applications:
该小组认为，应根据上述要求评估现有的多播协议和多播。该小组建议评估应包括多播协议DVMRP[12]、MOSPF[8]、PIM[4]、CBT[2]和Express[5]，以及多播应用程序使用的以下机制：
1. Registering with the core or the RP (Rendezvous Point), 2. Having the ID of the group include the core, and having joins specify the core 3. Having the ID of the group include the core, and having joins and data specify both 4. Sending data via unicast to all members, and 5. Sending data via unicast transport to the RP.
1. 向堆芯或RP（交会点）登记，2。组ID包含核心，连接指定核心3。让组的ID包含核心，让连接和数据同时指定4。通过单播向所有成员发送数据，以及5。通过单播传输向RP发送数据。
The group acknowledged that the current multicast model does not scale well for all scenarios that applications use.
该小组承认，当前的多播模型不能很好地适应应用程序使用的所有场景。
The group noted that reliable multicast is surprisingly orthogonal to the issues about the scaling of the multicast model to all possible applications.
该小组注意到，可靠的多播与多播模型扩展到所有可能应用的问题惊人地正交。
Encourage evaluation and written reports on these multicast protocols, and mechanisms for different types of protocols.
鼓励对这些多播协议以及不同类型协议的机制进行评估和编写报告。
Notify the IRTF Routing Research Group of the need to charter activity in this area.
通知IRTF路由研究小组需要租用该区域的活动。
Damping the effects of route updates enhances stability, but possibly at the cost of reachability for some prefixes. A prefix can be damped and reachable via another path, so that for such prefixes the effects of damping are less serious than for other prefixes. The performance of various algorithms for enhancing stability should be
抑制路由更新的影响可以增强稳定性，但可能会以某些前缀的可达性为代价。前缀可以通过另一条路径进行阻尼和访问，因此对于此类前缀，阻尼的影响不如其他前缀严重。提高稳定性的各种算法的性能应该是
measured by recording whether the affected route prefixes are reachable or not reachable. Using current damping approaches, approximately 1% of the prefixes are affected at any one point in time. We should try to find out how many prefixes are unreachable because of damping.
通过记录受影响的路由前缀是否可访问来测量。使用当前的阻尼方法，大约1%的前缀在任何一个时间点都会受到影响。我们应该找出有多少前缀由于阻尼而无法访问。
The conclusion is that this effort merits continued investigation.
结论是，这一努力值得继续调查。
The IRTF Routing Research Group should measure how stable things are, and if stability is an issue, to study methods of making them more stable.
IRTF路由研究小组应该衡量事物的稳定性，如果稳定性是一个问题，研究使它们更稳定的方法。
The group noted that the terms Type of Service (ToS), Class of Service (CoS), and Quality of Service (QoS) are imprecise as currently used. The discussion started by defining the terminology as follows:
专家组注意到，目前使用的服务类型（ToS）、服务类别（CoS）和服务质量（QoS）等术语不准确。讨论从定义术语开始，如下所示：
ToS: hop by hop routing based on destination plus ToS bits [9] CoS: classes of service based on service contracts. These classes of service are enabled by a variety of mechanisms which include queueing, and multiple physical or link level paths. QoS: managing routes that meet certain quality of service constraints, and involving the following steps:
ToS：基于目的地的逐跳路由加上ToS位[9]CoS：基于服务合约的服务类别。这些服务类别由多种机制启用，包括排队和多个物理或链路级路径。QoS：管理满足特定服务质量约束的路由，包括以下步骤：
* routing the resource requests * setting up a path that satisfies the constraints * routing the data
* 路由资源请求*设置满足约束的路径*路由数据
There is no smooth dividing line between between ToS and QoS. ToS is relative. QoS is absolute. The group discussed whether there is a demand for ToS, CoS and QoS. Differentiated-services [3] as discussed in the IETF is ToS++.
ToS和QoS之间没有平滑的分界线。ToS是相对的。服务质量是绝对的。该小组讨论了是否需要ToS、CoS和QoS。IETF中讨论的区分服务[3]是ToS++。
The group also discussed a more general concept of "Constraint Based Routing" which was defined as traffic engineering on large aggregated flows. Constraint based routing allows the providers to better utilize the bandwidth in their network to handle traffic requests from users. Besides enabling policy management techniques, constraint based routing allows providers to route traffic based on the characteristics of the traffic flows.
该小组还讨论了“基于约束的路由”的更一般概念，该概念被定义为大型聚合流上的流量工程。基于约束的路由允许提供商更好地利用其网络中的带宽来处理来自用户的流量请求。除了启用策略管理技术外，基于约束的路由还允许提供商根据流量的特征路由流量。
We recommend that IETF should look into the issue of Constraint Based Routing.
我们建议IETF研究基于约束的路由问题。
After a lengthy discussion of the various problems of network security, the group notes that:
在对网络安全的各种问题进行了长时间的讨论之后，专家组注意到：
1. Routers need intrinsic system security as good as or better than any host computer. 2. Improving router security will not solve all problems. 3. Console access to the router can do everything. 4. One compromised router can create disaster. 5. ISPs and vendors should consider taking some control traffic out of band, due to lack of wire speed authentication. 6. We discussed other issues that will be passed on to the appropriate people involved with network security. 7. Identified areas of work to improve things (e.g., wire speed authentication).
1. 路由器需要与任何主机一样好或更好的内在系统安全性。2.提高路由器安全性并不能解决所有问题。3.控制台访问路由器可以做任何事情。4.一个受损的路由器会造成灾难。5.ISP和供应商应考虑采取一些控制流量带外，由于缺乏线速认证。6.我们讨论了将传递给网络安全相关人员的其他问题。7.确定改进工作的领域（例如，线速认证）。
The IETF should encourage work on "wire speed" authentication, pair-wise authentication of routers in routing protocols, and Byzantine robustness [6] in routing protocols.
IETF应鼓励在“线速”认证、路由协议中路由器的成对认证以及路由协议中的拜占庭健壮性[6]方面开展工作。
During our discussion on routing policy the group reviewed what could be done with BGP. The group noted that:
在我们关于路由策略的讨论中，小组回顾了BGP可以做些什么。专家组注意到：
1. Some routing policies requested by ISPs or NSPs are not solvable with BGP. Some of these "unsolvable" routing policies can be put into effect using tunnels and static configuration. 2. BGP is only a mechanism for announcing reachability 3. BGP routing controls traffic direction without regard to traffic volume. 4. BGP policy management is too delicate, too easy to mess up, and fragile.
1. ISP或NSP请求的某些路由策略无法通过BGP解决。其中一些“无法解决”的路由策略可以使用隧道和静态配置来实施。2.BGP只是一种宣布可达性3的机制。BGP路由控制流量方向，而不考虑流量。4.BGP策略管理过于微妙，太容易出错，而且脆弱。
5. Router Configuration Language is very complex and error-prone 6. We can't count on symmetric routing, so ISPs/NSPs/Enterprise nets should deal with it.
5. 路由器配置语言非常复杂且容易出错。我们不能指望对称路由，所以ISP/NSPs/企业网络应该处理它。
The group concluded the Internet needed a better routing policy specification language.
该小组得出结论，互联网需要更好的路由策略规范语言。
Pass the concerns about the Routing Policy Syntax Language (RPSL) [1] to chairs of the Routing Policy Syntax (RPS) working group [11].
将有关路由策略语法语言（RPSL）[1]的问题传递给路由策略语法（RPS）工作组的主席[11]。
Publishing information about traffic statistics along backbone routes could improve the way Internet services replicate data for retrieval from various sites. This replication could be especially important for the retrieval of information off the web. Currently, web pages refer people to caches local to their sites; for instance, a European site might be used for United Kingdom customers and a North American site for North American customers. Proponents of web caches want to auto-configure the locations of web caches so a user's web browser can automatically discover the local cache. Other applications share this need for finding the best cache for a particular service.
发布主干线路上的流量统计信息可以改进互联网服务复制数据以从不同站点检索的方式。这种复制对于从web上检索信息可能特别重要。目前，网页指的是人们在其网站的本地缓存；例如，欧洲站点可能用于英国客户，而北美站点可能用于北美客户。web缓存的支持者希望自动配置web缓存的位置，以便用户的web浏览器能够自动发现本地缓存。其他应用程序也需要为特定服务找到最佳缓存。
The group recommends a BOF be held on Measuring Path Characteristics. Measurement of path characteristics should include:
该小组建议在测量路径特性时举行BOF。路径特性的测量应包括：
- format for exchange of measurement data - mechanisms for distribution of measurement data
- 测量数据交换格式.测量数据分配机制
IPPM working group [7] is dealing with issues within the measurement problem space.
IPPM工作组[7]正在处理测量问题空间内的问题。
PPP did multi-link in a way that required too much computation and could not be used for faster links. Internet technology should treat multiple parallel trunks as 1 link at the IP layer, but with multi-dimensional metrics.
PPP以一种需要太多计算且不能用于更快链路的方式进行多链路。互联网技术应该在IP层将多个并行中继视为一条链路，但要使用多维度量。
Multi-strand Trunking - Action Items
多股中继-动作项
There is design and development work at layer two which should be done to support the multiple parallel trunks. This layer two work is outside the scope of the IETF. Layer three routing should support richer metrics in OSPF.
第二层需要进行设计和开发工作，以支持多条平行干线。第二层工作不在IETF的范围内。第三层路由应该支持OSPF中更丰富的指标。
1. It would be nice to have an Authoritative Database listing those prefixes permitted from each AS. The authoritative data base was attempted before without success, but the group felt it might be useful to try again. 2. SNMP version 3 should be deployed in order to make use of its improved authentication, scope and rate limiting 3. Remotely-controlled traffic monitors should be used to measure traffic 4. Better tools are needed for preventative problem detection
1. 最好有一个权威数据库，列出每个AS允许的前缀。权威数据库以前曾尝试过，但没有成功，但该小组认为再试一次可能有用。2.应部署SNMP版本3，以利用其改进的身份验证、范围和速率限制3。应使用远程控制的流量监视器来测量流量4。预防性问题检测需要更好的工具
1. Encouraged an authoritative database within the Internet 2. Notify SNMP version 3 working groups regarding needs for authentication, scope, and rate limiting. 3. Encourage funding of better tools for remotely controlled traffic sources and pro-active problem detection.
1. 鼓励在Internet 2内建立权威数据库。通知SNMP版本3工作组有关身份验证、范围和速率限制的需要。3.鼓励为远程控制交通源和主动问题检测提供更好的工具。
1. We need to describe the advantages and disadvantages of anycast. 2. Local-scoped well-known anycast addresses will be useful to applications.
1. 我们需要描述anycast的优缺点。2.本地范围的已知选播地址对应用程序很有用。
A BOF should be held to plan work on anycast.
应召开BOF，以计划anycast的工作。
If a working group forms, a paper on the advantages and disadvantages of anycast should be included as part of the charter.
如果成立了一个工作组，则应将一份关于anycast利弊的文件作为宪章的一部分。
While load sensitive routing is interesting in some ways, it cannot be considered until certain problems are worked out. Currently, constraint based routing is assigning administrative metrics to allow routing to adapt to different traffic patterns. Load sensitive routing may increase oscillation and instability of routes. This instability of routes, sometimes called churn, may affect the ability of the routing infrastructure to scale.
虽然负载敏感路由在某些方面很有趣，但在解决某些问题之前，不能考虑它。目前，基于约束的路由正在分配管理度量，以允许路由适应不同的流量模式。负载敏感路由可能会增加路由的振荡和不稳定性。路由的这种不稳定性（有时称为客户流失）可能会影响路由基础设施的扩展能力。
Load sensitive routing would allow IGPs to better utilize links. Past and current efforts in load sensitive routing include: QoS OSPF [10], Q-OSPF [10], and load sensitive routers developed by BBN.
负载敏感路由将允许IGP更好地利用链路。过去和当前在负载敏感路由方面的工作包括：QoS OSPF[10]、Q-OSPF[10]和BBN开发的负载敏感路由器。
The IRTF Routing Research group chair and Routing Area Director should discuss this subject and determine what techniques from Load Sensitive IGP routing are ready for IETF, and what requires additional research.
IRTF路由研究组主席和路由区域主任应讨论该主题，并确定哪些负载敏感IGP路由技术可用于IETF，以及哪些需要额外研究。
This topic was discussed, but without any conclusions or action items.
讨论了这一议题，但没有任何结论或行动项目。
1. The IAB should be concerned about the issues involving NATs 2. Authoritative Database (for addresses within domains) should be encouraged within the Internet 3. Encourage funding of better tools for remotely controlled traffic sources and pro-active problem detection.
1. IAB应关注涉及NATs 2的问题。应鼓励在Internet 3中使用权威数据库（用于域内的地址）。鼓励为远程控制交通源和主动问题检测提供更好的工具。
1. NAT: Forward our concerns, problems and suggestions to the appropriate working groups 2. We recommend that IETF should work the issue of Constraint Based Routing. 3. The IETF should encourage work on "wire speed" authentication, pair-wise authentication of routers in routing protocols, and Byzantine robustness in routing protocols.
1. NAT：将我们的关注、问题和建议提交给相应的工作组2。我们建议IETF解决基于约束的路由问题。3.IETF应鼓励在“线速”认证、路由协议中路由器的成对认证以及路由协议中的拜占庭健壮性方面开展工作。
4. Concerns about the Routing Policy Specification Language (RPSL) should go to the Routing Policy Systems (RPS) working group chair. 5. The group recommends a BOF be held on Measuring Path Characteristics. The BOF should consider the data exchange format of measurement and mechanisms to distribution of data mechanism. It is noted that the IPPM working group is dealing with issues within the measurement problem space. 6. There is layer two work which should be done to support the multiple parallel trunks which is outside the scope of the IETF. Layer three routing should support richer metrics in OSPF. 7. SNMP version 3 working groups should be notified about the issues about authentication, scope, and rate limiting. 8. A BOF should be held to plan work on anycast. A document on anycast should be part of the proposed working group charter.
4. 有关路由策略规范语言（RPSL）的问题应提交给路由策略系统（RPS）工作组主席。5.该小组建议在测量路径特性时举行BOF。转炉应考虑测量数据的交换格式和数据机制的分配机制。值得注意的是，IPPM工作组正在处理测量问题空间内的问题。6.为了支持IETF范围之外的多个并行中继线，需要进行第二层工作。第三层路由应该支持OSPF中更丰富的指标。7.应通知SNMP版本3工作组有关身份验证、范围和速率限制的问题。8.应召开BOF，以计划anycast的工作。关于选播的文件应成为拟议工作组章程的一部分。
1. We recommend that the IRTF Routing Research working group try to encourage more analysis of routing data, not just the collection of more data.
1. 我们建议IRTF路由研究工作组鼓励更多的路由数据分析，而不仅仅是收集更多的数据。
2. Encourage evaluation and written reports on the evaluation of multicast protocols and mechanisms for different types of protocols
2. 鼓励对不同类型协议的多播协议和机制进行评估并编写评估报告
3. The IRTF Routing Research group chair and the Routing Area Director should discuss Load Sensitive IGP routing and determine whether it is ready for the IETF.
3. IRTF路由研究组主席和路由区域主任应讨论负载敏感IGP路由，并确定其是否已准备好用于IETF。
Security considerations were an important part of the discussions at the workshop, but the workshop decided not to publish a summary of these discussions. Other documents that address the issues of routing infrastructure security have recently been published.
安全考虑是讲习班讨论的一个重要部分，但讲习班决定不发表这些讨论的摘要。解决路由基础设施安全问题的其他文档最近已经发布。
A. Participants
A.与会者
(Email addresses as of the meeting date.)
（截至会议日期的电子邮件地址。）
Harald Alvestrand Harald.Alvestrand@maxware.no Fred Baker fred@cisco.com Jeff Burgan burgan@corp.home.net Brian Carpenter brian@hursley.ibm.com Noel Chiappa jnc@ginger.lcs.mit.edu Rob Coltun rcoltun@fore.com Steve Deering deering@cisco.com Deborah Estrin estrin@usc.edu
哈拉尔·阿尔韦斯特拉德·哈拉尔德。Alvestrand@maxware.no弗雷德·贝克fred@cisco.com杰夫·伯根burgan@corp.home.net布莱恩·卡彭特brian@hursley.ibm.com诺埃尔·基亚帕jnc@ginger.lcs.mit.edu罗伯·科尔顿rcoltun@fore.com史蒂夫·迪林deering@cisco.com黛博拉·埃斯特林estrin@usc.edu
Dino Farinacci dino@cisco.com Paul Francis francis@slab.ntt.co.jp Elise Gerich epg@home.net Joel Halpern jhalpern@newbridge.com Sue Hares skh@merit.edu Cyndi Jung cmj@3Com.com Dave Katz dkatz@jnx.com Tony Li tli@juniper.net Peter Lothberg roll@stupi.se Louis Mamakos louie@uu.net Dave Meyer dmm@cisco.com Keith Moore moore@cs.utk.edu Bob Moskowitz rgm@htt-consult.com Thomas Narten narten@raleigh.ibm.com Vern Paxson vern@ee.lbl.gov Charles E. Perkins cperkins@eng.sun.com Radia Perlman Radia.Perlman@East.Sun.COM Yakov Rekhter yakov@cisco.com Allyn Romanow allyn@MCI.NET Martha Steenstrup msteenst@bbn.com George Swallow swallow@cisco.com
恐龙粉dino@cisco.com保罗弗朗西斯francis@slab.ntt.co.jp伊莉丝·格里奇epg@home.net乔尔·哈尔本jhalpern@newbridge.com苏·哈尔斯skh@merit.edu钟欣迪cmj@3Com.com戴夫·卡茨dkatz@jnx.com李东尼tli@juniper.net彼得·洛斯伯格roll@stupi.se路易斯马马科斯louie@uu.net戴夫·迈耶dmm@cisco.com基思摩尔moore@cs.utk.edu鲍勃莫斯科维茨rgm@htt-咨询网站Thomas Nartennarten@raleigh.ibm.com弗恩帕克森vern@ee.lbl.gov查尔斯·E·珀金斯cperkins@eng.sun.com帕尔曼半径。Perlman@East.Sun.COM亚科夫·雷赫特yakov@cisco.com艾琳·罗曼诺allyn@MCI.NET玛莎甜菊msteenst@bbn.com乔治·斯沃洛swallow@cisco.com
References
工具书类
[1] Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer, D., Terpstra, M. and C. Villamizar, "Routing Policy Specification Language (RPSL)", RFC 2280, January 1998.
[1] Alaettinoglu，C.，Bates，T.，Gerich，E.，Karrenberg，D.，Meyer，D.，Terpstra，M.和C.Villamizar，“路由策略规范语言（RPSL）”，RFC 2280，1998年1月。
[2] Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.
[2] Ballardie，A.，“基于核心的树（CBT）多播路由架构”，RFC2201，1997年9月。
[3] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[3] Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[4] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[4] Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Liu，C.，Sharma，P.和L.Wei，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[5] Holbrook, H., Cheriton, D, "EXPRESS Multicast", SIGCOMM 99, September 1999.
[5] 霍尔布鲁克，H.，切里顿，D，“快速多播”，SIGCOM991999年9月。
[6] Charlie Kaufman, Radia Perlman, and Mike Speciner. Network Security: Private Communication in a Public World, pages 462-- 465. Prentice-Hall, Inc., 1995.
[6] 查理·考夫曼、拉迪娅·帕尔曼和迈克·斯派纳。网络安全：公共世界中的私人通信，第462-465页。普伦蒂斯·霍尔公司，1995年。
[7] W. Leland and M. Zekauskas (chairs). IP Performance Metrics (IPPM), October 1997. http://www.ietf.org/html.charters/ippm-charter.html.
[7] W.Leland和M.Zekauskas（主席）。IP性能指标（IPPM），1997年10月。http://www.ietf.org/html.charters/ippm-charter.html.
[8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[8] Moy，J.，“OSPF的多播扩展”，RFC1584，1994年3月。
[9] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[9] Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[10] H. Sandick and E. Crawley (chairs). QoS Routing (qosr), April 1997. http://www.ietf.org/html.charters/qosr-charter.html.
[10] H.Sandick和E.Crawley（椅子）。QoS路由（qosr），1997年4月。http://www.ietf.org/html.charters/qosr-charter.html.
[11] C. Villamizar and C. Alaettinoglu (chairs). Routing Policy Syntax (RPS), July 1995. http://www.ietf.org/html.charters/rps-charter.html.
[11] C.Villamizar和C.Alaettinoglu（椅子）。路由策略语法（RPS），1995年7月。http://www.ietf.org/html.charters/rps-charter.html.
[12] Waitzman, D., Partridge, C. and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[12] Waitzman，D.，Partridge，C.和S.Deering，“距离向量多播路由协议”，RFC 1075，1988年11月。
Authors' Addresses
作者地址
Questions about this memo can be directed to:
有关本备忘录的问题，请联系：
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Stephen E.Deering Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
Phone: +1 408 527-8213
EMail: deering@cisco.com
Phone: +1 408 527-8213
EMail: deering@cisco.com
Susan Hares Merit, Inc. 1071 Beal Avenue, Ann Arbor, MI 48109 USA
美国密歇根州安娜堡比尔大道1071号Susan Hares Merit公司，邮编：48109
Phone: +1 313 936-2095
EMail: skh@nexthop.com
Phone: +1 313 936-2095
EMail: skh@nexthop.com
Radia Perlman Sun Microsystems Laboratories 2 Elizabeth Drive Chelmsford, MA 01824 USA
美国马萨诸塞州切姆斯福德伊丽莎白大道2号Radia Perlman太阳微系统实验室01824
Phone: +1 978 442-3252
EMail: Radia.Perlman@sun.com
Phone: +1 978 442-3252
EMail: Radia.Perlman@sun.com
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
查尔斯·E·珀金斯诺基亚研究中心313飞兆半导体山景大道，加利福尼亚州94043
Phone: +1 650 625-2986
EMail: Charles.Perkins@nokia.com
Fax: +1 650-625-2502
Phone: +1 650 625-2986
EMail: Charles.Perkins@nokia.com
Fax: +1 650-625-2502
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。