Network Working Group R. Bonica
Request for Comments: 4950 Juniper Networks
Category: Standards Track D. Gan
D. Tappan
Consultant
C. Pignataro
Cisco Systems, Inc.
August 2007
Network Working Group R. Bonica
Request for Comments: 4950 Juniper Networks
Category: Standards Track D. Gan
D. Tappan
Consultant
C. Pignataro
Cisco Systems, Inc.
August 2007
ICMP Extensions for Multiprotocol Label Switching
用于多协议标签交换的ICMP扩展
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits Label Switching Routers to append MPLS information to ICMP messages, and has already been widely deployed.
此备忘录定义了可附加到所选多部分ICMP消息的扩展对象。这个扩展允许标签交换路由器将MPLS信息附加到ICMP消息中，并且已经被广泛部署。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. Application to TRACEROUTE . . . . . . . . . . . . . . . . . . . 3
4. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. MPLS Label Stack Object . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. Application to TRACEROUTE . . . . . . . . . . . . . . . . . . . 3
4. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. MPLS Label Stack Object . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
IP routers use the Internet Control Message Protocol, ICMPv4 [RFC0792] and ICMPv6 [RFC4443], to convey control information to source hosts. Network operators use this information to diagnose routing problems.
IP路由器使用互联网控制消息协议ICMPv4[RFC0792]和ICMPv6[RFC4443]将控制信息传送给源主机。网络运营商使用此信息诊断路由问题。
When a router receives an undeliverable IP datagram, it can send an ICMP message to the host that originated the datagram. The ICMP message indicates why the datagram could not be delivered. It also contains the IP header and leading payload octets of the "original datagram" to which the ICMP message is a response.
当路由器接收到无法传送的IP数据报时，它可以向发起该数据报的主机发送ICMP消息。ICMP消息指示数据报无法传递的原因。它还包含ICMP消息作为响应的“原始数据报”的IP报头和前导有效负载八位字节。
MPLS Label Switching Routers (LSR) also use ICMP to convey control information to source hosts. Section 2.3 of [RFC3032] describes the interaction between MPLS and ICMP, and Sections 2.4 and 3 of [RFC3032] provide applications of that interaction.
MPLS标签交换路由器（LSR）也使用ICMP将控制信息传送到源主机。[RFC3032]第2.3节描述了MPLS和ICMP之间的交互作用，[RFC3032]第2.4节和第3节提供了该交互作用的应用。
When an LSR receives an undeliverable MPLS-encapsulated datagram, it removes the entire MPLS label stack, exposing the previously encapsulated IP datagram. The LSR then submits the IP datagram to an error processing module. Error processing can include ICMP message generation.
当LSR接收到无法传递的MPLS封装数据报时，它会移除整个MPLS标签堆栈，从而暴露先前封装的IP数据报。然后，LSR将IP数据报提交给错误处理模块。错误处理可以包括ICMP消息生成。
The ICMP message indicates why the original datagram could not be delivered. It also contains the IP header and leading octets of the original datagram.
ICMP消息指出原始数据报无法传递的原因。它还包含原始数据报的IP报头和前导八位字节。
The ICMP message, however, contains no information regarding the MPLS label stack that encapsulated the original datagram when it arrived at the LSR. This omission is significant because the LSR would have forwarded the original datagram based upon information contained by the MPLS label stack.
然而，ICMP消息不包含有关MPLS标签堆栈的信息，MPLS标签堆栈在原始数据报到达LSR时封装了原始数据报。这一遗漏意义重大，因为LSR将根据MPLS标签堆栈包含的信息转发原始数据报。
This memo defines an ICMP extension object that permits an LSR to append MPLS information to ICMP messages. Selected ICMP messages SHOULD include the MPLS label stack, as it arrived at the router that is sending the ICMP message. The ICMP message MUST also include the IP header and leading payload octets of the original datagram.
此备忘录定义了一个ICMP扩展对象，该对象允许LSR将MPLS信息附加到ICMP消息中。选定的ICMP消息在到达发送ICMP消息的路由器时应包括MPLS标签堆栈。ICMP消息还必须包括原始数据报的IP报头和前导有效负载八位字节。
The ICMP extensions defined in this document must be preceded by an ICMP Extension Structure Header and an ICMP Object Header. Both are defined in [RFC4884].
本文档中定义的ICMP扩展之前必须有ICMP扩展结构头和ICMP对象头。[RFC4884]中定义了这两者。
The ICMP extension defined in this document is equally applicable to ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. Throughout this document, unless otherwise specified, the acronym ICMP refers to multi-part ICMP messages, encompassing both ICMPv4 and ICMPv6.
本文件中定义的ICMP扩展同样适用于ICMPv4[RFC0792]和ICMPv6[RFC4443]。在本文件中，除非另有规定，否则首字母缩写ICMP指多部分ICMP消息，包括ICMPv4和ICMPv6。
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 RFC2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC2119[RFC2119]中所述进行解释。
The ICMP extension defined in this memo supports enhancements to TRACEROUTE. Enhanced TRACEROUTE applications, like older implementations, indicate which nodes the original datagram visited en route to its destination. They differ from older implementations in that they also reflect the original datagram's MPLS encapsulation status as it arrived at each node.
本备忘录中定义的ICMP扩展支持对跟踪路由的增强。增强的TRACEROUTE应用程序与旧的实现类似，指示原始数据报在到达目的地的途中访问了哪些节点。它们不同于以前的实现，因为它们还反映了原始数据报到达每个节点时的MPLS封装状态。
Figure 1 contains sample output from an enhanced TRACEROUTE implementation.
图1包含一个增强的TRACEROUTE实现的示例输出。
> traceroute 192.0.2.1
>示踪路由192.0.2.1
traceroute to 192.0.2.1 (192.0.2.1), 30 hops max, 40 byte packets
追踪路由到192.0.2.1（192.0.2.1），最多30跳，40字节数据包
1 192.0.2.13 (192.0.2.13) 0.661 ms 0.618 ms 0.579 ms
1192.0.2.13（192.0.2.13）0.661毫秒0.618毫秒0.579毫秒
2 192.0.2.9 (192.0.2.9) 0.861 ms 0.718 ms 0.679 ms
2192.0.2.9（192.0.2.9）0.861毫秒0.718毫秒0.679毫秒
MPLS Label=100048 Exp=0 TTL=1 S=1
MPLS Label=100048 Exp=0 TTL=1 S=1
3 192.0.2.5 (192.0.2.5) 0.822 ms 0.731 ms 0.708 ms
3192.0.2.5（192.0.2.5）0.822毫秒0.731毫秒0.708毫秒
MPLS Label=100016 Exp=0 TTL=1 S=1
MPLS Label=100016 Exp=0 TTL=1 S=1
4 192.0.2.1 (192.0.2.1) 0.961 ms 8.676 ms 0.875 ms
4192.0.2.1（192.0.2.1）0.961毫秒8.676毫秒0.875毫秒
Figure 1: Enhanced TRACEROUTE Sample Output
图1：增强的TRACEROUTE示例输出
This memo does not define the general relationship between ICMP and MPLS. Section 2.3 of [RFC3032] defines this relationship.
本备忘录未定义ICMP和MPLS之间的一般关系。[RFC3032]第2.3节定义了这种关系。
The current memo does not define encapsulation-specific TTL (Time to Live) manipulation procedures. It defers to Section 5.4 of RFC 3034 [RFC3034] and Section 10 of [RFC3035] in this matter.
当前备忘录没有定义封装特定的TTL（生存时间）操作过程。在这一问题上，它遵循RFC 3034[RFC3034]第5.4节和[RFC3035]第10节。
When encapsulation-specific TTL manipulation procedures defeat the basic TRACEROUTE mechanism, they will also defeat enhanced TRACEROUTE implementations.
当封装特定的TTL操作过程破坏了基本的跟踪路由机制时，它们也会破坏增强的跟踪路由实现。
The MPLS Label Stack Object can be appended to the ICMP Time Exceeded and Destination Unreachable messages. A single instance of the MPLS Label Stack Object represents the entire MPLS label stack, formatted exactly as it was when it arrived at the LSR that sends the ICMP message.
MPLS标签堆栈对象可以附加到ICMP超时和目标不可访问消息中。MPLS标签堆栈对象的单个实例表示整个MPLS标签堆栈，其格式与到达发送ICMP消息的LSR时完全相同。
Figure 2 depicts the MPLS Label Stack Object. It must be preceded by an ICMP Extension Structure Header and an ICMP Object Header. Both are defined in [RFC4884].
图2描述了MPLS标签堆栈对象。它前面必须有ICMP扩展结构头和ICMP对象头。[RFC4884]中定义了这两者。
In the object payload, octets 0-3 depict the first member of the MPLS label stack. Each remaining member of the MPLS label stack is represented by another 4 octets that share the same format.
在对象负载中，八位字节0-3表示MPLS标签堆栈的第一个成员。MPLS标签堆栈的每个剩余成员由共享相同格式的另外4个八位字节表示。
Class-Num = 1, MPLS Label Stack Class
C-Type = 1, Incoming MPLS Label Stack
Length = 4 + 4 * (number of MPLS LSEs)
Class-Num = 1, MPLS Label Stack Class
C-Type = 1, Incoming MPLS Label Stack
Length = 4 + 4 * (number of MPLS LSEs)
0 1 2 3
+-------------+-------------+-------------+-------------+
| Label |EXP |S| TTL |
+-------------+-------------+-------------+-------------+
| |
| // Remaining MPLS Label Stack Entries // |
| |
+-------------+-------------+-------------+-------------+
0 1 2 3
+-------------+-------------+-------------+-------------+
| Label |EXP |S| TTL |
+-------------+-------------+-------------+-------------+
| |
| // Remaining MPLS Label Stack Entries // |
| |
+-------------+-------------+-------------+-------------+
Figure 2: MPLS Label Stack Object
图2:MPLS标签堆栈对象
Label: 20 bits
标签：20位
Exp: Experimental Use, 3 bits
实验使用，3位
S: Bottom of Stack, 1 bit
S：堆栈底部，1位
TTL: Time to Live, 8 bits
TTL：生存时间，8位
This memo does not specify the conditions that trigger the generation of ICMP Messages for Labeled IP Packets. It does not define the interaction between MPLS and ICMP. However, this document defines an extension that allows an MPLS router to append MPLS information to multi-part ICMP messages, and therefore can provide the user of the TRACEROUTE application with additional information. Consequently, a network operator may wish to provide this information selectively based on some policy; for example, only include the MPLS extensions in ICMP messages destined to addresses within the network management blocks with administrative control over the router. An implementation could determine whether to include the MPLS Label Stack extensions based upon the destination address of the ICMP message, or based on a global configuration option in the router. Alternatively, an implementation may determine whether to include these MPLS extensions when TTL expires based on the number of label stack entries (depth of the label stack) of the incoming packet. Finally, an operator can make use of the TTL treatment on MPLS Pipe Model LSPs defined in [RFC3443] for a TTL-transparent mode of operation that would prevent ICMP Time Exceeded altogether when tunneled over the MPLS LSP.
此备忘录未指定触发已标记IP数据包的ICMP消息生成的条件。它没有定义MPLS和ICMP之间的交互。但是，本文档定义了一个扩展，该扩展允许MPLS路由器将MPLS信息附加到多部分ICMP消息中，因此可以向跟踪路由应用程序的用户提供附加信息。因此，网络运营商可能希望基于某些策略选择性地提供该信息；例如，仅在ICMP消息中包含MPLS扩展，该消息的目的地为网络管理块内的地址，并对路由器进行管理控制。实现可以根据ICMP消息的目标地址或路由器中的全局配置选项确定是否包括MPLS标签堆栈扩展。或者，实现可以基于传入分组的标签栈条目的数量（标签栈的深度）来确定当TTL到期时是否包括这些MPLS扩展。最后，运营商可以利用[RFC3443]中定义的MPLS管道型号LSP上的TTL处理，以实现TTL透明操作模式，从而防止在MPLS LSP上进行隧道传输时完全超过ICMP时间。
IANA has assigned the following object Class-num in the ICMP Extension Object registry:
IANA已在ICMP扩展对象注册表中分配了以下对象类num：
Class-Num Description 1 MPLS Label Stack Class
类别编号说明1 MPLS标签堆栈类别
IANA has established a registry for the corresponding class sub-type (C-Type) space, as follows:
IANA已为相应的类子类型（C类型）空间建立了注册表，如下所示：
MPLS Label Stack Class Sub-types:
MPLS标签堆栈类子类型：
C-Type Description 0 Reserved 1 Incoming MPLS Label Stack 0x02-0xF6 Available for assignment 0xF7-0xFF Reserved for private use
C类型描述0保留1传入MPLS标签堆栈0x02-0xF6可用于分配0xF7-0xFF保留供私人使用
C-Type values are assignable on a first-come-first-serve (FCFS) basis [RFC2434].
C型值可在先到先得（FCFS）的基础上分配[RFC2434]。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[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月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[RFC4884]Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“支持多部分消息的扩展ICMP”，RFC 4884，2007年4月。
[RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[RFC3034]Conta，A.，Doolan，P.，和A.Malis，“帧中继网络上标签切换的使用规范”，RFC 3034，2001年1月。
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[RFC3035]Davie，B.，Lawrence，J.，McCloghrie，K.，Rosen，E.，Swallow，G.，Rekhter，Y.，和P.Doolan，“使用LDP和ATM VC交换的MPLS”，RFC 3035，2001年1月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，2003年1月。
Authors' Addresses
作者地址
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US
罗纳德P.博尼卡Juniper Networks 2251美国弗吉尼亚州赫恩登市企业园大道20171
EMail: rbonica@juniper.net
EMail: rbonica@juniper.net
Der-Hwa Gan Consultant
德华根顾问
EMail: derhwagan@yahoo.com
EMail: derhwagan@yahoo.com
Daniel C. Tappan Consultant
Daniel C.Tappan顾问
EMail: Dan.Tappan@gmail.com
EMail: Dan.Tappan@gmail.com
Carlos Pignataro Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709 US
卡洛斯·皮格纳塔罗思科系统公司，美国北卡罗来纳州基特克里克路研究三角公园7025号，邮编27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。