Internet Engineering Task Force (IETF)                       J. Luo, Ed.
Request for Comments: 7743                                           ZTE
Updates: 4379                                                L. Jin, Ed.
Category: Standards Track
ISSN: 2070-1721                                           T. Nadeau, Ed.
                                                                 Brocade
                                                         G. Swallow, Ed.
                                                                   Cisco
                                                            January 2016
        
Internet Engineering Task Force (IETF)                       J. Luo, Ed.
Request for Comments: 7743                                           ZTE
Updates: 4379                                                L. Jin, Ed.
Category: Standards Track
ISSN: 2070-1721                                           T. Nadeau, Ed.
                                                                 Brocade
                                                         G. Swallow, Ed.
                                                                   Cisco
                                                            January 2016
        

Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping

标签交换路径(LSP)Ping的中继回音应答机制

Abstract

摘要

In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping and Traceroute"), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute. This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379.

在RFC 4379的某些AS间(自治系统)和区域间部署场景(“标签交换路径(LSP)Ping和跟踪路由”)中,应答标签交换路由器(LSR)可能没有到启动器的可用路由,发送到启动器的回音应答消息将被丢弃,导致LSP Ping和Traceroute的误阴性或操作完全失败。本文档描述了对LSP Ping机制的扩展,以使应答LSR能够通过一组可路由中间节点将回音响应中继到启动器。本文件更新了RFC 4379。

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 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7743.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc7743.

Copyright Notice

版权公告

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2016 IETF信托基金和确定为文件作者的人员。版权所有。

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
        
   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.

本文件的出版。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................3
   2. Motivation ......................................................3
   3. Extensions ......................................................5
      3.1. Relayed Echo Reply Message .................................5
      3.2. Relay Node Address Stack ...................................6
      3.3. MTU Exceeded Return Code ...................................8
   4. Procedures ......................................................8
      4.1. Sending an Echo Request ....................................9
      4.2. Receiving an Echo Request ..................................9
      4.3. Originating a Relayed Echo Reply ..........................10
      4.4. Relaying a Relayed Echo Reply .............................11
      4.5. Sending an Echo Reply .....................................11
      4.6. Sending Subsequent Echo Requests ..........................12
      4.7. Impact on Traceroute ......................................12
   5. LSP Ping Relayed Echo Reply Example ............................13
   6. Security Considerations ........................................14
   7. Backward Compatibility .........................................15
   8. IANA Considerations ............................................15
      8.1. MPLS Relayed Echo Reply ...................................15
      8.2. Relay Node Address Stack TLV ..............................16
      8.3. MTU Exceeded Return Code ..................................16
   9. References .....................................................16
      9.1. Normative References ......................................16
      9.2. Informative References ....................................17
   Acknowledgements ..................................................17
   Contributors ......................................................17
   Authors' Addresses ................................................18
        
   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................3
   2. Motivation ......................................................3
   3. Extensions ......................................................5
      3.1. Relayed Echo Reply Message .................................5
      3.2. Relay Node Address Stack ...................................6
      3.3. MTU Exceeded Return Code ...................................8
   4. Procedures ......................................................8
      4.1. Sending an Echo Request ....................................9
      4.2. Receiving an Echo Request ..................................9
      4.3. Originating a Relayed Echo Reply ..........................10
      4.4. Relaying a Relayed Echo Reply .............................11
      4.5. Sending an Echo Reply .....................................11
      4.6. Sending Subsequent Echo Requests ..........................12
      4.7. Impact on Traceroute ......................................12
   5. LSP Ping Relayed Echo Reply Example ............................13
   6. Security Considerations ........................................14
   7. Backward Compatibility .........................................15
   8. IANA Considerations ............................................15
      8.1. MPLS Relayed Echo Reply ...................................15
      8.2. Relay Node Address Stack TLV ..............................16
      8.3. MTU Exceeded Return Code ..................................16
   9. References .....................................................16
      9.1. Normative References ......................................16
      9.2. Informative References ....................................17
   Acknowledgements ..................................................17
   Contributors ......................................................17
   Authors' Addresses ................................................18
        
1. Introduction
1. 介绍

This document describes extensions to the Label Switched Path (LSP) Ping specified in [RFC4379] by adding a Relayed Echo Reply mechanism that could be used to report data-plane failures for inter-AS (Autonomous System) and inter-area LSPs. Without these extensions, the ping functionality provided by [RFC4379] would fail in many deployed inter-AS scenarios, since the replying Label Switching Router (LSR) in one AS may not have an available route to the initiator in the other AS. The mechanism in this document defines a new Message Type referred to as the "Relayed Echo Reply message" and a new TLV referred to as the "Relay Node Address Stack TLV".

本文档描述了[RFC4379]中规定的标签交换路径(LSP)Ping的扩展,添加了中继回音回复机制,可用于报告AS(自治系统)和区域间LSP的数据平面故障。如果没有这些扩展,[RFC4379]提供的ping功能将在许多部署的AS间场景中失败,因为一个AS中的应答标签交换路由器(LSR)可能没有到另一个AS中启动器的可用路由。本文档中的机制定义了一种称为“中继回显回复消息”的新消息类型和一种称为“中继节点地址堆栈TLV”的新TLV。

This document updates [RFC4379]; it includes updates to the Echo Request sending procedure in Section 4.3 of [RFC4379], the Echo Request receiving procedure in Section 4.4 of [RFC4379], the Echo Reply sending procedure in Section 4.5 of [RFC4379], and the Echo Reply receiving procedure in Section 4.6 of [RFC4379].

本文件更新了[RFC4379];它包括对[RFC4379]第4.3节中回声请求发送程序、[RFC4379]第4.4节中回声请求接收程序、[RFC4379]第4.5节中回声回复发送程序以及[RFC4379]第4.6节中回声回复接收程序的更新。

1.1. Conventions Used in This Document
1.1. 本文件中使用的公约

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]中所述进行解释。

2. Motivation
2. 动机

LSP Ping [RFC4379] defines a mechanism to detect data-plane failures and localize faults. The mechanism specifies that the Echo Reply should be sent back to the initiator using a UDP packet with the IPv4/IPv6 destination address set to an address of the LSR that originated the Echo Request. This works in administrative domains where IP-address reachability is allowed among LSRs and every LSR is able to route back to the originating LSR. However, in practice, this is often not the case due to intra-provider routing policy, route hiding, and network address translation at Autonomous System Border Routers (ASBRs). In fact, it is almost always the case that in inter-AS scenarios, the only node in one AS to which direct routing is allowed from the other AS is the ASBR, and routing information from within one AS is not distributed into another AS.

