draft-ietf-mpls-return-path-specified-lsp-ping-03.txt   draft-ietf-mpls-return-path-specified-lsp-ping-04.txt 
Network working group M. Chen(Ed.) Network Working Group M. Chen
Internet Draft Huawei Technologies Co.,Ltd Internet-Draft W. Cao
Category: Standards Track N. So(Ed.) Intended status: Standards Track Huawei Technologies Co., Ltd
Verizon Expires: May 3, 2012 S. Ning
Expires: January 11, 2012 July 11, 2011 Verizon Inc.
F. Jounay
France Telecom
S. Delord
Alcatel-Lucent
October 31, 2011
Return Path Specified LSP Ping Return Path Specified LSP Ping
draft-ietf-mpls-return-path-specified-lsp-ping-04.txt
draft-ietf-mpls-return-path-specified-lsp-ping-03.txt
Abstract Abstract
This document defines extensions to the failure-detection protocol This document defines extensions to the failure-detection protocol
for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
known as "LSP Ping" that allow selection of the LSP to use for the known as "LSP Ping" that allow selection of the LSP to use for the
echo reply return path. Enforcing a specific return path can be used echo reply return path. Enforcing a specific return path can be used
to verify bidirectional connectivity and also increase LSP ping to verify bidirectional connectivity and also increase LSP ping
robustness. It may also be used by Bidirectional Forwarding Detection robustness. It may also be used by Bidirectional Forwarding
(BFD) for MPLS bootstrap signaling thereby making BFD for MPLS more Detection (BFD) for MPLS bootstrap signaling thereby making BFD for
robust. MPLS more robust.
Status of This Memo Requirements Language
This Internet-Draft is submitted to IETF in full conformance with the 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
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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on May 3, 2012.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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.
Conventions used in this document
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].
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statements and Solution Overview ..................... 3 2. Problem Statements and Solution Overview . . . . . . . . . . . 3
2.1. Limitations of Existing Mechanisms for Bidirectional LSPs 4 2.1. Limitations of Existing Mechanisms for Bidirectional
2.2. Limitations of Existing Mechanisms for Handling Unreliable LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Return Paths ................................................. 4 2.2. Limitations of Existing Mechanisms for Handling
3. Extensions ................................................... 5 Unreliable Return Paths . . . . . . . . . . . . . . . . . 4
3.1. Reply Via Specified Path mode ........................... 6 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Reply Path (RP) TLV ..................................... 6 3.1. Reply Via Specified Path mode . . . . . . . . . . . . . . 5
3.3. RP TLV sub-TLVs.......................................... 9 3.2. Reply Path (RP) TLV . . . . . . . . . . . . . . . . . . . 6
3.3.1. IPv4 RSVP Tunnel sub-TLV .......................... 10 3.3. RP TLV sub-TLVs . . . . . . . . . . . . . . . . . . . . . 8
3.3.2. IPv6 RSVP Tunnel sub-TLV .......................... 11 3.3.1. IPv4 RSVP Tunnel sub-TLV . . . . . . . . . . . . . . . 8
3.3.3. RP TC sub-TLV ..................................... 12 3.3.2. IPv6 RSVP Tunnel sub-TLV . . . . . . . . . . . . . . . 9
4. Theory of Operation ......................................... 13 3.3.3. RP TC sub-TLV . . . . . . . . . . . . . . . . . . . . 10
4.1. Sending an Echo Request ................................ 14 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 11
4.2. Receiving an Echo Request .............................. 14 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 12
4.3. Sending an Echo Reply .................................. 15 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 12
4.4. Receiving an Echo Reply ................................ 16 4.3. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 13
5. Security Considerations ..................................... 17 4.4. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 14
6. IANA Considerations ......................................... 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. New TLV ................................................ 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.2. Sub-TLVs ............................................... 17 6.1. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.1. Sub-TLVs from RFC3479 ............................. 17 6.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.2. New Sub-TLVs ...................................... 18 6.2.1. New Sub-TLVs . . . . . . . . . . . . . . . . . . . . . 15
6.2.3. New Reply Mode .................................... 18 6.2.2. New Reply Mode . . . . . . . . . . . . . . . . . . . . 15
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Contributors ................................................ 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments ............................................. 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. References .................................................. 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References ................................... 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References ................................. 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses ............................................. 21
1. Introduction 1. Introduction
This document defines extensions to the failure-detection protocol This document defines extensions to the failure-detection protocol
for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
known as "LSP Ping" [RFC4379] that can be used to specify the return known as "LSP Ping" [RFC4379] that can be used to specify the return
paths for the echo reply message, increasing the robustness of LSP paths for the echo reply message, increasing the robustness of LSP
Ping, reducing the opportunity for error, and improving the Ping, reducing the opportunity for error, and improving the
reliability of the echo reply message. A new reply mode, which is reliability of the echo reply message. A new reply mode, which is
referred to as "Reply via specified path", is added and a new Type- referred to as "Reply via specified path", is added and a new Type-
Length-Value (TLV), which is referred to as Reply Path (RP) TLV, is Length-Value (TLV), which is referred to as Reply Path (RP) TLV, is
defined in this memo. defined in this memo.
With the extensions described in this document, a bidirectional LSP With the extensions described in this document, a bidirectional LSP
and a pair of unidirectional LSPs (one for each direction) could both and a pair of unidirectional LSPs (one for each direction) could both
be tested with a single operational action, hence providing better be tested with a single operational action, hence providing better
control plane scalability. The defined extensions can also be control plane scalability. The defined extensions can also be
utilized for creating a single Bidirectional Forwarding Detection utilized for creating a single Bidirectional Forwarding Detection
(BFD) [BFD], [BFD-MPLS] session for a bidirectional LSP or for a pair (BFD)[RFC5880], [RFC5884]session for a bidirectional LSP or for a
of unidirectional LSPs (one for each direction). pair of unidirectional LSPs (one for each direction).
In this document, term bidirectional LSP includes the co-routed In this document, 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), and which are associated with one
another at the LSP's ingress/egress points [RFC5654]. another at the LSP's ingress/egress points [RFC5654].
2. Problem Statements and Solution Overview 2. Problem Statements and Solution Overview
MPLS LSP Ping is defined in [RFC4379]. It can be used to detect data MPLS LSP Ping is defined in [RFC4379]. It can be used to detect data
path failures in all MPLS LSPs, and was originally designed for path failures in all MPLS LSPs, and was originally designed for
unidirectional LSPs. unidirectional LSPs.
LSP are increasingly being deployed to provide bidirectional LSP are increasingly being deployed to provide bidirectional
services. The co-routed bidirectional LSP is defined in [RFC3471] and services. The co-routed bidirectional LSP is defined in [RFC3471]
[RFC3473], and the associated bidirectional LSP is defined in and [RFC3473], and the associated bidirectional LSP is defined in
[RFC5654]. With the deployment of such services, operators have a [RFC5654]. With the deployment of such services, operators have a
desire to test both directions of a bidirectional LSP in a single desire to test both directions of a bidirectional LSP in a single
operation. 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 2.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
conditions: conditions:
1. The LSR that the operator logged on to perform the checking 1. 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
the return direction of a bidirectional LSP in a single operation - check the return direction of a bidirectional LSP in a single
the operator must log on to the LSR at the other end of the LSP to operation - the operator must log on to the LSR at the other end
test the return direction. of the LSP to test the return direction.
2. The LSP being tested might be an inter-domain/inter-AS LSP where 2. The LSP being tested might be an inter-domain/inter-AS LSP where
the operator of one domain/AS may have no right to log on to the the operator of one domain/AS may have no right to log on to the
LSR at the other end of the LSP since this LSR resides in another LSR at the other end of the LSP since this LSR resides in another
domain/AS. That can make it completely impossible for the operator domain/AS. That can make it completely impossible for the
to check the return direction of a bidirectional LSP. operator to check the return direction of a bidirectional LSP.
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 2.2. Limitations of Existing Mechanisms for Handling Unreliable Return
Paths Paths
[RFC4379] defines 4 reply modes: [RFC4379] defines 4 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 must support the Router Alert option and must
understand and know how to forward MPLS echo replies. understand and know how to forward MPLS echo replies.
This is a rigorous requirement in deployed IP/MPLS networks This is a rigorous requirement in deployed IP/MPLS networks
especially since the return path may be through legacy IP-only especially since the return path may be through legacy IP-only
routers. Furthermore, for inter-domain LSPs, the use of the Router routers. Furthermore, for inter-domain LSPs, the use of the Router
Alert option may encounter significant issues at domain boundaries Alert option may encounter significant issues at domain boundaries
where the option is usually stripped from all packets. Thus, the use where the option is usually stripped from all packets. Thus, the use
of this mode may itself introduce issues that lead to the echo reply of this mode may itself introduce issues that lead to the echo reply
messages not being delivered. messages not being delivered.
And in any case, the use modes 2 or 3 cannot guarantee the delivery And in any case, the use modes 2 or 3 cannot guarantee the delivery
of echo responses through an IP network that is fundamentally of echo responses through an IP network that is fundamentally
unreliable. The failure to deliver echo response messages can lead to unreliable. The failure to deliver echo response messages can lead
false negatives making it appear that the LSP has failed. 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, and in particular forcing those messages to use an LSP messages, and in particular forcing those messages to use an LSP
rather than being sent through the IP network, enables an operator to rather than being sent through the IP network, enables an operator to
apply an extra level of deterministic process to the LSP Ping test. apply an extra level of deterministic process to the LSP Ping 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 LSP echo specify the return paths of the echo reply message in an LSP echo
request message. request message.
3. Extensions 3. 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 tested LSP which indicates which MPLS path is information of the tested LSP which indicates which MPLS path is
being verified, along the same data path as other normal data packets being verified, along the same data path as other normal data packets
belonging to the FEC. 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
defines a new reply mode, the Reply Via Specified Path mode. This new the egress LSR in how to send back an echo reply. This document
mode is used to direct the egress LSR of the tested LSP to send the defines a new reply mode, the Reply Via Specified Path mode. This
echo reply message back along the path specified in the echo request new mode is used to direct the egress LSR of the tested LSP to send
message. the echo reply message back along the path specified in the echo
request message.
In addition, a new TLV, the Reply Path (RP) TLV, is defined in this In addition, a new TLV, the Reply Path (RP) TLV, is defined in this
document. The RP TLV consists of one or more sub-TLVs that can be document. The RP TLV consists of one or more sub-TLVs that can be
used to carry the specified return path information to be used by the used to carry the specified return path information to be used by the
echo reply message. echo reply message.
3.1. Reply Via Specified Path mode 3.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 LSP Ping echo request message. the LSP Ping echo request message.
The recommended value of the Reply Via Specified Path mode is 5 (This The recommended value of the Reply Via Specified Path mode is 5 (This
is to be confirmed by the IANA). is to be confirmed by the IANA).
Value Meaning Value Meaning
----- ------- ----- -------
5 Reply via specified path 5 Reply via specified path
The Reply Via Specified Path mode is used to notify the remote LSR The Reply Via Specified Path mode is used to notify the remote LSR
receiving the LSP Ping echo request message to send back the echo receiving the LSP Ping echo request message to send back the echo
reply message along the specified paths carried in the Reply Path reply message along the specified paths carried in the Reply Path
TLV. TLV.
3.2. Reply Path (RP) TLV 3.2. Reply Path (RP) TLV
The Reply Path (RP) TLV is optionally included in an echo request The Reply Path (RP) TLV is optionally included in an echo request
message. It carries the specified return paths that the echo reply message. It carries the specified return paths that the echo reply
message is required to follow. The format of RP TLV is as follows: message is required to follow. The format of RP TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP (reply path) TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP return code | Flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Paths |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 Figure3 IPv6 PSN Tunnel sub-TLV format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP (reply path) TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP return code | Flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Paths |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RP TLV Type field is 2 octets in length, and the type value is TBD by RP TLV Type field is 2 octets in length, and the type value is TBD by
IANA. IANA.
The Length field is 2 octets in length. It defines the length in The Length field is 2 octets in length. It defines the length in
octets of the RP return code, Flag and Reply Paths fields. octets of the RP return code, Flag and Reply Paths fields.
RP return code is 2 octets in length. It is defined for the egress RP return code is 2 octets in length. It is defined for the egress
LSR of the forward LSP to report the results of RP TLV processing and LSR of the forward LSP to report the results of RP TLV processing and
return path selection. When sending echo request, these codes MUST be return path selection. When sending echo request, these codes MUST
set to zero. RP return code only used when sending echo reply, and it be set to zero. RP return code only used when sending echo reply,
MUST be ignored when processing echo request message. This document and it MUST be ignored when processing echo request message. This
defines the following RP return codes: document defines the following RP return codes:
Value Meaning
----- ----------------------
0 No return code
1 Malformed RP TLV was received
2 One or more of the sub-TLVs in RP TLV
was not understood
3 The echo reply was sent successfully
using the specified RP
4 The specified RP was not found, the echo
reply was sent via other LSP
5 The specified RP was not found, the echo
reply was sent via IP path
6 The Reply mode in echo request was not set to 5
(replay via specified path) although RP TLV exists
7 RP TLV was missing in echo request Value Meaning
----- ----------------------
0 No return code
1 Malformed RP TLV was received
2 One or more of the sub-TLVs in RP TLV was not understood
3 The echo reply was sent successfully using the specified RP
4 The specified RP was not found, the echo reply was sent via
other LSP
5 The specified RP was not found, the echo reply was sent via
IP path
6 The Reply mode in echo request was not set to 5(replay via
specified path) although RP TLV exists
7 RP TLV was missing in echo request
Flag field is also 2 octets in length, it is used to notify the Flag field 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 Flag field is a bit vector and has following path selection. The Flag field is a bit vector and has following
format: format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero |A|B|E| | MUST be zero |A|B|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A (Alternative path): the egress LSR MUST select a non-default path A (Alternative path): the egress LSR MUST select a non-default path
as the return path. This is very useful when reverse default path as the return path. This is very useful when reverse default path
problems are suspected which can be confirmed when the echo reply is problems are suspected which can be confirmed when the echo reply is
forced to follow a non-default return path. If A bit is set, there is forced to follow a non-default return path. If A bit is set, there
no need to carry any specific reply path sub-TLVs. is no need to carry any specific reply path sub-TLVs.
B (Bidirectional): the return path is required to follow the reverse B (Bidirectional): the return path is required to follow the reverse
direction of the tested bidirectional LSP. direction of the tested bidirectional LSP.
E (Exclude): the return path is required to exclude the paths that E (Exclude): the return path is required to exclude the paths that
field. This is very useful when one or more previous LSP Ping are identified by the reply path sub-TLVs carried in the Reply Paths
attempts failed. By setting this E bit and carrying the previous field. This is very useful when one or more previous LSP Ping
attempts failed. By setting this E bit and carrying the previous
failed reply path sub-TLVs, a new LSP Ping echo request could be used failed reply path sub-TLVs, a new LSP Ping echo request could be used
to help the egress LSR to select another candidate path when sending to help the egress LSR to select another candidate path when sending
echo reply message. echo reply message.
A bit MUST NOT be set when any one of other two bits (B bit and E A bit MUST NOT be set when any one of other two bits (B bit and E
bit) set. bit) set.
The Reply Paths field is variable in length. It has several nested The Reply Paths field is variable in length. It has several nested
sub-TLVs that describe the specified paths the echo reply message is sub-TLVs that describe the specified paths the echo reply message is
required to follow. When the Reply Mode field is set to "Reply via required to follow. When the Reply Mode field is set to "Reply via
specified path" in an LSP echo request message, the RP TLV MUST be specified path" in an LSP echo request message, the RP TLV MUST be
present. present.
3.3. RP TLV sub-TLVs 3.3. RP TLV sub-TLVs
Each of the FEC sub-TLVs defined in [RFC4379] is applicable to be a Each of the FEC sub-TLVs for the Target FEC Stack TLV[RFC4379] is
sub-TLV for inclusion in the RP TLV for expressing a specific return applicable to be a sub-TLV for inclusion in the RP TLV for expressing
path. a specific return path.
In addition, three more new sub-TLVs are defined: IPv4 RSVP Tunnel In addition, three more new sub-TLVs are defined: IPv4 RSVP Tunnel
sub-TLV, IPv6 RSVP Tunnel sub-TLV, and RP TC (Traffic Class) sub-TLV. sub-TLV, IPv6 RSVP Tunnel sub-TLV, and RP TC (Traffic Class) sub-TLV.
Detailed definition is in the following sections. Detailed definition is in the following sections.
With the Return Path TLV flags and the sub-TLVs defined in [RFC4379] With the Return Path TLV flags and the sub-TLVs defined for the
and in this document, it could provide following options for return Target FEC Stack TLV and in this document, it could provide following
paths specifying: options for return paths specifying:
1. Specify a particular LSP as return path 1. Specify a particular LSP as return path
- use those sub-TLVs defined in [RFC4379],
2. Specify a more generic tunnel FEC as return path - use those sub-TLVs defined for the Target FEC Stack TLV
- use the IPv4/IPv6 RSVP Tunnel sub-TLVs defined in Section
3.3.1 and Section 3.3.2 of this document
3. Specify the reverse path of the bidirectional LSP as return path - 2. Specify a more generic tunnel FEC as return path
use B bit defined in Section 3.2 of this document.
4. Force return path to non-default path - use the IPv4/IPv6 RSVP Tunnel sub-TLVs defined in Section
- use A bit defined in Section 3.2 of this document. 3.3.1 and Section 3.3.2 of this document
5. Allow any LSPs except specific or general ones as return path 3. Specify the reverse path of the bidirectional LSP as return path
- use E bit (Section 3.2 of this document) and combine with
the specific paths identified by the sub-TLVs carried in
Reply Path field.
3.3.1. IPv4 RSVP Tunnel sub-TLV - use B bit defined in Section 3.2 of this document.
4. Force return path to non-default path
- use A bit defined in Section 3.2 of this document.
5. Allow any LSPs except specific or general ones as return path
- use E bit (Section 3.2 of this document) and combine with
the specific paths identified by the sub-TLVs carried in Reply
Path field.
3.3.1. IPv4 RSVP Tunnel sub-TLV
The IPv4 RSVP Tunnel sub-TLV is used in the RP TLV to allow the The IPv4 RSVP Tunnel sub-TLV is used in the RP TLV to allow the
operator to specify a more generic tunnel FEC other than a particular operator to specify a more generic tunnel FEC other than a particular
LSP as the return path. The egress LSR chooses any LSP from the LSPs LSP as the return path. The egress LSR chooses any LSP from the LSPs
that have the same Tunnel attributes and satisfy the conditions that have the same Tunnel attributes and satisfy the conditions
carried in the Flag field. The format of IPv4 RSVP Tunnel sub-TLV is carried in the Flag field. The format of IPv4 RSVP Tunnel sub-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 RSVP Tunnel sub-TLV Type | Length | | IPv4 RSVP Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address | | IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flag | Tunnel ID | | Flag | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address | | IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [RFC4379]. All fields have the same
semantics as defined in [RFC4379] except that the LSP-ID field is semantics as defined in [RFC4379] except that the LSP-ID field is
omitted and a new Flag field is defined. omitted and a new Flag 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 18 (to be confirmed by IANA). the recommended type value is 18 (to be confirmed by IANA).
The Flag field is 2 octets in length, it is used to notify the egress The Flag field is 2 octets in length, it is used to notify the egress
LSR how to choose the return path. The Flag field is a bit vector and LSR how to choose the return path. The Flag field is a bit vector
has following format: and has following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero |S|P| | MUST be zero |S|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P (Primary): the return path MUST be chosen from the LSPs that have P (Primary): the return path MUST be chosen from the LSPs that have
the same Tunnel attributes and the LSP MUST be the primary LSP. the same Tunnel attributes and the LSP MUST be the primary LSP.
S (Secondary): the return path MUST be chosen from the LSPs that have S (Secondary): the return path MUST be chosen from the LSPs that have
the same Tunnel attributes and the LSP MUST be the secondary LSP. the same Tunnel attributes and the LSP MUST be the secondary LSP.
P bit and S bit MUST NOT both be set. If P bit and S bit are both not P bit and S bit MUST NOT both be set. If P bit and S bit are both
set, the return path could be any one of the LSPs that have the same not set, the return path could be any one of the LSPs that have the
Tunnel attributes. same Tunnel attributes.
3.3.2. IPv6 RSVP Tunnel sub-TLV 3.3.2. IPv6 RSVP Tunnel sub-TLV
The IPv6 RSVP Tunnel sub-TLV is used in the RP TLV to allow the The IPv6 RSVP Tunnel sub-TLV is used in the RP TLV to allow the
operator to specify a more generic tunnel FEC other than a particular operator to specify a more generic tunnel FEC other than a particular
LSP as the return path. The egress LSR chooses an LSP from the LSPs LSP as the return path. The egress LSR chooses an LSP from the LSPs
that have the same Tunnel attributes and satisfy the conditions that have the same Tunnel attributes and satisfy the conditions
carried in the Flag field. The format of IPv6 RSVP Tunnel sub-TLV is carried in the Flag field. The format of IPv6 RSVP Tunnel sub-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 12, line 28 skipping to change at page 10, line 28
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address | | IPv6 tunnel sender address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 RSVP Tunnel sub-TLV is derived from RSVP IPv6 FEC TLV that The IPv6 RSVP Tunnel sub-TLV is derived from RSVP IPv6 FEC TLV that
is defined in Section 3.2.4 of [RFC4379].All fields have the same 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 semantics as defined in [RFC4379] except that the LSP-ID field is
omitted and a new Flag field is defined.. omitted and a new Flag 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 recommended type value is 19 (to be confirmed by IANA). the recommended type value is 19 (to be confirmed by IANA).
The Flag field is 2 octets in length and is identical to that The Flag field is 2 octets in length and is identical to that
described in Section 3.3. described in Section 3.3.
3.3.3. RP TC sub-TLV 3.3.3. RP TC sub-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 sub-TLV: RP TC sub-TLV is defined and MAY be used by document, a new sub-TLV: RP TC sub-TLV is defined and MAY be used by
the originator of the echo request to request that an echo reply be the originator of the echo request to request that an echo reply be
sent with the TC bits of the specified return LSP set to the value sent with the TC bits of the specified return LSP set to the value
specified in this sub-TLV. Since there may be more than one FEC sub- specified in this sub-TLV. Since there may be more than one FEC sub-
TLVs (return paths) specified in the RP TLV, the relevant RP TC sub- TLVs (return paths) specified in the RP TLV, the relevant RP TC sub-
TLV MUST directly follow the FEC sub-TLV that identifies the TLV MUST directly follow the FEC sub-TLV that identifies the
corresponding specified return LSP. The format of RP TC sub-TLV is as corresponding specified return LSP. The format of RP TC sub-TLV is
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP TC sub-TLV type | Length | | RP TC sub-TLV type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TC | MUST be zero | | TC | MUST be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RP TC sub-TLV Type field is 2 octets in length, and the The RP TC sub-TLV Type field is 2 octets in length, and the
recommended type value is 17 (to be confirmed by IANA). recommended type value is 17 (to be confirmed by IANA).
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. fixed 4.
4. Theory of Operation 4. 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 document. "ping" mode. The "traceroute" mode is out of scope for this
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 (RP TLV) which enable the LSP ping initiator to mode and a new TLV (RP TLV) which enable the LSP ping initiator to
specify or constrain the return path of the echo reply. Similarly the specify or constrain the return path of the echo reply. Similarly
behavior of echo reply is extended to detect the requested return the behavior of echo reply is extended to detect the requested return
path by looking at a specified path FEC TLV. This enables LSP Ping to path by looking at a specified path FEC TLV. This enables LSP Ping
detect failures in both directions of a path with a single operation, to detect failures in both directions of a path with a single
this of course cuts in half the operational steps required to verify operation, this of course cuts in half the operational steps required
the end to end bidirectional connectivity and integrity of an LSP. to verify the end to end bidirectional connectivity and integrity of
an LSP.
When the echo reply message is intended to test the return MPLS LSP When the echo reply message is intended to test the return MPLS LSP
path(the A bit and E bit is not set in the previous received echo path(when the A bit and E bit is not set in the previous received
request message), the destination IP address of the echo reply echo request message), the destination IP address of the echo reply
message MUST never be used in a forwarding decision. To avoid this message MUST never be used in a forwarding decision. To avoid this
possibility the destination IP address of the echo reply message that possibility the destination IP address of the echo reply message that
is transmitted along the specified return path MUST be set to numbers is 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/104 for IPv6, and from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, and
the IP TTL MUST be set 1. Of course when the echo reply message is the IP TTL MUST be set 1. Of course when the echo reply message is
not intended for testing the specified return path, the not intended for testing the specified return path (when the A bit or
E bit is set in the previous received echo request message) , the
procedures defined in [RFC4379] (the destination IP address is copied procedures defined in [RFC4379] (the destination IP address is copied
from the source IP address) apply unchanged. from the source IP address) apply unchanged.
4.1. Sending an Echo Request 4.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 RP TLV MUST request MUST be set to "Reply via specified path", and a RP TLV MUST
be carried in the echo request message correspondingly. The RP TLV be carried in the echo request message correspondingly. The RP TLV
includes one or several reply path sub-TLV(s) to identify the return includes one or several reply path sub-TLV(s) to identify the return
path(s) the egress LSR should use for its reply. 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 RP and backward direction LSPs, only the B bit SHOULD be set in the RP
TLV. If the operator wants the echo reply to be sent along a TLV. If the operator wants the echo reply to be sent along a
different path other than the reverse direction of the bidirectional different path other than the reverse direction of the bidirectional
LSP, "A" bit SHOULD be set or another FEC sub-TLV SHOULD be carried LSP, "A" bit SHOULD be set or another FEC sub-TLV SHOULD be carried
in the RP TLV instead, and the B bit MUST be clear. in the RP TLV instead, and the B bit MUST 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 RP TLV) accomplish this, the echo request message MUST carry (in the RP TLV)
a FEC sub-TLV that belongs to the backward LSP. a FEC sub-TLV that belongs to the backward LSP.
4.2. Receiving an Echo Request 4.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] applies
in this document. In addition, when an echo request is received, if in this document. In addition, when an echo request is received, if
the egress LSR does not know the reply mode defined in this document, the egress LSR does not know the reply mode defined in this document,
an echo reply with the return code set to "Malformed echo request" an echo reply with the return code set to "Malformed echo request"
and the Subcode set to zero will be send back to the ingress LSR and the Subcode set to zero will be send back to the ingress LSR
according to the rules of [RFC4379]. If the egress LSR knows the according to the rules of [RFC4379]. If the egress LSR knows the
reply mode, according to the RP TLV, it SHOULD find and select the reply mode, according to the RP TLV, it SHOULD find and select the
desired return path. If there is a matched path, an echo reply with desired return path. If there is a matched path, an echo reply with
RP TLV that identify the return path SHOULD be sent back to the RP TLV that identify the return path SHOULD be sent back to the
ingress LSR, the RP return code SHOULD be set to "The echo reply was ingress LSR, the RP return code SHOULD be set to "The echo reply was
sent successfully using the specified RP". If there is no such path, sent successfully using the specified RP". If there is no such path,
an echo reply with RP TLV SHOULD be sent back to the ingress LSR, the an echo reply with RP TLV SHOULD be sent back to the ingress LSR, the
RP return code SHOULD be set to relevant code (defined Section 3.2) RP return code SHOULD be set to relevant code (defined Section 3.2)
for the real situation to reflect the result of RP TLV processing and for the real situation to reflect the result of RP TLV processing and
return path selection. For example, if the specified LSP is not return path selection. For example, if the specified LSP is not
found, the egress then chooses another LSP as the return path to send found, the egress then chooses another LSP as the return path to send
the echo reply, the RP return code SHOULD be set to "The specified RP the echo reply, the RP return code SHOULD be set to "The specified RP
was not found, the echo reply was sent via other LSP", and if the was not found, the echo reply was sent via other LSP", and if the
egress chooses an IP path to send the echo reply, the RP return code egress chooses an IP path to send the echo reply, the RP return code
SHOULD be set to "The specified RP was not found, the echo reply was SHOULD be set to "The specified RP was not found, the echo reply was
sent via IP path". If there is unknown sub-TLV in the received RP sent via IP path". If there is unknown sub-TLV in the received RP
TLV, the RP return code SHOULD be set to "One or more of the sub-TLVs TLV, the RP return code SHOULD be set to "One or more of the sub-TLVs
in RP TLV was not understood". in RP TLV was not understood".
If the A bit of the RP TLV in a received echo request message is set, If the A bit of the RP TLV in a received echo request message is set,
the egress LSR SHOULD send the echo reply along an non-default return the egress LSR SHOULD send the echo reply along an non-default return
path. path.
IF the B bit of the RP TLV in a received echo request message is set, IF the B bit of the RP TLV in a received echo request message is set,
the egress LSR SHOULD send the echo reply along the reverse direction the egress LSR SHOULD send the echo reply along the reverse direction
of the bidirectional LSP. of the bidirectional LSP.
skipping to change at page 15, line 23 skipping to change at page 13, line 28
reply. reply.
If the A and E bit of the RP TLV in a received echo request message If the A and E bit of the RP TLV in a received echo request message
is not set, the echo reply is REQUIRED not only to send along the is not set, the echo reply is REQUIRED not only to send along the
specified path, but to test the selected return path as well (by specified path, but to test the selected return path as well (by
carrying the FEC stack information of the return path). carrying the FEC stack information of the return path).
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 4.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 routable IP address of the replier, the source source IP address is a routable 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 echo reply is intended to test the return path (both A and E When the echo reply is intended to test the return path (both A and E
bit are not set in the previous received echo request), the bit are not set in the previous received echo request), the
destination IP address of the echo reply message MUST never be used destination IP address of the echo reply message MUST never be used
in a forwarding decision. To avoid this problem, the IP destination in a forwarding decision. To avoid this problem, the IP destination
address of the echo reply message that is transmitted along the address of the echo reply message that is transmitted along the
specified return path MUST be set to numbers from the range 127/8 for specified return path MUST be set to numbers from the range 127/8 for
IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, and the IP TTL MUST be set IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, and the IP TTL MUST be set
to 1. Otherwise, the same as defined in [RFC4379], the destination IP to 1. Otherwise, the same as defined in [RFC4379], the destination
address and UDP port are copied from the source IP address and source IP address and UDP port are copied from the source IP address and
UDP port of the echo request. source UDP port of the echo request.
When sending the echo reply, a RP TLV that identifies the return path When sending the echo reply, a RP TLV that identifies the return path
MUST be carried, the RP return code SHOULD be set to relevant code MUST be carried, the RP return code SHOULD be set to relevant code
that reflects results about how the egress processes the RP TLV in a that reflects results about how the egress processes the RP TLV in a
previous received echo request message and return path selection. By previous received echo request message and return path selection. By
carrying the RP TLV in an echo reply, it gives the Ingress LSR enough carrying the RP TLV in an echo reply, it gives the Ingress LSR enough
information about the reverse direction of the tested path to verify information about the reverse direction of the tested path to verify
the consistency of the data plane against control plane. Thus a the consistency of the data plane against control plane. Thus a
single LSP Ping could achieve both directions of a path test. single LSP Ping could achieve both directions of a path test. If the
return path is pure IP path, no sub-TLVs are carried in the RP TLV.
4.4. Receiving an Echo Reply
4.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 RP return code is "The echo reply was sent specified path" and the RP return code is "The echo reply was sent
successfully using the specified RP", and if both the A bit and E bit successfully using the specified RP", and if both the A bit and E bit
are not set. The ingress LSR MUST do FEC validation (based on the FEC are not set. The ingress LSR MUST do FEC validation (based on the
stack information of the return path carried in the RP TLV) as an FEC stack information of the return path carried in the RP TLV) as an
egress LSR does when receiving an echo request, the FEC validation egress LSR does when receiving an echo request, the FEC validation
process (relevant to "ping" mode) defined in Section 4.4.1 of process (relevant to "ping" mode) defined in Section 4.4.1 of
[RFC4379] applies here. [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 RP return code in the RP TLV set to On receipt of an echo reply with RP return code in the RP TLV set to
"The specified RP was not found, ...", it means that the egress LSR "The specified RP was not found, ...", it means that the egress LSR
could not find a matched return path as specified. Operators may could not find a matched return path as specified. Operators may
choose to specify another LSP as the return path or use other methods choose to specify another LSP as the return path or use other methods
to detect the path further. to detect the path further.
When the LSP Ping initiator fails after some time to receive the echo When the LSP Ping initiator fails after some time to receive the echo
reply message, the operator MAY initiate another LSP Ping by reply message, the operator MAY initiate another LSP Ping by
resending a new echo request carrying a RP TLV with E bit set, the resending a new echo request carrying a RP TLV with E bit set, the
sub-TLVs and/or B bit (when the tested LSP is a bidirectional LSP) sub-TLVs and/or B bit (when the tested LSP is a bidirectional LSP)
identify the previous tried reply paths that are used to notify the identify the previous tried reply paths that are used to notify the
egress LSR to send echo reply message along any other workable path egress LSR to send echo reply message along any other workable path
other than these failed return paths. Hence it could improve the other than these failed return paths.
reliability of the echo reply message.
5. Security Considerations 5. Security Considerations
Security considerations discussed in [RFC4379] apply to this Security considerations discussed in [RFC4379] apply to this
document. In addition to that, in order to prevent using the document. In addition to that, in order to prevent using the
extension defined in this document for "proxying" any possible extension defined in this document for "proxying" any possible
attacks, the return path LSP MUST have destination to the same node attacks, the return path LSP MUST have destination to the same node
where the forward path is from. where the forward path is from.
6. IANA Considerations 6. IANA Considerations
IANA is requested to assign one new TLV from the "Multiprotocol Label IANA is requested to assign one new TLV from the "Multiprotocol Label
Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters
- TLVs" registry, "TLVs and sub-TLVs" sub- registry; and a set of - TLVs" registry, "TLVs and sub-TLVs" sub- registry; and a set of
sub-TLVs under this new TLV; one new Reply Mode from the sub-TLVs under this new TLV; one new Reply Mode from the "Multi-
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Parameters" registry, the "Reply Mode" subregistry. Parameters" registry, the "Reply Mode" subregistry.
6.1. New TLV 6.1. New TLV
The IANA is requested to as assign a new TLV from the "Multiprotocol The IANA is requested to as assign a new TLV from the "Multiprotocol
Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Label Switching Architecture (MPLS) Label Switched Paths (LSPs)
Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- registry. Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- registry.
Value Meaning Reference Value Meaning Reference
----- ------- --------- ----- ------- ---------
21 Reply Path TLV this document (sect 3.2) 21 Reply Path TLV this document (sect 3.2)
6.2. Sub-TLVs
6.2.1. Sub-TLVs from RFC3479
The following sub-TLVs to the Target FEC Stack specified in Section
3.2 of RFC4379 and fournd in the "Multiprotocol Label Switching
Architecture (MPLS) Label Switched Paths (LSPs) Parameters - TLVs"
registry, "TLVs and sub-TLVs" sub- registry are also valid for the
Reply Path TLV.
Sub-Type Value Field Reference 6.2. Sub-TLVs
-------- ----------- ---------
1 LDP IPv4 prefix RFC4379
2 LDP IPv6 prefix RFC4379
3 RSVP IPv4 LSP RFC4379
4 RSVP IPv6 LSP RFC4379
5 Not Assigned RFC4379
6 VPN IPv4 prefix RFC4379
7 VPN IPv6 prefix RFC4379
8 L2 VPN endpoint RFC4379
9 "FEC 128" Pseudowire (deprecated) RFC4379
10 "FEC 128" Pseudowire RFC4379
11 "FEC 129" Pseudowire RFC4379
12 BGP labeled IPv4 prefix RFC4379
13 BGP labeled IPv6 prefix RFC4379
14 Generic IPv4 prefix RFC4379
15 Generic IPv6 prefix RFC4379
16 Nil FEC RFC4379
The IANA is requested to assign the same values to the sub-TLVs for Since all existing sub-TLVs and any new sub-TLVs added to the Target
the Reply Path TLV (Type 21)as those used for the sub-TLVs for the FEC Stack TLV apply to the Reply Path TLV, except for the range of
Target FEC Stack TLV (TLV Type 1) in the same registry. 31744-32767 that is left for "Vendor Private Use" in the sub-type
space of Target FEC Stack TLV, the sub-TLV space and assignment for
Reply Path TLV and Target FEC Stack TLV MUST be kept the same. All
new sub-types dedicated added to the Reply Path TLV MUST be assigned
from the range of 31744-32767.
6.2.2. New Sub-TLVs 6.2.1. New Sub-TLVs
IANA is also requested to assign three new sub-TLV types from IANA is also requested to assign three new sub-TLV types from
"Multiprotocol Label Switching Architecture (MPLS) Label Switched "Multiprotocol Label Switching Architecture (MPLS) Label Switched
Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-
registry for the Reply Path TLV (Type 21). registry for the Reply Path TLV (Type 21).
Sub-type Value Field Reference
------- ----------- ---------
TBD RP TC this document (sect 3.3.3)
TBD IPv4 RSVP Tunnel this document (sect 3.3.2)
TBD IPv6 RSVP Tunnel this document (sect 3.3.1)
Sub-type Value Field Reference 6.2.2. New Reply Mode
------- ----------- ---------
17 RP TC this document (sect 3.3.3)
18 IPv4 RSVP Tunnel this document (sect 3.3.2)
19 IPv6 RSVP Tunnel this document (sect 3.3.1)
6.2.3. New Reply Mode
IANA is requested to assign a new reply mode code point from the from IANA is requested to assign a new reply mode code point from the from
the "Multi-Protocol Label Switching (MPLS) Label Switched Paths the "Multi-Protocol Label Switching (MPLS) Label Switched Paths
(LSPs) Parameters" registry, the "Reply Mode" subregistry. (LSPs) Parameters" registry, the "Reply Mode" subregistry.
Value Meaning Reference Value Meaning Reference
----- ------- ---------- ----- ------- ----------
5 Reply via specified path this document (sect 3.1) 5 Reply via specified path this document (sect 3.1)
7. Contributors 7. 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
8. Acknowledgments Xinchun Guo
EMail: guoxinchun@huawei.com
The authors would like to thank Adrian Farrel and Peter Ashwood- 8. Acknowledgements
Smith for their review, suggestion and comments to this document.
9. References The authors would like to thank Adrian Farrel and Peter Ashwood-Smith
for their review, suggestion and comments to this document.
9.1. Normative References 9. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 9.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4379] K. Kompella., et al., "Detecting Multi-Protocol Label [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Switched (MPLS) Data Plane Failures", RFC 4379, February Requirement Levels", BCP 14, RFC 2119, March 1997.
2006.
9.2. Informative References [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC3471] L. Berger, "Generalized Multi-Protocol Label Switching 9.2. Informative References
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] L. Berger, "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling", RFC 3473, January 2003. (GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC5654] Niven-Jenkins, B. (Ed.), Brungard, D. (Ed.), Betts, M. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(Ed.) Sprecher, N., and Ueno, S., "Requirements of an MPLS (GMPLS) Architecture", RFC 3945, October 2004.
Transport Profile", RFC 5654, September 2009.
[BFD] D. Katz, D. and Ward, D., "Bidirectional Forwarding [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
Detection", RFC5880, June 2010. and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
"BFD For MPLS LSPs", RFC5884, June 2010. (BFD)", RFC 5880, June 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
Authors' Addresses Authors' Addresses
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd
No. 3 Xinxi Road Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
Shangdi Information Industry Base Beijing 100095
Hai-Dian District, Beijing 100085
China China
EMail: mach@huawei.com Email: mach@huawei.com
Wei Cao
Huawei Technologies Co., Ltd
Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
Beijing 100095
China
Email: wayne.caowei@huawei.com
So Ning So Ning
Verizon Inc. Verizon Inc.
2400 N. Glenville Rd., 2400 N. Glenville Rd.,
Richardson, TX 75082 Richardson, TX 75082
USA
Phone: +1 972-729-7905 Email: ning.so@verizonbusiness.com
EMail: ning.so@verizonbusiness.com
Frederic Jounay Frederic Jounay
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex Lannion Cedex 22307
FRANCE FRANCE
EMail: frederic.jounay@orange-ftgroup.com Email: frederic.jounay@orange-ftgroup.com
Simon Delord Simon Delord
Alcatel-Lucent Alcatel-Lucent
Building 3, 388 Ningqiao Road, Jinqiao, Pudong Building 3, 388 Ningqiao Road, Jinqiao, Pudong
Shanghai, 201206, P.R. China Shanghai 201206
EMail: simon.delord@alcatel-lucent.com
Xinchun Guo
Huawei Technologies Co., Ltd.
No. 3 Xinxi Road
Shangdi Information Industry Base
Hai-Dian District, Beijing 100085
China
EMail: guoxinchun@huawei.com
Wei Cao
Huawei Technologies Co., Ltd.
No. 3 Xinxi Road
Shangdi Information Industry Base
Hai-Dian District, Beijing 100085
China China
EMail: caoweigne@huawei.com Email: simon.delord@alcatel-lucent.com
 End of changes. 137 change blocks. 
345 lines changed or deleted 314 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/