draft-ietf-mpls-return-path-specified-lsp-ping-15.txt   rfc7110.txt 
Network Working Group M. Chen Internet Engineering Task Force (IETF) M. Chen
Internet-Draft W. Cao Request for Comments: 7110 W. Cao
Intended status: Standards Track Huawei Technologies Co., Ltd Category: Standards Track Huawei Technologies Co., Ltd
Expires: April 24, 2014 S. Ning ISSN: 2070-1721 S. Ning
Tata Communications Tata Communications
F. Jounay F. Jounay
Orange CH Orange CH
S. Delord S. Delord
Alcatel-Lucent January 2014
October 21, 2013
Return Path Specified LSP Ping Return Path Specified Label Switched Path (LSP) Ping
draft-ietf-mpls-return-path-specified-lsp-ping-15.txt
Abstract Abstract
This document defines extensions to the data-plane failure-detection This document defines extensions to the data-plane failure-detection
protocol for Multiprotocol Label Switching (MPLS) Label Switched protocol for Multiprotocol Label Switching (MPLS) Label Switched
Paths (LSPs) known as "LSP Ping". These extensions allow selection Paths (LSPs) known as "LSP ping". These extensions allow a selection
of the LSP to use for the echo reply return path. Enforcing a of the LSP to be used for the echo reply return path. Enforcing a
specific return path can be used to verify bidirectional connectivity specific return path can be used to verify bidirectional connectivity
and also increase LSP ping robustness. and also increase LSP ping robustness.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 24, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7110.
Copyright Notice Copyright Notice
Copyright (c) 2013 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Problem Statements and Solution Overview . . . . . . . . . . 3 2. Requirements Language ...........................................3
2.1. Limitations of Existing Mechanisms for Bidirectional LSPs 3 3. Problem Statements and Solution Overview ........................3
2.2. Limitations of Existing Mechanisms for Handling 3.1. Limitations of Existing Mechanisms for Bidirectional LSPs ..4
Unreliable Return Paths . . . . . . . . . . . . . . . . . 4 3.2. Limitations of Existing Mechanisms for Handling
3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 5 Unreliable Return Paths ....................................4
3.1. Reply Via Specified Path mode . . . . . . . . . . . . . . 5 4. Extensions ......................................................5
3.2. Reply Path (RP) TLV . . . . . . . . . . . . . . . . . . . 6 4.1. Reply via Specified Path Mode ..............................6
3.3. Tunnel sub-TLVs . . . . . . . . . . . . . . . . . . . . . 8 4.2. Reply Path (RP) TLV ........................................6
3.3.1. IPv4 RSVP Tunnel sub-TLV . . . . . . . . . . . . . . 9 4.3. Tunnel Sub-TLVs ............................................8
3.3.2. IPv6 RSVP Tunnel sub-TLV . . . . . . . . . . . . . . 10 4.3.1. IPv4 RSVP Tunnel Sub-TLV ...........................10
3.3.3. Static Tunnel sub-TLV . . . . . . . . . . . . . . . . 11 4.3.2. IPv6 RSVP Tunnel Sub-TLV ...........................11
3.4. Reply TC TLV . . . . . . . . . . . . . . . . . . . . . . 11 4.3.3. Static Tunnel Sub-TLV ..............................12
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 12 4.4. Reply TC TLV ..............................................12
4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 12 5. Theory of Operation ............................................13
4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 13 5.1. Sending an Echo Request ...................................14
4.3. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 14 5.2. Receiving an Echo Request .................................14
4.4. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 14 5.3. Sending an Echo Reply .....................................15
4.5. Non-IP Encapsulation for MPLS-TP LSPs . . . . . . . . . . 15 5.4. Receiving an Echo Reply ...................................16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5.5. Non-IP Encapsulation for MPLS-TP LSPs .....................16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations ........................................16
6.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations ............................................17
6.2. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 16 7.1. TLVs ......................................................17
6.3. New Reply Mode . . . . . . . . . . . . . . . . . . . . . 16 7.2. New Target FEC Stack Sub-TLVs .............................17
6.4. Reply Path Return Code . . . . . . . . . . . . . . . . . 17 7.3. New Reply Mode ............................................17
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 7.4. Reply Path Return Code ....................................18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 8. Contributors ...................................................19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements ...............................................19
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 10. References ....................................................19
9.2. Informative References . . . . . . . . . . . . . . . . . 18 10.1. Normative References .....................................19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References ...................................20
1. Introduction 1. Introduction
This document defines extensions to the data-plane failure-detection This document defines extensions to the data-plane failure-detection
protocol for Multiprotocol Label Switching (MPLS) Label Switched protocol for Multiprotocol Label Switching (MPLS) Label Switched
Paths (LSPs) known as "LSP Ping" [RFC4379] that can be used to Paths (LSPs) known as "LSP ping" [RFC4379] that can be used to
specify the return paths for the echo reply message, increasing the specify the return paths for the echo reply message, increasing the
robustness of LSP Ping, reducing the opportunity for error, and robustness of LSP ping, reducing the opportunity for error, and
improving the reliability of the echo reply message. A new reply improving the reliability of the echo reply message. A new Reply
mode, which is referred to as "Reply via Specified Path", is added Mode, which is referred to as "Reply via Specified Path", is added
and a new Type-Length-Value (TLV), which is referred to as Reply Path and a new Type-Length-Value (TLV), which is referred to as "Reply
(RP) TLV, is defined in this memo. The procedures defined in this Path (RP) TLV", is defined in this memo. The procedures defined in
document currently only apply to "ping" mode. The "traceroute" mode this document currently only apply to "ping" mode. The "traceroute"
is out of scope for this document. mode is out of scope for this document.
In this document, the term bidirectional LSP includes the co-routed In this document, the term bidirectional LSP includes the co-routed
bidirectional LSP defined in [RFC3945] and the associated bidirectional LSP defined in [RFC3945] and the associated
bidirectional LSP that is constructed from a pair of unidirectional bidirectional LSP that is constructed from a pair of unidirectional
LSPs (one for each direction), and which are associated with one LSPs (one for each direction) that are associated with one another at
another at the LSP's ingress/egress points [RFC5654]. The mechanisms the LSP's ingress/egress points [RFC5654]. The mechanisms defined in
defined in this document can apply to both IP/MPLS and MPLS Transport this document can apply to both IP/MPLS and MPLS Transport Profile
Profile (MPLS-TP) scenarios. (MPLS-TP) scenarios.
2. Problem Statements and Solution Overview 2. Requirements Language
MPLS LSP Ping is defined in [RFC4379]. It can be used to detect data The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
path failures in all MPLS LSPs. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
LSP are increasingly being deployed to provide bidirectional 3. Problem Statements and Solution Overview
MPLS LSP ping is defined in [RFC4379]. It can be used to detect
data-path failures in all MPLS LSPs.
LSPs are increasingly being deployed to provide bidirectional
services. The co-routed bidirectional LSP is defined in [RFC3945], services. The co-routed bidirectional LSP is defined in [RFC3945],
and the associated bidirectional LSP is defined in [RFC5654]. With and the associated bidirectional LSP is defined in [RFC5654]. With
the deployment of such services, operators have a desire to test both the deployment of such services, operators have a desire to test both
directions of a bidirectional LSP in a single operation. directions of a bidirectional LSP in a single operation.
Additionally, when testing a single direction of an LSP (either a Additionally, when testing a single direction of an LSP (either a
unidirectional LSP, or a single direction of a bidirectional LSP) unidirectional LSP or a single direction of a bidirectional LSP)
using LSP Ping, the validity of the result may be affected by the using LSP ping, the validity of the result may be affected by the
success of delivering the echo reply message. Failure to exchange success of delivering the echo reply message. Failure to exchange
these messages between the egress Label Switching Router (LSR) and these messages between the egress Label Switching Router (LSR) and
the ingress LSR can lead to false negatives where the LSP under test the ingress LSR can lead to false negatives where the LSP under test
is reported as "down" even though it is functioning correctly. is reported as "down" even though it is functioning correctly.
2.1. Limitations of Existing Mechanisms for Bidirectional LSPs 3.1. Limitations of Existing Mechanisms for Bidirectional LSPs
With the existing LSP Ping mechanisms as defined in [RFC4379],
With the existing LSP ping mechanisms, as defined in [RFC4379],
operators have to enable LSP detection on each of the two ends of a operators have to enable LSP detection on each of the two ends of a
bidirectional LSP independently. This not only doubles the workload bidirectional LSP independently. This not only doubles the workload
for the operators, but may also bring additional difficulties when for the operators but may also bring additional difficulties when
checking the backward direction of the LSP under the following checking the backward direction of the LSP under the following
condition: condition:
The LSR that the operator logged on to perform the checking The LSR that the operator logged on to perform the checking
operations might not have out-of-band connectivity to the LSR at operations might not have out-of-band connectivity to the LSR at
the far end of the LSP. That can mean it is not possible to check the far end of the LSP. That can mean it is not possible to check
the return direction of a bidirectional LSP in a single operation the return direction of a bidirectional LSP in a single operation
- the operator must log on to the LSR at the other end of the LSP -- the operator must log on to the LSR at the other end of the LSP
to test the return direction. to test the return direction.
Associated bidirectional LSPs have the same issues as those listed Associated bidirectional LSPs have the same issues as those listed
for co-routed bidirectional LSPs. for co-routed bidirectional LSPs.
This document defines a mechanism to allow the operator to request This document defines a mechanism to allow the operator to request
that both directions of a bidirectional LSP be tested by a single LSP that both directions of a bidirectional LSP be tested by a single LSP
Ping message exchange. ping message exchange.
2.2. Limitations of Existing Mechanisms for Handling Unreliable Return 3.2. Limitations of Existing Mechanisms for Handling Unreliable Return
Paths Paths
[RFC4379] defines 4 reply modes: [RFC4379] defines four Reply Modes:
1. Do not reply 1. Do not reply
2. Reply via an IPv4/IPv6 UDP packet 2. Reply via an IPv4/IPv6 UDP packet
3. Reply via an IPv4/IPv6 UDP packet with Router Alert 3. Reply via an IPv4/IPv6 UDP packet with Router Alert
4. Reply via application level control channel. 4. Reply via application level control channel
Obviously, the issue of the reliability of the return path for an Obviously, the issue of the reliability of the return path for an
echo reply message does not apply in the first of these cases. echo reply message does not apply in the first of these cases.
[RFC4379] states that the third mode may be used when the IP return [RFC4379] states that the third mode may be used when the IP return
path is deemed unreliable. This mode of operation requires that all path is deemed unreliable. This mode of operation requires that all
intermediate nodes must support the Router Alert option and must intermediate nodes support the Router Alert option and understand how
understand and know how to forward MPLS echo replies. This is a to forward MPLS echo replies. This is a rigorous requirement in
rigorous requirement in deployed IP/MPLS networks especially since deployed IP/MPLS networks, especially since the return path may be
the return path may be through legacy IP-only routers. through legacy IP-only routers.
And in any case, the use modes 2 or 3 cannot guarantee the delivery In any case, the use of Reply Modes 2 or 3 cannot guarantee the
of echo responses through an IP network that is fundamentally delivery of echo responses through an IP network that is
unreliable. The failure to deliver echo response messages can lead fundamentally unreliable. The failure to deliver echo response
to false negatives making it appear that the LSP has failed. messages can lead to false negatives, making it appear that the LSP
has failed.
Allowing the ingress LSR to control the path used for echo reply Allowing the ingress LSR to control the path used for echo reply
messages enables an operator to apply an extra level of deterministic messages enables an operator to apply an extra level of deterministic
process to the LSP Ping test. For example, when testing an LSP, the process to the LSP ping test. For example, when testing an LSP,
Reply Mode 2 is used at the beginning but no echo reply received. Reply Mode 2 is used at the beginning but no echo reply is received.
When the return path is suspected with failure, the operator can When failure of the return path is suspected, the operator can
initiate another LSP Ping with the Reply Mode defined in this initiate another LSP ping with the Reply Mode defined in this
document and specify a different return path that is deemed workable document and specify a different return path that is deemed workable
to complete the test. to complete the test.
This document defines extensions to LSP Ping that can be used to This document defines extensions to LSP ping that can be used to
specify the return paths of the echo reply message in an echo request specify the return paths of the echo reply message in an echo request
message. message.
3. Extensions 4. Extensions
LSP Ping defined in [RFC4379] is carried out by sending an echo LSP ping, defined in [RFC4379], is carried out by sending an echo
request message. It carries the Forwarding Equivalence Class (FEC) request message. It carries the Forwarding Equivalence Class (FEC)
information of the LSP being tested which indicates which MPLS path information of the LSP being tested. The FEC information indicates
is being verified, along the same data path as other normal data which MPLS path is being verified along the same data path as other
packets belonging to the FEC. normal data packets belonging to the FEC.
LSP Ping [RFC4379] defines four reply modes that are used to direct LSP ping [RFC4379] defines four Reply Modes that are used to direct
the egress LSR in how to send back an echo reply. This document the egress LSR in how to send back an echo reply. This document
defines a new reply mode, the Reply via Specified Path mode. This defines a new Reply Mode, the "Reply via Specified Path" mode. This
new mode is used to direct the egress LSR of the tested LSP to send new mode is used to direct the egress LSR of the tested LSP to send
the echo reply message back along the path specified in the echo the echo reply message back along the path specified in the echo
request message. request message.
In addition, two new TLVs, the Reply Path TLV and Reply Traffic Class In addition, two new TLVs, the "Reply Path (RP) TLV" and "Reply
(TC) [RFC5462] TLV, are defined in this document. The Reply Path TLV Traffic Class (TC) TLV" [RFC5462], are defined in this document. The
contains one or more nested sub-TLVs that can be used to carry the Reply Path TLV contains one or more nested sub-TLVs that can be used
specified return path information to be used by the echo reply to carry the specified return path information to be used by the echo
message. reply message.
3.1. Reply Via Specified Path mode 4.1. Reply via Specified Path Mode
A new reply mode is defined to be carried in the Reply Mode field of A new Reply Mode is defined to be carried in the Reply Mode field of
the echo request message. the echo request message.
The value of the Reply via Specified Path mode is 5 (This has been The value of the Reply via Specified Path mode is 5 (This has been
allocated by IANA using early allocation and is to be confirmed by allocated by IANA using early allocation and is to be confirmed by
IANA). IANA).
Value Meaning Value Meaning
----- ------- ----- -------
5 Reply via Specified Path 5 Reply via Specified Path
The Reply via Specified Path mode is used to request that the remote The Reply via Specified Path mode is used to request that the remote
LSR receiving the echo request message sends back the echo reply LSR receiving the echo request message sends back the echo reply
message along the specified paths carried in the Reply Path TLV. message along the specified paths carried in the Reply Path TLV.
3.2. Reply Path (RP) TLV 4.2. Reply Path (RP) TLV
The Reply Path (RP) TLV is an optional TLV within the LSP Ping The Reply Path (RP) TLV is an optional TLV within the LSP ping
protocol. However, if the Reply via Specified Path mode requested as protocol. However, if the Reply via Specified Path mode requested,
described in Section 3.1, the Reply Path (RP) TLV MUST be included in as described in Section 4.1, the Reply Path (RP) TLV MUST be included
an echo request message and its absence is treated as a malformed in an echo request message, and its absence is treated as a malformed
echo request as described in [RFC4379]. Furthermore, if a Reply Path echo request, as described in [RFC4379]. Furthermore, if a Reply
(RP) TLV is included in an echo request message, a Reply Path (RP) Path (RP) TLV is included in an echo request message, a Reply Path
TLV MUST be included in the corresponding echo reply message sent by (RP) TLV MUST be included in the corresponding echo reply message
an implementation that is conformant to this specification. sent by an implementation that is conformant to this specification.
The Reply Path (RP) TLV carries the specified return path that the The Reply Path (RP) TLV carries the specified return path that the
echo reply message is required to follow. The format of Reply Path echo reply message is required to follow. The format of Reply Path
TLV is as follows: TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path TLV Type | Length | | Reply Path TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path return code | Flags | | Reply Path return code | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path | | Reply Path |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Reply Path TLV Figure 1: Reply Path TLV
Reply Path TLV Type: It is 2 octets in length, and the type value is Reply Path TLV Type: It is 2 octets in length, and the type value is
21. (This has been allocated by IANA using early allocation and 21.
is to be confirmed by IANA).
Length: It is 2 octets in length. It defines the length in octets Length: It is 2 octets in length. It defines the length in octets
of the Reply Path return code, Flags and Reply Path fields. of the Reply Path return code, Flags, and Reply Path fields.
Reply Path return code: The Reply Path return code field is 2 octets Reply Path return code: The Reply Path return code field is 2 octets
in length. It is defined for the egress LSR of the forward LSP to in length. It is defined for the egress LSR of the forward LSP to
report the results of Reply Path TLV processing and return path report the results of Reply Path TLV processing and return path
selection. This field MUST be set to zero in a Reply Path TLV selection. This field MUST be set to zero in a Reply Path TLV
carried on an echo request message and MUST be ignored on receipt. carried on an echo request message and MUST be ignored on receipt.
This document defines the following Reply Path return codes for This document defines the following Reply Path return codes for
inclusion in a Reply Path TLV carried on an echo reply: inclusion in a Reply Path TLV carried on an echo reply:
Value Meaning Value Meaning
------ ---------------------- ------ ----------------------
0x0000 Reserved, MUST NOT be used 0x0000 Reserved, MUST NOT be used
0x0001 Malformed Reply Path TLV was received 0x0001 Malformed Reply Path TLV was received
0x0002 One or more of the sub-TLVs in Reply Path TLV 0x0002 One or more of the sub-TLVs in the Reply Path TLV
were not understood were not understood
0x0003 The echo reply was sent successfully using the 0x0003 The echo reply was sent successfully using the
specified Reply Path specified Reply Path
0x0004 The specified Reply Path was not found, the echo 0x0004 The specified Reply Path was not found, the echo
reply was sent via other LSP reply was sent via another LSP
0x0005 The specified Reply Path was not found, the echo 0x0005 The specified Reply Path was not found, the echo
reply was sent via pure IP forwarding (non-MPLS) reply was sent via pure IP forwarding (non-MPLS)
path path
0x0006-0xfffb Not allocated, allocated via Standard Action 0x0006-0xfffb Unassigned
0xfffc-0xffff Experimental Use 0xfffc-0xffff Experimental Use
Flags: It is also 2 octets in length, it is used to notify the Flags: It is also 2 octets in length, it is used to notify the
egress how to process the Reply Paths field when performing return egress how to process the Reply Paths field when performing return
path selection. The Flags field is a bit vector and has following path selection. The Flags field is a bit vector and has following
format: format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero |A|B| | MUST be zero |A|B|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Flags Figure 2: Flags
A (Alternative path): the egress LSR MUST select a non-default A (Alternative path): the egress LSR MUST select a non-default
path as the return path. This is very useful when reverse path as the return path. This is very useful when reverse
default path problems are suspected which can be confirmed when default path problems are suspected that can be confirmed when
the echo reply is forced to follow a non-default return path. the echo reply is forced to follow a non-default return path.
Here, the default path refers to the path that the egress LSR Here, the default path refers to the path that the egress LSR
will use to send the echo reply when Reply Mode 2 or 3 is used. will use to send the echo reply when Reply Mode 2 or 3 is used.
If A bit is set, there is no need to carry any specific reply If A bit is set, there is no need to carry any specific reply
path sub-TLVs, and when received, the sub-TLVs SHOULD be path sub-TLVs, and when received, the sub-TLVs SHOULD be
ignored. ignored.
B (Bidirectional): the return path is required to follow the B (Bidirectional): the return path is required to follow the
reverse direction of the tested bidirectional LSP. If B bit is reverse direction of the tested bidirectional LSP. If B bit is
set, there is no need to carry any specific reply path sub- set, there is no need to carry any specific reply path sub-
TLVs, and when received, the sub-TLVs SHOULD be ignored. TLVs, and when received, the sub-TLVs SHOULD be ignored.
The A bit and B bit set MUST NOT both be set, otherwise, an The A flag and B flag MUST NOT both be set, otherwise, an echo
echo reply with the RP return code set to "Malformed RP TLV was reply with the RP return code set to "Malformed Reply Path TLV
received" MUST be returned. was received" MUST be returned.
Reply Path: It is used to describe the return path that an echo Reply Path: It is used to describe the return path that an echo
reply will be send along. It is variable in length and can reply will be send along. It is variable in length and can
contain zero, one or more Target FEC sub-TLVs [RFC4379] . In echo contain zero, one or more Target FEC sub-TLVs [RFC4379]. In an
request, it carries sub-TLVs that describe the specified path that echo request, it carries sub-TLVs that describe the specified path
the echo reply message is required to follow. In echo reply, the that the echo reply message is required to follow. In an echo
sub-TLVs describe the FEC Stack information of the return path reply, the sub-TLVs describe the FEC Stack information of the
(when the return path is an MPLS path) that the echo reply will be return path (when the return path is an MPLS path) that the echo
sent along. reply will be sent along.
3.3. Tunnel sub-TLVs 4.3. Tunnel Sub-TLVs
[RFC4379] has already defined several Target FEC sub-TLVs, the Target [RFC4379] has already defined several Target FEC sub-TLVs, the Target
FEC sub-TLVs provide a good way to identify a specific return path. FEC sub-TLVs provide a good way to identify a specific return path.
The Reply Path TLV can carry any (existing and future defined) sub- The Reply Path TLV can carry any (existing and future defined) sub-
TLV defined for use in the Target FEC Stack TLV to specify the return TLV defined for use in the Target FEC Stack TLV to specify the return
path. path.
This document defines three new Target FEC sub-TLVs: IPv4 RSVP Tunnel This document defines three new Target FEC sub-TLVs: IPv4 RSVP Tunnel
sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel sub-TLV. One sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel sub-TLV. One
usage of these generic RSVP Tunnel sub-TLVs is when LSP Ping is used usage of these generic RSVP Tunnel sub-TLVs is when LSP ping is used
to periodically verify the control plane against the data plane to periodically verify the control plane against the data plane
[RFC5884], using Tunnel other than particular LSP can avoid the [RFC5884], using a Tunnel other than a particular LSP can avoid the
impact of LSP identifier changing when Make-Before-Break (MBB) is impact of an LSP identifier changing when Make-Before-Break (MBB) is
deployed. These sub-TLVs also can be used in the Reply Path TLV to deployed. These sub-TLVs also can be used in the Reply Path TLV to
allow the operator to specify a more generic tunnel FEC other than a allow the operator to specify a more generic tunnel FEC other than a
particular LSP as the return path. particular LSP as the return path.
No assignments of sub-TLVs are made directly for TLV Type 21, the No assignments of sub-TLVs are made directly for TLV Type 21, the
sub-TLV space and assignments for this TLV Type 21 will be the same sub-TLV space and assignments for TLV Type 21 will be the same as
as that for TLV Type 1. Sub-types for TLV Type 1 and TLV Type 21 that for TLV Type 1. Sub-types for TLV Type 1 and TLV Type 21 MUST
MUST be kept the same. Any new sub-type added to TLV Type 1 MUST be kept the same. Any new sub-type added to TLV Type 1 MUST apply to
apply to the TLV Type 21 as well. the TLV Type 21 as well.
With the Return Path TLV flags and the sub-TLVs defined for the With the Return Path TLV flags and the sub-TLVs defined for the
Target FEC Stack TLV and in this document, it could provide following Target FEC Stack TLV and in this document, it could provide the
options for return paths specifying: following options for return paths specifying:
1. Specify a particular LSP as return path 1. a particular LSP as return path
- use those sub-TLVs defined for the Target FEC Stack TLV - use those sub-TLVs defined for the Target FEC Stack TLV
2. Specify a more generic tunnel FEC as return path 2. a more generic tunnel FEC as return path
- use the IPv4/IPv6 RSVP and Static Tunnel sub-TLVs defined in - use the IPv4/IPv6 RSVP and Static Tunnel sub-TLVs defined in
Section 3.3.1, Section 3.3.2 and Section 3.3.3 of this Sections Section 4.3.1, Section 4.3.2, and Section 4.3.3 of
document this document
3. Specify the reverse path of the bidirectional LSP as return path 3. the reverse path of the bidirectional LSP as return path
- use B bit defined in Section 3.2 of this document.
- use B bit defined in Section 4.2 of this document.
4. Force return path to non-default path 4. Force return path to non-default path
- use A bit defined in Section 3.2 of this document. - use A bit defined in Section 4.2 of this document.
3.3.1. IPv4 RSVP Tunnel sub-TLV 4.3.1. IPv4 RSVP Tunnel Sub-TLV
The format of IPv4 RSVP Tunnel sub-TLV is as follows: The format of the IPv4 RSVP Tunnel sub-TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 RSVP Tunnel sub-TLV Type | Length | | IPv4 RSVP Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address | | IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tunnel ID | | Flags | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address | | IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 IPv4 RSVP Tunnel sub-TLV
Figure 3: IPv4 RSVP Tunnel Sub-TLV
The IPv4 RSVP Tunnel sub-TLV is derived from the RSVP IPv4 FEC TLV The IPv4 RSVP Tunnel sub-TLV is derived from the RSVP IPv4 FEC TLV
that is defined in Section 3.2.3 [RFC4379]. All fields have the same that is defined in Section 3.2.3 of [RFC4379]. All fields have the
semantics as defined in [RFC4379] except that the LSP-ID field is same semantics as defined in [RFC4379] except that the LSP-ID field
omitted and a new Flags field is defined. is omitted and a new Flags field is defined.
The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
the recommended type value is TBD1. the recommended type value is 26.
The Flags field is 2 octets in length, it is used to notify the The Flags field is 2 octets in length, it is used to notify the
egress LSR how to choose the return path. The Flags field is a bit egress LSR how to choose the return path. The Flags field is a bit
vector and has following format: vector and has following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero |S|P| | MUST be zero |S|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Tunnel Flags
Figure 4: Tunnel Flags
P (Primary): the return path MUST be chosen from the LSPs that belong P (Primary): the return path MUST be chosen from the LSPs that belong
to the specified Tunnel and the LSP MUST be the primary LSP. to the specified Tunnel and the LSP MUST be the primary LSP.
S (Secondary): the return path MUST be chosen from the LSPs that S (Secondary): the return path MUST be chosen from the LSPs that
belong to the specified Tunnel and the LSP MUST be the secondary LSP. belong to the specified Tunnel and the LSP MUST be the secondary LSP.
Primary and secondary LSPs are defined in [RFC4872].
The terminologies and definitions of primary and secondary LSP are
defined [RFC4872].
P bit and S bit MUST NOT both be set, otherwise, an echo reply with P bit and S bit MUST NOT both be set, otherwise, an echo reply with
the RP return code set to "Malformed RP TLV was received" SHOULD be the RP return code set to "Malformed Reply Path TLV was received"
returned. If P bit and S bit are both not set, the return path could SHOULD be returned. If P bit and S bit are both not set, the return
be any one of the LSPs from the same Tunnel. path could be any one of the LSPs from the same Tunnel.
3.3.2. IPv6 RSVP Tunnel sub-TLV 4.3.2. IPv6 RSVP Tunnel Sub-TLV
The format of IPv6 RSVP Tunnel sub-TLV is as follows: The format of the IPv6 RSVP Tunnel sub-TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 RSVP Tunnel sub-TLV Type | Length | | IPv6 RSVP Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address | | IPv6 tunnel end point address |
| | | |
| | | |
| | | |
skipping to change at page 10, line 42 skipping to change at page 11, line 36
| Extended Tunnel ID | | Extended Tunnel ID |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address | | IPv6 tunnel sender address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 IPv6 RSVP Tunnel sub-TLV
The IPv6 RSVP Tunnel sub-TLV is derived from RSVP IPv6 FEC TLV that Figure 5: IPv6 RSVP Tunnel Sub-TLV
is defined in Section 3.2.4 of [RFC4379].All fields have the same
semantics as defined in [RFC4379] except that the LSP-ID field is The IPv6 RSVP Tunnel sub-TLV is derived from the RSVP IPv6 FEC TLV
omitted and a new Flags field is defined. that is defined in Section 3.2.4 of [RFC4379]. All fields have the
same semantics as defined in [RFC4379] except that the LSP-ID field
is omitted and a new Flags field is defined.
The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
the type value is TBD2. the type value is 27.
The Flags field is 2 octets in length and is identical to that The Flags field is 2 octets in length and is identical to that
described in Section 3.3.1. described in Section 4.3.1.
3.3.3. Static Tunnel sub-TLV 4.3.3. Static Tunnel Sub-TLV
The format of Static RSVP Tunnel sub-TLV is as follows. The value The format of the Static RSVP Tunnel sub-TLV is as follows. The
fields are taken from the definitions in [RFC6370]. value fields are taken from the definitions in [RFC6370].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static Tunnel sub-TLV Type | Length | | Static Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID | | Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID | | Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID | | Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID | | Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Num | Destination Tunnel Num | | Source Tunnel Num | Destination Tunnel Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Must Be Zero | | Flags | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Static Tunnel sub-TLV
Figure 6: Static Tunnel Sub-TLV
The Flags field is 2 octets in length and is identical to that The Flags field is 2 octets in length and is identical to that
described in Section 3.3.1. described in Section 4.3.1.
The sub-TLV type value is TBD3. The sub-TLV type value is 28.
3.4. Reply TC TLV 4.4. Reply TC TLV
Reply TOS Byte TLV [RFC4379] is used by the originator of the echo Reply TOS Byte TLV [RFC4379] is used by the originator of the echo
request to request that an echo reply be sent with the IP header TOS request to request that an echo reply be sent with the IP header TOS
byte set to the value specified in the TLV. Similarly, in this byte set to the value specified in the TLV. Similarly, in this
document, a new TLV: Reply TC TLV is defined and MAY be used by the document, a new TLV, Reply TC TLV, is defined and MAY be used by the
originator of the echo request to request that an echo reply be sent originator of the echo request to request that an echo reply be sent
with the TC bits of the return path LSP set to the value specified in with the TC bits of the return path LSP set to the value specified in
this TLV. The Reply TC TLV is not limited to the reply mode this TLV. The Reply TC TLV is not limited to the Reply Mode
specified in this document (Reply via Specified Path) but may be used specified in this document (Reply via Specified Path) but may be used
in all the other reply modes as well. The format of Reply TC TLV is in all the other Reply Modes as well. The format of Reply TC TLV is
as follows: as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply TC TLV type | Length | | Reply TC TLV type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TC | MUST be zero | | TC | MUST be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 Reply TC TLV
Figure 7: Reply TC TLV
The Reply TC TLV Type field is 2 octets in length, and the type value The Reply TC TLV Type field is 2 octets in length, and the type value
is TBD4. is 22.
The Length field is 2 octets in length, the value of length field is The Length field is 2 octets in length, the value of length field is
fixed 4 octets. fixed 4 octets.
4. Theory of Operation 5. Theory of Operation
The procedures defined in this document currently only apply to The procedures defined in this document currently only apply to
"ping" mode. The "traceroute" mode is out of scope for this "ping" mode. The "traceroute" mode is out of scope for this
document. document.
In [RFC4379], the echo reply is used to report the LSP checking In [RFC4379], the echo reply is used to report the LSP checking
result to the LSP Ping initiator. This document defines a new reply result to the LSP ping initiator. This document defines a new Reply
mode and a new TLV (Reply Path TLV) that enable the LSP ping Mode and a new TLV (Reply Path TLV) that enable the LSP ping
initiator to specify or constrain the return path of the echo reply. initiator to specify or constrain the return path of the echo reply.
Similarly the behavior of echo reply is extended to detect the Similarly, the behavior of echo reply is extended to detect the
requested return path by looking at a specified path FEC TLV. This requested return path by looking at a specified path FEC TLV. This
enables LSP Ping to detect failures in both directions of a path with enables LSP ping to detect failures in both directions of a path with
a single operation, this of course cuts in half the operational steps a single operation; of course, this cuts in half the operational
required to verify the end to end bidirectional connectivity and steps required to verify the end-to-end bidirectional connectivity
integrity of an LSP. and integrity of an LSP.
When the return path is an MPLS path, the echo reply MUST carry the When the return path is an MPLS path, the echo reply MUST carry the
FEC stack information in a Reply Path TLV to test the return MPLS LSP FEC Stack information in a Reply Path TLV to test the return MPLS LSP
path. The destination IP address of the echo reply message MUST path. The destination IP address of the echo reply message MUST
never be used in a forwarding decision. To avoid this possibility never be used in a forwarding decision. To avoid this possibility
the destination IP address of the echo reply message that is the destination IP address of the echo reply message that is
transmitted along the specified return path MUST be set to numbers transmitted along the specified return path MUST be set to numbers
from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127.0.0.0/104 for from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127.0.0.0/104 for
IPv6, and the IP TTL MUST be set 1, and the TTL in the outermost IPv6, and the IP Time to Live (TTL) MUST be set 1, and the TTL in the
label MUST be set to 255. outermost label MUST be set to 255.
When the return path is a pure IP forwarding path, the procedures When the return path is a pure IP forwarding path, the procedures
defined in [RFC4379] (the destination IP address is copied from the defined in [RFC4379] (the destination IP address is copied from the
source IP address) apply unchanged. source IP address) apply unchanged.
4.1. Sending an Echo Request 5.1. Sending an Echo Request
When sending an echo request, in addition to the rules and procedures When sending an echo request, in addition to the rules and procedures
defined in Section 4.3 of [RFC4379], the reply mode of the echo defined in Section 4.3 of [RFC4379], the Reply Mode of the echo
request MUST be set to "Reply via Specified Path", and a Reply Path request MUST be set to "Reply via Specified Path", and a Reply Path
TLV MUST be carried in the echo request message correspondingly. The TLV MUST be carried in the echo request message correspondingly. The
Reply Path TLV includes one or several reply path sub-TLV(s) to Reply Path TLV includes one or several reply path sub-TLV(s) to
identify the return path(s) the egress LSR should use for its reply. identify the return path(s) the egress LSR should use for its reply.
For a bidirectional LSP, since the ingress LSR and egress LSR of a For a bidirectional LSP, since the ingress LSR and egress LSR of a
bidirectional LSP are aware of the relationship between the forward bidirectional LSP are aware of the relationship between the forward
and backward direction LSPs, only the B bit SHOULD be set in the and backward direction LSPs, only the B bit SHOULD be set in the
Reply Path TLV. If the operator wants the echo reply to be sent Reply Path TLV. If the operator wants the echo reply to be sent
along a different path other than the reverse direction of the along a path other than the reverse direction of the bidirectional
bidirectional LSP, the "A" bit SHOULD be set or another FEC sub-TLV LSP, the A bit SHOULD be set or another FEC sub-TLV SHOULD be carried
SHOULD be carried in the Reply Path TLV instead, and the B bit MUST in the Reply Path TLV instead, and the B bit MUST be clear.
be clear.
In some cases, operators may want to treat two unidirectional LSPs In some cases, operators may want to treat two unidirectional LSPs
(one for each direction) as a pair. There may not be any binding (one for each direction) as a pair. There may not be any binding
relationship between the two LSPs. Using the mechanism defined in relationship between the two LSPs. Using the mechanism defined in
this document, operators can run LSP Ping one time from one end to this document, operators can run LSP ping one time from one end to
complete the failure detection on both unidirectional LSPs. To complete the failure detection on both unidirectional LSPs. To
accomplish this, the echo request message MUST carry (in the Reply accomplish this, the echo request message MUST carry (in the Reply
Path TLV) a FEC sub-TLV that belongs to the backward LSP. Path TLV) a FEC sub-TLV that belongs to the backward LSP.
4.2. Receiving an Echo Request 5.2. Receiving an Echo Request
"Ping" mode processing as defined in Section 4.4 of [RFC4379] applies "Ping" mode processing, as defined in Section 4.4 of [RFC4379],
in this document. In addition, when an echo request is received, if applies in this document. In addition, when an echo request is
the egress LSR does not know the reply mode defined in this document, received, if the egress LSR does not know the Reply Mode defined in
an echo reply with the return code set to "Malformed echo request" this document, an echo reply with the return code set to "Malformed
and the Subcode set to zero will be send back to the ingress LSR echo request received" and the Subcode set to zero will be send back
according to the rules of [RFC4379]. If the egress LSR knows the to the ingress LSR according to the rules of [RFC4379]. If the
reply mode, according to the Reply Path TLV, it SHOULD find and egress LSR knows the Reply Mode, according to the Reply Path TLV, it
select the desired return path. If there is a matched path, an echo SHOULD find and select the desired return path. If there is a
reply with Reply Path TLV that identify the return path SHOULD be matched path, an echo reply with a Reply Path TLV that identifies the
sent back to the ingress LSR, the Reply Path return code SHOULD be return path SHOULD be sent back to the ingress LSR, the Reply Path
set to "The echo reply was sent successfully using the specified return code SHOULD be set to "The echo reply was sent successfully
return path". If there is no such path, an echo reply with Reply using the specified Reply Path". If there is no such path, an echo
Path TLV SHOULD be sent back to the ingress LSR, the Reply Path reply with the Reply Path TLV SHOULD be sent back to the ingress LSR,
return code SHOULD be set to relevant code (defined Section 3.2) for the Reply Path return code SHOULD be set to the relevant code
the real situation to reflect the result of Reply Path TLV processing (defined in Section 4.2) for the real situation to reflect the result
and return path selection. For example, if the specified LSP is not of Reply Path TLV processing and return path selection. For example,
found, the egress then chooses another LSP as the return path to send if the specified LSP is not found, the egress then chooses another
the echo reply, the Reply Path return code SHOULD be set to "The LSP as the return path to send the echo reply, the Reply Path return
specified reply path was not found, the echo reply was sent via other code SHOULD be set to "The specified reply path was not found, the
LSP", and if the egress chooses an IP path to send the echo reply, echo reply was sent via another LSP", and if the egress chooses an IP
the Reply Path return code SHOULD be set to "The specified reply path path to send the echo reply, the Reply Path return code SHOULD be set
was not found, the echo reply was sent via IP path". If there is to "The specified Reply Path was not found, the echo reply was sent
unknown sub-TLV in the received Reply Path TLV, the Reply Path return via pure IP forwarding (non-MPLS) path". If there is an unknown sub-
code SHOULD be set to "One or more of the sub-TLVs in Reply Path TLV TLV in the received Reply Path TLV, the Reply Path return code SHOULD
was not understood". be set to "One or more of the sub-TLVs in the Reply Path TLV were not
understood".
If the A bit of the Reply Path TLV in a received echo request message If the A bit of the Reply Path TLV in a received echo request message
is set, the egress LSR SHOULD send the echo reply along an non- is set, the egress LSR SHOULD send the echo reply along a non-default
default return path. return path.
IF the B bit of the Reply Path TLV in a received echo request message If the B bit of the Reply Path TLV in a received echo request message
is set, the egress LSR SHOULD send the echo reply along the reverse is set, the egress LSR SHOULD send the echo reply along the reverse
direction of the bidirectional LSP. direction of the bidirectional LSP.
In addition, the FEC validate results of the forward path LSP SHOULD In addition, the FEC validate results of the forward path LSP SHOULD
NOT affect the egress LSR continue to test return path LSP. NOT affect the egress LSR continue to test return path LSP.
4.3. Sending an Echo Reply 5.3. Sending an Echo Reply
As described in [RFC4379], the echo reply message is a UDP packet, As described in [RFC4379], the echo reply message is a UDP packet,
and it MUST be sent only in response to an MPLS echo request. The and it MUST be sent only in response to an MPLS echo request. The
source IP address is a valid IP address of the replier, the source source IP address is a valid IP address of the replier, the source
UDP port is the well-know UDP port for LSP ping. UDP port is the well-know UDP port for LSP ping.
When the return path is an MPLS LSP path, the destination IP address When the return path is an MPLS LSP, the destination IP address of
of the echo reply message is copied from the destination IP address the echo reply message is copied from the destination IP address of
of echo request, the destination UDP port is copied from the source the echo request, and the destination UDP port is copied from the
UDP port of the echo request. The IP TTL MUST be set to 1, the TTL source UDP port of the echo request. The IP TTL MUST be set to 1,
in the outermost label MUST be set to 255. the TTL in the outermost label MUST be set to 255.
When the return path is a pure IP forwarding path, the same as When the return path is a pure IP forwarding path, the same as
defined in [RFC4379], the destination IP address and UDP port are defined in [RFC4379], the destination IP address and UDP port are
copied from the source IP address and source UDP port of the echo copied from the source IP address and source UDP port of the echo
request. request.
When sending the echo reply, a Reply Path TLV that identifies the When sending the echo reply, a Reply Path TLV that identifies the
return path MUST be carried, the Reply Path return code SHOULD be set return path MUST be carried, the Reply Path return code SHOULD be set
to relevant code that reflects results about how the egress processes to relevant code that reflects results about how the egress processes
the Reply Path TLV in a previous received echo request message and the Reply Path TLV in a previous received echo request message and
return path selection. By carrying the Reply Path TLV in an echo return path selection. By carrying the Reply Path TLV in an echo
reply, it gives the Ingress LSR enough information about the reverse reply, it gives the ingress LSR enough information about the reverse
direction of the tested path to verify the consistency of the data direction of the tested path to verify the consistency of the data
plane against control plane. Thus a single LSP Ping could achieve plane against control plane. Thus, a single LSP ping could achieve
both directions of a path test. If the return path is pure IP path, both directions of a path test. If the return path is pure IP path,
no sub-TLVs are carried in the Reply Path TLV. no sub-TLVs are carried in the Reply Path TLV.
4.4. Receiving an Echo Reply 5.4. Receiving an Echo Reply
The rules and process defined in Section 4.6 of [RFC4379] apply here. The rules and process defined in Section 4.6 of [RFC4379] apply here.
When an echo reply is received, if the reply mode is "Reply via When an echo reply is received, if the Reply Mode is "Reply via
Specified Path" and the Reply Path return code is "The echo reply was Specified Path" and the Reply Path return code is "The echo reply was
sent successfully using the specified return path", and if the return sent successfully using the specified Reply Path", and if the return
path is an MPLS LSP. The ingress LSR MUST perform FEC validation path is an MPLS LSP. The ingress LSR MUST perform FEC validation
(based on the FEC stack information of the return path carried in the (based on the FEC Stack information of the return path carried in the
Reply Path TLV) as an egress LSR does when receiving an echo request, Reply Path TLV) as an egress LSR does when receiving an echo request,
the FEC validation process (relevant to "ping" mode) defined in the FEC validation process (relevant to "ping" mode) defined in
Section 4.4.1 of [RFC4379] applies here. Section 4.4.1 of [RFC4379] applies here.
When an echo reply is received with return code set to "Malformed When an echo reply is received with return code set to "Malformed
echo request received" and the Subcode set to zero. It is possible echo request received" and the Subcode set to zero. It is possible
that the egress LSR may not know the "Reply via Specified Path" reply that the egress LSR may not know the "Reply via Specified Path" Reply
mode, the operator may choose to re-perform another LSP Ping by using Mode, the operator may choose to re-perform another LSP ping by using
one of the four reply modes defined [RFC4379]. one of the four Reply Modes defined [RFC4379].
On receipt of an echo reply with Reply Path return code in the Reply On receipt of an echo reply with Reply Path return code in the Reply
Path TLV set to "The specified reply path was not found, ...", it Path TLV set to "The specified reply path was not found, ...", it
means that the egress LSR could not find a matched return path as means that the egress LSR could not find a matched return path as
specified. Operators may choose to specify another LSP as the return specified. Operators may choose to specify another LSP as the return
path or use other methods to detect the path further. path or use other methods to detect the path further.
4.5. Non-IP Encapsulation for MPLS-TP LSPs 5.5. Non-IP Encapsulation for MPLS-TP LSPs
In some MPLS-TP deployment scenarios, IP addressing might not be In some MPLS-TP deployment scenarios, IP addressing might not be
available or use some form of non-IP encapsulation might be available or the use of some form of non-IP encapsulation might be
preferred. In such scenarios, the Non-IP encapsulation defined in preferred. In such scenarios, the Non-IP encapsulation defined in
[RFC6426] applies here. The LSP Ping Reply Mode in echo request and [RFC6426] applies here. The LSP Ping Reply Mode in the echo request
echo reply is set to 5. The return path of the echo reply is as and echo reply is set to 5. The return path of the echo reply is as
specified in the Reply Path TLV. specified in the Reply Path TLV.
5. Security Considerations 6. Security Considerations
Security considerations discussed in [RFC4379] apply to this Security considerations discussed in [RFC4379] apply to this
document. document.
In addition, the extensions defined in this document may be used for In addition, the extensions defined in this document may be used for
potential "proxying" attacks. For example, an echo request initiator potential "proxying" attacks. For example, an echo request initiator
may specify a return path that has the destination different from the may specify a return path that has a destination different from that
initiator. But normally, such attacks will not happen in an MPLS of the initiator. But normally, such attacks will not happen in an
domain where the initiators and receivers belong to the same domain. MPLS domain where the initiators and receivers belong to the same
Even this, in order to prevent using the extension defined in this domain. Even this, in order to prevent using the extension defined
document for "proxying" any possible attacks, the return path LSP in this document for proxying any possible attacks, the return path
should have destination to the same node where the forward path is LSP should have destination to the same node where the forward path
from. The receiver may drop the echo request when it cannot is from. The receiver may drop the echo request when it cannot
determine whether the return path LSP has the destination to the determine whether the return path LSP has the destination to the
initiator. That means, when sending echo request, the initiator initiator. That means, when sending echo request, the initiator
should choose a proper source address according the specified return should choose a proper source address according the specified return
path LSP to help the receiver to make the decision. path LSP to help the receiver to make the decision.
6. IANA Considerations 7. IANA Considerations
6.1. TLVs
The IANA is requested to assign the temporary assigned value (21) for 7.1. TLVs
the Reply Path TLV and assign one new value (TBD4) for Reply TC TLV
from the "Multiprotocol Label Switching Architecture (MPLS) Label
Switched Paths (LSPs) Ping Parameters - TLVs" registry, "TLVs and
sub-TLVs" sub-registry.
Note: IANA have made an early allocation of the value 21 for Reply IANA has assigned the value 21 for the Reply Path TLV and assigned
Path TLV. the value 22 for Reply TC TLV from the "Multiprotocol Label Switching
Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters"
registry, "TLVs" subregistry.
Value Meaning Reference Value Meaning Reference
----- ------- --------- ----- ------- ---------
21 Reply Path TLV this document (sect 3.2) 21 Reply Path TLV this document (Section 4.2)
TBD4 Reply TC TLV this document (sect 3.4) 22 Reply TC TLV this document (Section 4.4)
The sub-TLV space and assignments for the Reply Path TLV will be the The sub-TLV space and assignments for the Reply Path TLV will be the
same as that for the Target FEC Stack TLV. Sub-types for the Target same as that for the Target FEC Stack TLV. Sub-types for the Target
FEC Stack TLV and the Reply Path TLV MUST be kept the same. Any new FEC Stack TLV and the Reply Path TLV MUST be kept the same. Any new
sub-type added to the Target FEC Stack TLV MUST apply to the Reply sub-type added to the Target FEC Stack TLV MUST apply to the Reply
Path TLV as well. Path TLV as well.
6.2. New Target FEC Stack Sub-TLVs 7.2. New Target FEC Stack Sub-TLVs
IANA is also requested to assign three new sub-TLV types from IANA has assigned three new sub-TLV types from the "Multiprotocol
"Multiprotocol Label Switching Architecture (MPLS) Label Switched Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping
Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV Type Parameters - TLVs" registry, "Sub-TLVs for TLV Types 1, 16, and 21"
1" sub-registry. subregistry.
Sub-type Value Field Reference Sub-Type Sub-TLV Name Reference
------- ----------- --------- ------- ----------- ---------
TBD1 IPv4 RSVP Tunnel this document (sect 3.3.1) 26 IPv4 RSVP Tunnel this document (Section 4.3.1)
TBD2 IPv6 RSVP Tunnel this document (sect 3.3.2) 27 IPv6 RSVP Tunnel this document (Section 4.3.2)
TBD3 Static Tunnel this document (sect 3.3.3) 28 Static Tunnel this document (Section 4.3.3)
6.3. New Reply Mode 7.3. New Reply Mode
IANA has made an early allocation (5 - Reply via specified path) from IANA has allocated (5 - Reply via Specified Path) from the "Multi-
the "Multi-Protocol Label Switching (MPLS) Label Switched Paths Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
(LSPs) Ping Parameters" registry, the "Reply Mode" sub-registry. Parameters" registry, the "Reply Modes" subregistry.
IANA is requested to make this allocation permanent.
Value Meaning Reference Value Meaning Reference
----- ------- ---------- ----- ------- ----------
5 Reply via Specified Path this document (sect 3.1) 5 Reply via Specified Path this document (Section 4.1)
6.4. Reply Path Return Code 7.4. Reply Path Return Code
IANA is requested to create a new registry (as part of mpls-lsp-ping- IANA has created a new subregistry for the "Multi-Protocol Label
parameters ) for Reply Path return code. Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" for
Reply Path return codes.
This document (Section 3.2) defines the following return codes: This document (Section 4.2) defines the following return codes:
Value Meaning Value Meaning
------ ---------------------- ------ ----------------------
0x0000 No return code 0x0000 No return code
0x0001 Malformed Reply Path TLV was received 0x0001 Malformed Reply Path TLV was received
0x0002 One or more of the sub-TLVs in Reply Path TLV 0x0002 One or more of the sub-TLVs in the Reply Path TLV
were not understood were not understood
0x0003 The echo reply was sent successfully using the 0x0003 The echo reply was sent successfully using the
specified Reply Path specified Reply Path
0x0004 The specified Reply Path was not found, the echo 0x0004 The specified Reply Path was not found, the echo
reply was sent via other LSP reply was sent via another LSP
0x0005 The specified Reply Path was not found, the echo 0x0005 The specified Reply Path was not found, the echo
reply was sent via pure IP forwarding (non-MPLS) reply was sent via pure IP forwarding (non-MPLS)
path path
0x0006-0xfffb Not allocated, allocated via Standard Action 0x0006-0xfffb Unassigned
0xfffc-0xffff Experimental Use 0xfffc-0xffff Reserved for Experimental Use
The range of 0x0006-0xfffb is not allocated and reserved for future The range of 0x0006-0xfffb is not allocated and reserved for future
extensions and is allocated via Standard Action, the range of 0xfffc- extensions and is allocated via Standard Action; the range of 0xfffc-
0xffff is for Experimental Use. 0xffff is for Experimental Use.
7. Contributors 8. Contributors
The following individuals also contributed to this document: The following individuals also contributed to this document:
Ehud Doron Ehud Doron
Orckit-Corrigent Orckit-Corrigent
EMail: ehudd@orckit.com EMail: ehudd@orckit.com
Ronen Solomon Ronen Solomon
Orckit-Corrigent Orckit-Corrigent
EMail: RonenS@orckit.com EMail: RonenS@orckit.com
Ville Hallivuori Ville Hallivuori
Tellabs Tellabs
Sinimaentie 6 C Sinimaentie 6 C
FI-02630 Espoo, Finland FI-02630 Espoo, Finland
EMail: ville.hallivuori@tellabs.com EMail: ville.hallivuori@tellabs.com
Xinchun Guo Xinchun Guo
EMail: guoxinchun@huawei.com EMail: guoxinchun@huawei.com
8. Acknowledgements 9. Acknowledgements
The authors would like to thank Adrian Farrel, Peter Ashwood-Smith, The authors would like to thank Adrian Farrel, Peter Ashwood-Smith,
Sriganesh Kini, Gregory Mirsky, Eric Gray, Loa Andersson, Carlos Sriganesh Kini, Gregory Mirsky, Eric Gray, Loa Andersson, Carlos
Pignataro and Tom Petch for their review, suggestion and comments to Pignataro, and Tom Petch for their reviews, suggestions, and
this document. comments.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
9.2. Informative References 10.2. Informative References
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi- Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872, May Protocol Label Switching (GMPLS) Recovery", RFC 4872, May
2007. 2007.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
skipping to change at page 19, line 21 skipping to change at page 21, line 13
RFC 6426, November 2011. RFC 6426, November 2011.
Authors' Addresses Authors' Addresses
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
Beijing 100095 Beijing 100095
China China
Email: mach.chen@huawei.com EMail: mach.chen@huawei.com
Wei Cao Wei Cao
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
Beijing 100095 Beijing 100095
China China
Email: wayne.caowei@huawei.com EMail: wayne.caowei@huawei.com
So Ning So Ning
Tata Communications Tata Communications
Email: ning.so@tatacommunications.com EMail: ning.so@tatacommunications.com
Frederic Jounay Frederic Jounay
Orange CH Orange CH
4 rue caudray 1020 Renens 4 rue caudray 1020 Renens
Switzerland Switzerland
Email: frederic.jounay@orange.ch EMail: frederic.jounay@orange.ch
Simon Delord Simon Delord
Alcatel-Lucent
Building 3, 388 Ningqiao Road, Jinqiao, Pudong
Shanghai 201206
China
Email: simon.delord@alcatel-lucent.com EMail: Simon.delord@team.telstra.com
 End of changes. 140 change blocks. 
335 lines changed or deleted 326 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/