LSP Ping[RFC4379]定义了一种检测数据平面故障和定位故障的机制。该机制指定应使用UDP数据包将回送回复发送回启动器,并将IPv4/IPv6目标地址设置为发起回送请求的LSR的地址。这适用于管理域,其中允许LSR之间的IP地址可达性,并且每个LSR都能够路由回原始LSR。然而,在实践中,由于自治系统边界路由器(ASBR)上的提供商内部路由策略、路由隐藏和网络地址转换,情况往往并非如此。事实上,在AS间场景中,一个AS中唯一允许从另一个AS直接路由到的节点是ASBR,并且一个AS中的路由信息不会分布到另一个AS中。

Figure 1 demonstrates a case where an LSP is set up between PE1 and PE2. If PE1's IP address is not distributed to AS2, a traceroute from PE1 directed towards PE2 can result in a failure because an LSR in AS2 may not be able to send the Echo Reply message. For example, P2 cannot forward packets back to PE1 given that it is a routable IP address in AS1 but not routable in AS2. In this case, PE1 would

图1演示了在PE1和PE2之间设置LSP的情况。如果PE1的IP地址未分配给AS2,则从PE1指向PE2的跟踪路由可能会导致失败,因为AS2中的LSR可能无法发送回显回复消息。例如,P2无法将数据包转发回PE1,因为它在AS1中是可路由的IP地址,但在AS2中不可路由。在这种情况下,PE1将

detect a path break, as the Echo Reply messages would not be received. Then, localization of the actual fault would not be possible.

检测路径中断,因为无法接收回显回复消息。这样,实际故障的定位就不可能了。

Note that throughout the document, "routable address" means that it is possible to route an IP packet to this address using the normal information exchanged by the IGP and BGP (or EGP) operating in the AS.

注意,在整个文档中,“可路由地址”意味着可以使用在AS中运行的IGP和BGP(或EGP)交换的正常信息将IP分组路由到此地址。

   +-------+   +-------+   +------+   +------+   +------+   +------+
   |       |   |       |   |      |   |      |   |      |   |      |
   |  PE1  +---+   P1  +---+ ASBR1+---+ ASBR2+---+  P2  +---+  PE2 |
   |       |   |       |   |      |   |      |   |      |   |      |
   +-------+   +-------+   +------+   +------+   +------+   +------+
   <---------------AS1-------------><---------------AS2------------>
   <---------------------------- LSP ------------------------------>
        
   +-------+   +-------+   +------+   +------+   +------+   +------+
   |       |   |       |   |      |   |      |   |      |   |      |
   |  PE1  +---+   P1  +---+ ASBR1+---+ ASBR2+---+  P2  +---+  PE2 |
   |       |   |       |   |      |   |      |   |      |   |      |
   +-------+   +-------+   +------+   +------+   +------+   +------+
   <---------------AS1-------------><---------------AS2------------>
   <---------------------------- LSP ------------------------------>
        

Figure 1: Simple Inter-AS LSP Configuration

图1:简单的内部AS LSP配置

A second example that illustrates how [RFC4379] would be insufficient would be the inter-area situation in a seamless MPLS architecture [MPLSARCH] as shown below in Figure 2. In this example, LSRs in the core network would not have an IP-reachable route to any of the access nodes (ANs). When tracing an LSP from one AN to the remote AN, the LSR1/LSR2 node cannot send the Echo Reply either, like the P2 node in the inter-AS scenario in Figure 1.

第二个例子说明了[RFC4379]的不足之处,即无缝MPLS体系结构[MPLSARCH]中的区域间情况,如下图2所示。在此示例中,核心网络中的LSR将不具有到任何接入节点(an)的IP可到达路由。当从一个an跟踪LSP到远程an时,LSR1/LSR2节点也不能发送回显回复,就像图1中inter-AS场景中的P2节点一样。

              +-------+   +-------+   +------+   +------+
              |       |   |       |   |      |   |      |
           +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
          /   |       |  /|       |   |      |   |      |
   +----+/    +-------+\/ +-------+   +------+  /+------+
   | AN |              /\                     \/
   +----+\    +-------+  \+-------+   +------+/\ +------+
          \   |       |   |       |   |      |  \|      |
           +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
              |       |   |       |   |      |   |      |
              +-------+   +-------+   +------+   +------+
   static route    IS-IS L1 LDP            IS-IS L2 LDP
   <-Access-><--Aggregation Domain--><---------Core--------->
        
              +-------+   +-------+   +------+   +------+
              |       |   |       |   |      |   |      |
           +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
          /   |       |  /|       |   |      |   |      |
   +----+/    +-------+\/ +-------+   +------+  /+------+
   | AN |              /\                     \/
   +----+\    +-------+  \+-------+   +------+/\ +------+
          \   |       |   |       |   |      |  \|      |
           +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
              |       |   |       |   |      |   |      |
              +-------+   +-------+   +------+   +------+
   static route    IS-IS L1 LDP            IS-IS L2 LDP
   <-Access-><--Aggregation Domain--><---------Core--------->
        

AGN: aggregation node

AGN:聚合节点

Figure 2: Seamless MPLS Architecture

图2:无缝MPLS体系结构

This document describes extensions to the LSP Ping mechanism to facilitate a response from the replying LSR by defining a mechanism that uses a relay node (e.g., ASBR) to relay the message back to the initiator. Every designated or learned relay node must be reachable to the next relay node or to the initiator. Using a recursive approach, a relay node could relay the message to the next relay node until the initiator is reached.

本文档描述了LSP Ping机制的扩展,通过定义一种使用中继节点(例如ASBR)将消息中继回发起方的机制来促进来自应答LSR的响应。每个指定的或学习到的中继节点必须能够到达下一个中继节点或启动器。使用递归方法,中继节点可以将消息中继到下一个中继节点,直到到达启动器。

The LSP Ping relay mechanism in this document is defined for unicast. How to apply the LSP Ping relay mechanism in multicast is out of scope.

本文档中的LSP Ping中继机制是为单播定义的。如何在多播中应用LSP Ping中继机制超出了范围。

3. Extensions
3. 扩展

[RFC4379] defines two Message Types: Echo Request and Echo Reply. This document defines a new Message Type: Relayed Echo Reply. The Relayed Echo Reply message is used in place of the Echo Reply message when an LSR is replying LSR to a relay node.

[RFC4379]定义了两种消息类型:回显请求和回显回复。本文档定义了一种新的消息类型:中继回显回复。当LSR向中继节点回复LSR时,使用中继回显回复消息代替回显回复消息。

