draft-ietf-mpls-lsp-ping-relay-reply-09.txt   draft-ietf-mpls-lsp-ping-relay-reply-10.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 Individual Intended status: Standards Track Individual
Expires: November 26, 2015 T. Nadeau, Ed. Expires: January 7, 2016 T. Nadeau, Ed.
Lucidvision Lucidvision
G. Swallow, Ed. G. Swallow, Ed.
Cisco Cisco
May 25, 2015 July 6, 2015
Relayed Echo Reply mechanism for LSP Ping Relayed Echo Reply mechanism for LSP Ping
draft-ietf-mpls-lsp-ping-relay-reply-09 draft-ietf-mpls-lsp-ping-relay-reply-10
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 Label Switching Router (LSR) may not have the
initiator, and the Echo Reply message sent to the initiator would be available route to an initiator, and the Echo Reply message sent to
discarded resulting in false negatives or complete failure of the initiator would be discarded resulting in false negatives or
operation of LSP Ping and Traceroute. This document describes complete failure of operation of LSP Ping and Traceroute. This
extensions to LSP Ping mechanism to enable the replying Label document describes extensions to LSP Ping mechanism to enable the
Switching Router (LSR) to have the capability to relay the Echo replying LSR to have the capability to relay the Echo Response by a
Response by a set of routable intermediate nodes to the initiator. set of routable intermediate nodes to the initiator. This document
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 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 November 26, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 8 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8
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 an Relayed Echo Reply . . . . . . . . . . . . 10
4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 10 4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 10
4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 10 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 11
4.6. Sending Subsequent Echo Requests . . . . . . . . . . . . 11 4.6. Sending Subsequent Echo Requests . . . . . . . . . . . . 11
4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 11 4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 12
5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 12 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 14 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 14 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 14
8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 15 8.3. MTU Exceeded Return Code . . . . . . . . . . . . . . . . 15
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document describes the extensions to the Label Switched Path This document describes extensions to the Label Switched Path (LSP)
(LSP) Ping as specified in [RFC4379], by adding a relayed echo reply 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 report data plane failures for inter
inter autonomous system (AS) and inter-area LSPs. The extensions are autonomous system (AS) and inter-area LSPs. Without these
to update the [RFC4379]. Without these extensions, the ping extensions, the ping functionality provided by [RFC4379] would fail
functionality provided by [RFC4379] would fail in many deployed in many deployed inter-AS scenarios, since the replying Label
inter-AS scenarios, since the replying LSR in one AS may not have the Switching Router (LSR) in one AS may not have an available route to
available route to the initiator in the other AS. The mechanism in the initiator in the other AS. The mechanism in this document
this document defines a new message type referred as "Relayed Echo defines a new message type referred as "Relayed Echo Reply message",
Reply message", and a new TLV referred as "Relay Node Address Stack and a new TLV referred as "Relay Node Address Stack TLV".
TLV".
This document is also to update [RFC4379], include updating of Echo This document is also to update [RFC4379], include updating of Echo
Request sending procedure in section 4.3 of [RFC4379], Echo Request Request sending procedure in section 4.3 of [RFC4379], Echo Request
receiving procedure in section 4.4 of [RFC4379], Echo Reply sending receiving procedure in section 4.4 of [RFC4379], Echo Reply sending
procedure in Section 4.5 of [RFC4379], Echo Reply receiving procedure procedure in Section 4.5 of [RFC4379], Echo Reply receiving procedure
in section 4.6 of [RFC4379]. 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 the data plane LSP Ping [RFC4379] defines a mechanism to detect data plane failures
failures and localize faults. The mechanism specifies that the Echo and localize faults. The mechanism specifies that the Echo Reply
Reply should be sent back to the initiator using an UDP packet with should be sent back to the initiator using an UDP packet with the
the IPv4/IPv6 address of the originating LSR. This works in IPv4/IPv6 destination address set to an address of the LSR that
administrative domains where IP addresses reachability are allowed originated the Echo Request. This works in administrative domains
among LSRs, and every LSR is able to route back to the originating where IP address reachability is allowed among LSRs, and every LSR is
LSR. However, in practice, this is often not the case due to intra- able to route back to the originating LSR. However, in practice,
provider routing policy, route hiding, and network address this is often not the case due to intra-provider routing policy,
translation at autonomous system border routers (ASBR). In fact, it route hiding, and network address translation at autonomous system
is almost uniformly the case that in inter-AS scenarios, it is not border routers (ASBR). In fact, it is almost always the case that in
allowed the distribution or direct routing to the IP addresses of any inter-AS scenarios the only node in one AS to which direct routing is
of the nodes other than the ASBR in another AS. allowed from the other AS is the ASBR, and routing information from
within one AS is not distributed into another AS.
Figure 1 demonstrates a case where one 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. E.g., P2
cannot forward packets back to PE1 given that it is an routable IP cannot forward packets back to PE1 given that it is an 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 is
skipping to change at page 4, line 35 skipping to change at page 4, line 25
+-------+ +-------+ +------+ +------+ +------+ +------+ +-------+ +-------+ +------+ +------+ +------+ +------+
<---------------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 LSRs in the core network would not have IP reachable route to example LSRs in the core network would not have IP reachable route to
any of the ANs. When tracing an LSP from one AN to the remote AN, any of the ANs. When tracing an LSP from one access node (AN) to the
the LSR1/LSR2 node cannot send the Echo Reply either, like the P2 remote AN, the LSR1/LSR2 node cannot send the Echo Reply either, like
node in the inter-AS scenario in Figure 1. 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
skipping to change at page 5, line 43 skipping to change at page 5, line 24
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 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 relay nodes for the
the replying LSR. replying LSR.
In addition, MTU (Maximum Transmission Unit) Exceeded Return Code is In addition, MTU (Maximum Transmission Unit) Exceeded Return Code is
defined to indicate to the initiator that one or more TLVs will not defined to indicate to the initiator that one or more TLVs will not
be returned due to MTU size. 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
skipping to change at page 6, line 20 skipping to change at page 5, line 49
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 TBD1 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
skipping to change at page 6, line 42 skipping to change at page 6, line 25
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 octects) | | Source Address of Replying Router (0, 4, or 16 octects) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address Pointer | 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: to be assigned by IANA. A value should be assigned from - Type: value is TBD2. The value should be assigned by IANA 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 - 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.
skipping to change at page 7, line 22 skipping to change at page 7, line 4
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 Replay Echo Reply message.
- Destination Address Pointer: an integer entry number used as the - Destination Address Offset: an offset (octets) to indicate the
destination address of the Reply or Relayed Reply message. The position of the destination address of the Reply or Relayed Reply
entry on the top of the Stack of Relayed Addresses will have value message. The entry on the top of the Stack of Relayed Addresses
1. will have offset of 0.
- 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
skipping to change at page 8, line 4 skipping to change at page 7, line 34
| Address Type |K| Reserved | Reserved | | 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 Null 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: The two fields are 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 address stack entry MUST
Relay Node Address Stack during TLV compress process described in NOT be stripped from the Relay Node Address Stack during processing
section 4.2. described in Section 4.2. If the K bit is clear, the entry might be
stripped according to the processing described in Section 4.2.
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. 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 Return Code is defined to indicate that one or more TLVs were omitted
from the Echo Reply or Relayed Echo Reply message to avoid exceeding from the Echo Reply or Relayed Echo Reply message to avoid exceeding
the message's effective MTU size. These TLVs MAY be included in an the message's effective MTU size. These TLVs MAY be included in an
Errored TLV's Object with their lengths set to 0 and no value. The 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 return sub-code MUST be set to the value that otherwise would have
been sent. been sent. For more detail, please refer to section 4.2.
MTU Exceeded Return Code: MTU Exceeded Return Code:
Value Meaning Value Meaning
----- ------- ----- -------
TBD One or more TLVs not returned due to MTU size TBD2 One or more TLVs not returned due to MTU size
Then section 4.4 of [RFC4379], step 7 will be updated to integrate
the processing of MTU Exceeded Return Code.The following text will be
added:
Before sending Echo Reply, the new packet size should be checked. If
Best-return-code is 3 ("Replying router is an egress for the FEC at
stack depth"), or 8 ("Label switched at stack-depth"), and if the
packet size exceeds MTU size, then Best-return-code is TBD3 ("One or
more TLVs not returned due to MTU size")
4. Procedures 4. Procedures
In the following section, we describe the relay reply procedures with
traceroute operation. If operator has knowledge of the relay nodes,
the initiator could do LSP Ping by directly sending Echo Request with
Relay Node Address Stack TLV containing the already known relay
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 to facilitate the relay functionality. message if the relay functionality is required.
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 pointer 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 source UDP port field MUST be set replying router set to null. The Initiator Source Port field MUST be
to the source UDP port. Note that the first relay node address in set to the source UDP port. Note that the first relay node address
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.
4.2. Receiving an Echo Request 4.2. Receiving an Echo Request
An LSR that does not recognize the Relay Node Address Stack TLV, The Type of the Relay Node Address Stack TLV is chosen from the range
SHOULD ignore it as per section 3 of [RFC4379]. 32768 to 49161 so that (per section 3 of [RFC4379]) an LSR that does
not recognize the TLV knows that the TLV is optional and can safely
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 same as the source IP address of Relay
Echo Reply (section 4.3) or Echo Reply message (section 4.5) being Echo Reply (section 4.3) or Echo Reply message (section 4.5) being
sent. sent.
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 receiver MUST check the addresses of the stack in sequence from The receiver MUST check the addresses of the stack in sequence from
bottom to top to find the last address in the stack with the K bit bottom to top to find the last address in the stack with the K bit
set (or the top of the stack if no K bit was found). The receiver set (or the top of the stack if no K bit was found). The receiver
then checks the stack beginning with this entry, proceeding towards then checks the stack beginning with this entry, proceeding towards
the bottom to find the first routable address IP address. The the bottom to find the first routable address IP address. The
Destination Address Pointer MUST be set to this entry which is also Destination Address Offset MUST be set to this entry which is also
the Destination Address. Address entries below the first routable IP the resolved destination address. Address entries below the first
address MUST be deleted. At least one address entries of the routable IP address MUST be deleted. At least one address entries of
replying LSR MUST be added at the bottom of the stack. A second or the replying LSR MUST be added at the bottom of the stack. A second
more address entries MAY also be added if necessary, depending on or more address entries MAY also be added if necessary, depending on
implementation. The final address added MUST be an address that is implementation. The final address added MUST be an address that is
reachable through the interface that the Echo Request Message would reachable through the interface that the Echo Request Message would
have been forwarded if it had not TTL expired at this node. The 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 updated Relay Node Address Stack TLV MUST be carried in the response
message. 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. K other domain, then the final address added SHOULD set the K bit. One
bit applies in the case of a NULL address, to serve as a warning to example of spanning two address domains is the ASBR node. Other
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
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 an Relayed Echo Reply
The Destination Address determined in section 4.2 is used as the next The destination address determined in section 4.2 is used as the next
relay node address. If the resolved next relay node address is not relay node address. If the resolved next relay node address is not
routable, then sending of Relayed Echo Reply or Echo Reply will fail. routable, then sending of 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 Replying Router field is kept unmodified, and
Source IP address field of the IP header is set to an address of the Source IP address field of the IP header is set to an address of the
sending node. sending node.
When the next relay node address is the first one in the address
list, please refer to section 4.5.
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 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 Pointer 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 section 4.2 no
changes are made to the Stack of Relayed Addresses. 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 an Relayed Echo Reply message to the determined upstream node with
the payload unchanged other than the Relay Node Address Stack TLV. the payload unchanged other than the Relay Node Address Stack TLV.
The TTL SHOULD be copied from the received Relay Echo Reply and The 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 Replying Router field is
kept unmodified, and Source IP address field of the IP header is set kept unmodified, and Source IP address field of the IP header is set
to an address of the sending node. to an address of the sending node.
When the next relay node address is the first one in the address
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 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.
If the receiver does not recognize the Relay Node Address Stack TLV,
as per section 3 and 4.5 of [RFC4379], it will send an Echo 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 the
next relay node address (section 4.4), the intermediate relay node next relay node address (section 4.4), the intermediate relay node
would send the Echo Reply to the initiator, and update the Message would send the Echo Reply to the initiator, and update the Message
Type field from type of Relayed Echo Reply to Echo Reply. The Type field from type of Relayed Echo Reply to Echo Reply. The
updated Relay Node Address Stack TLV described in section 4.4 MUST be updated Relay Node Address Stack TLV described in section 4.4 MUST be
carried in the Echo Reply. The destination IP address of the Echo 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 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
skipping to change at page 11, line 33 skipping to change at page 11, line 49
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 with K bit unset MAY be
removed. A NIL entry with K bit serves as a warning that further removed. A NIL entry with K bit serves as a warning that further
Echo Request messages are likely to not result in a reply. If, Echo Request messages are likely to not result in a reply. If,
however, the initiator decides to continue a traceroute operation, however, the initiator decides to continue a traceroute operation,
the NIL entry with the K bit set MUST be removed. The Source Address the NIL entry with the K bit set MUST be removed. The Source Address
of Replying Router and Destination Address Pointer fields may be of Replying Router and Destination Address Offset fields may be
preserved or reset since these fields are ignored in received MPLS preserved or reset since these fields are ignored in received MPLS
Echo Request. 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:
skipping to change at page 13, line 50 skipping to change at page 14, line 16
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 NIL address entry in Relay Node Address Stack TLV. Reply with NIL address entry in 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,
and such information may be maliciously used by any uncontrolled LSR/
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
unless you have to.
2. it is encouraged to use NIL address entry to hide node 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
skipping to change at page 14, line 31 skipping to change at page 15, line 7
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 TBD1 MPLS Relayed Echo Reply
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.
8.2. New TLV 8.2. New TLV
This document requires allocation of one new TLV from "Multi-Protocol This document requires allocation of one new TLV from "Multi-Protocol
Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
registry, the "TLVs" registry: registry, the "TLVs" registry:
Type Meaning Type Meaning
---- -------- ---- --------
TBD Relay Node Address Stack TLV TBD2 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. MTU Exceeded Return Code 8.3. MTU Exceeded Return Code
This document requires allocation of MTU Exceeded return code from This document requires allocation of MTU Exceeded return code from
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" registry, the "Return Codes" registry: Ping Parameters" registry, the "Return Codes" registry:
Value Meaning Value Meaning
----- ------- ----- -------
TBD One or more TLVs not returned due to MTU size TBD3 One or more TLVs not returned due to MTU size
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.
 End of changes. 41 change blocks. 
96 lines changed or deleted 128 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/