Internet Engineering Task Force (IETF) E. Rosen
Request for Comments: 8277 Juniper Networks, Inc.
Obsoletes: 3107 October 2017
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) E. Rosen
Request for Comments: 8277 Juniper Networks, Inc.
Obsoletes: 3107 October 2017
Category: Standards Track
ISSN: 2070-1721
Using BGP to Bind MPLS Labels to Address Prefixes
使用BGP将MPLS标签绑定到地址前缀
Abstract
摘要
This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107.
本文档指定了一组过程，用于使用BGP通知指定的路由器已将指定的MPLS标签（或作为标签堆栈的连续部分组织的指定MPLS标签序列）绑定到指定的地址前缀。这可以通过发送BGP更新消息来实现，该消息的网络层可达性信息字段包含前缀和MPLS标签，并且其下一跳字段标识所述前缀绑定到所述标签的节点。本文件淘汰了RFC 3107。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8277.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8277.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Using BGP to Bind an Address Prefix to One or More MPLS
Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Multiple Labels Capability . . . . . . . . . . . . . . . 6
2.2. NLRI Encoding When the Multiple Labels Capability Is
Not Used . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. NLRI Encoding When the Multiple Labels Capability Is Used 10
2.4. How to Explicitly Withdraw the Binding of a Label to a
Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Changing the Label That Is Bound to a Prefix . . . . . . 13
3. Installing and/or Propagating SAFI-4 or SAFI-128 Routes . . . 14
3.1. Comparability of Routes . . . . . . . . . . . . . . . . . 14
3.2. Modification of Label(s) Field When Propagating . . . . . 14
3.2.1. When the Next Hop Field Is Unchanged . . . . . . . . 14
3.2.2. When the Next Hop Field Is Changed . . . . . . . . . 15
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Relationship between SAFI-4 and SAFI-1 Routes . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Using BGP to Bind an Address Prefix to One or More MPLS
Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Multiple Labels Capability . . . . . . . . . . . . . . . 6
2.2. NLRI Encoding When the Multiple Labels Capability Is
Not Used . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. NLRI Encoding When the Multiple Labels Capability Is Used 10
2.4. How to Explicitly Withdraw the Binding of a Label to a
Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Changing the Label That Is Bound to a Prefix . . . . . . 13
3. Installing and/or Propagating SAFI-4 or SAFI-128 Routes . . . 14
3.1. Comparability of Routes . . . . . . . . . . . . . . . . . 14
3.2. Modification of Label(s) Field When Propagating . . . . . 14
3.2.1. When the Next Hop Field Is Unchanged . . . . . . . . 14
3.2.2. When the Next Hop Field Is Changed . . . . . . . . . 15
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Relationship between SAFI-4 and SAFI-1 Routes . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
[RFC3107] specifies encodings and procedures for using BGP to indicate that a particular router has bound either a single MPLS label or a sequence of MPLS labels to a particular address prefix. (A sequence of labels would be organized as a contiguous part of an MPLS label stack as specified in [RFC3031] and [RFC3032].) This is done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). Each such UPDATE also advertises a path to the specified prefix via the specified next hop.
[RFC3107]指定使用BGP指示特定路由器已将单个MPLS标签或MPLS标签序列绑定到特定地址前缀的编码和过程。（按照[RFC3031]和[RFC3032]中的规定，标签序列将被组织为MPLS标签堆栈的连续部分）。这是通过发送BGP更新消息来完成的，该消息的网络层可达性信息字段包含前缀和MPLS标签以及其下一跳字段标识所述前缀绑定到所述标签的节点。每个这样的更新还通过指定的下一跳播发到指定前缀的路径。
Although there are many implementations and deployments of [RFC3107], there are a number of issues with it that have impeded interoperability in the past and may potentially impede interoperability in the future:
尽管[RFC3107]有许多实施和部署，但在过去存在许多阻碍互操作性的问题，并可能在未来阻碍互操作性：
o Although [RFC3107] specifies an encoding that allows a sequence of MPLS labels (rather than just a single label) to be bound to a prefix, it does not specify the semantics of binding a sequence of labels to a prefix.
o 尽管[RFC3107]指定了允许MPLS标签序列（而不仅仅是单个标签）绑定到前缀的编码，但它没有指定将标签序列绑定到前缀的语义。
o Many implementations of [RFC3107] assume that only one label will be bound to a prefix, and cannot properly process a BGP UPDATE message that binds a sequence of labels to a prefix. Thus, an implementation attempting to provide this feature is likely to experience problems interoperating with other implementations.
o [RFC3107]的许多实现都假设只有一个标签将绑定到前缀，并且无法正确处理将标签序列绑定到前缀的BGP更新消息。因此，试图提供此功能的实现可能会遇到与其他实现互操作的问题。
o The procedures in [RFC3107] for withdrawing the binding of a label or sequence of labels to a prefix are not specified clearly and correctly.
o [RFC3107]中关于撤销标签或标签序列与前缀的绑定的程序未明确正确地规定。
o [RFC3107] specifies an optional feature, known as "Advertising Multiple Routes to a Destination", that, to the best of the author's knowledge, has never been implemented as specified. The functionality that this feature was intended to provide can and has been implemented in a different way using the procedures of [RFC7911], which were not available at the time that [RFC3107] was written. In [RFC3107], this feature was controlled by a BGP Capability Code that has never been implemented and is now deprecated; see Section 6.
o [RFC3107]指定了一个可选功能，称为“向目的地发送多条路线的广告”，据作者所知，该功能从未按规定实施过。该功能旨在提供can，并已使用[RFC7911]的程序以不同的方式实现，该程序在编写[RFC3107]时不可用。在[RFC3107]中，此功能由BGP功能代码控制，该代码从未实现过，现在已被弃用；见第6节。
o It is possible for a BGP speaker to receive two BGP UPDATEs that advertise paths to the same address prefix, where one UPDATE binds a label (or sequence of labels) to the prefix and the other does not. [RFC3107] is silent on the issue of how the presence of two such UPDATEs impacts the BGP decision process and does not say explicitly whether one or the other or both of these UPDATEs should be propagated. This has led different implementations to handle this situation in different ways.
o BGP扬声器可能会接收到两个BGP更新，其中一个更新将标签（或标签序列）绑定到同一地址前缀，而另一个则不会。[RFC3107]对两个此类更新的存在如何影响BGP决策过程的问题保持沉默，并且没有明确说明是否应传播一个或另一个或两个更新。这导致不同的实现以不同的方式处理这种情况。
o Much of [RFC3107] applies to the VPN-IPv4 ([RFC4364]) and VPN-IPv6 ([RFC4659]) address families, but those address families are not mentioned in it.
o [RFC3107]中的大部分适用于VPN-IPv4（[RFC4364]）和VPN-IPv6（[RFC4659]）地址系列，但其中未提及这些地址系列。
This document replaces and obsoletes [RFC3107]. It defines a new BGP Capability to be used when binding a sequence of labels to a prefix; by using this Capability, the interoperability problems alluded to above can be avoided. This document also removes the unimplemented
本文件取代并废弃[RFC3107]。它定义了将标签序列绑定到前缀时要使用的新BGP功能；通过使用此功能，可以避免上面提到的互操作性问题。本文档还删除了未实现的
"Advertising Multiple Routes to a Destination" feature (see Section 4 of [RFC3107]), while specifying how to use [RFC7911] to provide the same functionality. This document also addresses the issue of the how UPDATEs that bind labels to a given prefix interact with UPDATEs that advertise paths to that prefix but do not bind labels to it. However, for backwards compatibility, it declares most of these interactions to be matters of local policy.
“向目的地发布多条路线广告”功能（参见[RFC3107]第4节），同时指定如何使用[RFC7911]提供相同的功能。本文档还讨论了将标签绑定到给定前缀的更新如何和向该前缀播发路径但不将标签绑定到该前缀的更新交互的问题。然而，为了向后兼容，它声明大多数这些交互都是本地策略的问题。
The places where this specification differs from [RFC3107] are indicated in the text. It is believed that implementations that conform to the current document will interoperate correctly with existing deployed implementations of [RFC3107].
文本中指出了本规范与[RFC3107]不同的地方。相信符合当前文档的实现将与[RFC3107]的现有部署实现正确地互操作。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
BGP may be used to advertise that a particular node (call it N) has bound a particular MPLS label, or a particular sequence of MPLS labels (organized as a contiguous part of an MPLS label stack), to a particular address prefix. This is done by sending a Multiprotocol BGP UPDATE message, i.e., an UPDATE message with an MP_REACH_NLRI attribute as specified in [RFC4760]. The Network Address of Next Hop field of that attribute contains an IP address of node N. The label(s) and the prefix are encoded in the Network Layer Reachability Information (NLRI) field of the MP_REACH_NLRI. The encoding of the NLRI field is specified in Sections 2.2 and 2.3.
BGP可用于通告特定节点（称为N）已将特定MPLS标签或特定MPLS标签序列（组织为MPLS标签堆栈的连续部分）绑定到特定地址前缀。这是通过发送多协议BGP更新消息来实现的，即具有[RFC4760]中指定的MP_REACH_NLRI属性的更新消息。该属性的下一跳网络地址字段包含节点N的IP地址。标签和前缀在MP_REACH_NLRI的网络层可达性信息（NLRI）字段中编码。第2.2节和第2.3节规定了NLRI字段的编码。
If the prefix is an IPv4 address prefix or a VPN-IPv4 ([RFC4364]) address prefix, the Address Family Identifier (AFI) of the MP_REACH_NLRI attribute is set to 1. If the prefix is an IPv6 address prefix or a VPN-IPv6 prefix ([RFC4659]), the AFI is set to 2.
如果前缀是IPv4地址前缀或VPN-IPv4（[RFC4364]）地址前缀，则MP_REACH_NLRI属性的地址族标识符（AFI）设置为1。如果前缀是IPv6地址前缀或VPN-IPv6前缀（[RFC4659]），则AFI设置为2。
If the prefix is an IPv4 address prefix or an IPv6 address prefix, the Subsequent Address Family Identifier (SAFI) field is set to 4. If the prefix is a VPN-IPv4 address prefix or a VPN-IPv6 address prefix, the SAFI is set to 128.
如果前缀是IPv4地址前缀或IPv6地址前缀，则后续地址族标识符（SAFI）字段设置为4。如果前缀是VPN-IPv4地址前缀或VPN-IPv6地址前缀，则SAFI设置为128。
The use of SAFI 4 or SAFI 128 when the AFI is other than 1 or 2 is outside the scope of this document.
当AFI不是1或2时，使用SAFI 4或SAFI 128不在本文件范围内。
This document does not specify the format of the Network Address of Next Hop field of the MP_REACH_NLRI attribute. The format of the Next Hop field depends upon a number of factors and is discussed in a number of other RFCs: see [RFC4364], [RFC4659], [RFC4798], and [RFC5549].
本文档未指定MP_REACH_NLRI属性的下一跳网络地址字段的格式。下一跳字段的格式取决于许多因素，并在许多其他RFC中讨论：请参阅[RFC4364]、[RFC4659]、[RFC4798]和[RFC5549]。
There are a variety of applications that make use of alternative methods of using BGP to advertise MPLS label bindings: see, e.g., [RFC7432], [RFC6514], or [TUNNEL-ENCAPS]. The method described in the current document is not claimed to be the only way of using BGP to advertise MPLS label bindings. Discussion of which method to use for which application is outside the scope of the current document.
有多种应用程序使用BGP的替代方法来公布MPLS标签绑定：例如，请参阅[RFC7432]、[RFC6514]或[TUNNEL-ENCAPS]。当前文档中描述的方法并不是使用BGP播发MPLS标签绑定的唯一方法。讨论当前文档范围之外的应用程序所使用的方法。
In the remainder of this document, we will use the term "SAFI-x UPDATE" to refer to a BGP UPDATE message containing an MP_REACH_NLRI attribute or an MP_UNREACH_NLRI attribute ([RFC4760]) whose SAFI field contains the value x.
在本文档的其余部分中，我们将使用术语“SAFI-x更新”来指包含MP_REACH_NLRI属性或MP_UNREACH_NLRI属性（[RFC4760]）的BGP更新消息，其SAFI字段包含值x。
This document defines a BGP Optional Capabilities parameter ([RFC5492]) known as the Multiple Labels Capability.
本文档定义了BGP可选功能参数（[RFC5492]），称为多标签功能。
o Unless this Capability is sent on a given BGP session by both of that session's BGP speakers, a SAFI-4 or SAFI-128 UPDATE message sent on that session from either speaker MUST bind a prefix to only a single label and MUST use the encoding of Section 2.2.
o 除非该会话的两个BGP扬声器在给定BGP会话上发送此功能，否则从任一扬声器在该会话上发送的SAFI-4或SAFI-128更新消息必须仅将前缀绑定到单个标签，并且必须使用第2.2节的编码。
o If this Capability is sent by both BGP speakers on a given session, an UPDATE message on that session, from either speaker, MUST use the encoding of Section 2.3 and MAY bind a prefix to a sequence of more than one label.
o 如果该功能是由两个BGP发言者在给定会话上发送的，则来自任一发言者的该会话上的更新消息必须使用第2.3节的编码，并且可以将前缀绑定到多个标签的序列。
The encoding of the Multiple Labels Capability is specified in Section 2.1.
第2.1节规定了多标签功能的编码。
Procedures for explicitly withdrawing a label binding are given in Section 2.4. Procedures for changing the label(s) bound to a given prefix by a given node are given in Section 2.5.
第2.4节给出了明确撤销标签绑定的程序。第2.5节给出了更改由给定节点绑定到给定前缀的标签的步骤。
Procedures for propagating SAFI-4 and SAFI-128 UPDATEs are discussed in Section 3.
第3节讨论了传播SAFI-4和SAFI-128更新的程序。
When a BGP speaker installs and propagates a SAFI-4 or SAFI-128 UPDATE, and if it changes the value of the Network Address of Next Hop field, it must program its data plane appropriately. This is discussed in Section 4.
当BGP扬声器安装并传播SAFI-4或SAFI-128更新时，如果它更改了下一个跃点字段的网络地址值，则必须对其数据平面进行适当编程。第4节对此进行了讨论。
[RFC5492] defines the "Capabilities Optional Parameter". A BGP speaker can include a Capabilities Optional Parameter in a BGP OPEN message. The Capabilities Optional Parameter is a triple that includes a one-octet Capability Code, a one-octet Capability length, and a variable-length Capability Value.
[RFC5492]定义了“能力可选参数”。BGP扬声器可以在BGP OPEN消息中包含可选参数。Capabilities可选参数是一个三元组，包括一个八位字节能力代码、一个八位字节能力长度和一个可变长度能力值。
This document defines a Capability Code known as the Multiple Labels Capability code. IANA has assigned value 8 to this Capability Code. (This Capability Code is new to this document and does not appear in [RFC3107].)
本文档定义了称为多标签能力代码的能力代码。IANA已将值8分配给该能力代码。（此能力代码是本文档的新代码，未出现在[RFC3107]中。）
If a BGP speaker has not sent the Multiple Labels Capability in its BGP OPEN message on a particular BGP session, or if it has not received the Multiple Labels Capability in the BGP OPEN message from its peer on that BGP session, that BGP speaker MUST NOT send on that session any UPDATE message that binds more than one MPLS label to any given prefix. Further, when advertising the binding of a single label to a prefix, the BGP speaker MUST use the encoding specified in Section 2.2.
如果BGP扬声器在特定BGP会话中未在其BGP OPEN消息中发送多标签功能，或者在该BGP会话中未从其对等方接收到BGP OPEN消息中的多标签功能，BGP演讲者不得在该会话中发送将多个MPLS标签绑定到任何给定前缀的任何更新消息。此外，当广告将单个标签绑定到前缀时，BGP扬声器必须使用第2.2节中规定的编码。
The value field of the Multiple Labels Capability (shown in Figure 1) consists of one or more triples, where each triple consists of four octets. The first two octets of a triple specify an AFI value, the third octet specifies a SAFI value, and the fourth specifies a Count. If one of the triples is <AFI, SAFI, Count>, the Count is the maximum number of labels that the BGP speaker sending the Capability can process in a received UPDATE of the specified AFI/SAFI. If the Count is 255, then no limit has been placed on the number of labels that can be processed in a received UPDATE of the specified AFI/SAFI.
多标签功能的值字段（如图1所示）由一个或多个三元组组成，其中每个三元组由四个八位组组成。三元组的前两个八位组指定AFI值，第三个八位组指定SAFI值，第四个八位组指定计数。如果其中一个三元组为<AFI，SAFI，Count>，则Count是发送该功能的BGP扬声器在接收到的指定AFI/SAFI更新中可以处理的最大标签数。如果计数为255，则未对接收到的指定AFI/SAFI更新中可处理的标签数量进行限制。
Any implementation that sends a Multiple Labels Capability MUST be able to support at least two labels in the NLRI. However, there may be deployment scenarios in which a larger number of labels is needed.
任何发送多标签功能的实现必须能够在NLRI中支持至少两个标签。但是，可能存在需要更多标签的部署场景。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | SAFI | Count ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AFI | SAFI | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | SAFI | Count ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AFI | SAFI | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Value Field of Multiple Labels Capability
图1：多标签功能的值字段
If the Capability contains more than one triple with a given AFI/ SAFI, all but the first MUST be ignored.
如果功能包含一个以上具有给定AFI/SAFI的三元组，则必须忽略除第一个之外的所有三元组。
A triple of the form <AFI=x, SAFI=y, Count=0> or <AFI=x, SAFI=y, Count=1> MUST NOT be sent. If such a triple is received, it MUST be ignored.
不得发送形式为<AFI=x，SAFI=y，Count=0>或<AFI=x，SAFI=y，Count=1>的三元组。如果收到这样的三元组，则必须忽略它。
A Multiple Labels Capability whose length is not a multiple of four MUST be considered to be malformed.
长度不是四的倍数的多标签功能必须视为格式错误。
"Graceful Restart Mechanism for BGP" [RFC4724] describes a procedure that allows routes learned over a given BGP session to be maintained when the session fails and then restarts. This procedure requires the entire RIB to be transmitted when the session restarts. If the Multiple Labels Capability for a given AFI/SAFI was exchanged on the failed session but has not been exchanged on the restarted session, then any prefixes advertised in that AFI/SAFI with multiple labels MUST be explicitly withdrawn. Similarly, if the maximum label count (specified in the Capability for a given AFI/SAFI) is reduced, any prefixes advertised with more labels than are valid for the current session MUST be explicitly withdrawn.
“BGP的优雅重启机制”[RFC4724]描述了一个过程，该过程允许在给定BGP会话失败时维护通过该会话学习的路由，然后重新启动。此过程要求在会话重新启动时传输整个RIB。如果给定AFI/SAFI的多标签功能在失败的会话上交换，但在重新启动的会话上未交换，则必须显式撤回该AFI/SAFI中带有多个标签的任何前缀。类似地，如果最大标签计数（在给定AFI/SAFI的功能中指定）减少，则必须显式地撤回任何带有超过当前会话有效标签的前缀。
"Accelerated Routing Convergence for BGP Graceful Restart" [Enhanced-GR] describes another procedure that allows the routes learned over a given BGP session to be maintained when the session fails and then restarts. These procedures MUST NOT be applied if either of the following conditions hold:
“BGP优雅重启的加速路由收敛”[Enhanced GR]描述了另一个过程，该过程允许在给定BGP会话中学习的路由在会话失败后重新启动时保持。如果以下任一条件成立，则不得采用这些程序：
o The Multiple Labels Capability for a given AFI/SAFI had been exchanged prior to the restart but has not been exchanged on the restarted session.
o 给定AFI/SAFI的多标签功能在重新启动之前已交换，但在重新启动的会话上尚未交换。
o The Multiple Labels Capability for a given AFI/SAFI had been exchanged with a given Count prior to the restart but have been exchanged with a smaller count on the restarted session.
o 给定AFI/SAFI的多标签功能在重新启动前已与给定计数交换，但在重新启动的会话中已与较小计数交换。
If either of these conditions hold, the complete set of routes for the given AFI/SAFI MUST be exchanged.
如果上述任一条件成立，则必须交换给定AFI/SAFI的整套路线。
If a BGP OPEN message contains multiple copies of the Multiple Labels Capability, only the first copy is significant; subsequent copies MUST be ignored.
如果BGP OPEN消息包含多个标签功能的多个副本，则只有第一个副本有效；必须忽略后续副本。
If (a) a BGP speaker has sent the Multiple Labels Capability in its BGP OPEN message for a particular BGP session, (b) it has received the Multiple Labels Capability in its peer's BGP OPEN message for that session, and (c) both Capabilities specify AFI/SAFI x/y, then when using an UPDATE of AFI x and SAFI y to advertise the binding of a label or sequence of labels to a given prefix, the BGP speaker MUST use the encoding of Section 2.3. This encoding MUST be used even if only one label is being bound to a given prefix.
如果（a）某个BGP演讲者在其BGP OPEN消息中为特定BGP会话发送了多标签功能，（b）该演讲者在其对等方的BGP OPEN消息中为该会话接收了多标签功能，以及（c）两种功能都指定了AFI/SAFI x/y，然后，当使用AFI x和SAFI y的更新来公布标签或标签序列与给定前缀的绑定时，BGP演讲者必须使用第2.3节的编码。即使只有一个标签绑定到给定前缀，也必须使用此编码。
If both BGP speakers of a given BGP session have sent the Multiple Labels Capability, but AFI/SAFI x/y has not been specified in both Capabilities, then UPDATEs of AFI/SAFI x/y on that session MUST use the encoding of Section 2.2, and such UPDATEs can only bind one label to a prefix.
如果给定BGP会话的两个BGP扬声器都发送了多标签功能，但两个功能中均未指定AFI/SAFI x/y，则该会话上的AFI/SAFI x/y更新必须使用第2.2节的编码，并且此类更新只能将一个标签绑定到前缀。
A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a given prefix than its peer is capable of receiving, as specified in the Multiple Labels Capability sent by that peer. If a BGP speaker receives an UPDATE that binds more labels to a given prefix than the number of labels the BGP speaker is prepared to receive (as announced in its Multiple Labels Capability), the BGP speaker MUST apply the "treat-as-withdraw" strategy of [RFC7606] to that UPDATE.
BGP演讲者不应发送将更多标签绑定到给定前缀的更新，而不是其对等方能够接收的，如该对等方发送的多标签功能中所规定。如果BGP扬声器接收到一个更新，该更新将更多的标签绑定到一个给定前缀，超过BGP扬声器准备接收的标签数量（在其多标签功能中宣布），则BGP扬声器必须对该更新应用[RFC7606]的“视为撤回”策略。
Notwithstanding the number of labels that a BGP speaker has claimed to be able to receive, its peer MUST NOT attempt to send more labels than can be properly encoded in the NLRI field of the MP_REACH_NLRI attribute. Please note that there is only a limited amount of space in the NLRI field for labels:
尽管BGP说话者声称能够接收的标签数量很多，但其对等方不得尝试发送超出MP_REACH_NLRI属性NLRI字段中正确编码的标签数量。请注意，NLRI字段中标签的空间有限：
o per [RFC4760], the size of this field is limited to 255 bits (not 255 octets), including the number of bits in the prefix;
o 根据[RFC4760]，此字段的大小限制为255位（不是255个八位字节），包括前缀中的位数；
o in a SAFI-128 UPDATE, the prefix is at least 64 bits long and may be as long as 192 bits (e.g., in a VPN-IPv6 host route).
o 在SAFI-128更新中，前缀的长度至少为64位，并且可以长达192位（例如，在VPN-IPv6主机路由中）。
If the Multiple Labels Capability has not been both sent and received on a given BGP session, then in a BGP UPDATE on that session whose MP_REACH_NLRI attribute contains one of the AFI/SAFI combinations specified in Section 2, the NLRI field is encoded as shown in Figure 2:
如果在给定BGP会话上未发送和接收多标签功能，则在MP_REACH_NLRI属性包含第2节中指定的AFI/SAFI组合之一的会话上的BGP更新中，NLRI字段编码如图2所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Label |Rsrv |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Label |Rsrv |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NLRI with One Label
图2：带有一个标签的NLRI
- Length:
- 长度：
The Length field consists of a single octet. It specifies the length in bits of the remainder of the NLRI field.
长度字段由一个八位字节组成。它以位为单位指定NLRI字段其余部分的长度。
Note that the length will always be the sum of 20 (number of bits in Label field), plus 3 (number of bits in Rsrv field), plus 1 (number of bits in S field), plus the length in bits of the prefix.
请注意，长度始终为20（标签字段中的位数）加上3（Rsrv字段中的位数）加上1（S字段中的位数）加上前缀的长度（位数）。
In an MP_REACH_NLRI attribute whose AFI/SAFI is 1/4, the prefix length will be 32 bits or less. In an MP_REACH_NLRI attribute whose AFI/SAFI is 2/4, the prefix length will be 128 bits or less. In an MP_REACH_NLRI attribute whose SAFI is 128, the prefix will be 96 bits or less if the AFI is 1 and will be 192 bits or less if the AFI is 2.
在AFI/SAFI为1/4的MP_REACH_NLRI属性中，前缀长度将小于等于32位。在AFI/SAFI为2/4的MP_REACH_NLRI属性中，前缀长度将小于等于128位。在SAFI为128的MP_REACH_NLRI属性中，如果AFI为1，前缀将为96位或更少；如果AFI为2，前缀将为192位或更少。
As specified in [RFC4760], the actual length of the NLRI field will be the number of bits specified in the Length field, rounded up to the nearest integral number of octets.
如[RFC4760]所述，NLRI字段的实际长度将是长度字段中指定的位数，四舍五入到最接近的八位字节整数。
- Label:
- 标签：
The Label field is a 20-bit field containing an MPLS label value (see [RFC3032]).
标签字段是包含MPLS标签值的20位字段（请参阅[RFC3032]）。
- Rsrv:
- Rsrv：
This 3-bit field SHOULD be set to zero on transmission and MUST be ignored on reception.
此3位字段在传输时应设置为零，在接收时必须忽略。
- S:
- S:
This 1-bit field MUST be set to one on transmission and MUST be ignored on reception.
此1位字段在传输时必须设置为1，在接收时必须忽略。
Note that the UPDATE message not only advertises the binding between the prefix and the label, it also advertises a path to the prefix via the node identified in the Network Address of Next Hop field of the MP_REACH_NLRI attribute.
注意，更新消息不仅播发前缀和标签之间的绑定，还通过MP_REACH_NLRI属性的下一跳网络地址字段中标识的节点播发指向前缀的路径。
[RFC3107] requires that if only a single label is bound to a prefix, the S bit must be set. If the S bit is not set, [RFC3107] specifies that additional labels will appear in the NLRI. However, some implementations assume that the NLRI will contain only a single label and thus do not check the setting of the S bit. The procedures specified in the current document will interwork with such implementations. As long as the Multiple Labels Capability is not
[RFC3107]要求如果只有一个标签绑定到前缀，则必须设置S位。如果未设置S位，[RFC3107]指定附加标签将出现在NLRI中。然而，一些实现假设NLRI将只包含一个标签，因此不检查S位的设置。当前文件中规定的程序将与此类实施相互配合。只要不使用多标签功能
sent and received by both BGP speakers on a given BGP session, this document REQUIRES that only one label be specified in the NLRI, that the S bit be set on transmission, and that it be ignored on reception.
在给定的BGP会话中由两个BGP扬声器发送和接收，本文档要求NLRI中只指定一个标签，传输时设置S位，接收时忽略S位。
If the procedures of [RFC7911] are being used, a four-octet "path identifier" (as defined in Section 3 of [RFC7911]) is part of the NLRI and precedes the Length field.
如果使用[RFC7911]中的程序，则四个八位字节的“路径标识符”（如[RFC7911]第3节所定义）是NLRI的一部分，位于长度字段之前。
If the Multiple Labels Capability has been both sent and received on a given BGP session, then in a BGP UPDATE on that session whose MP_REACH_NLRI attribute contains one of the AFI/SAFI combinations specified in Section 2, the NLRI field is encoded as shown in Figure 3:
如果在给定BGP会话上发送和接收了多标签功能，则在MP_REACH_NLRI属性包含第2节中指定的AFI/SAFI组合之一的会话上的BGP更新中，NLRI字段编码如图3所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |Rsrv |S~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Label |Rsrv |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |Rsrv |S~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Label |Rsrv |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NLRI with Multiple Labels
图3：具有多个标签的NLRI
- Length:
- 长度：
The Length field consists of a single octet. It specifies the length in bits of the remainder of the NLRI field.
长度字段由一个八位字节组成。它以位为单位指定NLRI字段其余部分的长度。
Note that for each label, the length is increased by 24 bits (20 bits in the Label field, plus 3 bits in the Rsrv field, plus 1 S bit).
请注意，对于每个标签，长度增加24位（标签字段中增加20位，Rsrv字段中增加3位，再增加1s位）。
In an MP_REACH_NLRI attribute whose AFI/SAFI is 1/4, the prefix length will be 32 bits or less. In an MP_REACH_NLRI attribute whose AFI/SAFI is 2/4, the prefix length will be 128 bits or less. In an MP_REACH_NLRI attribute whose SAFI is 128, the prefix will be 96 bits or less if the AFI is 1 and will be 192 bits or less if the AFI is 2.
在AFI/SAFI为1/4的MP_REACH_NLRI属性中，前缀长度将小于等于32位。在AFI/SAFI为2/4的MP_REACH_NLRI属性中，前缀长度将小于等于128位。在SAFI为128的MP_REACH_NLRI属性中，如果AFI为1，前缀将为96位或更少；如果AFI为2，前缀将为192位或更少。
As specified in [RFC4760], the actual length of the NLRI field will be the number of bits specified in the Length field rounded up to the nearest integral number of octets.
如[RFC4760]所述，NLRI字段的实际长度将是长度字段中指定的位数，四舍五入到最接近的八位字节整数。
- Label:
- 标签：
The Label field is a 20-bit field containing an MPLS label value (see [RFC3032]).
标签字段是包含MPLS标签值的20位字段（请参阅[RFC3032]）。
- Rsrv:
- Rsrv：
This 3-bit field SHOULD be set to zero on transmission and MUST be ignored on reception.
此3位字段在传输时应设置为零，在接收时必须忽略。
- S:
- S:
In all labels except the last (i.e., in all labels except the one immediately preceding the prefix), the S bit MUST be 0. In the last label, the S bit MUST be 1.
在除最后一个标签外的所有标签中（即，除前缀前面的标签外的所有标签中），S位必须为0。在最后一个标签中，S位必须为1。
Note that failure to set the S bit in the last label will make it impossible to parse the NLRI correctly. See Section 3, paragraph j of [RFC7606] for a discussion of error handling when the NLRI cannot be parsed.
请注意，如果未能在最后一个标签中设置S位，则无法正确解析NLRI。有关无法解析NLRI时的错误处理的讨论，请参见[RFC7606]第3节第j段。
Note that the UPDATE message not only advertises the binding between the prefix and the labels, it also advertises a path to the prefix via the node identified in the Next Hop field of the MP_REACH_NLRI attribute.
注意，更新消息不仅播发前缀和标签之间的绑定，还通过MP_REACH_NLRI属性的下一跳字段中标识的节点播发指向前缀的路径。
If the procedures of [RFC7911] are being used, a four-octet "path identifier" (as defined in Section 3 of [RFC7911]) is part of the NLRI and precedes the Length field.
如果使用[RFC7911]中的程序，则四个八位字节的“路径标识符”（如[RFC7911]第3节所定义）是NLRI的一部分，位于长度字段之前。
Suppose a BGP speaker has announced, on a given BGP session, the binding of a given label or sequence of labels to a given prefix. Suppose it now wishes to withdraw that binding. To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI attribute. The NLRI field of this attribute is encoded as follows:
假设BGP演讲者在给定的BGP会话上宣布将给定标签或标签序列绑定到给定前缀。假设它现在希望撤销该约束。为此，它可以发送带有MP_UNREACH_NLRI属性的BGP更新消息。此属性的NLRI字段编码如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Compatibility |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Compatibility |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NLRI for Withdrawal
图4：提取的NLRI
Upon transmission, the Compatibility field SHOULD be set to 0x800000. Upon reception, the value of the Compatibility field MUST be ignored.
传输时，兼容性字段应设置为0x800000。接收时，必须忽略兼容性字段的值。
This encoding is used for explicitly withdrawing the binding (on a given BGP session) between the specified prefix and whatever label or sequence of labels had previously been bound by the procedures of this document to that prefix on the given session. This encoding is used whether or not the Multiple Labels Capability has been sent or received on the session. Note that label/prefix bindings that were not advertised on the given session cannot be withdrawn by this method. (However, if the bindings were advertised on a previous session with the same peer, and the current session is the result of a "graceful restart" ([RFC4724]) of the previous session, then this withdrawal method may be used.)
此编码用于显式撤销指定前缀和任何标签或标签序列之间的绑定（在给定BGP会话上），这些标签或标签序列之前已通过本文档的过程绑定到给定会话上的该前缀。无论会话上是否发送或接收了多标签功能，都将使用此编码。请注意，此方法无法撤消给定会话上未播发的标签/前缀绑定。（但是，如果绑定是在具有相同对等方的前一个会话上播发的，并且当前会话是前一个会话的“正常重新启动”（[RFC4724]）的结果，则可以使用此退出方法。）
When using an MP_UNREACH_NLRI attribute to withdraw a route whose NLRI was previously specified in an MP_REACH_NLRI attribute, the lengths and values of the respective prefixes must match, and the respective AFI/SAFIs must match. If the procedures of [RFC7911] are being used, the respective values of the "path identifier" fields must match as well. Note that the prefix length is not the same as the NLRI length; to determine the prefix length of a prefix in an MP_UNREACH_NLRI, the length of the Compatibility field must be subtracted from the length of the NLRI.
当使用MP_UNREACH_NLRI属性提取其NLRI先前在MP_REACH_NLRI属性中指定的路由时，各个前缀的长度和值必须匹配，并且各个AFI/SAFI必须匹配。如果使用[RFC7911]的过程，“路径标识符”字段的相应值也必须匹配。请注意，前缀长度与NLRI长度不同；要确定MP_UNREACH_NLRI中前缀的前缀长度，必须从NLRI的长度中减去兼容性字段的长度。
An explicit withdrawal in a SAFI-x UPDATE on a given BGP session not only withdraws the binding between the prefix and the label(s), it also withdraws the path to that prefix that was previously advertised in a SAFI-x UPDATE on that session.
在给定BGP会话上的SAFI-x更新中显式撤销不仅撤销前缀和标签之间的绑定，还撤销先前在该会话上的SAFI-x更新中公布的指向该前缀的路径。
[RFC3107] made it possible to specify a particular label value in the Compatibility field. However, the functionality that required the presence of a particular label value (or sequence of label values) was never implemented, and that functionality is not present in the current document. Hence, the value of this field is of no significance; there is never any reason for this field to contain a label value or a sequence of label values.
[RFC3107]可以在兼容性字段中指定特定的标签值。但是，要求存在特定标签值（或标签值序列）的功能从未实现，并且当前文档中不存在该功能。因此，该字段的值没有意义；此字段没有任何理由包含标签值或标签值序列。
[RFC3107] also made it possible to withdraw a binding without specifying the label explicitly, by setting the Compatibility field to 0x800000. However, some implementations set it to 0x000000. In order to ensure backwards compatibility, it is RECOMMENDED by this document that the Compatibility field be set to 0x800000, but it is REQUIRED that it be ignored upon reception.
[RFC3107]通过将兼容性字段设置为0x800000，还可以在不明确指定标签的情况下撤消绑定。但是，有些实现将其设置为0x000000。为了确保向后兼容性，本文档建议将兼容性字段设置为0x800000，但要求在接收时忽略该字段。
Suppose a BGP speaker, S1, has received on a given BGP session, a SAFI-4 or SAFI-128 UPDATE, U1, that specifies label (or sequence of labels) L1, prefix P, and next hop N1. As specified above, this indicates that label (or sequence of labels) L1 is bound to prefix P at node N1. Suppose that S1 now receives, on the same session, an UPDATE, U2, of the same AFI/SAFI, that specifies label (or sequence of labels) L2, prefix P, and the same next hop, N1.
假设BGP扬声器S1在给定BGP会话上接收到SAFI-4或SAFI-128更新U1，该更新指定标签（或标签序列）L1、前缀P和下一跳N1。如上所述，这表示标签（或标签序列）L1绑定到节点N1处的前缀P。假设S1现在在同一会话上接收到同一AFI/SAFI的更新U2，该更新指定标签（或标签序列）L2，前缀P和同一下一跳N1。
o If [RFC7911] is not being used, UPDATE U2 MUST be interpreted as meaning that L2 is now bound to P at N1 and that L1 is no longer bound to P at N1. That is, the UPDATE U1 is implicitly withdrawn and is replaced by UPDATE U2.
o 如果未使用[RFC7911]，则必须将更新U2解释为L2现在绑定到N1处的P，而L1不再绑定到N1处的P。即，隐式地撤回更新U1，并由更新U2替换。
o Suppose that [RFC7911] is being used, that UPDATE U1 has Path Identifier I1, and that UPDATE U2 has Path Identifier I2.
o 假设正在使用[RFC7911]，更新U1具有路径标识符I1，更新U2具有路径标识符I2。
* If I1 is the same as I2, UPDATE U2 MUST be interpreted as meaning that L2 is now bound to P at N1 and that L1 is no longer bound to P at N1. UPDATE U1 is implicitly withdrawn.
* 如果I1与I2相同，则更新U2必须解释为L2现在绑定到N1处的P，而L1不再绑定到N1处的P。更新U1被隐式撤回。
* If I1 is not the same as I2, U2 MUST be interpreted as meaning that L2 is now bound to P at N1, but U2 MUST NOT be interpreted as meaning that L1 is no longer bound to P at N1. Under certain conditions (specification of which is outside the scope of this document), S1 may choose to load-balance traffic between the path represented by U1 and the path represented by U2. To send traffic on the path represented by U1, S1 uses the label(s) advertised in U1; to send traffic on the path represented by U2, S1 uses the label(s) advertised in U2. (Although these two paths have the same next hop, one must suppose that they diverge further downstream.)
* 如果I1与I2不同，则U2必须解释为L2现在与N1处的P绑定，但U2不得解释为L1不再与N1处的P绑定。在某些条件下（其规范不在本文件范围内），S1可以选择在U1表示的路径和U2表示的路径之间进行负载平衡。为了在由U1表示的路径上发送通信量，S1使用在U1中通告的标签；要在U2表示的路径上发送流量，S1使用U2中公布的标签。（虽然这两条路径具有相同的下一跳，但必须假设它们在下游进一步分叉。）
Suppose a BGP speaker, S1, has received, on a given BGP session, a SAFI-4 or SAFI-128 UPDATE that specifies label L1, prefix P, and next hop N1. Suppose that S1 now receives, on a different BGP session, an UPDATE of the same AFI/SAFI, that specifies label L2, prefix P, and the same next hop, N1. BGP speaker S1 SHOULD treat this as an indication that N1 has at least two paths to P, and S1 MAY use this fact to do load-balancing of any traffic that it has to send to P.
假设BGP扬声器S1在给定BGP会话上接收到SAFI-4或SAFI-128更新，该更新指定标签L1、前缀P和下一跳N1。假设S1现在在不同的BGP会话上接收到相同AFI/SAFI的更新，该更新指定标签L2、前缀P和相同的下一跳N1。BGP扬声器S1应将此视为N1至少有两条到P的路径的指示，S1可利用此事实对其必须发送到P的任何通信量进行负载平衡。
Note that this section discusses only the case where two UPDATEs have the same next hop. Procedures for the case where two UPDATEs have different next hops are adequately described in [RFC4271].
请注意，本节仅讨论两个更新具有相同下一跳的情况。[RFC4271]中充分描述了两个更新具有不同下一跳的情况下的程序。
Suppose a BGP speaker has received two SAFI-4 UPDATEs specifying the same Prefix and that either:
假设BGP扬声器已收到两个指定相同前缀的SAFI-4更新，并且：
o the two UPDATEs are received on different BGP sessions; or
o 这两个更新在不同的BGP会话上接收；或
o the two UPDATEs are received on the same session, add-paths is used on that session, and the NLRIs of the two UPDATEs have different path identifiers.
o 两个更新在同一个会话上接收，添加路径在该会话上使用，并且两个更新的NLRI具有不同的路径标识符。
These two routes MUST be considered to be comparable, even if they specify different labels. Thus, the BGP best-path selection procedures (see Section 9.1 of [RFC4271]) are applied to select one of them as the better path. If the procedures of [RFC7911] are not being used on a particular BGP session, only the best path is propagated on that session. If the procedures of [RFC7911] are being used on a particular BGP session, then both paths may be propagated on that session, though with different path identifiers.
这两条路线必须被视为具有可比性，即使它们指定了不同的标签。因此，BGP最佳路径选择程序（见[RFC4271]第9.1节）用于选择其中一个作为更好的路径。如果[RFC7911]的过程未在特定BGP会话上使用，则仅在该会话上传播最佳路径。如果[RFC7911]的过程正在特定BGP会话上使用，则两条路径可以在该会话上传播，尽管路径标识符不同。
The same applies to SAFI-128 routes.
这同样适用于SAFI-128路线。
When a SAFI-4 or SAFI-128 route is propagated, if the Network Address of Next Hop field is left unchanged, the Label field(s) MUST also be left unchanged.
传播SAFI-4或SAFI-128路由时，如果下一跳字段的网络地址保持不变，则标签字段也必须保持不变。
Note that a given route MUST NOT be propagated to a given peer if the route's NLRI has multiple labels, but the Multiple Labels Capability was not negotiated with the peer. Similarly, a given route MUST NOT be propagated to a given peer if the route's NLRI has more labels
请注意，如果路由的NLRI具有多个标签，但多标签功能未与对等方协商，则不得将给定路由传播到给定对等方。类似地，如果路由的NLRI具有更多标签，则不得将给定路由传播到给定对等方
than the peer has announced (through its Multiple Labels Capability) that it can handle. In either case, if a previous route with the same AFI, SAFI, and prefix (but with fewer labels) has already been propagated to the peer, that route MUST be withdrawn from that peer using the procedure specified in Section 2.4.
而对等方（通过其多标签功能）宣布它可以处理。在任何一种情况下，如果具有相同AFI、SAFI和前缀（但标签较少）的先前路由已经传播到对等方，则必须使用第2.4节中规定的程序从该对等方撤回该路由。
If the Network Address of Next Hop field is changed before a SAFI-4 or SAFI-128 route is propagated, the Label field(s) of the propagated route MUST contain the label(s) that is (are) bound to the prefix at the new next hop.
如果在传播SAFI-4或SAFI-128路由之前更改了下一跳的网络地址字段，则传播路由的标签字段必须包含绑定到新下一跳前缀的标签。
Suppose BGP speaker S1 has received an UPDATE that binds a particular sequence of one or more labels to a particular prefix. If S1 chooses to propagate this route after changing its next hop, S1 may change the label in any of the following ways, depending upon local policy:
假设BGP扬声器S1已接收到将一个或多个标签的特定序列绑定到特定前缀的更新。如果S1在更改下一跳后选择传播此路由，则S1可根据本地策略，通过以下任一方式更改标签：
o A single label may be replaced by a single label of the same or different value.
o 单个标签可替换为具有相同或不同值的单个标签。
o A sequence of multiple labels may be replaced by a single label.
o 多个标签的序列可以由单个标签替换。
o A single label may be replaced by a sequence of multiple labels.
o 单个标签可以由一系列多个标签替换。
o A sequence of multiple labels may be replaced by a sequence of multiple labels; the number of labels may be left the same or may be changed.
o 多个标签的序列可以被多个标签的序列替换；标签的数量可以保持不变，也可以更改。
Of course, when deciding whether to propagate, to a given BGP peer, an UPDATE binding a sequence of more than one label, a BGP speaker must attend to the information provided by the Multiple Labels Capability (see Section 2.1). A BGP speaker MUST NOT send multiple labels to a peer with which it has not exchanged the Multiple Labels Capability and MUST NOT send more labels to a given peer than the peer has announced (via the Multiple Labels Capability) than it can handle.
当然，在决定是否向给定BGP对等方传播绑定多个标签序列的更新时，BGP演讲者必须注意多标签功能提供的信息（参见第2.1节）。BGP演讲者不得向未与之交换多标签功能的对等方发送多个标签，也不得向给定对等方发送超出其所能处理范围的标签（通过多标签功能）。
It is possible that a BGP speaker's local policy will tell it to encode N labels in a given route's NLRI before propagating the route, but that one of the BGP speaker's peers cannot handle N labels in the NLRI. In this case, the BGP speaker has two choices:
BGP演讲者的本地策略可能会告诉它在传播路由之前对给定路由的NLRI中的N个标签进行编码，但BGP演讲者的一个对等方无法处理NLRI中的N个标签。在这种情况下，BGP扬声器有两种选择：
o It can propagate the route to the given peer with fewer than N labels; however, whether this makes sense, and if so, how to choose the labels, is also a matter of local policy.
o 它可以将路由传播到具有少于N个标签的给定对等方；然而，这是否有意义，如果有，如何选择标签，也是当地政策的问题。
o It can decide not to propagate the route to the given peer. In that case, if a previous route with the same AFI, SAFI, and prefix (but with fewer labels) has already been propagated to that peer, that route MUST be withdrawn from that peer using the procedure of Section 2.4.
o 它可以决定不将路由传播到给定的对等方。在这种情况下，如果具有相同AFI、SAFI和前缀（但标签较少）的先前路由已经传播到该对等方，则必须使用第2.4节的程序从该对等方撤回该路由。
In the following, we will use the phrase "node S tunnels packet P to node N", where packet P is an MPLS packet. By this phrase, we mean that node S encapsulates packet P and causes packet P to be delivered to node N in such a way that P's label stack before encapsulation will be seen unchanged by N but will not be seen by the nodes (if any) between S and N.
在下面，我们将使用短语“节点S隧道数据包P到节点N”，其中数据包P是MPLS数据包。通过这个短语，我们的意思是节点S封装数据包P并使数据包P以这样的方式传递到节点N，即封装前的P的标签堆栈将被N看到，但不会被S和N之间的节点（如果有的话）看到。
If the tunnel is a Label Switched Path (LSP), encapsulating the packet may be as simple as pushing on another MPLS label. If node N is a Layer 2 adjacency of node S, a Layer 2 encapsulation may be all that is needed. Other sorts of tunnels (e.g., IP tunnels, GRE tunnels, UDP tunnels) may also be used, depending upon the particular deployment scenario.
如果隧道是标签交换路径（LSP），封装数据包可能与推送另一个MPLS标签一样简单。如果节点N是节点S的第2层邻接，则可能只需要第2层封装。根据特定的部署场景，还可以使用其他种类的隧道（例如，IP隧道、GRE隧道、UDP隧道）。
Suppose BGP speaker S1 receives a SAFI-4 or SAFI-128 BGP UPDATE with an MP_REACH_NLRI specifying label L1, prefix P, and next hop N1, and suppose S1 installs this route as its (or one of its) best path(s) towards P. And suppose S1 propagates this route after changing the next hop to itself and changing the label to L2. Suppose further that S1 receives an MPLS data packet and, in the process of forwarding that MPLS data packet, S1 sees label L2 rise to the top of the packet's label stack. Then, to forward the packet further, S1 must replace L2 with L1 as the top entry in the packet's label stack, and S1 must then tunnel the packet to N1.
假设BGP扬声器S1接收到SAFI-4或SAFI-128 BGP更新，MP_REACH_NLRI指定标签L1、前缀P和下一跳N1，假设S1安装此路由作为其（或其）通向P的最佳路径之一。假设S1在将下一跳更改为自身并将标签更改为L2后传播此路由。进一步假设S1接收到MPLS数据分组，并且在转发该MPLS数据分组的过程中，S1看到标签L2上升到分组的标签栈的顶部。然后，为了进一步转发分组，S1必须用L1替换L2作为分组标签堆栈中的顶部条目，并且S1随后必须将分组隧道到N1。
Suppose that the route received by S1 specified not a single label, but a sequence of k labels <L11, L12, ..., L1k> where L11 is the first label appearing in the NLRI, and L1k is the last. And suppose again that S1 propagates this route after changing the next hop to itself and changing the Label field to the single label L2. Suppose further that S1 receives an MPLS data packet, and in the process of forwarding that MPLS data packet, S1 sees label L2 rise to the top of the packet's label stack. In this case, instead of simply replacing L2 with L1, S1 removes L2 from the top of the label stack and then pushes labels L1k through L11 onto the label stack such that L11 is now at the top of the label stack. Then, S1 must tunnel the packet to N1. (Note that L1k will not be at the bottom of the packet's label stack and hence will not have the "bottom of stack" bit set unless L2 had previously been at the bottom of the packet's label stack.)
假设S1接收的路由指定的不是单个标签，而是一个k标签序列<L11，L12，…，L1k>，其中L11是NLRI中出现的第一个标签，L1k是最后一个标签。并且再次假设S1在将下一跳更改为自身并将标签字段更改为单个标签L2之后传播该路由。进一步假设S1接收到MPLS数据分组，并且在转发该MPLS数据分组的过程中，S1看到标签L2上升到分组的标签栈的顶部。在这种情况下，S1不是简单地用L1替换L2，而是从标签堆栈的顶部移除L2，然后将标签L1k到L11推送到标签堆栈上，这样L11现在位于标签堆栈的顶部。然后，S1必须通过隧道将数据包传输到N1。（请注意，L1k不会位于数据包标签堆栈的底部，因此不会设置“堆栈底部”位，除非L2以前位于数据包标签堆栈的底部。）
The above paragraph assumes that when S1 propagates a SAFI-4 or SAFI-128 route after setting the next hop to itself, it replaces the label or labels specified in the NLRI of that route with a single label. However, it is also possible, as determined by local policy, for a BGP speaker to specify multiple labels when it propagates a SAFI-4 or SAFI-128 route after setting the next hop to itself.
上述段落假设，当S1在将下一跳设置为自身后传播SAFI-4或SAFI-128路由时，它将用单个标签替换该路由NLRI中指定的一个或多个标签。但是，根据本地策略的确定，BGP演讲者在将下一跳设置为自身后传播SAFI-4或SAFI-128路由时，也可以指定多个标签。
Suppose, for example, that S1 supports context labels ([RFC5331]). Let L21 be a context label supported by S1, and let L22 be a label that is in the label space identified (at S1) by L21. Suppose S1 receives a SAFI-4 or SAFI-128 UPDATE whose prefix is P, whose Label field is <L11, L12, ..., L1k> and whose next hop is N1. Before propagating the UPDATE, S1 may set the next hop to itself (by replacing N1 with S1) and may replace the label stack <L11, L12, ..., L1k> with the pair of labels <L21, L22>.
例如，假设S1支持上下文标签（[RFC5331]）。设L21为S1支持的上下文标签，设L22为L21标识的标签空间（S1处）中的标签。假设S1接收到前缀为P的SAFI-4或SAFI-128更新，其标签字段为<L11，L12，…，L1k>，其下一跳为N1。在传播更新之前，S1可以将下一跳设置为自身（通过将N1替换为S1），并且可以将标签堆栈<L11、L12、…、L1k>替换为标签对<L21、L22>。
In this case, if S1 receives an MPLS data packet whose top label is L21 and whose second label is L22, S1 will remove both L21 and L22 from the label stack and replace them with <L11, L12, ..., L1k>. Note that the fact that L21 is a context label is known only to S1; other BGP speakers do not know how S1 will interpret L21 (or L22).
在这种情况下，如果S1接收到一个MPLS数据包，其顶部标签为L21，第二个标签为L22，则S1将从标签堆栈中删除L21和L22，并将其替换为<L11，L12，…，L1k>。注意，L21是上下文标签的事实只有S1知道；其他BGP演讲者不知道S1将如何解释L21（或L22）。
The ability to replace one or more labels by one or more labels can provide great flexibility, but it must be done carefully. Let's suppose again that S1 receives an UPDATE that specifies prefix P, label stack <L11, L12, ..., L1k>, and next hop N1. And suppose that S1 propagates this UPDATE to BGP speaker S2 after setting next hop self and after replacing the Label field with <L21, L22, ..., L2k>. Finally, suppose that S1 programs its data plane so that when it processes a received MPLS packet whose top label is L21, it replaces L21 with <L11, L12, ..., L1k> and then tunnels the packet to N1.
用一个或多个标签替换一个或多个标签的功能可以提供很大的灵活性，但必须小心操作。让我们再次假设S1接收到一个更新，该更新指定前缀P、标签堆栈<L11、L12、…、L1k>和下一跳N1。假设S1在设置下一跳self并用<L21，L22，…，L2k>替换标签字段后，将此更新传播到BGP扬声器S2。最后，假设S1对其数据平面进行编程，以便当其处理接收到的顶部标签为L21的MPLS分组时，它用<L11，L12，…，L1k>替换L21，然后将分组隧道到N1。
In this case, BGP speaker S2 will have received a route with prefix P, Label field <L21, L22, ..., L2k>, and next hop S1. If S2 decides to forward an IP packet according to this route, it will push <L21, L22, ..., L2k> onto the packet's label stack and tunnel the packet to S1. S1 will replace L21 with <L11, L12, ..., L1k> and will tunnel the packet to N1. N1 will receive the packet with the following label stack: <L11, L12, ..., L1k, L22, ..., L2k>. While this may be useful in certain scenarios, it may provide unintended results in other scenarios.
在这种情况下，BGP扬声器S2将接收到带有前缀P、标签字段<L21、L22、…、L2k>和下一跳S1的路由。如果S2决定根据此路由转发IP数据包，它将<L21，L22，…，L2k>推送到数据包的标签堆栈上，并将数据包隧道传输到S1。S1将用<L11，L12，…，L1k>替换L21，并将数据包隧道到N1。N1将接收具有以下标签堆栈的数据包：<L11、L12、…、L1k、L22、…、L2k>。虽然这在某些场景中可能有用，但在其他场景中可能会产生意外结果。
Procedures for choosing, setting up, maintaining, or determining the liveness of a particular tunnel or type of tunnel are outside the scope of this document.
选择、设置、维护或确定特定隧道或隧道类型的活动性的程序不在本文件范围内。
When pushing labels onto a packet's label stack, the Time-to-Live (TTL) field ([RFC3032], [RFC3443]) and the Traffic Class (TC) field ([RFC3032], [RFC5462]) of each label stack entry must, of course, be set. This document does not specify any set of rules for setting these fields; that is a matter of local policy.
将标签推送到数据包的标签堆栈上时，当然必须设置每个标签堆栈条目的生存时间（TTL）字段（[RFC3032]、[RFC3443]）和流量类别（TC）字段（[RFC3032]、[RFC5462]）。本文档未指定设置这些字段的任何规则集；这是当地政策的问题。
This document does not specify any new rules for processing the label stack of an incoming data packet.
本文档没有为处理传入数据包的标签堆栈指定任何新规则。
It is a matter of local policy whether SAFI-4 routes can be used as the basis for forwarding IP packets or whether SAFI-4 routes can only be used for forwarding MPLS packets. If BGP speaker S1 is forwarding IP packets according to SAFI-4 routes, then consider an IP packet with destination address D, such that P is the "longest prefix match" for D from among the routes that are being used to forward IP packets. And suppose the packet is being forwarded according to a SAFI-4 route whose prefix is P, whose next hop is N1 and whose sequence of labels is L1. To forward the packet according to this route, S1 must create a label stack for the packet, push on the sequence of labels L1, and then tunnel the packet to N1.
SAFI-4路由是否可以用作转发IP数据包的基础，或者SAFI-4路由是否只能用于转发MPLS数据包，这是本地政策的问题。如果BGP扬声器S1根据SAFI4路由转发IP分组，则考虑具有目的地址D的IP分组，使得P是用于转发IP分组的路由中的D的“最长前缀匹配”。并且假设分组根据SAFI-4路由转发，其前缀是P，其下一跳是N1，其标签序列是L1。要根据此路由转发数据包，S1必须为数据包创建标签堆栈，推送标签序列L1，然后将数据包隧道到N1。
It is possible that a BGP speaker will receive both a SAFI-1 route for prefix P and a SAFI-4 route for prefix P. Different implementations treat this situation in different ways.
BGP扬声器可能同时接收前缀P的SAFI-1路由和前缀P的SAFI-4路由。不同的实现以不同的方式处理这种情况。
For example, some implementations may regard SAFI-1 routes and SAFI-4 routes as completely independent and may treat them in a "ships in the night" fashion. In this case, best-path selection for the two SAFIs is independent, and there will be a best SAFI-1 route to P as well as a best SAFI-4 route to P. Which packets get forwarded according to the routes of which SAFI is then a matter of local policy.
例如，一些实现可能将SAFI-1路由和SAFI-4路由视为完全独立的，并可能以“夜间船舶”的方式处理它们。在这种情况下，两个SAFI的最佳路径选择是独立的，并且将存在到P的最佳SAFI-1路由以及到P的最佳SAFI-4路由。根据哪个SAFI的路由转发哪些数据包是本地策略的问题。
Other implementations may treat the SAFI-1 and SAFI-4 routes for a given prefix as comparable, such that the best route to prefix P is either a SAFI-1 route or a SAFI-4 route but not both. In such implementations, if load-balancing is done among a set of equal cost routes, some of the equal cost routes may be SAFI-1 routes and some may be SAFI-4 routes. Whether this is allowed is, again, a matter of local policy.
其他实现可以将给定前缀的SAFI-1和SAFI-4路由视为可比较的，从而到前缀P的最佳路由是SAFI-1路由或SAFI-4路由，但不是两者都是。在这种实现中，如果在一组等成本路由之间进行负载平衡，则一些等成本路由可能是SAFI-1路由，而一些可能是SAFI-4路由。这是否被允许也是当地政策的问题。
Some implementations may allow a single BGP session to carry UPDATEs of both SAFI-1 and SAFI-4; other implementations may disallow this. Some implementations that allow both SAFIs on the same session may treat the receipt of a SAFI-1 route for prefix P on a given session
一些实现可能允许单个BGP会话同时携带SAFI-1和SAFI-4的更新；其他实现可能不允许这样做。某些允许两个SAFI在同一会话上的实现可能会在给定会话上处理接收前缀P的SAFI-1路由
as an implicit withdrawal of a previous SAFI-4 route for prefix P on that session, and vice versa. Other implementations may have different behavior.
作为在该会话上对前缀P的先前SAFI-4路由的隐式撤回，反之亦然。其他实现可能有不同的行为。
A BGP speaker may receive a SAFI-4 route over a given BGP session but may have other BGP sessions for which SAFI-4 is not enabled. In this case, the BGP speaker MAY convert the SAFI-4 route to a SAFI-1 route and then propagate the result over the session on which SAFI-4 is not enabled. Whether this is done is a matter of local policy.
BGP演讲者可以通过给定的BGP会话接收SAFI-4路由，但可能有其他未启用SAFI-4的BGP会话。在这种情况下，BGP演讲者可以将SAFI-4路由转换为SAFI-1路由，然后在未启用SAFI-4的会话上传播结果。是否这样做是当地政策的问题。
These differences in the behavior of different implementations may result in unexpected behavior or lack of interoperability. In some cases, it may be difficult or impossible to achieve the desired policies with certain implementations or combinations of implementations.
不同实现行为的这些差异可能导致意外行为或缺乏互操作性。在某些情况下，可能很难或不可能通过某些实现或实现的组合实现所需的策略。
IANA has assigned value 8 for Multiple Labels Capability in the BGP "Capability Codes" registry, with this document as the reference.
IANA在BGP“能力代码”注册表中为多标签能力分配了值8，本文件作为参考。
IANA has modified the BGP "Capability Codes" registry to mark value 4 ("Multiple routes to a destination capability") as deprecated, with this document as the reference.
IANA修改了BGP“能力代码”注册表，将值4（“到目标能力的多条路由”）标记为已弃用，并将本文档作为参考。
IANA has changed the reference for SAFI 4 in the "Subsequent Address Family Identifiers (SAFI) Parameters" registry to this document.
IANA已将“后续地址系列标识符（SAFI）参数”注册表中SAFI 4的参考更改为本文件。
Also, IANA has added this document as a reference for SAFI 128 in that same registry.
此外，IANA已将此文档添加为同一注册表中SAFI 128的参考。
The security considerations of BGP (as specified in [RFC4271]) apply.
BGP的安全注意事项（如[RFC4271]所述）适用。
If a BGP implementation that is not conformant with the current document encodes multiple labels in the NLRI but has not sent and received the Multiple Labels Capability, a BGP implementation that does conform with the current document will likely reset the BGP session.
如果不符合当前文档的BGP实现在NLRI中编码多个标签，但尚未发送和接收多标签功能，则符合当前文档的BGP实现可能会重置BGP会话。
This document specifies that certain data packets be "tunneled" from one BGP speaker to another. This requires that the packets be encapsulated while in flight. This document does not specify the encapsulation to be used. However, if a particular encapsulation is used, the security considerations of that encapsulation are applicable.
本文件规定将某些数据包从一个BGP扬声器“隧道”到另一个BGP扬声器。这要求在传输过程中封装数据包。本文档未指定要使用的封装。但是，如果使用特定的封装，则该封装的安全性考虑是适用的。
If a particular tunnel encapsulation does not provide integrity and authentication, it is possible that a data packet's label stack can be modified, through error or malfeasance, while the packet is in flight. This can result in misdelivery of the packet. It should be noted that the tunnel encapsulation (MPLS) most commonly used in deployments of this specification does not provide integrity or authentication; neither do the other tunnel encapsulations mentioned in Section 4.
如果特定的隧道封装不提供完整性和身份验证，则数据包的标签堆栈可能会在数据包飞行时因错误或渎职而被修改。这可能导致数据包的错误传递。应该注意的是，本规范部署中最常用的隧道封装（MPLS）不提供完整性或身份验证；第4节中提到的其他隧道封装也没有。
There are various techniques one can use to constrain the distribution of BGP UPDATE messages. If a BGP UPDATE advertises the binding of a particular label or set of labels to a particular address prefix, such techniques can be used to control the set of BGP speakers that are intended to learn of that binding. However, if BGP sessions do not provide privacy, other routers may learn of that binding.
有多种技术可用于限制BGP更新消息的分发。如果BGP更新播发特定标签或标签组到特定地址前缀的绑定，则可以使用此类技术来控制打算学习该绑定的BGP扬声器组。然而，如果BGP会话不提供隐私，其他路由器可能会知道该绑定。
When a BGP speaker processes a received MPLS data packet whose top label it advertised, there is no guarantee that the label in question was put on the packet by a router that was intended to know about that label binding. If a BGP speaker is using the procedures of this document, it may be useful for that speaker to distinguish its "internal" interfaces from its "external" interfaces and to avoid advertising the same labels to BGP speakers reached on internal interfaces as to BGP speakers reached on external interfaces. Then, a data packet can be discarded if its top label was not advertised over the type of interface from which the packet was received. This reduces the likelihood of forwarding packets whose labels have been "spoofed" by untrusted sources.
当BGP演讲者处理接收到的MPLS数据包时，它会公布其顶部标签，但不能保证该标签是由打算了解该标签绑定的路由器放在该数据包上的。如果BGP扬声器正在使用本文件中的程序，则该扬声器可能有助于区分其“内部”接口和“外部”接口，并避免向内部接口上的BGP扬声器宣传与外部接口上的BGP扬声器相同的标签。然后，如果数据包的顶部标签没有在接收数据包的接口类型上公布，则可以丢弃数据包。这降低了转发标签被不可信来源“欺骗”的数据包的可能性。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 3031，DOI 10.17487/RFC3031，2001年1月<https://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，DOI 10.17487/RFC3032，2001年1月<https://www.rfc-editor.org/info/rfc3032>.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, <https://www.rfc-editor.org/info/rfc3107>.
[RFC3107]Rekhter，Y.和E.Rosen，“在BGP-4中携带标签信息”，RFC 3107，DOI 10.17487/RFC3107，2001年5月<https://www.rfc-editor.org/info/rfc3107>.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, <https://www.rfc-editor.org/info/rfc3443>.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，DOI 10.17487/RFC3443，2003年1月<https://www.rfc-editor.org/info/rfc3443>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 4271，DOI 10.17487/RFC4271，2006年1月<https://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<https://www.rfc-editor.org/info/rfc4364>.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, <https://www.rfc-editor.org/info/rfc4659>.
[RFC4659]De Clercq，J.，Ooms，D.，Carugi，M.，和F.Le Faucheur，“用于IPv6 VPN的BGP-MPLS IP虚拟专用网络（VPN）扩展”，RFC 4659，DOI 10.17487/RFC4659，2006年9月<https://www.rfc-editor.org/info/rfc4659>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，DOI 10.17487/RFC4760，2007年1月<https://www.rfc-editor.org/info/rfc4760>.
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, DOI 10.17487/RFC4798, February 2007, <https://www.rfc-editor.org/info/rfc4798>.
[RFC4798]De Clercq，J.，Ooms，D.，Prevost，S.，和F.Le Faucheur，“使用IPv6提供商边缘路由器（6PE）通过IPv4 MPLS连接IPv6孤岛”，RFC 4798，DOI 10.17487/RFC4798，2007年2月<https://www.rfc-editor.org/info/rfc4798>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，DOI 10.17487/RFC5462，2009年2月<https://www.rfc-editor.org/info/rfc5462>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC5492]Scudder，J.和R.Chandra，“BGP-4的能力广告”，RFC 5492，DOI 10.17487/RFC5492，2009年2月<https://www.rfc-editor.org/info/rfc5492>.
[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", RFC 5549, DOI 10.17487/RFC5549, May 2009, <https://www.rfc-editor.org/info/rfc5549>.
[RFC5549]Le Faucheur，F.和E.Rosen，“通过IPv6下一跳发布IPv4网络层可达性信息”，RFC 5549，DOI 10.17487/RFC5549，2009年5月<https://www.rfc-editor.org/info/rfc5549>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.
[RFC7606]Chen，E.，Ed.，Scudder，J.，Ed.，Mohapatra，P.，和K.Patel，“BGP更新消息的修订错误处理”，RFC 7606，DOI 10.17487/RFC7606，2015年8月<https://www.rfc-editor.org/info/rfc7606>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[Enhanced-GR] Patel, K., Chen, E., Fernando, R., and J. Scudder, "Accelerated Routing Convergence for BGP Graceful Restart", Work in Progress, draft-ietf-idr-enhanced-gr-06, June 2016.
[Enhanced GR]Patel，K.，Chen，E.，Fernando，R.，和J.Scudder，“BGP优雅重启的加速路由收敛”，正在进行的工作，草稿-ietf-idr-Enhanced-GR-062016年6月。
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, <https://www.rfc-editor.org/info/rfc4724>.
[RFC4724]Sangli，S.，Chen，E.，Fernando，R.，Scudder，J.，和Y.Rekhter，“BGP的优雅重启机制”，RFC 4724，DOI 10.17487/RFC4724，2007年1月<https://www.rfc-editor.org/info/rfc4724>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 5331，DOI 10.17487/RFC5331，2008年8月<https://www.rfc-editor.org/info/rfc5331>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>.
[RFC6514]Aggarwal，R.，Rosen，E.，Morin，T.，和Y.Rekhter，“MPLS/BGP IP VPN中的BGP编码和多播过程”，RFC 6514，DOI 10.17487/RFC6514，2012年2月<https://www.rfc-editor.org/info/rfc6514>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7432]Sajassi，A.，Ed.，Aggarwal，R.，Bitar，N.，Isaac，A.，Uttaro，J.，Drake，J.，和W.Henderickx，“基于BGP MPLS的以太网VPN”，RFC 7432，DOI 10.17487/RFC7432，2015年2月<https://www.rfc-editor.org/info/rfc7432>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, <https://www.rfc-editor.org/info/rfc7911>.
[RFC7911]Walton，D.，Retana，A.，Chen，E.，和J.Scudder，“BGP中多路径的广告”，RFC 7911，DOI 10.17487/RFC7911，2016年7月<https://www.rfc-editor.org/info/rfc7911>.
[TUNNEL-ENCAPS] Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel Encapsulation Attribute", Work in Progress, draft-ietf-idr-tunnel-encaps-07, July 2017.
[TUNNEL-ENCAPS]Rosen，E.，Patel，K.和G.Velde，“BGP隧道封装属性”，在建工程，草稿-ietf-idr-TUNNEL-ENCAPS-072017年7月。
Acknowledgements
致谢
This document obsoletes RFC 3107. We wish to thank Yakov Rekhter, co-author of RFC 3107, for his work on that document. We also wish to thank Ravi Chandra, Enke Chen, Srihari R. Sangli, Eric Gray, and Liam Casey for their review of and comments on that document.
本文件淘汰了RFC 3107。我们要感谢RFC3107的共同作者亚科夫·雷克特（Yakov Rekhter）在该文件方面所做的工作。我们还要感谢Ravi Chandra、Enke Chen、Srihari R.Sangli、Eric Gray和Liam Casey对该文件的审查和评论。
We thank Alexander Okonnikov and David Lamparter for pointing out a number of the errors in RFC 3107.
我们感谢亚历山大·奥孔尼科夫和大卫·兰帕特指出RFC3107中的一些错误。
We wish to thank Lili Wang and Kaliraj Vairavakkalai for their help and advice during the preparation of this document.
我们要感谢Lili Wang和Kaliraj Vairavakkalai在编写本文件期间提供的帮助和建议。
We also thank Mach Chen, Bruno Decraene, Jie Dong, Adrian Farrel, Jeff Haas, Jonathan Hardwick, Jakob Heitz, Alexander Okonnikov, Keyur Patel, Kevin Wang, and Lucy Yong for their review of and comments on this document.
我们还感谢Mach Chen、Bruno DeClaene、Jie Dong、Adrian Farrel、Jeff Haas、Jonathan Hardwick、Jakob Heitz、Alexander Okonnikov、Keyur Patel、Kevin Wang和Lucy Yong对本文件的审查和评论。
Author's Address
作者地址
Eric C. Rosen Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America
Eric C.Rosen Juniper Networks，Inc.美国马萨诸塞州韦斯特福德科技园大道10号01886
Email: erosen@juniper.net
Email: erosen@juniper.net