A new TLV named the "Relay Node Address Stack TLV" is defined in this document to carry the IP addresses of the relay nodes for the replying LSR.

本文档中定义了一个名为“中继节点地址堆栈TLV”的新TLV,用于承载应答LSR的中继节点的IP地址。

In addition, the Maximum Transmission Unit (MTU) Exceeded Return Code is defined to indicate to the initiator that one or more TLVs will not be returned due to the MTU size.

此外,定义了超出最大传输单元(MTU)的返回代码,以向启动器指示由于MTU大小,一个或多个TLV将不会返回。

It should be noted that this document focuses only on detecting the LSP that is set up using a uniform IP address family type. That is, all hops between the source and destination node use the same address family type for their LSP Ping control planes. This does not preclude nodes that support both IPv6 and IPv4 addresses simultaneously, but the entire path must be addressable using only one address family type. Support for mixed IPv4-only and IPv6-only is beyond the scope of this document.

应注意,本文档仅关注检测使用统一IP地址族类型设置的LSP。也就是说,源节点和目标节点之间的所有跃点对其LSP Ping控制平面使用相同的地址族类型。这并不排除同时支持IPv6和IPv4地址的节点,但整个路径必须只能使用一种地址族类型进行寻址。对仅IPv4和仅IPv6混合的支持超出了本文档的范围。

3.1. Relayed Echo Reply Message
3.1. 中继回音回复消息

The Relayed Echo Reply message is a UDP packet, and the UDP payload has the same format with Echo Request/Reply message. A new Message Type is requested from IANA.

中继回显回复消息是UDP数据包,UDP有效负载的格式与回显请求/回复消息相同。已从IANA请求新的消息类型。

   New Message Type:
       Value    Meaning
       -----    -------
       5        MPLS Relayed Echo Reply
        
   New Message Type:
       Value    Meaning
       -----    -------
       5        MPLS Relayed Echo Reply
        

The use of TCP and UDP port number 3503 is described in [RFC4379] and has been allocated by IANA for LSP Ping messages. The Relayed Echo Reply message will use the same port number.

[RFC4379]中描述了TCP和UDP端口号3503的使用,IANA已将其分配给LSP Ping消息。中继回显回复消息将使用相同的端口号。

3.2. Relay Node Address Stack
3.2. 中继节点地址栈

The Relay Node Address Stack TLV is an optional TLV. It MUST be carried in the Echo Request, Echo Reply, and Relayed Echo Reply messages if the Echo Reply relayed mechanism described in this document is required. Figure 3 illustrates the TLV format.

中继节点地址堆栈TLV是可选的TLV。如果需要本文档中描述的回送回复中继机制,则必须在回送请求、回送回复和中继回送回复消息中携带。图3说明了TLV格式。

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Type           |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Initiator Source Port       | Reply Add Type|   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Source Address of Replying Router (0, 4, or 16 octets)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Destination Address Offset   |   Number of Relayed Addresses |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                Stack of Relayed Addresses                     ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Type           |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Initiator Source Port       | Reply Add Type|   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Source Address of Replying Router (0, 4, or 16 octets)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Destination Address Offset   |   Number of Relayed Addresses |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                Stack of Relayed Addresses                     ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 3: Relay Node Address Stack TLV

图3:中继节点地址堆栈TLV

- Type: Value is 32768. The value has been assigned by IANA from the 32768-49161 range as suggested by [RFC4379], Section 3.

- 类型:值为32768。IANA根据[RFC4379]第3节的建议,从32768-49161范围内分配了该值。

- Length: The length of the value field in octets.

- 长度:值字段的长度(以八位字节为单位)。

- Initiator Source Port: The source UDP port that the initiator uses in the Echo Request message, and the port that is expected to receive the Echo Reply message.

- 启动器源端口:启动器在回显请求消息中使用的源UDP端口,以及预期接收回显回复消息的端口。

- Reply Address Type: Address type of replying router. This value also implies the length of the address field as shown below.

- 应答地址类型:应答路由器的地址类型。该值还表示地址字段的长度,如下所示。

   Type#   Address Type   Address Length
   ----    ------------   ------------
   0       Null           0
   1       IPv4           4
   2       IPv6           16
        
   Type#   Address Type   Address Length
   ----    ------------   ------------
   0       Null           0
   1       IPv4           4
   2       IPv6           16
        

- Reserved: This field is reserved and MUST be set to zero.

- 保留:此字段为保留字段,必须设置为零。

- Source Address of Replying Router: Source IP address of the originator of Echo Reply or Relay Echo Reply message.

- 应答路由器的源地址:回显应答或中继回显应答消息的发起者的源IP地址。

- Destination Address Offset: The offset in octets from the top-of-stack to the destination address entry. Each entry size has been listed in this section. Please also refer to Section 4.2 for more detail of the operation.

- 目标地址偏移量:堆栈顶部到目标地址项的偏移量(以八位字节为单位)。本节列出了每个条目的大小。有关操作的更多详情,请参阅第4.2节。

- Number of Relayed Addresses: An integer indicating the number of relayed addresses in the stack.

- 中继地址数:表示堆栈中中继地址数的整数。

- Stack of Relayed Addresses: A list of relay node address entries. This stack grows downward, with relay node addresses that are further along the LSP appearing lower down in the stack. Please refer to Section 4.2 for the relay node discovery mechanism.

- 中继地址堆栈:中继节点地址项的列表。此堆栈向下增长,沿LSP更远的中继节点地址在堆栈中显示得更低。有关中继节点发现机制,请参阅第4.2节。

The format of each relay node address entry is as below:

每个中继节点地址条目的格式如下:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Address  Type |K|  Reserved   |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~           Relayed Address (0, 4, or 16 octets)                ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Address  Type |K|  Reserved   |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~           Relayed Address (0, 4, or 16 octets)                ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 4: Relay Node Address Entry

图4:中继节点地址条目

   Type#   Address Type   Address Length   Size of the Entry
   ----    ------------   ------------     -----------------
   0       Null           0                4
   1       IPv4           4                8
   2       IPv6           16               20
        
   Type#   Address Type   Address Length   Size of the Entry
   ----    ------------   ------------     -----------------
   0       Null           0                4
   1       IPv4           4                8
   2       IPv6           16               20
        

Reserved: The two fields are reserved and MUST be set to zero.

保留:这两个字段是保留的,必须设置为零。

K bit: If the K bit is set to 1, then this address stack entry MUST NOT be stripped from the Relay Node Address Stack during the processing described in Section 4.2. If the K bit is clear, the entry might be stripped according to the processing described in Section 4.2.

