Network Working Group Y. Rekhter
Request for Comments: 3107 Juniper Networks
Category: Standards Track E. Rosen
Cisco Systems, Inc.
May 2001
Network Working Group Y. Rekhter
Request for Comments: 3107 Juniper Networks
Category: Standards Track E. Rosen
Cisco Systems, Inc.
May 2001
Carrying Label Information in BGP-4
在BGP-4中携带标签信息
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 way in which the label mapping information for a particular route is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the route itself. When BGP is used to distribute a particular route, it can be also be used to distribute a Multiprotocol Label Switching (MPLS) label which is mapped to that route.
本文档指定了在用于分发路由本身的同一边界网关协议（BGP）更新消息中承载特定路由的标签映射信息的方式。当BGP用于分发特定路由时，它还可用于分发映射到该路由的多协议标签交换（MPLS）标签。
Table of Contents
目录
1 Specification of Requirements .......................... 2
2 Overview ............................................... 2
3 Carrying Label Mapping Information ..................... 3
4 Advertising Multiple Routes to a Destination ........... 4
5 Capability Advertisement ............................... 4
6 When the BGP Peers are not Directly Adjacent ........... 5
7 Security Considerations ................................ 5
8 Acknowledgments ........................................ 6
9 References ............................................. 6
10 Authors' Addresses ..................................... 7
11 Full Copyright Statement ............................... 8
1 Specification of Requirements .......................... 2
2 Overview ............................................... 2
3 Carrying Label Mapping Information ..................... 3
4 Advertising Multiple Routes to a Destination ........... 4
5 Capability Advertisement ............................... 4
6 When the BGP Peers are not Directly Adjacent ........... 5
7 Security Considerations ................................ 5
8 Acknowledgments ........................................ 6
9 References ............................................. 6
10 Authors' Addresses ..................................... 7
11 Full Copyright Statement ............................... 8
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中的说明进行解释。
When BGP is used to distribute a particular route, it can also be used to distribute an MPLS label that is mapped to that route [MPLS-ARCH]. This document specifies the way in which this is done. The label mapping information for a particular route is piggybacked in the same BGP Update message that is used to distribute the route itself.
当BGP用于分发特定路由时，它还可用于分发映射到该路由的MPLS标签[MPLS-ARCH]。本文档指定了执行此操作的方式。特定路由的标签映射信息在用于分发路由本身的同一BGP更新消息中进行了携带。
This can be useful in the following situations:
这在以下情况下非常有用：
- If two immediately adjacent Label Switched Routers (LSRs) are also BGP peers, then label distribution can be done without the need for any other label distribution protocol.
- 如果两个相邻的标签交换路由器（LSR）也是BGP对等方，则可以在不需要任何其他标签分发协议的情况下完成标签分发。
- Suppose one's network consists of two "classes" of LSR: exterior LSRs, which interface to other networks, and interior LSRs, which serve only to carry traffic between exterior LSRs. Suppose that the exterior LSRs are BGP speakers. If the BGP speakers distribute MPLS labels to each other along with each route they distribute, then as long as the interior routers support MPLS, they need not receive any of the BGP routes from the BGP speakers.
- 假设一个人的网络由两类LSR组成：外部LSR（与其他网络连接）和内部LSR（仅用于在外部LSR之间传输流量）。假设外部LSR是BGP扬声器。如果BGP扬声器将MPLS标签与它们分发的每个路由一起分发给彼此，那么只要内部路由器支持MPLS，它们就不需要从BGP扬声器接收任何BGP路由。
If exterior router A needs to send a packet to destination D, and A's BGP next hop for D is exterior router B, and B has mapped label L to D, then A first pushes L onto the packet's label stack. A then consults its IGP to find the next hop to B, call it C. If C has distributed to A an MPLS label for the route to B, A can push this label on the packet's label stack, and then send the packet to C.
如果外部路由器A需要将数据包发送到目的地D，并且A的BGP下一跳为D的外部路由器B，并且B已将标签L映射到D，则A首先将L推送到数据包的标签堆栈上。然后，A咨询其IGP以找到到B的下一个跃点，称之为C。如果C已向A分发到B的路由的MPLS标签，A可以将此标签推到数据包的标签堆栈上，然后将数据包发送到C。
If a set of BGP speakers are exchanging routes via a Route Reflector [BGP-RR], then by piggybacking the label distribution on the route distribution, one is able to use the Route Reflector to distribute the labels as well. This improves scalability quite significantly. Note that if the Route Reflector is not in the forwarding path, it need not even be capable of forwarding MPLS packets.
如果一组BGP扬声器通过路由反射器[BGP-RR]交换路由，那么通过在路由分布上搭载标签分布，也可以使用路由反射器来分布标签。这大大提高了可伸缩性。注意，如果路由反射器不在转发路径中，则它甚至不需要能够转发MPLS分组。
Label distribution can be piggybacked in the BGP Update message by using the BGP-4 Multiprotocol Extensions attribute [RFC 2283]. The label is encoded into the NLRI field of the attribute, and the SAFI
标签分发可以通过使用BGP-4多协议扩展属性[RFC 2283]在BGP更新消息中进行。标签编码到属性的NLRI字段中，SAFI
("Subsequent Address Family Identifier") field is used to indicate that the NLRI contains a label. A BGP speaker may not use BGP to send labels to a particular BGP peer unless that peer indicates, through BGP Capability Advertisement, that it can process Update messages with the specified SAFI field.
（“后续地址族标识符”）字段用于指示NLRI包含标签。BGP演讲者不得使用BGP向特定BGP对等方发送标签，除非该对等方通过BGP功能公告表明其可以使用指定的SAFI字段处理更新消息。
Label mapping information is carried as part of the Network Layer Reachability Information (NLRI) in the Multiprotocol Extensions attributes. The AFI indicates, as usual, the address family of the associated route. The fact that the NLRI contains a label is indicated by using SAFI value 4.
标签映射信息作为网络层可达性信息（NLRI）的一部分包含在多协议扩展属性中。AFI通常指示相关路由的地址族。NLRI包含标签的事实通过使用SAFI值4表示。
The Network Layer Reachability information is encoded as one or more triples of the form <length, label, prefix>, whose fields are described below:
网络层可达性信息编码为<length，label，prefix>形式的一个或多个三元组，其字段描述如下：
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Label (3 octets) |
+---------------------------+
.............................
+---------------------------+
| Prefix (variable) |
+---------------------------+
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Label (3 octets) |
+---------------------------+
.............................
+---------------------------+
| Prefix (variable) |
+---------------------------+
The use and the meaning of these fields are as follows:
这些字段的用途和含义如下：
a) Length:
a) 长度：
The Length field indicates the length in bits of the address prefix plus the label(s).
长度字段表示地址前缀加上标签的位长度。
b) Label:
b) 标签：
The Label field carries one or more labels (that corresponds to the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 octets, where the high-order 20 bits contain the label value, and the low order bit contains "Bottom of Stack" (as defined in [MPLS-ENCAPS]).
标签字段包含一个或多个标签（对应于标签堆栈[MPLS-ENCAPS]）。每个标签编码为3个八位字节，其中高阶20位包含标签值，低阶位包含“堆栈底部”（定义见[MPLS-ENCAPS]）。
c) Prefix:
c) 前缀：
The Prefix field contains address prefixes followed by enough trailing bits to make the end of the field fall on an octet boundary. Note that the value of trailing bits is irrelevant.
前缀字段包含地址前缀，后跟足够的尾随位，以使字段的结尾落在八位字节边界上。请注意，尾随位的值是无关的。
The label(s) specified for a particular route (and associated with its address prefix) must be assigned by the LSR which is identified by the value of the Next Hop attribute of the route.
为特定路由指定的标签（与其地址前缀关联）必须由LSR分配，LSR由路由的下一跳属性值标识。
When a BGP speaker redistributes a route, the label(s) assigned to that route must not be changed (except by omission), unless the speaker changes the value of the Next Hop attribute of the route.
当BGP演讲者重新分配路由时，除非演讲者更改路由的下一跳属性的值，否则不得更改分配给该路由的标签（省略的情况除外）。
A BGP speaker can withdraw a previously advertised route (as well as the binding between this route and a label) by either (a) advertising a new route (and a label) with the same NLRI as the previously advertised route, or (b) listing the NLRI of the previously advertised route in the Withdrawn Routes field of an Update message. The label information carried (as part of NLRI) in the Withdrawn Routes field should be set to 0x800000. (Of course, terminating the BGP session also withdraws all the previously advertised routes.)
BGP演讲者可以通过（A）使用与先前公布的路由相同的NLRI公布新路由（和标签），或（b）在更新消息的撤回路由字段中列出先前公布的路由的NLRI，撤回先前公布的路由（以及该路由与标签之间的绑定）。撤回路线字段中携带的标签信息（作为NLRI的一部分）应设置为0x800000。（当然，终止BGP会话也会撤回所有以前公布的路由。）
A BGP speaker may maintain (and advertise to its peers) more than one route to a given destination, as long as each such route has its own label(s).
BGP演讲者可以维护（并向其对等方发布）到给定目的地的多条路由，只要每条路由都有自己的标签。
The encoding described above allows a single BGP Update message to carry multiple routes, each with its own label(s).
上述编码允许单个BGP更新消息承载多个路由，每个路由都有自己的标签。
In the case where a BGP speaker advertises multiple routes to a destination, if a route is withdrawn, and a label(s) is specified at the time of withdrawal, only the corresponding route with the corresponding label is withdrawn. If a route is withdrawn, and no label is specified at the time of withdrawal, then only the corresponding unlabeled route is withdrawn; the labeled routes are left in place.
在BGP扬声器向目的地播发多条路由的情况下，如果路由被撤回，并且在撤回时指定了标签，则仅撤回具有相应标签的相应路由。如果路线被撤回，且撤回时未指定标签，则仅撤回相应的未标记路线；标记的路线保留在原位。
A BGP speaker that uses Multiprotocol Extensions to carry label mapping information should use the Capabilities Optional Parameter, as defined in [BGP-CAP], to inform its peers about this capability. The MP_EXT Capability Code, as defined in [BGP-MP], is used to advertise the (AFI, SAFI) pairs available on a particular connection.
使用多协议扩展来携带标签映射信息的BGP演讲者应使用[BGP-CAP]中定义的Capabilities可选参数来通知其对等方此功能。[BGP-MP]中定义的MP_EXT功能代码用于公布特定连接上可用的（AFI、SAFI）对。
A BGP speaker should not advertise this capability to another BGP speaker unless there is a Label Switched Path (LSP) between the two speakers.
BGP扬声器不应向另一个BGP扬声器宣传此功能，除非两个扬声器之间存在标签交换路径（LSP）。
A BGP speaker that is capable of handling multiple routes to a destination (as described above) should use the Capabilities Optional Parameter, as defined in [BGP-CAP], to inform its peers about this capability. The value of this capability is 4.
能够处理到目的地的多条路由的BGP扬声器（如上所述）应使用[BGP-CAP]中定义的Capabilities（能力）可选参数通知其对等方该能力。此功能的值为4。
Consider the following LSR topology: A--B--C--D. Suppose that D distributes a label L to A. In this topology, A cannot simply push L onto a packet's label stack, and then send the resulting packet to B. D must be the only LSR that sees L at the top of the stack. Before A sends the packet to B, it must push on another label, which was distributed by B. B must replace this label with yet another label, which was distributed by C. In other words, there must be an LSP between A and D. If there is no such LSP, A cannot make use of label L. This is true any time labels are distributed between non-adjacent LSRs, whether that distribution is done by BGP or by some other method.
考虑下面的LSR拓扑结构：A -B-C-D。假设D将标签L分配给A。在这个拓扑中，A不能简单地将L推到分组的标签堆栈上，然后将结果分组发送到B。必须是在栈顶看到L的唯一LSR。在A将数据包发送给B之前，它必须推上B分发的另一个标签。B必须用C分发的另一个标签替换该标签。换句话说，A和D之间必须有LSP。如果没有这样的LSP，A就不能使用标签L。在非相邻LSR之间分发标签时，这是正确的，无论该分发是通过BGP还是通过其他方法完成的。
This document does NOT specify any procedure for ensuring in real time that label distribution between non-adjacent LSRs is done only when the appropriate MPLS infrastructure exists in the network or networks connecting the two LSRs. Ensuring that the proper infrastructure exists is an issue for network management and operation.
本文件未规定任何程序，以确保只有在网络或连接两个LSR的网络中存在适当的MPLS基础设施时，才能实时在非相邻LSR之间分配标签。确保适当的基础设施存在是网络管理和运营的一个问题。
When an LSR A is directly connected to an LSR B via a point-to-point interface, then when A receives packets over that interface, it knows that they come from B. This makes it easy for A to discard any packets from B whose top labels are not among the labels that A distributed to B. That is, A can easily ensure that B only uses those labels which it is entitled to use. This technique can be used to prevent "label spoofing", i.e., the situation in which an LSR imposes a label which has not been properly distributed to it.
当LSR A通过点对点接口直接连接到LSR B时，当A通过该接口接收到数据包时，它知道这些数据包来自B。这使得A很容易丢弃B的任何数据包，这些数据包的顶部标签不在A分发给B的标签中。也就是说，A可以轻松确保B只使用其有权使用的标签。该技术可用于防止“标签欺骗”，即LSR施加未正确分发的标签的情况。
The procedures discussed in this document would commonly be used when the label distribution peers are separated not merely by a point-to-point link, but by an MPLS network. This means that when an LSR A processes a labeled packet, it really has no way to determine which other LSR B pushed on the top label. Hence it cannot tell whether the label is one which B is entitled to use. In fact, when Route Reflectors are in use, A may not even know the set of LSRs which receive its label mappings. So the previous paragraph's technique for preventing label spoofing does not apply.
当标签分发对等点不仅通过点到点链路分离，而且通过MPLS网络分离时，通常使用本文档中讨论的过程。这意味着，当一个LSR A处理一个标记的数据包时，它实际上无法确定哪个LSR B推到了顶部标签上。因此，它无法判断该标签是否是B有权使用的标签。事实上，当使用路由反射器时，A甚至可能不知道接收其标签映射的LSR集。因此，前一段防止标签欺骗的技术不适用。
It is possible though to use other techniques to avoid label spoofing problems. If, for example, one never accepts labeled packets from the network's "external" interfaces, and all the BGP-distributed labels are advertised via IBGP, then there is no way for an untrusted router to put a labeled packet into the network. One can generally assume that one's IBGP peers (or the IBGP peers of one's Route Reflector) will not attempt label spoofing, since they are all under the control of a single administration.
不过，可以使用其他技术来避免标签欺骗问题。例如，如果从不接受来自网络“外部”接口的带标签的数据包，并且所有BGP分发的标签都是通过IBGP发布的，那么不受信任的路由器就无法将带标签的数据包放入网络。人们通常可以假设自己的IBGP对等方（或路由反射器的IBGP对等方）不会尝试标签欺骗，因为它们都在单一管理的控制下。
This condition can actually be weakened significantly. One doesn't need to refuse to accept all labeled packets from external interfaces. One just needs to make sure that any labeled packet received on an external interface has a top label which was actually distributed out that interface.
这种情况实际上可以大大削弱。不需要拒绝接受来自外部接口的所有标记数据包。我们只需要确保在外部接口上接收到的任何带标签的数据包都有一个顶部标签，该标签实际上是分发给该接口的。
Then a label spoofing problem would only exist if there are both trusted and untrusted systems out the same interface. One way to avoid this problem is simply to avoid this situation.
那么，只有在同一接口上同时存在受信任和不受信任的系统时，标签欺骗问题才会存在。避免这个问题的一个方法就是避免这种情况。
Thanks to Ravi Chandra, Enke Chen, Srihari Ramachandra, Eric Gray and Liam Casey for their comments.
感谢Ravi Chandra、Enke Chen、Srihari Ramachandra、Eric Gray和Liam Casey的评论。
[BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP-4]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000.
[BGP-CAP]Chandra，R.和J.Scudder，“BGP-4的能力广告”，RFC 2842，2000年5月。
[BGP-MP] Bates, T., Rekhter, Y, Chandra, R. and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[BGP-MP]Bates，T.，Rekhter，Y，Chandra，R.和D.Katz，“BGP-4的多协议扩展”，RFC 2858，2000年6月。
[BGP-RR] Bates, T. and R. Chandra, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.
[BGP-RR]Bates，T.和R.Chandra，“BGP路线反射：全网格IBGP的替代方案”，RFC 1966，1996年6月。
[MPLS-ARCH] Rosen, E., Vishwanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture" RFC 3031, January 2001.
[MPLS-ARCH]Rosen，E.，Vishwanathan，A.和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-ENCAPS]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089
加利福尼亚州桑尼维尔市马蒂尔达大道北1194号雅科夫·雷克特·杜松网络公司，邮编94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
Eric Rosen Cisco Systems，Inc.马萨诸塞州切姆斯福德阿波罗大道250号邮编01824
EMail: erosen@cisco.com
EMail: erosen@cisco.com
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编辑功能的资金目前由互联网协会提供。