draft-ietf-mpls-lsp-ping-relay-reply-06.txt   draft-ietf-mpls-lsp-ping-relay-reply-07.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 Individual
Expires: June 8, 2015 T. Nadeau, Ed. Expires: September 8, 2015 T. Nadeau, Ed.
Lucidvision Lucidvision
G. Swallow, Ed. G. Swallow, Ed.
Cisco Cisco
December 5, 2014 March 7, 2015
Relayed Echo Reply mechanism for LSP Ping Relayed Echo Reply mechanism for LSP Ping
draft-ietf-mpls-lsp-ping-relay-reply-06 draft-ietf-mpls-lsp-ping-relay-reply-07
Abstract Abstract
In some inter autonomous system (AS) and inter-area deployment In some inter autonomous system (AS) 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 LSR may not have the available route to the Traceroute", a replying LSR may not have the available route to the
initiator, and the Echo Reply message sent to the initiator would be initiator, and the Echo Reply message sent to the initiator would be
discarded resulting in false negatives or complete failure of discarded resulting in false negatives or complete failure of
operation of LSP Ping and Traceroute. This document describes operation of LSP Ping and Traceroute. This document describes
extensions to LSP Ping mechanism to enable the replying Label extensions to LSP Ping mechanism to enable the replying Label
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 June 8, 2015. This Internet-Draft will expire on September 8, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 40 skipping to change at page 2, line 40
than English. than English.
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 . . . . . . . . . . . . . . . 6 3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . 6
3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . 6 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . 6
3.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 8 3.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 8
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8
4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 8 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 9
4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 9 4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 10
4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 9 4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 10
4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 10 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 10
4.6. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 10 4.6. Sending Subsequent Echo Requests . . . . . . . . . . . . 11
4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 10 4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 11
5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 11 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 13 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 13 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 14
8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 14 8.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 14
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 for the mechanism which could be used to detect data plane failures for the
skipping to change at page 5, line 46 skipping to change at page 5, line 46
two message types, Echo Request and Echo Reply message. This two message types, Echo Request and Echo Reply message. This
document defines a new message, Relayed Echo Reply message. This new document defines a new message, Relayed Echo Reply message. This new
message is used to replace Echo Reply message which is sent from the message is used to replace Echo Reply message which is sent from the
replying LSR to a relay node or from a relay node to another relay replying LSR to a relay node or from a relay node to another relay
node. 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
document, to carry the IP addresses of the possible relay nodes for document, to carry the IP addresses of the possible relay nodes for
the replying LSR. the replying LSR.
In addition, a new Return Code is defined to notify the initiator In addition, MTU (Maximum Transmission Unit) Exceeded Return Code is
that the packet length is exceeded unexpected by the Relay Node defined to indicate to the initiator that one or more TLVs will not
Address Stack TLV. be returned due to 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 which 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. Supporting for mixed IPv4-only and
IPv6-only is beyond the scope of this document. IPv6-only is beyond the scope of this document.
skipping to change at page 6, line 38 skipping to change at page 6, line 38
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 | Number of Relayed Addresses | | Initiator Source Port | Reply Add Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address of Replying Router (0, 4, or 16 octects) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address Pointer | 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 value should be 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 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 also 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
also implies the length of the address field as shown below.
Type# Address Type Address Length
---- ------------ ------------
0 Null 0
1 IPv4 4
2 IPv6 16
- Reserved: This field is reserved and MUST be set to zero.
- Source Address of Replying Router: source IP address of the
originator of Echo Reply or Replay Echo Reply message.
- Destination Address Pointer: an integer entry number used as the
destination address of the Reply or Relayed Reply message. The
entry on the top of the Stack of Relayed Addresses will have value
1.
- 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 |K| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 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 Null 0
1 IPv4 4 1 IPv4 4
2 IPv6 16 2 IPv6 16
Reserved: The two fields are reserved and MUST be set to zero.
Reserved: This field is reserved and MUST be set to zero.
K bit: if the K bit is set to 1, then this sub-TLV MUST 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 during TLV compress process described in Relay Node Address Stack during TLV compress process described in
section 4.2. The entry with Unspecified Address Type SHOULD NOT set section 4.2.
K bit.
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 K bit set will
always be a relay node address for the Relayed Echo Reply, see always be a relay node address for the Relayed Echo Reply, see
section 4.3. Some nodes could be configured to always set the K bit, section 4.3.
or the module handling MPLS echo requests could discover its K bit
use through topology awareness. One application scenario of K bit is
given out in section 5.
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. New Return Code 3.3. MTU Exceeded Return Code
A new Return Code is used by the replying LSR to notify the initiator Return Code is defined to indicate that one or more TLVs were omitted
that the packet length is exceeded unexpected by the Relay Node from the Reply or Relay-Reply message to avoid exceeding the
Address Stack TLV. message's effective MTU size. These TLVs MAY be included in an
Errored TLV's Object with their lengths set to 0 and no value. The
return sub-code MUST be set to the value that otherwise would have
been sent.
New Return Code: MTU Exceeded Return Code:
Value Meaning Value Meaning
----- ------- ----- -------
TBD Response Packet length was exceeded by the Relay Node TBD One or more TLVs not returned due to MTU size
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 to facilitate the relay functionality. message to facilitate the relay functionality.
When the Echo Request is first sent by the initiator, a Relay Node When the Echo Request is first sent by the initiator included a Relay
Address Stack TLV with the initiator address in the stack and its Node Address Stack TLV, the TLV MUST contain the initiator address as
source UDP port MUST be included. That will ensure that the first the only entry of the stack of relayed addresses, the destination
relay node address in the stack will always be the initiator address. address pointer set to this entry, and the source address of the
replying router set to null. The source UDP port field MUST be set
For the subsequent Echo Request messages, the initiator would copy to the source UDP port. Note that the first relay node address in
the Relay Node Address Stack TLV from the received Echo Reply the stack will always be the initiator's address.
message.
4.2. Receiving an Echo Request 4.2. Receiving an Echo Request
An LSR that does not recognize the Relay Node Address Stack TLV,
SHOULD ignore it as per section 3 of [RFC4379].
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 in an Echo Request
message, the receiver MUST check the addresses of the stack in message, the receiver updates the "Source Address of Replying
sequence from top to bottom (the first address in the stack will be Router". The address MUST be same as the source IP address of Relay
the first one to be checked), to find out the first routable IP Echo Reply (section 4.3) or Echo Reply message (section 4.5) being
address. Those address entries behind of the first routable IP sent.
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 Those address entries with K bit set to 1 MUST be kept in the stack.
the stack. The address entry added by the replying LSR MUST be same The receiver MUST check the addresses of the stack in sequence from
as the source IP address of Relay Echo Reply (section 4.3) or Echo bottom to top to find the last address in the stack with the K bit
Reply message (section 4.5) being sent. A second or more address set (or the top of the stack if no K bit was found). The receiver
entries could also be added if necessary, which depends on then checks the stack beginning with this entry, proceeding towards
implementation. Those address entries with K bit set to 1 MUST be the bottom to find the first routable address IP address. The
kept in the stack. The updated Relay Node Address Stack TLV MUST be Destination Address Pointer MUST be set to this entry. Address
carried in the response message. entries below the first routable IP address MUST be deleted. At
least one address entries of the replying LSR MUST be added at the
bottom of the stack. A second or more address entries MAY also be
added if necessary, depending on implementation. The final address
added MUST be an address that is reachable through the interface that
the Echo Request Message would have been forwarded if it had not TTL
expired at this node. The updated Relay Node Address Stack TLV MUST
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 SHOULD be a blank information, the address entry added in the stack MUST be a NIL entry
entry with Address Type set to unspecified. The blank address entry with Address Type set to NULL.
in the receiving Echo Request SHOULD be treated as an unroutable
address entry.
If the packet length was exceeded unexpectedly by the Relay Node If a node spans two addressing domains (with respect to this message)
Address Stack TLV, the TLV SHOULD be returned back unchanged in the where nodes on either side may not be able to nodes in the other
Echo Reply message. And the new return code in section 3.3 SHOULD be domain, then the final address added MUST set the K bit. K bit
used to notify the initiator of the situation. applies in the case of a NULL address, to serve as a warning to the
initiator that further Echo Request messages may not result in
receiving Echo Reply messages.
An LSR not recognize the Relay Node Address Stack TLV, SHOULD ignore If the full reply message would exceed the MTU size, the Relay Node
it according to section 3 of [RFC4379]. Address Stack TLV MUST be returned back in the Echo Reply message.
Some other TLV(s) MUST be dropped.
4.3. Originating an Relayed Echo Reply 4.3. Originating an Relayed Echo Reply
To find out the next relay node address, the node SHOULD check the The Destination Address determined in section 4.2 is used as the next
address items in Relay Node Address Stack TLV in sequence from top to relay node address. If the resolved next relay node address is not
down, and find the first IP routable address, e.g., A, and the last routable, then sending of Relayed Echo Reply or Echo Reply will fail.
address with K bit set, e.g., B. If address A is before address B in
Relay Node Address Stack TLV, then use address B as the next relay
node address. Otherwise, use address A as the next relay node
address. If there is no B existed, then use A as the next relay node
address. If the resolved next relay node address is not routable,
then sending of Relayed Echo Reply or Echo Reply will fail.
When the replying LSR receives an Echo Request, and the first IP If the first IP address in the Relay Node Address Stack TLV is not
address in the Relay Node Address Stack TLV is not the next relay the next relay node address, the replying LSR SHOULD send a Relayed
node address, the replying LSR SHOULD send a Relayed Echo Reply Echo Reply message to the next relay node. The processing of Relayed
message to the next relay node. The processing of Relayed Echo Reply Echo Reply is the same with the procedure of the Echo Reply described
is the same with the procedure of the Echo Reply described in in Section 4.5 of [RFC4379], except the destination IP address and
Section 4.5 of [RFC4379], except the destination IP address and the the destination UDP port. The destination IP address of the Relayed
destination UDP port. The destination IP address of the Relayed Echo Echo Reply is set to the next relay node address from the Relay Node
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 is
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. section 4.2 MUST be carried in the Relayed Echo Reply message.
4.4. Relaying an Relayed Echo Reply 4.4. Relaying an Relayed Echo Reply
Upon receiving an Relayed Echo Reply message with its own address as Upon receiving an Relayed Echo Reply message with its own address as
the destination address in the IP header, the relay node SHOULD find the destination address in the IP header, the relay node MUST
out the next relay node address as described in section 4.3. determine the next relay node address as described in section 4.3,
with the modification that the location of the received Destination
Address is used instead of the bottom of stack in the algorithm. The
destination address in Relay Node Address Stack TLV will be updated
with the next relay node address. Note that unlike section 4.2 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, e.g, another intermediate relay node, the relay node SHOULD list, i.e., another intermediate relay node, the relay node MUST send
send an Relayed Echo Reply message to this next relay node with the an Relayed Echo Reply message to the determined upstream node with
payload unchanged. The TTL of the Relayed Echo Reply SHOULD be the payload unchanged other than the Relay Node Address Stack TLV.
copied from the received Relay Echo Reply and decremented by 1. The TTL SHOULD be copied from the received Relay Echo Reply and
decremented by 1.
Note, the next relay node address MUST be located before 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 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 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 node
address (section 4.3), the replying LSR would send an Echo Reply to address (section 4.3), the replying LSR would send an Echo Reply to
the initiator. In addition to the procedure of the Echo Reply the initiator. In addition to the procedure of the Echo Reply
described in Section 4.5 of [RFC4379], the updated Relay Node Address described in Section 4.5 of [RFC4379], the updated Relay Node Address
Stack TLV described in section 4.2 MUST be carried in the Echo Reply. Stack TLV described in section 4.2 MUST be carried in the Echo Reply.
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 the
next relay node address (section 4.3), the intermediate relay node next relay node address (section 4.4), the intermediate relay node
would send the Echo Reply to the initiator with the UDP payload would send the Echo Reply to the initiator, and update the Message
unchanged other than the Message Type field (change from type of Type field from type of Relayed Echo Reply to Echo Reply. The
Relayed Echo Reply to Echo Reply). The destination IP address of the updated Relay Node Address Stack TLV described in section 4.4 MUST be
Echo Reply is set to the first IP address in the stack, and the carried in the Echo Reply. 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 destination UDP port would be copied from the Initiator Source Port
field of the Relay Node Address Stack TLV. The source UDP port field of the Relay Node Address Stack TLV. The source UDP port
should be 3503. The TTL of the Echo Reply SHOULD be copied from the should be 3503. The TTL of the Echo Reply SHOULD be copied from the
received Relay Echo Reply and decremented by 1. received Relay Echo Reply and decremented by 1.
4.6. Receiving an Echo Reply 4.6. Sending Subsequent Echo Requests
In addition to the processes in Section 4.6 of [RFC4379], the During a traceroute operation, multiple Echo Request messages are
initiator would copy the Relay Node Address Stack TLV received in the sent. Each time the TTL is increased, the initiator MUST copy the
Echo Reply to the next Echo Request. Relay Node Address Stack TLV received in the previous Echo Reply to
the next Echo Request.
4.7. Impact to Traceroute 4.7. Impact to Traceroute
Source IP address in Echo Reply and Relay Echo Reply is to be of the Source IP address in Echo Reply and Relay Echo Reply is to be of the
address of the node sending those packets, not the original 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 last address in the stack; Print the Source Address of Replying Router in
} else { Relay Node Address Stack TLV;
} 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 4 below. Considering the inter-AS scenario in Figure 4 below. AS1 and AS2 are
two independent address domains. In the example, an LSP has been
created between PE1 to PE2, but PE1 in AS1 is not reachable by P2 in
AS2.
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | | | | | | | | | | | | | |
| 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 When performing LSP traceroute on the LSP, the first Echo Request
performing LSP traceroute on the LSP, the first Echo Request sent by sent by PE1 with outer-most label TTL=1, contains the Relay Node
PE1 with outer-most label TTL=1, contains the Relay Node Address Address Stack TLV with PE1's address as the first relayed address.
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 interface address facing ASBR1 without
Address Stack TLV address list following PE1's address in the Echo the K bit set will be added in the Relay Node Address Stack TLV
Reply. 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 in sequence, and finds out that PE1's Relay Node Address Stack TLV, and determines that PE1's address is
address is routable. Then deletes P1's address, and adds its own the next relay address. Then deletes P1's address, and adds its
address following PE1 address. As a result, there would be PE1's interface address facing ASBR2 with the K bit set. As a result,
address followed by ASBR1's address in the Relay Node Address Stack there would be PE1's address followed by ASBR1's interface address
TLV of the Echo Reply sent by ASBR1. facing ASBR2 in the Relay Node Address Stack 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, and
sequence, and finds out that PE1's address is IP route unreachable, determines ASBR1's interface address is the next relay address in the
and ASBR1's address is the first routable one in the Relay Node stack TLV. ASBR2 adds its interface address facing P2 with the K bit
Address Stack TLV. So ASBR1 is the next relay node. ASBR2 adds its set. Then ASBR2 sets the next relay address as the destination
address as the last address item following ASBR1's address in Relay
Node Address Stack TLV, sets ASBR1's address as the destination
address of the Relayed Echo Reply, and sends the Relayed Echo Reply address of the 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 in sequence, and address list in the Relay Node Address Stack TLV, and determines that
finds out that PE1's address is first routable one in the address PE1's address is the next relay node. Then ASBR1 sends an Echo Reply
list. So PE1 is the next relay node. Then ASBR1 sends an Echo Reply to PE1.
to PE1 with the payload of the received Relayed Echo Reply unchanged
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, and determines that
finds out that both PE1's and ASBR1's addresses are not IP routable, ASBR2's interface address is the next relay address. Then P2 sends
and ASBR2's address is the first routable address. Then P2 sends an 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, ASBR2's and P2's address interface address and P2's interface address facing PE2 in sequence.
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 which is IP routable. And as Reply, ASBR1 sends an Echo Reply to PE1. And as relayed by ASBR2 and
relayed by ASBR2 and ASBR1, the Echo Reply would finally be sent to ASBR1, the Echo Reply would finally be sent to the initiator PE1.
the initiator PE1.
For the Echo Request with outer-most label TTL=5, the Echo Reply 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 IP reachable route The Echo Reply from the replying node which has no IP reachable route
to the initiator is finally transmitted to the initiator by multiple to the initiator is thus transmitted to the initiator by multiple
relay nodes. relay nodes.
In the case that the interface address of ASBR1 to P1 is IP1 which
maybe an IPv4 private address and not IP routable for AS2, and the
loopback address on ASRB1 is IP2 which is routable for AS2. Then
when ASBR1 sends a Relayed Echo Reply, it will firstly add IP1
without K bit set in the Relay Node Address Stack TLV, and then add
IP2 with K bit set in the stack TLV. Then ASBR2/P2 could relay the
Relayed Echo Reply back first to IP2 which is routable for ASBR2/P2,
then ASBR1 will send Echo Reply to PE1. Thanks for the K bit, the
ASBR1 will not be skipped for message relay.
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.
skipping to change at page 13, line 40 skipping to change at page 14, line 8
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 is requested to assign one new Message Type, one new TLV and one
new Return Code. Return Code.
8.1. New Message Type 8.1. New Message Type
This document requires allocation of one new message type from This document requires allocation of one new message type from
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" registry, the "Message Type" registry: Ping Parameters" registry, the "Message Type" registry:
Value Meaning Value Meaning
----- ------- ----- -------
TBD MPLS Relayed Echo Reply TBD MPLS Relayed Echo Reply
skipping to change at page 14, line 22 skipping to change at page 14, line 37
registry, the "TLVs" registry: registry, the "TLVs" registry:
Type Meaning Type Meaning
---- -------- ---- --------
TBD Relay Node Address Stack TLV TBD Relay Node Address Stack TLV
A suggested value should be assigned from "Standards Action" range A suggested value should be assigned from "Standards Action" range
(32768-49161) as suggested by [RFC4379] Section 3, using the first (32768-49161) as suggested by [RFC4379] Section 3, using the first
free value within this range. free value within this range.
8.3. New Return Code 8.3. MTU Exceeded Return Code
This document requires allocation of one new return code from "Multi- This document requires allocation of MTU Exceeded return code from
Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Parameters" registry, the "Return Codes" registry: Ping Parameters" registry, the "Return Codes" registry:
Value Meaning Value Meaning
----- ------- ----- -------
TBD Response Packet length was exceeded unexpected by the Relay TBD One or more TLVs not returned due to MTU size
Node Address Stack TLV unexpected
The value should be assigned from the "Standards Action" range The value should be assigned from the "Standards Action" range
(0-191), and using the lowest free value within this 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, Gregory Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin, Gregory
Mirsky, Nobo Akiya and Joel M. Halpern for their valuable comments Mirsky, Nobo Akiya and Joel M. Halpern for their valuable comments
and suggestions. and suggestions.
skipping to change at page 15, line 31 skipping to change at page 16, line 4
ietf-mpls-seamless-mpls-07 (work in progress), June 2014. ietf-mpls-seamless-mpls-07 (work in progress), June 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)
Individual
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
George Swallow (editor) George Swallow (editor)
 End of changes. 53 change blocks. 
166 lines changed or deleted 179 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/