K位:如果K位设置为1,则在第4.2节所述的处理过程中,不得从中继节点地址堆栈中剥离此地址堆栈条目。如果K位是清除的,则可以根据第4.2节中描述的处理去除条目。

Having the K bit set in the relay node address entry causes that entry to be preserved in the Relay Node Address Stack TLV for the entire traceroute operation. A responder node MAY set the K bit to ensure its relay node address entry remains as one of the relay nodes

在中继节点地址条目中设置K位会导致该条目在整个跟踪路由操作中保留在中继节点地址堆栈TLV中。应答器节点可设置K位以确保其中继节点地址条目保持为中继节点之一

in the Relay Node Address Stack TLV. The address with the K bit set will always be a relay node address for the Relayed Echo Reply, see Section 4.3.

在中继节点地址堆栈TLV中。设置了K位的地址将始终是中继回音应答的中继节点地址,见第4.3节。

Relayed Address: This field specifies the node address: either IPv4 or IPv6.

中继地址:此字段指定节点地址:IPv4或IPv6。

3.3. MTU Exceeded Return Code
3.3. MTU超出返回代码

This Return Code is defined to indicate that one or more TLVs were omitted from the Echo Reply or Relayed Echo Reply message to avoid exceeding the message's effective MTU size. These TLVs MAY be included in an Errored TLV's Object with their lengths set to 0 and no value. The return sub-code MUST be set to the value that otherwise would have been sent. For more detail, please refer to Section 4.2.

此返回码的定义是为了指示回送回复或中继回送回复消息中省略了一个或多个TLV,以避免超过消息的有效MTU大小。这些TLV可能包含在出错TLV的对象中,其长度设置为0且无值。返回子代码必须设置为否则将被发送的值。有关更多详细信息,请参阅第4.2节。

   MTU Exceeded Return Code:
       Value    Meaning
       -----    -------
       20       One or more TLVs not returned due to MTU size
        
   MTU Exceeded Return Code:
       Value    Meaning
       -----    -------
       20       One or more TLVs not returned due to MTU size
        

This document updates step 7 in Section 4.4 of [RFC4379] to integrate the processing of the MTU Exceeded Return Code by adding the following text:

本文件更新了[RFC4379]第4.4节中的步骤7,通过添加以下文本整合了MTU超出返回代码的处理:

Before sending Echo Reply, the new packet size should be checked. If Best-return-code is 3 ("Replying router is an egress for the FEC at stack depth"), or 8 ("Label switched at stack-depth"), and if the packet size exceeds MTU size, then Best-return-code is 20 ("One or more TLVs not returned due to MTU size").

在发送回显回复之前,应检查新的数据包大小。如果最佳返回码为3(“应答路由器是FEC在堆栈深度的出口”)或8(“标签在堆栈深度交换”),并且如果包大小超过MTU大小,则最佳返回码为20(“由于MTU大小而未返回一个或多个TLV”)。

4. Procedures
4. 程序

To perform a ping operation, the initiator first discovers the relay nodes. Once those nodes have been discovered, the initiator includes the Relay Node Address Stack TLV into any Echo Request message. The node can then ping as normal. Note that, in some cases, the repeated lack of replies to Echo Request messages may be due to a route change that has impacted the necessary stack of relay nodes. In this case, the initiator may need to rediscover the relay nodes. The following sections describe the procedures for sending and receiving Echo Request messages with the Relay Node Address Stack TLV. These procedures can be used in traceroute mode to discover the relay nodes.

要执行ping操作,启动器首先发现中继节点。一旦发现了这些节点,启动器就会将中继节点地址堆栈TLV包含到任何回显请求消息中。然后,节点可以正常ping。请注意,在某些情况下,重复缺少对回显请求消息的响应可能是由于路由更改影响了必要的中继节点堆栈。在这种情况下,启动器可能需要重新发现中继节点。以下各节描述使用中继节点地址堆栈TLV发送和接收回显请求消息的过程。这些过程可在跟踪路由模式下用于发现中继节点。

4.1. Sending an Echo Request
4.1. 发送回显请求

In addition to the procedures described in Section 4.3 of [RFC4379], a Relay Node Address Stack TLV MUST be carried in the Echo Request message if the relay functionality is required. The relay function initiation is out of the scope of this document. One possible way to do this is that the operator can explicitly add an option to the ping command.

除了[RFC4379]第4.3节中描述的程序外,如果需要中继功能,则回波请求消息中必须携带中继节点地址堆栈TLV。继电器功能启动不在本文件范围内。一种可能的方法是,操作员可以显式地向ping命令添加一个选项。

When the initiator sends the first Echo Request with a Relay Node Address Stack TLV, the TLV MUST contain the initiator address as the first entry of the stack of relayed addresses, the Destination Address Offset set to this entry, and the source address of the replying router set to null. The Initiator Source Port field MUST be set to the source UDP port. Note that the first relay node address in the stack will always be the initiator's address.

当启动器发送带有中继节点地址堆栈TLV的第一个回显请求时,TLV必须包含启动器地址作为中继地址堆栈的第一个条目,目标地址偏移量设置为该条目,应答路由器的源地址设置为null。启动器源端口字段必须设置为源UDP端口。请注意,堆栈中的第一个中继节点地址始终是启动器的地址。

When sending a subsequent Echo Request message, refer to Section 4.6.

发送后续回显请求消息时,请参阅第4.6节。

4.2. Receiving an Echo Request
4.2. 接收回显请求

The Type of the Relay Node Address Stack TLV (32768) falls within the range defined in [RFC4379] as "optional TLVs" that can be silently dropped if not recognized. An LSR that does not recognize the TLV SHOULD ignore it.

中继节点地址堆栈TLV(32768)的类型在[RFC4379]中定义的范围内,称为“可选TLV”,如果无法识别,则可以静默删除。不识别TLV的LSR应忽略它。

In addition to the processes in Section 4.4 of [RFC4379], the procedures of the Relay Node Address Stack TLV are defined here.

除了[RFC4379]第4.4节中的过程外,这里还定义了中继节点地址堆栈TLV的过程。

Upon receiving a Relay Node Address Stack TLV in an Echo Request message, the receiver updates the "Source Address of Replying Router". The address MUST be the same as the source IP address of Relay Echo Reply (Section 4.3) or Echo Reply message (Section 4.5) being sent.

在接收回显请求消息中的中继节点地址堆栈TLV时,接收器更新“应答路由器的源地址”。该地址必须与正在发送的中继回送回复(第4.3节)或回送回复消息(第4.5节)的源IP地址相同。

