Network Working Group T. Li
Request for Comments: 2430 Juniper Networks
Category: Informational Y. Rekhter
Cisco Systems
October 1998
Network Working Group T. Li
Request for Comments: 2430 Juniper Networks
Category: Informational Y. Rekhter
Cisco Systems
October 1998
A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)
用于区分服务和流量工程的提供商体系结构（PASTE）
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). Providing differentiated services in ISPs is a challenge because the scaling problems presented by the sheer number of flows present in large ISPs makes the cost of maintaining per-flow state unacceptable. Coupled with this, large ISPs need the ability to perform traffic engineering by directing aggregated flows of traffic along specific paths.
本文档描述了互联网服务提供商（ISP）的差异化服务和流量工程（PASTE）的提供商体系结构。在ISP中提供差异化服务是一项挑战，因为大型ISP中存在的流量数量所带来的扩展问题使得维持每个流量状态的成本无法接受。再加上这一点，大型ISP需要通过引导特定路径上的聚合流量来执行流量工程。
PASTE addresses these issues by using Multiprotocol Label Switching (MPLS) [1] and the Resource Reservation Protocol (RSVP) [2] to create a scalable traffic management architecture that supports differentiated services. This document assumes that the reader has at least some familiarity with both of these technologies.
PASTE通过使用多协议标签交换（MPLS）[1]和资源预留协议（RSVP）[2]来创建支持差异化服务的可扩展流量管理体系结构，从而解决了这些问题。本文档假设读者至少对这两种技术都有一定的了解。
In common usage, a packet flow, or a flow, refers to a unidirectional stream of packets, distributed over time. Typically a flow has very fine granularity and reflects a single interchange between hosts, such as a TCP connection. An aggregated flow is a number of flows that share forwarding state and a single resource reservation along a sequence of routers.
在常见用法中，分组流或流是指随时间分布的单向分组流。通常，流具有非常精细的粒度，反映主机之间的单个交换，例如TCP连接。聚合流是沿路由器序列共享转发状态和单个资源保留的多个流。
One mechanism for supporting aggregated flows is Multiprotocol Label Switching (MPLS). In MPLS, packets are tunneled by wrapping them in a minimal header [3]. Each such header contains a label, that carries both forwarding and resource reservation semantics. MPLS defines mechanisms to install label-based forwarding information along a series of Label Switching Routers (LSRs) to construct a Label Switched Path (LSP). LSPs can also be associated with resource reservation information.
支持聚合流的一种机制是多协议标签交换（MPLS）。在MPLS中，通过将数据包包装在最小报头[3]中来对数据包进行隧道传输。每个这样的报头都包含一个标签，该标签携带转发和资源保留语义。MPLS定义了沿一系列标签交换路由器（LSR）安装基于标签的转发信息的机制，以构建标签交换路径（LSP）。LSP还可以与资源保留信息相关联。
One protocol for constructing such LSPs is the Resource Reservation Protocol (RSVP) [4]. When used with the Explicit Route Object (ERO) [5], RSVP can be used to construct an LSP along an explicit route [6].
构造这种LSP的一个协议是资源保留协议（RSVP）[4]。当与显式路由对象（ERO）[5]一起使用时，RSVP可用于沿显式路由构造LSP[6]。
To support differentiated services, packets are divided into separate traffic classes. For conceptual purposes, we will discuss three different traffic classes: Best Effort, Priority, and Network Control. The exact number of subdivisions within each class is to be defined.
为了支持区分服务，数据包被划分为不同的流量类别。出于概念上的目的，我们将讨论三种不同的流量类别：尽力而为、优先级和网络控制。每个类别内细分的确切数量有待定义。
Network Control traffic primarily consists of routing protocols and network management traffic. If Network Control traffic is dropped, routing protocols can fail or flap, resulting in network instability. Thus, Network Control must have very low drop preference. However, Network Control traffic is generally insensitive to moderate delays and requires a relatively small amount of bandwidth. A small bandwidth guarantee is sufficient to insure that Network Control traffic operates correctly.
网络控制流量主要包括路由协议和网络管理流量。如果网络控制流量被丢弃，路由协议可能会失败或抖动，从而导致网络不稳定。因此，网络控制必须具有非常低的丢包偏好。然而，网络控制流量通常对中等延迟不敏感，并且需要相对较少的带宽。小带宽保证足以确保网络控制流量正常运行。
Priority traffic is likely to come in many flavors, depending on the application. Particular flows may require bandwidth guarantees, jitter guarantees, or upper bounds on delay. For the purposes of this memo, we will not distinguish the subdivisions of priority traffic. All priority traffic is assumed to have an explicit resource reservation.
优先级流量可能有多种形式，具体取决于应用程序。特定流可能需要带宽保证、抖动保证或延迟上限。在本备忘录中，我们将不区分优先级流量的细分。假设所有优先级流量都有明确的资源预留。
Currently, the vast majority of traffic in ISPs is Best Effort traffic. This traffic is, for the most part, delay insensitive and reasonably adaptive to congestion.
目前，ISP中的绝大多数流量都是尽力而为的流量。这种流量在很大程度上是对延迟不敏感的，并且能够合理地适应拥塞。
When flows are aggregated according to their traffic class and then the aggregated flow is placed inside a LSP, we call the result a traffic trunk, or simply a trunk. The traffic class of a packet is orthogonal to the LSP that it is on, so many different trunks, each with its own traffic class, may share an LSP if they have different traffic classes.
当根据流量类别对流量进行聚合，然后将聚合的流量放在LSP中时，我们将结果称为流量主干，或简称主干。一个数据包的流量等级与它所在的LSP是正交的，因此许多不同的中继，每个中继都有自己的流量等级，如果它们有不同的流量等级，可能共享一个LSP。
The next generation of the Internet presents special challenges that must be addressed by a single, coordinated architecture. While this architecture allows for distinction between ISPs, it also defines a framework within which ISPs may provide end-to-end differentiated services in a coordinated and reliable fashion. With such an architecture, an ISP would be able to craft common agreements for the handling of differentiated services in a consistent fashion, facilitating end-to-end differentiated services via a composition of these agreements. Thus, the goal of this document is to describe an architecture for providing differentiated services within the ISPs of the Internet, while including support for other forthcoming needs such as traffic engineering. While this document addresses the needs of the ISPs, its applicability is not limited to the ISPs. The same architecture could be used in any large, multiprovider catenet needing differentiated services.
下一代互联网带来了特殊的挑战，必须通过一个单一的、协调的体系结构来解决。虽然这种架构允许区分ISP，但它也定义了一个框架，在该框架内，ISP可以以协调和可靠的方式提供端到端的差异化服务。有了这样一种体系结构，ISP将能够以一致的方式起草处理差异化服务的通用协议，通过这些协议的组合促进端到端的差异化服务。因此，本文档的目标是描述一种在互联网ISP内提供差异化服务的体系结构，同时包括对其他未来需求（如流量工程）的支持。虽然本文件满足了ISP的需求，但其适用性并不限于ISP。相同的体系结构可用于任何需要差异化服务的大型多供应商catenet。
This document only discusses unicast services. Extensions to the architecture to support multicast are a subject for future research.
本文档仅讨论单播服务。支持多播的架构扩展是未来研究的主题。
One of the primary considerations in any ISP architecture is scalability. Solutions that have state growth proportional to the size of the Internet result in growth rates exceeding Moore's law, making such solutions intractable in the long term. Thus, solutions that use mechanisms with very limited growth rates are strongly preferred.
任何ISP体系结构中的主要考虑因素之一是可伸缩性。国家增长与互联网规模成比例的解决方案导致增长率超过摩尔定律，使此类解决方案长期难以解决。因此，强烈推荐使用增长率非常有限的机制的解决方案。
Discussions of differentiated services to date have frequently resulted in solutions that require per-flow state or per-flow queuing. As the number of flows in an ISP within the "default-free zone of the Internet" scales with the size of the Internet, the growth rate is difficult to support and argues strongly for a solution with lower state requirements. Simultaneously, supporting differentiated services is a significant benefit to most ISPs. Such support would allow providers to offer special services such as priority for bandwidth for mission critical services for users willing to pay a service premium. Customers would contract with ISPs for these services under Service Level Agreements (SLAs). Such an agreement may specify the traffic volume, how the traffic is handled, either in an absolute or relative manner, and the compensation that the ISP receives.
迄今为止，对差异化服务的讨论经常导致需要按流状态或按流排队的解决方案。由于“互联网无默认区”内的ISP流量随着互联网规模的扩大而增加，因此很难支持这种增长率，并强烈主张采用州要求较低的解决方案。同时，支持差异化服务对大多数ISP来说是一个巨大的好处。这种支持将允许提供商为愿意支付服务费的用户提供特殊服务，例如任务关键型服务的带宽优先级。客户将根据服务水平协议（SLA）与ISP签订这些服务合同。这种协议可以规定通信量、以绝对或相对方式处理通信量的方式以及ISP收到的补偿。
Differentiated services are likely to be deployed across a single ISP to support applications such as a single enterprise's Virtual Private Network (VPN). However, this is only the first wave of service implementation. Closely following this will be the need for differentiated services to support extranets, enterprise VPNs that
差异化服务可能跨单个ISP部署，以支持单个企业的虚拟专用网络（VPN）等应用程序。然而，这只是服务实现的第一波。紧随其后的将是对差异化服务的需求，以支持外部网，即
span ISPs, or industry interconnection networks such as the ANX [7]. Because such applications span enterprises and thus span ISPs, there is a clear need for inter-domain SLAs. This document discusses the technical architecture that would allow the creation of such inter-domain SLAs.
跨ISP或行业互连网络，如ANX[7]。由于此类应用程序跨越企业，因此跨越ISP，因此显然需要域间SLA。本文档讨论了允许创建此类域间SLA的技术体系结构。
Another important consideration in this architecture is the advent of traffic engineering within ISPs. Traffic engineering is the ability to move trunks away from the path selected by the ISP's IGP and onto a different path. This allows an ISP to route traffic around known points of congestion in its network, thereby making more efficient use of the available bandwidth. In turn, this makes the ISP more competitive within its market by allowing the ISP to pass lower costs and better service on to its customers.
该体系结构中的另一个重要考虑因素是ISP中流量工程的出现。流量工程是指将中继线从ISP的IGP选择的路径移到另一条路径上的能力。这允许ISP在其网络中的已知拥塞点周围路由流量，从而更有效地利用可用带宽。反过来，通过允许ISP将更低的成本和更好的服务传递给客户，这使得ISP在其市场中更具竞争力。
Finally, the need to provide end-to-end differentiated services implies that the architecture must support consistent inter-provider differentiated services. Most flows in the Internet today traverse multiple ISPs, making a consistent description and treatment of priority flows across ISPs a necessity.
最后，提供端到端区分服务的需要意味着体系结构必须支持一致的提供商间区分服务。如今，互联网上的大多数流量都会穿越多个ISP，因此有必要对ISP之间的优先流进行一致的描述和处理。
The Differentiated Services Backbone architecture is the integration of several different mechanisms that, when used in a coordinated way, achieve the goals outlined above. This section describes each of the mechanisms used in some detail. Subsequent sections will then detail the interoperation of these mechanisms.
区分服务主干架构是几种不同机制的集成，当以协调的方式使用这些机制时，可以实现上述目标。本节详细介绍了使用的每种机制。随后的章节将详细介绍这些机制的互操作。
As described above, packets may fall into a variety of different traffic classes. For ISP operations, it is essential that packets be accurately classified before entering the ISP and that it is very easy for an ISP device to determine the traffic class for a particular packet.
如上所述，分组可以分为各种不同的业务类别。对于ISP操作，在进入ISP之前对数据包进行准确分类至关重要，并且ISP设备很容易确定特定数据包的通信量等级。
The traffic class of MPLS packets can be encoded in the three bits reserved for CoS within the MPLS label header. In addition, traffic classes for IPv4 packets can be classified via the IPv4 ToS byte, possibly within the three precedence bits within that byte. Note that the consistent interpretation of the traffic class, regardless of the bits used to indicate this class, is an important feature of PASTE.
MPLS数据包的流量类别可以在MPLS标签报头中为CoS保留的三个比特中编码。此外，IPv4数据包的流量类别可以通过IPv4 ToS字节进行分类，可能在该字节内的三个优先位内。请注意，无论用于指示该类的位是什么，流量类的一致解释都是PASTE的一个重要特性。
In this architecture it is not overly important to control which packets entering the ISP have a particular traffic class. From the ISP's perspective, each Priority packet should involve some economic premium for delivery. As a result the ISP need not pass judgment as to the appropriateness of the traffic class for the application.
在这种体系结构中，控制进入ISP的哪些数据包具有特定的流量等级并不太重要。从ISP的角度来看，每个优先级数据包都应该包含一定的经济溢价。因此，ISP无需对应用程序的流量等级是否合适进行判断。
It is important that any Network Control traffic entering an ISP be handled carefully. The contents of such traffic must also be carefully authenticated. Currently, there is no need for traffic generated external to a domain to transit a border router of the ISP.
重要的是，任何进入ISP的网络控制流量都必须小心处理。还必须仔细验证此类通信的内容。目前，不需要在域外部生成流量来传输ISP的边界路由器。
As described above, traffic of a single traffic class that is aggregated into a single LSP is called a traffic trunk, or simply a trunk. Trunks are essential to the architecture because they allow the overhead in the infrastructure to be decoupled from the size of the network and the amount of traffic in the network. Instead, as the traffic scales up, the amount of traffic in the trunks increases; not the number of trunks.
如上所述，聚合到单个LSP中的单个业务类别的业务称为业务主干，或简称为主干。中继对体系结构至关重要，因为它们允许基础设施中的开销与网络的大小和网络中的流量解耦。相反，随着交通量的增加，干线中的交通量增加；不是树干的数量。
The number of trunks within a given topology has a worst case of one trunk per traffic class from each entry router to each exit router. If there are N routers in the topology and C classes of service, this would be (N * (N-1) * C) trunks. Fortunately, instantiating this many trunks is not always necessary.
给定拓扑中的中继数在最坏的情况下是，从每个入口路由器到每个出口路由器的每个通信量类别有一个中继。如果拓扑中有N个路由器和C类服务，这将是（N*（N-1）*C）个中继。幸运的是，实例化这么多主干并不总是必要的。
Trunks with a single exit point which share a common internal path can be merged to form a single sink tree. The computation necessary to determine if two trunks can be merged is straightforward. If, when a trunk is being established, it intersects an existing trunk with the same traffic class and the same remaining explicit route, the new trunk can be spliced into the existing trunk at the point of intersection. The splice itself is straightforward: both incoming trunks will perform a standard label switching operation, but will result in the same outbound label. Since each sink tree created this way touches each router at most once and there is one sink tree per exit router, the result is N * C sink trees.
具有共享公共内部路径的单个出口点的主干可以合并为单个汇树。确定两个中继是否可以合并所需的计算非常简单。如果在建立主干时，它与具有相同交通等级和相同剩余显式路线的现有主干相交，则可以在交叉点处将新主干拼接到现有主干中。拼接本身很简单：两个传入中继都将执行标准的标签交换操作，但会产生相同的出站标签。由于以这种方式创建的每个接收器树最多接触每个路由器一次，并且每个出口路由器有一个接收器树，因此结果是N*C个接收器树。
The number of trunks or sink trees can also be reduced if multiple trunks or sink trees for different classes follow the same path. This works because the traffic class of a trunk or sink tree is orthogonal to the path defined by its LSP. Thus, two trunks with different traffic classes can share a label for any part of the topology that is shared and ends in the exit router. Thus, the entire topology can be overlaid with N trunks.
如果不同等级的多个树干或下沉树遵循相同的路径，那么树干或下沉树的数量也可以减少。这是因为主干树或汇树的流量类与其LSP定义的路径正交。因此，具有不同流量等级的两个中继可以共享拓扑中任何部分的标签，该拓扑共享并在出口路由器中结束。因此，整个拓扑可以覆盖N个中继。
Further, if Best Effort trunks and individual Best Effort flows are treated identically, there is no need to instantiate any Best Effort trunk that would follow the IGP computed path. This is because the packets can be directly forwarded without an LSP. However, traffic engineering may require Best Effort trunks to be treated differently from the individual Best Effort flows, thus requiring the instantiation of LSPs for Best Effort trunks. Note that Priority trunks must be instantiated because end-to-end RSVP packets to support the aggregated Priority flows must be tunneled.
此外，如果对尽力而为中继和单个尽力而为流进行相同的处理，则不需要实例化任何将遵循IGP计算路径的尽力而为中继。这是因为数据包可以在没有LSP的情况下直接转发。然而，流量工程可能要求对尽力而为中继进行不同于单个尽力而为流的处理，因此需要为尽力而为中继实例化LSP。请注意，必须实例化优先级中继，因为支持聚合优先级流的端到端RSVP数据包必须通过隧道传输。
Trunks can also be aggregated with other trunks by adding a new label to the stack of labels for each trunk, effectively bundling the trunks into a single tunnel. For the purposes of this document, this is also considered a trunk, or if we need to be specific, this will be called an aggregated trunk. Two trunks can be aggregated if they share a portion of their path. There is no requirement on the exact length of the common portion of the path, and thus the exact requirements for forming an aggregated trunk are beyond the scope of this document. Note that traffic class (i.e., QoS indication) is propagated when an additional label is added to a trunk, so trunks of different classes may be aggregated.
还可以通过向每个中继的标签堆栈中添加新标签，将中继与其他中继聚合，从而有效地将中继捆绑到单个隧道中。在本文档中，这也被视为主干，或者如果我们需要具体说明，这将被称为聚合主干。如果两个中继共享一部分路径，则可以聚合它们。对路径公共部分的确切长度没有要求，因此形成聚合主干的确切要求超出了本文档的范围。请注意，当向中继添加附加标签时，会传播流量类别（即QoS指示），因此可以聚合不同类别的中继。
Trunks can be terminated at any point, resulting in a deaggregation of traffic. The obvious consequence is that there needs to be sufficient switching capacity at the point of deaggregation to deal with the resultant traffic.
中继可以在任何点终止，从而导致流量的非聚集。显而易见的结果是，在解聚集点需要有足够的交换容量来处理由此产生的流量。
High reliability for a trunk can be provided through the use of one or more backup trunks. Backup trunks can be initiated either by the same router that would initiate the primary trunk or by another backup router. The status of the primary trunk can be ascertained by the router that initiated the backup trunk (note that this may be either the same or a different router as the router that initiated the primary trunk) through out of band information, such as the IGP. If a backup trunk is established and the primary trunk returns to service, the backup trunk can be deactivated and the primary trunk used instead.
通过使用一个或多个备份中继，可以为中继提供高可靠性。备份中继可以由启动主中继的同一路由器启动，也可以由另一个备份路由器启动。主中继的状态可以通过带外信息（如IGP）由启动备份中继的路由器确定（注意，这可能是与启动主中继的路由器相同或不同的路由器）。如果建立了备份中继，并且主中继恢复服务，则可以停用备份中继并使用主中继。
Originally RSVP was designed as a protocol to install state associated with resource reservations for individual flows originated/destined to hosts, where path was determined by destination-based routing. Quoting directly from the RSVP specifications, "The RSVP protocol is used by a host, on behalf of an application data stream, to request a specific quality of service (QoS) from the network for particular data streams or flows" [RFC2205].
最初，RSVP被设计为一种协议，用于为源于/目的地为主机的各个流安装与资源保留相关的状态，其中路径由基于目的地的路由确定。直接引用RSVP规范，“RSVP协议由主机代表应用程序数据流使用，以从网络请求特定数据流或流的特定服务质量（QoS）”[RFC2205]。
The usage of RSVP in PASTE is quite different from the usage of RSVP as it was originally envisioned by its designers. The first difference is that RSVP is used in PASTE to install state that applies to a collection of flows that all share a common path and common pool of reserved resources. The second difference is that RSVP is used in PASTE to install state related to forwarding, including label switching information, in addition to resource reservations. The third difference is that the path that this state is installed along is no longer constrained by the destination-based routing.
RSVP在PASTE中的用法与RSVP的用法完全不同，RSVP最初是由其设计者设想的。第一个区别是，RSVP在“粘贴到安装”状态中使用，该状态应用于所有共享公共路径和公共保留资源池的流集合。第二个区别是，在粘贴中使用RSVP来安装与转发相关的状态，包括标签切换信息，以及资源保留。第三个区别是，安装此状态的路径不再受基于目标的路由的约束。
The key factor that makes RSVP suitable for PASTE is the set of mechanisms provided by RSVP. Quoting from the RSVP specifications, "RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths." Moreover, RSVP provides a straightforward extensibility mechanism by allowing for the creation of new RSVP Objects. This flexibility allows us to also use the mechanisms provided by RSVP to create and maintain distributed state for information other than pure resource reservation, as well as allowing the creation of forwarding state in conjunction with resource reservation state.
使RSVP适合粘贴的关键因素是RSVP提供的一组机制。引用RSVP规范，“RSVP协议机制提供了一种通用的工具，用于在多播或单播交付路径的网格中创建和维护分布式保留状态。”此外，RSVP通过允许创建新的RSVP对象，提供了一种简单的扩展机制。这种灵活性还允许我们使用RSVP提供的机制来创建和维护除纯资源保留之外的信息的分布式状态，并允许创建转发状态和资源保留状态。
The original RSVP design, in which "RSVP itself transfers and manipulates QoS control parameters as opaque data, passing them to the appropriate traffic control modules for interpretation" can thus be extended to include explicit route parameters and label binding parameters. Just as with QoS parameters, RSVP can transfer and manipulate explicit route parameters and label binding parameters as opaque data, passing explicit route parameters to the appropriate forwarding module, and label parameters to the appropriate MPLS module.
最初的RSVP设计“RSVP本身将QoS控制参数作为不透明数据进行传输和操作，并将其传递给适当的流量控制模块进行解释”，因此可以扩展到包括显式路由参数和标签绑定参数。与QoS参数一样，RSVP可以将显式路由参数和标签绑定参数作为不透明数据进行传输和操作，将显式路由参数传递给适当的转发模块，并将标签参数传递给适当的MPLS模块。
Moreover, an RSVP session in PASTE is not constrained to be only between a pair of hosts, but is also used between pairs of routers that act as the originator and the terminator of a traffic trunk.
此外，PASTE中的RSVP会话不仅限于一对主机之间，而且还用于充当流量中继的发起方和终止方的路由器对之间。
Using RSVP in PASTE helps consolidate procedures for several tasks: (a) procedures for establishing forwarding along an explicit route, (b) procedures for establishing a label switched path, and (c) RSVP's existing procedures for resource reservation. In addition, these functions can be cleanly combined in any manner. The main advantage of this consolidation comes from an observation that the above three tasks are not independent, but inter-related. Any alternative that accomplished each of these functions via independent sets of procedures, would require additional coordination between functions, adding more complexity to the system.
在粘贴中使用RSVP有助于整合多个任务的过程：（a）沿显式路由建立转发的过程，（b）建立标签交换路径的过程，以及（c）RSVP现有的资源保留过程。此外，这些功能可以以任何方式干净地组合在一起。这种整合的主要优势来自于观察到上述三项任务不是独立的，而是相互关联的。任何通过独立程序集实现这些功能的替代方案都需要功能之间的额外协调，从而增加系统的复杂性。
The purpose of traffic engineering is to give the ISP precise control over the flow of traffic within its network. Traffic engineering is necessary because standard IGPs compute the shortest path across the ISP's network based solely on the metric that has been administratively assigned to each link. This computation does not take into account the loading of each link. If the ISP's network is not a full mesh of physical links, the result is that there may not be an obvious way to assign metrics to the existing links such that no congestion will occur given known traffic patterns. Traffic engineering can be viewed as assistance to the routing infrastructure that provides additional information in routing traffic along specific paths, with the end goal of more efficient utilization of networking resources.
流量工程的目的是让ISP精确控制其网络中的流量。流量工程是必要的，因为标准IGP仅基于管理分配给每个链路的度量来计算ISP网络中的最短路径。此计算不考虑每个链路的负载。如果ISP的网络不是物理链路的完整网格，结果可能是没有一种明显的方法来为现有链路分配度量，从而在已知流量模式下不会发生拥塞。流量工程可被视为对路由基础设施的帮助，该基础设施在沿特定路径路由流量时提供附加信息，最终目标是更有效地利用网络资源。
Traffic engineering is performed by directing trunks along explicit paths within the ISP's topology. This diverts the traffic away from the shortest path computed by the IGP and presumably onto uncongested links, eventually arriving at the same destination. Specification of the explicit route is done by enumerating an explicit list of the routers in the path. Given this list, traffic engineering trunks can be constructed in a variety of ways. For example, a trunk could be manually configured along the explicit path. This would involve configuring each router along the path with state information for forwarding the particular label. Such techniques are currently used for traffic engineering in some ISPs today.
流量工程是通过沿ISP拓扑内的显式路径引导中继来执行的。这会将流量从IGP计算的最短路径转移到未阻塞的链路上，最终到达同一目的地。通过枚举路径中路由器的显式列表来指定显式路由。根据该列表，交通工程干线可以采用多种方式建造。例如，可以沿显式路径手动配置主干。这将涉及使用状态信息沿路径配置每个路由器，以转发特定标签。这些技术目前在一些ISP中用于流量工程。
Alternately, a protocol such as RSVP can be used with an Explicit Route Object (ERO) so that the first router in the path can establish the trunk. The computation of the explicit route is beyond the scope of this document but may include considerations of policy, static and dynamic bandwidth allocation, congestion in the topology and manually configured alternatives.
或者，诸如RSVP之类的协议可以与显式路由对象（ERO）一起使用，以便路径中的第一个路由器可以建立中继。显式路由的计算超出了本文档的范围，但可能包括策略、静态和动态带宽分配、拓扑中的拥塞以及手动配置的备选方案。
Priority traffic has certain requirements on capacity and traffic handling. To provide differentiated services, the ISP's infrastructure must know of, and support these requirements. The mechanism used to communicate these requirements dynamically is RSVP. The flow specification within RSVP can describe many characteristics of the flow or trunk. An LSR receiving RSVP information about a flow or trunk has the ability to look at this information and either accept or reject the reservation based on its local policy. This policy is likely to include constraints about the traffic handling functions that can be supported by the network and the aggregate capacity that the network is willing to provide for Priority traffic.
优先流量对容量和流量处理有一定的要求。要提供差异化服务，ISP的基础设施必须了解并支持这些要求。用于动态传达这些需求的机制是RSVP。RSVP中的流规范可以描述流或主干的许多特性。接收有关流或中继的RSVP信息的LSR能够查看此信息，并根据其本地策略接受或拒绝保留。该策略可能包括关于网络可支持的流量处理功能以及网络愿意为优先流量提供的总容量的约束。
Trunks that span multiple ISPs are likely to be based on legal agreements and some other external considerations. As a result, one of the common functions that we would expect to see in this type of architecture is a bilateral agreement between ISPs to support differentiated services. In addition to the obvious compensation, this agreement is likely to spell out the acceptable traffic handling policies and capacities to be used by both parties.
跨越多个ISP的中继可能基于法律协议和其他一些外部考虑。因此，我们期望在这种体系结构中看到的共同功能之一是ISP之间的双边协议，以支持差异化服务。除了明显的补偿外，本协议可能会详细说明双方可接受的交通处理政策和通行能力。
Documents similar to this exist today on behalf of Best Effort traffic and are known as peering agreements. Extending a peering agreement to support differentiated services would effectively create an Inter-Provider SLA (IPS). Such agreements may include the types of differentiated services that one ISP provides to the other ISP, as well as the upper bound on the amount of traffic associated with each such service that the ISP would be willing to accept and carry from the other ISP. Further, an IPS may limit the types of differentiated services and an upper bound on the amount of traffic that may originate from a third party ISP and be passed from one signer of the IPS to the other.
与此类似的文档今天代表Best Effort流量存在，称为对等协议。扩展对等协议以支持差异化服务将有效地创建供应商间SLA（IPS）。此类协议可能包括一家ISP向另一家ISP提供的差异化服务的类型，以及ISP愿意接受并从另一家ISP获得的与每项此类服务相关的流量上限。此外，IPS可以限制区分服务的类型以及可能来自第三方ISP并且可以从IPS的一个签名者传递到另一个签名者的流量的上限。
If the expected costs associated with the IPS are not symmetric, the parties may agree that one ISP will provide the other ISP with appropriate compensation. Such costs may be due to inequality of traffic exchange, costs in delivering the exchanged traffic, or the overhead involved in supporting the protocols exchanged between the two ISPs.
如果与IP相关的预期成本不对称，双方可同意一家ISP向另一家ISP提供适当的补偿。这种成本可能是由于流量交换的不平等性、传递交换流量的成本或支持两个ISP之间交换的协议所涉及的开销造成的。
Note that the PASTE architecture provides a technical basis to establish IPSs, while the procedures necessary to create such IPSs are outside the scope of PASTE.
请注意，粘贴体系结构为建立IPSs提供了技术基础，而创建此类IPSs所需的程序不在粘贴的范围之内。
To help support IPSs, special facilities must be available at the interconnect between ISPs. These mechanisms are necessary to insure that the network transmitting a trunk of Priority traffic does so within the agreed traffic characterization and capacity. A simplistic example of such a mechanism might be a token bucket system, implemented on a per-trunk basis. Similarly, there need to be mechanisms to insure, on a per trunk basis, that an ISP receiving a trunk receives only the traffic that is in compliance with the agreement between ISPs.
为了帮助支持IPSs，必须在ISP之间的互连处提供特殊设施。这些机制对于确保传输优先级业务主干的网络在约定的业务特征和容量范围内传输是必要的。这种机制的一个简单示例可能是基于每个中继实现的令牌桶系统。类似地，需要有机制来确保在每个中继的基础上，接收中继的ISP只接收符合ISP之间协议的流量。
Trunks may span multiple ISPs. As a result, establishing a particular trunk may require more than two ISPs. The result would be a multilateral IPS. This type of agreement is unusual with respect to existing Internet business practices in that it requires multiple participating parties for a useful result. This is also challenging because without a commonly accepted service level definition, there will need to be a multilateral definition, and this definition may not be compatible used in IPSs between the same parties.
中继可以跨越多个ISP。因此，建立一个特定的中继可能需要两个以上的ISP。结果将是一场多边谈判。这种类型的协议对于现有的互联网商业实践来说是不寻常的，因为它需要多个参与方才能获得有用的结果。这也是一个挑战，因为如果没有一个普遍接受的服务级别定义，就需要有一个多边定义，而这一定义可能与IPSs中使用的同一方不兼容。
Because this new type of agreement may be a difficulty, it may in some cases be simpler for certain ISPs to establish aggregated trunks through other ISPs and then contract with customers to aggregate their trunks. In this way, trunks can span multiple ISPs without requiring multilateral IPSs.
由于这种新型协议可能是一个难题，因此在某些情况下，某些ISP通过其他ISP建立聚合中继，然后与客户签订合同聚合其中继，可能会更简单。通过这种方式，中继线可以跨越多个ISP，而无需多边IPS。
Either or both of these two alternatives are possible and acceptable within this architecture, and the choice is left for the the participants to make on a case-by-case basis.
在这个架构中，这两个备选方案中的一个或两个都是可能的和可接受的，并且由参与者根据具体情况做出选择。
5.0 The Provider Architecture for differentiated Services and Traffic Engineering (PASTE)
5.0 差异化服务和流量工程的提供商体系结构（PASTE）
The Provider Architecture for differentiated Services and Traffic Engineering (PASTE) is based on the usage of MPLS and RSVP as mechanisms to establish differentiated service connections across ISPs. This is done in a scalable way by aggregating differentiated flows into traffic class specific MPLS tunnels, also known as traffic trunks.
区分服务和流量工程的提供商体系结构（PASTE）基于MPLS和RSVP作为跨ISP建立区分服务连接的机制。这是通过将不同的流聚合到特定于流量类别的MPLS隧道（也称为流量中继）中，以可伸缩的方式实现的。
Such trunks can be given an explicit route by an ISP to define the placement of the trunk within the ISP's infrastructure, allowing the ISP to traffic engineer its own network. Trunks can also be aggregated and merged, which helps the scalability of the architecture by minimizing the number of individual trunks that intermediate systems must support.
ISP可以为此类中继提供明确的路由，以定义中继在ISP基础设施中的位置，从而允许ISP对自己的网络进行流量工程。中继还可以聚合和合并，这有助于通过最小化中间系统必须支持的单个中继的数量来提高体系结构的可伸缩性。
Special traffic handling operations, such as specific queuing algorithms or drop computations, can be supported by a network on a per-trunk basis, allowing these services to scale with the number of trunks in the network.
特定的流量处理操作，例如特定的排队算法或丢包计算，可以由网络在每个中继的基础上支持，从而允许这些服务随着网络中中继的数量而扩展。
Agreements for handling of trunks between ISPs require both legal documentation and conformance mechanisms on both sides of the agreement. As a trunk is unidirectional, it is sufficient for the transmitter to monitor and shape outbound traffic, while the receiver polices the traffic profile.
ISP之间的中继处理协议要求协议双方提供法律文件和合规机制。由于中继线是单向的，发送器监视和塑造出站流量就足够了，而接收器则对流量配置文件进行策略。
Trunks can either be aggregated across other ISPs or can be the subject of a multilateral agreement for the carriage of the trunk. RSVP information about individual flows is tunneled in the trunk to provide an end-to-end reservation. To insure that the return RSVP traffic is handled properly, each trunk must also have another tunnel running in the opposite direction. Note that the reverse tunnel may be a different trunk or it may be an independent tunnel terminating at the same routers as the trunk. Routing symmetry between a trunk and its return is not assumed.
中继线可以跨其他ISP聚合，也可以是中继线运输多边协议的主体。有关单个流的RSVP信息通过隧道传输到中继中，以提供端到端预留。为了确保返回的RSVP流量得到正确处理，每个中继线还必须有另一条反向运行的隧道。请注意，反向隧道可以是不同的主干，也可以是独立的隧道，终止于与主干相同的路由器。不假设主干与其返回之间的路由对称。
RSVP already contains the ability to do local path repair. In the event of a trunk failure, this capability, along with the ability to specify abstractions in the ERO, allows RSVP to re-establish the trunk in many failure scenarios.
RSVP已经包含执行本地路径修复的功能。在中继失败的情况下，此功能以及在ERO中指定抽象的功能允许RSVP在许多故障场景中重新建立中继。
As an example of the operation of this architecture, we consider an example of a single differentiated flow. Suppose that a user wishes to make a telephone call using a Voice over IP service. While this call is full duplex, we can consider the data flow in each direction in a half duplex fashion because the architecture operates symmetrically.
作为这种体系结构的操作的一个例子，我们考虑一个单一的差异流的例子。假设用户希望使用IP语音服务拨打电话。虽然这个调用是全双工的，但是我们可以考虑半双工方式在每个方向上的数据流，因为体系结构对称地工作。
Suppose that the data packets for this voice call are created at a node S and need to traverse to node D. Because this is a voice call, the data packets are encoded as Priority packets. If there is more granularity within the traffic classes, these packets might be encoded as wanting low jitter and having low drop preference. Initially this is encoded into the precedence bits of the IPv4 ToS byte.
假设此语音呼叫的数据包是在节点S处创建的，需要遍历到节点D。因为这是语音呼叫，所以数据包被编码为优先级数据包。如果在流量类中有更多的粒度，这些包可能被编码为需要低抖动和具有低丢弃偏好。最初，它被编码到IPv4 ToS字节的优先位中。
To establish the flow to node D, node S first generates an RSVP PATH message which describes the flow in more detail. For example, the flow might require 3kbps of bandwidth, be insensitive to jitter of less than 50ms, and require a delay of less than 200ms. This message is passed through node S's local network and eventually appears in node S's ISP. Suppose that this is ISP F.
为了建立到节点D的流，节点S首先生成RSVP PATH消息，该消息更详细地描述了流。例如，流可能需要3kbps的带宽，对小于50ms的抖动不敏感，并且需要小于200ms的延迟。此消息通过节点的本地网络传递，并最终出现在节点的ISP中。假设这是ispf。
ISP F has considerable latitude in its options at this point. The requirement on F is to place the flow into a trunk before it exits F's infrastructure. One thing that F might do is to perform the admission control function at the first hop router. At this point, F would determine if it had the capacity and capability of carrying the flow across its own infrastructure to an exit router E. If the admission control decision is negative, the first hop router can
ISPF在这一点上有相当大的选择余地。对F的要求是在流退出F的基础设施之前将其放入主干中。F可以做的一件事是在第一跳路由器上执行接纳控制功能。在这一点上，F将确定它是否有能力将流通过其自身的基础设施传输到出口路由器E。如果准入控制决定是否定的，则第一跳路由器可以
inform node S using RSVP. Alternately, it can propagate the RSVP PATH message along the path to exit router E. This is simply normal operation of RSVP on a differentiated flow.
使用RSVP通知节点。或者，它可以沿着路径传播RSVP PATH消息以退出路由器E。这只是RSVP在区分流上的正常操作。
At exit router E, there is a trunk that ISP F maintains that transits ISP X, Y, and Z and terminates in ISP L. Based on BGP path information or on out of band information, Node D is known to be a customer of ISP L. Exit router E matches the flow requirements in the RSVP PATH message to the characteristics (e.g., remaining capacity) of the trunk to ISP L. Assuming that the requirements are compatible, it then notes that the flow should be aggregated into the trunk.
在出口路由器E处，有一个由ISP F维护的中继，该中继传输ISP X、Y和Z并终止于ISP L。根据BGP路径信息或带外信息，已知节点D是ISP L的客户。出口路由器E将RSVP路径消息中的流量要求与特征（例如，剩余容量）相匹配假设需求是兼容的，那么它注意到流应该聚合到主干中。
To insure that the flow reservation happens end to end, the RSVP PATH message is then encapsulated into the trunk itself, where it is transmitted to ISP L. It eventually reaches the end of the trunk, where it is decapsulated by router U. PATH messages are then propagated all the way to the ultimate destination D.
为了确保流保留发生端到端，RSVP PATH消息随后被封装到主干中，并在那里传输到ISP L。它最终到达主干的末端，在那里被路由器U解除封装。然后，路径消息被传播到最终目的地D。
Note that the end-to-end RSVP RESV messages must be carefully handled by router U. The RESV messages from router U to E must return via a tunnel back to router E.
请注意，路由器U必须小心处理端到端RSVP RESV消息。从路由器U到E的RESV消息必须通过隧道返回到路由器E。
RSVP is also used by exit router E to initialize and maintain the trunk to ISP L. The RSVP messages for this trunk are not placed within the trunk itself but the end-to-end RSVP messages are. The existence of multiple overlapping RSVP sessions in PASTE is straightforward, but requires explicit enumeration when discussing particular RSVP sessions.
出口路由器E也使用RSVP来初始化和维护到ISP L的中继线。此中继线的RSVP消息不放在中继线本身中，而是端到端RSVP消息。PASTE中存在多个重叠的RSVP会话很简单，但在讨论特定RSVP会话时需要显式枚举。
Data packets created by S flow through ISP F's network following the flow reservation and eventually make it to router E. At that point, they are given an MPLS label and placed in the trunk. Normal MPLS switching will propagate this packet across ISP X's network. Note that the same traffic class still applies because the class encoding is propagated from the precedence bits of the IPv4 header to the CoS bits in the MPLS label. As the packet exits ISP X's network, it can be aggregated into another trunk for the express purpose of tranisiting ISP Y.
由S创建的数据包在流保留之后通过ISP F的网络，并最终到达路由器E。在这一点上，它们被赋予MPLS标签并放置在中继中。正常的MPLS交换将通过ISP X的网络传播此数据包。请注意，由于类编码是从IPv4报头的优先位传播到MPLS标签中的CoS位，因此相同的流量类仍然适用。当数据包离开ISP X的网络时，它可以聚合到另一个主干中，以便传输ISP Y。
Again, label switching is used to bring the packet across ISP Y's network and then the aggregated trunk terminates at a router in ISP Z's network. This router deaggregates the trunk, and forwards the resulting trunk towards ISP L. This trunk transits ISP Z and terminates in ISP L at router U. At this point, the data packets are removed from the trunk and forwarded along the path computed by RSVP.
同样，标签交换用于将数据包带过ISP Y的网络，然后聚合中继终止于ISP Z网络中的路由器。该路由器解聚合中继线，并将生成的中继线转发给ISP L。该中继线传输ISP Z并在路由器U的ISP L中终止。此时，数据包从中继线中移除，并沿RSVP计算的路径转发。
In this example, there are two trunks in use. One trunk runs from ISP F, through ISPs X, Y and Z, and then terminates in ISP L. The other aggregated trunk begins in ISP X, transits ISP Y and terminates in ISP Z.
在本例中，有两个中继正在使用。一个中继从ISP F运行，经过ISP X、Y和Z，然后终止于ISP L。另一个聚合中继从ISP X开始，传输ISP Y并终止于ISP Z。
The first trunk may be established based on a multilateral agreement between ISPs F, X, Z and L. Note that ISP Y is not part of this multilateral agreement, and ISP X is contractually responsible for providing carriage of the trunk into ISP Z. Also per this agreement, the tunnel is maintained by ISP F and is initialized and maintained through the use of RSVP and an explicit route object that lists ISP's X, Z, and L. Within this explicit route, ISP X and ISP L are given as strict hops, thus constraining the path so that there may not be other ISPs intervening between the pair of ISPs F and X and the pair Z and L. However, no constraint is placed on the path between ISPs X and Z. Further, there is no constraint placed on which router terminates the trunk within L's infrastructure.
第一条中继线可根据ISP F、X、Z和L之间的多边协议建立。请注意，ISP Y不是本多边协议的一部分，ISP X根据合同负责将中继线运输至ISP Z。同样根据本协议，隧道由ISP F维护，并通过使用RSVP和列出ISP的X、Z和L的显式路由对象进行初始化和维护。在此显式路由中，ISP X和ISP L作为严格跳数给出，因此，对路径进行约束，以便在ISP对F和X以及ISP对Z和L之间可能不会有其他ISP介入。但是，ISP X和Z之间的路径没有约束。此外，在L的基础设施中，路由器终止中继的位置没有约束。
Normally this trunk is maintained by one of ISP F's routers adjacent to ISP X. For robustness, ISP F has a second router adjacent to ISP X, and that provides a backup trunk.
通常，该中继线由ISP F的一个路由器与ISP X相邻来维护。为保证健壮性，ISP F在ISP X附近有第二个路由器，该路由器提供了一个备份中继线。
The second trunk may be established by a bilateral agreement between ISP X and Y. ISP Z is not involved. The second trunk is constrained so that it terminates on the last hop router within Y's infrastructure. This tunnel is initialized and maintained through the use of RSVP and an explicit route that lists the last hop router within ISP Y's infrastructure. In order to provide redundancy in the case of the failure of the last hop router, there are multiple explicit routes configured into ISP X's routers. These routers can select one working explicit route from their configured list. Further, in order to provide redundancy against the failure of X's primary router, X provides a backup router with a backup trunk.
第二条中继线可以通过ISP X和Y之间的双边协议建立。ISP Z不参与。第二个中继受到约束，因此它在Y的基础结构中的最后一个跃点路由器上终止。该隧道通过使用RSVP和一条显式路由（列出ISP Y基础设施中的最后一跳路由器）进行初始化和维护。为了在最后一跳路由器发生故障时提供冗余，ISP X的路由器中配置了多条显式路由。这些路由器可以从其配置的列表中选择一个工作显式路由。此外，为了针对X的主路由器的故障提供冗余，X提供了一个带有备份中继的备份路由器。
Note that in this example, there are no single points of failure once the traffic is within ISP F's network. Each trunk has a backup trunk to protect against the failure of the primary trunk. To protect against the failure of any particular router, each trunk can be configured with multiple explicit route objects that terminate at one of several acceptable routers.
请注意，在本例中，一旦流量在ISP F的网络内，就不会出现单点故障。每个中继都有一个备用中继，以防止主中继出现故障。为了防止任何特定路由器出现故障，每个中继可以配置多个显式路由对象，这些对象终止于多个可接受的路由器之一。
Because Priority traffic intrinsically has more 'value' than Best Effort traffic, the ability to inject Priority traffic into a network must be carefully controlled. Further, signaling concerning Priority traffic has to be authenticated because it is likely that the signaling information will result in specific accounting and eventually billing for the Priority services. ISPs are cautioned to insure that the Priority traffic that they accept is in fact from a known previous hop. Note that this is a simple requirement to fulfill at private peerings, but it is much more difficult at public interconnects. For this reason, exchanging Priority traffic at public interconnects should be done with great care.
由于优先级流量本质上比尽力而为的流量具有更多的“价值”，因此必须仔细控制将优先级流量注入网络的能力。此外，必须对关于优先级业务的信令进行认证，因为信令信息很可能会导致针对优先级服务的特定计费和最终计费。ISP应注意确保他们接受的优先级流量实际上来自已知的前一跳。请注意，这是一个在专用对等上实现的简单要求，但在公共互连上要困难得多。因此，在公共互连上交换优先级流量时应非常小心。
RSVP traffic needs to be authenticated. This can possibly be done through the use of the Integrity Object.
RSVP通信需要进行身份验证。这可以通过使用Integrity对象来实现。
The Provider Architecture for differentiated Services and Traffic Engineering (PASTE) provides a robust, scalable means of deploying differentiated services in the Internet. It provides scalability by aggregating flows into class specific MPLS tunnels. These tunnels, also called trunks, can in turn be aggregated, thus leading to a hierarchical aggregation of traffic.
区分服务和流量工程的提供商体系结构（PASTE）提供了一种在Internet上部署区分服务的健壮、可扩展的方法。它通过将流聚合到特定于类的MPLS隧道中来提供可伸缩性。这些隧道（也称为中继）可以依次聚合，从而导致流量的分层聚合。
Trunk establishment and maintenance is done with RSVP, taking advantage of existing work in differentiated services. Explicit routes within the RSVP signaling structure allow providers to perform traffic engineering by placing trunks on particular links in their network.
中继线的建立和维护是通过RSVP完成的，它利用了差异化服务中的现有工作。RSVP信令结构中的显式路由允许提供商通过在其网络中的特定链路上放置中继来执行流量工程。
The result is an architecture that is sufficient to scale to meet ISP needs and can provide differentiated services in the large, support traffic engineering, and continue to grow with the Internet.
其结果是形成了一个足以扩展以满足ISP需求的体系结构，并且能够在大型网络中提供差异化服务，支持流量工程，并随着互联网的发展而不断增长。
Inspiration and comments about this document came from Noel Chiappa, Der-Hwa Gan, Robert Elz, Lisa Bourgeault, and Paul Ferguson.
关于本文件的灵感和评论来自诺埃尔·基亚帕、德华·甘、罗伯特·埃尔兹、丽莎·布热奥和保罗·弗格森。
[1] Rosen, E., Viswanathan, A., and R. Callon, "A Proposed Architecture for MPLS", Work in Progress.
[1] Rosen，E.，Viswanathan，A.，和R.Callon，“MPLS的拟议架构”，正在进行中。
[2] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[2] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow,, G., Li, T., and A. Conta, "MPLS Label Stack Encoding", Work in Progress.
[3] Rosen，E.，Rekhter，Y.，Tappan，D.，Farinaci，D.，Fedorkow，，G.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，工作正在进行中。
[4] Davie, B., Rekhter, Y., Rosen, E., Viswanathan, A., and V. Srinivasan, "Use of Label Switching With RSVP", Work in Progress.
[4] Davie，B.，Rekhter，Y.，Rosen，E.，Viswanathan，A.，和V.Srinivasan，“使用RSVP进行标签切换”，工作正在进行中。
[5] Gan, D.-H., Guerin, R., Kamat, S., Li, T., and E. Rosen, "Setting up Reservations on Explicit Paths using RSVP", Work in Progress.
[5] Gan，D-H.，Guerin，R.，Kamat，S.，Li，T.，和E.Rosen，“使用RSVP在显式路径上设置保留”，工作正在进行中。
[6] Davie, B., Li, T., Rosen, E., and Y. Rekhter, "Explicit Route Support in MPLS", Work in Progress.
[6] Davie，B.，Li，T.，Rosen，E.，和Y.Rekhter，“MPLS中的显式路由支持”，正在进行中。
[7] http://www.anxo.com/
[7] http://www.anxo.com/
Tony Li Juniper Networks, Inc. 385 Ravendale Dr. Mountain View, CA 94043
Tony Li Juniper Networks，Inc.加利福尼亚州拉文代尔山景城385号，邮编94043
Phone: +1 650 526 8006
Fax: +1 650 526 8001
EMail: tli@juniper.net
Phone: +1 650 526 8006
Fax: +1 650 526 8001
EMail: tli@juniper.net
Yakov Rekhter cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134
雅科夫·雷克特思科系统公司，170 W.塔斯曼博士，加利福尼亚州圣何塞，邮编95134
EMail: yakov@cisco.com
EMail: yakov@cisco.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。