draft-ietf-mpls-lsp-ping-relay-reply-11.txt   rfc7743.txt 
Network Working Group J. Luo, Ed. Internet Engineering Task Force (IETF) J. Luo, Ed.
Internet-Draft ZTE Request for Comments: 7743 ZTE
Updates: 4379 (if approved) L. Jin, Ed. Updates: 4379 L. Jin, Ed.
Intended status: Standards Track Individual Category: Standards Track
Expires: April 7, 2016 T. Nadeau, Ed. ISSN: 2070-1721 T. Nadeau, Ed.
Lucidvision Brocade
G. Swallow, Ed. G. Swallow, Ed.
Cisco Cisco
October 5, 2015 January 2016
Relayed Echo Reply mechanism for LSP Ping Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping
draft-ietf-mpls-lsp-ping-relay-reply-11
Abstract Abstract
In some inter autonomous system (AS) and inter-area deployment In some inter-AS (Autonomous System) and inter-area deployment
scenarios for RFC 4379 "Label Switched Path (LSP) Ping and scenarios for RFC 4379 ("Label Switched Path (LSP) Ping and
Traceroute", a replying Label Switching Router (LSR) may not have the Traceroute"), a replying Label Switching Router (LSR) may not have
available route to an initiator, and the Echo Reply message sent to the available route to an initiator, and the Echo Reply message sent
the initiator would be discarded resulting in false negatives or to the initiator would be discarded, resulting in false negatives or
complete failure of operation of LSP Ping and Traceroute. This a complete failure of operation of the LSP Ping and Traceroute. This
document describes extensions to LSP Ping mechanism to enable the document describes extensions to the LSP Ping mechanism to enable the
replying LSR to have the capability to relay the Echo Response by a replying LSR to have the capability to relay the Echo Response by a
set of routable intermediate nodes to the initiator. This document set of routable intermediate nodes to the initiator. This document
updates RFC 4379. updates RFC 4379.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 7, 2016. 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.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document ..........................3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation ......................................................3
3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Extensions ......................................................5
3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . 5 3.1. Relayed Echo Reply Message .................................5
3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . 6 3.2. Relay Node Address Stack ...................................6
3.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 8 3.3. MTU Exceeded Return Code ...................................8
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Procedures ......................................................8
4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 9 4.1. Sending an Echo Request ....................................9
4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 9 4.2. Receiving an Echo Request ..................................9
4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 10 4.3. Originating a Relayed Echo Reply ..........................10
4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 11 4.4. Relaying a Relayed Echo Reply .............................11
4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 11 4.5. Sending an Echo Reply .....................................11
4.6. Sending Subsequent Echo Requests . . . . . . . . . . . . 12 4.6. Sending Subsequent Echo Requests ..........................12
4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 12 4.7. Impact on Traceroute ......................................12
5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 12 5. LSP Ping Relayed Echo Reply Example ............................13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations ........................................14
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15 7. Backward Compatibility .........................................15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations ............................................15
8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 15 8.1. MPLS Relayed Echo Reply ...................................15
8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. Relay Node Address Stack TLV ..............................16
8.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 16 8.3. MTU Exceeded Return Code ..................................16
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 9. References .....................................................16
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References ......................................16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References ....................................17
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 Acknowledgements ..................................................17
11.2. Informative References . . . . . . . . . . . . . . . . . 17 Contributors ......................................................17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses ................................................18
1. Introduction 1. Introduction
This document describes extensions to the Label Switched Path (LSP) This document describes extensions to the Label Switched Path (LSP)
Ping as specified in [RFC4379], by adding a relayed echo reply Ping specified in [RFC4379] by adding a Relayed Echo Reply mechanism
mechanism which could be used to report data plane failures for inter that could be used to report data-plane failures for inter-AS
autonomous system (AS) and inter-area LSPs. Without these (Autonomous System) and inter-area LSPs. Without these extensions,
extensions, the ping functionality provided by [RFC4379] would fail the ping functionality provided by [RFC4379] would fail in many
in many deployed inter-AS scenarios, since the replying Label deployed inter-AS scenarios, since the replying Label Switching
Switching Router (LSR) in one AS may not have an available route to Router (LSR) in one AS may not have an available route to the
the initiator in the other AS. The mechanism in this document initiator in the other AS. The mechanism in this document defines a
defines a new message type referred as "Relayed Echo Reply message", new Message Type referred to as the "Relayed Echo Reply message" and
and a new TLV referred as "Relay Node Address Stack TLV". a new TLV referred to as the "Relay Node Address Stack TLV".
This document is also to update [RFC4379], include updating of Echo This document updates [RFC4379]; it includes updates to the Echo
Request sending procedure in section 4.3 of [RFC4379], Echo Request Request sending procedure in Section 4.3 of [RFC4379], the Echo
receiving procedure in section 4.4 of [RFC4379], Echo Reply sending Request receiving procedure in Section 4.4 of [RFC4379], the Echo
procedure in Section 4.5 of [RFC4379], Echo Reply receiving procedure Reply sending procedure in Section 4.5 of [RFC4379], and the Echo
in section 4.6 of [RFC4379]. Reply receiving procedure in Section 4.6 of [RFC4379].
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Motivation 2. Motivation
LSP Ping [RFC4379] defines a mechanism to detect data plane failures LSP Ping [RFC4379] defines a mechanism to detect data-plane failures
and localize faults. The mechanism specifies that the Echo Reply and localize faults. The mechanism specifies that the Echo Reply
should be sent back to the initiator using an UDP packet with the 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 IPv4/IPv6 destination address set to an address of the LSR that
originated the Echo Request. This works in administrative domains originated the Echo Request. This works in administrative domains
where IP address reachability is allowed among LSRs, and every LSR is where IP-address reachability is allowed among LSRs and every LSR is
able to route back to the originating LSR. However, in practice, able to route back to the originating LSR. However, in practice,
this is often not the case due to intra-provider routing policy, this is often not the case due to intra-provider routing policy,
route hiding, and network address translation at autonomous system route hiding, and network address translation at Autonomous System
border routers (ASBR). In fact, it is almost always the case that in Border Routers (ASBRs). In fact, it is almost always the case that
inter-AS scenarios the only node in one AS to which direct routing is in inter-AS scenarios, the only node in one AS to which direct
allowed from the other AS is the ASBR, and routing information from routing is allowed from the other AS is the ASBR, and routing
within one AS is not distributed into another AS. information from within one AS is not distributed into another AS.
Figure 1 demonstrates a case where an LSP is set up between PE1 and 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 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 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. E.g., P2 in AS2 may not be able to send the Echo Reply message. For example,
cannot forward packets back to PE1 given that it is an routable IP 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 address in AS1 but not routable in AS2. In this case, PE1 would
detect a path break, as the Echo Reply messages would not be detect a path break, as the Echo Reply messages would not be
received. Then localization of the actual fault would not be received. Then, localization of the actual fault would not be
possible. possible.
Note that throughout the document, routable address means that it is Note that throughout the document, "routable address" means that it
possible to route an IP packet to this address using the normal 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 information exchanged by the IGP and BGP (or EGP) operating in the
AS. AS.
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | | | | | | | | | | | | | |
| PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 |
| | | | | | | | | | | | | | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
<---------------AS1-------------><---------------AS2------------> <---------------AS1-------------><---------------AS2------------>
<---------------------------- LSP ------------------------------> <---------------------------- LSP ------------------------------>
Figure 1: Simple Inter-AS LSP Configuration Figure 1: Simple Inter-AS LSP Configuration
A second example that illustrates how [RFC4379] would be insufficient A second example that illustrates how [RFC4379] would be insufficient
would be the inter-area situation in a seamless MPLS architecture would be the inter-area situation in a seamless MPLS architecture
[I-D.ietf-mpls-seamless-mpls] as shown below in Figure 2. In this [MPLSARCH] as shown below in Figure 2. In this example, LSRs in the
example LSRs in the core network would not have IP reachable route to core network would not have an IP-reachable route to any of the
any of the access nodes (AN). When tracing an LSP from one AN to the access nodes (ANs). When tracing an LSP from one AN to the remote
remote AN, the LSR1/LSR2 node cannot send the Echo Reply either, like AN, the LSR1/LSR2 node cannot send the Echo Reply either, like the P2
the P2 node in the inter-AS scenario in Figure 1. node in the inter-AS scenario in Figure 1.
+-------+ +-------+ +------+ +------+ +-------+ +-------+ +------+ +------+
| | | | | | | | | | | | | | | |
+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
/ | | /| | | | | | / | | /| | | | | |
+----+/ +-------+\/ +-------+ +------+ /+------+ +----+/ +-------+\/ +-------+ +------+ /+------+
| AN | /\ \/ | AN | /\ \/
+----+\ +-------+ \+-------+ +------+/\ +------+ +----+\ +-------+ \+-------+ +------+/\ +------+
\ | | | | | | \| | \ | | | | | | \| |
+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
| | | | | | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +-------+ +-------+ +------+ +------+
static route ISIS L1 LDP ISIS L2 LDP static route IS-IS L1 LDP IS-IS L2 LDP
<-Access-><--Aggregation Domain--><---------Core---------> <-Access-><--Aggregation Domain--><---------Core--------->
AGN: aggregation node
Figure 2: Seamless MPLS Architecture Figure 2: Seamless MPLS Architecture
This document describes extensions to the LSP Ping mechanism to This document describes extensions to the LSP Ping mechanism to
facilitate a response from the replying LSR, by defining a mechanism 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 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 initiator. Every designated or learned relay node must be reachable
to the next relay node or to the initiator. Using a recursive to the next relay node or to the initiator. Using a recursive
approach, relay node could relay the message to the next relay node approach, a relay node could relay the message to the next relay node
until the initiator is reached. until the initiator is reached.
The LSP Ping relay mechanism in this document is defined for unicast The LSP Ping relay mechanism in this document is defined for unicast.
case. How to apply the LSP Ping relay mechanism in multicast case is How to apply the LSP Ping relay mechanism in multicast is out of
out of the scope. scope.
3. Extensions 3. Extensions
[RFC4379] defines two message types, Echo Request and Echo Reply. [RFC4379] defines two Message Types: Echo Request and Echo Reply.
This document defines a new message type, Relayed Echo Reply. The This document defines a new Message Type: Relayed Echo Reply. The
Relayed Echo Reply message is used in place of the Echo Reply message Relayed Echo Reply message is used in place of the Echo Reply message
when an LSR is replying LSR to a relay node. when an LSR is replying LSR to a relay node.
A new TLV named Relay Node Address Stack TLV is defined in this 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 document to carry the IP addresses of the relay nodes for the
replying LSR. replying LSR.
In addition, MTU (Maximum Transmission Unit) Exceeded Return Code is In addition, the Maximum Transmission Unit (MTU) Exceeded Return Code
defined to indicate to the initiator that one or more TLVs will not is defined to indicate to the initiator that one or more TLVs will
be returned due to MTU size. not be returned due to the MTU size.
It should be noted that this document focuses only on detecting the It should be noted that this document focuses only on detecting the
LSP which is set up using a uniform IP address family type. That is, 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 all hops between the source and destination node use the same address
family type for their LSP ping control planes. This does not family type for their LSP Ping control planes. This does not
preclude nodes that support both IPv6 and IPv4 addresses preclude nodes that support both IPv6 and IPv4 addresses
simultaneously, but the entire path must be addressable using only simultaneously, but the entire path must be addressable using only
one address family type. Supporting for mixed IPv4-only and one address family type. Support for mixed IPv4-only and IPv6-only
IPv6-only is beyond the scope of this document. is beyond the scope of this document.
3.1. Relayed Echo Reply message 3.1. Relayed Echo Reply Message
The Relayed Echo Reply message is a UDP packet, and the UDP payload 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 has the same format with Echo Request/Reply message. A new Message
type is requested from IANA. Type is requested from IANA.
New Message Type: New Message Type:
Value Meaning Value Meaning
----- ------- ----- -------
TBD1 MPLS Relayed Echo Reply 5 MPLS Relayed Echo Reply
The use of TCP and UDP port number 3503 is described in [RFC4379] and 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 has been allocated by IANA for LSP Ping messages. The Relayed Echo
Reply message will use the same port number. Reply message will use the same port number.
3.2. Relay Node Address Stack 3.2. Relay Node Address Stack
The Relay Node Address Stack TLV is an optional TLV. It MUST be The Relay Node Address Stack TLV is an optional TLV. It MUST be
carried in the Echo Request, Echo Reply and Relayed Echo Reply carried in the Echo Request, Echo Reply, and Relayed Echo Reply
messages if the echo reply relayed mechanism described in this messages if the Echo Reply relayed mechanism described in this
document is required. Figure 3 illustrates the TLV format. document is required. Figure 3 illustrates the TLV format.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Source Port | Reply Add Type| Reserved | | Initiator Source Port | Reply Add Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address of Replying Router (0, 4, or 16 octets) | | Source Address of Replying Router (0, 4, or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address Offset | Number of Relayed Addresses | | Destination Address Offset | Number of Relayed Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Stack of Relayed Addresses ~ ~ Stack of Relayed Addresses ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Relay Node Address Stack TLV Figure 3: Relay Node Address Stack TLV
- Type: value is TBD2. The value should be assigned by IANA from - Type: Value is 32768. The value has been assigned by IANA from
32768-49161 as suggested by [RFC4379] Section 3. the 32768-49161 range as suggested by [RFC4379], Section 3.
- Length: the length of the value field in octets. - Length: The length of the value field in octets.
- Initiator Source Port: the source UDP port that the initiator uses - Initiator Source Port: The source UDP port that the initiator uses
in the Echo Request message, and also the port that is expected to in the Echo Request message, and the port that is expected to
receive the Echo Reply message. receive the Echo Reply message.
- Reply Address Type: address type of replying router. This value - Reply Address Type: Address type of replying router. This value
also implies the length of the address field as shown below. also implies the length of the address field as shown below.
Type# Address Type Address Length Type# Address Type Address Length
---- ------------ ------------ ---- ------------ ------------
0 Null 0 0 Null 0
1 IPv4 4 1 IPv4 4
2 IPv6 16 2 IPv6 16
- Reserved: This field is reserved and MUST be set to zero. - Reserved: This field is reserved and MUST be set to zero.
- Source Address of Replying Router: source IP address of the - Source Address of Replying Router: Source IP address of the
originator of Echo Reply or Replay Echo Reply message. originator of Echo Reply or Relay Echo Reply message.
- Destination Address Offset: the offset in octets from the top-of- - Destination Address Offset: The offset in octets from the top-of-
stack to the destination address entry. Each entry size has been stack to the destination address entry. Each entry size has been
listed in this section. Please also refer to section 4.2 for more listed in this section. Please also refer to Section 4.2 for more
detail of the operation. detail of the operation.
- Number of Relayed Addresses: an integer indicating the number of - Number of Relayed Addresses: An integer indicating the number of
relayed addresses in the stack. relayed addresses in the stack.
- Stack of Relayed Addresses: a list of relay node address entries. - Stack of Relayed Addresses: A list of relay node address entries.
This stack grows downward, with relay nodes address further along This stack grows downward, with relay node addresses that are
the LSP appearing lower down in the stack. Please refer to further along the LSP appearing lower down in the stack. Please
section 4.2 for the relay node discovery mechanism. refer to Section 4.2 for the relay node discovery mechanism.
The format of each relay node address entry is as below: The format of each relay node address entry is as below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Address Type |K| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Relayed Address (0, 4, or 16 octets) ~ ~ Relayed Address (0, 4, or 16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 42 skipping to change at page 7, line 42
Figure 4: Relay Node Address Entry Figure 4: Relay Node Address Entry
Type# Address Type Address Length Size of the Entry Type# Address Type Address Length Size of the Entry
---- ------------ ------------ ----------------- ---- ------------ ------------ -----------------
0 Null 0 4 0 Null 0 4
1 IPv4 4 8 1 IPv4 4 8
2 IPv6 16 20 2 IPv6 16 20
Reserved: The two fields are reserved and MUST be set to zero. 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 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 processing NOT be stripped from the Relay Node Address Stack during the
described in Section 4.2. If the K bit is clear, the entry might be processing described in Section 4.2. If the K bit is clear, the
stripped according to the processing described in Section 4.2. entry might be stripped according to the processing described in
Section 4.2.
Having the K bit set in the relay node address entry causes that 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 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 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 ensure its relay node address entry remains as one of the relay nodes
in the Relay Node Address Stack TLV. The address with K bit set will in the Relay Node Address Stack TLV. The address with the K bit set
always be a relay node address for the Relayed Echo Reply, see will always be a relay node address for the Relayed Echo Reply, see
section 4.3. Section 4.3.
Relayed Address: this field specifies the node address, either IPv4 Relayed Address: This field specifies the node address: either IPv4
or IPv6. or IPv6.
3.3. MTU Exceeded Return Code 3.3. MTU Exceeded Return Code
Return Code is defined to indicate that one or more TLVs were omitted This Return Code is defined to indicate that one or more TLVs were
from the Echo Reply or Relayed Echo Reply message to avoid exceeding omitted from the Echo Reply or Relayed Echo Reply message to avoid
the message's effective MTU size. These TLVs MAY be included in an exceeding the message's effective MTU size. These TLVs MAY be
Errored TLV's Object with their lengths set to 0 and no value. The included in an Errored TLV's Object with their lengths set to 0 and
return sub-code MUST be set to the value that otherwise would have no value. The return sub-code MUST be set to the value that
been sent. For more detail, please refer to section 4.2. otherwise would have been sent. For more detail, please refer to
Section 4.2.
MTU Exceeded Return Code: MTU Exceeded Return Code:
Value Meaning Value Meaning
----- ------- ----- -------
TBD2 One or more TLVs not returned due to MTU size 20 One or more TLVs not returned due to MTU size
Then section 4.4 of [RFC4379], step 7 will be updated to integrate This document updates step 7 in Section 4.4 of [RFC4379] to integrate
the processing of MTU Exceeded Return Code.The following text will be the processing of the MTU Exceeded Return Code by adding the
added: following text:
Before sending Echo Reply, the new packet size should be checked. If Before sending Echo Reply, the new packet size should be checked.
Best-return-code is 3 ("Replying router is an egress for the FEC at If Best-return-code is 3 ("Replying router is an egress for the
stack depth"), or 8 ("Label switched at stack-depth"), and if the FEC at stack depth"), or 8 ("Label switched at stack-depth"), and
packet size exceeds MTU size, then Best-return-code is TBD3 ("One or if the packet size exceeds MTU size, then Best-return-code is 20
more TLVs not returned due to MTU size") ("One or more TLVs not returned due to MTU size").
4. Procedures 4. Procedures
To preform a ping operation, the initiator first discovers the relay To perform a ping operation, the initiator first discovers the relay
nodes. Once those nodes have been discovered, the initiator includes nodes. Once those nodes have been discovered, the initiator includes
the Relay Node Address Stack TLV into any Echo Request message. The 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 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 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 that has impacted the necessary stack of relay nodes. In this case,
the initiator may need to re-discover the relay nodes. The following the initiator may need to rediscover the relay nodes. The following
sections describe the procedures for sending and receiving Echo sections describe the procedures for sending and receiving Echo
Request messages with the the Relay Node Address Stack TLV. These Request messages with the Relay Node Address Stack TLV. These
procedures can be used in "trace route" mode to discover the relay procedures can be used in traceroute mode to discover the relay
nodes. nodes.
4.1. Sending an Echo Request 4.1. Sending an Echo Request
In addition to the procedures described in section 4.3 of [RFC4379], 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 a Relay Node Address Stack TLV MUST be carried in the Echo Request
message if the relay functionality is required. The relay function message if the relay functionality is required. The relay function
initiation is out of the scope of this document, one possible way is initiation is out of the scope of this document. One possible way to
that the operator will explicitly add an option to the ping command. do this is that the operator can explicitly add an option to the ping
command.
When the initiator sends the first Echo Request with a Relay Node When the initiator sends the first Echo Request with a Relay Node
Address Stack TLV, the TLV MUST contain the initiator address as the Address Stack TLV, the TLV MUST contain the initiator address as the
first entry of the stack of relayed addresses, the Destination first entry of the stack of relayed addresses, the Destination
Address Offset set to this entry, and the source address of the Address Offset set to this entry, and the source address of the
replying router set to null. The Initiator Source Port field MUST be 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 set to the source UDP port. Note that the first relay node address
in the stack will always be the initiator's address. in the stack will always be the initiator's address.
When sending subsequent Echo Request message, refer to section 4.6. When sending a subsequent Echo Request message, refer to Section 4.6.
4.2. Receiving an Echo Request 4.2. Receiving an Echo Request
The Type of the Relay Node Address Stack TLV is chosen from the range The Type of the Relay Node Address Stack TLV (32768) falls within the
defined in [RFC4379] as "optional TLVs that can be silently dropped range defined in [RFC4379] as "optional TLVs" that can be silently
if not recognized. An LSR that does not recognize the TLV SHOULD dropped if not recognized. An LSR that does not recognize the TLV
ignore it. SHOULD ignore it.
In addition to the processes in section 4.4 of [RFC4379], the In addition to the processes in Section 4.4 of [RFC4379], the
procedures of the Relay Node Address Stack TLV are defined here. procedures of the Relay Node Address Stack TLV are defined here.
Upon receiving a Relay Node Address Stack TLV in an Echo Request Upon receiving a Relay Node Address Stack TLV in an Echo Request
message, the receiver updates the "Source Address of Replying message, the receiver updates the "Source Address of Replying
Router". The address MUST be same as the source IP address of Relay Router". The address MUST be the same as the source IP address of
Echo Reply (section 4.3) or Echo Reply message (section 4.5) being Relay Echo Reply (Section 4.3) or Echo Reply message (Section 4.5)
sent. being sent.
Those address entries with K bit set to 1 MUST be kept in the stack. Those address entries with the K bit set to 1 MUST be kept in the
The receiver MUST check the addresses of the stack in sequence from stack. The receiver MUST check the addresses of the stack in
bottom to top to find the last address in the stack with the K bit sequence from bottom to top to find the last address in the stack
set (or the top of the stack if no K bit was found). The receiver with the K bit set (or the top of the stack if no K bit was found).
then checks the stack beginning with this entry, proceeding towards The receiver then checks the stack beginning with this entry,
the bottom to find the first routable address IP address. The proceeding towards the bottom to find the first routable address IP
Destination Address Offset MUST be set to this entry which is also address. The Destination Address Offset MUST be set to this entry,
the resolved destination address. Address entries below the first which is also the resolved destination address. Address entries
routable IP address MUST be deleted. At least one address entries of below the first routable IP address MUST be deleted. At least one
the replying LSR MUST be added at the bottom of the stack. A second address entry of the replying LSR MUST be added at the bottom of the
or more address entries MAY also be added if necessary, depending on stack. A second address entry (or more) MAY also be added if
implementation. The final address added MUST be an address that is necessary, depending on implementation. The final address added MUST
reachable through the interface that the Echo Request Message would be an address that is reachable through the interface that the Echo
have been forwarded if it had not TTL expired at this node. The Request message would have been forwarded to if its TTL had not
updated Relay Node Address Stack TLV MUST be carried in the response expired at this node. The updated Relay Node Address Stack TLV MUST
message. be carried in the response message.
If the replying LSR is configured to hide its routable address If the replying LSR is configured to hide its routable address
information, the address entry added in the stack MUST be a NIL entry information, the address entry added in the stack MUST be a NIL entry
with Address Type set to NULL. with Address Type set to NULL.
If a node spans two addressing domains (with respect to this message) 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 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 other domain, then the final address added SHOULD set the K bit. One
example of spanning two address domains is the ASBR node. Other example of spanning two address domains is the ASBR node.
cases are also possible, and out of the scope of this document.
K bit applies in the case of a NULL address, to serve as a warning to 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 the initiator that further Echo Request messages may not result in
receiving Echo Reply messages. receiving Echo Reply messages.
If the full reply message would exceed the MTU size, the Relay Node 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., Address Stack TLV SHOULD be included in the Echo Reply message (i.e.,
other optional TLVs are excluded). other optional TLVs are excluded).
4.3. Originating an Relayed Echo Reply 4.3. Originating a Relayed Echo Reply
The destination address determined in section 4.2 is used as the next The destination address determined as described in Section 4.2 is
relay node address. If the resolved next relay node address is not used as the next relay node address. If the resolved next relay node
routable, then sending of Relayed Echo Reply or Echo Reply will fail. address is not routable, then the sending of the Relayed Echo Reply
or Echo Reply will fail.
If the first IP address in the Relay Node Address Stack TLV is not 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 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 message to the next relay node. The processing of Relayed
Echo Reply is the same with the procedure of the Echo Reply described 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 in Section 4.5 of [RFC4379], except the destination IP address and
the destination UDP port. The destination IP address of the Relayed 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 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 Address Stack TLV, and both the source and destination UDP port are
set to 3503. The updated Relay Node Address Stack TLV described in 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 Section 4.2 MUST be carried in the Relayed Echo Reply message. The
Source Address of Replying Router field is kept unmodified, and Source Address of the Replying Router field is kept unmodified, and
Source IP address field of the IP header is set to an address of the the Source IP address field of the IP header is set to an address of
sending node. the sending node.
When the next relay node address is the first one in the address When the next relay node address is the first one in the address
list, please refer to section 4.5. list, please refer to Section 4.5.
4.4. Relaying an Relayed Echo Reply 4.4. Relaying a Relayed Echo Reply
Upon receiving an Relayed Echo Reply message with its own address as Upon receiving a Relayed Echo Reply message with its own address as
the destination address in the IP header, the relay node MUST the destination address in the IP header, the relay node MUST
determine the next relay node address as described in section 4.2, determine the next relay node address as described in Section 4.2,
with the modification that the location of the received destination with the modification that the location of the received destination
address is used instead of the bottom of stack in the algorithm. The address is used instead of the bottom of stack in the algorithm. The
Destination Address Offset in Relay Node Address Stack TLV will be Destination Address Offset in Relay Node Address Stack TLV will be
set to the next relay node address. Note that unlike section 4.2 no set to the next relay node address. Note that unlike in Section 4.2,
changes are made to the Stack of Relayed Addresses. no changes are made to the Stack of Relayed Addresses.
If the next relay node address is not the first one in the address 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 list, i.e., another intermediate relay node, the relay node MUST send
an Relayed Echo Reply message to the determined upstream node with a Relayed Echo Reply message to the determined upstream node with the
the payload unchanged other than the Relay Node Address Stack TLV. payload unchanged other than the Relay Node Address Stack TLV. The
The TTL SHOULD be copied from the received Relay Echo Reply and TTL SHOULD be copied from the received Relay Echo Reply and
decremented by 1. The Source Address of Replying Router field is decremented by 1. The Source Address of the Replying Router field is
kept unmodified, and Source IP address field of the IP header is set kept unmodified and the Source IP address field of the IP header is
to an address of the sending node. set to an address of the sending node.
When the next relay node address is the first one in the address When the next relay node address is the first one in the address
list, please refer to section 4.5. list, please refer to Section 4.5.
4.5. Sending an Echo Reply 4.5. Sending an Echo Reply
The Echo Reply is sent in two cases: The Echo Reply is sent in two cases:
1. When the replying LSR receives an Echo Request, and the first IP 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 in the Relay Node Address Stack TLV is the next relay
address (section 4.3), the replying LSR would send an Echo Reply to node address (Section 4.3), the replying LSR would send an Echo
the initiator. In addition to the procedure of the Echo Reply Reply to the initiator. In addition to the procedure of the Echo
described in Section 4.5 of [RFC4379], the updated Relay Node Address Reply described in Section 4.5 of [RFC4379], the updated Relay
Stack TLV described in section 4.2 MUST be carried in the Echo Reply. Node Address Stack TLV described in Section 4.2 MUST be carried
in the Echo Reply.
If the receiver does not recognize the Relay Node Address Stack TLV, If the receiver does not recognize the Relay Node Address Stack
as per section 3 and 4.5 of [RFC4379], it will send an Echo Reply TLV, as per Sections 3 and 4.5 of [RFC4379], it will send an Echo
without including the TLV. Reply without including the TLV.
2. When the intermediate relay node receives a Relayed Echo Reply, 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 and the first IP address in the Relay Node Address Stack TLV is
next relay node address (section 4.4), the intermediate relay node the next relay node address (Section 4.4), the intermediate relay
would send the Echo Reply to the initiator, and update the Message node will send the Echo Reply to the initiator, and update the
Type field from type of Relayed Echo Reply to Echo Reply. The Message Type field from type of "Relayed Echo Reply" to "Echo
updated Relay Node Address Stack TLV described in section 4.4 MUST be Reply". The updated Relay Node Address Stack TLV described in
carried in the Echo Reply. The destination IP address of the Echo Section 4.4 MUST be carried in the Echo Reply. The destination
Reply is set to the first IP address in the stack, and the IP address of the Echo Reply is set to the first IP address in
destination UDP port would be copied from the Initiator Source Port the stack, and the destination UDP port will be copied from the
field of the Relay Node Address Stack TLV. The source UDP port Initiator Source Port field of the Relay Node Address Stack TLV.
should be 3503. The TTL of the Echo Reply SHOULD be copied from the The source UDP port should be 3503. The TTL of the Echo Reply
received Relay Echo Reply and decremented by 1. The Source Address SHOULD be copied from the received Relay Echo Reply and
of Replying Router field is kept unmodified, and Source IP address decremented by 1. The Source Address of the Replying Router
field of the IP header is set to an address of the sending node. field is kept unmodified, and the Source IP address field of the
IP header is set to an address of the sending node.
4.6. Sending Subsequent Echo Requests 4.6. Sending Subsequent Echo Requests
During a traceroute operation, multiple Echo Request messages are During a traceroute operation, multiple Echo Request messages are
sent. Each time the TTL is increased, the initiator SHOULD copy the sent. Each time the TTL is increased, the initiator SHOULD copy the
Relay Node Address Stack TLV received in the previous Echo Reply to 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 the next Echo Request. The Relay Node Address Stack TLV MUST NOT be
modified except as follows. A NIL entry with K bit unset MAY be modified except as follows. A NIL entry that does not have the K bit
removed. A NIL entry with K bit serves as a warning that further set MAY be removed. A NIL entry with the K bit serves as a warning
Echo Request messages are likely to not result in a reply. If, that further Echo Request messages are likely not to result in a
however, the initiator decides to continue a traceroute operation, reply. If, however, the initiator decides to continue a traceroute
the NIL entry with the K bit set MUST be removed. The Source Address operation, the NIL entry with the K bit set MUST be removed. The
of Replying Router and Destination Address Offset fields may be Source Address of the Replying Router and Destination Address Offset
preserved or reset since these fields are ignored in received MPLS fields may be preserved or reset since these fields are ignored in
Echo Request. the received MPLS Echo Request.
4.7. Impact to Traceroute 4.7. Impact on Traceroute
Source IP address in Echo Reply and Relay Echo Reply is to be of the The Source IP address in Echo Reply and Relay Echo Reply should be
address of the node sending those packets, not the original the address of the node sending those packets, not the original
responding node. Then the traceroute address output module will responding node. Then the traceroute address output module will
print the source IP address as below: print the source IP address as below:
if (Relay Node Address Stack TLV exists) { if (Relay Node Address Stack TLV exists) {
Print the Source Address of Replying Router in Print the Source Address of Replying Router in
Relay Node Address Stack TLV; Relay Node Address Stack TLV;
} else { } else {
Print the source IP address of Echo Reply message; Print the source IP address of Echo Reply message;
} }
5. LSP Ping Relayed Echo Reply Example 5. LSP Ping Relayed Echo Reply Example
Considering the inter-AS scenario in Figure 5 below. AS1 and AS2 are Considering the inter-AS scenario in Figure 5 below, AS1 and AS2 are
two independent address domains. In the example, an LSP has been 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 created between PE1 to PE2, but PE1 in AS1 is not reachable by P2 in
AS2. AS2.
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | | | | | | | | | | | | | |
| PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 |
| | | | | | | | | | | | | | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
<---------------AS1-------------><---------------AS2------------> <---------------AS1-------------><---------------AS2------------>
<--------------------------- LSP -------------------------------> <--------------------------- LSP ------------------------------->
Figure 5: Example Inter-AS LSP Figure 5: Example Inter-AS LSP
When performing LSP traceroute on the LSP, the first Echo Request When performing LSP traceroute on the LSP, the first Echo Request
sent by PE1 with outer-most label TTL=1, contains the Relay Node sent by PE1 with outermost label TTL=1 contains the Relay Node
Address Stack TLV with PE1's address as the first relayed address. Address Stack TLV with PE1's address as the first relayed address.
After processed by P1, P1's interface address facing ASBR1 without After being processed by P1, P1's interface address facing ASBR1
the K bit set will be added in the Relay Node Address Stack TLV without the K bit set will be added in the Relay Node Address Stack
address list following PE1's address in the Echo Reply. TLV address list following PE1's address in the Echo Reply.
PE1 copies the Relay Node Address Stack TLV into the next Echo PE1 copies the Relay Node Address Stack TLV into the next Echo
Request when receiving the Echo Reply. Request when receiving the Echo Reply.
Upon receiving the Echo Request, ASBR1 checks the address list in the Upon receiving the Echo Request, ASBR1 checks the address list in the
Relay Node Address Stack TLV, and determines that PE1's address is Relay Node Address Stack TLV and determines that PE1's address is the
the next relay address. Then deletes P1's address, and adds its next relay address. Then it deletes P1's address, and adds its
interface address facing ASBR2 with the K bit set. As a result, interface address facing ASBR2 with the K bit set. As a result,
there would be PE1's address followed by ASBR1's interface address 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 facing ASBR2 in the Relay Node Address Stack TLV of the Echo Reply
sent by ASBR1. sent by ASBR1.
PE1 then sends an Echo Request with outer-most label TTL=3, PE1 then sends an Echo Request with outermost label TTL=3, containing
containing the Relay Node Address Stack TLV copied from the received the Relay Node Address Stack TLV copied from the received Echo Reply
Echo Reply message. Upon receiving the Echo Request message, ASBR2 message. Upon receiving the Echo Request message, ASBR2 checks the
checks the address list in the Relay Node Address Stack TLV, and address list in the Relay Node Address Stack TLV and determines that
determines ASBR1's interface address is the next relay address in the ASBR1's interface address is the next relay address in the stack TLV.
stack TLV. ASBR2 adds its interface address facing P2 with the K bit ASBR2 adds its interface address facing P2 with the K bit set. Then
set. Then ASBR2 sets the next relay address as the destination ASBR2 sets the next relay address as the destination address of the
address of the Relayed Echo Reply, and sends the Relayed Echo Reply Relayed Echo Reply and sends the Relayed Echo Reply to ASBR1.
to ASBR1.
Upon receiving the Relayed Echo Reply from ASBR2, ASBR1 checks the Upon receiving the Relayed Echo Reply from ASBR2, ASBR1 checks the
address list in the Relay Node Address Stack TLV, and determines that 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 PE1's address is the next relay node. Then ASBR1 sends an Echo Reply
to PE1. to PE1.
For the Echo Request with outer-most label TTL=4, P2 checks the For the Echo Request with outermost label TTL=4, P2 checks the
address list in the Relay Node Address Stack TLV, and determines that address list in the Relay Node Address Stack TLV and determines that
ASBR2's interface address is the next relay address. Then P2 sends ASBR2's interface address is the next relay address. Then P2 sends a
an Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV
containing four addresses, PE1's, ASBR1's interface address, ASBR2's containing four addresses: PE1's, ASBR1's interface address, ASBR2's
interface address and P2's interface address facing PE2 in sequence. interface address, and P2's interface address facing PE2 in sequence.
Then according to the process described in section 4.4, ASBR2 sends Then, according to the process described in Section 4.4, ASBR2 sends
the Relayed Echo Reply to ASBR1. Upon receiving the Relayed Echo 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 Reply, ASBR1 sends an Echo Reply to PE1. And, as relayed by ASBR2
ASBR1, the Echo Reply would finally be sent to the initiator PE1. and ASBR1, the Echo Reply would finally be sent to the initiator PE1.
For the Echo Request with outer-most label TTL=5, the Echo Reply For the Echo Request with outermost label TTL=5, the Echo Reply would
would relayed to PE1 by ASBR2 and ASBR1, similar to the case of relayed to PE1 by ASBR2 and ASBR1, similar to the case of TTL=4.
TTL=4.
The Echo Reply from the replying node which has no IP reachable route The Echo Reply from the replying node that has no IP reachable route
to the initiator is thus transmitted to the initiator by multiple to the initiator is thus transmitted to the initiator by multiple
relay nodes. relay nodes.
6. Security Considerations 6. Security Considerations
The Relayed Echo Reply mechanism for LSP Ping creates an increased 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 risk of DoS by putting the IP address of a target router in the Relay
Node Address Stack. These messages then could be used to attack the Node Address Stack. These messages could then be used to attack the
control plane of an LSR by overwhelming it with these packets. A 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 rate limiter SHOULD be applied to the well-known UDP port on the
relay node as suggested in [RFC4379]. The node which acts as a relay 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 node SHOULD validate the relay reply against a set of valid source
addresses and discard packets from untrusted border router addresses. addresses and discard packets from untrusted border router addresses.
An implementation SHOULD provide such filtering capabilities. An implementation SHOULD provide such filtering capabilities.
If an operator wants to obscure their nodes, it is RECOMMENDED that If an operator wants to obscure their nodes, it is RECOMMENDED that
they may replace the replying node address that originated the Echo they replace the replying node address that originated the Echo Reply
Reply with NIL address entry in Relay Node Address Stack TLV. with the NIL address entry in the Relay Node Address Stack TLV.
A receiver of an MPLS Echo Request could verify that the first 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 address in the Relay Node Address Stack TLV is the same address as
the source IP address field of the received IP header. the source IP address field of the received IP header.
The Relay Node Address Stack TLV has the path information of the LSP, The Relay Node Address Stack TLV has the path information of the LSP,
and such information may be maliciously used by any uncontrolled LSR/ and such information may be maliciously used by any uncontrolled LSR/
LER. We have two ways to reduce the path information in the TLV: LER. We have two ways to reduce the path information in the TLV:
1. it is recommended to clear the K bit in the relay address entry o It is recommended to clear the K bit in the relay address entry
unless you have to. unless it must be set (e.g., as listed in Section 4.2).
2. it is encouraged to use NIL address entry to hide node information o It is recommended to use the NIL address entry to hide node
if possible. information, if possible.
Other security considerations discussed in [RFC4379], are also Other security considerations discussed in [RFC4379] are also
applicable to this document. applicable to this document.
7. Backward Compatibility 7. Backward Compatibility
When one of the nodes along the LSP does not support the mechanism When one of the nodes along the LSP does not support the mechanism
specified in this document, the node will ignore the Relay Node specified in this document, the node will ignore the Relay Node
Address Stack TLV as described in section 4.2. Then the initiator Address Stack TLV as described in Section 4.2. Then the initiator
may not receive the Relay Node Address Stack TLV in Echo Reply may not receive the Relay Node Address Stack TLV in Echo Reply
message from that node. In this case, an indication should be message from that node. In this case, an indication should be
reported to the operator, and the Relay Node Address Stack TLV in the reported to the operator, and the Relay Node Address Stack TLV in the
next Echo Request message should be copied from the previous Echo next Echo Request message should be copied from the previous Echo
Request, and continue the ping process. If the node described above Request, and continue the ping process. If the node described above
is located between the initiator and the first relay node, the ping is located between the initiator and the first relay node, the ping
process could continue without interruption. process could continue without interruption.
8. IANA Considerations 8. IANA Considerations
IANA is requested to assign one new Message Type, one new TLV and one IANA has assigned one new Message Type, one new TLV, and one Return
Return Code. Code.
8.1. New Message Type 8.1. MPLS Relayed Echo Reply
This document requires allocation of one new message type from One new Message Type from the "Multi-Protocol Label Switching (MPLS)
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Label Switched Paths (LSPs) Ping Parameters" registry in the "Message
Ping Parameters" registry, the "Message Type" registry: Type" subregistry has been allocated:
Value Meaning Value Meaning
----- ------- ----- -------
TBD1 MPLS Relayed Echo Reply 5 MPLS Relayed Echo Reply
The value should be assigned from the "Standards Action" range The value has been assigned from the "Standards Action" [RFC5226]
(0-191), and using the lowest free value within this range. range (0-191) using the lowest free value within this range.
8.2. New TLV 8.2. Relay Node Address Stack TLV
This document requires allocation of one new TLV from "Multi-Protocol One new TLV from the "Multi-Protocol Label Switching (MPLS) Label
Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" Switched Paths (LSPs) Ping Parameters" registry in the "TLVs"
registry, the "TLVs" registry: subregistry has been allocated:
Type Meaning Type TLV Name
---- -------- ---- --------
TBD2 Relay Node Address Stack TLV 32768 Relay Node Address Stack TLV
A value should be assigned from "Standards Action" range The value has been assigned from the "Standards Action" range
(32768-49161) as suggested by [RFC4379] Section 3, using the first (32768-49161) as suggested by [RFC4379] Sections 3 and 7.2 using the
free value within this range. first free value within this range.
8.3. MTU Exceeded Return Code 8.3. MTU Exceeded Return Code
This document requires allocation of MTU Exceeded return code from The MTU Exceeded return code from the "Multi-Protocol Label Switching
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the
Ping Parameters" registry, the "Return Codes" registry: "Return Codes"subregistry has been allocated:
Value Meaning Value Meaning
----- ------- ----- -------
TBD3 One or more TLVs not returned due to MTU size 20 One or more TLVs not returned due to MTU size
The value should be assigned from the "Standards Action" range
(0-191), and using the lowest free value within this range.
9. Acknowledgement
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.
10. Contributors
Ryan Zheng The value has been assigned from the "Standards Action" range (0-191)
JSPTPD using the lowest free value within this range.
371, Zhongshan South Road
Nanjing, 210006, China
Email: ryan.zhi.zheng@gmail.com
11. References 9. References
11.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC4379, February 2006, DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>. <http://www.rfc-editor.org/info/rfc4379>.
11.2. Informative References 9.2. Informative References
[I-D.ietf-mpls-seamless-mpls] [MPLSARCH] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", Work
M., and D. Steinberg, "Seamless MPLS Architecture", draft- in Progress, draft-ietf-mpls-seamless-mpls-07, June 2014.
ietf-mpls-seamless-mpls-07 (work in progress), June 2014.
[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>.
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
Email: ryan.zhi.zheng@gmail.com
Authors' Addresses Authors' Addresses
Jian Luo (editor) Jian Luo (editor)
ZTE ZTE
50, Ruanjian Avenue 50, Ruanjian Avenue
Nanjing, 210012, China Nanjing 210012
China
Email: luo.jian@zte.com.cn Email: luo.jian@zte.com.cn
Lizhong Jin (editor) Lizhong Jin (editor)
Individual Shanghai
Shanghai, China China
Email: lizho.jin@gmail.com Email: lizho.jin@gmail.com
Thomas Nadeau (editor) Thomas Nadeau (editor)
Lucidvision Brocade
Email: tnadeau@lucidvision.com Email: tnadeau@lucidvision.com
George Swallow (editor) George Swallow (editor)
Cisco Cisco Systems
300 Beaver Brook Road
Boxborough , MASSACHUSETTS 01719, USA
Email: swallow@cisco.com Email: swallow@cisco.com
 End of changes. 121 change blocks. 
337 lines changed or deleted 344 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/