Those address entries with the K bit set to 1 MUST be kept in the stack. The receiver MUST check the addresses of the stack in sequence from bottom to top to find the last address in the stack with the K bit set (or the top of the stack if no K bit was found). The receiver then checks the stack beginning with this entry, proceeding towards the bottom to find the first routable address IP address. The Destination Address Offset MUST be set to this entry, which is also the resolved destination address. Address entries below the first routable IP address MUST be deleted. At least one address entry of the replying LSR MUST be added at the bottom of the stack. A second address entry (or more) MAY also be added if necessary, depending on implementation. The final address added MUST be an address that is reachable through the interface that the Echo

K位设置为1的地址项必须保留在堆栈中。接收器必须按从下到上的顺序检查堆栈的地址,以找到设置了K位的堆栈中的最后一个地址(如果未找到K位,则检查堆栈顶部)。然后,接收器从这个条目开始检查堆栈,向底部继续查找第一个可路由地址IP地址。必须将目标地址偏移量设置为此条目,该条目也是已解析的目标地址。必须删除第一个可路由IP地址下面的地址条目。必须在堆栈底部至少添加一个应答LSR的地址项。根据实现情况,如有必要,还可以添加第二个(或更多)地址条目。添加的最终地址必须是一个可通过Echo提供的接口访问的地址

Request message would have been forwarded to if its TTL had not expired at this node. The updated Relay Node Address Stack TLV MUST be carried in the response message.

如果请求消息的TTL在此节点上未过期,则请求消息将被转发到。更新的中继节点地址堆栈TLV必须包含在响应消息中。

If the replying LSR is configured to hide its routable address information, the address entry added in the stack MUST be a NIL entry with Address Type set to NULL.

如果应答LSR配置为隐藏其可路由地址信息,则堆栈中添加的地址项必须是地址类型设置为NULL的NIL项。

If a node spans two addressing domains (with respect to this message) where nodes on either side may not be able to reach nodes in the other domain, then the final address added SHOULD set the K bit. One example of spanning two address domains is the ASBR node.

如果一个节点跨越两个寻址域(关于此消息),其中任何一方的节点可能无法到达另一个域中的节点,则添加的最终地址应设置K位。跨越两个地址域的一个示例是ASBR节点。

K bit applies in the case of a NULL address, to serve as a warning to the initiator that further Echo Request messages may not result in receiving Echo Reply messages.

K位适用于空地址的情况,作为对启动器的警告,进一步的回显请求消息可能不会导致接收回显回复消息。

If the full reply message would exceed the MTU size, the Relay Node Address Stack TLV SHOULD be included in the Echo Reply message (i.e., other optional TLVs are excluded).

如果完整回复消息将超过MTU大小,则中继节点地址堆栈TLV应包含在回送回复消息中(即,排除其他可选TLV)。

4.3. Originating a Relayed Echo Reply
4.3. 发起中继回音应答

The destination address determined as described in Section 4.2 is used as the next relay node address. If the resolved next relay node address is not routable, then the sending of the Relayed Echo Reply or Echo Reply will fail.

按照第4.2节所述确定的目的地地址用作下一个中继节点地址。如果解析的下一个中继节点地址不可路由,则中继回送回复或回送回复的发送将失败。

If the first IP address in the Relay Node Address Stack TLV is not the next relay node address, the replying LSR SHOULD send a Relayed Echo Reply message to the next relay node. The processing of Relayed Echo Reply is the same with the procedure of the Echo Reply described in Section 4.5 of [RFC4379], except the destination IP address and the destination UDP port. The destination IP address of the Relayed Echo Reply is set to the next relay node address from the Relay Node Address Stack TLV, and both the source and destination UDP port are set to 3503. The updated Relay Node Address Stack TLV described in Section 4.2 MUST be carried in the Relayed Echo Reply message. The Source Address of the Replying Router field is kept unmodified, and the Source IP address field of the IP header is set to an address of the sending node.

如果中继节点地址堆栈TLV中的第一个IP地址不是下一个中继节点地址,则应答LSR应向下一个中继节点发送中继回显应答消息。中继回显回复的处理与[RFC4379]第4.5节中描述的回显回复过程相同,但目标IP地址和目标UDP端口除外。中继回显应答的目标IP地址设置为中继节点地址堆栈TLV中的下一个中继节点地址,并且源和目标UDP端口都设置为3503。第4.2节中描述的更新的中继节点地址堆栈TLV必须在中继回显回复消息中携带。应答路由器字段的源地址保持不变,IP报头的源IP地址字段设置为发送节点的地址。

When the next relay node address is the first one in the address list, please refer to Section 4.5.

当下一个中继节点地址是地址列表中的第一个地址时,请参考第4.5节。

4.4. Relaying a Relayed Echo Reply
4.4. 中继一个中继回音应答

Upon receiving a Relayed Echo Reply message with its own address as the destination address in the IP header, the relay node MUST determine the next relay node address as described in Section 4.2, with the modification that the location of the received destination address is used instead of the bottom of stack in the algorithm. The Destination Address Offset in Relay Node Address Stack TLV will be set to the next relay node address. Note that unlike in Section 4.2, no changes are made to the Stack of Relayed Addresses.

在接收到中继回显回复消息(其自身地址作为IP报头中的目标地址)后,中继节点必须按照第4.2节所述确定下一个中继节点地址,修改为使用接收到的目标地址的位置,而不是算法中的堆栈底部。中继节点地址堆栈TLV中的目标地址偏移量将设置为下一个中继节点地址。请注意,与第4.2节不同的是,中继地址堆栈未做任何更改。

If the next relay node address is not the first one in the address list, i.e., another intermediate relay node, the relay node MUST send a Relayed Echo Reply message to the determined upstream node with the payload unchanged other than the Relay Node Address Stack TLV. The TTL SHOULD be copied from the received Relay Echo Reply and decremented by 1. The Source Address of the Replying Router field is kept unmodified and the Source IP address field of the IP header is set to an address of the sending node.

如果下一个中继节点地址不是地址列表中的第一个地址,即另一个中间中继节点,则中继节点必须向确定的上游节点发送中继回送回复消息,有效负载保持不变,中继节点地址堆栈TLV除外。TTL应从接收到的中继回波应答中复制,并递减1。应答路由器字段的源地址保持不变,IP报头的源IP地址字段设置为发送节点的地址。

When the next relay node address is the first one in the address list, please refer to Section 4.5.

当下一个中继节点地址是地址列表中的第一个地址时,请参考第4.5节。

