Network Working Group E. Rosen
Request for Comments: 4182 Cisco Systems, Inc.
Updates: 3032 September 2005
Category: Standards Track
Network Working Group E. Rosen
Request for Comments: 4182 Cisco Systems, Inc.
Updates: 3032 September 2005
Category: Standards Track
Removing a Restriction on the use of MPLS Explicit NULL
删除对使用MPLS显式NULL的限制
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The label stack encoding for Multi-protocol Label Switching (MPLS) defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL". Previously, these labels were only legal when they occurred at the bottom of the MPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack.
用于多协议标签交换（MPLS）的标签堆栈编码定义了一个称为“IPv4显式NULL”的保留标签值和一个称为“IPv6显式NULL”的保留标签值。以前，只有当这些标签出现在MPLS标签堆栈的底部时，它们才是合法的。现在，此限制已被删除，因此这些标签值可以合法地出现在堆栈中的任何位置。
This document updates RFC 3032.
本文档更新了RFC 3032。
Table of Contents
目录
1. Introduction ....................................................2
2. Detail of Change ................................................2
3. Reasons for Change ..............................................3
4. Deployment Considerations .......................................5
5. Security Considerations .........................................5
6. Acknowledgments .................................................5
7. Normative References ............................................5
8. Informative References ..........................................5
1. Introduction ....................................................2
2. Detail of Change ................................................2
3. Reasons for Change ..............................................3
4. Deployment Considerations .......................................5
5. Security Considerations .........................................5
6. Acknowledgments .................................................5
7. Normative References ............................................5
8. Informative References ..........................................5
RFC 3032 defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL" [RFC3032]. It states that these label values are only legal at the bottom of the MPLS label stack. However, no reason is given for this restriction.
RFC 3032定义了一个名为“IPv4显式NULL”的保留标签值和一个名为“IPv6显式NULL”的保留标签值[RFC3032]。它声明这些标签值仅在MPLS标签堆栈的底部是合法的。但是，没有给出限制的理由。
It has turned out that in practice there are some situations in which it is useful to send MPLS packets that have Explicit NULL occur somewhere other than at that bottom of the label stack. While the intended semantics are obvious enough, the fact that such packets are gratuitously declared by RFC 3032 to be illegal has made it difficult to handle these situations in an interoperable manner.
事实证明，在实践中，在某些情况下，发送具有显式NULL的MPLS数据包是有用的，这些数据包发生在标签堆栈底部以外的其他位置。虽然预期的语义非常明显，但RFC 3032无偿宣布这些数据包为非法的事实使得以可互操作的方式处理这些情况变得困难。
This document updates RFC 3032 by removing the unnecessary restriction, so that the two aforementioned label values are legal anywhere in the label stack.
本文档通过删除不必要的限制来更新RFC 3032，以便上述两个标签值在标签堆栈中的任何位置都是合法的。
RFC 3032 states on page 4:
RFC 3032第4页说明：
There are several reserved label values:
有几个保留标签值：
i. A value of 0 represents the "IPv4 Explicit NULL Label". This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv4 header.
i. 值0表示“IPv4显式空标签”。此标签值仅在标签堆栈底部合法。它表示必须弹出标签堆栈，然后数据包的转发必须基于IPv4报头。
iii. A value of 2 represents the "IPv6 Explicit NULL Label". This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv6 header.
iii.值2表示“IPv6显式空标签”。此标签值仅在标签堆栈底部合法。它表示必须弹出标签堆栈，然后数据包的转发必须基于IPv6报头。
Paragraph i is hereby changed to read:
兹将第一款改为：
i. A value of 0 represents the "IPv4 Explicit NULL Label".
i. 值0表示“IPv4显式空标签”。
An IPv4 Explicit NULL at the top of the label stack means that the stack must be popped.
标签堆栈顶部的IPv4显式NULL表示必须弹出堆栈。
If the NULL was not the only label on the stack, this will cause the label beneath it to rise to the top of the stack. The disposition of the packet is based on the label that has now risen to the top.
如果NULL不是堆栈上的唯一标签，这将导致它下面的标签上升到堆栈顶部。数据包的处理基于现在已上升到顶部的标签。
If, on the other hand, the NULL was the only label on the stack, then the stack is now empty. The resulting packet is treated as an IPv4 packet, and its disposition is based on the IPv4 header.
另一方面，如果NULL是堆栈上的唯一标签，那么堆栈现在是空的。生成的数据包被视为IPv4数据包，其处置基于IPv4报头。
Paragraph iii is hereby changed to read:
兹将第三款改为：
iii. A value of 2 represents the "IPv6 Explicit NULL Label".
iii.值2表示“IPv6显式空标签”。
An IPv6 Explicit NULL at the top of the label stack means that the stack must be popped.
标签堆栈顶部的IPv6显式NULL表示必须弹出堆栈。
If the NULL was not the only label on the stack, this will cause the label beneath it to rise to the top of the stack. The disposition of the packet is based on the label that has now risen to the top.
如果NULL不是堆栈上的唯一标签，这将导致它下面的标签上升到堆栈顶部。数据包的处理基于现在已上升到顶部的标签。
If, on the other hand, the NULL was the only label on the stack, then the stack is now empty. The resulting packet is treated as an IPv6 packet, and its disposition is based on the IPv6 header.
另一方面，如果NULL是堆栈上的唯一标签，那么堆栈现在是空的。生成的数据包被视为IPv6数据包，其处置基于IPv6报头。
Restricting Explicit NULL to the bottom of the stack has caused some problems in practice.
将显式NULL限制在堆栈的底部在实践中导致了一些问题。
With this restriction in place, one should not distribute, to a particular label distribution peer, a binding of Explicit NULL to a particular Forwarding Equivalence Class (FEC), unless the following condition (call it "Condition L") holds: all MPLS packets received by that peer with an incoming label corresponding to that FEC contain only a single label stack entry. If Explicit NULL is bound to the FEC, but Condition L doesn't hold, the peer is being requested to create illegal packets. None of the MPLS specifications say what the peer is actually supposed to do in this case. This situation is made more troublesome by the facts that, in practice, Condition L rarely holds, and it is not possible, in general, to determine whether it holds or not.
有了这个限制，就不应该向特定的标签分发对等方分发显式NULL绑定到特定的转发等价类（FEC），除非满足以下条件（称之为“条件L”）保持：该对等方接收的所有MPLS数据包，其传入标签对应于该FEC，仅包含一个标签堆栈条目。如果显式NULL绑定到FEC，但条件L不成立，则请求对等方创建非法数据包。没有一个MPLS规范说明对等方在这种情况下应该做什么。事实上，条件L在实践中很少成立，而且通常不可能确定它是否成立，这使得这种情况更加麻烦。
Further, if one is supporting the Pipe Model of RFC 3270 [RFC3270], there are good reasons to create label stacks in which Explicit NULL is at the top of the label stack, but a non-null label is at the bottom.
此外，如果支持RFC 3270[RFC3270]的管道模型，则有充分的理由创建标签堆栈，其中显式NULL位于标签堆栈的顶部，而非NULL标签位于底部。
RFC 3270 specifies the procedures for MPLS support of Differentiated Services. In particular, it defines a "Pipe Model" in which (quoting from RFC 3270, Section 2.6.2):
RFC 3270规定了MPLS支持差异化服务的程序。特别是，它定义了一个“管道模型”，其中（引用RFC 3270第2.6.2节）：
"tunneled packets must convey two meaningful pieces of Diff-Serv information:
“隧道数据包必须传递两条有意义的区分服务信息：
- the Diff-Serv information which is meaningful to intermediate nodes along the LSP span including the LSP Egress (which we refer to as the 'LSP Diff-Serv Information'). This LSP Diff-Serv Information is not meaningful beyond the LSP Egress: Whether Traffic Conditioning at intermediate nodes on the LSP span affects the LSP Diff-Serv information or not, this updated Diff-Serv information is not considered meaningful beyond the LSP Egress and is ignored.
- Diff-Serv信息对包括LSP出口（我们称之为“LSP Diff-Serv信息”）在内的LSP跨度上的中间节点有意义。此LSP区分服务信息在LSP出口之外没有意义：无论LSP范围上中间节点处的流量调节是否影响LSP区分服务信息，此更新的区分服务信息在LSP出口之外没有意义，将被忽略。
- the Diff-Serv information which is meaningful beyond the LSP Egress (which we refer to as the 'Tunneled Diff-Serv Information'). This information is to be conveyed by the LSP Ingress to the LSP Egress. This Diff-Serv information is not meaningful to the intermediate nodes on the LSP span."
- 除了LSP出口之外有意义的区分服务信息（我们称之为“隧道式区分服务信息”）。该信息将由LSP入口传送到LSP出口。此区分服务信息对LSP范围上的中间节点没有意义。”
When the Pipe Model is in use, it is common practice for the LSP Egress to bind Explicit Null to the tunnel's FEC. The intention is that the LSP Diff-Serv information will be carried in the EXP bits of the Explicit Null label stack entry, and the tunneled Diff-Serv information will be carried in whatever is "below" the Explicit Null label stack entry, i.e., in the IP header DS bits or in the EXP bits of the next entry on the MPLS label stack.
在使用管道模型时，LSP出口通常将显式Null绑定到隧道的FEC。其目的是，LSP区分服务信息将被携带在显式空标签堆栈项的EXP位中，而隧道区分服务信息将被携带在显式空标签堆栈项“之下”的任何位置，即，在IP报头DS位中或在MPLS标签堆栈上的下一项的EXP位中。
Naturally, this practice causes a problem if the Pipe Model LSP is being used to tunnel MPLS packets (i.e., if Condition L does not hold). With strict adherence to RFCs 3031 and 3036, this practice results in an MPLS packet where Explicit NULL is at the top of the label stack, even though it is not the only entry in the label stack. However, RFC 3032 makes this packet illegal.
当然，如果使用管道模型LSP对MPLS数据包进行隧道传输（即，如果条件L不成立），这种做法会导致问题。在严格遵守RFCs 3031和3036的情况下，这种做法会导致MPLS数据包，其中显式NULL位于标签堆栈的顶部，即使它不是标签堆栈中的唯一条目。但是，RFC3032使该数据包非法。
Some implementations simply transmit the illegal packet. Others try to convert it to a legal packet by stripping off the Explicit NULL before transmitting it. However, that breaks the Pipe Model by discarding the LSP Diff-Serv information. It is conceivable that there may be an implementation that drops the illegal packet entirely; this would also break the Pipe Model, as it would lose not only the LSP Diff-Serv information, but the entire packet.
一些实现只是传输非法数据包。其他人则试图通过在传输前去掉显式空值来将其转换为合法数据包。然而，这通过丢弃LSP Diff-Serv信息打破了管道模型。可以想象，可能存在完全丢弃非法分组的实现；这也会破坏管道模型，因为它不仅会丢失LSP Diff-Serv信息，还会丢失整个数据包。
Of course the LSP egress is not compelled to bind Explicit NULL to the tunnel's FEC; an ordinary label could be used instead. However, using Explicit NULL enables the egress to determine immediately (i.e., without need for lookup in the Label Information Base) that the further forwarding of the packet is to be determined by whatever is below the label. Avoiding this lookup can have favorable implications on forwarding performance.
当然，LSP出口不必将显式NULL绑定到隧道的FEC；可以使用普通标签代替。然而，使用显式NULL使得出口能够立即（即，无需在标签信息库中查找）确定分组的进一步转发将由标签下方的任何内容来确定。避免这种查找会对转发性能产生有利影响。
Removing the restriction that Explicit Null only occur at the bottom of the stack is the simplest way to facilitate the proper operation of the Pipe Model.
消除显式Null仅出现在堆栈底部的限制是促进管道模型正确操作的最简单方法。
Implementations that adhere to this specification will interoperate correctly, and will correctly support the Pipe Model.
遵守此规范的实现将正确地进行互操作，并正确地支持管道模型。
Implementations that do not adhere to this specification may not interoperate. In particular, if a router advertises a binding of Explicit NULL, and if that router has an upstream LDP peer that will not transmit a packet that has multiple label stack entries with Explicit Null at top of the stack, then it will not be possible to use Explicit NULL to support the Pipe Model until the upstream LDP peer is brought into compliance with this specification.
不遵守此规范的实现可能无法互操作。特别是，如果路由器播发显式NULL的绑定，并且如果该路由器具有上游LDP对等方，该对等方不会传输具有多个标签堆栈项且堆栈顶部显式NULL的数据包，然后，在上游LDP对等方符合本规范之前，不可能使用显式NULL来支持管道模型。
It is possible that there may be a router implementation, preceding this specification, which will discard any received packet with multiple label stack entries and a top label value of Explicit Null. It is advisable to configure any such routers so that they do not advertise any bindings to Explicit Null.
在本规范之前，可能存在路由器实现，该实现将丢弃具有多个标签堆栈条目且顶部标签值为显式Null的任何接收数据包。建议配置任何此类路由器，以便它们不会向显式Null播发任何绑定。
This document updates RFC 3032 by allowing Explicit NULL to occur at any position in the label stack. This modification does not impose any new security considerations beyond those discussed in RFC 3032.
本文档通过允许标签堆栈中的任何位置出现显式NULL来更新RFC 3032。除了RFC 3032中讨论的安全注意事项外，此修改没有强加任何新的安全注意事项。
Thanks to Rahul Aggarwal, Francois LeFaucheur, Yakov Rekhter, and Dan Tappan for their helpful comments.
感谢Rahul Aggarwal、Francois LeFaucheur、Yakov Rekhter和Dan Tappan的有益评论。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
Author's Address
作者地址
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
Eric C.Rosen Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。