Network Working Group B. Davie
Request for Comments: 3035 J. Lawrence
Category: Standards Track K. McCloghrie
E. Rosen
G. Swallow
Cisco Systems, Inc.
Y. Rekhter
Juniper Networks
P. Doolan
Ennovate Networks, Inc.
January 2001
Network Working Group B. Davie
Request for Comments: 3035 J. Lawrence
Category: Standards Track K. McCloghrie
E. Rosen
G. Swallow
Cisco Systems, Inc.
Y. Rekhter
Juniper Networks
P. Doolan
Ennovate Networks, Inc.
January 2001
MPLS using LDP and ATM VC Switching
使用LDP和ATM-VC交换的MPLS
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
The Multiprotocol Label Switching (MPLS) Architecture [1] discusses a way in which Asynchronous Transfer Mode (ATM) switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs (Label Switching Routers).
多协议标签交换（MPLS）体系结构[1]讨论了异步传输模式（ATM）交换机可用作标签交换路由器的方法。ATM交换机运行网络层路由算法（如开放最短路径优先（OSPF）、中间系统到中间系统（IS-IS）等），其数据转发基于这些路由算法的结果。不需要ATM特定的路由或寻址。以这种方式使用的ATM交换机称为ATM LSR（标签交换路由器）。
This document extends and clarifies the relevant portions of [1] and [2] by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see [1]) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms.
本文件扩展并澄清了[1]和[2]的相关部分，详细说明了在向ATM LSR分发标签或从ATM LSR分发标签时使用的程序，这些标签表示转发等价类（FEC，请参见[1]），网络层路由算法在逐跳的基础上为其确定路由。
This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to [3].
本文件还规定了向ATM LSR发送或从ATM LSR发送标记数据包时使用的MPLS封装，在这方面，本文件是[3]的配套文件。
Table of Contents
目录
1 Introduction ........................................... 2
2 Specification of Requirements .......................... 3
3 Definitions ............................................ 3
4 Special Characteristics of ATM Switches ................ 4
5 Label Switching Control Component for ATM .............. 5
6 Hybrid Switches (Ships in the Night) ................... 5
7 Use of VPI/VCIs ....................................... 5
7.1 Direct Connections ..................................... 6
7.2 Connections via an ATM VP .............................. 7
7.3 Connections via an ATM SVC ............................. 7
8 Label Distribution and Maintenance Procedures .......... 7
8.1 Edge LSR Behavior ...................................... 8
8.2 Conventional ATM Switches (non-VC-merge) ............... 9
8.3 VC-merge-capable ATM Switches .......................... 11
9 Encapsulation .......................................... 12
10 TTL Manipulation ....................................... 13
11 Optional Loop Detection: Distributing Path Vectors ..... 15
11.1 When to Send Path Vectors Downstream ................... 15
11.2 When to Send Path Vectors Upstream ..................... 16
12 Security Considerations ................................ 17
13 Intellectual Property Considerations ................... 17
14 References ............................................. 18
15 Acknowledgments ........................................ 18
16 Authors' Addresses ..................................... 18
17 Full Copyright Statement ............................... 20
1 Introduction ........................................... 2
2 Specification of Requirements .......................... 3
3 Definitions ............................................ 3
4 Special Characteristics of ATM Switches ................ 4
5 Label Switching Control Component for ATM .............. 5
6 Hybrid Switches (Ships in the Night) ................... 5
7 Use of VPI/VCIs ....................................... 5
7.1 Direct Connections ..................................... 6
7.2 Connections via an ATM VP .............................. 7
7.3 Connections via an ATM SVC ............................. 7
8 Label Distribution and Maintenance Procedures .......... 7
8.1 Edge LSR Behavior ...................................... 8
8.2 Conventional ATM Switches (non-VC-merge) ............... 9
8.3 VC-merge-capable ATM Switches .......................... 11
9 Encapsulation .......................................... 12
10 TTL Manipulation ....................................... 13
11 Optional Loop Detection: Distributing Path Vectors ..... 15
11.1 When to Send Path Vectors Downstream ................... 15
11.2 When to Send Path Vectors Upstream ..................... 16
12 Security Considerations ................................ 17
13 Intellectual Property Considerations ................... 17
14 References ............................................. 18
15 Acknowledgments ........................................ 18
16 Authors' Addresses ..................................... 18
17 Full Copyright Statement ............................... 20
The MPLS Architecture [1] discusses the way in which ATM switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs.
MPLS体系结构[1]讨论了ATM交换机可用作标签交换路由器的方式。ATM交换机运行网络层路由算法（如OSPF、IS-IS等），其数据转发基于这些路由算法的结果。不需要ATM特定的路由或寻址。以这种方式使用的ATM交换机称为ATM LSR。
This document extends and clarifies the relevant portions of [1] and [2] by specifying in more detail the procedures which are to be used for distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see [1]) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. The label distribution technique described here is referred to in [1] as "downstream-on-demand". This label distribution technique MUST be used by ATM-LSRs that are not capable of "VC merge" (defined in section 3), and is OPTIONAL for ATM-LSRs that are capable of VC merge.
本文件扩展并澄清了[1]和[2]的相关部分，更详细地规定了当标签表示转发等价类（FEC，见[1]）时，用于向ATM LSR或从ATM LSR分发标签的程序其路由是通过网络层路由算法逐跳确定的。此处描述的标签分发技术在[1]中称为“下游随需应变”。这种标签分发技术必须由不能进行“VC合并”（定义见第3节）的ATM LSR使用，并且对于能够进行VC合并的ATM LSR是可选的。
This document does NOT specify the label distribution techniques to be used in the following cases:
本文件未规定在以下情况下使用的标签分发技术：
- the routes are explicitly chosen before label distribution begins, instead of being chosen on a hop-by-hop basis as label distribution proceeds,
- 在标签分发开始之前显式选择路由，而不是在标签分发过程中逐跳选择路由，
- the routes are intended to diverge in any way from the routes chosen by the conventional hop-by-hop routing at any time,
- 这些路由旨在随时以任何方式偏离传统逐跳路由选择的路由，
- the labels represent FECs that consist of multicast packets,
- 标签表示由多播数据包组成的FEC，
- the LSRs use "VP merge".
- LSR使用“VP合并”。
Further statements made in this document about ATM-LSR label distribution do not necessarily apply in these cases.
本文件中关于ATM-LSR标签分发的进一步说明不一定适用于这些情况。
This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to [3]. The specified encapsulation is to be used for multicast or explicitly routed labeled packets as well.
本文件还规定了向ATM LSR发送或从ATM LSR发送标记数据包时使用的MPLS封装，在这方面，本文件是[3]的配套文件。指定的封装也将用于多播或显式路由标记的数据包。
This document uses terminology from [1].
本文件使用[1]中的术语。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
A Label Switching Router (LSR) is a device which implements the label switching control and forwarding components described in [1].
标签交换路由器（LSR）是实现[1]中所述标签交换控制和转发组件的设备。
A label switching controlled ATM (LC-ATM) interface is an ATM interface controlled by the label switching control component. When a packet traversing such an interface is received, it is treated as a labeled packet. The packet's top label is inferred either from the contents of the VCI field or the combined contents of the VPI and VCI fields. Any two LDP peers which are connected via an LC-ATM interface will use LDP negotiations to determine which of these cases is applicable to that interface.
标签交换控制ATM（LC-ATM）接口是由标签交换控制组件控制的ATM接口。当接收到穿过此类接口的数据包时，它将被视为带标签的数据包。从VCI字段的内容或VPI和VCI字段的组合内容推断数据包的顶部标签。通过LC-ATM接口连接的任何两个LDP对等点将使用LDP协商来确定这些情况中的哪一种适用于该接口。
An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards cells between these interfaces, using labels carried in the VCI or VPI/VCI field, without reassembling the cells into frames before forwarding.
ATM-LSR是具有多个LC-ATM接口的LSR，使用VCI或VPI/VCI字段中携带的标签在这些接口之间转发信元，而无需在转发前将信元重新组装成帧。
A frame-based LSR is a LSR which forwards complete frames between its interfaces. Note that such a LSR may have zero, one or more LC-ATM interfaces.
基于帧的LSR是在其接口之间转发完整帧的LSR。注意，这样的LSR可能有零个、一个或多个LC-ATM接口。
Sometimes a single box may behave as an ATM-LSR with respect to certain pairs of interfaces, but may behave as a frame-based LSR with respect to other pairs. For example, an ATM switch with an ethernet interface may function as an ATM-LSR when forwarding cells between its LC-ATM interfaces, but may function as a frame-based LSR when forwarding frames from its ethernet to one of its LC-ATM interfaces. In such cases, one can consider the two functions (ATM-LSR and frame-based LSR) as being coresident in a single box.
有时，一个单独的框可以作为ATM-LSR（关于某些接口对），但也可以作为基于帧的LSR（关于其他接口对）。例如，具有以太网接口的ATM交换机在其LC-ATM接口之间转发信元时可以用作ATM-LSR，但在将帧从其以太网转发到其LC-ATM接口之一时可以用作基于帧的LSR。在这种情况下，可以将两个函数（ATM LSR和基于帧的LSR）视为单个框中的CORESID。
It is intended that an LC-ATM interface be used to connect two ATM-LSRs, or to connect an ATM-LSR to a frame-based LSR. The use of an LC-ATM interface to connect two frame-based LSRs is not considered in this document.
LC-ATM接口用于连接两个ATM LSR，或将ATM-LSR连接到基于帧的LSR。本文件不考虑使用LC-ATM接口连接两个基于帧的LSR。
An ATM-LSR domain is a set of ATM-LSRs which are mutually interconnected by LC-ATM interfaces.
ATM-LSR域是由LC-ATM接口相互连接的一组ATM LSR。
The Edge Set of an ATM-LSR domain is the set of frame-based LSRs which are connected to members of the domain by LC-ATM interfaces. A frame-based LSR which is a member of an Edge Set of an ATM-LSR domain may be called an Edge LSR.
ATM-LSR域的边缘集是通过LC-ATM接口连接到域成员的基于帧的LSR集。作为ATM-LSR域的边缘集的成员的基于帧的LSR可以称为边缘LSR。
VC-merge is the process by which a switch receives cells on several incoming VCIs and transmits them on a single outgoing VCI without causing the cells of different AAL5 PDUs to become interleaved.
VC合并是交换机在多个传入VCI上接收单元并在单个传出VCI上传输它们的过程，而不会导致不同AAL5 PDU的单元交错。
While the MPLS architecture permits considerable flexibility in LSR implementation, an ATM-LSR is constrained by the capabilities of the (possibly pre-existing) hardware and the restrictions on such matters as cell format imposed by ATM standards. Because of these constraints, some special procedures are required for ATM-LSRs.
虽然MPLS体系结构允许LSR实现具有相当大的灵活性，但ATM-LSR受到硬件（可能预先存在）能力和ATM标准对信元格式等问题的限制。由于这些限制，ATM LSR需要一些特殊程序。
Some of the key features of ATM switches that affect their behavior as LSRs are:
ATM交换机作为LSR影响其行为的一些关键特性包括：
- the label swapping function is performed on fields (the VCI and/or VPI) in the cell header; this dictates the size and placement of the label(s) in a packet.
- 标签交换功能在单元头中的字段（VCI和/或VPI）上执行；这决定了标签在数据包中的大小和位置。
- multipoint-to-point and multipoint-to-multipoint VCs are generally not supported. This means that most switches cannot support 'VC-merge' as defined above.
- 通常不支持多点对点和多点对多点VCs。这意味着大多数交换机不能支持上面定义的“VC合并”。
- there is generally no capability to perform a 'TTL-decrement' function as is performed on IP headers in routers.
- 通常不具备在路由器的IP头上执行“TTL递减”功能的能力。
This document describes ways of applying label switching to ATM switches which work within these constraints.
本文档描述了将标签交换应用于在这些约束条件下工作的ATM交换机的方法。
To support label switching an ATM switch MUST implement the control component of label switching. This consists primarily of label allocation, distribution, and maintenance procedures. Label binding information is communicated by several mechanisms, notably the Label Distribution Protocol (LDP) [2]. This document imposes certain requirements on the LDP.
为了支持标签交换，ATM交换机必须实现标签交换的控制组件。这主要包括标签分配、分发和维护程序。标签绑定信息通过多种机制进行通信，尤其是标签分发协议（LDP）[2]。本文件对自民党提出了某些要求。
This document considers only the case where the label switching control component uses information learned directly from network layer routing protocols. It is presupposed that the switch participates as a peer in these protocols (e.g., OSPF, IS-IS).
本文档仅考虑标签交换控制组件使用直接从网络层路由协议学习的信息的情况。假定交换机作为对等方参与这些协议（例如，OSPF、is-is）。
In some cases, LSRs make use of other protocols (e.g., RSVP, PIM, BGP) to distribute label bindings. In these cases, an ATM-LSR would need to participate in these protocols. However, these are not explicitly considered in this document.
在某些情况下，LSR使用其他协议（如RSVP、PIM、BGP）来分发标签绑定。在这些情况下，ATM-LSR需要参与这些协议。但是，本文件并未明确考虑这些问题。
Support of label switching on an ATM switch does NOT require the switch to support the ATM control component defined by the ITU and ATM Forum (e.g., UNI, PNNI). An ATM-LSR may OPTIONALLY respond to OAM cells.
支持ATM交换机上的标签交换并不要求交换机支持ITU和ATM论坛（如UNI、PNNI）定义的ATM控制组件。ATM-LSR可以选择性地响应OAM信元。
The existence of the label switching control component on an ATM switch does not preclude the ability to support the ATM control component defined by the ITU and ATM Forum on the same switch and the same interfaces. The two control components, label switching and the ITU/ATM Forum defined, would operate independently.
ATM交换机上存在标签交换控制组件并不排除在同一交换机和同一接口上支持ITU和ATM论坛定义的ATM控制组件的能力。标签交换和定义的ITU/ATM论坛这两个控制组件将独立运行。
Definition of how such a device operates is beyond the scope of this document. However, only a small amount of information needs to be consistent between the two control components, such as the portions of the VPI/VCI space which are available to each component.
此类设备如何运行的定义超出了本文件的范围。然而，两个控制组件之间只需要少量信息保持一致，例如每个组件可用的VPI/VCI空间部分。
Label switching is accomplished by associating labels with Forwarding Equivalence Classes, and using the label value to forward packets, including determining the value of any replacement label. See [1]
标签交换是通过将标签与转发等价类相关联，并使用标签值转发数据包来完成的，包括确定任何替换标签的值。见[1]
for further details. In an ATM-LSR, the label is carried in the VPI/VCI field, or, when two ATM-LSRs are connected via an ATM "Virtual Path", in the VCI field.
详情请参阅。在ATM-LSR中，标签携带在VPI/VCI字段中，或者，当两个ATM LSR通过ATM“虚拟路径”连接时，标签携带在VCI字段中。
Labeled packets MUST be transmitted using the null encapsulation, as defined in Section 6.1 of RFC 2684 [5].
按照RFC 2684[5]第6.1节的规定，必须使用空封装传输带标签的数据包。
In addition, if two LDP peers are connected via an LC-ATM interface, a non-MPLS connection, capable of carrying unlabelled IP packets, MUST be available. This non-MPLS connection is used to carry LDP packets between the two peers, and MAY also be used (but is not required to be used) for other unlabeled packets (such as OSPF packets, etc.). The LLC/SNAP encapsulation of RFC 2684 [5] MUST be used on the non-MPLS connection.
此外，如果两个LDP对等点通过LC-ATM接口连接，则必须提供能够承载未标记IP数据包的非MPLS连接。该非MPLS连接用于在两个对等方之间承载LDP分组，并且还可用于（但不要求使用）其他未标记分组（例如OSPF分组等）。RFC 2684[5]的LLC/SNAP封装必须用于非MPLS连接。
It SHOULD be possible to configure an LC-ATM interface with additional VPI/VCIs that are used to carry control information or non-labelled packets. In that case, the VCI values MUST NOT be in the 0-32 range. These may use either the null encapsulation, as defined in Section 6.1 of RFC 2684 [5], or the LLC/SNAP encapsulation, as defined in Section 5.1 of RFC 2684 [5].
应该可以使用附加的VPI/VCI配置LC-ATM接口，这些VPI/VCI用于传输控制信息或无标签数据包。在这种情况下，VCI值不得在0-32范围内。这些可以使用RFC 2684[5]第6.1节中定义的空封装，或RFC 2684[5]第5.1节中定义的LLC/SNAP封装。
We say that two LSRs are "directly connected" over an LC-ATM interface if all cells transmitted out that interface by one LSR will reach the other, and there are no ATM switches between the two LSRs.
我们说两个LSR通过LC-ATM接口“直接连接”，如果一个LSR从该接口发送的所有信元都将到达另一个，并且两个LSR之间没有ATM交换机。
When two LSRs are directly connected via an LC-ATM interface, they jointly control the allocation of VPIs/VCIs on the interface connecting them. They may agree to use the VPI/VCI field to encode a single label.
当两个LSR通过LC-ATM接口直接连接时，它们共同控制连接它们的接口上VPI/VCI的分配。他们可能同意使用VPI/VCI字段对单个标签进行编码。
The default VPI/VCI value for the non-MPLS connection is VPI 0, VCI 32. Other values can be configured, as long as both parties are aware of the configured value.
非MPLS连接的默认VPI/VCI值为VPI 0，VCI 32。只要双方都知道配置的值，就可以配置其他值。
A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST NOT be used as the encoding of a label.
VCI部分在0-32（含0-32）范围内的VPI/VCI值不得用作标签编码。
With the exception of these reserved values, the VPI/VCI values used in the two directions of the link MAY be treated as independent spaces.
除这些保留值外，链路两个方向上使用的VPI/VCI值可被视为独立空间。
The allowable ranges of VCIs are communicated through LDP.
VCI的允许范围通过LDP进行通信。
Sometimes it can be useful to treat two LSRs as adjacent (in some LSP) across an LC-ATM interface, even though the connection between them is made through an ATM "cloud" via an ATM Virtual Path. In this case, the VPI field is not available to MPLS, and the label MUST be encoded entirely within the VCI field.
有时，在LC-ATM接口上将两个LSR视为相邻（在某些LSP中）是有用的，即使它们之间的连接是通过ATM虚拟路径通过ATM“云”进行的。在这种情况下，MPLS无法使用VPI字段，标签必须完全在VCI字段中编码。
In this case, the default VCI value of the non-MPLS connection between the LSRs is 32. Other values can be configured, as long as both parties are aware of the configured value. The VPI is set to whatever is required to make use of the Virtual Path.
在这种情况下，LSR之间的非MPLS连接的默认VCI值为32。只要双方都知道配置的值，就可以配置其他值。VPI设置为使用虚拟路径所需的任何值。
A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST NOT be used as the encoding of a label.
VCI部分在0-32（含0-32）范围内的VPI/VCI值不得用作标签编码。
With the exception of these reserved values, the VPI/VCI values used in the two directions of the link MAY be treated as independent spaces.
除这些保留值外，链路两个方向上使用的VPI/VCI值可被视为独立空间。
The allowable ranges of VPI/VCIs are communicated through LDP. If more than one VPI is used for label switching, the allowable range of VCIs may be different for each VPI, and each range is communicated through LDP.
VPI/VCI的允许范围通过LDP进行通信。如果标签交换使用多个VPI，则每个VPI的VCI允许范围可能不同，并且每个范围通过LDP进行通信。
Sometimes it may be useful to treat two LSRs as adjacent (in some LSP) across an LC-ATM interface, even though the connection between them is made through an ATM "cloud" via a set of ATM Switched Virtual Circuits.
有时，在LC-ATM接口上将两个LSR视为相邻（在某些LSP中）可能是有用的，即使它们之间的连接是通过一组ATM交换虚拟电路通过ATM“云”进行的。
The current document does not specify the procedure for handling this case. Such procedures can be found in [4]. The procedures described in [4] allow a VCID to be assigned to each such VC, and specify how LDP can be used used to bind a VCID to a FEC. The top label of a received packet would then be inferred (via a one-to-one mapping) from the virtual circuit on which the packet arrived. There would not be a default VPI or VCI value for the non-MPLS connection.
目前的文件没有规定处理该案件的程序。此类程序见[4]。[4]中描述的过程允许将VCID分配给每个此类VC，并指定如何使用LDP将VCID绑定到FEC。然后（通过一对一映射）从数据包到达的虚拟电路推断出所接收数据包的顶部标签。对于非MPLS连接，不会有默认的VPI或VCI值。
This document discusses the use of "downstream-on-demand" label distribution (see [1]) by ATM-LSRs. These label distribution procedures MUST be used by ATM-LSRs that do not support VC-merge, and MAY also be used by ATM-LSRs that do support VC-merge. The procedures differ somewhat in the two cases, however. We therefore describe the two scenarios in turn. We begin by describing the
本文件讨论了ATM LSR使用“下游按需”标签分发（见[1]）。这些标签分发过程必须由不支持VC合并的ATM LSR使用，也可以由支持VC合并的ATM LSR使用。然而，在这两种情况下，程序有所不同。因此，我们依次描述这两种情况。我们首先描述
behavior of members of the Edge Set of an ATM-LSR domain; these "Edge LSRs" are not themselves ATM-LSRs, and their behavior is the same whether the domain contains VC-merge capable LSRs or not.
ATM-LSR域的边集成员的行为；这些“边缘LSR”本身不是ATM LSR，无论域是否包含支持VC合并的LSR，它们的行为都是相同的。
Consider a member of the Edge Set of an ATM-LSR domain. Assume that, as a result of its routing calculations, it selects an ATM-LSR as the next hop of a certain FEC, and that the next hop is reachable via a LC-ATM interface. The Edge LSR uses LDP to request a label binding for that FEC from the next hop. The hop count field in the request is set to 1 (but see the next paragraph). Once the Edge LSR receives the label binding information, it may use MPLS forwarding procedures to transmit packets in the specified FEC, using the specified label as an outgoing label. (Or using the VPI/VCI that corresponds to the specified VCID as the outgoing label, if the VCID technique of [4] is being used.)
考虑一个ATM-SLSR域的边缘集的成员。假设，作为其路由计算的结果，它选择ATM-LSR作为某个FEC的下一跳，并且下一跳可以通过LC-ATM接口到达。边缘LSR使用LDP从下一跳请求该FEC的标签绑定。请求中的跃点计数字段设置为1（但请参见下一段）。一旦边缘LSR接收到标签绑定信息，它就可以使用MPLS转发过程来使用指定标签作为传出标签在指定FEC中发送分组。（或使用与指定VCID对应的VPI/VCI作为输出标签，如果使用的是[4]的VCID技术。）
Note: if the Edge LSR's previous hop is using downstream-on-demand label distribution to request a label from the Edge LSR for a particular FEC, and if the Edge LSR is not merging the LSP from that previous hop with any other LSP, and if the request from the previous hop has a hop count of h, then the hop count in the request issued by the Edge LSR should not be set to 1, but rather to h+1.
注意：如果边缘LSR的上一个跃点使用下游按需标签分发从边缘LSR请求特定FEC的标签，并且如果边缘LSR没有将该上一个跃点的LSP与任何其他LSP合并，并且如果来自上一个跃点的请求的跃点计数为h，然后，边缘LSR发出的请求中的跃点计数不应设置为1，而应设置为h+1。
The binding received by the edge LSR may contain a hop count, which represents the number of hops a packet will take to cross the ATM-LSR domain when using this label. If there is a hop count associated with the binding, the ATM-LSR SHOULD adjust a data packet's TTL by this amount before transmitting the packet. In any event, it MUST adjust a data packet's TTL by at least one before transmitting it. The procedures for doing so (in the case of IP packets) are specified in section 10. The procedures for encapsulating the packets are specified in section 9.
边缘LSR接收到的绑定可能包含一个跳数，该跳数表示当使用该标签时，一个数据包将通过ATM-LSR域的跳数。如果存在与绑定相关联的跳数，则ATM-LSR应在传输数据包之前将数据包的TTL调整该数量。在任何情况下，它都必须在传输数据包之前将其TTL至少调整一次。第10节规定了这样做的程序（在IP数据包的情况下）。第9节规定了封装数据包的程序。
When a member of the Edge Set of the ATM-LSR domain receives a label binding request from an ATM-LSR, it allocates a label, and returns (via LDP) a binding containing the allocated label back to the peer that originated the request. It sets the hop count in the binding to 1.
当ATM-LSR域的边缘集的成员从ATM-LSR接收到标签绑定请求时，它分配标签，并（通过LDP）将包含所分配标签的绑定返回给发起请求的对等方。它将绑定中的跃点计数设置为1。
When a routing calculation causes an Edge LSR to change the next hop for a particular FEC, and the former next hop was in the ATM-LSR domain, the Edge LSR SHOULD notify the former next hop (via LDP) that the label binding associated with the FEC is no longer needed.
当路由计算导致边缘LSR更改特定FEC的下一跳，且前一跳位于ATM-LSR域中时，边缘LSR应通知前一跳（通过LDP）与FEC关联的标签绑定不再需要。
When an ATM-LSR receives (via LDP) a label binding request for a certain FEC from a peer connected to the ATM-LSR over a LC-ATM interface, the ATM-LSR takes the following actions:
当ATM-LSR（通过LDP）从通过LC-ATM接口连接到ATM-LSR的对等方接收到特定FEC的标签绑定请求时，ATM-LSR将采取以下行动：
- it allocates a label,
- 它分配一个标签，
- it requests (via LDP) a label binding from the next hop for that FEC;
- 它（通过LDP）从该FEC的下一跳请求标签绑定；
- it returns (via LDP) a binding containing the allocated incoming label back to the peer that originated the request.
- 它（通过LDP）将包含分配的传入标签的绑定返回给发起请求的对等方。
For purposes of this procedure, we define a maximum hop count value MAXHOP. MAXHOP has a default value of 255, but may be configured to a different value.
为了实现此过程，我们定义了最大跃点计数值MAXHOP。MAXHOP的默认值为255，但可以配置为其他值。
The hop count field in the request that the ATM-LSR sends (to the next hop LSR) MUST be set to one more than the hop count field in the request that it received from the upstream LSR. If the resulting hop count exceeds MAXHOP, the request MUST NOT be sent to the next hop, and the ATM-LSR MUST notify the upstream neighbor that its binding request cannot be satisfied.
ATM-LSR发送（到下一跳LSR）的请求中的跳数字段必须设置为比从上游LSR接收的请求中的跳数字段多一个。如果产生的跃点计数超过MAXHOP，则不得将请求发送到下一个跃点，并且ATM-LSR必须通知上游邻居其绑定请求无法满足。
Otherwise, once the ATM-LSR receives the binding from the next hop, it begins using that label.
否则，一旦ATM-LSR从下一跳接收到绑定，它就开始使用该标签。
The ATM-LSR MAY choose to wait for the request to be satisfied from downstream before returning the binding upstream. This is a form of "ordered control" (as defined in [1] and [2]), in particular "ingress-initiated ordered control". In this case, as long as the ATM-LSR receives from downstream a hop count which is greater than 0 and less than MAXHOP, it MUST increment the hop count it receives from downstream and MUST include the result in the binding it returns upstream. However, if the hop count exceeds MAXHOP, a label binding MUST NOT be passed upstream. Rather, the upstream LDP peer MUST be informed that the requested label binding cannot be satisfied. If the hop count received from downstream is 0, the hop count passed upstream should also be 0; this indicates that the actual hop count is unknown.
ATM-LSR可以选择等待来自下游的请求得到满足，然后再返回绑定上游。这是一种“有序控制”（定义见[1]和[2]），尤其是“入口启动有序控制”。在这种情况下，只要ATM-LSR从下游接收到大于0且小于MAXHOP的跃点计数，它就必须增加从下游接收到的跃点计数，并且必须将结果包含在它返回上游的绑定中。但是，如果跃点计数超过MAXHOP，则不得向上游传递标签绑定。相反，必须通知上游LDP对等方无法满足所请求的标签绑定。如果从下游接收的跳数为0，则向上游传递的跳数也应为0；这表示实际跃点计数未知。
Alternatively, the ATM-LSR MAY return the binding upstream without waiting for a binding from downstream ("independent" control, as defined in [1] and [2]). In this case, it specifies a hop count of 0 in the binding, indicating that the true hop count is unknown. The correct value for hop count will be returned later, as described below.
或者，ATM-LSR可以在不等待下游绑定的情况下返回上游绑定（“独立”控制，如[1]和[2]中所定义）。在这种情况下，它在绑定中指定了一个0的跃点计数，这表示真正的跃点计数未知。稍后将返回正确的跃点计数值，如下所述。
Note that an ATM-LSR, or a member of the edge set of an ATM-LSR domain, may receive multiple binding requests for the same FEC from the same ATM-LSR. It MUST generate a new binding for each request (assuming adequate resources to do so), and retain any existing binding(s). For each request received, an ATM-LSR MUST also generate a new binding request toward the next hop for the FEC.
注意，ATM-LSR或ATM-LSR域的边缘集的成员可以从同一ATM-LSR接收同一FEC的多个绑定请求。它必须为每个请求生成一个新绑定（假设有足够的资源这样做），并保留任何现有绑定。对于接收到的每个请求，ATM-LSR还必须向FEC的下一跳生成新的绑定请求。
When a routing calculation causes an ATM-LSR to change the next hop for a FEC, the ATM-LSR MUST notify the former next hop (via LDP) that the label binding associated with the FEC is no longer needed.
当路由计算导致ATM-LSR更改FEC的下一跳时，ATM-LSR必须（通过LDP）通知前一个下一跳，与FEC关联的标签绑定不再需要。
When a LSR receives a notification that a particular label binding is no longer needed, the LSR MAY deallocate the label associated with the binding, and destroy the binding. In the case where an ATM-LSR receives such notification and destroys the binding, it MUST notify the next hop for the FEC that the label binding is no longer needed. If a LSR does not destroy the binding, it may re-use the binding only if it receives a request for the same FEC with the same hop count as the request that originally caused the binding to be created.
当LSR收到不再需要特定标签绑定的通知时，LSR可能会取消分配与该绑定关联的标签，并销毁该绑定。在ATM-LSR收到此类通知并销毁绑定的情况下，它必须通知FEC的下一个跃点不再需要标签绑定。如果LSR未销毁绑定，则仅当它接收到与最初创建绑定的请求具有相同跳数的相同FEC的请求时，它才可以重新使用绑定。
When a route changes, the label bindings are re-established from the point where the route diverges from the previous route. LSRs upstream of that point are (with one exception, noted below) oblivious to the change.
当管线发生更改时，标签绑定将从管线偏离上一条管线的点重新建立。该点上游的LSR（有一个例外，如下所述）不受变化影响。
Whenever a LSR changes its next hop for a particular FEC, if the new next hop is reachable via an LC-ATM interface, then for each label that it has bound to that FEC, and distributed upstream, it MUST request a new label binding from the new next hop.
每当LSR为特定FEC更改其下一跳时，如果新的下一跳可通过LC-ATM接口访问，则对于其绑定到该FEC且分布在上游的每个标签，它必须从新的下一跳请求新的标签绑定。
When an ATM-LSR receives a label binding for a particular FEC from a downstream neighbor, it may already have provided a corresponding label binding for this FEC to an upstream neighbor, either because it is using independent control, or because the new binding from downstream is the result of a routing change. In this case, unless the hop count is 0, it MUST extract the hop count from the new binding and increment it by one. If the new hop count is different from that which was previously conveyed to the upstream neighbor (including the case where the upstream neighbor was given the value 'unknown') the ATM-LSR MUST notify the upstream neighbor of the change. Each ATM-LSR in turn MUST increment the hop count and pass it upstream until it reaches the ingress Edge LSR. If at any point the value of the hop count equals MAXHOP, the ATM-LSR SHOULD withdraw the binding from the upstream neighbor. A hop count of 0 MUST be passed upstream unchanged.
当ATM-LSR从下游邻居接收到特定FEC的标签绑定时，它可能已经为该FEC向上游邻居提供了相应的标签绑定，因为它正在使用独立控制，或者因为来自下游的新绑定是路由更改的结果。在这种情况下，除非跃点计数为0，否则它必须从新绑定中提取跃点计数并将其递增1。如果新的跃点计数不同于先前传送给上游邻居的跃点计数（包括上游邻居被赋予“未知”值的情况），则ATM-LSR必须将该变化通知上游邻居。每个ATM-LSR必须依次增加跳数并向上游传递，直到到达入口边缘LSR。如果在任何一点上，跃点计数的值等于MAXHOP，ATM-LSR应该从上游邻居撤回绑定。必须向上游传递0的跃点计数，而不作任何更改。
Whenever an ATM-LSR originates a label binding request to its next hop LSR as a result of receiving a label binding request from another (upstream) LSR, and the request to the next hop LSR is not satisfied, the ATM-LSR SHOULD destroy the binding created in response to the received request, and notify the requester (via LDP).
当ATM-LSR由于接收到来自另一个（上游）LSR的标签绑定请求而发起到其下一跳LSR的标签绑定请求，并且到下一跳LSR的请求未得到满足时，ATM-LSR应销毁响应接收到的请求而创建的绑定，并通知请求者（通过LDP）。
If an ATM-LSR receives a binding request containing a hop count that exceeds MAXHOP, it MUST not establish a binding, and it MUST return an error to the requester.
如果ATM-LSR接收到一个绑定请求，该请求包含超过MAXHOP的跃点计数，则它不能建立绑定，并且必须向请求者返回一个错误。
When a LSR determines that it has lost its LDP session with another LSR, the following actions are taken. Any binding information learned via this connection MUST be discarded. For any label bindings that were created as a result of receiving label binding requests from the peer, the LSR MAY destroy these bindings (and deallocate labels associated with these binding).
当一个LSR确定它丢失了与另一个LSR的LDP会话时，将采取以下操作。必须放弃通过此连接学习的任何绑定信息。对于由于从对等方接收标签绑定请求而创建的任何标签绑定，LSR可能会销毁这些绑定（并取消分配与这些绑定关联的标签）。
An ATM-LSR SHOULD use 'split-horizon' when it satisfies binding requests from its neighbors. That is, if it receives a request for a binding to a particular FEC and the LSR making that request is, according to this ATM-LSR, the next hop for that FEC, it should not return a binding for that route.
当ATM-LSR满足其邻居的绑定请求时，它应该使用“拆分地平线”。也就是说，如果它接收到绑定到特定FEC的请求，并且根据该ATM-LSR，发出该请求的LSR是该FEC的下一跳，则它不应返回该路由的绑定。
It is expected that non-merging ATM-LSRs would generally use "conservative label retention mode" [1].
预计非合并ATM LSR通常使用“保守标签保留模式”[1]。
Relatively minor changes are needed to accommodate ATM-LSRs which support VC-merge. The primary difference is that a VC-merge-capable ATM-LSR needs only one outgoing label per FEC, even if multiple requests for label bindings to that FEC are received from upstream neighbors.
需要进行相对较小的更改以适应支持VC合并的ATM LSR。主要区别在于，支持VC合并的ATM-LSR每个FEC只需要一个传出标签，即使从上游邻居接收到多个标签绑定到该FEC的请求。
When a VC-merge-capable ATM-LSR receives a binding request from an upstream LSR for a certain FEC, and it does not already have an outgoing label binding for that FEC (or an outstanding request for such a label binding), it MUST issue a bind request to its next hop just as it would do if it were not merge-capable. If, however, it already has an outgoing label binding for that FEC, it does not need to issue a downstream binding request. Instead, it may simply allocate an incoming label, and return that label in a binding to the upstream requester. When packets with that label as top label are received from the requester, the top label value will be replaced with the existing outgoing label value that corresponds to the same FEC.
当支持VC合并的ATM-LSR从上游LSR接收到针对某个FEC的绑定请求，并且该FEC还没有传出标签绑定（或此类标签绑定的未完成请求），它必须向其下一跳发出绑定请求，就像它不支持合并一样。但是，如果它已经为该FEC具有传出标签绑定，则不需要发出下游绑定请求。相反，它可以简单地分配一个传入标签，并在绑定中将该标签返回给上游请求者。当从请求者接收到具有该标签作为顶标签的数据包时，顶标签值将替换为对应于相同FEC的现有传出标签值。
If the ATM-LSR does not have an outgoing label binding for the FEC, but does have an outstanding request for one, it need not issue another request.
如果ATM-LSR没有FEC的传出标签绑定，但有一个未完成的请求，则无需发出另一个请求。
When sending a label binding upstream, the hop count associated with the corresponding binding from downstream MUST be incremented by 1, and the result transmitted upstream as the hop count associated with the new binding. However, there are two exceptions: a hop count of 0 MUST be passed upstream unchanged, and if the hop count is already at MAXHOP, the ATM-LSR MUST NOT pass a binding upstream, but instead MUST send an error upstream.
向上游发送标签绑定时，与来自下游的相应绑定相关联的跃点计数必须增加1，并且向上游传输的结果作为与新绑定相关联的跃点计数。但是，有两种例外情况：跳数为0的跳数必须在未更改的情况下向上游传递，如果跳数已经在MAXHOP，则ATM-LSR不能向上游传递绑定，而是必须向上游发送错误。
Note that, just like conventional ATM-LSRs and members of the edge set of the ATM-LSR domain, a VC-merge-capable ATM-LSR MUST issue a new binding every time it receives a request from upstream, since there may be switches upstream which do not support VC-merge. However, it only needs to issue a corresponding binding request downstream if it does not already have a label binding for the appropriate route.
请注意，就像传统的ATM LSR和ATM-LSR域边缘集的成员一样，支持VC合并的ATM-LSR在每次收到来自上游的请求时都必须发出新绑定，因为上游可能有不支持VC合并的交换机。但是，如果它还没有相应路由的标签绑定，则只需要在下游发出相应的绑定请求。
When a change in the routing table of a VC-merge-capable ATM-LSR causes it to select a new next hop for one of its FECs, it MAY optionally release the binding for that route from the former next hop. If it doesn't already have a corresponding binding for the new next hop, it must request one. (The choice between conservative and liberal label retention mode [1] is an implementation option.)
当支持VC合并的ATM-LSR的路由表中的更改导致其为其中一个FEC选择新的下一跳时，它可以选择从前一个下一跳释放该路由的绑定。如果它还没有新的下一跳的相应绑定，它必须请求一个。（保守和自由标签保留模式[1]之间的选择是一种实现选项。）
If a new binding is obtained, which contains a hop count that differs from that which was received in the old binding, then the ATM-LSR must take the new hop count, increment it by one, and notify any upstream neighbors who have label bindings for this FEC of the new value. Just as with conventional ATM-LSRs, this enables the new hop count to propagate back towards the ingress of the ATM-LSR domain. If at any point the hop count exceeds MAXHOP, then the label bindings for this route must be withdrawn from all upstream neighbors to whom a binding was previously provided. This ensures that any loops caused by routing transients will be detected and broken.
如果获得了一个新绑定，其中包含一个与旧绑定中接收到的跳数不同的跳数，则ATM-LSR必须获取新的跳数，将其递增一，并将新值通知具有此FEC标签绑定的任何上游邻居。与传统的ATM LSR一样，这使得新的跳数能够传播回ATM-LSR域的入口。如果在任何时候跃点计数超过MAXHOP，则必须从先前提供绑定的所有上游邻居中撤消此路由的标签绑定。这确保了由路由瞬变引起的任何环路都将被检测到并断开。
The procedures described in this section affect only the Edge LSRs of the ATM-LSR domain. The ATM-LSRs themselves do not modify the encapsulation in any way.
本节中描述的过程仅影响ATM-LSR域的边缘LSR。ATM LSR本身不会以任何方式修改封装。
Labeled packets MUST be transmitted using the null encapsulation of Section 6.1 of RFC 2684 [5].
必须使用RFC 2684[5]第6.1节中的空封装传输带标签的数据包。
Except in certain circumstances specified below, when a labeled packet is transmitted on an LC-ATM interface, where the VPI/VCI (or VCID) is interpreted as the top label in the label stack, the packet MUST also contain a "shim header" [3].
除非在下文规定的某些情况下，当在LC-ATM接口上传输带标签的数据包时，其中VPI/VCI（或VCID）被解释为标签堆栈中的顶部标签，数据包还必须包含“垫片头”[3]。
If the packet has a label stack with n entries, it MUST carry a shim with n entries. The actual value of the top label is encoded in the VPI/VCI field. The label value of the top entry in the shim (which is just a "placeholder" entry) MUST be set to 0 upon transmission, and MUST be ignored upon reception. The packet's outgoing TTL, and its CoS, are carried in the TTL and CoS fields respectively of the top stack entry in the shim.
如果数据包有一个包含n个条目的标签堆栈，它必须携带一个包含n个条目的垫片。顶部标签的实际值编码在VPI/VCI字段中。垫片中顶部条目（仅为“占位符”条目）的标签值在传输时必须设置为0，在接收时必须忽略。数据包的传出TTL及其CoS分别在垫片中顶部堆栈项的TTL和CoS字段中携带。
Note that if a packet has a label stack with only one entry, this requires it to have a single-entry shim (4 bytes), even though the actual label value is encoded into the VPI/VCI field. This is done to ensure that the packet always has a shim. Otherwise, there would be no way to determine whether it had one or not, i.e., no way to determine whether there are additional label stack entries.
请注意，如果一个数据包的标签堆栈只有一个条目，这就要求它有一个条目垫片（4字节），即使实际的标签值被编码到VPI/VCI字段中。这样做是为了确保数据包始终有一个垫片。否则，将无法确定它是否有一个标签堆栈条目，即无法确定是否有其他标签堆栈条目。
The only ways to eliminate this extra overhead are:
消除这种额外开销的唯一方法是：
- through apriori knowledge that packets have only a single label (e.g., perhaps the network only supports one level of label)
- 通过先验知识，即数据包只有一个标签（例如，网络可能只支持一个级别的标签）
- by using two VCs per FEC, one for those packets which have only a single label, and one for those packets which have more than one label
- 通过为每个FEC使用两个VCs，一个用于只有一个标签的数据包，另一个用于具有多个标签的数据包
The second technique would require that there be some way of signalling via LDP that the VC is carrying only packets with a single label, and is not carrying a shim. When supporting VC merge, one would also have to take care not to merge a VC on which the shim is not used into a VC on which it is used, or vice versa.
第二种技术需要有某种方式通过LDP发送信号，表明VC只携带带有单个标签的数据包，而不携带垫片。在支持VC合并时，还必须注意不要将未使用垫片的VC合并到使用垫片的VC中，反之亦然。
While either of these techniques is permitted, it is doubtful that they have any practical utility. Note that if the shim header is not present, the outgoing TTL is carried in the TTL field of the network layer header.
虽然这两种技术中的任何一种都是允许的，但它们是否有任何实际用途值得怀疑。请注意，如果垫片标头不存在，则传出TTL将携带在网络层标头的TTL字段中。
The procedures described in this section affect only the Edge LSRs of the ATM-LSR domain. The ATM-LSRs themselves do not modify the TTL in any way.
本节中描述的过程仅影响ATM-LSR域的边缘LSR。ATM LSR本身不会以任何方式修改TTL。
The details of the TTL adjustment procedure are as follows. If a packet was received by the Edge LSR as an unlabeled packet, the "incoming TTL" comes from the IP header. (Procedures for other network layer protocols are for further study.) If a packet was received by the Edge LSR as a labeled packet, using the encapsulation specified in [3], the "incoming TTL" comes from the entry at the top of the label stack.
TTL调整程序的细节如下所示。如果边缘LSR接收到的数据包是未标记的数据包，“传入TTL”来自IP报头。（其他网络层协议的程序有待进一步研究。）如果边缘LSR使用[3]中规定的封装将数据包作为标签数据包接收，“传入TTL”来自标签堆栈顶部的条目。
If a hop count has been associated with the label binding that is used when the packet is forwarded, the "outgoing TTL" is set to the larger of (a) 0 or (b) the difference between the incoming TTL and the hop count. If a hop count has not been associated with the label binding that is used when the packet is forwarded, the "outgoing TTL" is set to the larger of (a) 0 or (b) one less than the incoming TTL.
如果跃点计数与转发数据包时使用的标签绑定相关联，“传出TTL”设置为（a）0或（b）传入TTL和跃点计数之间的差值中的较大值。如果跃点计数未与转发数据包时使用的标签绑定相关联，“传出TTL”设置为（a）0或（b）比传入TTL小一的较大值。
If this causes the outgoing TTL to become zero, the packet MUST NOT be transmitted as a labeled packet using the specified label. The packet can be treated in one of two ways:
如果这导致传出TTL变为零，则不得使用指定标签将数据包作为带标签的数据包传输。可采用以下两种方式之一处理数据包：
- it may be treated as having expired; this may cause an ICMP message to be transmitted;
- 可将其视为已过期；这可能导致传输ICMP消息；
- the packet may be forwarded, as an unlabeled packet, with a TTL that is 1 less than the incoming TTL; such forwarding would need to be done over a non-MPLS connection.
- 该分组可以作为未标记分组转发，其TTL小于传入TTL 1；这种转发需要在非MPLS连接上完成。
Of course, if the incoming TTL is 1, only the first of these two options is applicable.
当然，如果传入的TTL为1，则只有这两个选项中的第一个适用。
If the packet is forwarded as a labeled packet, the outgoing TTL is carried as specified in section 9.
如果数据包作为标记数据包转发，则按照第9节的规定携带出站TTL。
When an Edge LSR receives a labeled packet over an LC-ATM interface, it obtains the incoming TTL from the top label stack entry of the generic encapsulation, or, if that encapsulation is not present, from the IP header.
当边缘LSR通过LC-ATM接口接收到带标签的数据包时，它从通用封装的顶部标签堆栈条目获取传入TTL，或者，如果封装不存在，则从IP报头获取传入TTL。
If the packet's next hop is an ATM-LSR, the outgoing TTL is formed using the procedures described in this section. Otherwise the outgoing TTL is formed using the procedures described in [3].
如果数据包的下一个跃点是ATM-LSR，则使用本节中描述的过程形成传出TTL。否则，使用[3]中描述的程序形成输出TTL。
The procedures in this section are intended to apply only to unicast packets.
本节中的步骤仅适用于单播数据包。
Every ATM-LSR MUST implement, as a configurable option, the following procedure for detecting forwarding loops. We refer to this as the LDPV (Loop Detection via Path Vectors) procedure. This procedure does not prevent the formation of forwarding loops, but does ensure that any such loops are detected. If this option is not enabled, loops are detected by the hop count mechanism previously described. If this option is enabled, loops will be detected more quickly, but at a higher cost in overhead.
作为一个可配置选项，每个ATM-LSR必须实现以下检测转发环路的过程。我们称之为LDPV（通过路径向量的环路检测）过程。此过程不会阻止转发循环的形成，但会确保检测到任何此类循环。如果未启用此选项，则通过前面描述的跃点计数机制检测循环。如果启用此选项，将更快地检测循环，但开销会更高。
Suppose an LSR R sends a request for a label binding, for a particular LSP, to its next hop. Then if R does not support VC-merging, and R is configured to use the LDPV procedure:
假设LSR向其下一个跃点发送特定LSP的标签绑定请求。然后，如果R不支持VC合并，并且R配置为使用LDPV过程：
- If R is sending the request because it is an ingress node for that LSP, or because it has acquired a new next hop, then R MUST include a path vector object with the request, and the path vector object MUST contain only R's own address.
- 如果R发送请求是因为它是该LSP的入口节点，或者因为它获得了新的下一跳，那么R必须在请求中包含路径向量对象，并且路径向量对象必须只包含R自己的地址。
- If R is sending the request as a result of having received a request from an upstream LSR, then:
- 如果R由于从上游LSR接收到请求而发送请求，则：
* if the received request has a path vector object, R MUST add its own address to the received path vector object, and MUST pass the resulting path vector object to its next hop along with the label binding request;
* 如果接收到的请求具有路径向量对象，R必须将其自己的地址添加到接收到的路径向量对象，并且必须将得到的路径向量对象与标签绑定请求一起传递到其下一跳；
* if the received request does not have a path vector object, R MUST include a path vector object with the request it sends, and the path vector object MUST contain only R's own address.
* 如果接收到的请求没有路径向量对象，则R必须在其发送的请求中包含路径向量对象，并且路径向量对象必须仅包含R自己的地址。
An LSR which supports VC-merge SHOULD NOT include a path vector object in the requests that it sends to its next hop.
支持VC合并的LSR不应在发送到下一跳的请求中包含路径向量对象。
If an LSR receives a label binding request whose path vector object contains the address of the node itself, the LSR concludes that the label binding requests have traveled in a loop. The LSR MUST act as it would in the case where the hop count exceeds MAXHOP (see section 8.2).
如果LSR接收到一个标签绑定请求，其路径向量对象包含节点本身的地址，则LSR认为标签绑定请求已在一个循环中移动。LSR必须在跃点计数超过MAXHOP的情况下发挥作用（参见第8.2节）。
This procedure detects the case where the request messages loop though a sequence of non-merging ATM-LSRs.
此过程检测请求消息通过非合并ATM LSR序列循环的情况。
As specified in section 8, there are circumstances in which an LSR R must inform its upstream neighbors, via a label binding response message, of a change in hop count for a particular LSP. If the following conditions all hold:
如第8节所述，在某些情况下，LSR必须通过标签绑定响应消息通知其上游邻居特定LSP的跃点计数的变化。如果以下条件均成立：
- R is configured for the LDPV procedure,
- 为LDPV程序配置了R，
- R supports VC-merge,
- R支持VC合并，
- R is not the egress for that LSP, and
- R不是该LSP的出口，并且
- R is not informing its neighbors of a decrease in the hop count,
- R没有通知其邻居跳数减少，
then R MUST include a path vector object in the response message.
然后R必须在响应消息中包含路径向量对象。
If the change in hop count is a result of R's having been informed by its next hop, S, of a change in hop count, and the message from S to R included a path vector object, then if the above conditions hold, R MUST add itself to this object and pass the result upstream. Otherwise, if the above conditions hold, R MUST create a new object with only its own address.
如果跃点计数的变化是由于R的下一个跃点s通知了R跃点计数的变化，并且从s到R的消息包括路径向量对象，则如果上述条件成立，R必须将自身添加到此对象并将结果向上游传递。否则，如果上述条件成立，R必须创建一个只有自己地址的新对象。
If R is configured for the LDPV procedure, and R supports VC merge, then it MAY include a path vector object in any label binding response message that it sends upstream. In particular, at any time that R receives a label binding response from its next hop, if that response contains a path vector, R MAY (if configured for the LDPV procedure) send a response to its upstream neighbors, containing the path vector object formed by adding its own address to the received path vector.
如果为LDPV过程配置了R，并且R支持VC合并，那么它可以在向上游发送的任何标签绑定响应消息中包含路径向量对象。具体地，在R从其下一跳接收到标签绑定响应的任何时候，如果该响应包含路径向量，则R可以（如果为LDPV过程配置）向其上游邻居发送响应，该响应包含通过将其自身地址添加到接收到的路径向量而形成的路径向量对象。
If R does not support VC merge, it SHOULD NOT send a path vector object upstream.
如果R不支持VC合并，则不应向上游发送路径向量对象。
If an LSR receives a message from its next hop, with a path vector object containing its own address, then LSR MUST act as it would if it received a message with a hop count equal to MAXHOP.
如果LSR从其下一个跃点接收到消息，且路径向量对象包含其自己的地址，则LSR必须像接收到跃点计数等于MAXHOP的消息一样工作。
LSRs which are configured for the LDPV procedure SHOULD NOT store a path vector once the corresponding path vector object has been transmitted.
为LDPV过程配置的LSR在相应的路径向量对象被传输后不应存储路径向量。
Note that if the ATM-LSR domain consists entirely of non-merging ATM-LSRs, path vectors need not ever be sent upstream, since any loops will be detected by means of the path vectors traveling downstream.
注意，如果ATM-LSR域完全由非合并的ATM LSR组成，则永远不需要向上游发送路径向量，因为任何环路都将通过向下游移动的路径向量来检测。
By not sending path vectors unless the hop count increases, one avoids sending them in many situations when there is no loop. The cost is that in some situations in which there is a loop, the time to detect the loop may be lengthened.
除非跳数增加，否则不发送路径向量，可以避免在没有循环的许多情况下发送路径向量。其代价是，在存在循环的某些情况下，检测循环的时间可能会延长。
The encapsulation and procedures specified in this document do not interfere in any way with the application of authentication and/or encryption to network layer packets (such as the application of IPSEC to IP datagrams).
本文件中规定的封装和程序不会以任何方式干扰对网络层数据包的身份验证和/或加密应用（如对IP数据报应用IPSEC）。
The procedures described in this document do not protect against the alteration (either accidental or malicious) of MPLS labels. Such alteration could cause misforwarding.
本文件中描述的程序不能防止更改MPLS标签（意外或恶意）。这种改变可能导致错误的前进方向。
The procedures described in this document do not enable a receiving LSR to authenticate the transmitting LSR.
本文档中描述的过程不允许接收LSR对发送LSR进行身份验证。
A discussion of the security considerations applicable to the label distribution mechanism can be found in [2].
关于适用于标签分发机制的安全注意事项的讨论见[2]。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
[1] Rosen, E., Viswanathan, A. and R. Callon "Multi-Protocol Label Switching Architecture", RFC 3031, January 2001.
[1] Rosen，E.，Viswanathan，A.和R.Callon“多协议标签交换架构”，RFC 30312001年1月。
[2] Andersson L., Doolan P., Feldman N., Fredette A. and R. Thomas, "LDP Specification", RFC 3036, January 2001.
[2] Andersson L.，Doolan P.，Feldman N.，Fredette A.和R.Thomas，“LDP规范”，RFC 3036，2001年1月。
[3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[3] Rosen，E.，Rekhter，Y.，Tappan，D.，Farinaci，D.，Fedorkow，G.，Li，T.和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[4] Nagami, K., Demizu N., Esaki H. and P. Doolan, "VCID Notification over ATM Link for LDP", RFC 3038, January 2001.
[4] Nagami，K.，Demizu N.，Esaki H.和P.Doolan，“LDP ATM链路上的VCID通知”，RFC 3038，2001年1月。
[5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[5] Grossman，D.，Heinanen，J.，“ATM适配层5上的多协议封装”，RFC 2684，1999年9月。
Significant contributions to this work have been made by Anthony Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan Littlewood and Dan Tappan. We thank Alex Conta for his comments.
Anthony Alles、Fred Baker、Dino Farinaci、Guy Fedorkow、Arthur Lin、Morgan Littlewood和Dan Tappan对这项工作做出了重大贡献。我们感谢Alex Conta的评论。
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
布鲁斯·戴维斯思科系统公司，马萨诸塞州切姆斯福德阿波罗大道250号，邮编01824
EMail: bsd@cisco.com
EMail: bsd@cisco.com
Paul Doolan Ennovate Networks Inc. 60 Codman Hill Rd Boxborough, MA 01719
Paul Doolan Ennovate Networks Inc.马萨诸塞州博克斯伯勒市科德曼山路60号，邮编01719
EMail: pdoolan@ennovatenetworks.com
EMail: pdoolan@ennovatenetworks.com
Jeremy Lawrence Cisco Systems, Inc. 99 Walker St. North Sydney, NSW, Australia
Jeremy Lawrence Cisco Systems，Inc.澳大利亚新南威尔士州北悉尼沃克街99号
EMail: jlawrenc@cisco.com
EMail: jlawrenc@cisco.com
Keith McCloghrie Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134
基思·麦克洛赫里思科系统公司，地址：加利福尼亚州圣何塞塔斯曼大道170号，邮编：95134
EMail: kzm@cisco.com
EMail: kzm@cisco.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089
加利福尼亚州桑尼维尔市马蒂尔达大道北1194号雅科夫·雷克特·杜松网络公司，邮编94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Eric Rosen Cisco Systems，Inc.马萨诸塞州切姆斯福德阿波罗大道250号，邮编01824
EMail: erosen@cisco.com
EMail: erosen@cisco.com
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
乔治斯沃诺思科系统公司，马萨诸塞州切姆斯福德阿波罗大道250号，邮编01824
EMail: swallow@cisco.com
EMail: swallow@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。