4.5. Sending an Echo Reply
4.5. 发送回音回复

The Echo Reply is sent in two cases:

回送回复在两种情况下发送:

1. When the replying LSR receives an Echo Request, and the first IP address in the Relay Node Address Stack TLV is the next relay node address (Section 4.3), the replying LSR would send an Echo Reply to the initiator. In addition to the procedure of the Echo Reply described in Section 4.5 of [RFC4379], the updated Relay Node Address Stack TLV described in Section 4.2 MUST be carried in the Echo Reply.

1. 当应答LSR接收到回显请求,并且中继节点地址堆栈TLV中的第一个IP地址是下一个中继节点地址(第4.3节)时,应答LSR将向启动器发送回显应答。除了[RFC4379]第4.5节中描述的回送回复程序外,第4.2节中描述的更新中继节点地址堆栈TLV必须包含在回送回复中。

If the receiver does not recognize the Relay Node Address Stack TLV, as per Sections 3 and 4.5 of [RFC4379], it will send an Echo Reply without including the TLV.

根据[RFC4379]第3节和第4.5节,如果接收器无法识别中继节点地址堆栈TLV,则将发送不包括TLV的回显回复。

2. When the intermediate relay node receives a Relayed Echo Reply, and the first IP address in the Relay Node Address Stack TLV is the next relay node address (Section 4.4), the intermediate relay node will send the Echo Reply to the initiator, and update the Message Type field from type of "Relayed Echo Reply" to "Echo Reply". The updated Relay Node Address Stack TLV described in Section 4.4 MUST be carried in the Echo Reply. The destination IP address of the Echo Reply is set to the first IP address in

2. 当中间中继节点接收到中继回显回复,并且中继节点地址堆栈TLV中的第一个IP地址是下一个中继节点地址(第4.4节)时,中间中继节点将向启动器发送回显回复,并将消息类型字段从“中继回显回复”类型更新为“回显回复”。第4.4节中描述的更新的中继节点地址堆栈TLV必须包含在回送应答中。回显回复的目标IP地址设置为中的第一个IP地址

the stack, and the destination UDP port will be copied from the Initiator Source Port field of the Relay Node Address Stack TLV. The source UDP port should be 3503. The TTL of the Echo Reply SHOULD be copied from the received Relay Echo Reply and decremented by 1. The Source Address of the Replying Router field is kept unmodified, and the Source IP address field of the IP header is set to an address of the sending node.

堆栈和目标UDP端口将从中继节点地址堆栈TLV的启动器源端口字段复制。源UDP端口应为3503。回送回复的TTL应从接收到的中继回送回复中复制,并递减1。应答路由器字段的源地址保持不变,IP报头的源IP地址字段设置为发送节点的地址。

4.6. Sending Subsequent Echo Requests
4.6. 发送后续回显请求

During a traceroute operation, multiple Echo Request messages are sent. Each time the TTL is increased, the initiator SHOULD copy the Relay Node Address Stack TLV received in the previous Echo Reply to the next Echo Request. The Relay Node Address Stack TLV MUST NOT be modified except as follows. A NIL entry that does not have the K bit set MAY be removed. A NIL entry with the K bit serves as a warning that further Echo Request messages are likely not to result in a reply. If, however, the initiator decides to continue a traceroute operation, the NIL entry with the K bit set MUST be removed. The Source Address of the Replying Router and Destination Address Offset fields may be preserved or reset since these fields are ignored in the received MPLS Echo Request.

在跟踪路由操作期间,会发送多个回显请求消息。每次TTL增加时,启动器都应将在上一个回显回复中接收到的中继节点地址堆栈TLV复制到下一个回显请求。不得修改中继节点地址堆栈TLV,以下情况除外。可以删除未设置K位的NIL条目。带有K位的NIL条目用作警告,进一步的回显请求消息可能不会导致应答。但是,如果启动器决定继续跟踪路由操作,则必须删除设置了K位的NIL条目。应答路由器的源地址和目标地址偏移字段可以保留或重置,因为这些字段在收到的MPLS回送请求中被忽略。

4.7. Impact on Traceroute
4.7. 对示踪路由的影响

The Source IP address in Echo Reply and Relay Echo Reply should be the address of the node sending those packets, not the original responding node. Then the traceroute address output module will print the source IP address as below:

Echo Reply和中继Echo Reply中的源IP地址应该是发送这些数据包的节点的地址,而不是原始响应节点的地址。然后,跟踪路由地址输出模块将打印源IP地址,如下所示:

     if (Relay Node Address Stack TLV exists) {
   Print the Source Address of Replying Router in
   Relay Node Address Stack TLV;
     } else {
   Print the source IP address of Echo Reply message;
     }
        
     if (Relay Node Address Stack TLV exists) {
   Print the Source Address of Replying Router in
   Relay Node Address Stack TLV;
     } else {
   Print the source IP address of Echo Reply message;
     }
        
5. LSP Ping Relayed Echo Reply Example
5. LSP Ping中继回波应答示例

Considering the inter-AS scenario in Figure 5 below, AS1 and AS2 are two independent address domains. In the example, an LSP has been created between PE1 to PE2, but PE1 in AS1 is not reachable by P2 in AS2.

考虑到下面图5中的inter-AS场景,AS1和AS2是两个独立的地址域。在该示例中,已在PE1到PE2之间创建了LSP,但AS1中的PE1无法由AS2中的P2访问。

   +-------+   +-------+   +------+   +------+   +------+   +------+
   |       |   |       |   |      |   |      |   |      |   |      |
   |  PE1  +---+   P1  +---+ ASBR1+---+ ASBR2+---+  P2  +---+  PE2 |
   |       |   |       |   |      |   |      |   |      |   |      |
   +-------+   +-------+   +------+   +------+   +------+   +------+
   <---------------AS1-------------><---------------AS2------------>
   <--------------------------- LSP ------------------------------->
        
   +-------+   +-------+   +------+   +------+   +------+   +------+
   |       |   |       |   |      |   |      |   |      |   |      |
   |  PE1  +---+   P1  +---+ ASBR1+---+ ASBR2+---+  P2  +---+  PE2 |
   |       |   |       |   |      |   |      |   |      |   |      |
   +-------+   +-------+   +------+   +------+   +------+   +------+
   <---------------AS1-------------><---------------AS2------------>
   <--------------------------- LSP ------------------------------->
        

Figure 5: Example Inter-AS LSP

图5:Inter AS LSP示例

When performing LSP traceroute on the LSP, the first Echo Request sent by PE1 with outermost label TTL=1 contains the Relay Node Address Stack TLV with PE1's address as the first relayed address.

