Network Working Group E. Rosen
Request for Comments: 3031 Cisco Systems, Inc.
Category: Standards Track A. Viswanathan
Force10 Networks, Inc.
R. Callon
Juniper Networks, Inc.
January 2001
Network Working Group E. Rosen
Request for Comments: 3031 Cisco Systems, Inc.
Category: Standards Track A. Viswanathan
Force10 Networks, Inc.
R. Callon
Juniper Networks, Inc.
January 2001
Multiprotocol Label Switching Architecture
多协议标签交换体系结构
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
摘要
This document specifies the architecture for Multiprotocol Label Switching (MPLS).
本文件规定了多协议标签交换（MPLS）的体系结构。
Table of Contents
目录
1 Specification ...................................... 3
2 Introduction to MPLS ............................... 3
2.1 Overview ........................................... 4
2.2 Terminology ........................................ 6
2.3 Acronyms and Abbreviations ......................... 9
2.4 Acknowledgments .................................... 9
3 MPLS Basics ........................................ 9
3.1 Labels ............................................. 9
3.2 Upstream and Downstream LSRs ....................... 10
3.3 Labeled Packet ..................................... 11
3.4 Label Assignment and Distribution .................. 11
3.5 Attributes of a Label Binding ...................... 11
3.6 Label Distribution Protocols ....................... 11
3.7 Unsolicited Downstream vs. Downstream-on-Demand .... 12
3.8 Label Retention Mode ............................... 12
3.9 The Label Stack .................................... 13
3.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 13
3.11 Incoming Label Map (ILM) ........................... 14
1 Specification ...................................... 3
2 Introduction to MPLS ............................... 3
2.1 Overview ........................................... 4
2.2 Terminology ........................................ 6
2.3 Acronyms and Abbreviations ......................... 9
2.4 Acknowledgments .................................... 9
3 MPLS Basics ........................................ 9
3.1 Labels ............................................. 9
3.2 Upstream and Downstream LSRs ....................... 10
3.3 Labeled Packet ..................................... 11
3.4 Label Assignment and Distribution .................. 11
3.5 Attributes of a Label Binding ...................... 11
3.6 Label Distribution Protocols ....................... 11
3.7 Unsolicited Downstream vs. Downstream-on-Demand .... 12
3.8 Label Retention Mode ............................... 12
3.9 The Label Stack .................................... 13
3.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 13
3.11 Incoming Label Map (ILM) ........................... 14
3.12 FEC-to-NHLFE Map (FTN) ............................. 14
3.13 Label Swapping ..................................... 15
3.14 Scope and Uniqueness of Labels ..................... 15
3.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 16
3.16 Penultimate Hop Popping ............................ 18
3.17 LSP Next Hop ....................................... 20
3.18 Invalid Incoming Labels ............................ 20
3.19 LSP Control: Ordered versus Independent ............ 20
3.20 Aggregation ........................................ 21
3.21 Route Selection .................................... 23
3.22 Lack of Outgoing Label ............................. 24
3.23 Time-to-Live (TTL) ................................. 24
3.24 Loop Control ....................................... 25
3.25 Label Encodings .................................... 26
3.25.1 MPLS-specific Hardware and/or Software ............. 26
3.25.2 ATM Switches as LSRs ............................... 26
3.25.3 Interoperability among Encoding Techniques ......... 28
3.26 Label Merging ...................................... 28
3.26.1 Non-merging LSRs ................................... 29
3.26.2 Labels for Merging and Non-Merging LSRs ............ 30
3.26.3 Merge over ATM ..................................... 31
3.26.3.1 Methods of Eliminating Cell Interleave ............. 31
3.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 31
3.27 Tunnels and Hierarchy .............................. 32
3.27.1 Hop-by-Hop Routed Tunnel ........................... 32
3.27.2 Explicitly Routed Tunnel ........................... 33
3.27.3 LSP Tunnels ........................................ 33
3.27.4 Hierarchy: LSP Tunnels within LSPs ................. 33
3.27.5 Label Distribution Peering and Hierarchy ........... 34
3.28 Label Distribution Protocol Transport .............. 35
3.29 Why More than one Label Distribution Protocol? ..... 36
3.29.1 BGP and LDP ........................................ 36
3.29.2 Labels for RSVP Flowspecs .......................... 36
3.29.3 Labels for Explicitly Routed LSPs .................. 36
3.30 Multicast .......................................... 37
4 Some Applications of MPLS .......................... 37
4.1 MPLS and Hop by Hop Routed Traffic ................. 37
4.1.1 Labels for Address Prefixes ........................ 37
4.1.2 Distributing Labels for Address Prefixes ........... 37
4.1.2.1 Label Distribution Peers for an Address Prefix ..... 37
4.1.2.2 Distributing Labels ................................ 38
4.1.3 Using the Hop by Hop path as the LSP ............... 39
4.1.4 LSP Egress and LSP Proxy Egress .................... 39
4.1.5 The Implicit NULL Label ............................ 40
4.1.6 Option: Egress-Targeted Label Assignment ........... 40
4.2 MPLS and Explicitly Routed LSPs .................... 42
4.2.1 Explicitly Routed LSP Tunnels ...................... 42
4.3 Label Stacks and Implicit Peering .................. 43
3.12 FEC-to-NHLFE Map (FTN) ............................. 14
3.13 Label Swapping ..................................... 15
3.14 Scope and Uniqueness of Labels ..................... 15
3.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 16
3.16 Penultimate Hop Popping ............................ 18
3.17 LSP Next Hop ....................................... 20
3.18 Invalid Incoming Labels ............................ 20
3.19 LSP Control: Ordered versus Independent ............ 20
3.20 Aggregation ........................................ 21
3.21 Route Selection .................................... 23
3.22 Lack of Outgoing Label ............................. 24
3.23 Time-to-Live (TTL) ................................. 24
3.24 Loop Control ....................................... 25
3.25 Label Encodings .................................... 26
3.25.1 MPLS-specific Hardware and/or Software ............. 26
3.25.2 ATM Switches as LSRs ............................... 26
3.25.3 Interoperability among Encoding Techniques ......... 28
3.26 Label Merging ...................................... 28
3.26.1 Non-merging LSRs ................................... 29
3.26.2 Labels for Merging and Non-Merging LSRs ............ 30
3.26.3 Merge over ATM ..................................... 31
3.26.3.1 Methods of Eliminating Cell Interleave ............. 31
3.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 31
3.27 Tunnels and Hierarchy .............................. 32
3.27.1 Hop-by-Hop Routed Tunnel ........................... 32
3.27.2 Explicitly Routed Tunnel ........................... 33
3.27.3 LSP Tunnels ........................................ 33
3.27.4 Hierarchy: LSP Tunnels within LSPs ................. 33
3.27.5 Label Distribution Peering and Hierarchy ........... 34
3.28 Label Distribution Protocol Transport .............. 35
3.29 Why More than one Label Distribution Protocol? ..... 36
3.29.1 BGP and LDP ........................................ 36
3.29.2 Labels for RSVP Flowspecs .......................... 36
3.29.3 Labels for Explicitly Routed LSPs .................. 36
3.30 Multicast .......................................... 37
4 Some Applications of MPLS .......................... 37
4.1 MPLS and Hop by Hop Routed Traffic ................. 37
4.1.1 Labels for Address Prefixes ........................ 37
4.1.2 Distributing Labels for Address Prefixes ........... 37
4.1.2.1 Label Distribution Peers for an Address Prefix ..... 37
4.1.2.2 Distributing Labels ................................ 38
4.1.3 Using the Hop by Hop path as the LSP ............... 39
4.1.4 LSP Egress and LSP Proxy Egress .................... 39
4.1.5 The Implicit NULL Label ............................ 40
4.1.6 Option: Egress-Targeted Label Assignment ........... 40
4.2 MPLS and Explicitly Routed LSPs .................... 42
4.2.1 Explicitly Routed LSP Tunnels ...................... 42
4.3 Label Stacks and Implicit Peering .................. 43
4.4 MPLS and Multi-Path Routing ........................ 44
4.5 LSP Trees as Multipoint-to-Point Entities .......... 44
4.6 LSP Tunneling between BGP Border Routers ........... 45
4.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 47
4.8 MPLS and Multicast ................................. 47
5 Label Distribution Procedures (Hop-by-Hop) ......... 47
5.1 The Procedures for Advertising and Using labels .... 48
5.1.1 Downstream LSR: Distribution Procedure ............. 48
5.1.1.1 PushUnconditional .................................. 49
5.1.1.2 PushConditional .................................... 49
5.1.1.3 PulledUnconditional ................................ 49
5.1.1.4 PulledConditional .................................. 50
5.1.2 Upstream LSR: Request Procedure .................... 51
5.1.2.1 RequestNever ....................................... 51
5.1.2.2 RequestWhenNeeded .................................. 51
5.1.2.3 RequestOnRequest ................................... 51
5.1.3 Upstream LSR: NotAvailable Procedure ............... 52
5.1.3.1 RequestRetry ....................................... 52
5.1.3.2 RequestNoRetry ..................................... 52
5.1.4 Upstream LSR: Release Procedure .................... 52
5.1.4.1 ReleaseOnChange .................................... 52
5.1.4.2 NoReleaseOnChange .................................. 53
5.1.5 Upstream LSR: labelUse Procedure ................... 53
5.1.5.1 UseImmediate ....................................... 53
5.1.5.2 UseIfLoopNotDetected ............................... 53
5.1.6 Downstream LSR: Withdraw Procedure ................. 53
5.2 MPLS Schemes: Supported Combinations of Procedures . 54
5.2.1 Schemes for LSRs that Support Label Merging ........ 55
5.2.2 Schemes for LSRs that do not Support Label Merging . 56
5.2.3 Interoperability Considerations .................... 57
6 Security Considerations ............................ 58
7 Intellectual Property .............................. 58
8 Authors' Addresses ................................. 59
9 References ......................................... 59
10 Full Copyright Statement ........................... 61
4.4 MPLS and Multi-Path Routing ........................ 44
4.5 LSP Trees as Multipoint-to-Point Entities .......... 44
4.6 LSP Tunneling between BGP Border Routers ........... 45
4.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 47
4.8 MPLS and Multicast ................................. 47
5 Label Distribution Procedures (Hop-by-Hop) ......... 47
5.1 The Procedures for Advertising and Using labels .... 48
5.1.1 Downstream LSR: Distribution Procedure ............. 48
5.1.1.1 PushUnconditional .................................. 49
5.1.1.2 PushConditional .................................... 49
5.1.1.3 PulledUnconditional ................................ 49
5.1.1.4 PulledConditional .................................. 50
5.1.2 Upstream LSR: Request Procedure .................... 51
5.1.2.1 RequestNever ....................................... 51
5.1.2.2 RequestWhenNeeded .................................. 51
5.1.2.3 RequestOnRequest ................................... 51
5.1.3 Upstream LSR: NotAvailable Procedure ............... 52
5.1.3.1 RequestRetry ....................................... 52
5.1.3.2 RequestNoRetry ..................................... 52
5.1.4 Upstream LSR: Release Procedure .................... 52
5.1.4.1 ReleaseOnChange .................................... 52
5.1.4.2 NoReleaseOnChange .................................. 53
5.1.5 Upstream LSR: labelUse Procedure ................... 53
5.1.5.1 UseImmediate ....................................... 53
5.1.5.2 UseIfLoopNotDetected ............................... 53
5.1.6 Downstream LSR: Withdraw Procedure ................. 53
5.2 MPLS Schemes: Supported Combinations of Procedures . 54
5.2.1 Schemes for LSRs that Support Label Merging ........ 55
5.2.2 Schemes for LSRs that do not Support Label Merging . 56
5.2.3 Interoperability Considerations .................... 57
6 Security Considerations ............................ 58
7 Intellectual Property .............................. 58
8 Authors' Addresses ................................. 59
9 References ......................................... 59
10 Full Copyright Statement ........................... 61
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中的说明进行解释。
This document specifies the architecture for Multiprotocol Label Switching (MPLS).
本文件规定了多协议标签交换（MPLS）的体系结构。
Note that the use of MPLS for multicast is left for further study.
请注意，对于多播使用MPLS还有待进一步研究。
As a packet of a connectionless network layer protocol travels from one router to the next, each router makes an independent forwarding decision for that packet. That is, each router analyzes the packet's header, and each router runs a network layer routing algorithm. Each router independently chooses a next hop for the packet, based on its analysis of the packet's header and the results of running the routing algorithm.
当无连接网络层协议的数据包从一个路由器传输到下一个路由器时，每个路由器对该数据包做出独立的转发决策。也就是说，每个路由器分析数据包的报头，每个路由器运行一个网络层路由算法。每个路由器根据对数据包报头的分析和运行路由算法的结果，独立地为数据包选择下一跳。
Packet headers contain considerably more information than is needed simply to choose the next hop. Choosing the next hop can therefore be thought of as the composition of two functions. The first function partitions the entire set of possible packets into a set of "Forwarding Equivalence Classes (FECs)". The second maps each FEC to a next hop. Insofar as the forwarding decision is concerned, different packets which get mapped into the same FEC are indistinguishable. All packets which belong to a particular FEC and which travel from a particular node will follow the same path (or if certain kinds of multi-path routing are in use, they will all follow one of a set of paths associated with the FEC).
数据包头包含的信息远远多于选择下一跳所需的信息。因此，选择下一跳可以被认为是两个函数的组合。第一个函数将整个可能的数据包集划分为一组“转发等价类（FEC）”。第二个将每个FEC映射到下一个跃点。就转发决策而言，映射到同一FEC的不同分组是不可区分的。属于特定FEC且从特定节点传输的所有分组将遵循相同的路径（或者，如果正在使用某些类型的多路径路由，则它们将全部遵循与FEC相关联的一组路径之一）。
In conventional IP forwarding, a particular router will typically consider two packets to be in the same FEC if there is some address prefix X in that router's routing tables such that X is the "longest match" for each packet's destination address. As the packet traverses the network, each hop in turn reexamines the packet and assigns it to a FEC.
在传统的IP转发中，如果路由器的路由表中有一些地址前缀X，那么X将是每个包的目标地址的“最长匹配”，特定路由器通常会考虑两个包处于相同的FEC中。当数据包穿越网络时，每个跃点依次重新检查数据包并将其分配给FEC。
In MPLS, the assignment of a particular packet to a particular FEC is done just once, as the packet enters the network. The FEC to which the packet is assigned is encoded as a short fixed length value known as a "label". When a packet is forwarded to its next hop, the label is sent along with it; that is, the packets are "labeled" before they are forwarded.
在MPLS中，当数据包进入网络时，将特定数据包分配给特定FEC只需一次。分组被分配到的FEC被编码为称为“标签”的短固定长度值。当一个数据包被转发到它的下一个跃点时，标签也随之发送；也就是说，数据包在转发之前会被“标记”。
At subsequent hops, there is no further analysis of the packet's network layer header. Rather, the label is used as an index into a table which specifies the next hop, and a new label. The old label is replaced with the new label, and the packet is forwarded to its next hop.
在随后的跳数中，对数据包的网络层报头没有进一步的分析。相反，标签用作表的索引，表指定下一个跃点和新标签。旧标签被新标签替换，数据包被转发到下一跳。
In the MPLS forwarding paradigm, once a packet is assigned to a FEC, no further header analysis is done by subsequent routers; all forwarding is driven by the labels. This has a number of advantages over conventional network layer forwarding.
在MPLS转发范例中，一旦分组被分配给FEC，后续路由器就不再进行进一步的报头分析；所有的转发都是由标签驱动的。与传统的网络层转发相比，这有许多优点。
- MPLS forwarding can be done by switches which are capable of doing label lookup and replacement, but are either not capable of analyzing the network layer headers, or are not capable of analyzing the network layer headers at adequate speed.
- MPLS转发可以由能够进行标签查找和替换的交换机完成，但不能分析网络层报头，或者不能以足够的速度分析网络层报头。
- Since a packet is assigned to a FEC when it enters the network, the ingress router may use, in determining the assignment, any information it has about the packet, even if that information cannot be gleaned from the network layer header. For example, packets arriving on different ports may be assigned to different FECs. Conventional forwarding, on the other hand, can only consider information which travels with the packet in the packet header.
- 由于分组在进入网络时被分配给FEC，因此在确定分配时，入口路由器可以使用其关于分组的任何信息，即使该信息不能从网络层报头收集。例如，到达不同端口的分组可以被分配给不同的fec。另一方面，传统的转发只能考虑在分组报头中与分组一起传播的信息。
- A packet that enters the network at a particular router can be labeled differently than the same packet entering the network at a different router, and as a result forwarding decisions that depend on the ingress router can be easily made. This cannot be done with conventional forwarding, since the identity of a packet's ingress router does not travel with the packet.
- 在特定路由器进入网络的分组可以被标记为不同于在不同路由器进入网络的相同分组，并且因此可以容易地做出依赖于入口路由器的转发决策。这不能通过传统的转发来实现，因为数据包的入口路由器的身份不随数据包一起传输。
- The considerations that determine how a packet is assigned to a FEC can become ever more and more complicated, without any impact at all on the routers that merely forward labeled packets.
- 决定如何将数据包分配给FEC的考虑因素可能变得越来越复杂，对仅转发标记数据包的路由器没有任何影响。
- Sometimes it is desirable to force a packet to follow a particular route which is explicitly chosen at or before the time the packet enters the network, rather than being chosen by the normal dynamic routing algorithm as the packet travels through the network. This may be done as a matter of policy, or to support traffic engineering. In conventional forwarding, this requires the packet to carry an encoding of its route along with it ("source routing"). In MPLS, a label can be used to represent the route, so that the identity of the explicit route need not be carried with the packet.
- 有时，希望强制分组遵循在分组进入网络时或之前明确选择的特定路由，而不是在分组通过网络时由正常动态路由算法选择。这可以作为一项政策，或支持交通工程。在传统转发中，这要求数据包携带其路由的编码（“源路由”）。在MPLS中，可以使用标签来表示路由，因此显式路由的标识不需要与数据包一起携带。
Some routers analyze a packet's network layer header not merely to choose the packet's next hop, but also to determine a packet's "precedence" or "class of service". They may then apply different discard thresholds or scheduling disciplines to different packets. MPLS allows (but does not require) the precedence or class of service to be fully or partially inferred from the label. In this case, one may say that the label represents the combination of a FEC and a precedence or class of service.
一些路由器分析数据包的网络层报头，不仅是为了选择数据包的下一跳，还为了确定数据包的“优先级”或“服务级别”。然后，他们可以对不同的数据包应用不同的丢弃阈值或调度规程。MPLS允许（但不要求）从标签中完全或部分推断服务的优先级或类别。在这种情况下，可以说标签表示FEC和优先级或服务类别的组合。
MPLS stands for "Multiprotocol" Label Switching, multiprotocol because its techniques are applicable to ANY network layer protocol. In this document, however, we focus on the use of IP as the network layer protocol.
MPLS代表“多协议”标签交换，多协议，因为其技术适用于任何网络层协议。然而，在本文档中，我们将重点介绍IP作为网络层协议的使用。
A router which supports MPLS is known as a "Label Switching Router", or LSR.
支持MPLS的路由器称为“标签交换路由器”，或LSR。
This section gives a general conceptual overview of the terms used in this document. Some of these terms are more precisely defined in later sections of the document.
本节给出了本文件中所用术语的一般概念概述。其中一些术语在本文件后面的章节中有更精确的定义。
DLCI a label used in Frame Relay networks to identify frame relay circuits
帧中继网络中用于识别帧中继电路的标签
forwarding equivalence class a group of IP packets which are forwarded in the same manner (e.g., over the same path, with the same forwarding treatment)
转发等价类以相同方式转发的一组IP数据包（例如，通过相同路径，采用相同的转发处理）
frame merge label merging, when it is applied to operation over frame based media, so that the potential problem of cell interleave is not an issue.
帧合并标签合并，当它应用于基于帧的媒体上的操作时，因此单元交织的潜在问题不是问题。
label a short fixed length physically contiguous identifier which is used to identify a FEC, usually of local significance.
标签一个短的固定长度的物理连续标识符，用于识别FEC，通常具有局部意义。
label merging the replacement of multiple incoming labels for a particular FEC with a single outgoing label
标签合并将特定FEC的多个传入标签替换为单个传出标签
label swap the basic forwarding operation consisting of looking up an incoming label to determine the outgoing label, encapsulation, port, and other data handling information.
标签交换基本转发操作，包括查找传入标签以确定传出标签、封装、端口和其他数据处理信息。
label swapping a forwarding paradigm allowing streamlined forwarding of data by using labels to identify classes of data packets which are treated indistinguishably when forwarding.
标签交换一种转发模式，通过使用标签识别转发时不区分处理的数据包类别，简化数据转发。
label switched hop the hop between two MPLS nodes, on which forwarding is done using labels.
标签交换跃点两个MPLS节点之间的跃点，在其上使用标签进行转发。
label switched path The path through one or more LSRs at one level of the hierarchy followed by a packets in a particular FEC.
标签交换路径在层次结构的一个级别上通过一个或多个LSR的路径，后跟特定FEC中的数据包。
label switching router an MPLS node which is capable of forwarding native L3 packets
标签交换路由器能够转发本机L3数据包的MPLS节点
layer 2 the protocol layer under layer 3 (which therefore offers the services used by layer 3). Forwarding, when done by the swapping of short fixed length labels, occurs at layer 2 regardless of whether the label being examined is an ATM VPI/VCI, a frame relay DLCI, or an MPLS label.
第2层是第3层下的协议层（因此提供第3层使用的服务）。通过交换固定长度的短标签进行转发时，无论正在检查的标签是ATM VPI/VCI、帧中继DLCI还是MPLS标签，都会在第2层进行转发。
layer 3 the protocol layer at which IP and its associated routing protocols operate link layer synonymous with layer 2
第3层IP及其相关路由协议运行的协议层链路层与第2层同义
loop detection a method of dealing with loops in which loops are allowed to be set up, and data may be transmitted over the loop, but the loop is later detected
环路检测一种处理环路的方法，允许设置环路，数据可以在环路上传输，但随后会检测到环路
loop prevention a method of dealing with loops in which data is never transmitted over a loop
环路预防处理数据从未通过环路传输的环路的方法
label stack an ordered set of labels
标签堆栈一组有序的标签
merge point a node at which label merging is done
合并点完成标签合并的节点
MPLS domain a contiguous set of nodes which operate MPLS routing and forwarding and which are also in one Routing or Administrative Domain
MPLS域操作MPLS路由和转发的一组连续节点，它们也位于一个路由或管理域中
MPLS edge node an MPLS node that connects an MPLS domain with a node which is outside of the domain, either because it does not run MPLS, and/or because it is in a different domain. Note that if an LSR has a neighboring host which is not running MPLS, that that LSR is an MPLS edge node.
MPLS边缘节点连接MPLS域与域外节点的MPLS节点，原因可能是它不运行MPLS，和/或它位于不同的域中。请注意，如果LSR有一个不运行MPLS的相邻主机，则该LSR是一个MPLS边缘节点。
MPLS egress node an MPLS edge node in its role in handling traffic as it leaves an MPLS domain
MPLS出口节点在离开MPLS域时处理流量的MPLS边缘节点
MPLS ingress node an MPLS edge node in its role in handling traffic as it enters an MPLS domain
MPLS入口节点在进入MPLS域时处理流量的MPLS边缘节点
MPLS label a label which is carried in a packet header, and which represents the packet's FEC
MPLS标签数据包头中携带的标签，表示数据包的FEC
MPLS node a node which is running MPLS. An MPLS node will be aware of MPLS control protocols, will operate one or more L3 routing protocols, and will be capable of forwarding packets based on labels. An MPLS node may optionally be also capable of forwarding native L3 packets.
MPLS节点运行MPLS的节点。MPLS节点将知道MPLS控制协议，将操作一个或多个L3路由协议，并且将能够基于标签转发数据包。MPLS节点还可以可选地能够转发本机L3分组。
MultiProtocol Label Switching an IETF working group and the effort associated with the working group
IETF工作组的多协议标签交换及其相关工作
network layer synonymous with layer 3
网络层与第3层同义
stack synonymous with label stack
堆栈与标签堆栈同义
switched path synonymous with label switched path
交换路径与标签交换路径同义
virtual circuit a circuit used by a connection-oriented layer 2 technology such as ATM or Frame Relay, requiring the maintenance of state information in layer 2 switches.
虚拟电路面向连接的第2层技术（如ATM或帧中继）使用的电路，需要维护第2层交换机中的状态信息。
VC merge label merging where the MPLS label is carried in the ATM VCI field (or combined VPI/VCI field), so as to allow multiple VCs to merge into one single VC
VC合并标签合并，其中MPLS标签在ATM VCI字段（或组合VPI/VCI字段）中携带，以便允许多个VC合并为一个VC
VP merge label merging where the MPLS label is carried din the ATM VPI field, so as to allow multiple VPs to be merged into one single VP. In this case two cells would have the same VCI value only if they originated from the same node. This allows cells from different sources to be distinguished via the VCI.
VP合并标签合并，其中在ATM VPI字段中携带MPLS标签，以便允许将多个VP合并到一个VP中。在这种情况下，只有当两个单元来自同一节点时，它们才会具有相同的VCI值。这允许通过VCI区分来自不同来源的细胞。
VPI/VCI a label used in ATM networks to identify circuits
VPI/VCI在ATM网络中用于识别电路的标签
ATM Asynchronous Transfer Mode BGP Border Gateway Protocol DLCI Data Link Circuit Identifier FEC Forwarding Equivalence Class FTN FEC to NHLFE Map IGP Interior Gateway Protocol ILM Incoming Label Map IP Internet Protocol LDP Label Distribution Protocol L2 Layer 2 L3 Layer 3 LSP Label Switched Path LSR Label Switching Router MPLS MultiProtocol Label Switching NHLFE Next Hop Label Forwarding Entry SVC Switched Virtual Circuit SVP Switched Virtual Path TTL Time-To-Live VC Virtual Circuit VCI Virtual Circuit Identifier VP Virtual Path VPI Virtual Path Identifier
ATM异步传输模式BGP边界网关协议DLCI数据链路电路标识符FEC转发等价类FTN FEC到NHLFE映射IGP内部网关协议ILM传入标签映射IP互联网协议LDP标签分发协议L2层2 L3层3 LSP标签交换路径LSR标签交换路由器MPLS多协议标签交换NHLFE下一跳标签转发条目SVC交换虚拟电路SVP交换虚拟路径TTL生存时间VC虚拟电路VCI虚拟电路标识符VP虚拟路径VPI虚拟路径标识符
The ideas and text in this document have been collected from a number of sources and comments received. We would like to thank Rick Boivie, Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan, and George Swallow for their inputs and ideas.
本文件中的想法和文本是从许多来源和收到的评论中收集的。我们要感谢Rick Boivie、Paul Doolan、Nancy Feldman、Yakov Rekhter、Vijay Srinivasan和George Swallow的投入和想法。
In this section, we introduce some of the basic concepts of MPLS and describe the general approach to be used.
在本节中，我们将介绍MPLS的一些基本概念，并描述将要使用的一般方法。
A label is a short, fixed length, locally significant identifier which is used to identify a FEC. The label which is put on a particular packet represents the Forwarding Equivalence Class to which that packet is assigned.
标签是一个短的、固定长度的、局部有效的标识符，用于标识FEC。放置在特定数据包上的标签表示该数据包被分配到的转发等价类。
Most commonly, a packet is assigned to a FEC based (completely or partially) on its network layer destination address. However, the label is never an encoding of that address.
最常见的情况是，数据包根据其网络层目标地址（完全或部分）分配给FEC。但是，标签永远不是该地址的编码。
If Ru and Rd are LSRs, they may agree that when Ru transmits a packet to Rd, Ru will label with packet with label value L if and only if the packet is a member of a particular FEC F. That is, they can agree to a "binding" between label L and FEC F for packets moving from Ru to Rd. As a result of such an agreement, L becomes Ru's "outgoing label" representing FEC F, and L becomes Rd's "incoming label" representing FEC F.
如果Ru和Rd是LSR，他们可能同意，当Ru向Rd发送数据包时，Ru将使用标签值为L的数据包进行标记，当且仅当该数据包是特定FEC F的成员时。也就是说，他们可以同意标签L和FEC F之间对于从Ru移动到Rd的数据包的“绑定”。由于这种协议，L成为Ru的“传出标签”表示FEC F，L成为Rd表示FEC F的“传入标签”。
Note that L does not necessarily represent FEC F for any packets other than those which are being sent from Ru to Rd. L is an arbitrary value whose binding to F is local to Ru and Rd.
注意，对于从Ru发送到Rd的数据包以外的任何数据包，L不一定表示FEC F。L是任意值，其与F的绑定是Ru和Rd的本地绑定。
When we speak above of packets "being sent" from Ru to Rd, we do not imply either that the packet originated at Ru or that its destination is Rd. Rather, we mean to include packets which are "transit packets" at one or both of the LSRs.
当我们在上面提到从Ru“发送”到Rd的包时，我们并不意味着该包起源于Ru或其目的地是Rd。相反，我们的意思是包括在一个或两个lsr处的“传输包”的包。
Sometimes it may be difficult or even impossible for Rd to tell, of an arriving packet carrying label L, that the label L was placed in the packet by Ru, rather than by some other LSR. (This will typically be the case when Ru and Rd are not direct neighbors.) In such cases, Rd must make sure that the binding from label to FEC is one-to-one. That is, Rd MUST NOT agree with Ru1 to bind L to FEC F1, while also agreeing with some other LSR Ru2 to bind L to a different FEC F2, UNLESS Rd can always tell, when it receives a packet with incoming label L, whether the label was put on the packet by Ru1 or whether it was put on by Ru2.
有时，对于携带标签L的到达分组，Rd可能很难或甚至不可能判断标签L是由Ru而不是某个其他LSR放置在分组中的。（当Ru和Rd不是直接邻居时，通常会出现这种情况。）在这种情况下，Rd必须确保从标签到FEC的绑定是一对一的。也就是说，Rd不得同意Ru1将L绑定到FEC F1，同时也不得同意某些其他LSR Ru2将L绑定到不同的FEC F2，除非Rd在接收到带有传入标签L的数据包时，总是能够判断标签是由Ru1还是由Ru2放在数据包上。
It is the responsibility of each LSR to ensure that it can uniquely interpret its incoming labels.
每个LSR都有责任确保能够唯一地解释其传入标签。
Suppose Ru and Rd have agreed to bind label L to FEC F, for packets sent from Ru to Rd. Then with respect to this binding, Ru is the "upstream LSR", and Rd is the "downstream LSR".
假设Ru和Rd已经同意将标签L绑定到FEC F，用于从Ru发送到Rd的数据包。那么关于该绑定，Ru是“上游LSR”，Rd是“下游LSR”。
To say that one node is upstream and one is downstream with respect to a given binding means only that a particular label represents a particular FEC in packets travelling from the upstream node to the downstream node. This is NOT meant to imply that packets in that FEC would actually be routed from the upstream node to the downstream node.
对于给定绑定来说，一个节点是上游的，一个是下游的，这仅意味着特定标签表示从上游节点到下游节点的分组中的特定FEC。这并不意味着该FEC中的分组实际上将从上游节点路由到下游节点。
A "labeled packet" is a packet into which a label has been encoded. In some cases, the label resides in an encapsulation header which exists specifically for this purpose. In other cases, the label may reside in an existing data link or network layer header, as long as there is a field which is available for that purpose. The particular encoding technique to be used must be agreed to by both the entity which encodes the label and the entity which decodes the label.
“带标签的数据包”是一个已编码标签的数据包。在某些情况下，标签驻留在一个封装头中，该头是专门为此目的而存在的。在其他情况下，标签可以位于现有数据链路或网络层报头中，只要存在可用于该目的的字段。使用的特定编码技术必须得到编码标签的实体和解码标签的实体的同意。
In the MPLS architecture, the decision to bind a particular label L to a particular FEC F is made by the LSR which is DOWNSTREAM with respect to that binding. The downstream LSR then informs the upstream LSR of the binding. Thus labels are "downstream-assigned", and label bindings are distributed in the "downstream to upstream" direction.
在MPLS体系结构中，将特定标签L绑定到特定FEC F的决定由在该绑定下游的LSR作出。然后，下游LSR将绑定通知上游LSR。因此，标签是“下游指定的”，标签绑定分布在“下游到上游”的方向上。
If an LSR has been designed so that it can only look up labels that fall into a certain numeric range, then it merely needs to ensure that it only binds labels that are in that range.
如果LSR的设计使得它只能查找属于某个数字范围的标签，那么它只需要确保它只绑定该范围内的标签。
A particular binding of label L to FEC F, distributed by Rd to Ru, may have associated "attributes". If Ru, acting as a downstream LSR, also distributes a binding of a label to FEC F, then under certain conditions, it may be required to also distribute the corresponding attribute that it received from Rd.
由Rd分发到Ru的标签L到FEC F的特定绑定可能具有关联的“属性”。如果作为下游LSR的Ru也将标签的绑定分发给FEC F，则在某些条件下，可能还需要分发从Rd接收到的相应属性。
A label distribution protocol is a set of procedures by which one LSR informs another of the label/FEC bindings it has made. Two LSRs which use a label distribution protocol to exchange label/FEC binding information are known as "label distribution peers" with respect to the binding information they exchange. If two LSRs are label distribution peers, we will speak of there being a "label distribution adjacency" between them.
标签分发协议是一组程序，通过这些程序，一个LSR通知另一个LSR已进行的标签/FEC绑定。使用标签分发协议交换标签/FEC绑定信息的两个LSR就其交换的绑定信息而言称为“标签分发对等点”。如果两个LSR是标签分布对等点，我们将说它们之间存在“标签分布邻接”。
(N.B.: two LSRs may be label distribution peers with respect to some set of bindings, but not with respect to some other set of bindings.)
（注意：对于某些绑定集，两个LSR可能是标签分发对等点，但对于某些其他绑定集则不是。）
The label distribution protocol also encompasses any negotiations in which two label distribution peers need to engage in order to learn of each other's MPLS capabilities.
标签分发协议还包括两个标签分发对等方需要参与的任何协商，以便了解彼此的MPLS能力。
THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL DISTRIBUTION PROTOCOL. In fact, a number of different label distribution protocols are being standardized. Existing protocols have been extended so that label distribution can be piggybacked on them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]). New protocols have also been defined for the explicit purpose of distributing labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].
该体系结构并不假定只有一个标签分发协议。事实上，许多不同的标签分发协议正在标准化。现有协议已经扩展，因此标签分发可以在其上进行（例如参见[MPLS-BGP]、[MPLS-RSVP-TUNNELS]）。还定义了新的协议，明确用于分发标签（例如，参见[MPLS-LDP]、[MPLS-CR-LDP]）。
In this document, we try to use the acronym "LDP" to refer specifically to the protocol defined in [MPLS-LDP]; when speaking of label distribution protocols in general, we try to avoid the acronym.
在本文件中，我们尝试使用首字母缩略词“LDP”来专门指代[MPLS-LDP]中定义的协议；一般来说，在谈到标签分发协议时，我们尽量避免使用缩写词。
The MPLS architecture allows an LSR to explicitly request, from its next hop for a particular FEC, a label binding for that FEC. This is known as "downstream-on-demand" label distribution.
MPLS体系结构允许LSR从特定FEC的下一跳显式请求该FEC的标签绑定。这被称为“下游按需”标签分发。
The MPLS architecture also allows an LSR to distribute bindings to LSRs that have not explicitly requested them. This is known as "unsolicited downstream" label distribution.
MPLS体系结构还允许LSR将绑定分发到未明确请求它们的LSR。这称为“未经请求的下游”标签分发。
It is expected that some MPLS implementations will provide only downstream-on-demand label distribution, and some will provide only unsolicited downstream label distribution, and some will provide both. Which is provided may depend on the characteristics of the interfaces which are supported by a particular implementation. However, both of these label distribution techniques may be used in the same network at the same time. On any given label distribution adjacency, the upstream LSR and the downstream LSR must agree on which technique is to be used.
预计一些MPLS实现将仅提供下游按需标签分发，一些将仅提供未经请求的下游标签分发，而一些将同时提供两者。所提供的功能可能取决于特定实现所支持的接口的特性。然而，这两种标签分发技术可以同时在同一网络中使用。在任何给定的标签分布邻接上，上游LSR和下游LSR必须就使用哪种技术达成一致。
An LSR Ru may receive (or have received) a label binding for a particular FEC from an LSR Rd, even though Rd is not Ru's next hop (or is no longer Ru's next hop) for that FEC.
LSR-Ru可以从LSR-Rd接收（或已经接收）特定FEC的标签绑定，即使Rd不是Ru对该FEC的下一跳（或不再是Ru的下一跳）。
Ru then has the choice of whether to keep track of such bindings, or whether to discard such bindings. If Ru keeps track of such bindings, then it may immediately begin using the binding again if Rd eventually becomes its next hop for the FEC in question. If Ru discards such bindings, then if Rd later becomes the next hop, the binding will have to be reacquired.
然后，Ru可以选择是跟踪此类绑定，还是放弃此类绑定。如果Ru跟踪这些绑定，那么如果Rd最终成为所讨论的FEC的下一个跃点，它可能会立即再次开始使用绑定。如果Ru丢弃这样的绑定，那么如果Rd以后成为下一个跃点，则必须重新获取绑定。
If an LSR supports "Liberal Label Retention Mode", it maintains the bindings between a label and a FEC which are received from LSRs which are not its next hop for that FEC. If an LSR supports "Conservative Label Retention Mode", it discards such bindings.
如果LSR支持“自由标签保留模式”，它将维护标签和FEC之间的绑定，这些绑定是从LSR接收的，而LSR不是该FEC的下一跳。如果LSR支持“保守标签保留模式”，它将丢弃此类绑定。
Liberal label retention mode allows for quicker adaptation to routing changes, but conservative label retention mode though requires an LSR to maintain many fewer labels.
自由的标签保留模式允许更快地适应路由更改，但保守的标签保留模式需要LSR来维护更少的标签。
So far, we have spoken as if a labeled packet carries only a single label. As we shall see, it is useful to have a more general model in which a labeled packet carries a number of labels, organized as a last-in, first-out stack. We refer to this as a "label stack".
到目前为止，我们说的好像一个带标签的包只携带一个标签。正如我们将要看到的，有一个更一般的模型是有用的，在这个模型中，一个带标签的数据包携带许多标签，组织成一个后进先出的堆栈。我们称之为“标签堆栈”。
Although, as we shall see, MPLS supports a hierarchy, the processing of a labeled packet is completely independent of the level of hierarchy. The processing is always based on the top label, without regard for the possibility that some number of other labels may have been "above it" in the past, or that some number of other labels may be below it at present.
虽然，正如我们将看到的，MPLS支持层次结构，但标记数据包的处理完全独立于层次结构的级别。处理始终基于顶部标签，而不考虑一些其他标签在过去可能“在其上方”，或者一些其他标签目前可能在其下方的可能性。
An unlabeled packet can be thought of as a packet whose label stack is empty (i.e., whose label stack has depth 0).
未标记的数据包可以被认为是其标签堆栈为空（即，其标签堆栈深度为0）的数据包。
If a packet's label stack is of depth m, we refer to the label at the bottom of the stack as the level 1 label, to the label above it (if such exists) as the level 2 label, and to the label at the top of the stack as the level m label.
如果数据包的标签堆栈深度为m，我们将堆栈底部的标签称为1级标签，将其上方的标签（如果存在）称为2级标签，将堆栈顶部的标签称为m级标签。
The utility of the label stack will become clear when we introduce the notion of LSP Tunnel and the MPLS Hierarchy (section 3.27).
当我们介绍LSP隧道和MPLS层次结构（第3.27节）的概念时，标签堆栈的效用将变得清晰。
The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding a labeled packet. It contains the following information:
“下一跳标签转发条目”（NHLFE）用于转发标记的数据包。它包含以下信息：
1. the packet's next hop
1. 包的下一跳
2. the operation to perform on the packet's label stack; this is one of the following operations:
2. 在数据包的标签堆栈上执行的操作；这是以下操作之一：
a) replace the label at the top of the label stack with a specified new label
a) 用指定的新标签替换标签堆栈顶部的标签
b) pop the label stack
b) 弹出标签堆栈
c) replace the label at the top of the label stack with a specified new label, and then push one or more specified new labels onto the label stack.
c) 用指定的新标签替换标签堆栈顶部的标签，然后将一个或多个指定的新标签推到标签堆栈上。
It may also contain:
它还可能包含：
d) the data link encapsulation to use when transmitting the packet
d) 传输数据包时使用的数据链路封装
e) the way to encode the label stack when transmitting the packet
e) 传输数据包时对标签堆栈进行编码的方法
f) any other information needed in order to properly dispose of the packet.
f) 正确处理数据包所需的任何其他信息。
Note that at a given LSR, the packet's "next hop" might be that LSR itself. In this case, the LSR would need to pop the top level label, and then "forward" the resulting packet to itself. It would then make another forwarding decision, based on what remains after the label stacked is popped. This may still be a labeled packet, or it may be the native IP packet.
请注意，在给定的LSR上，数据包的“下一跳”可能是该LSR本身。在这种情况下，LSR将需要弹出顶层标签，然后将结果包“转发”到自身。然后，它将根据弹出标签后剩余的内容做出另一个转发决定。这可能仍然是带标签的数据包，也可能是本机IP数据包。
This implies that in some cases the LSR may need to operate on the IP header in order to forward the packet.
这意味着在某些情况下，LSR可能需要在IP报头上操作以转发分组。
If the packet's "next hop" is the current LSR, then the label stack operation MUST be to "pop the stack".
如果数据包的“下一跳”是当前LSR，那么标签堆栈操作必须是“弹出堆栈”。
The "Incoming Label Map" (ILM) maps each incoming label to a set of NHLFEs. It is used when forwarding packets that arrive as labeled packets.
“传入标签映射”（ILM）将每个传入标签映射到一组NHLFE。它用于转发作为标记数据包到达的数据包。
If the ILM maps a particular label to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the ILM map a label to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths.
如果ILM将特定标签映射到一组包含多个元素的NHLFE，则在转发数据包之前，必须选择该组中的一个元素。从集合中选择元素的过程超出了本文档的范围。例如，如果希望在多个等成本路径上进行负载平衡，则让ILM将标签映射到包含多个NHLFE的集合可能很有用。
The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is used when forwarding packets that arrive unlabeled, but which are to be labeled before being forwarded.
“FEC到NHLFE”（FTN）将每个FEC映射到一组NHLFE。它用于转发未标记但在转发前要标记的数据包。
If the FTN maps a particular label to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the FTN map a label to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths.
如果FTN将特定标签映射到包含多个元素的NHLFE集合，则在转发数据包之前，必须选择集合中的一个元素。从集合中选择元素的过程超出了本文档的范围。例如，如果希望在多个等成本路径上进行负载平衡，则使FTN将标签映射到包含多个NHLFE的集合可能是有用的。
Label swapping is the use of the following procedures to forward a packet.
标签交换是使用以下步骤转发数据包。
In order to forward a labeled packet, a LSR examines the label at the top of the label stack. It uses the ILM to map this label to an NHLFE. Using the information in the NHLFE, it determines where to forward the packet, and performs an operation on the packet's label stack. It then encodes the new label stack into the packet, and forwards the result.
为了转发带标签的数据包，LSR检查标签堆栈顶部的标签。它使用ILM将此标签映射到NHLFE。使用NHLFE中的信息，它确定将数据包转发到哪里，并对数据包的标签堆栈执行操作。然后将新标签堆栈编码到数据包中，并转发结果。
In order to forward an unlabeled packet, a LSR analyzes the network layer header, to determine the packet's FEC. It then uses the FTN to map this to an NHLFE. Using the information in the NHLFE, it determines where to forward the packet, and performs an operation on the packet's label stack. (Popping the label stack would, of course, be illegal in this case.) It then encodes the new label stack into the packet, and forwards the result.
为了转发未标记的分组，LSR分析网络层报头以确定分组的FEC。然后使用FTN将其映射到NHLFE。使用NHLFE中的信息，它确定将数据包转发到哪里，并对数据包的标签堆栈执行操作。（在这种情况下，弹出标签堆栈当然是非法的。）然后它将新标签堆栈编码到数据包中，并转发结果。
IT IS IMPORTANT TO NOTE THAT WHEN LABEL SWAPPING IS IN USE, THE NEXT HOP IS ALWAYS TAKEN FROM THE NHLFE; THIS MAY IN SOME CASES BE DIFFERENT FROM WHAT THE NEXT HOP WOULD BE IF MPLS WERE NOT IN USE.
需要注意的是，在使用标签交换时，下一个跃点始终取自NHLFE；在某些情况下，这可能与不使用MPLS时的下一跳不同。
A given LSR Rd may bind label L1 to FEC F, and distribute that binding to label distribution peer Ru1. Rd may also bind label L2 to FEC F, and distribute that binding to label distribution peer Ru2. Whether or not L1 == L2 is not determined by the architecture; this is a local matter.
给定的LSR Rd可以将标签L1绑定到FEC F，并将该绑定分发到标签分发对等Ru1。Rd还可以将标签L2绑定到FEC F，并将该绑定分发到标签分发对等Ru2。L1==L2是否由架构决定；这是当地的事。
A given LSR Rd may bind label L to FEC F1, and distribute that binding to label distribution peer Ru1. Rd may also bind label L to FEC F2, and distribute that binding to label distribution peer Ru2. IF (AND ONLY IF) RD CAN TELL, WHEN IT RECEIVES A PACKET WHOSE TOP LABEL IS L, WHETHER THE LABEL WAS PUT THERE BY RU1 OR BY RU2, THEN THE ARCHITECTURE DOES NOT REQUIRE THAT F1 == F2. In such cases, we may say that Rd is using a different "label space" for the labels it distributes to Ru1 than for the labels it distributes to Ru2.
给定的LSR Rd可以将标签L绑定到FEC F1，并将该绑定分发到标签分发对等Ru1。Rd还可以将标签L绑定到FEC F2，并将该绑定分发到标签分发对等Ru2。如果（且仅当）RD在接收到顶部标签为L的数据包时，能够判断标签是由RU1还是由RU2放在那里，则架构不要求F1==F2。在这种情况下，我们可以说Rd为其分发给Ru1的标签使用的“标签空间”与为其分发给Ru2的标签使用的“标签空间”不同。
In general, Rd can only tell whether it was Ru1 or Ru2 that put the particular label value L at the top of the label stack if the following conditions hold:
通常，如果满足以下条件，Rd只能判断将特定标签值L置于标签堆栈顶部的是Ru1还是Ru2：
- Ru1 and Ru2 are the only label distribution peers to which Rd distributed a binding of label value L, and
- Ru1和Ru2是Rd向其分发标签值L绑定的唯一标签分发对等点，并且
- Ru1 and Ru2 are each directly connected to Rd via a point-to-point interface.
- Ru1和Ru2分别通过点对点接口直接连接到Rd。
When these conditions hold, an LSR may use labels that have "per interface" scope, i.e., which are only unique per interface. We may say that the LSR is using a "per-interface label space". When these conditions do not hold, the labels must be unique over the LSR which has assigned them, and we may say that the LSR is using a "per-platform label space."
当这些条件成立时，LSR可以使用具有“每个接口”范围的标签，即仅每个接口唯一的标签。我们可以说LSR使用的是“每个接口标签空间”。当这些条件不成立时，标签必须在分配它们的LSR上是唯一的，我们可以说LSR使用的是“每个平台标签空间”
If a particular LSR Rd is attached to a particular LSR Ru over two point-to-point interfaces, then Rd may distribute to Ru a binding of label L to FEC F1, as well as a binding of label L to FEC F2, F1 != F2, if and only if each binding is valid only for packets which Ru sends to Rd over a particular one of the interfaces. In all other cases, Rd MUST NOT distribute to Ru bindings of the same label value to two different FECs.
如果通过两个点到点接口将特定LSR Rd连接到特定LSR Ru，则Rd可以向Ru分发标签L到FEC F1的绑定，以及标签L到FEC F2、F1的绑定！=F2，当且仅当每个绑定仅对Ru通过特定接口之一发送给Rd的数据包有效。在所有其他情况下，Rd不得将相同标签值的绑定分发到两个不同的FEC。
This prohibition holds even if the bindings are regarded as being at different "levels of hierarchy". In MPLS, there is no notion of having a different label space for different levels of the hierarchy; when interpreting a label, the level of the label is irrelevant.
即使绑定被视为处于不同的“层次结构级别”，该禁令仍然有效。在MPLS中，对于层次结构的不同级别，没有使用不同标签空间的概念；解释标签时，标签的级别无关。
The question arises as to whether it is possible for an LSR to use multiple per-platform label spaces, or to use multiple per-interface label spaces for the same interface. This is not prohibited by the architecture. However, in such cases the LSR must have some means, not specified by the architecture, of determining, for a particular incoming label, which label space that label belongs to. For example, [MPLS-SHIM] specifies that a different label space is used for unicast packets than for multicast packets, and uses a data link layer codepoint to distinguish the two label spaces.
出现的问题是，LSR是否可以使用多个每平台标签空间，或者为同一接口使用多个每接口标签空间。这不是体系结构所禁止的。然而，在这种情况下，LSR必须有一些方法（架构未指定）来确定特定传入标签的标签所属的标签空间。例如，[MPLS-SHIM]指定单播分组使用的标签空间与多播分组不同，并使用数据链路层码点来区分这两个标签空间。
A "Label Switched Path (LSP) of level m" for a particular packet P is a sequence of routers,
特定分组P的“m级标签交换路径（LSP）”是路由器序列，
<R1, ..., Rn>
<R1，…，Rn>
with the following properties:
具有以下特性：
1. R1, the "LSP Ingress", is an LSR which pushes a label onto P's label stack, resulting in a label stack of depth m;
1. R1，“LSP入口”是一个LSR，它将标签推到P的标签堆栈上，产生深度为m的标签堆栈；
2. For all i, 1<i<n, P has a label stack of depth m when received by LSR Ri;
2. 对于所有i，1<i<n，当LSR Ri接收到P时，P具有深度为m的标签堆栈；
3. At no time during P's transit from R1 to R[n-1] does its label stack ever have a depth of less than m;
3. 在P从R1传输到R[n-1]的过程中，其标签堆栈的深度从未小于m；
4. For all i, 1<i<n: Ri transmits P to R[i+1] by means of MPLS, i.e., by using the label at the top of the label stack (the level m label) as an index into an ILM;
4. 对于所有i，1<i<n:Ri通过MPLS将P传输到R[i+1]，即通过使用标签堆栈顶部的标签（m级标签）作为ILM的索引；
5. For all i, 1<i<n: if a system S receives and forwards P after P is transmitted by Ri but before P is received by R[i+1] (e.g., Ri and R[i+1] might be connected via a switched data link subnetwork, and S might be one of the data link switches), then S's forwarding decision is not based on the level m label, or on the network layer header. This may be because:
5. 对于所有i，1<i<n：如果系统S在P被Ri发送之后但在P被R[i+1]接收之前接收并转发P（例如，Ri和R[i+1]可能通过交换数据链路子网连接，并且S可能是数据链路交换机之一），则S的转发决策不基于m级标签或网络层报头。这可能是因为：
a) the decision is not based on the label stack or the network layer header at all;
a) 决定根本不是基于标签堆栈或网络层头；
b) the decision is based on a label stack on which additional labels have been pushed (i.e., on a level m+k label, where k>0).
b) 该决定基于已推送其他标签的标签堆栈（即，在级别m+k标签上，其中k>0）。
In other words, we can speak of the level m LSP for Packet P as the sequence of routers:
换句话说，我们可以将分组P的m级LSP称为路由器序列：
1. which begins with an LSR (an "LSP Ingress") that pushes on a level m label,
1. 以LSR（“LSP入口”）开始，该LSR推送m级标签，
2. all of whose intermediate LSRs make their forwarding decision by label Switching on a level m label,
2. 所有中间LSR通过在m级标签上切换标签来做出转发决策，
3. which ends (at an "LSP Egress") when a forwarding decision is made by label Switching on a level m-k label, where k>0, or when a forwarding decision is made by "ordinary", non-MPLS forwarding procedures.
3. 当通过m-k级标签上的标签切换做出转发决定时（其中k>0），或当通过“普通”非MPLS转发过程做出转发决定时，其结束（在“LSP出口”）。
A consequence (or perhaps a presupposition) of this is that whenever an LSR pushes a label onto an already labeled packet, it needs to make sure that the new label corresponds to a FEC whose LSP Egress is the LSR that assigned the label which is now second in the stack.
其结果（或者可能是一个前提）是，每当LSR将标签推到已标记的数据包上时，它需要确保新标签对应于一个FEC，该FEC的LSP出口是分配标签的LSR，该标签现在是堆栈中的第二个标签。
We will call a sequence of LSRs the "LSP for a particular FEC F" if it is an LSP of level m for a particular packet P when P's level m label is a label corresponding to FEC F.
当P的m级标签是对应于FEC F的标签时，如果它是特定分组P的m级LSP，我们将lsr序列称为“特定FEC F的LSP”。
Consider the set of nodes which may be LSP ingress nodes for FEC F. Then there is an LSP for FEC F which begins with each of those nodes. If a number of those LSPs have the same LSP egress, then one can consider the set of such LSPs to be a tree, whose root is the LSP egress. (Since data travels along this tree towards the root, this may be called a multipoint-to-point tree.) We can thus speak of the "LSP tree" for a particular FEC F.
考虑一组节点可以是FEC F的LSP入口节点，然后有FEC F的LSP，每个节点都从LSC开始。如果一些LSP具有相同的LSP出口，那么可以考虑这样的LSP的集合是树，其根是LSP出口。（由于数据沿着这棵树向根方向移动，这可以称为多点对点树。）因此，我们可以为特定的FEC F称为“LSP树”。
Note that according to the definitions of section 3.15, if <R1, ..., Rn> is a level m LSP for packet P, P may be transmitted from R[n-1] to Rn with a label stack of depth m-1. That is, the label stack may be popped at the penultimate LSR of the LSP, rather than at the LSP Egress.
注意，根据第3.15节的定义，如果<R1，…，Rn>是分组P的m级LSP，则P可以使用深度为m-1的标签堆栈从R[n-1]发送到Rn。也就是说，标签堆栈可以在LSP的倒数第二个LSR处弹出，而不是在LSP出口处弹出。
From an architectural perspective, this is perfectly appropriate. The purpose of the level m label is to get the packet to Rn. Once R[n-1] has decided to send the packet to Rn, the label no longer has any function, and need no longer be carried.
从架构的角度来看，这是非常合适的。级别m标签的目的是将数据包发送到Rn。一旦R[n-1]决定将数据包发送给Rn，标签就不再具有任何功能，并且不再需要携带。
There is also a practical advantage to doing penultimate hop popping. If one does not do this, then when the LSP egress receives a packet, it first looks up the top label, and determines as a result of that lookup that it is indeed the LSP egress. Then it must pop the stack, and examine what remains of the packet. If there is another label on the stack, the egress will look this up and forward the packet based on this lookup. (In this case, the egress for the packet's level m LSP is also an intermediate node for its level m-1 LSP.) If there is no other label on the stack, then the packet is forwarded according to its network layer destination address. Note that this would require the egress to do TWO lookups, either two label lookups or a label lookup followed by an address lookup.
倒数第二跳弹跳还有一个实际优势。如果不这样做，那么当LSP出口接收到分组时，它首先查找顶部标签，并作为该查找的结果确定它确实是LSP出口。然后它必须弹出堆栈，并检查数据包的剩余部分。如果堆栈上有另一个标签，出口将查找该标签并根据该查找转发数据包。（在这种情况下，分组的m级LSP的出口也是其m-1级LSP的中间节点。）如果栈上没有其他标签，则分组根据其网络层目的地地址转发。请注意，这将需要出口执行两次查找，两次标签查找或一次标签查找，然后是地址查找。
If, on the other hand, penultimate hop popping is used, then when the penultimate hop looks up the label, it determines:
另一方面，如果使用倒数第二个跃点弹出，则当倒数第二个跃点查找标签时，它确定：
- that it is the penultimate hop, and
- 这是倒数第二跳
- who the next hop is.
- 下一跳是谁。
The penultimate node then pops the stack, and forwards the packet based on the information gained by looking up the label that was previously at the top of the stack. When the LSP egress receives the
然后倒数第二个节点弹出堆栈，并根据通过查找先前位于堆栈顶部的标签而获得的信息转发数据包。当LSP出口接收到
packet, the label which is now at the top of the stack will be the label which it needs to look up in order to make its own forwarding decision. Or, if the packet was only carrying a single label, the LSP egress will simply see the network layer packet, which is just what it needs to see in order to make its forwarding decision.
数据包，现在位于堆栈顶部的标签将是它需要查找的标签，以便做出自己的转发决策。或者，如果数据包仅携带一个标签，LSP出口将只看到网络层数据包，这正是它需要看到的，以便做出转发决策。
This technique allows the egress to do a single lookup, and also requires only a single lookup by the penultimate node.
此技术允许出口执行单个查找，并且只需要倒数第二个节点执行单个查找。
The creation of the forwarding "fastpath" in a label switching product may be greatly aided if it is known that only a single lookup is ever required:
如果已知只需要一次查找，则在标签交换产品中创建转发“快速路径”可能会有很大帮助：
- the code may be simplified if it can assume that only a single lookup is ever needed
- 如果可以假定只需要一次查找，那么代码可能会简化
- the code can be based on a "time budget" that assumes that only a single lookup is ever needed.
- 代码可以基于“时间预算”，该预算假定只需要一次查找。
In fact, when penultimate hop popping is done, the LSP Egress need not even be an LSR.
事实上，当倒数第二跳弹出完成时，LSP出口甚至不需要是LSR。
However, some hardware switching engines may not be able to pop the label stack, so this cannot be universally required. There may also be some situations in which penultimate hop popping is not desirable. Therefore the penultimate node pops the label stack only if this is specifically requested by the egress node, OR if the next node in the LSP does not support MPLS. (If the next node in the LSP does support MPLS, but does not make such a request, the penultimate node has no way of knowing that it in fact is the penultimate node.)
但是，某些硬件交换引擎可能无法弹出标签堆栈，因此这不是普遍需要的。也可能有一些情况下倒数第二跳弹出是不可取的。因此，倒数第二个节点仅在出口节点明确请求时，或者如果LSP中的下一个节点不支持MPLS，才会弹出标签堆栈。（如果LSP中的下一个节点确实支持MPLS，但没有发出这样的请求，则倒数第二个节点无法知道它实际上是倒数第二个节点。）
An LSR which is capable of popping the label stack at all MUST do penultimate hop popping when so requested by its downstream label distribution peer.
当下游标签分发对等方请求时，能够弹出标签堆栈的LSR必须进行倒数第二跳弹出。
Initial label distribution protocol negotiations MUST allow each LSR to determine whether its neighboring LSRS are capable of popping the label stack. A LSR MUST NOT request a label distribution peer to pop the label stack unless it is capable of doing so.
初始标签分发协议协商必须允许每个LSR确定其相邻LSR是否能够弹出标签堆栈。LSR不得请求标签分发对等方弹出标签堆栈，除非它能够这样做。
It may be asked whether the egress node can always interpret the top label of a received packet properly if penultimate hop popping is used. As long as the uniqueness and scoping rules of section 3.14 are obeyed, it is always possible to interpret the top label of a received packet unambiguously.
可以询问如果使用倒数第二跳弹出，出口节点是否总是能够正确地解释接收到的分组的顶部标签。只要遵守第3.14节的唯一性和范围规则，就始终可以毫不含糊地解释所接收数据包的顶部标签。
The LSP Next Hop for a particular labeled packet in a particular LSR is the LSR which is the next hop, as selected by the NHLFE entry used for forwarding that packet.
特定LSR中特定标记分组的LSP下一跳是作为下一跳的LSR，由用于转发该分组的NHLFE条目选择。
The LSP Next Hop for a particular FEC is the next hop as selected by the NHLFE entry indexed by a label which corresponds to that FEC.
特定FEC的LSP下一跳是由NHLFE条目选择的下一跳，该条目由对应于该FEC的标签索引。
Note that the LSP Next Hop may differ from the next hop which would be chosen by the network layer routing algorithm. We will use the term "L3 next hop" when we refer to the latter.
注意，LSP下一跳可能不同于网络层路由算法选择的下一跳。当我们提到后者时，我们将使用术语“L3下一跳”。
What should an LSR do if it receives a labeled packet with a particular incoming label, but has no binding for that label? It is tempting to think that the labels can just be removed, and the packet forwarded as an unlabeled IP packet. However, in some cases, doing so could cause a loop. If the upstream LSR thinks the label is bound to an explicit route, and the downstream LSR doesn't think the label is bound to anything, and if the hop by hop routing of the unlabeled IP packet brings the packet back to the upstream LSR, then a loop is formed.
如果LSR接收到带有特定传入标签的标记数据包，但没有该标签的绑定，该怎么办？人们很容易认为标签可以被移除，而数据包可以作为未标记的IP数据包转发。但是，在某些情况下，这样做可能会导致循环。如果上游LSR认为标签绑定到显式路由，而下游LSR不认为标签绑定到任何东西，并且如果未标记IP数据包的逐跳路由将数据包带回上游LSR，则形成循环。
It is also possible that the label was intended to represent a route which cannot be inferred from the IP header.
也可能该标签旨在表示无法从IP报头推断的路由。
Therefore, when a labeled packet is received with an invalid incoming label, it MUST be discarded, UNLESS it is determined by some means (not within the scope of the current document) that forwarding it unlabeled cannot cause any harm.
因此，当接收到带有无效传入标签的标记数据包时，必须将其丢弃，除非通过某种方式（不在当前文档的范围内）确定未标记的转发不会造成任何伤害。
Some FECs correspond to address prefixes which are distributed via a dynamic routing algorithm. The setup of the LSPs for these FECs can be done in one of two ways: Independent LSP Control or Ordered LSP Control.
一些FEC对应于通过动态路由算法分发的地址前缀。这些FEC的LSP设置可以通过两种方式之一完成：独立LSP控制或有序LSP控制。
In Independent LSP Control, each LSR, upon noting that it recognizes a particular FEC, makes an independent decision to bind a label to that FEC and to distribute that binding to its label distribution peers. This corresponds to the way that conventional IP datagram routing works; each node makes an independent decision as to how to treat each packet, and relies on the routing algorithm to converge rapidly so as to ensure that each datagram is correctly delivered.
在独立LSP控制中，每个LSR在注意到其识别特定FEC后，做出将标签绑定到该FEC并将该绑定分发到其标签分发对等方的独立决定。这与传统IP数据报路由的工作方式相对应；每个节点对如何处理每个数据包做出独立的决策，并依靠路由算法快速收敛，以确保每个数据报都正确传递。
In Ordered LSP Control, an LSR only binds a label to a particular FEC if it is the egress LSR for that FEC, or if it has already received a label binding for that FEC from its next hop for that FEC.
在有序LSP控制中，如果LSR是特定FEC的出口LSR，或者LSR已经从该FEC的下一跳接收到该FEC的标签绑定，则LSR仅将标签绑定到该FEC。
If one wants to ensure that traffic in a particular FEC follows a path with some specified set of properties (e.g., that the traffic does not traverse any node twice, that a specified amount of resources are available to the traffic, that the traffic follows an explicitly specified path, etc.) ordered control must be used. With independent control, some LSRs may begin label switching a traffic in the FEC before the LSP is completely set up, and thus some traffic in the FEC may follow a path which does not have the specified set of properties. Ordered control also needs to be used if the recognition of the FEC is a consequence of the setting up of the corresponding LSP.
如果希望确保特定FEC中的流量遵循具有某些指定属性集的路径（例如，流量不会两次穿过任何节点，流量可以使用指定数量的资源，流量遵循明确指定的路径等），则必须使用有序控制。通过独立控制，一些lsr可以在LSP完全设置之前开始标记交换FEC中的业务，因此FEC中的一些业务可以沿着不具有指定属性集的路径。如果FEC的识别是建立相应LSP的结果，则也需要使用有序控制。
Ordered LSP setup may be initiated either by the ingress or the egress.
有序LSP设置可由入口或出口启动。
Ordered control and independent control are fully interoperable. However, unless all LSRs in an LSP are using ordered control, the overall effect on network behavior is largely that of independent control, since one cannot be sure that an LSP is not used until it is fully set up.
有序控制和独立控制完全可互操作。然而，除非LSP中的所有LSR都使用有序控制，否则对网络行为的总体影响很大程度上是独立控制的影响，因为人们无法确定LSP在完全设置之前不会使用。
This architecture allows the choice between independent control and ordered control to be a local matter. Since the two methods interwork, a given LSR need support only one or the other. Generally speaking, the choice of independent versus ordered control does not appear to have any effect on the label distribution mechanisms which need to be defined.
这种体系结构允许在独立控制和有序控制之间进行选择，这是一个局部问题。由于这两种方法相互作用，给定的LSR只需要支持其中一种。一般来说，独立控制与有序控制的选择似乎对需要定义的标签分发机制没有任何影响。
One way of partitioning traffic into FECs is to create a separate FEC for each address prefix which appears in the routing table. However, within a particular MPLS domain, this may result in a set of FECs such that all traffic in all those FECs follows the same route. For example, a set of distinct address prefixes might all have the same egress node, and label swapping might be used only to get the the traffic to the egress node. In this case, within the MPLS domain, the union of those FECs is itself a FEC. This creates a choice: should a distinct label be bound to each component FEC, or should a single label be bound to the union, and that label applied to all traffic in the union?
将流量划分为FEC的一种方法是为路由表中出现的每个地址前缀创建单独的FEC。然而，在特定MPLS域内，这可能导致一组fec，使得所有这些fec中的所有业务遵循相同的路由。例如，一组不同的地址前缀可能都具有相同的出口节点，并且标签交换可能仅用于获取到出口节点的流量。在这种情况下，在MPLS域中，这些FEC的联合本身就是FEC。这就产生了一个选择：是将一个不同的标签绑定到每个组件FEC，还是将一个标签绑定到联合，并且该标签应用到联合中的所有通信？
The procedure of binding a single label to a union of FECs which is itself a FEC (within some domain), and of applying that label to all
将单个标签绑定到自身为FEC（在某个域内）的FEC联合上，并将该标签应用于所有FEC的过程
traffic in the union, is known as "aggregation". The MPLS architecture allows aggregation. Aggregation may reduce the number of labels which are needed to handle a particular set of packets, and may also reduce the amount of label distribution control traffic needed.
联合中的流量称为“聚合”。MPLS体系结构允许聚合。聚合可以减少处理特定分组集所需的标签数量，并且还可以减少所需的标签分发控制通信量。
Given a set of FECs which are "aggregatable" into a single FEC, it is possible to (a) aggregate them into a single FEC, (b) aggregate them into a set of FECs, or (c) not aggregate them at all. Thus we can speak of the "granularity" of aggregation, with (a) being the "coarsest granularity", and (c) being the "finest granularity".
给定一组可“聚合”为单个FEC的FEC，可以（a）将它们聚合为单个FEC，（b）将它们聚合为一组FEC，或（c）根本不聚合它们。因此，我们可以说聚合的“粒度”，其中（a）是“最粗粒度”，而（c）是“最细粒度”。
When order control is used, each LSR should adopt, for a given set of FECs, the granularity used by its next hop for those FECs.
当使用顺序控制时，对于给定的一组FEC，每个LSR应采用其下一跳用于这些FEC的粒度。
When independent control is used, it is possible that there will be two adjacent LSRs, Ru and Rd, which aggregate some set of FECs differently.
当使用独立控制时，可能会有两个相邻的LSR，Ru和Rd，它们以不同的方式聚合某些FEC集。
If Ru has finer granularity than Rd, this does not cause a problem. Ru distributes more labels for that set of FECs than Rd does. This means that when Ru needs to forward labeled packets in those FECs to Rd, it may need to map n labels into m labels, where n > m. As an option, Ru may withdraw the set of n labels that it has distributed, and then distribute a set of m labels, corresponding to Rd's level of granularity. This is not necessary to ensure correct operation, but it does result in a reduction of the number of labels distributed by Ru, and Ru is not gaining any particular advantage by distributing the larger number of labels. The decision whether to do this or not is a local matter.
如果Ru的粒度比Rd更细，则不会导致问题。Ru为该组FEC分发的标签比Rd多。这意味着，当Ru需要将这些FEC中的标记数据包转发到Rd时，它可能需要将n个标签映射到m个标签，其中n>m。作为一种选择，Ru可以提取其已分发的n个标签的集合，然后分发与Rd的粒度级别相对应的m个标签的集合。这对于确保正确的操作不是必需的，但是它确实减少了Ru分发的标签数量，并且Ru没有通过分发更多的标签而获得任何特定的优势。是否这样做的决定是当地的事情。
If Ru has coarser granularity than Rd (i.e., Rd has distributed n labels for the set of FECs, while Ru has distributed m, where n > m), it has two choices:
如果Ru的粒度比Rd粗（即，Rd为FEC集分配了n个标签，而Ru分配了m，其中n>m），则它有两个选择：
- It may adopt Rd's finer level of granularity. This would require it to withdraw the m labels it has distributed, and distribute n labels. This is the preferred option.
- 它可以采用Rd更精细的粒度级别。这将要求它收回已分发的m个标签，然后分发n个标签。这是首选方案。
- It may simply map its m labels into a subset of Rd's n labels, if it can determine that this will produce the same routing. For example, suppose that Ru applies a single label to all traffic that needs to pass through a certain egress LSR, whereas Rd binds a number of different labels to such traffic, depending on the individual destination addresses of the packets. If Ru knows the address of the egress router, and if Rd has bound a label to the FEC which is identified by that address, then Ru can simply apply that label.
- 它可以简单地将其m个标签映射到Rd的n个标签的子集，前提是它可以确定这将产生相同的路由。例如，假设Ru将单个标签应用于需要通过某个出口LSR的所有流量，而Rd根据分组的各个目的地地址将多个不同的标签绑定到此类流量。如果Ru知道出口路由器的地址，并且如果Rd已经将标签绑定到由该地址标识的FEC，则Ru可以简单地应用该标签。
In any event, every LSR needs to know (by configuration) what granularity to use for labels that it assigns. Where ordered control is used, this requires each node to know the granularity only for FECs which leave the MPLS network at that node. For independent control, best results may be obtained by ensuring that all LSRs are consistently configured to know the granularity for each FEC. However, in many cases this may be done by using a single level of granularity which applies to all FECs (such as "one label per IP prefix in the forwarding table", or "one label per egress node").
在任何情况下，每个LSR都需要知道（通过配置）它分配的标签的粒度。在使用有序控制的情况下，这要求每个节点仅知道离开该节点MPLS网络的FEC的粒度。对于独立控制，可通过确保所有LSR一致地配置为知道每个FEC的粒度来获得最佳结果。然而，在许多情况下，这可以通过使用适用于所有fec的单一粒度级别（例如“转发表中每个IP前缀一个标签”或“每个出口节点一个标签”）来实现。
Route selection refers to the method used for selecting the LSP for a particular FEC. The proposed MPLS protocol architecture supports two options for Route Selection: (1) hop by hop routing, and (2) explicit routing.
路由选择是指用于为特定FEC选择LSP的方法。所提出的MPLS协议架构支持两种路由选择选项：（1）逐跳路由和（2）显式路由。
Hop by hop routing allows each node to independently choose the next hop for each FEC. This is the usual mode today in existing IP networks. A "hop by hop routed LSP" is an LSP whose route is selected using hop by hop routing.
逐跳路由允许每个节点为每个FEC独立选择下一跳。这是现有IP网络中的常见模式。“逐跳路由LSP”是使用逐跳路由选择其路由的LSP。
In an explicitly routed LSP, each LSR does not independently choose the next hop; rather, a single LSR, generally the LSP ingress or the LSP egress, specifies several (or all) of the LSRs in the LSP. If a single LSR specifies the entire LSP, the LSP is "strictly" explicitly routed. If a single LSR specifies only some of the LSP, the LSP is "loosely" explicitly routed.
在显式路由LSP中，每个LSR不独立地选择下一跳；相反，单个LSR（通常为LSP入口或LSP出口）指定LSP中的若干（或全部）LSR。如果单个LSR指定整个LSP，则LSP将“严格”显式路由。如果单个LSR仅指定部分LSP，则LSP将“松散地”显式路由。
The sequence of LSRs followed by an explicitly routed LSP may be chosen by configuration, or may be selected dynamically by a single node (for example, the egress node may make use of the topological information learned from a link state database in order to compute the entire path for the tree ending at that egress node).
紧接着显式路由LSP的lsr序列可以通过配置来选择，或者可以由单个节点动态选择（例如，出口节点可以利用从链路状态数据库学习的拓扑信息，以便计算在该出口节点处结束的树的整个路径）。
Explicit routing may be useful for a number of purposes, such as policy routing or traffic engineering. In MPLS, the explicit route needs to be specified at the time that labels are assigned, but the explicit route does not have to be specified with each IP packet. This makes MPLS explicit routing much more efficient than the alternative of IP source routing.
显式路由可能有很多用途，例如策略路由或流量工程。在MPLS中，需要在分配标签时指定显式路由，但不必在每个IP数据包中指定显式路由。这使得MPLS显式路由比IP源路由更有效。
The procedures for making use of explicit routes, either strict or loose, are beyond the scope of this document.
使用明确路线的程序，无论是严格的还是宽松的，都超出了本文件的范围。
When a labeled packet is traveling along an LSP, it may occasionally happen that it reaches an LSR at which the ILM does not map the packet's incoming label into an NHLFE, even though the incoming label is itself valid. This can happen due to transient conditions, or due to an error at the LSR which should be the packet's next hop.
当标记的数据包沿着LSP移动时，有时可能会出现这样的情况：它到达一个LSR，在该LSR处ILM不会将数据包的传入标签映射到NHLFE，即使传入标签本身是有效的。这可能是由于瞬态条件造成的，或者是由于LSR处的错误造成的，LSR应该是数据包的下一跳。
It is tempting in such cases to strip off the label stack and attempt to forward the packet further via conventional forwarding, based on its network layer header. However, in general this is not a safe procedure:
在这种情况下，很容易剥离标签堆栈，并根据其网络层报头，尝试通过传统转发进一步转发数据包。但是，一般来说，这不是一个安全的程序：
- If the packet has been following an explicitly routed LSP, this could result in a loop.
- 如果数据包一直遵循显式路由LSP，这可能会导致循环。
- The packet's network header may not contain enough information to enable this particular LSR to forward it correctly.
- 数据包的网络报头可能没有包含足够的信息，无法使此特定LSR正确转发数据包。
Unless it can be determined (through some means outside the scope of this document) that neither of these situations obtains, the only safe procedure is to discard the packet.
除非可以确定（通过本文件范围外的某些方法）这两种情况都不存在，否则唯一安全的程序是丢弃数据包。
In conventional IP forwarding, each packet carries a "Time To Live" (TTL) value in its header. Whenever a packet passes through a router, its TTL gets decremented by 1; if the TTL reaches 0 before the packet has reached its destination, the packet gets discarded.
在传统的IP转发中，每个数据包在其报头中携带一个“生存时间”（TTL）值。每当一个包通过路由器，它的TTL就会减少1；如果TTL在数据包到达目的地之前达到0，则数据包将被丢弃。
This provides some level of protection against forwarding loops that may exist due to misconfigurations, or due to failure or slow convergence of the routing algorithm. TTL is sometimes used for other functions as well, such as multicast scoping, and supporting the "traceroute" command. This implies that there are two TTL-related issues that MPLS needs to deal with: (i) TTL as a way to suppress loops; (ii) TTL as a way to accomplish other functions, such as limiting the scope of a packet.
这提供了一定程度的保护，防止由于错误配置、路由算法的故障或缓慢收敛而存在的转发循环。TTL有时也用于其他功能，如多播作用域和支持“traceroute”命令。这意味着MPLS需要处理两个与TTL相关的问题：（i）TTL作为抑制循环的一种方式；（ii）TTL作为完成其他功能的一种方式，例如限制数据包的范围。
When a packet travels along an LSP, it SHOULD emerge with the same TTL value that it would have had if it had traversed the same sequence of routers without having been label switched. If the packet travels along a hierarchy of LSPs, the total number of LSR-hops traversed SHOULD be reflected in its TTL value when it emerges from the hierarchy of LSPs.
当一个数据包沿着LSP传输时，它应该以相同的TTL值出现，如果它在没有标签交换的情况下穿越相同的路由器序列，它应该具有相同的TTL值。如果数据包沿着LSP的层次结构移动，那么当它从LSP的层次结构中出现时，经过的LSR跳总数应该反映在其TTL值中。
The way that TTL is handled may vary depending upon whether the MPLS label values are carried in an MPLS-specific "shim" header [MPLS-SHIM], or if the MPLS labels are carried in an L2 header, such as an ATM header [MPLS-ATM] or a frame relay header [MPLS-FRMRLY].
TTL的处理方式可能会有所不同，这取决于MPLS标签值是在MPLS特定的“垫片”报头[MPLS-shim]中携带，还是MPLS标签是在L2报头中携带，例如ATM报头[MPLS-ATM]或帧中继报头[MPLS-FRMRLY]。
If the label values are encoded in a "shim" that sits between the data link and network layer headers, then this shim MUST have a TTL field that SHOULD be initially loaded from the network layer header TTL field, SHOULD be decremented at each LSR-hop, and SHOULD be copied into the network layer header TTL field when the packet emerges from its LSP.
如果标签值编码在位于数据链路和网络层标头之间的“垫片”中，则该垫片必须具有一个TTL字段，该字段最初应从网络层标头加载TTL字段，并应在每个LSR跃点处递减，当数据包从其LSP中出现时，应将其复制到网络层报头TTL字段中。
If the label values are encoded in a data link layer header (e.g., the VPI/VCI field in ATM's AAL5 header), and the labeled packets are forwarded by an L2 switch (e.g., an ATM switch), and the data link layer (like ATM) does not itself have a TTL field, then it will not be possible to decrement a packet's TTL at each LSR-hop. An LSP segment which consists of a sequence of LSRs that cannot decrement a packet's TTL will be called a "non-TTL LSP segment".
如果标签值编码在数据链路层报头（例如，ATM的AAL5报头中的VPI/VCI字段）中，并且标签分组由L2交换机（例如，ATM交换机）转发，并且数据链路层（例如ATM）本身没有TTL字段，则不可能在每个LSR跳上减少分组的TTL。由不能减少数据包TTL的LSR序列组成的LSP段称为“非TTL LSP段”。
When a packet emerges from a non-TTL LSP segment, it SHOULD however be given a TTL that reflects the number of LSR-hops it traversed. In the unicast case, this can be achieved by propagating a meaningful LSP length to ingress nodes, enabling the ingress to decrement the TTL value before forwarding packets into a non-TTL LSP segment.
当一个包从一个非TTL LSP段出现时，应该给它一个TTL，该TTL反映了它经过的LSR跳数。在单播情况下，这可以通过向入口节点传播有意义的LSP长度来实现，使得入口能够在将分组转发到非TTL LSP段之前减小TTL值。
Sometimes it can be determined, upon ingress to a non-TTL LSP segment, that a particular packet's TTL will expire before the packet reaches the egress of that non-TTL LSP segment. In this case, the LSR at the ingress to the non-TTL LSP segment must not label switch the packet. This means that special procedures must be developed to support traceroute functionality, for example, traceroute packets may be forwarded using conventional hop by hop forwarding.
有时，在进入非TTL LSP段时，可以确定特定分组的TTL将在分组到达该非TTL LSP段的出口之前过期。在这种情况下，非TTL LSP段入口的LSR不得标记交换数据包。这意味着必须开发特殊程序来支持跟踪路由功能，例如，跟踪路由数据包可以使用传统的逐跳转发进行转发。
On a non-TTL LSP segment, by definition, TTL cannot be used to protect against forwarding loops. The importance of loop control may depend on the particular hardware being used to provide the LSR functions along the non-TTL LSP segment.
根据定义，在非TTL LSP段上，TTL不能用于防止转发循环。环路控制的重要性可能取决于用于沿非TTL LSP段提供LSR功能的特定硬件。
Suppose, for instance, that ATM switching hardware is being used to provide MPLS switching functions, with the label being carried in the VPI/VCI field. Since ATM switching hardware cannot decrement TTL, there is no protection against loops. If the ATM hardware is capable of providing fair access to the buffer pool for incoming cells carrying different VPI/VCI values, this looping may not have any deleterious effect on other traffic. If the ATM hardware cannot
例如，假设ATM交换硬件用于提供MPLS交换功能，标签位于VPI/VCI字段中。由于ATM交换硬件不能减少TTL，因此没有环路保护。如果ATM硬件能够为携带不同VPI/VCI值的传入信元提供对缓冲池的公平访问，则该循环可能不会对其他流量产生任何有害影响。如果ATM硬件不能
provide fair buffer access of this sort, however, then even transient loops may cause severe degradation of the LSR's total performance.
然而，提供这种类型的公平缓冲区访问，即使是瞬态循环也可能导致LSR的总体性能严重下降。
Even if fair buffer access can be provided, it is still worthwhile to have some means of detecting loops that last "longer than possible". In addition, even where TTL and/or per-VC fair queuing provides a means for surviving loops, it still may be desirable where practical to avoid setting up LSPs which loop. All LSRs that may attach to non-TTL LSP segments will therefore be required to support a common technique for loop detection; however, use of the loop detection technique is optional. The loop detection technique is specified in [MPLS-ATM] and [MPLS-LDP].
即使可以提供公平的缓冲区访问，仍然值得使用一些方法来检测持续时间“超过可能时间”的循环。此外，即使TTL和/或per VC公平队列提供了一种幸存循环的方法，在实际情况下，也可能需要避免设置LSP，从而避免循环。因此，所有可能连接到非TTL LSP段的LSR都需要支持环路检测的通用技术；然而，循环检测技术的使用是可选的。环路检测技术在[MPLS-ATM]和[MPLS-LDP]中有规定。
In order to transmit a label stack along with the packet whose label stack it is, it is necessary to define a concrete encoding of the label stack. The architecture supports several different encoding techniques; the choice of encoding technique depends on the particular kind of device being used to forward labeled packets.
为了将标签堆栈与标签堆栈所在的数据包一起传输，必须定义标签堆栈的具体编码。该体系结构支持多种不同的编码技术；编码技术的选择取决于用于转发标记数据包的特定类型的设备。
If one is using MPLS-specific hardware and/or software to forward labeled packets, the most obvious way to encode the label stack is to define a new protocol to be used as a "shim" between the data link layer and network layer headers. This shim would really be just an encapsulation of the network layer packet; it would be "protocol-independent" such that it could be used to encapsulate any network layer. Hence we will refer to it as the "generic MPLS encapsulation".
如果使用MPLS特定的硬件和/或软件转发标记的数据包，则对标签堆栈进行编码的最明显方式是定义一个新协议，用作数据链路层和网络层头之间的“垫片”。这个垫片实际上只是网络层数据包的封装；它将是“独立于协议”的，因此可以用来封装任何网络层。因此，我们将其称为“通用MPLS封装”。
The generic MPLS encapsulation would in turn be encapsulated in a data link layer protocol.
通用MPLS封装将依次封装在数据链路层协议中。
The MPLS generic encapsulation is specified in [MPLS-SHIM].
MPLS通用封装在[MPLS-SHIM]中指定。
It will be noted that MPLS forwarding procedures are similar to those of legacy "label swapping" switches such as ATM switches. ATM switches use the input port and the incoming VPI/VCI value as the index into a "cross-connect" table, from which they obtain an output port and an outgoing VPI/VCI value. Therefore if one or more labels can be encoded directly into the fields which are accessed by these legacy switches, then the legacy switches can, with suitable software upgrades, be used as LSRs. We will refer to such devices as "ATM-LSRs".
需要注意的是，MPLS转发过程类似于传统的“标签交换”交换机，如ATM交换机。ATM交换机使用输入端口和传入VPI/VCI值作为“交叉连接”表的索引，从中获得输出端口和传出VPI/VCI值。因此，如果可以将一个或多个标签直接编码到这些传统交换机访问的字段中，那么通过适当的软件升级，传统交换机可以用作LSR。我们将这些设备称为“ATM LSR”。
There are three obvious ways to encode labels in the ATM cell header (presuming the use of AAL5):
ATM信元报头中有三种明显的标签编码方式（假定使用AAL5）：
1. SVC Encoding
1. SVC编码
Use the VPI/VCI field to encode the label which is at the top of the label stack. This technique can be used in any network. With this encoding technique, each LSP is realized as an ATM SVC, and the label distribution protocol becomes the ATM "signaling" protocol. With this encoding technique, the ATM-LSRs cannot perform "push" or "pop" operations on the label stack.
使用VPI/VCI字段对标签堆栈顶部的标签进行编码。这种技术可以用于任何网络。通过这种编码技术，每个LSP被实现为一个ATM SVC，标签分发协议成为ATM“信令”协议。使用这种编码技术，ATM LSR无法在标签堆栈上执行“推送”或“弹出”操作。
2. SVP Encoding
2. SVP编码
Use the VPI field to encode the label which is at the top of the label stack, and the VCI field to encode the second label on the stack, if one is present. This technique some advantages over the previous one, in that it permits the use of ATM "VP-switching". That is, the LSPs are realized as ATM SVPs, with the label distribution protocol serving as the ATM signaling protocol.
使用VPI字段对标签堆栈顶部的标签进行编码，使用VCI字段对堆栈上的第二个标签（如果存在）进行编码。与前一种技术相比，这种技术有一些优点，因为它允许使用ATM“VP交换”。也就是说，LSP实现为ATM SVP，标签分发协议作为ATM信令协议。
However, this technique cannot always be used. If the network includes an ATM Virtual Path through a non-MPLS ATM network, then the VPI field is not necessarily available for use by MPLS.
然而，这种技术并不总是被使用。如果网络包括通过非MPLS ATM网络的ATM虚拟路径，则VPI字段不一定可供MPLS使用。
When this encoding technique is used, the ATM-LSR at the egress of the VP effectively does a "pop" operation.
当使用这种编码技术时，VP出口处的ATM-LSR有效地执行“pop”操作。
3. SVP Multipoint Encoding
3. SVP多点编码
Use the VPI field to encode the label which is at the top of the label stack, use part of the VCI field to encode the second label on the stack, if one is present, and use the remainder of the VCI field to identify the LSP ingress. If this technique is used, conventional ATM VP-switching capabilities can be used to provide multipoint-to-point VPs. Cells from different packets will then carry different VCI values. As we shall see in section 3.26, this enables us to do label merging, without running into any cell interleaving problems, on ATM switches which can provide multipoint-to-point VPs, but which do not have the VC merge capability.
使用VPI字段对标签堆栈顶部的标签进行编码，使用VCI字段的一部分对堆栈上的第二个标签（如果存在）进行编码，并使用VCI字段的其余部分识别LSP入口。如果使用这种技术，可以使用传统的ATM VP交换能力来提供多点对点VP。来自不同数据包的单元格将携带不同的VCI值。正如我们将在第3.26节中看到的，这使我们能够在ATM交换机上进行标签合并，而不会遇到任何信元交织问题，ATM交换机可以提供多点对点VP，但不具备VC合并功能。
This technique depends on the existence of a capability for assigning 16-bit VCI values to each ATM switch such that no single VCI value is assigned to two different switches. (If an
这项技术取决于是否存在为每个ATM交换机分配16位VCI值的能力，从而不会将单个VCI值分配给两个不同的交换机。（如属
adequate number of such values could be assigned to each switch, it would be possible to also treat the VCI value as the second label in the stack.)
可以为每个开关分配足够数量的此类值，也可以将VCI值视为堆栈中的第二个标签。）
If there are more labels on the stack than can be encoded in the ATM header, the ATM encodings must be combined with the generic encapsulation.
如果堆栈上的标签多于ATM报头中可以编码的标签，则必须将ATM编码与通用封装结合起来。
If <R1, R2, R3> is a segment of a LSP, it is possible that R1 will use one encoding of the label stack when transmitting packet P to R2, but R2 will use a different encoding when transmitting a packet P to R3. In general, the MPLS architecture supports LSPs with different label stack encodings used on different hops. Therefore, when we discuss the procedures for processing a labeled packet, we speak in abstract terms of operating on the packet's label stack. When a labeled packet is received, the LSR must decode it to determine the current value of the label stack, then must operate on the label stack to determine the new value of the stack, and then encode the new value appropriately before transmitting the labeled packet to its next hop.
如果<R1，R2，R3>是LSP的一段，则在将分组P发送到R2时，R1可能将使用标签堆栈的一种编码，但在将分组P发送到R3时，R2将使用不同的编码。通常，MPLS体系结构支持在不同跳上使用不同标签堆栈编码的LSP。因此，当我们讨论处理标记数据包的过程时，我们用抽象的术语来描述对数据包的标签堆栈的操作。当接收到带标签的数据包时，LSR必须对其进行解码以确定标签堆栈的当前值，然后必须对标签堆栈进行操作以确定堆栈的新值，然后在将带标签的数据包传输到其下一跳之前对新值进行适当编码。
Unfortunately, ATM switches have no capability for translating from one encoding technique to another. The MPLS architecture therefore requires that whenever it is possible for two ATM switches to be successive LSRs along a level m LSP for some packet, that those two ATM switches use the same encoding technique.
不幸的是，ATM交换机没有从一种编码技术转换到另一种编码技术的能力。因此，MPLS体系结构要求，每当两个ATM交换机可能是某个数据包的m级LSP上的连续LSR时，这两个ATM交换机使用相同的编码技术。
Naturally there will be MPLS networks which contain a combination of ATM switches operating as LSRs, and other LSRs which operate using an MPLS shim header. In such networks there may be some LSRs which have ATM interfaces as well as "MPLS Shim" interfaces. This is one example of an LSR with different label stack encodings on different hops. Such an LSR may swap off an ATM encoded label stack on an incoming interface and replace it with an MPLS shim header encoded label stack on the outgoing interface.
自然会有MPLS网络，其中包含作为LSR运行的ATM交换机的组合，以及使用MPLS shim报头运行的其他LSR。在这种网络中，可能存在一些具有ATM接口以及“MPLS垫片”接口的LSR。这是在不同跳上使用不同标签堆栈编码的LSR的一个示例。这样的LSR可以交换传入接口上的ATM编码标签堆栈，并用传出接口上的MPLS垫片头编码标签堆栈替换它。
Suppose that an LSR has bound multiple incoming labels to a particular FEC. When forwarding packets in that FEC, one would like to have a single outgoing label which is applied to all such packets. The fact that two different packets in the FEC arrived with different incoming labels is irrelevant; one would like to forward them with the same outgoing label. The capability to do so is known as "label merging".
假设LSR已将多个传入标签绑定到特定FEC。在该FEC中转发数据包时，希望有一个应用于所有此类数据包的单个传出标签。FEC中的两个不同分组以不同的传入标签到达这一事实是无关的；我们希望使用相同的传出标签转发它们。这样做的能力称为“标签合并”。
Let us say that an LSR is capable of label merging if it can receive two packets from different incoming interfaces, and/or with different labels, and send both packets out the same outgoing interface with the same label. Once the packets are transmitted, the information that they arrived from different interfaces and/or with different incoming labels is lost.
假设LSR能够接收来自不同传入接口和/或具有不同标签的两个数据包，并使用相同标签将两个数据包发送出相同的传出接口，则LSR能够进行标签合并。一旦数据包被传输，来自不同接口和/或具有不同传入标签的数据包到达的信息就会丢失。
Let us say that an LSR is not capable of label merging if, for any two packets which arrive from different interfaces, or with different labels, the packets must either be transmitted out different interfaces, or must have different labels. ATM-LSRs using the SVC or SVP Encodings cannot perform label merging. This is discussed in more detail in the next section.
假设LSR不能进行标签合并，如果对于来自不同接口或具有不同标签的任何两个数据包，这些数据包必须从不同接口传输出去，或者必须具有不同的标签。使用SVC或SVP编码的ATM LSR无法执行标签合并。下一节将对此进行更详细的讨论。
If a particular LSR cannot perform label merging, then if two packets in the same FEC arrive with different incoming labels, they must be forwarded with different outgoing labels. With label merging, the number of outgoing labels per FEC need only be 1; without label merging, the number of outgoing labels per FEC could be as large as the number of nodes in the network.
如果特定LSR无法执行标签合并，那么如果同一FEC中的两个数据包到达时带有不同的传入标签，则必须使用不同的传出标签转发它们。通过标签合并，每个FEC的传出标签数只需为1；如果没有标签合并，每个FEC的传出标签数量可能与网络中的节点数量一样多。
With label merging, the number of incoming labels per FEC that a particular LSR needs is never be larger than the number of label distribution adjacencies. Without label merging, the number of incoming labels per FEC that a particular LSR needs is as large as the number of upstream nodes which forward traffic in the FEC to the LSR in question. In fact, it is difficult for an LSR to even determine how many such incoming labels it must support for a particular FEC.
通过标签合并，特定LSR需要的每个FEC的传入标签数永远不会大于标签分布邻接数。在没有标签合并的情况下，特定LSR需要的每个FEC的传入标签的数量与将FEC中的业务转发到所讨论的LSR的上游节点的数量一样大。事实上，LSR甚至很难确定一个特定FEC必须支持多少这样的传入标签。
The MPLS architecture accommodates both merging and non-merging LSRs, but allows for the fact that there may be LSRs which do not support label merging. This leads to the issue of ensuring correct interoperation between merging LSRs and non-merging LSRs. The issue is somewhat different in the case of datagram media versus the case of ATM. The different media types will therefore be discussed separately.
MPLS体系结构同时支持合并和非合并LSR，但允许存在不支持标签合并的LSR。这导致了确保合并LSR和非合并LSR之间正确互操作的问题。数据报媒体与ATM的问题有所不同。因此，将分别讨论不同的媒体类型。
The MPLS forwarding procedures is very similar to the forwarding procedures used by such technologies as ATM and Frame Relay. That is, a unit of data arrives, a label (VPI/VCI or DLCI) is looked up in a "cross-connect table", on the basis of that lookup an output port is chosen, and the label value is rewritten. In fact, it is possible to use such technologies for MPLS forwarding; a label distribution protocol can be used as the "signalling protocol" for setting up the cross-connect tables.
MPLS转发过程与ATM和帧中继等技术使用的转发过程非常相似。也就是说，一个数据单元到达后，在“交叉连接表”中查找标签（VPI/VCI或DLCI），在此基础上选择输出端口，并重写标签值。事实上，可以将这些技术用于MPLS转发；标签分发协议可用作设置交叉连接表的“信令协议”。
Unfortunately, these technologies do not necessarily support the label merging capability. In ATM, if one attempts to perform label merging, the result may be the interleaving of cells from various packets. If cells from different packets get interleaved, it is impossible to reassemble the packets. Some Frame Relay switches use cell switching on their backplanes. These switches may also be incapable of supporting label merging, for the same reason -- cells of different packets may get interleaved, and there is then no way to reassemble the packets.
不幸的是，这些技术不一定支持标签合并功能。在ATM中，如果试图执行标签合并，结果可能是来自各种数据包的信元交织。如果来自不同数据包的单元被交织，就不可能重新组装数据包。一些帧中继交换机在其背板上使用单元开关。出于同样的原因，这些交换机也可能无法支持标签合并——不同数据包的单元可能会交错，因此无法重新组装数据包。
We propose to support two solutions to this problem. First, MPLS will contain procedures which allow the use of non-merging LSRs. Second, MPLS will support procedures which allow certain ATM switches to function as merging LSRs.
我们建议支持这一问题的两种解决方案。首先，MPLS将包含允许使用非合并LSR的过程。其次，MPLS将支持允许某些ATM交换机充当合并LSR的过程。
Since MPLS supports both merging and non-merging LSRs, MPLS also contains procedures to ensure correct interoperation between them.
由于MPLS支持合并和非合并LSR，因此MPLS还包含确保它们之间正确互操作的过程。
An upstream LSR which supports label merging needs to be sent only one label per FEC. An upstream neighbor which does not support label merging needs to be sent multiple labels per FEC. However, there is no way of knowing a priori how many labels it needs. This will depend on how many LSRs are upstream of it with respect to the FEC in question.
支持标签合并的上游LSR每个FEC只需要发送一个标签。不支持标签合并的上游邻居需要为每个FEC发送多个标签。然而，无法事先知道它需要多少标签。这将取决于相对于所述FEC在其上游有多少LSR。
In the MPLS architecture, if a particular upstream neighbor does not support label merging, it is not sent any labels for a particular FEC unless it explicitly asks for a label for that FEC. The upstream neighbor may make multiple such requests, and is given a new label each time. When a downstream neighbor receives such a request from upstream, and the downstream neighbor does not itself support label merging, then it must in turn ask its downstream neighbor for another label for the FEC in question.
在MPLS体系结构中，如果特定上游邻居不支持标签合并，则不会为特定FEC发送任何标签，除非它明确要求为该FEC提供标签。上游邻居可以发出多个这样的请求，并且每次都被赋予一个新的标签。当下游邻居从上游接收到这样的请求时，并且下游邻居本身不支持标签合并，那么它必须反过来向其下游邻居请求所讨论的FEC的另一个标签。
It is possible that there may be some nodes which support label merging, but can only merge a limited number of incoming labels into a single outgoing label. Suppose for example that due to some hardware limitation a node is capable of merging four incoming labels into a single outgoing label. Suppose however, that this particular node has six incoming labels arriving at it for a particular FEC. In this case, this node may merge these into two outgoing labels.
可能有一些节点支持标签合并，但只能将有限数量的传入标签合并到单个传出标签中。例如，假设由于某些硬件限制，节点能够将四个传入标签合并为一个传出标签。但是，假设这个特定节点有六个到达它的特定FEC的传入标签。在这种情况下，此节点可以将这些标签合并为两个传出标签。
Whether label merging is applicable to explicitly routed LSPs is for further study.
标签合并是否适用于显式路由LSP有待进一步研究。
There are several methods that can be used to eliminate the cell interleaving problem in ATM, thereby allowing ATM switches to support stream merge:
有几种方法可用于消除ATM中的信元交织问题，从而允许ATM交换机支持流合并：
1. VP merge, using the SVP Multipoint Encoding
1. VP合并，使用SVP多点编码
When VP merge is used, multiple virtual paths are merged into a virtual path, but packets from different sources are distinguished by using different VCIs within the VP.
当使用VP merge时，多个虚拟路径合并到一个虚拟路径中，但是通过在VP中使用不同的VCI来区分来自不同来源的数据包。
2. VC merge
2. VC合并
When VC merge is used, switches are required to buffer cells from one packet until the entire packet is received (this may be determined by looking for the AAL5 end of frame indicator).
当使用VC merge时，交换机需要缓冲来自一个数据包的单元，直到接收到整个数据包（这可以通过查找AAL5帧结束指示符来确定）。
VP merge has the advantage that it is compatible with a higher percentage of existing ATM switch implementations. This makes it more likely that VP merge can be used in existing networks. Unlike VC merge, VP merge does not incur any delays at the merge points and also does not impose any buffer requirements. However, it has the disadvantage that it requires coordination of the VCI space within each VP. There are a number of ways that this can be accomplished. Selection of one or more methods is for further study.
VP merge的优点是它与现有ATM交换机实现的较高百分比兼容。这使得VP合并更有可能在现有网络中使用。与VC merge不同，VP merge不会在合并点产生任何延迟，也不会强加任何缓冲区要求。然而，它的缺点是需要协调每个VP内的VCI空间。有许多方法可以实现这一点。一种或多种方法的选择有待进一步研究。
This tradeoff between compatibility with existing equipment versus protocol complexity and scalability implies that it is desirable for the MPLS protocol to support both VP merge and VC merge. In order to do so each ATM switch participating in MPLS needs to know whether its immediate ATM neighbors perform VP merge, VC merge, or no merge.
与现有设备的兼容性与协议复杂性和可伸缩性之间的这种折衷意味着MPLS协议需要同时支持VP合并和VC合并。为了做到这一点，参与MPLS的每个ATM交换机都需要知道其直接ATM邻居是执行VP合并、VC合并还是不执行合并。
The interoperation of the various forms of merging over ATM is most easily described by first describing the interoperation of VC merge with non-merge.
通过首先描述VC合并与非合并的互操作，最容易描述ATM上各种合并形式的互操作。
In the case where VC merge and non-merge nodes are interconnected the forwarding of cells is based in all cases on a VC (i.e., the concatenation of the VPI and VCI). For each node, if an upstream neighbor is doing VC merge then that upstream neighbor requires only a single VPI/VCI for a particular stream (this is analogous to the requirement for a single label in the case of operation over frame media). If the upstream neighbor is not doing merge, then the
在VC合并和非合并节点互连的情况下，小区的转发在所有情况下都基于VC（即VPI和VCI的串联）。对于每个节点，如果上游邻居正在进行VC合并，则该上游邻居对于特定流仅需要单个VPI/VCI（这类似于在帧媒体上操作的情况下对单个标签的要求）。如果上游邻居没有进行合并，则
neighbor will require a single VPI/VCI per stream for itself, plus enough VPI/VCIs to pass to its upstream neighbors. The number required will be determined by allowing the upstream nodes to request additional VPI/VCIs from their downstream neighbors (this is again analogous to the method used with frame merge).
邻居需要为其自身的每个流提供一个VPI/VCI，外加足够的VPI/VCI以传递给其上游邻居。所需数量将通过允许上游节点从其下游邻居请求额外的VPI/VCI来确定（这同样类似于帧合并使用的方法）。
A similar method is possible to support nodes which perform VP merge. In this case the VP merge node, rather than requesting a single VPI/VCI or a number of VPI/VCIs from its downstream neighbor, instead may request a single VP (identified by a VPI) but several VCIs within the VP. Furthermore, suppose that a non-merge node is downstream from two different VP merge nodes. This node may need to request one VPI/VCI (for traffic originating from itself) plus two VPs (one for each upstream node), each associated with a specified set of VCIs (as requested from the upstream node).
类似的方法也可以支持执行VP合并的节点。在这种情况下，VP合并节点不是从其下游邻居请求单个VPI/VCI或多个VPI/VCI，而是可以请求单个VP（由VPI标识），但VP内有多个VCI。此外，假设一个非合并节点位于两个不同VP合并节点的下游。该节点可能需要请求一个VPI/VCI（用于来自自身的流量）加上两个VP（每个上游节点一个），每个VP与一组指定的VCI（根据上游节点的请求）相关联。
In order to support all of VP merge, VC merge, and non-merge, it is therefore necessary to allow upstream nodes to request a combination of zero or more VC identifiers (consisting of a VPI/VCI), plus zero or more VPs (identified by VPIs) each containing a specified number of VCs (identified by a set of VCIs which are significant within a VP). VP merge nodes would therefore request one VP, with a contained VCI for traffic that it originates (if appropriate) plus a VCI for each VC requested from above (regardless of whether or not the VC is part of a containing VP). VC merge node would request only a single VPI/VCI (since they can merge all upstream traffic into a single VC). Non-merge nodes would pass on any requests that they get from above, plus request a VPI/VCI for traffic that they originate (if appropriate).
为了支持所有VP合并、VC合并和非合并，因此有必要允许上游节点请求零个或多个VC标识符（由VPI/VCI组成）加上零个或多个VP（由VPI标识）的组合，每个VP包含指定数量的VC（由VP中重要的一组VCI标识）。因此，VP合并节点将请求一个VP，其中包含一个针对其发起的流量的VCI（如果合适），以及一个针对从上面请求的每个VC的VCI（无论VC是否是包含VP的一部分）。VC合并节点将只请求单个VPI/VCI（因为它们可以将所有上游流量合并到单个VC中）。非合并节点将传递他们从上面得到的任何请求，并为他们发起的流量请求一个VPI/VCI（如果合适）。
Sometimes a router Ru takes explicit action to cause a particular packet to be delivered to another router Rd, even though Ru and Rd are not consecutive routers on the Hop-by-hop path for that packet, and Rd is not the packet's ultimate destination. For example, this may be done by encapsulating the packet inside a network layer packet whose destination address is the address of Rd itself. This creates a "tunnel" from Ru to Rd. We refer to any packet so handled as a "Tunneled Packet".
有时，路由器Ru采取显式动作以使特定分组被传送到另一路由器Rd，即使Ru和Rd不是该分组逐跳路径上的连续路由器，并且Rd不是该分组的最终目的地。例如，这可以通过将分组封装在目的地地址为Rd本身地址的网络层分组内来实现。这将创建一个从Ru到Rd的“隧道”。我们将任何这样处理的数据包称为“隧道数据包”。
If a Tunneled Packet follows the Hop-by-hop path from Ru to Rd, we say that it is in an "Hop-by-Hop Routed Tunnel" whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd.
如果一个隧道包沿着从Ru到Rd的逐跳路径，我们说它在一个“逐跳路由隧道”中，其“传输端点”是Ru，“接收端点”是Rd。
If a Tunneled Packet travels from Ru to Rd over a path other than the Hop-by-hop path, we say that it is in an "Explicitly Routed Tunnel" whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd. For example, we might send a packet through an Explicitly Routed Tunnel by encapsulating it in a packet which is source routed.
如果一个隧道数据包通过非逐跳路径的路径从Ru到Rd，我们说它位于“显式路由隧道”中，其“传输端点”为Ru，“接收端点”为Rd。例如，我们可以通过将数据包封装在源路由的数据包中，通过显式路由隧道发送数据包。
It is possible to implement a tunnel as a LSP, and use label switching rather than network layer encapsulation to cause the packet to travel through the tunnel. The tunnel would be a LSP <R1, ..., Rn>, where R1 is the transmit endpoint of the tunnel, and Rn is the receive endpoint of the tunnel. This is called a "LSP Tunnel".
可以将隧道实现为LSP，并使用标签交换而不是网络层封装来使分组通过隧道。隧道将是LSP<R1，…，Rn>，其中R1是隧道的发送端点，Rn是隧道的接收端点。这被称为“LSP隧道”。
The set of packets which are to be sent though the LSP tunnel constitutes a FEC, and each LSR in the tunnel must assign a label to that FEC (i.e., must assign a label to the tunnel). The criteria for assigning a particular packet to an LSP tunnel is a local matter at the tunnel's transmit endpoint. To put a packet into an LSP tunnel, the transmit endpoint pushes a label for the tunnel onto the label stack and sends the labeled packet to the next hop in the tunnel.
要通过LSP隧道发送的分组集构成FEC，隧道中的每个LSR必须为该FEC分配标签（即，必须为隧道分配标签）。将特定分组分配给LSP隧道的标准是隧道传输端点处的局部问题。要将数据包放入LSP隧道中，传输端点将隧道的标签推送到标签堆栈上，并将标签数据包发送到隧道中的下一跳。
If it is not necessary for the tunnel's receive endpoint to be able to determine which packets it receives through the tunnel, as discussed earlier, the label stack may be popped at the penultimate LSR in the tunnel.
如前所述，如果隧道的接收端点不必能够确定它通过隧道接收哪些分组，则标签堆栈可以在隧道中倒数第二个LSR处弹出。
A "Hop-by-Hop Routed LSP Tunnel" is a Tunnel that is implemented as an hop-by-hop routed LSP between the transmit endpoint and the receive endpoint.
“逐跳路由LSP隧道”是在发送端点和接收端点之间实现为逐跳路由LSP的隧道。
An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an Explicitly Routed LSP.
“显式路由LSP隧道”是也是显式路由LSP的LSP隧道。
Consider a LSP <R1, R2, R3, R4>. Let us suppose that R1 receives unlabeled packet P, and pushes on its label stack the label to cause it to follow this path, and that this is in fact the Hop-by-hop path. However, let us further suppose that R2 and R3 are not directly connected, but are "neighbors" by virtue of being the endpoints of an LSP tunnel. So the actual sequence of LSRs traversed by P is <R1, R2, R21, R22, R23, R3, R4>.
考虑一个LSP< R1，R2，R3，R4>。让我们假设R1接收到未标记的数据包P，并在其标签堆栈上推送标签以使其遵循此路径，而这实际上是逐跳路径。然而，让我们进一步假设R2和R3不是直接连接的，而是由于是LSP隧道的端点而成为“邻居”。因此P遍历的lsr的实际序列是<R1，R2，R21，R22，R23，R3，R4>。
When P travels from R1 to R2, it will have a label stack of depth 1. R2, switching on the label, determines that P must enter the tunnel. R2 first replaces the Incoming label with a label that is meaningful to R3. Then it pushes on a new label. This level 2 label has a value which is meaningful to R21. Switching is done on the level 2 label by R21, R22, R23. R23, which is the penultimate hop in the R2-R3 tunnel, pops the label stack before forwarding the packet to R3. When R3 sees packet P, P has only a level 1 label, having now exited the tunnel. Since R3 is the penultimate hop in P's level 1 LSP, it pops the label stack, and R4 receives P unlabeled.
当P从R1移动到R2时，它将有一个深度为1的标签堆栈。R2打开标签，确定P必须进入通道。R2首先用对R3有意义的标签替换传入标签。然后它推出了一个新标签。此级别2标签具有对R21有意义的值。通过R21、R22、R23在2级标签上进行切换。R23是R2-R3隧道中的倒数第二个跃点，在将数据包转发到R3之前弹出标签堆栈。当R3看到数据包P时，P只有一个级别1标签，现在已经退出了隧道。由于R3是P的1级LSP中的倒数第二个跃点，它弹出标签堆栈，R4接收未标记的P。
The label stack mechanism allows LSP tunneling to nest to any depth.
标签堆栈机制允许LSP隧道嵌套到任何深度。
Suppose that packet P travels along a Level 1 LSP <R1, R2, R3, R4>, and when going from R2 to R3 travels along a Level 2 LSP <R2, R21, R22, R3>. From the perspective of the Level 2 LSP, R2's label distribution peer is R21. From the perspective of the Level 1 LSP, R2's label distribution peers are R1 and R3. One can have label distribution peers at each layer of hierarchy. We will see in sections 4.6 and 4.7 some ways to make use of this hierarchy. Note that in this example, R2 and R21 must be IGP neighbors, but R2 and R3 need not be.
假设数据包P沿着级别1 LSP<R1，R2，R3，R4>移动，并且当从R2移动到R3时，数据包P沿着级别2 LSP<R2，R21，R22，R3>移动。从2级LSP的角度来看，R2的标签分发对等点是R21。从级别1 LSP的角度来看，R2的标签分发对等点是R1和R3。每个层次结构的每一层都可以有标签分发对等点。我们将在第4.6节和第4.7节中看到一些利用这种层次结构的方法。注意，在本例中，R2和R21必须是IGP邻居，但R2和R3不必是。
When two LSRs are IGP neighbors, we will refer to them as "local label distribution peers". When two LSRs may be label distribution peers, but are not IGP neighbors, we will refer to them as "remote label distribution peers". In the above example, R2 and R21 are local label distribution peers, but R2 and R3 are remote label distribution peers.
当两个LSR是IGP邻居时，我们将它们称为“本地标签分发对等点”。当两个LSR可能是标签分发对等点，但不是IGP邻居时，我们将它们称为“远程标签分发对等点”。在上面的示例中，R2和R21是本地标签分发对等点，但R2和R3是远程标签分发对等点。
The MPLS architecture supports two ways to distribute labels at different layers of the hierarchy: Explicit Peering and Implicit Peering.
MPLS体系结构支持在层次结构的不同层上分发标签的两种方式：显式对等和隐式对等。
One performs label distribution with one's local label distribution peer by sending label distribution protocol messages which are addressed to the peer. One can perform label distribution with one's remote label distribution peers in one of two ways:
通过向本地标签分发对等方发送标签分发协议消息，执行标签分发。可以通过以下两种方式之一与远程标签分发对等方执行标签分发：
1. Explicit Peering
1. 显式对等
In explicit peering, one distributes labels to a peer by sending label distribution protocol messages which are addressed to the peer, exactly as one would do for local label distribution peers. This technique is most useful when the number of remote label distribution peers is small, or the
在显式对等中，通过向对等方发送标签分发协议消息，将标签分发给对等方，就像本地标签分发对等方一样。当远程标签分发对等点的数量很小时，或者
number of higher level label bindings is large, or the remote label distribution peers are in distinct routing areas or domains. Of course, one needs to know which labels to distribute to which peers; this is addressed in section 4.1.2.
高级标签绑定的数量很大，或者远程标签分发对等点位于不同的路由区域或域中。当然，我们需要知道哪些标签要分发给哪些同行；第4.1.2节对此进行了说明。
Examples of the use of explicit peering is found in sections 4.2.1 and 4.6.
第4.2.1节和第4.6节提供了使用显式对等的示例。
2. Implicit Peering
2. 隐式窥视
In Implicit Peering, one does not send label distribution protocol messages which are addressed to one's peer. Rather, to distribute higher level labels to ones remote label distribution peers, one encodes a higher level label as an attribute of a lower level label, and then distributes the lower level label, along with this attribute, to one's local label distribution peers. The local label distribution peers then propagate the information to their local label distribution peers. This process continues till the information reaches the remote peer.
在隐式对等中，不向对等方发送标签分发协议消息。相反，要将较高级别的标签分发给远程标签分发对等方，需要将较高级别的标签编码为较低级别标签的属性，然后将较低级别的标签连同此属性分发给本地标签分发对等方。然后，本地标签分发对等方将信息传播到其本地标签分发对等方。此过程将继续，直到信息到达远程对等方。
This technique is most useful when the number of remote label distribution peers is large. Implicit peering does not require an n-square peering mesh to distribute labels to the remote label distribution peers because the information is piggybacked through the local label distribution peering. However, implicit peering requires the intermediate nodes to store information that they might not be directly interested in.
当远程标签分发对等点的数量较大时，此技术最有用。隐式对等不需要n方形对等网格将标签分发到远程标签分发对等点，因为信息是通过本地标签分发对等点承载的。但是，隐式对等需要中间节点存储它们可能不直接感兴趣的信息。
An example of the use of implicit peering is found in section 4.3.
隐式对等的使用示例见第4.3节。
A label distribution protocol is used between nodes in an MPLS network to establish and maintain the label bindings. In order for MPLS to operate correctly, label distribution information needs to be transmitted reliably, and the label distribution protocol messages pertaining to a particular FEC need to be transmitted in sequence. Flow control is also desirable, as is the capability to carry multiple label messages in a single datagram.
MPLS网络中的节点之间使用标签分发协议来建立和维护标签绑定。为了使MPLS正确工作，需要可靠地传输标签分发信息，并且需要按顺序传输与特定FEC有关的标签分发协议消息。流控制也是可取的，在单个数据报中承载多个标签消息的能力也是可取的。
One way to meet these goals is to use TCP as the underlying transport, as is done in [MPLS-LDP] and [MPLS-BGP].
实现这些目标的一种方法是使用TCP作为底层传输，正如在[MPLS-LDP]和[MPLS-BGP]中所做的那样。
This architecture does not establish hard and fast rules for choosing which label distribution protocol to use in which circumstances. However, it is possible to point out some of the considerations.
该体系结构没有建立硬性规则来选择在何种情况下使用何种标签分发协议。然而，可以指出其中一些考虑因素。
In many scenarios, it is desirable to bind labels to FECs which can be identified with routes to address prefixes (see section 4.1). If there is a standard, widely deployed routing algorithm which distributes those routes, it can be argued that label distribution is best achieved by piggybacking the label distribution on the distribution of the routes themselves.
在许多情况下，需要将标签绑定到FEC，FEC可以通过路由地址前缀进行识别（参见第4.1节）。如果有一个标准的、广泛部署的路由算法来分配这些路由，那么可以认为标签分配最好是通过将标签分配背驮在路由本身的分配上来实现的。
For example, BGP distributes such routes, and if a BGP speaker needs to also distribute labels to its BGP peers, using BGP to do the label distribution (see [MPLS-BGP]) has a number of advantages. In particular, it permits BGP route reflectors to distribute labels, thus providing a significant scalability advantage over using LDP to distribute labels between BGP peers.
例如，BGP分发此类路由，如果BGP演讲者还需要向其BGP对等方分发标签，则使用BGP进行标签分发（请参见[MPLS-BGP]）具有许多优点。特别是，它允许BGP路由反射器分发标签，因此与使用LDP在BGP对等点之间分发标签相比，具有显著的可扩展性优势。
When RSVP is used to set up resource reservations for particular flows, it can be desirable to label the packets in those flows, so that the RSVP filterspec does not need to be applied at each hop. It can be argued that having RSVP distribute the labels as part of its path/reservation setup process is the most efficient method of distributing labels for this purpose.
当使用RSVP为特定流设置资源预留时，可能希望标记这些流中的分组，以便不需要在每个跳应用RSVP filterspec。可以说，让RSVP分发标签作为其路径/保留设置过程的一部分，是为此目的分发标签的最有效方法。
In some applications of MPLS, particularly those related to traffic engineering, it is desirable to set up an explicitly routed path, from ingress to egress. It is also desirable to apply resource reservations along that path.
在MPLS的一些应用中，特别是与流量工程相关的应用中，需要建立从入口到出口的显式路由路径。沿该路径应用资源保留也是可取的。
One can imagine two approaches to this:
可以想象两种方法：
- Start with an existing protocol that is used for setting up resource reservations, and extend it to support explicit routing and label distribution.
- 从用于设置资源保留的现有协议开始，并对其进行扩展以支持显式路由和标签分发。
- Start with an existing protocol that is used for label distribution, and extend it to support explicit routing and resource reservations.
- 从用于标签分发的现有协议开始，并对其进行扩展以支持显式路由和资源保留。
The first approach has given rise to the protocol specified in [MPLS-RSVP-TUNNELS], the second to the approach specified in [MPLS-CR-LDP].
第一种方法产生了[MPLS-RSVP-TUNNELS]中规定的协议，第二种方法产生了[MPLS-CR-LDP]中规定的方法。
This section is for further study
本节是为了进一步研究
A number of uses of MPLS require that packets with a certain label be forwarded along the same hop-by-hop routed path that would be used for forwarding a packet with a specified address in its network layer destination address field.
MPLS的许多用途要求具有特定标签的数据包沿着相同的逐跳路由路径转发，该路径将用于转发具有其网络层目标地址字段中指定地址的数据包。
In general, router R determines the next hop for packet P by finding the address prefix X in its routing table which is the longest match for P's destination address. That is, the packets in a given FEC are just those packets which match a given address prefix in R's routing table. In this case, a FEC can be identified with an address prefix.
通常，路由器R通过在其路由表中查找地址前缀X来确定分组P的下一跳，该地址前缀X是P的目的地地址的最长匹配。也就是说，给定FEC中的包只是那些与R的路由表中的给定地址前缀匹配的包。在这种情况下，可以使用地址前缀来标识FEC。
Note that a packet P may be assigned to FEC F, and FEC F may be identified with address prefix X, even if P's destination address does not match X.
注意，分组P可以被分配给FEC F，并且FEC F可以用地址前缀X来标识，即使P的目的地地址与X不匹配。
LSRs R1 and R2 are considered to be label distribution peers for address prefix X if and only if one of the following conditions holds:
当且仅当下列条件之一成立时，LSR R1和R2被视为地址前缀X的标签分发对等方：
1. R1's route to X is a route which it learned about via a particular instance of a particular IGP, and R2 is a neighbor of R1 in that instance of that IGP
1. R1到X的路由是它通过特定IGP的特定实例了解的路由，R2是该IGP实例中R1的邻居
2. R1's route to X is a route which it learned about by some instance of routing algorithm A1, and that route is redistributed into an instance of routing algorithm A2, and R2 is a neighbor of R1 in that instance of A2
2. R1到X的路由是它通过路由算法A1的某个实例了解到的路由，该路由被重新分配到路由算法A2的实例中，R2是该路由算法A2实例中R1的邻居
3. R1 is the receive endpoint of an LSP Tunnel that is within another LSP, and R2 is a transmit endpoint of that tunnel, and R1 and R2 are participants in a common instance of an IGP, and are in the same IGP area (if the IGP in question has areas), and R1's route to X was learned via that IGP instance, or is redistributed by R1 into that IGP instance
3. R1是位于另一个LSP内的LSP隧道的接收端点，R2是该隧道的传输端点，R1和R2是IGP公共实例的参与者，并且位于同一IGP区域（如果所讨论的IGP具有区域），R1到X的路由通过该IGP实例学习，或者由R1重新分配到该IGP实例中
4. R1's route to X is a route which it learned about via BGP, and R2 is a BGP peer of R1
4. R1到X的路由是它通过BGP了解的路由，R2是R1的BGP对等方
In general, these rules ensure that if the route to a particular address prefix is distributed via an IGP, the label distribution peers for that address prefix are the IGP neighbors. If the route to a particular address prefix is distributed via BGP, the label distribution peers for that address prefix are the BGP peers. In other cases of LSP tunneling, the tunnel endpoints are label distribution peers.
通常，这些规则确保如果到特定地址前缀的路由是通过IGP分发的，则该地址前缀的标签分发对等方是IGP邻居。如果到特定地址前缀的路由是通过BGP分发的，则该地址前缀的标签分发对等方就是BGP对等方。在LSP隧道的其他情况下，隧道端点是标签分布对等点。
In order to use MPLS for the forwarding of packets according to the hop-by-hop route corresponding to any address prefix, each LSR MUST:
为了根据与任何地址前缀对应的逐跳路由使用MPLS转发数据包，每个LSR必须：
1. bind one or more labels to each address prefix that appears in its routing table;
1. 将一个或多个标签绑定到其路由表中出现的每个地址前缀；
2. for each such address prefix X, use a label distribution protocol to distribute the binding of a label to X to each of its label distribution peers for X.
2. 对于每个这样的地址前缀X，使用标签分发协议将标签到X的绑定分发到X的每个标签分发对等方。
There is also one circumstance in which an LSR must distribute a label binding for an address prefix, even if it is not the LSR which bound that label to that address prefix:
还有一种情况是，LSR必须为地址前缀分发标签绑定，即使不是LSR将该标签绑定到该地址前缀：
3. If R1 uses BGP to distribute a route to X, naming some other LSR R2 as the BGP Next Hop to X, and if R1 knows that R2 has assigned label L to X, then R1 must distribute the binding between L and X to any BGP peer to which it distributes that route.
3. 如果R1使用BGP将路由分配给X，将其他LSR R2命名为下一跳到X的BGP，并且如果R1知道R2已将标签L分配给X，则R1必须将L和X之间的绑定分配给其分配该路由的任何BGP对等方。
These rules ensure that labels corresponding to address prefixes which correspond to BGP routes are distributed to IGP neighbors if and only if the BGP routes are distributed into the IGP. Otherwise, the labels bound to BGP routes are distributed only to the other BGP speakers.
这些规则确保当且仅当BGP路由分布到IGP中时，与BGP路由对应的地址前缀对应的标签才会分布到IGP邻居。否则，绑定到BGP路由的标签将仅分发给其他BGP扬声器。
These rules are intended only to indicate which label bindings must be distributed by a given LSR to which other LSRs.
这些规则仅用于指示给定LSR必须将哪些标签绑定分发给哪些其他LSR。
If the hop-by-hop path that packet P needs to follow is <R1, ..., Rn>, then <R1, ..., Rn> can be an LSP as long as:
如果分组P需要遵循的逐跳路径是<R1，…，Rn>，则<R1，…，Rn>可以是LSP，只要：
1. there is a single address prefix X, such that, for all i, 1<=i<n, X is the longest match in Ri's routing table for P's destination address;
1. 有一个地址前缀X，因此，对于所有i，1<=i<n，X是Ri的路由表中P的目的地地址的最长匹配；
2. for all i, 1<i<n, Ri has assigned a label to X and distributed that label to R[i-1].
2. 对于所有i，1<i<n，Ri将一个标签分配给X，并将该标签分配给R[i-1]。
Note that a packet's LSP can extend only until it encounters a router whose forwarding tables have a longer best match address prefix for the packet's destination address. At that point, the LSP must end and the best match algorithm must be performed again.
请注意，数据包的LSP只能扩展到遇到其转发表具有较长的数据包目标地址最佳匹配地址前缀的路由器为止。此时，LSP必须结束，并且必须再次执行最佳匹配算法。
Suppose, for example, that packet P, with destination address 10.2.153.178 needs to go from R1 to R2 to R3. Suppose also that R2 advertises address prefix 10.2/16 to R1, but R3 advertises 10.2.153/23, 10.2.154/23, and 10.2/16 to R2. That is, R2 is advertising an "aggregated route" to R1. In this situation, packet P can be label Switched until it reaches R2, but since R2 has performed route aggregation, it must execute the best match algorithm to find P's FEC.
例如，假设目标地址为10.2.153.178的数据包P需要从R1到R2再到R3。还假设R2向R1播发地址前缀10.2/16，但R3向R2播发地址前缀10.2.153/23、10.2.154/23和10.2/16。也就是说，R2正在向R1宣传一条“聚合路由”。在这种情况下，数据包P可以在到达R2之前进行标签交换，但由于R2已经执行了路由聚合，它必须执行最佳匹配算法来找到P的FEC。
An LSR R is considered to be an "LSP Egress" LSR for address prefix X if and only if one of the following conditions holds:
当且仅当以下条件之一成立时，LSR被视为地址前缀X的“LSP出口”LSR：
1. R has an address Y, such that X is the address prefix in R's routing table which is the longest match for Y, or
1. R有一个地址Y，因此X是R的路由表中的地址前缀，它是Y的最长匹配，或者
2. R contains in its routing tables one or more address prefixes Y such that X is a proper initial substring of Y, but R's "LSP previous hops" for X do not contain any such address prefixes Y; that is, R is a "deaggregation point" for address prefix X.
2. R在其路由表中包含一个或多个地址前缀Y，使得X是Y的适当初始子串，但是R的X的“LSP先前跳数”不包含任何这样的地址前缀Y；也就是说，R是地址前缀X的“解聚集点”。
An LSR R1 is considered to be an "LSP Proxy Egress" LSR for address prefix X if and only if:
LSR R1被认为是地址前缀X的“LSP代理出口”LSR，当且仅当：
1. R1's next hop for X is R2, and R1 and R2 are not label distribution peers with respect to X (perhaps because R2 does not support MPLS), or
1. R1对于X的下一个跃点是R2，R1和R2不是相对于X的标签分发对等点（可能是因为R2不支持MPLS），或者
2. R1 has been configured to act as an LSP Proxy Egress for X
2. R1已配置为充当X的LSP代理出口
The definition of LSP allows for the LSP Egress to be a node which does not support MPLS; in this case the penultimate node in the LSP is the Proxy Egress.
LSP的定义允许LSP出口是不支持MPLS的节点；在这种情况下，LSP中的倒数第二个节点是代理出口。
The Implicit NULL label is a label with special semantics which an LSR can bind to an address prefix. If LSR Ru, by consulting its ILM, sees that labeled packet P must be forwarded next to Rd, but that Rd has distributed a binding of Implicit NULL to the corresponding address prefix, then instead of replacing the value of the label on top of the label stack, Ru pops the label stack, and then forwards the resulting packet to Rd.
隐式空标签是具有特殊语义的标签，LSR可以将其绑定到地址前缀。如果LSR Ru通过咨询其ILM发现标签数据包P必须转发到Rd旁边，但Rd已将隐式NULL绑定分发到相应的地址前缀，则Ru将弹出标签堆栈，然后将生成的数据包转发给Rd，而不是替换标签堆栈顶部的标签值。
LSR Rd distributes a binding between Implicit NULL and an address prefix X to LSR Ru if and only if:
LSR Rd将隐式NULL和地址前缀X之间的绑定分发给LSR Ru，当且仅当：
1. the rules of Section 4.1.2 indicate that Rd distributes to Ru a label binding for X, and
1. 第4.1.2节的规则表明Rd向Ru分发了一个X的标签绑定，以及
2. Rd knows that Ru can support the Implicit NULL label (i.e., that it can pop the label stack), and
2. Rd知道Ru可以支持隐式空标签（即，它可以弹出标签堆栈），并且
3. Rd is an LSP Egress (not proxy egress) for X.
3. Rd是X的LSP出口（不是代理出口）。
This causes the penultimate LSR on a LSP to pop the label stack. This is quite appropriate; if the LSP Egress is an MPLS Egress for X, then if the penultimate LSR does not pop the label stack, the LSP Egress will need to look up the label, pop the label stack, and then look up the next label (or look up the L3 address, if no more labels are present). By having the penultimate LSR pop the label stack, the LSP Egress is saved the work of having to look up two labels in order to make its forwarding decision.
这会导致LSP上倒数第二个LSR弹出标签堆栈。这是很恰当的,；如果LSP出口是X的MPLS出口，那么如果倒数第二个LSR没有弹出标签堆栈，LSP出口将需要查找标签，弹出标签堆栈，然后查找下一个标签（或者如果没有更多标签，则查找L3地址）。通过让倒数第二个LSR弹出标签堆栈，LSP出口省去了查找两个标签以做出转发决策的工作。
However, if the penultimate LSR is an ATM switch, it may not have the capability to pop the label stack. Hence a binding of Implicit NULL may be distributed only to LSRs which can support that function.
但是，如果倒数第二个LSR是ATM交换机，则它可能无法弹出标签堆栈。因此，隐式NULL的绑定可能仅分发给支持该函数的LSR。
If the penultimate LSR in an LSP for address prefix X is an LSP Proxy Egress, it acts just as if the LSP Egress had distributed a binding of Implicit NULL for X.
如果地址前缀X的LSP中倒数第二个LSR是一个LSP代理出口，那么它的作用就像LSP出口为X分发了一个隐式NULL绑定一样。
There are situations in which an LSP Ingress, Ri, knows that packets of several different FECs must all follow the same LSP, terminating at, say, LSP Egress Re. In this case, proper routing can be achieved
在某些情况下，LSP入口Ri知道多个不同fec的分组必须全部遵循相同的LSP，在例如LSP出口Re处终止。在这种情况下，可以实现正确的路由
by using a single label for all such FECs; it is not necessary to have a distinct label for each FEC. If (and only if) the following conditions hold:
通过对所有此类FEC使用单一标签；没有必要为每个FEC设置不同的标签。如果（且仅当）以下条件成立：
1. the address of LSR Re is itself in the routing table as a "host route", and
1. LSR Re的地址本身在路由表中作为“主机路由”，并且
2. there is some way for Ri to determine that Re is the LSP egress for all packets in a particular set of FECs
2. Ri可以通过某种方式确定Re是特定fec集合中所有分组的LSP出口
Then Ri may bind a single label to all FECS in the set. This is known as "Egress-Targeted Label Assignment."
然后Ri可以将单个标签绑定到集合中的所有fec。这称为“出口目标标签分配”
How can LSR Ri determine that an LSR Re is the LSP Egress for all packets in a particular FEC? There are a number of possible ways:
LSR Ri如何确定LSR Re是特定FEC中所有分组的LSP出口？有许多可能的方法：
- If the network is running a link state routing algorithm, and all nodes in the area support MPLS, then the routing algorithm provides Ri with enough information to determine the routers through which packets in that FEC must leave the routing domain or area.
- 如果网络正在运行链路状态路由算法，并且该区域中的所有节点都支持MPLS，则路由算法向Ri提供足够的信息，以确定该FEC中的数据包必须通过哪些路由器离开路由域或区域。
- If the network is running BGP, Ri may be able to determine that the packets in a particular FEC must leave the network via some particular router which is the "BGP Next Hop" for that FEC.
- 如果网络正在运行BGP，Ri可能能够确定特定FEC中的分组必须经由某个特定路由器离开网络，该路由器是该FEC的“BGP下一跳”。
- It is possible to use the label distribution protocol to pass information about which address prefixes are "attached" to which egress LSRs. This method has the advantage of not depending on the presence of link state routing.
- 可以使用标签分发协议传递关于哪些地址前缀“附加”到哪个出口LSR的信息。这种方法的优点是不依赖于链路状态路由的存在。
If egress-targeted label assignment is used, the number of labels that need to be supported throughout the network may be greatly reduced. This may be significant if one is using legacy switching hardware to do MPLS, and the switching hardware can support only a limited number of labels.
如果使用出口目标标签分配，则需要在整个网络中支持的标签的数量可以大大减少。如果使用传统交换硬件来进行MPLS，并且交换硬件只能支持有限数量的标签，那么这可能非常重要。
One possible approach would be to configure the network to use egress-targeted label assignment by default, but to configure particular LSRs to NOT use egress-targeted label assignment for one or more of the address prefixes for which it is an LSP egress. We impose the following rule:
一种可能的方法是将网络配置为默认使用出口目标标签分配，但将特定lsr配置为不对其为LSP出口的一个或多个地址前缀使用出口目标标签分配。我们实施以下规则：
- If a particular LSR is NOT an LSP Egress for some set of address prefixes, then it should assign labels to the address prefixes in the same way as is done by its LSP next hop for those address prefixes. That is, suppose Rd is Ru's LSP next
- 如果某个特定的LSR不是某组地址前缀的LSP出口，那么它应该按照其LSP下一跳为这些地址前缀所做的相同方式为地址前缀分配标签。也就是说，假设Rd是Ru的下一个LSP
hop for address prefixes X1 and X2. If Rd assigns the same label to X1 and X2, Ru should as well. If Rd assigns different labels to X1 and X2, then Ru should as well.
地址前缀X1和X2的跃点。如果Rd将相同的标签分配给X1和X2，则Ru也应如此。如果Rd为X1和X2分配了不同的标签，那么Ru也应该这样做。
For example, suppose one wants to make egress-targeted label assignment the default, but to assign distinct labels to those address prefixes for which there are multiple possible LSP egresses (i.e., for those address prefixes which are multi-homed.) One can configure all LSRs to use egress-targeted label assignment, and then configure a handful of LSRs to assign distinct labels to those address prefixes which are multi-homed. For a particular multi-homed address prefix X, one would only need to configure this in LSRs which are either LSP Egresses or LSP Proxy Egresses for X.
例如，假设希望将出口目标标签分配设为默认值，但要将不同的标签分配给存在多个可能的LSP出口的地址前缀（即，多址地址前缀）。可以将所有LSR配置为使用出口目标标签分配，然后配置一些LSR，为多址地址前缀分配不同的标签。对于特定的多宿地址前缀X，只需在LSR中配置它，LSR是X的LSP出口或LSP代理出口。
It is important to note that if Ru and Rd are adjacent LSRs in an LSP for X1 and X2, forwarding will still be done correctly if Ru assigns distinct labels to X1 and X2 while Rd assigns just one label to the both of them. This just means that R1 will map different incoming labels to the same outgoing label, an ordinary occurrence.
需要注意的是，如果Ru和Rd是X1和X2的LSP中相邻的LSR，那么如果Ru将不同的标签分配给X1和X2，而Rd仅将一个标签分配给两者，则转发仍将正确进行。这仅仅意味着R1将把不同的传入标签映射到同一个传出标签，这是一个普通的事件。
Similarly, if Rd assigns distinct labels to X1 and X2, but Ru assigns to them both the label corresponding to the address of their LSP Egress or Proxy Egress, forwarding will still be done correctly. Ru will just map the incoming label to the label which Rd has assigned to the address of that LSP Egress.
类似地，如果Rd将不同的标签分配给X1和X2，但是Ru将与它们的LSP出口或代理出口的地址相对应的标签分配给它们，则转发仍将正确进行。Ru只将传入标签映射到Rd分配给该LSP出口地址的标签。
There are a number of reasons why it may be desirable to use explicit routing instead of hop by hop routing. For example, this allows routes to be based on administrative policies, and allows the routes that LSPs take to be carefully designed to allow traffic engineering [MPLS-TRFENG].
使用显式路由而不是逐跳路由可能是可取的，原因有很多。例如，这允许路由基于管理策略，并允许LSP采用的路由经过仔细设计，以允许流量工程[MPLS-TRFENG]。
In some situations, the network administrators may desire to forward certain classes of traffic along certain pre-specified paths, where these paths differ from the Hop-by-hop path that the traffic would ordinarily follow. This can be done in support of policy routing, or in support of traffic engineering. The explicit route may be a configured one, or it may be determined dynamically by some means, e.g., by constraint-based routing.
在某些情况下，网络管理员可能希望沿着某些预先指定的路径转发某些类别的流量，其中这些路径不同于流量通常遵循的逐跳路径。这可以通过支持策略路由或支持流量工程来实现。显式路由可以是配置的路由，或者可以通过一些手段（例如，通过基于约束的路由）动态地确定。
MPLS allows this to be easily done by means of Explicitly Routed LSP Tunnels. All that is needed is:
MPLS允许通过显式路由LSP隧道轻松实现这一点。所需要的是：
1. A means of selecting the packets that are to be sent into the Explicitly Routed LSP Tunnel;
1. 选择要发送到显式路由LSP隧道中的分组的装置；
2. A means of setting up the Explicitly Routed LSP Tunnel;
2. 设置显式路由LSP隧道的方法；
3. A means of ensuring that packets sent into the Tunnel will not loop from the receive endpoint back to the transmit endpoint.
3. 确保发送到隧道中的数据包不会从接收端点循环回发送端点的一种方法。
If the transmit endpoint of the tunnel wishes to put a labeled packet into the tunnel, it must first replace the label value at the top of the stack with a label value that was distributed to it by the tunnel's receive endpoint. Then it must push on the label which corresponds to the tunnel itself, as distributed to it by the next hop along the tunnel. To allow this, the tunnel endpoints should be explicit label distribution peers. The label bindings they need to exchange are of no interest to the LSRs along the tunnel.
如果隧道的传输端点希望将带标签的数据包放入隧道，它必须首先用隧道的接收端点分配给它的标签值替换堆栈顶部的标签值。然后，它必须推上与隧道本身相对应的标签，该标签由沿隧道的下一跳分发给它。为此，隧道端点应该是显式的标签分发对等点。他们需要交换的标签绑定对隧道沿线的LSR不感兴趣。
Suppose a particular LSR Re is an LSP proxy egress for 10 address prefixes, and it reaches each address prefix through a distinct interface.
假设一个特定的LSR Re是10个地址前缀的LSP代理出口，它通过一个不同的接口到达每个地址前缀。
One could assign a single label to all 10 address prefixes. Then Re is an LSP egress for all 10 address prefixes. This ensures that packets for all 10 address prefixes get delivered to Re. However, Re would then have to look up the network layer address of each such packet in order to choose the proper interface to send the packet on.
可以为所有10个地址前缀分配一个标签。然后Re是所有10个地址前缀的LSP出口。这确保了所有10个地址前缀的数据包都被发送到Re。然而，Re随后必须查找每个这样的分组的网络层地址，以便选择发送分组的适当接口。
Alternatively, one could assign a distinct label to each interface. Then Re is an LSP proxy egress for the 10 address prefixes. This eliminates the need for Re to look up the network layer addresses in order to forward the packets. However, it can result in the use of a large number of labels.
或者，可以为每个接口指定一个不同的标签。然后Re是10个地址前缀的LSP代理出口。这消除了重新查找网络层地址以转发数据包的需要。但是，它可能会导致使用大量标签。
An alternative would be to bind all 10 address prefixes to the same level 1 label (which is also bound to the address of the LSR itself), and then to bind each address prefix to a distinct level 2 label. The level 2 label would be treated as an attribute of the level 1 label binding, which we call the "Stack Attribute". We impose the following rules:
另一种方法是将所有10个地址前缀绑定到同一级别1标签（也绑定到LSR本身的地址），然后将每个地址前缀绑定到不同的级别2标签。级别2标签将被视为级别1标签绑定的属性，我们称之为“堆栈属性”。我们实施以下规则：
- When LSR Ru initially labels a hitherto unlabeled packet, if the longest match for the packet's destination address is X, and Ru's LSP next hop for X is Rd, and Rd has distributed to Ru a binding of label L1 to X, along with a stack attribute of L2, then
- 当LSR Ru最初标记一个迄今为止未标记的数据包时，如果该数据包的目的地地址的最长匹配为X，并且Ru的X的LSP下一跳为Rd，并且Rd已将标签L1到X的绑定以及堆栈属性L2分发给Ru，则
1. Ru must push L2 and then L1 onto the packet's label stack, and then forward the packet to Rd;
1. Ru必须将L2和L1推到数据包的标签堆栈上，然后将数据包转发给Rd；
2. When Ru distributes label bindings for X to its label distribution peers, it must include L2 as the stack attribute.
2. 当Ru将X的标签绑定分发给其标签分发对等方时，它必须将L2作为堆栈属性。
3. Whenever the stack attribute changes (possibly as a result of a change in Ru's LSP next hop for X), Ru must distribute the new stack attribute.
3. 每当堆栈属性更改时（可能是由于Ru的LSP next hop for X的更改），Ru必须分发新的堆栈属性。
Note that although the label value bound to X may be different at each hop along the LSP, the stack attribute value is passed unchanged, and is set by the LSP proxy egress.
注意，尽管绑定到X的标签值在沿着LSP的每个跃点处可能不同，但是堆栈属性值是不变地传递的，并且由LSP代理出口设置。
Thus the LSP proxy egress for X becomes an "implicit peer" with each other LSR in the routing area or domain. In this case, explicit peering would be too unwieldy, because the number of peers would become too large.
因此，X的LSP代理出口成为路由区域或域中彼此LSR的“隐式对等”。在这种情况下，显式对等将过于笨拙，因为对等的数量将变得太多。
If an LSR supports multiple routes for a particular stream, then it may assign multiple labels to the stream, one for each route. Thus the reception of a second label binding from a particular neighbor for a particular address prefix should be taken as meaning that either label can be used to represent that address prefix.
如果LSR支持特定流的多个路由，那么它可以为该流分配多个标签，每个路由一个标签。因此，对于特定地址前缀，从特定邻居接收到的第二标签绑定应被视为意味着可以使用任一标签来表示该地址前缀。
If multiple label bindings for a particular address prefix are specified, they may have distinct attributes.
如果为特定地址前缀指定了多个标签绑定，则它们可能具有不同的属性。
Consider the case of packets P1 and P2, each of which has a destination address whose longest match, throughout a particular routing domain, is address prefix X. Suppose that the Hop-by-hop path for P1 is <R1, R2, R3>, and the Hop-by-hop path for P2 is <R4, R2, R3>. Let's suppose that R3 binds label L3 to X, and distributes this binding to R2. R2 binds label L2 to X, and distributes this binding to both R1 and R4. When R2 receives packet P1, its incoming label will be L2. R2 will overwrite L2 with L3, and send P1 to R3. When R2 receives packet P2, its incoming label will also be L2. R2 again overwrites L2 with L3, and send P2 on to R3.
考虑分组P1和P2的情况，每一个都有一个目标地址，其在一个特定的路由域中最长的匹配是地址前缀X。假设P1的逐跳路径是<R1，R2，R3>，并且P2的逐跳路径是<R4，R2，R3>。假设R3将标签L3绑定到X，并将此绑定分发到R2。R2将标签L2绑定到X，并将此绑定分发到R1和R4。当R2接收到数据包P1时，其传入标签将为L2。R2将用L3覆盖L2，并将P1发送到R3。当R2接收到数据包P2时，其传入标签也将是L2。R2再次用L3覆盖L2，并将P2发送到R3。
Note then that when P1 and P2 are traveling from R2 to R3, they carry the same label, and as far as MPLS is concerned, they cannot be distinguished. Thus instead of talking about two distinct LSPs, <R1,
然后请注意，当P1和P2从R2移动到R3时，它们带有相同的标签，就MPLS而言，它们无法区分。因此，与其讨论两个不同的LSP，<R1，
R2, R3> and <R4, R2, R3>, we might talk of a single "Multipoint-to-Point LSP Tree", which we might denote as <{R1, R4}, R2, R3>.
R2，R3>和<R4，R2，R3>，我们可以谈论单个“多点对点LSP树”，我们可以将其表示为<{R1，R4}，R2，R3>。
This creates a difficulty when we attempt to use conventional ATM switches as LSRs. Since conventional ATM switches do not support multipoint-to-point connections, there must be procedures to ensure that each LSP is realized as a point-to-point VC. However, if ATM switches which do support multipoint-to-point VCs are in use, then the LSPs can be most efficiently realized as multipoint-to-point VCs. Alternatively, if the SVP Multipoint Encoding (section 3.25.2) can be used, the LSPs can be realized as multipoint-to-point SVPs.
当我们试图使用传统的ATM交换机作为LSR时，这就造成了一个困难。由于传统ATM交换机不支持多点对点连接，因此必须有程序确保每个LSP都实现为点对点VC。但是，如果使用支持多点对点VCs的ATM交换机，则LSP可以最有效地实现为多点对点VCs。或者，如果可以使用SVP多点编码（第3.25.2节），则LSP可以实现为多点对点SVP。
Consider the case of an Autonomous System, A, which carries transit traffic between other Autonomous Systems. Autonomous System A will have a number of BGP Border Routers, and a mesh of BGP connections among them, over which BGP routes are distributed. In many such cases, it is desirable to avoid distributing the BGP routes to routers which are not BGP Border Routers. If this can be avoided, the "route distribution load" on those routers is significantly reduced. However, there must be some means of ensuring that the transit traffic will be delivered from Border Router to Border Router by the interior routers.
考虑自治系统A的情况，它在其他自治系统之间传输过境业务。自治系统A将有多个BGP边界路由器，以及它们之间的BGP连接网，BGP路由分布在这些路由器上。在许多这样的情况下，希望避免将BGP路由分配给不是BGP边界路由器的路由器。如果可以避免这种情况，那么这些路由器上的“路由分布负载”将显著降低。然而，必须有某种方法确保过境交通将通过内部路由器从边界路由器传送到边界路由器。
This can easily be done by means of LSP Tunnels. Suppose that BGP routes are distributed only to BGP Border Routers, and not to the interior routers that lie along the Hop-by-hop path from Border Router to Border Router. LSP Tunnels can then be used as follows:
这可以通过LSP隧道轻松实现。假设BGP路由只分布到BGP边界路由器，而不分布到位于从边界路由器到边界路由器的逐跳路径上的内部路由器。LSP隧道可按如下方式使用：
1. Each BGP Border Router distributes, to every other BGP Border Router in the same Autonomous System, a label for each address prefix that it distributes to that router via BGP.
1. 每个BGP边界路由器向同一自治系统中的每个其他BGP边界路由器分发其通过BGP分发给该路由器的每个地址前缀的标签。
2. The IGP for the Autonomous System maintains a host route for each BGP Border Router. Each interior router distributes its labels for these host routes to each of its IGP neighbors.
2. 自治系统的IGP为每个BGP边界路由器维护主机路由。每个内部路由器将这些主机路由的标签分发给每个IGP邻居。
3. Suppose that:
3. 假设：
a) BGP Border Router B1 receives an unlabeled packet P,
a) BGP边界路由器B1接收未标记的分组P，
b) address prefix X in B1's routing table is the longest match for the destination address of P,
b) B1路由表中的地址前缀X是P的目标地址的最长匹配项，
c) the route to X is a BGP route,
c) 到X的路由是BGP路由，
d) the BGP Next Hop for X is B2,
d) X的BGP下一跳是B2，
e) B2 has bound label L1 to X, and has distributed this binding to B1,
e) B2已将标签L1绑定到X，并已将此绑定分发到B1，
f) the IGP next hop for the address of B2 is I1,
f) B2地址的IGP下一跳为I1，
g) the address of B2 is in B1's and I1's IGP routing tables as a host route, and
g) B2的地址作为主机路由在B1和I1的IGP路由表中，并且
h) I1 has bound label L2 to the address of B2, and distributed this binding to B1.
h) I1已将标签L2绑定到B2的地址，并将此绑定分发到B1。
Then before sending packet P to I1, B1 must create a label stack for P, then push on label L1, and then push on label L2.
然后，在将数据包P发送到I1之前，B1必须为P创建一个标签堆栈，然后按标签L1，然后按标签L2。
4. Suppose that BGP Border Router B1 receives a labeled Packet P, where the label on the top of the label stack corresponds to an address prefix, X, to which the route is a BGP route, and that conditions 3b, 3c, 3d, and 3e all hold. Then before sending packet P to I1, B1 must replace the label at the top of the label stack with L1, and then push on label L2.
4. 假设BGP边界路由器B1接收到标签分组P，其中标签栈顶部的标签对应于地址前缀X，路由是BGP路由，并且条件3b、3c、3d和3e都保持不变。然后，在将数据包P发送到I1之前，B1必须用L1替换标签堆栈顶部的标签，然后推上标签L2。
With these procedures, a given packet P follows a level 1 LSP all of whose members are BGP Border Routers, and between each pair of BGP Border Routers in the level 1 LSP, it follows a level 2 LSP.
通过这些过程，给定的分组P遵循一级LSP，其所有成员都是BGP边界路由器，并且在一级LSP中的每对BGP边界路由器之间，它遵循一级2 LSP。
These procedures effectively create a Hop-by-Hop Routed LSP Tunnel between the BGP Border Routers.
这些过程有效地在BGP边界路由器之间创建逐跳路由LSP隧道。
Since the BGP border routers are exchanging label bindings for address prefixes that are not even known to the IGP routing, the BGP routers should become explicit label distribution peers with each other.
由于BGP边界路由器正在为IGP路由甚至不知道的地址前缀交换标签绑定，因此BGP路由器应该成为彼此的显式标签分发对等点。
It is sometimes possible to create Hop-by-Hop Routed LSP Tunnels between two BGP Border Routers, even if they are not in the same Autonomous System. Suppose, for example, that B1 and B2 are in AS 1. Suppose that B3 is an EBGP neighbor of B2, and is in AS2. Finally, suppose that B2 and B3 are on some network which is common to both Autonomous Systems (a "Demilitarized Zone"). In this case, an LSP tunnel can be set up directly between B1 and B3 as follows:
有时可以在两个BGP边界路由器之间创建逐跳路由LSP隧道，即使它们不在同一自治系统中。例如，假设B1和B2位于AS 1中。假设B3是B2的EBGP邻居，并且在AS2中。最后，假设B2和B3位于两个自治系统共用的某个网络上（“非军事区”）。在这种情况下，可以直接在B1和B3之间设置LSP隧道，如下所示：
- B3 distributes routes to B2 (using EBGP), optionally assigning labels to address prefixes;
- B3将路由分配给B2（使用EBGP），可以选择将标签分配给地址前缀；
- B2 redistributes those routes to B1 (using IBGP), indicating that the BGP next hop for each such route is B3. If B3 has assigned labels to address prefixes, B2 passes these labels along, unchanged, to B1.
- B2将这些路由重新分配到B1（使用IBGP），表示每个此类路由的BGP下一跳是B3。如果B3为地址前缀分配了标签，B2将这些标签原封不动地传递给B1。
- The IGP of AS1 has a host route for B3.
- AS1的IGP有B3的主机路由。
The use of Hop-by-Hop Routed LSP Tunnels is not restricted to tunnels between BGP Next Hops. Any situation in which one might otherwise have used an encapsulation tunnel is one in which it is appropriate to use a Hop-by-Hop Routed LSP Tunnel. Instead of encapsulating the packet with a new header whose destination address is the address of the tunnel's receive endpoint, the label corresponding to the address prefix which is the longest match for the address of the tunnel's receive endpoint is pushed on the packet's label stack. The packet which is sent into the tunnel may or may not already be labeled.
逐跳路由LSP隧道的使用不限于BGP下一跳之间的隧道。任何可能使用封装隧道的情况都适合使用逐跳路由LSP隧道。不是用目的地地址为隧道接收端点地址的新报头封装数据包，而是将地址前缀对应的标签推送到数据包的标签堆栈上，该地址前缀与隧道接收端点的地址最长匹配。发送到隧道中的数据包可能已标记，也可能尚未标记。
If the transmit endpoint of the tunnel wishes to put a labeled packet into the tunnel, it must first replace the label value at the top of the stack with a label value that was distributed to it by the tunnel's receive endpoint. Then it must push on the label which corresponds to the tunnel itself, as distributed to it by the next hop along the tunnel. To allow this, the tunnel endpoints should be explicit label distribution peers. The label bindings they need to exchange are of no interest to the LSRs along the tunnel.
如果隧道的传输端点希望将带标签的数据包放入隧道，它必须首先用隧道的接收端点分配给它的标签值替换堆栈顶部的标签值。然后，它必须推上与隧道本身相对应的标签，该标签由沿隧道的下一跳分发给它。为此，隧道端点应该是显式的标签分发对等点。他们需要交换的标签绑定对隧道沿线的LSR不感兴趣。
Multicast routing proceeds by constructing multicast trees. The tree along which a particular multicast packet must get forwarded depends in general on the packet's source address and its destination address. Whenever a particular LSR is a node in a particular multicast tree, it binds a label to that tree. It then distributes that binding to its parent on the multicast tree. (If the node in question is on a LAN, and has siblings on that LAN, it must also distribute the binding to its siblings. This allows the parent to use a single label value when multicasting to all children on the LAN.)
组播路由通过构造组播树来进行。一个特定的多播数据包必须沿着的树通常取决于数据包的源地址和目的地址。只要特定LSR是特定多播树中的节点，它就会将标签绑定到该树。然后，它将该绑定分发到多播树上的父节点。（如果所讨论的节点位于LAN上，并且在该LAN上有同级，则它还必须将绑定分发给同级。这允许父节点在多播到LAN上的所有子节点时使用单个标签值。）
When a multicast labeled packet arrives, the NHLFE corresponding to the label indicates the set of output interfaces for that packet, as well as the outgoing label. If the same label encoding technique is used on all the outgoing interfaces, the very same packet can be sent to all the children.
当多播标记的分组到达时，与该标签对应的NHLFE指示该分组的输出接口集以及传出标签。如果在所有输出接口上使用相同的标签编码技术，则可以向所有子接口发送相同的数据包。
In this section, we consider only label bindings that are used for traffic to be label switched along its hop-by-hop routed path. In these cases, the label in question will correspond to an address prefix in the routing table.
在本节中，我们只考虑用于流量的标签绑定，其标签按其逐跳路由路径切换。在这些情况下，相关标签将对应于路由表中的地址前缀。
There are a number of different procedures that may be used to distribute label bindings. Some are executed by the downstream LSR, and some by the upstream LSR.
有许多不同的过程可用于分发标签绑定。有些由下游LSR执行，有些由上游LSR执行。
The downstream LSR must perform:
下游LSR必须执行以下操作：
- The Distribution Procedure, and
- 分发程序，以及
- the Withdrawal Procedure.
- 退出程序。
The upstream LSR must perform:
上游LSR必须执行以下操作：
- The Request Procedure, and
- 请求程序，以及
- the NotAvailable Procedure, and
- 不可用的程序，以及
- the Release Procedure, and
- 发布程序，以及
- the labelUse Procedure.
- labelUse程序。
The MPLS architecture supports several variants of each procedure.
MPLS体系结构支持每个过程的几个变体。
However, the MPLS architecture does not support all possible combinations of all possible variants. The set of supported combinations will be described in section 5.2, where the interoperability between different combinations will also be discussed.
但是，MPLS体系结构不支持所有可能变体的所有可能组合。第5.2节将描述支持的组合集，其中还将讨论不同组合之间的互操作性。
The Distribution Procedure is used by a downstream LSR to determine when it should distribute a label binding for a particular address prefix to its label distribution peers. The architecture supports four different distribution procedures.
分发过程由下游LSR用于确定何时应将特定地址前缀的标签绑定分发给其标签分发对等方。该体系结构支持四种不同的分发过程。
Irrespective of the particular procedure that is used, if a label binding for a particular address prefix has been distributed by a downstream LSR Rd to an upstream LSR Ru, and if at any time the attributes (as defined above) of that binding change, then Rd must inform Ru of the new attributes.
不管所使用的特定过程如何，如果下游LSR Rd已将特定地址前缀的标签绑定分发给上游LSR Ru，并且如果在任何时候该绑定的属性（如上所述）发生更改，则Rd必须将新属性通知Ru。
If an LSR is maintaining multiple routes to a particular address prefix, it is a local matter as to whether that LSR binds multiple labels to the address prefix (one per route), and hence distributes multiple bindings.
如果LSR维护到特定地址前缀的多个路由，则LSR是否将多个标签绑定到地址前缀（每个路由一个）并因此分发多个绑定是本地问题。
Let Rd be an LSR. Suppose that:
让Rd成为LSR。假设：
1. X is an address prefix in Rd's routing table
1. X是Rd路由表中的地址前缀
2. Ru is a label distribution peer of Rd with respect to X
2. Ru是Rd相对于X的标签分发对等点
Whenever these conditions hold, Rd must bind a label to X and distribute that binding to Ru. It is the responsibility of Rd to keep track of the bindings which it has distributed to Ru, and to make sure that Ru always has these bindings.
只要这些条件成立，Rd就必须将标签绑定到X，并将该绑定分发到Ru。Rd负责跟踪它已分发给Ru的绑定，并确保Ru始终拥有这些绑定。
This procedure would be used by LSRs which are performing unsolicited downstream label assignment in the Independent LSP Control Mode.
该程序将由在独立LSP控制模式下执行未经请求的下游标签分配的LSR使用。
Let Rd be an LSR. Suppose that:
让Rd成为LSR。假设：
1. X is an address prefix in Rd's routing table
1. X是Rd路由表中的地址前缀
2. Ru is a label distribution peer of Rd with respect to X
2. Ru是Rd相对于X的标签分发对等点
3. Rd is either an LSP Egress or an LSP Proxy Egress for X, or Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and Rn has bound a label to X and distributed that binding to Rd.
3. Rd是X的LSP出口或LSP代理出口，或者X的Rd的L3下一跳是Rn，其中Rn不同于Ru，并且Rn已将标签绑定到X并将该绑定分发到Rd。
Then as soon as these conditions all hold, Rd should bind a label to X and distribute that binding to Ru.
然后，只要这些条件都成立，Rd就应该将标签绑定到X，并将该绑定分发到Ru。
Whereas PushUnconditional causes the distribution of label bindings for all address prefixes in the routing table, PushConditional causes the distribution of label bindings only for those address prefixes for which one has received label bindings from one's LSP next hop, or for which one does not have an MPLS-capable L3 next hop.
PushConditional会导致路由表中所有地址前缀的标签绑定的分发，而PushConditional只会导致从LSP下一跳接收标签绑定的地址前缀的分发，或者没有支持MPLS的L3下一跳的地址前缀的分发。
This procedure would be used by LSRs which are performing unsolicited downstream label assignment in the Ordered LSP Control Mode.
在有序LSP控制模式下执行未经请求的下游标签分配的LSR将使用此程序。
Let Rd be an LSR. Suppose that:
让Rd成为LSR。假设：
1. X is an address prefix in Rd's routing table
1. X是Rd路由表中的地址前缀
2. Ru is a label distribution peer of Rd with respect to X
2. Ru是Rd相对于X的标签分发对等点
3. Ru has explicitly requested that Rd bind a label to X and distribute the binding to Ru
3. Ru已明确请求Rd将标签绑定到X并将绑定分发给Ru
Then Rd should bind a label to X and distribute that binding to Ru. Note that if X is not in Rd's routing table, or if Rd is not a label distribution peer of Ru with respect to X, then Rd must inform Ru that it cannot provide a binding at this time.
然后Rd应该将标签绑定到X，并将该绑定分发到Ru。注意，如果X不在Rd的路由表中，或者Rd不是Ru相对于X的标签分发对等方，则Rd必须通知Ru此时无法提供绑定。
If Rd has already distributed a binding for address prefix X to Ru, and it receives a new request from Ru for a binding for address prefix X, it will bind a second label, and distribute the new binding to Ru. The first label binding remains in effect.
如果Rd已经将地址前缀X的绑定分发给Ru，并且它从Ru接收到地址前缀X绑定的新请求，它将绑定第二个标签，并将新绑定分发给Ru。第一个标签绑定仍然有效。
This procedure would be used by LSRs performing downstream-on-demand label distribution using the Independent LSP Control Mode.
使用独立LSP控制模式执行下游按需标签分发的LSR将使用此程序。
Let Rd be an LSR. Suppose that:
让Rd成为LSR。假设：
1. X is an address prefix in Rd's routing table
1. X是Rd路由表中的地址前缀
2. Ru is a label distribution peer of Rd with respect to X
2. Ru是Rd相对于X的标签分发对等点
3. Ru has explicitly requested that Rd bind a label to X and distribute the binding to Ru
3. Ru已明确请求Rd将标签绑定到X并将绑定分发给Ru
4. Rd is either an LSP Egress or an LSP Proxy Egress for X, or Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and Rn has bound a label to X and distributed that binding to Rd
4. Rd是X的LSP出口或LSP代理出口，或者X的Rd的L3下一跳是Rn，其中Rn不同于Ru，并且Rn已将标签绑定到X并将该绑定分发到Rd
Then as soon as these conditions all hold, Rd should bind a label to X and distribute that binding to Ru. Note that if X is not in Rd's routing table and a binding for X is not obtainable via Rd's next hop for X, or if Rd is not a label distribution peer of Ru with respect to X, then Rd must inform Ru that it cannot provide a binding at this time.
然后，只要这些条件都成立，Rd就应该将标签绑定到X，并将该绑定分发到Ru。请注意，如果X不在Rd的路由表中，并且X的绑定无法通过Rd的X下一跳获得，或者如果Rd不是Ru相对于X的标签分发对等点，则Rd必须通知Ru此时无法提供绑定。
However, if the only condition that fails to hold is that Rn has not yet provided a label to Rd, then Rd must defer any response to Ru until such time as it has receiving a binding from Rn.
但是，如果无法保持的唯一条件是Rn尚未向Rd提供标签，则Rd必须将对Ru的任何响应延迟到收到来自Rn的绑定为止。
If Rd has distributed a label binding for address prefix X to Ru, and at some later time, any attribute of the label binding changes, then Rd must redistribute the label binding to Ru, with the new attribute. It must do this even though Ru does not issue a new Request.
如果Rd已将地址前缀X的标签绑定分发给Ru，并且在以后某个时间，标签绑定的任何属性都会更改，则Rd必须使用新属性将标签绑定重新分发给Ru。即使Ru没有发出新请求，它也必须这样做。
This procedure would be used by LSRs that are performing downstream-on-demand label allocation in the Ordered LSP Control Mode.
在有序LSP控制模式下执行下游按需标签分配的LSR将使用此程序。
In section 5.2, we will discuss how to choose the particular procedure to be used at any given time, and how to ensure interoperability among LSRs that choose different procedures.
在第5.2节中，我们将讨论如何选择在任何给定时间使用的特定程序，以及如何确保选择不同程序的LSR之间的互操作性。
The Request Procedure is used by the upstream LSR for an address prefix to determine when to explicitly request that the downstream LSR bind a label to that prefix and distribute the binding. There are three possible procedures that can be used.
请求过程由上游LSR用于地址前缀，以确定何时显式请求下游LSR将标签绑定到该前缀并分发绑定。可以使用三种可能的程序。
Never make a request. This is useful if the downstream LSR uses the PushConditional procedure or the PushUnconditional procedure, but is not useful if the downstream LSR uses the PulledUnconditional procedure or the the PulledConditional procedures.
永远不要提出要求。如果下游LSR使用PushConditional过程或PushConditional过程，则此选项很有用，但如果下游LSR使用PulledUnditional过程或PulledConditional过程，则此选项无效。
This procedure would be used by an LSR when unsolicited downstream label distribution and Liberal Label Retention Mode are being used.
当使用未经请求的下游标签分发和自由标签保留模式时，LSR将使用此程序。
Make a request whenever the L3 next hop to the address prefix changes, or when a new address prefix is learned, and one doesn't already have a label binding from that next hop for the given address prefix.
每当地址前缀的L3下一个跃点发生更改时，或当学习到新的地址前缀时，并且尚未从该下一个跃点为给定地址前缀绑定标签时，发出请求。
This procedure would be used by an LSR whenever Conservative Label Retention Mode is being used.
无论何时使用保守的标签保留模式，LSR都将使用此程序。
Issue a request whenever a request is received, in addition to issuing a request when needed (as described in section 5.1.2.2). If Ru is not capable of being an LSP ingress, it may issue a request only when it receives a request from upstream.
除在需要时发出请求外（如第5.1.2.2节所述），在收到请求时发出请求。如果Ru不能成为LSP入口，则它只能在接收到来自上游的请求时发出请求。
If Rd receives such a request from Ru, for an address prefix for which Rd has already distributed Ru a label, Rd shall assign a new (distinct) label, bind it to X, and distribute that binding. (Whether Rd can distribute this binding to Ru immediately or not depends on the Distribution Procedure being used.)
如果Rd收到Ru的此类请求，对于Rd已向Ru分配标签的地址前缀，Rd应分配一个新的（不同的）标签，将其绑定到X，并分发该绑定。（Rd是否可以立即将此绑定分发给Ru取决于所使用的分发过程。）
This procedure would be used by an LSR which is doing downstream-on-demand label distribution, but is not doing label merging, e.g., an ATM-LSR which is not capable of VC merge.
该程序将由正在进行下游按需标签分发但未进行标签合并的LSR使用，例如，无法进行VC合并的ATM-LSR。
If Ru and Rd are respectively upstream and downstream label distribution peers for address prefix X, and Rd is Ru's L3 next hop for X, and Ru requests a binding for X from Rd, but Rd replies that it cannot provide a binding at this time, because it has no next hop for X, then the NotAvailable procedure determines how Ru responds. There are two possible procedures governing Ru's behavior:
如果Ru和Rd分别是地址前缀X的上游和下游标签分发对等点，Rd是Ru的L3 X下一跳，并且Ru从Rd请求X的绑定，但Rd答复说此时无法提供绑定，因为它没有X下一跳，则NotAvailable过程确定Ru如何响应。Ru的行为有两种可能的程序：
Ru should issue the request again at a later time. That is, the requester is responsible for trying again later to obtain the needed binding. This procedure would be used when downstream-on-demand label distribution is used.
Ru应在以后再次发出请求。也就是说，请求者负责稍后再次尝试获取所需的绑定。当使用下游按需标签分发时，将使用此程序。
Ru should never reissue the request, instead assuming that Rd will provide the binding automatically when it is available. This is useful if Rd uses the PushUnconditional procedure or the PushConditional procedure, i.e., if unsolicited downstream label distribution is used.
Ru永远不应该重新发出请求，而是假设Rd将在可用时自动提供绑定。如果Rd使用PushConditional过程或PushConditional过程，即，如果使用未经请求的下游标签分发，则这非常有用。
Note that if Rd replies that it cannot provide a binding to Ru, because of some error condition, rather than because Rd has no next hop, the behavior of Ru will be governed by the error recovery conditions of the label distribution protocol, rather than by the NotAvailable procedure.
请注意，如果Rd回复由于某些错误条件而不是因为Rd没有下一跳而无法提供与Ru的绑定，则Ru的行为将由标签分发协议的错误恢复条件控制，而不是由NotAvailable过程控制。
Suppose that Rd is an LSR which has bound a label to address prefix X, and has distributed that binding to LSR Ru. If Rd does not happen to be Ru's L3 next hop for address prefix X, or has ceased to be Ru's L3 next hop for address prefix X, then Ru will not be using the label. The Release Procedure determines how Ru acts in this case. There are two possible procedures governing Ru's behavior:
假设Rd是一个LSR，它已将标签绑定到地址前缀X，并已将该绑定分发到LSR Ru。如果Rd不是地址前缀X的Ru的L3下一跳，或者不再是地址前缀X的Ru的L3下一跳，则Ru将不使用标签。释放程序确定Ru在这种情况下的行为。Ru的行为有两种可能的程序：
Ru should release the binding, and inform Rd that it has done so. This procedure would be used to implement Conservative Label Retention Mode.
Ru应该释放绑定，并通知Rd它已经这样做了。此程序将用于实施保守的标签保留模式。
Ru should maintain the binding, so that it can use it again immediately if Rd later becomes Ru's L3 next hop for X. This procedure would be used to implement Liberal Label Retention Mode.
Ru应该维护绑定，以便在Rd以后成为Ru的L3下一跳X时可以立即再次使用。此过程将用于实现自由标签保留模式。
Suppose Ru is an LSR which has received label binding L for address prefix X from LSR Rd, and Ru is upstream of Rd with respect to X, and in fact Rd is Ru's L3 next hop for X.
假设Ru是一个LSR，它从LSR Rd接收到地址前缀X的标签绑定L，并且Ru相对于X在Rd的上游，实际上Rd是Ru对于X的L3下一跳。
Ru will make use of the binding if Rd is Ru's L3 next hop for X. If, at the time the binding is received by Ru, Rd is NOT Ru's L3 next hop for X, Ru does not make any use of the binding at that time. Ru may however start using the binding at some later time, if Rd becomes Ru's L3 next hop for X.
如果Rd是Ru对X的L3下一个跃点，Ru将使用绑定。如果在Ru接收到绑定时，Rd不是Ru对X的L3下一个跃点，Ru在当时不使用绑定。但是，如果Rd成为Ru的X下一跳L3，Ru可能会在稍后的某个时间开始使用绑定。
The labelUse Procedure determines just how Ru makes use of Rd's binding.
labluse过程确定Ru如何利用Rd的绑定。
There are two procedures which Ru may use:
Ru可使用两种程序：
Ru may put the binding into use immediately. At any time when Ru has a binding for X from Rd, and Rd is Ru's L3 next hop for X, Rd will also be Ru's LSP next hop for X. This procedure is used when loop detection is not in use.
Ru可立即使用该装订。在任何时候，当Ru从Rd为X绑定，并且Rd是Ru为X的L3下一跳时，Rd也将是Ru为X的LSP下一跳。此过程在未使用循环检测时使用。
This procedure is the same as UseImmediate, unless Ru has detected a loop in the LSP. If a loop has been detected, Ru will discontinue the use of label L for forwarding packets to Rd.
此过程与UseImmediate相同，除非Ru在LSP中检测到环路。如果检测到循环，Ru将停止使用标签L向Rd转发数据包。
This procedure is used when loop detection is in use.
当使用循环检测时，使用此程序。
This will continue until the next hop for X changes, or until the loop is no longer detected.
这将一直持续到X的下一个跃点发生更改，或者直到不再检测到循环为止。
In this case, there is only a single procedure.
在这种情况下，只有一个过程。
When LSR Rd decides to break the binding between label L and address prefix X, then this unbinding must be distributed to all LSRs to which the binding was distributed.
当LSR Rd决定断开标签L和地址前缀X之间的绑定时，必须将此解除绑定分发给所有分发了绑定的LSR。
It is required that the unbinding of L from X be distributed by Rd to a LSR Ru before Rd distributes to Ru any new binding of L to any other address prefix Y, where X != Y. If Ru were to learn of the new binding of L to Y before it learned of the unbinding of L from X, and if packets matching both X and Y were forwarded by Ru to Rd, then for a period of time, Ru would label both packets matching X and packets matching Y with label L.
要求在Rd将L与任何其他地址前缀Y的任何新绑定分配给Ru之前，由Rd将L与X的解除绑定分配给LSR Ru，其中X！=Y.如果Ru在得知L从X解绑之前就知道L到Y的新绑定，并且如果匹配X和Y的数据包被Ru转发到Rd，则在一段时间内，Ru将标记匹配X的数据包和匹配Y的数据包，并使用标签L。
The distribution and withdrawal of label bindings is done via a label distribution protocol. All label distribution protocols require that a label distribution adjacency be established between two label distribution peers (except implicit peers). If LSR R1 has a label distribution adjacency to LSR R2, and has received label bindings from LSR R2 via that adjacency, then if adjacency is brought down by either peer (whether as a result of failure or as a matter of normal operation), all bindings received over that adjacency must be considered to have been withdrawn.
标签绑定的分发和撤销是通过标签分发协议完成的。所有标签分发协议都要求在两个标签分发对等点（隐式对等点除外）之间建立标签分发邻接。如果LSR R1与LSR R2具有标签分布邻接关系，并且通过该邻接关系从LSR R2接收到标签绑定，则如果邻接关系由任一对等方关闭（无论是由于故障还是由于正常操作），则必须将通过该邻接关系接收到的所有绑定视为已撤销。
As long as the relevant label distribution adjacency remains in place, label bindings that are withdrawn must always be withdrawn explicitly. If a second label is bound to an address prefix, the result is not to implicitly withdraw the first label, but to bind both labels; this is needed to support multi-path routing. If a second address prefix is bound to a label, the result is not to implicitly withdraw the binding of that label to the first address prefix, but to use that label for both address prefixes.
只要相关的标签分布邻接保持不变，则必须始终显式地撤销撤销的标签绑定。如果第二个标签绑定到地址前缀，则结果不是隐式撤回第一个标签，而是绑定两个标签；这是支持多路径路由所必需的。如果将第二个地址前缀绑定到标签，则结果不是隐式撤消该标签与第一个地址前缀的绑定，而是将该标签用于两个地址前缀。
Consider two LSRs, Ru and Rd, which are label distribution peers with respect to some set of address prefixes, where Ru is the upstream peer and Rd is the downstream peer.
考虑两个LSR，RU和RD，它们是相对于某些地址前缀的标签分发对等体，其中RU是上游对等体，RD是下游对等体。
The MPLS scheme which governs the interaction of Ru and Rd can be described as a quintuple of procedures: <Distribution Procedure, Request Procedure, NotAvailable Procedure, Release Procedure, labelUse Procedure>. (Since there is only one Withdraw Procedure, it need not be mentioned.) A "*" appearing in one of the positions is a wild-card, meaning that any procedure in that category may be present; an "N/A" appearing in a particular position indicates that no procedure in that category is needed.
管理Ru和Rd交互的MPLS方案可以描述为五个过程：<分发过程、请求过程、不可用过程、发布过程、labelUse过程>。（由于只有一个退出程序，因此无需提及。）出现在其中一个位置的“*”是通配符，意味着该类别中的任何程序都可能存在；在特定位置出现的“N/A”表示不需要该类别的程序。
Only the MPLS schemes which are specified below are supported by the MPLS Architecture. Other schemes may be added in the future, if a need for them is shown.
MPLS体系结构仅支持以下指定的MPLS方案。如果需要，将来可能会添加其他方案。
If Ru and Rd are label distribution peers, and both support label merging, one of the following schemes must be used:
如果Ru和Rd是标签分发对等方，并且两者都支持标签合并，则必须使用以下方案之一：
1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseImmediate>
1. <PushUnderstanced，RequestNever，N/A，NoReleaseOnChange，UseImmediate>
This is unsolicited downstream label distribution with independent control, liberal label retention mode, and no loop detection.
这是具有独立控制、自由标签保留模式和无循环检测的主动下游标签分发。
2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseIfLoopNotDetected>
2. <PushUnderstanced，RequestNever，N/A，NoReleaseOnChange，UseIfLoopNotDetected>
This is unsolicited downstream label distribution with independent control, liberal label retention, and loop detection.
这是具有独立控制、自由标签保留和循环检测的主动下游标签分发。
3. <PushConditional, RequestWhenNeeded, RequestNoRetry, ReleaseOnChange, *>
3. <PushConditional、requestwhenneed、RequestNoRetry、releaseochange，*>
This is unsolicited downstream label distribution with ordered control (from the egress) and conservative label retention mode. Loop detection is optional.
这是具有有序控制（从出口）和保守标签保留模式的未经请求的下游标签分发。循环检测是可选的。
4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>
4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>
This is unsolicited downstream label distribution with ordered control (from the egress) and liberal label retention mode. Loop detection is optional.
这是具有有序控制（从出口）和自由标签保留模式的主动下游标签分发。循环检测是可选的。
5. <PulledConditional, RequestWhenNeeded, RequestRetry, ReleaseOnChange, *>
5. <PulledConditional、RequestWhenneed、RequestRetry、ReleaseOnChange，*>
This is downstream-on-demand label distribution with ordered control (initiated by the ingress), conservative label retention mode, and optional loop detection.
这是下游按需标签分发，具有有序控制（由入口启动）、保守的标签保留模式和可选的环路检测。
6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseImmediate>
6. <PulledUnconditional，RequestWhenneed，N/A，ReleaseOnChange，UseImmediate>
This is downstream-on-demand label distribution with independent control and conservative label retention mode, without loop detection.
这是下游按需标签分发，具有独立控制和保守的标签保留模式，无需环路检测。
7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseIfLoopNotDetected>
7. <PullerUnconditional，RequestWhenneed，N/A，ReleaseOnChange，UseIfLoopNotDetected>
This is downstream-on-demand label distribution with independent control and conservative label retention mode, with loop detection.
这是下游按需标签分发，具有独立控制和保守的标签保留模式以及循环检测。
Suppose that R1, R2, R3, and R4 are ATM switches which do not support label merging, but are being used as LSRs. Suppose further that the L3 hop-by-hop path for address prefix X is <R1, R2, R3, R4>, and that packets destined for X can enter the network at any of these LSRs. Since there is no multipoint-to-point capability, the LSPs must be realized as point-to-point VCs, which means that there needs to be three such VCs for address prefix X: <R1, R2, R3, R4>, <R2, R3, R4>, and <R3, R4>.
假设R1、R2、R3和R4是不支持标签合并但用作LSR的ATM交换机。进一步假设地址前缀X的L3逐跳路径是<R1、R2、R3、R4>，并且目的地为X的分组可以在这些lsr中的任何一个进入网络。由于没有多点对点功能，LSP必须实现为点对点VCs，这意味着地址前缀X需要有三个这样的VCs：<R1，R2，R3，R4>，<R2，R3，R4>，和<R3，R4>。
Therefore, if R1 and R2 are MPLS peers, and either is an LSR which is implemented using conventional ATM switching hardware (i.e., no cell interleave suppression), or is otherwise incapable of performing label merging, the MPLS scheme in use between R1 and R2 must be one of the following:
因此，如果R1和R2是MPLS对等点，并且是使用传统ATM交换硬件实现的LSR（即，无信元交织抑制），或者不能执行标签合并，则R1和R2之间使用的MPLS方案必须是以下之一：
1. <PulledConditional, RequestOnRequest, RequestRetry, ReleaseOnChange, *>
1. <PulledConditional，RequestOnRequest，RequestRetry，ReleaseOnChange，*>
This is downstream-on-demand label distribution with ordered control (initiated by the ingress), conservative label retention mode, and optional loop detection.
这是下游按需标签分发，具有有序控制（由入口启动）、保守的标签保留模式和可选的环路检测。
The use of the RequestOnRequest procedure will cause R4 to distribute three labels for X to R3; R3 will distribute 2 labels for X to R2, and R2 will distribute one label for X to R1.
使用RequestOnRequest过程将导致R4为X向R3分发三个标签；R3将为X向R2分发2个标签，R2将为X向R1分发一个标签。
2. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseImmediate>
2. <PulledUnconditional，RequestOnRequest，N/A，ReleaseOnChange，UseImmediate>
This is downstream-on-demand label distribution with independent control and conservative label retention mode, without loop detection.
这是下游按需标签分发，具有独立控制和保守的标签保留模式，无需环路检测。
3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseIfLoopNotDetected>
3. <PulledUnconditional，RequestOnRequest，N/A，ReleaseOnChange，UseIfLoopNotDetected>
This is downstream-on-demand label distribution with independent control and conservative label retention mode, with loop detection.
这是下游按需标签分发，具有独立控制和保守的标签保留模式以及循环检测。
It is easy to see that certain quintuples do NOT yield viable MPLS schemes. For example:
很容易看出，某些五元组不能产生可行的MPLS方案。例如：
- <PulledUnconditional, RequestNever, *, *, *>
<PulledConditional, RequestNever, *, *, *>
- <PulledUnconditional, RequestNever, *, *, *>
<PulledConditional, RequestNever, *, *, *>
In these MPLS schemes, the downstream LSR Rd distributes label bindings to upstream LSR Ru only upon request from Ru, but Ru never makes any such requests. Obviously, these schemes are not viable, since they will not result in the proper distribution of label bindings.
在这些MPLS方案中，下游LSR-Rd仅在Ru请求时才将标签绑定分发到上游LSR-Ru，但Ru从未发出任何此类请求。显然，这些方案是不可行的，因为它们不会导致标签绑定的正确分布。
- <*, RequestNever, *, *, ReleaseOnChange>
- <*, RequestNever, *, *, ReleaseOnChange>
In these MPLS schemes, Rd releases bindings when it isn't using them, but it never asks for them again, even if it later has a need for them. These schemes thus do not ensure that label bindings get properly distributed.
在这些MPLS方案中，Rd在不使用绑定时会释放绑定，但它不会再次请求绑定，即使以后需要它们。因此，这些方案不能确保标签绑定得到正确分发。
In this section, we specify rules to prevent a pair of label distribution peers from adopting procedures which lead to infeasible MPLS Schemes. These rules require either the exchange of information between label distribution peers during the initialization of the label distribution adjacency, or a priori knowledge of the information (obtained through a means outside the scope of this document).
在本节中，我们指定规则以防止一对标签分发对等点采用导致不可行MPLS方案的过程。这些规则要求在标签分布邻接初始化期间，标签分布对等点之间交换信息，或者需要信息的先验知识（通过本文档范围之外的方法获得）。
1. Each must state whether it supports label merging.
1. 每个都必须说明是否支持标签合并。
2. If Rd does not support label merging, Rd must choose either the PulledUnconditional procedure or the PulledConditional procedure. If Rd chooses PulledConditional, Ru is forced to use the RequestRetry procedure.
2. 如果Rd不支持标签合并，Rd必须选择PulledUnconditional过程或PulledConditional过程。如果Rd选择PulledConditional，Ru将被迫使用RequestRetry过程。
That is, if the downstream LSR does not support label merging, its preferences take priority when the MPLS scheme is chosen.
也就是说，如果下游LSR不支持标签合并，则当选择MPLS方案时，其首选项优先。
3. If Ru does not support label merging, but Rd does, Ru must choose either the RequestRetry or RequestNoRetry procedure. This forces Rd to use the PulledConditional or PulledUnConditional procedure respectively.
3. 如果Ru不支持标签合并，但Rd支持，Ru必须选择RequestRetry或RequestNoRetry过程。这将强制Rd分别使用PulledConditional或PulledConditional过程。
That is, if only one of the LSRs doesn't support label merging, its preferences take priority when the MPLS scheme is chosen.
也就是说，如果只有一个LSR不支持标签合并，那么当选择MPLS方案时，它的首选项优先。
4. If both Ru and Rd both support label merging, then the choice between liberal and conservative label retention mode belongs to Ru. That is, Ru gets to choose either to use RequestWhenNeeded/ReleaseOnChange (conservative) , or to use RequestNever/NoReleaseOnChange (liberal). However, the choice of "push" vs. "pull" and "conditional" vs. "unconditional" belongs to Rd. If Ru chooses liberal label retention mode, Rd can choose either PushUnconditional or PushConditional. If Ru chooses conservative label retention mode, Rd can choose PushConditional, PulledConditional, or PulledUnconditional.
4. 如果Ru和Rd都支持标签合并，则自由和保守标签保留模式之间的选择属于Ru。也就是说，Ru可以选择使用RequestWhenneed/ReleaseOnChange（保守），或者使用RequestNever/NoReleaseOnChange（自由）。但是，“推”与“拉”以及“有条件”与“无条件”的选择属于Rd。如果Ru选择自由标签保留模式，Rd可以选择“推无条件”或“推有条件”。如果Ru选择保守的标签保留模式，Rd可以选择PushConditional、PulledConditional或PulledUnconditional。
These choices together determine the MPLS scheme in use.
这些选择共同决定了使用中的MPLS方案。
Some routers may implement security procedures which depend on the network layer header being in a fixed place relative to the data link layer header. The MPLS generic encapsulation inserts a shim between the data link layer header and the network layer header. This may cause any such security procedures to fail.
一些路由器可以实现安全过程，这取决于网络层报头处于相对于数据链路层报头的固定位置。MPLS通用封装在数据链路层头和网络层头之间插入一个垫片。这可能导致任何此类安全程序失败。
An MPLS label has its meaning by virtue of an agreement between the LSR that puts the label in the label stack (the "label writer"), and the LSR that interprets that label (the "label reader"). If labeled packets are accepted from untrusted sources, or if a particular incoming label is accepted from an LSR to which that label has not been distributed, then packets may be routed in an illegitimate manner.
MPLS标签的含义取决于将标签放入标签堆栈的LSR（“标签写入器”）和解释该标签的LSR（“标签读取器”）之间的协议。如果从不受信任的来源接受带标签的数据包，或者如果从没有分发标签的LSR接受特定的传入标签，则数据包可能以非法方式路由。
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已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Eric C.Rosen Cisco Systems，Inc.马萨诸塞州切姆斯福德阿波罗大道250号，邮编01824
EMail: erosen@cisco.com
EMail: erosen@cisco.com
Arun Viswanathan Force10 Networks, Inc. 1440 McCarthy Blvd. Milpitas, CA 95035-7438
Arun Viswanathan Force10 Networks，Inc.麦卡锡大道1440号。加利福尼亚州米尔皮塔斯95035-7438
EMail: arun@force10networks.com
EMail: arun@force10networks.com
Ross Callon Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA
美国加利福尼亚州桑尼维尔市北马蒂尔达大道1194号罗斯卡隆Juniper Networks公司，邮编94089
EMail: rcallon@juniper.net
EMail: rcallon@juniper.net
[MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[MPLS-ATM]Davie，B.，Lawrence，J.，McCloghrie，K.，Rekhter，Y.，Rosen，E.，Swallow，G.和P.Doolan，“使用LDP和ATM VC交换的MPLS”，RFC 3035，2001年1月。
[MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, Work in Progress.
[MPLS-BGP]“在BGP-4中携带标签信息”，罗森，雷克特，正在进行中。
[MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi, Editor, Work in Progress.
[MPLS-CR-LDP]“使用LDP的基于约束的LSP设置”，Jamoussi，编辑，正在进行中。
[MPLS-FRMRLY] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[MPLS-FRMRLY]Conta，A.，Doolan，P.和A.Malis，“帧中继网络上标签切换的使用规范”，RFC 3034，2001年1月。
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[MPLS-LDP]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[MPLS-RSVP-TUNNELS] "Extensions to RSVP for LSP Tunnels", Awduche, Berger, Gan, Li, Swallow, Srinvasan, Work in Progress.
[MPLS-RSVP-TUNNELS]“LSP隧道的RSVP扩展”，Awduche，Berger，Gan，Li，Swallow，Srinvasan，正在进行的工作。
[MPLS-SHIM] Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G., Farinacci, D. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-SHIM]Rosen，E.，Rekhter，Y.，Tappan，D.，Fedorkow，G.，Farinaci，D.和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[MPLS-TRFENG] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[MPLS-TRFENG]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
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编辑功能的资金目前由互联网协会提供。