draft-ietf-mpls-lsp-ping-relay-reply-02.txt   draft-ietf-mpls-lsp-ping-relay-reply-03.txt 
Network Working Group J. Luo, Ed. Network Working Group J. Luo, Ed.
Internet-Draft ZTE Internet-Draft ZTE
Updates: 4379 (if approved) L. Jin, Ed. Updates: 4379 (if approved) L. Jin, Ed.
Intended status: Standards Track Intended status: Standards Track
Expires: August 18, 2014 T. Nadeau, Ed. Expires: October 4, 2014 T. Nadeau, Ed.
Lucidvision Lucidvision
G. Swallow, Ed. G. Swallow, Ed.
Cisco Cisco
February 14, 2014 April 2, 2014
Relayed Echo Reply mechanism for LSP Ping Relayed Echo Reply mechanism for LSP Ping
draft-ietf-mpls-lsp-ping-relay-reply-02 draft-ietf-mpls-lsp-ping-relay-reply-03
Abstract Abstract
In some inter autonomous system (AS) and inter-area deployment In some inter autonomous system (AS) and inter-area deployment
scenarios for Label Switched Path (LSP) Ping and Traceroute, a scenarios for RFC 4379 "Label Switched Path (LSP) Ping and
replying LSR may not have the available route to the initiator, and Traceroute", a replying LSR may not have the available route to the
the Echo Reply message sent to the initiator would be discarded initiator, and the Echo Reply message sent to the initiator would be
resulting in false negatives or complete failure of operation of LSP discarded resulting in false negatives or complete failure of
Ping and Traceroute. This document describes extensions to LSP Ping operation of LSP Ping and Traceroute. This document describes
mechanism to enable the replying Label Switching Router (LSR) to have extensions to LSP Ping mechanism to enable the replying Label
the capability to relay the Echo Response by a set of routable Switching Router (LSR) to have the capability to relay the Echo
intermediate nodes to the initiator. Response by a set of routable intermediate nodes to the initiator.
This document updates RFC 4379.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014. This Internet-Draft will expire on October 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . . 5 3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . . 6
3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . . 5 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . . 6
3.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 7 3.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 8
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 7 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8
4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 7 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 8
4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 8 4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 9
4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . . 9 4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . . 9
4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 9 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 10
4.6. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 9 4.6. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 10
5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 10 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. New Message Type . . . . . . . . . . . . . . . . . . . . . 12 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . . 13
8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 12 8.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document describes the extensions to the Label Switched Path This document describes the extensions to the Label Switched Path
(LSP) Ping as specified in [RFC4379], by adding a relayed echo reply (LSP) Ping as specified in [RFC4379], by adding a relayed echo reply
mechanism which could be used to detect data plane failures in inter mechanism which could be used to detect data plane failures for the
autonomous system (AS) and inter-area LSPs. Without this extension, inter autonomous system (AS) and inter-area LSPs. The extensions are
the ping functionality provided by [RFC4379] would fail in many to update the [RFC4379]. Without these extensions, the ping
deployed inter-AS scenarios, since the replying LSR in one AS may not functionality provided by [RFC4379] would fail in many deployed
have the available route to the initiator in the other AS. The inter-AS scenarios, since the replying LSR in one AS may not have the
mechanism in this draft defines a new message type referred as available route to the initiator in the other AS. The mechanism in
"Relayed Echo Reply message", and a new TLV referred as "Relay Node this document defines a new message type referred as "Relayed Echo
Address Stack TLV". Reply message", and a new TLV referred as "Relay Node Address Stack
TLV".
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 the data plane
and localize faults. The mechanism specifies that the Echo Reply failures and localize faults. The mechanism specifies that the Echo
should be sent back to the initiator usig an UDP packet with the Reply should be sent back to the initiator using an UDP packet with
IPv4/ IPv6 address of the originating LSR. This works in the IPv4/ IPv6 address of the originating LSR. This works in
administrative domains allowing IP address reachability and routing administrative domains where IP addresses reachability are allowed
back to the originating LSR. However, in practice, this is often not among LSRs, and every LSR is able to route back to the originating
the case due to intra-provider routing policy, route hiding, network LSR. However, in practice, this is often not the case due to intra-
address translation at autonomous system border routers (ASBR), and provider routing policy, route hiding, and network address
etc. In fact, it is almost uniformly the case that in inter-AS translation at autonomous system border routers (ASBR). In fact, it
scenarios, it is not allowed the distribution or direct routing to is almost uniformly the case that in inter-AS scenarios, it is not
the IP addresses of any of the nodes other than the ASBR. allowed the distribution or direct routing to the IP addresses of any
of the nodes other than the ASBR in another AS.
Figure 1 demonstrates a case where one LSP is set up between PE1 and Figure 1 demonstrates a case where one LSP is set up between PE1 and
PE2. If private addresses were in use within AS2, a traceroute from PE2. If private addresses were in use within AS1, a traceroute from
PE1 directed to PE2 could fail if the fault exists somewhere between PE1 directed to PE2 could fail if the fault exists somewhere between
ASBR2 and PE2. Because P2 cannot forward packets back to PE1 given ASBR2 and PE2. Because P2 cannot forward packets back to PE1 given
that it is a private address within AS1. In this case, PE1 would that it is a private address within AS1. In this case, PE1 would
detect a path break, as the Echo Request messages would not be sent detect a path break, as the Echo Reply messages would not be
back; however, localization of the actual fault would not be received. Then localization of the actual fault would not be
possible. possible.
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | | | | | | | | | | | | | |
| 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 [I-D.ietf-mpls-seamless-mpls] as shown below in Figure 2. In this
example P nodes the in core network would not have IP reachable route example LSRs in the core network would not have IP reachable route to
to any of the ANs. When tracing an LSP from AN to remote AN, the any of the ANs. When tracing an LSP from one AN to the remote AN,
LSR1/LSR2 node could not make a response to the Echo Request either, the LSR1/LSR2 node could not make a response to the Echo Request
like P2 node in the inter-AS scenario in Figure 1. either, like the P2 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 ISIS L1 LDP ISIS L2 LDP
<-Access-><--Aggregation Domain--><---------Core---------> <-Access-><--Aggregation Domain--><---------Core--------->
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 simple facilitate a response from the replying LSR, by defining a simple
mechanism that uses the relay node (e.g, ASBR) to relay the message mechanism that uses a relay node (e.g, ASBR) to relay the message
back to the initiator. This approach will work because every back to the initiator. Every designated or learned relay node must
designated or learned relay node must have an IP route back to the have an IP route to the next relay node or to the initiator. Using a
initiator. Using a recursive approach, relay node could relay the recursive approach, relay node could relay the message to the next
message to the next relay node until the initiator is reached. relay node until the initiator is reached.
3. Extensions 3. Extensions
[RFC4379] describes the basic MPLS LSP Ping mechanism, which defines [RFC4379] describes the basic MPLS LSP Ping mechanism, which defines
two message types, Echo Request and Echo Reply message. This draft two message types, Echo Request and Echo Reply message. This
defines a new message, Relayed Echo Reply message. This new message document defines a new message, Relayed Echo Reply message. This new
is used to replace Echo Reply message which is sent from the replying message is used to replace Echo Reply message which is sent from the
LSR to a relay node or from a relay node to another relay node. replying LSR to a relay node or from a relay node to another relay
node.
A new TLV named Relay Node Address Stack TLV is defined in this A new TLV named Relay Node Address Stack TLV is defined in this
draft, to carry the IP addresses of the possible relay nodes for the document, to carry the IP addresses of the possible relay nodes for
replying LSR. the replying LSR.
In addition, a new Return Code is defined to notify the initiator In addition, a new Return Code is defined to notify the initiator
that the packet length was exceeded unexpected by the Relay Node that the packet length is exceeded unexpected by the Relay Node
Address Stack TLV. Address Stack TLV.
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 type of IP address. That is, all LSP which is set up using a uniform IP address family type. That is,
hops between the source and destination use one address type of their all hops between the source and destination node use the same address
control planes. This does not preclude nodes that support both IPv6 family type for their LSP ping control planes. This does not
and IPv4 addresses simultaneously, but the entire path must be preclude nodes that support both IPv6 and IPv4 addresses
addressable using only one address family type. Supporting for mixed simultaneously, but the entire path must be addressable using only
IPv4-only and IPv6-only is beyond the scope of this document. one address family type. Supporting for mixed IPv4-only and IPv6-
only 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
----- ------- ----- -------
TBD MPLS Relayed Echo Reply TBD MPLS Relayed Echo Reply
The TCP and UDP port number 3503 has been allocated in [RFC4379] by The use of TCP and UDP port number 3503 is described in [RFC4379] and
IANA for LSP Ping messages. The Relayed Echo Reply message will use has been allocated by IANA for LSP Ping messages. The Relayed Echo
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 draft messages if the echo reply relayed mechanism described in this
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 | Number of Relayed Addresses | | Initiator Source Port | 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: to be assigned by IANA. A suggested value is assigned from - Type: to be assigned by IANA. A value should be assigned from
32768-49161 as suggested by RFC4379 Section 3. 32768-49161 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 port that the initiator sends the Echo - Initiator Source Port: the source UDP port that the initiator
Request message, and also the port that expected to receive the sends the Echo Request message, and also the port that is expected
Echo Reply message. to receive the Echo Reply message.
- 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 addresses. - Stack of Relayed Addresses: a list of relay node addresses.
The format of each relay node address is as below: The format of each relay node address 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 | Address Length| Reserved |K| | Address Type | Address Length| Reserved |K|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Relayed Address (0, 4, or 16 octects) ~ ~ Relayed Address (0, 4, or 16 octects) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type# Address Type Address Length Type# Address Type Address Length
---- ------------ ------------ ---- ------------ ------------
0 Unspecified 0 0 Unspecified 0
1 IPv4 4 1 IPv4 4
2 IPv6 16 2 IPv6 16
Reserved: This field is reserved for future use and MUST be set to Reserved: This field is reserved and MUST be set to zero.
zero.
K bit: If the K bit is set to 1, then this sub-TLV SHOULD be kept in K bit: if the K bit is set to 1, then this sub-TLV MUST be kept in
Relay Node Address Stack, SHOULD not be deleted in compress process Relay Node Address Stack during TLV compress process described in
of section 4.2. The K bit may be set by ASBRs which address would be section 4.2. The K bit may be set by ASBRs whose address would be
kept in the stack if necessary. kept in the stack if necessary.
If the K bit is set to 0, then this sub-TLV SHOULD be processed Relayed Address: this field specifies the node address, either IPv4
normally according to section 4.2.
Relayed Address: This field specifies the node address, either IPv4
or IPv6. or IPv6.
3.3. New Return Code 3.3. New Return Code
A new Return Code is used by the replying LSR to notify the initiator A new Return Code is used by the replying LSR to notify the initiator
that the packet length was exceeded unexpected by the Relay Node that the packet length is exceeded unexpected by the Relay Node
Address Stack TLV. Address Stack TLV.
New Return Code: New Return Code:
Value Meaning Value Meaning
----- ------- ----- -------
TBD Response Packet length was exceeded by the Relay Node TBD Response Packet length was exceeded by the Relay Node
Address Stack TLV unexpected Address Stack TLV unexpected
4. Procedures 4. Procedures
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 for facilitate the relay functionality. message to facilitate the relay functionality.
When the Echo Request is first sent by initiator supporting these When the Echo Request is first sent by the initiator, a Relay Node
extensions, a Relay Node Address Stack TLV with the initiator address Address Stack TLV with the initiator address in the stack and its
in the stack and its source port MUST be included. That will ensure source UDP port MUST be included. That will ensure that the first
that the first relay node address in the stack will always be the relay node address in the stack will always be the initiator address.
initiator address.
For the subsequent Echo Request messages, the initiator would copy For the subsequent Echo Request messages, the initiator would copy
the Relay Node Address Stack TLV from the received Echo Reply the Relay Node Address Stack TLV from the received Echo Reply
message. message.
4.2. Receiving an Echo Request 4.2. Receiving an Echo Request
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 of the Echo Request Upon receiving a Relay Node Address Stack TLV of the Echo Request
message, the receiver MUST check the addresses of the stack in message, the receiver MUST check the addresses of the stack in
sequence from top to bottom (the first address in the stack ==== will sequence from top to bottom (the first address in the stack will be
be first one to be checked), to find out the first public routable IP the first one to be checked), to find out the first public routable
address. Those address entries behind of the first routable IP IP address. Those address entries behind of the first routable IP
address in the address list with K bit set to 0 MUST be deleted, and address in the address list with K bit set to 0 MUST be deleted, and
the address entry of the replying LSR MUST be added at the bottom of the address entry of the replying LSR MUST be added at the bottom of
the stack. Those address entries with K bit set to 1 MUST be kept in the stack. Those address entries with K bit set to 1 MUST be kept in
the stack. The updated Relay Node Address Stack TLV MUST be carried the stack. The updated Relay Node Address Stack TLV MUST be carried
in the response message. in the response message.
If the replying LSR wishes to hide its routable address information, If the replying LSR is configured to hide its routable address
the address entry added in the stack SHOULD be a blank entry with information, the address entry added in the stack SHOULD be a blank
Address Type set to unspecified. The blank address entry in the entry with Address Type set to unspecified. The blank address entry
receiving Echo Request SHOULD be treated as an unroutable address in the receiving Echo Request SHOULD be treated as an unroutable
entry. address entry.
If the packet length was exceeded unexpectedly by the Relay Node If the packet length was exceeded unexpectedly by the Relay Node
Address Stack TLV, the TLV SHOULD be returned back unchanged in the Address Stack TLV, the TLV SHOULD be returned back unchanged in the
echo response message. And the new return code SHOULD help to notify Echo Reply message. And the new return code in section 3.3 SHOULD be
the initiator of the situation. used to notify the initiator of the situation.
If the first routable IP address is the first address in the stack, If the first routable IP address is the first address in the stack,
the replying LSR SHOULD respond an Echo Reply message to the the replying LSR SHOULD respond an Echo Reply message to the
initiator. initiator.
If the first routable IP address is of an intermediate node, other If the first routable IP address is an intermediate node, other than
than the first address in the stack, the replying LSR SHOULD send an the first address in the stack, the replying LSR SHOULD send a
Relayed Echo Reply instead of an Echo Reply in response. Relayed Echo Reply instead of an Echo Reply as a response.
An LSR not recognize the Relay Node Address Stack TLV, SHOULD ignore An LSR not recognize the Relay Node Address Stack TLV, SHOULD ignore
it according to section 3 of RFC4379. it according to section 3 of [RFC4379].
4.3. Originating an Relayed Echo Reply 4.3. Originating an Relayed Echo Reply
When the replying LSR received an Echo Request with the initiator IP When the replying LSR receives an Echo Request with the first IP
address in the Relay Node Address Stack TLV is IP unroutable, the address in the Relay Node Address Stack TLV is IP unroutable, the
replying LSR SHOULD send an Relayed Echo Reply message to the first replying LSR SHOULD send a Relayed Echo Reply message to the first
routable intermediate node. The processing of Relayed Echo Reply is routable intermediate node. The processing of Relayed Echo Reply is
the same with the procedure of the Echo Reply described in Section the same with the procedure of the Echo Reply described in Section
4.5 of RFC4379, except the destination IP address and the destination 4.5 of [RFC4379], except the destination IP address and the
UDP port of the message part. The destination IP address of the destination UDP port. The destination IP address of the Relayed Echo
Relayed Echo Reply is set to the first routable IP address from the Reply is set to the first routable IP address from the Relay Node
Relay Node Address Stack TLV, and both the source and destination UDP Address Stack TLV, and both the source and destination UDP port is
port is set to 3503. set to 3503.
4.4. Relaying an Relayed Echo Reply 4.4. Relaying an Relayed Echo Reply
Upon receiving an Relayed Echo Reply message with its address as the Upon receiving an Relayed Echo Reply message with its own address as
destination address in the IP header, the relay node should check the the destination address in the IP header, the relay node SHOULD check
address items in Relay Node Address Stack TLV in sequence from top to the address items in Relay Node Address Stack TLV in sequence from
down, and find the first routable node address. top to down, and find the first routable node address.
If the first routable address is the top one of the address list, If the first routable address is the top one of the address list,
e.g, the initiator address, the relay node SHOULD send an Echo Reply e.g, the initiator address, the relay node SHOULD send an Echo Reply
message to the initiator containing the same payload with the Relayed message to the initiator containing the same payload with the Relayed
Echo Reply message received. See section 4.5 for detail. Echo Reply message received. See section 4.5 for detail.
If the first routable address is not the top one of the address list, If the first routable address is not the top one of the address list,
e.g, another intermediate relay node, the relay node SHOULD send an e.g, another intermediate relay node, the relay node SHOULD send an
Relayed Echo Reply message to this relay node with the payload Relayed Echo Reply message to this relay node with the payload
unchanged. unchanged.
skipping to change at page 9, line 33 skipping to change at page 10, line 26
the first relay node found in Relay Node Address Stack TLV that is the first relay node found in Relay Node Address Stack TLV that is
routable by the router. The routable address MUST be located before routable by the router. The routable address MUST be located before
the source IP address of the received Relayed Echo Reply which must the source IP address of the received Relayed Echo Reply which must
be also in the stack, otherwise the Relayed Echo Reply should not be be also in the stack, otherwise the Relayed Echo Reply should not be
sent, so as to avoid potential loop. sent, so as to avoid potential loop.
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 received an Echo Request with the initiator 1. When the replying LSR receives an Echo Request with the first IP
IP address in the Relay Node Address Stack TLV is IP routable, the address in the Relay Node Address Stack TLV IP routable, the replying
replying LSR would send an Echo Reply to the initiator. In addition LSR would send an Echo Reply to the initiator. In addition to the
to the procedure of the Echo Reply described in Section 4.5 of procedure of the Echo Reply described in Section 4.5 of [RFC4379],
RFC4379, the Relay Node Address Stack TLV would be carried in the the Relay Node Address Stack TLV would be carried in the Echo Reply.
Echo Reply.
2. When the intermediate relay node received an Relayed Echo Reply 2. When the intermediate relay node receives a Relayed Echo Reply
with the initiator IP address in the Relay Node Address Stack TLV IP with the first IP address in the Relay Node Address Stack TLV IP
routable, the intermediate relay node would send the Echo Reply to routable, the intermediate relay node would send the Echo Reply to
the initiator with the payload unchanged other than the Message Type the initiator with the UDP payload unchanged other than the Message
field. The destination IP address of the Echo Reply is set to the Type field (change from type of Relayed Echo Reply to Echo Reply).
initiator IP address, and the destination UDP port would be copied The destination IP address of the Echo Reply is set to the first IP
address in the stack, and the destination UDP port would be copied
from the Initiator Source Port field of the Relay Node Address Stack from the Initiator Source Port field of the Relay Node Address Stack
TLV. The source UDP port should be 3503. TLV. The source UDP port should be 3503.
4.6. Receiving an Echo Reply 4.6. Receiving an Echo Reply
In addition to the processes in Section 4.6 of [RFC4379], the In addition to the processes in Section 4.6 of [RFC4379], the
initiator would copy the Relay Node Address Stack TLV received in the initiator would copy the Relay Node Address Stack TLV received in the
Echo Reply to the next Echo Request. Echo Reply to the next Echo Request.
5. LSP Ping Relayed Echo Reply Example 5. LSP Ping Relayed Echo Reply Example
skipping to change at page 10, line 22 skipping to change at page 11, line 17
| PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 |
| | | | | | | | | | | | | | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
<---------------AS1-------------><---------------AS2------------> <---------------AS1-------------><---------------AS2------------>
<--------------------------- LSP -------------------------------> <--------------------------- LSP ------------------------------->
Figure 4: Example Inter-AS LSP Figure 4: Example Inter-AS LSP
In the example, an LSP has been created between PE1 to PE2. When In the example, an LSP has been created between PE1 to PE2. When
performing LSP traceroute on the LSP, the first Echo Request sent by performing LSP traceroute on the LSP, the first Echo Request sent by
PE1 with outter-most label TTL=1, contains the Relay Node Address PE1 with outer-most label TTL=1, contains the Relay Node Address
Stack TLV with the only address of PE1. Stack TLV with PE1's address.
After processed by P1, P1's address will be added in the Relay Node After processed by P1, P1's address will be added in the Relay Node
Address Stack TLV address list following PE1's address in the Echo Address Stack TLV address list following PE1's address in the Echo
Reply. 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 in sequence, and finds out that PE1 Relay Node Address Stack TLV in sequence, and finds out that PE1's
address is routable. Then deletes P1 address, and adds its own address is routable. Then deletes P1's address, and adds its own
address following PE1 address. As a result, there would be PE1 address following PE1 address. As a result, there would be PE1's
address followed by ASBR1 address in the Relay Node Address Stack TLV address followed by ASBR1's address in the Relay Node Address Stack
of the Echo Reply sent by ASBR1. TLV of the Echo Reply sent by ASBR1.
PE1 then sends an Echo Request with outer-most label TTL=3, PE1 then sends an Echo Request with outer-most label TTL=3,
containing the Relay Node Address Stack TLV copied from the received containing the Relay Node Address Stack TLV copied from the received
Echo Reply message. Upon receiving the Echo Request message, ASBR2 Echo Reply message. Upon receiving the Echo Request message, ASBR2
checks the address list in the Relay Node Address Stack TLV in checks the address list in the Relay Node Address Stack TLV in
sequence, and finds out that PE1 address is IP route unreachable, and sequence, and finds out that PE1's address is IP route unreachable,
ASBR1 address is the first routable one in the Relay Node Address and ASBR1's address is the first routable one in the Relay Node
Stack TLV. ASBR2 adds its address as the last address item following Address Stack TLV. ASBR2 adds its address as the last address item
ASBR1 address in Relay Node Address Stack TLV, sets ASBR1 address as following ASBR1's address in Relay Node Address Stack TLV, sets
the destination address of the Relayed Echo Reply, and sends the ASBR1's address as the destination address of the Relayed Echo Reply,
Relayed Echo Reply to ASBR1. and sends the Relayed Echo Reply 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 in sequence, and address list in the Relay Node Address Stack TLV in sequence, and
finds out that PE1 address is first routable one in the address list. finds out that PE1's address is first routable one in the address
Then ASBR1 send an Echo Reply to PE1 with the payload of received list. Then ASBR1 sends an Echo Reply to PE1 with the payload of the
Relayed Echo Reply no changes other than the Message Type field. received Relayed Echo Reply no changes other than the Message Type
field.
For the Echo Request with outer-most label TTL=4, P2 checks the For the Echo Request with outer-most label TTL=4, P2 checks the
address list in the Relay Node Address Stack TLV in sequence, and address list in the Relay Node Address Stack TLV in sequence, and
finds out that both PE1 and ASBR1 addresses are not IP routable, and finds out that both PE1's and ASBR1's addresses are not IP routable,
ASBR2 address is the first routable address. And P2 would send an and ASBR2's address is the first routable address. Then P2 sends an
Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV of Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV
four addresses, PE1, ASBR1, ASBR2 and P2 address in sequence. containing four addresses, PE1's, ASBR1's, ASBR2's and P2's address
in sequence.
Then according to the process described in section 4.4, ASBR2 would Then according to the process described in section 4.4, ASBR2 sends
send the Relayed Echo Reply to ASBR1. Upon receiving the Relayed the Relayed Echo Reply to ASBR1. Upon receiving the Relayed Echo
Echo Reply, ASBR1 would send an Echo Reply to PE1 as PE1 address is Reply, ASBR1 sends an Echo Reply to PE1 which is routable. And as
routable. And as relayed by ASBR2 and ASBR1, the echo response would relayed by ASBR2 and ASBR1, the Echo Reply would finally be sent to
finally be sent to the initiator PE1. the initiator PE1.
For the Echo Request with outer-most label TTL=5, the echo response For the Echo Request with outer-most label TTL=5, the Echo Reply
would relayed to PE1 by ASBR2 and ASBR1, similar to the case of would 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 reachable route to The Echo Reply from the replying node which has no IP reachable route
the initiator is finally transmitted to the initiator by multiple to the initiator is finally 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 then could 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 which 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 may replace the replying node address that originated the Echo
Reply with blank address in Relay Node Address Stack TLV. Reply with blank address in Relay Node Address Stack TLV.
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 draft, the node will ignore the Relay Node Address specified in this document, the node will ignore the Relay Node
Stack TLV as described in section 4.2. Then the initiator may not Address Stack TLV as described in section 4.2. Then the initiator
receive the Relay Node Address Stack TLV in Echo Reply message from may not receive the Relay Node Address Stack TLV in Echo Reply
that node. In this case, an indication should be reported to the message from that node. In this case, an indication should be
operator, and the Relay Node Address Stack TLV in the next Echo reported to the operator, and the Relay Node Address Stack TLV in the
Request message should be copied from the previous Echo Request, and next Echo Request message should be copied from the previous Echo
continue the ping process. If the node described above is located Request, and continue the ping process. If the node described above
between the initiator and the first relay node, the ping process is located between the initiator and the first relay node, the ping
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 is requested to assign one new Message Type, one new TLV and one
new Return Code. new Return Code.
8.1. New Message Type 8.1. New Message Type
New Message Type: This document requires allocation of one new message type from
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" registry, the "Message Type" registry:
Value Meaning Value Meaning
----- ------- ----- -------
TBD MPLS Relayed Echo Reply TBD MPLS Relayed Echo Reply
The value should be assigned from the "Standards Action" range
(0-191), and using the lowest free value within this range.
8.2. New TLV 8.2. New TLV
New TLV: Routable Relay Node Address TLV This document requires allocation of one new TLV from "Multi-Protocol
Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
registry, the "TLVs" registry:
Type Meaning Type Meaning
---- -------- ---- --------
TBD Relay Node Address Stack TLV TBD Relay Node Address Stack TLV
A suggested value is assigned from 32768-49161 as suggested by A suggested value should be assigned from "Standards Action" range
RFC4379 Section 3. (32768-49161) as suggested by [RFC4379] Section 3, using the first
free value within this range.
8.3. New Return Code 8.3. New Return Code
New Return Code: This document requires allocation of one new return code from "Multi-
Value Meaning Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
----- ------- Parameters" registry, the "Return Codes" registry:
TBD Response Packet length was exceeded by the Relay Node
Address Stack TLV unexpected Value Meaning
----- -------
TBD Response Packet length was exceeded unexpected by the Relay
Node Address Stack TLV unexpected
The value should be assigned from the "Standards Action" range
(0-191), and using the lowest free value within this range.
9. Acknowledgement 9. Acknowledgement
The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel
Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin and Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin and
Gregory Mirsky for their valuable comments and suggestions. Gregory Mirsky for their valuable comments and suggestions.
10. Contributors 10. Contributors
Ryan Zheng Ryan Zheng
skipping to change at page 13, line 35 skipping to change at page 14, line 43
[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,
February 2006. February 2006.
11.2. Informative References 11.2. Informative References
[I-D.ietf-mpls-seamless-mpls] [I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", M., and D. Steinberg, "Seamless MPLS Architecture",
draft-ietf-mpls-seamless-mpls-05 (work in progress), draft-ietf-mpls-seamless-mpls-06 (work in progress),
January 2014. February 2014.
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)
Shanghai, China Shanghai, China
Email: lizho.jin@gmail.com Email: lizho.jin@gmail.com
Thomas Nadeau (editor) Thomas Nadeau (editor)
Lucidvision Lucidvision
Email: tnadeau@lucidvision.com Email: tnadeau@lucidvision.com
 End of changes. 65 change blocks. 
197 lines changed or deleted 228 lines changed or added

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