在LSP上执行LSP跟踪路由时,PE1发送的最外层标签TTL=1的第一个回显请求包含中继节点地址堆栈TLV,PE1的地址作为第一个中继地址。

After being processed by P1, P1's interface address facing ASBR1 without the K bit set will be added in the Relay Node Address Stack TLV address list following PE1's address in the Echo Reply.

经过P1处理后,P1面向ASBR1的接口地址(未设置K位)将添加到中继节点地址堆栈TLV地址列表中,位于回显回复中PE1地址的后面。

PE1 copies the Relay Node Address Stack TLV into the next Echo Request when receiving the Echo Reply.

PE1在接收回显回复时,将中继节点地址堆栈TLV复制到下一个回显请求中。

Upon receiving the Echo Request, ASBR1 checks the address list in the Relay Node Address Stack TLV and determines that PE1's address is the next relay address. Then it deletes P1's address, and adds its interface address facing ASBR2 with the K bit set. As a result, there will be PE1's address followed by ASBR1's interface address facing ASBR2 in the Relay Node Address Stack TLV of the Echo Reply sent by ASBR1.

在收到回送请求后,ASBR1检查中继节点地址堆栈TLV中的地址列表,并确定PE1的地址是下一个中继地址。然后,它删除P1的地址,并将其面向ASBR2的接口地址与K位集相加。因此,在ASBR1发送的回送应答的中继节点地址堆栈TLV中,将有PE1的地址,后跟ASBR1面向ASBR2的接口地址。

PE1 then sends an Echo Request with outermost label TTL=3, containing the Relay Node Address Stack TLV copied from the received Echo Reply message. Upon receiving the Echo Request message, ASBR2 checks the address list in the Relay Node Address Stack TLV and determines that ASBR1's interface address is the next relay address in the stack TLV. ASBR2 adds its interface address facing P2 with the K bit set. Then ASBR2 sets the next relay address as the destination address of the Relayed Echo Reply and sends the Relayed Echo Reply to ASBR1.

然后,PE1发送一个最外层标签为TTL=3的回显请求,其中包含从接收到的回显回复消息复制的中继节点地址堆栈TLV。收到回送请求消息后,ASBR2检查中继节点地址堆栈TLV中的地址列表,并确定ASBR1的接口地址是堆栈TLV中的下一个中继地址。ASBR2将其面向P2的接口地址与K位集相加。然后ASBR2将下一个中继地址设置为中继回音应答的目标地址,并将中继回音应答发送给ASBR1。

Upon receiving the Relayed Echo Reply from ASBR2, ASBR1 checks the address list in the Relay Node Address Stack TLV and determines that PE1's address is the next relay node. Then ASBR1 sends an Echo Reply to PE1.

在接收到来自ASBR2的中继回显回复后,ASBR1检查中继节点地址堆栈TLV中的地址列表,并确定PE1的地址是下一个中继节点。然后ASBR1向PE1发送回显回复。

For the Echo Request with outermost label TTL=4, P2 checks the address list in the Relay Node Address Stack TLV and determines that ASBR2's interface address is the next relay address. Then P2 sends a Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV containing four addresses: PE1's, ASBR1's interface address, ASBR2's interface address, and P2's interface address facing PE2 in sequence.

对于最外层标签TTL=4的回显请求,P2检查中继节点地址堆栈TLV中的地址列表,并确定ASBR2的接口地址是下一个中继地址。然后,P2向ASBR2发送一个中继回音应答,中继节点地址堆栈TLV包含四个地址:PE1、ASBR1的接口地址、ASBR2的接口地址和P2的接口地址,依次面向PE2。

Then, according to the process described in Section 4.4, ASBR2 sends the Relayed Echo Reply to ASBR1. Upon receiving the Relayed Echo Reply, ASBR1 sends an Echo Reply to PE1. And, as relayed by ASBR2 and ASBR1, the Echo Reply would finally be sent to the initiator PE1.

然后,根据第4.4节中描述的过程,ASBR2向ASBR1发送中继回波应答。在接收到中继回音回复后,ASBR1向PE1发送回音回复。并且,正如ASBR2和ASBR1所中继的那样,回音应答最终将被发送到发起方PE1。

For the Echo Request with outermost label TTL=5, the Echo Reply would relayed to PE1 by ASBR2 and ASBR1, similar to the case of TTL=4.

对于最外层标签TTL=5的回显请求,回显回复将由ASBR2和ASBR1中继到PE1,类似于TTL=4的情况。

The Echo Reply from the replying node that has no IP reachable route to the initiator is thus transmitted to the initiator by multiple relay nodes.

因此,多个中继节点将来自没有到启动器的IP可到达路由的应答节点的回显应答发送到启动器。

6. Security Considerations
6. 安全考虑

The Relayed Echo Reply mechanism for LSP Ping creates an increased risk of DoS by putting the IP address of a target router in the Relay Node Address Stack. These messages could then be used to attack the control plane of an LSR by overwhelming it with these packets. A rate limiter SHOULD be applied to the well-known UDP port on the relay node as suggested in [RFC4379]. The node that acts as a relay node SHOULD validate the relay reply against a set of valid source addresses and discard packets from untrusted border router addresses. An implementation SHOULD provide such filtering capabilities.

LSP Ping的中继回显应答机制将目标路由器的IP地址放入中继节点地址堆栈,从而增加了拒绝服务的风险。然后,这些消息可以被用来攻击LSR的控制平面,方法是用这些数据包覆盖它。速率限制器应应用于中继节点上众所周知的UDP端口,如[RFC4379]中所建议。充当中继节点的节点应根据一组有效的源地址验证中继应答,并丢弃来自不受信任的边界路由器地址的数据包。实现应该提供这样的过滤功能。

If an operator wants to obscure their nodes, it is RECOMMENDED that they replace the replying node address that originated the Echo Reply with the NIL address entry in the Relay Node Address Stack TLV.

如果操作员想要隐藏其节点,建议他们用中继节点地址堆栈TLV中的NIL地址项替换发起回显应答的应答节点地址。

A receiver of an MPLS Echo Request could verify that the first address in the Relay Node Address Stack TLV is the same address as the source IP address field of the received IP header.

MPLS回显请求的接收器可以验证中继节点地址堆栈TLV中的第一个地址是否与接收到的IP报头的源IP地址字段相同。

The Relay Node Address Stack TLV has the path information of the LSP, and such information may be maliciously used by any uncontrolled LSR/ LER. We have two ways to reduce the path information in the TLV:

中继节点地址栈TLV具有LSP的路径信息,并且该信息可能被任何不受控制的LSR/LER恶意使用。我们有两种方法来减少TLV中的路径信息:

o It is recommended to clear the K bit in the relay address entry unless it must be set (e.g., as listed in Section 4.2).

o 建议清除中继地址条目中的K位,除非必须设置(如第4.2节所列)。

o It is recommended to use the NIL address entry to hide node information, if possible.

o 如果可能,建议使用NIL address条目隐藏节点信息。

Other security considerations discussed in [RFC4379] are also applicable to this document.

[RFC4379]中讨论的其他安全注意事项也适用于本文件。

7. Backward Compatibility
7. 向后兼容性

When one of the nodes along the LSP does not support the mechanism specified in this document, the node will ignore the Relay Node Address Stack TLV as described in Section 4.2. Then the initiator may not receive the Relay Node Address Stack TLV in Echo Reply message from that node. In this case, an indication should be reported to the operator, and the Relay Node Address Stack TLV in the next Echo Request message should be copied from the previous Echo Request, and continue the ping process. If the node described above is located between the initiator and the first relay node, the ping process could continue without interruption.

当LSP上的一个节点不支持本文件中规定的机制时,该节点将忽略第4.2节中所述的中继节点地址堆栈TLV。然后,启动器可能不会从该节点接收回显回复消息中的中继节点地址堆栈TLV。在这种情况下,应向操作员报告一个指示,下一个Echo请求消息中的中继节点地址堆栈TLV应从上一个Echo请求复制,并继续ping过程。如果上述节点位于发起方和第一中继节点之间,ping过程可以继续而不中断。

8. IANA Considerations
8. IANA考虑

IANA has assigned one new Message Type, one new TLV, and one Return Code.

IANA分配了一个新的消息类型、一个新的TLV和一个返回码。

8.1. MPLS Relayed Echo Reply
8.1. MPLS中继回音应答

One new Message Type from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the "Message Type" subregistry has been allocated:

已从“消息类型”子区的“多协议标签交换(MPLS)标签交换路径(LSPs)Ping参数”注册表中分配了一种新的消息类型:

        Value    Meaning
        -----    -------
        5        MPLS Relayed Echo Reply
        
        Value    Meaning
        -----    -------
        5        MPLS Relayed Echo Reply
        

The value has been assigned from the "Standards Action" [RFC5226] range (0-191) using the lowest free value within this range.

已使用该范围内的最低自由值,从“标准操作”[RFC5226]范围(0-191)中指定该值。

8.2. Relay Node Address Stack TLV
8.2. 中继节点地址栈

One new TLV from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the "TLVs" subregistry has been allocated:

已从“TLV”子区的“多协议标签交换(MPLS)标签交换路径(LSP)Ping参数”注册表中分配了一个新的TLV:

        Type    TLV Name
        ----    --------
        32768   Relay Node Address Stack TLV
        
        Type    TLV Name
        ----    --------
        32768   Relay Node Address Stack TLV
        

The value has been assigned from the "Standards Action" range (32768-49161) as suggested by [RFC4379] Sections 3 and 7.2 using the first free value within this range.

根据[RFC4379]第3节和第7.2节的建议,使用该范围内的第一个自由值,从“标准行动”范围(32768-49161)中指定了该值。

8.3. MTU Exceeded Return Code
8.3. MTU超出返回代码

The MTU Exceeded return code from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the "Return Codes"subregistry has been allocated:

已从“返回码”子区的“多协议标签交换(MPLS)标签交换路径(LSP)Ping参数”注册表中分配MTU超出的返回码:

       Value    Meaning
       -----    -------
       20       One or more TLVs not returned due to MTU size
        
       Value    Meaning
       -----    -------
       20       One or more TLVs not returned due to MTU size
        

The value has been assigned from the "Standards Action" range (0-191) using the lowest free value within this range.

已使用该范围内的最低自由值,从“标准操作”范围(0-191)中指定该值。

9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,DOI 10.17487/RFC2119,1997年3月<http://www.rfc-editor.org/info/rfc2119>.

[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.

[RFC4379]Kompella,K.和G.Swallow,“检测多协议标签交换(MPLS)数据平面故障”,RFC 4379,DOI 10.17487/RFC4379,2006年2月<http://www.rfc-editor.org/info/rfc4379>.

9.2. Informative References
9.2. 资料性引用

[MPLSARCH] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", Work in Progress, draft-ietf-mpls-seamless-mpls-07, June 2014.

[MPLSARCH]莱曼,N.,德雷恩,B.,菲尔斯菲尔斯,C.,康斯坦蒂诺维茨,M.,和D.斯坦伯格,“无缝MPLS架构”,正在进行的工作,草案-ietf-MPLS-无缝MPLS-072014年6月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5226]Narten,T.和H.Alvestrand,“在RFCs中编写IANA注意事项部分的指南”,BCP 26,RFC 5226,DOI 10.17487/RFC5226,2008年5月<http://www.rfc-editor.org/info/rfc5226>.

Acknowledgements

致谢

The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin, Gregory Mirsky, Nobo Akiya, and Joel M. Halpern for their valuable comments and suggestions.

作者要感谢卡洛斯·皮格纳塔罗、焦新文、曼努埃尔·保罗、洛亚·安德森、维姆·亨德里克斯、马赫·陈、托马斯·莫林、格雷戈里·米尔斯基、诺博·秋叶和乔尔·哈尔潘提出的宝贵意见和建议。

Contributors

贡献者

Ryan Zheng JSPTPD 371, Zhongshan South Road Nanjing 210006 China

中国南京市中山南路371号Ryan Zheng JSPTPD 210006

   Email: ryan.zhi.zheng@gmail.com
        
   Email: ryan.zhi.zheng@gmail.com
        

Authors' Addresses

作者地址

Jian Luo (editor) ZTE 50, Ruanjian Avenue Nanjing 210012 China

罗健(编辑)中国南京阮建大道50号中兴通讯210012

   Email: luo.jian@zte.com.cn
        
   Email: luo.jian@zte.com.cn
        

Lizhong Jin (editor) Shanghai China

金立中(编辑)中国上海

   Email: lizho.jin@gmail.com
        
   Email: lizho.jin@gmail.com
        

Thomas Nadeau (editor) Brocade

托马斯·纳多(编辑)博科

   Email: tnadeau@lucidvision.com
        
   Email: tnadeau@lucidvision.com
        

George Swallow (editor) Cisco Systems

George Swallow(编辑)思科系统

   Email: swallow@cisco.com
        
   Email: swallow@cisco.com