Network working group M. Chen
Internet Draft X. Guo
Category: Standards Track W. Cao
Created: July 2, 2009 Huawei Technologies Co.,Ltd
Expires: January 2010 N. So
Verizon
F. Jounay
France Telecom
S. Delord
Telstra
Return Path Specified LSP Ping
draft-chen-mpls-return-path-specified-lsp-ping-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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 August 15, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Chen, et al. Expires January 2, 2010 [Page 1]
Internet-Draft Return Path Specified LSP Ping July 2009
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Abstract
This document defines extensions to LSP Ping [RFC 4379] to enable
the return path(s) of an echo reply message, so that it can be
specified when sending an echo request message to perform LSP
failure detection, and the echo reply message is extended to detect
the return path(s). This capability could improve the reliability of
echo reply and allows failure detection of a Bidirectional LSP or
two unidirectional LSPs being performed by one message, resulting in
operational saving.
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
1. Introduction.................................................3
2. Problem statements and solution overview.....................3
3. Extensions...................................................4
3.1. Reply Via Specified Path mode...........................5
3.2. The return codes........................................5
3.3. Reply Path (RP) TLV.....................................5
3.4. Bidirectional sub-TLV...................................6
3.5. Any Candidate sub-TLV...................................7
4. Theory of Operation..........................................7
4.1. Sending an Echo Request.................................8
4.2. Receiving an Echo Request...............................8
4.3. Sending an Echo Reply...................................9
4.4. Receiving an Echo Reply.................................9
5. Security Considerations.....................................10
6. IANA Considerations.........................................10
6.1. Reply mode and return codes............................10
6.2. RP TLV.................................................11
6.3. Sub-TLVs for RP TLV....................................11
7. Acknowledgments.............................................12
8. References..................................................12
8.1. Normative References...................................12
8.2. Informative References.................................13
Authors' Addresses.............................................14
Chen, et al. Expires January 2, 2010 [Page 2]
Internet-Draft Return Path Specified LSP Ping July 2009
1. Introduction
This document defines the extensions to LSP Ping that can be used to
specify the return path(s) of the echo reply message in a LSP Ping
echo request message. Several new reply mode requirements are added
and a new Type-Length-Value (TLV) is defined.
With the extensions described in this document, the operators can
detect a Co-routed Bidirectional LSP and Associated Bidirectional
LSP with a single operational action, resulting in operational
savings. It can also detect two unidirectional LSPs without any
inherency or binding relationship (one for each direction) in one
operational action as well, reduces the opportunity for error, and
improves the reliability of the echo reply message.
In this document, Bidirectional LSP includes Co-routed Bidirectional
LSP defined in [RFC 3471] [RFC 3473] and Associated Bidirectional
LSP that is constructed from a pair of unidirectional LSPs (one for
each direction), and are associated with one another at the LSP's
ingress/egress points. In the rest of this document, if there is no
extra explanation, when say Bidirectional LSP, it includes both Co-
routed Bidirectional LSP and Associated Bidirectional LSP.
2. Problem statements and solution overview
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping
is defined in [RFC 4379]. It can be used to detect data plan
failures in MPLS LSPs. More specifically, it is designed for
unidirectional LSPs.
Co-routed Bidirectional LSP is defined in [RFC 3471] [RFC 3473], but
with the existing LSP Ping mechanisms defined in [RFC 4379], the
operators have to perform LSP detection on each of the two ends of a
specific Bidirectional LSP respectively. It not only doubles the
workload of the operators, but may also bring additional
difficulties when checking the backward direction of the LSP under
the following conditions
1. The LSR that the operator logged on to perform the checking
operations may not have out-of-band connectivity to the remote LSR
of the LSP. That can result in failing to check the return
direction of the Bidirectional LSP.
2. The tested LSP is an inter-domain/inter-AS LSP, the operator of
one domain/AS may have no right to log on to the remote LSR reside
Chen, et al. Expires January 2, 2010 [Page 3]
Internet-Draft Return Path Specified LSP Ping July 2009
in another domain/AS. That can also result in failing to check the
return direction of the Bidirectional LSP.
3. The return path of the echo reply message is randomly
determined by the egress of the LSP. However, there can be more
than one LSPs connecting the two LSRs. When a LSP Ping echo
request for detecting one Bidirectional LSP reached remote LSR,
the remote LSR may choose another LSP as the return path. This
can result in mis-information and mis-diagnostics.
For Associated Bidirectional LSPs and even unidirectional LSPs, they
have the similar issues listed above.
This document defines the extensions to LSP Ping that can be used to
specify the return path(s) of the echo reply message in a LSP echo
request message. A new TLV is defined to carry the specific return
path(s) information required by the initiator. Several new reply
mode requirements are added. For example, this document specifies
that the echo reply should return along the back direction LSP of
the tested Bidirectional LSP, or the specific return path(s) as
defined in the echo request message.
The detail extensions and procedures are defined in the following
sections.
3. Extensions
LSP Ping defined in [RFC 4379] is carried out by sending echo
request message. It carries the Forwarding Equivalence Class (FEC)
information of the tested LSP for indicating which MPLS path is
being verified, along the same data path as other normal data
packets belonging to the FEC.
The only determinant of the echo reply message return path is the
four reply modes defined in Section 3 of [RFC 4379]. But it is not
enough for the egress LSR of the tested LSP to determine how to
choose the return path(s) of the echo reply message.
This document defines a new reply mode, Reply Via Specified Path
mode. This new mode can be used to direct the egress of the tested
LSP to send back the echo reply message along the path specified in
the echo request message.
This document also adds a new TLV, Reply Path TLV. The Reply Path
TLV consists one or more sub-TLVs that can be used to carry the
Chen, et al. Expires January 2, 2010 [Page 4]
Internet-Draft Return Path Specified LSP Ping July 2009
specified return path information of an echo reply message. The
detail definitions listed below.
3.1. Reply Via Specified Path mode
The recommended value of the Reply via specified path mode is 5
(SHOULD be confirmed by the IANA).
Value Meaning
----- -------
5 Reply via specified path
The Reply via specified path mode is used to notify the remote LSR
received the LSP Ping echo request message to send back the echo
reply message along the specified path(s) carried in the Reply Path
TLV.
3.2. The return codes
This document defines two new return codes that can be used to
inform the sender the results of the testing.
Value Meaning
----- -------
14 Success to match the specified path
15 The specified reply path not existence
Return code 15 is used when egress fails to match the specified
reply path which is designated by ingress node. For example ingress
node expects to detect the reply path of the bidirectional LSP, but
the path being tested isn't bidirectional indeed, and also the
condition that the specified path does not exist on egress. Return
code 14 will be used when egress matches the specified reply path
successfully. The detailed usage of the return codes is described in
Section 4.
3.3. Reply Path (RP) TLV
The Reply Path (RP) TLV is included in an echo request message. It
carries the specified return path(s) that the echo reply message
required to follow. The format of RP TLV is as follows:
Chen, et al. Expires January 2, 2010 [Page 5]
Internet-Draft Return Path Specified LSP Ping July 2009
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path(s) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RP TLV Type field is 2 octets in length, and the type value is TBD
(which is needed to be assigned by IANA).
Length field is 2 octets in length. It defines the length in octets
of the Reply Path(s) field.
Reply Path(s) field is variable in length. It has several nested
sub-TLVs that describe the specified path(s) the echo reply message
is required to follow. Each of the FEC sub-TLVs defined in [RFC
4379] is applicable to be a sub-TLV for inclusion in the RP TLV for
expressing a specific return path.
In addition, two more new sub-TLVs are defined, Bidirectional sub-
TLV and Any Candidate sub-TLV.
3.4. Bidirectional sub-TLV
The Bidirectional sub-TLV is used when the return path is required
to follow the back direction of the tested Bidirectional LSP. The
format of Bidirectional sub-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bidirectional sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Bidirectional sub-TLV Type field is 2 octets in length, and the
type value is 17 (which is needed to be confirmed by IANA).
Length field is 2 octets in length, the value of length field MUST
be 0, it means that there is no any value fields follows.
Chen, et al. Expires January 2, 2010 [Page 6]
Internet-Draft Return Path Specified LSP Ping July 2009
3.5. Any Candidate sub-TLV
The Any Candidate sub-TLV is used when the return path is required
to exclude the path(s) that are identified by any other reply path
sub-TLVs carried in the echo request message. This is very useful
when one/several previous LSP Ping(s) failed. By carrying an Any
Candidate sub-TLV and the previous failed reply path sub-TLVs, a new
LSP Ping echo request could be used to help the egress to select
another candidate path when sending echo reply message. The format
of Any Candidate sub-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Any Candidate sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Any Candidate sub-TLV Type field is 2 octets in length, and the
type value is 18 (which is needed to be confirmed by IANA).
Length field is 2 octets in length, the value of length field MUST
be 0, it means that there is no any value fields follows.
4. Theory of Operation
The procedures defined in this document only apply to "ping" mode,
how to deal with "traceroute" mode is out of the scope of this
document.
In RFC 4379, the echo reply is used to report the LSP checking
result to the LSP Ping initiator. This document defines a new reply
mode and a new TLV (RP TLV) to enable that the return path of the
echo reply message could specified by the LSP Ping initiator, and
the function of echo reply is extended to detect the return path by
carrying specified path FEC TLV. It enables LSP Ping to detect both
directions of a path in one operation.
When the echo reply message is intended to test the return MPLS LSP
path as specified, the destination IP address of the echo reply
message is never used in a forwarding decision. For the purpose of
detection the specified return MPLS LSP path, the echo reply message
also needs to avoid IP forward at the condition of the LSP being
tested broken. So the destination IP address of the echo reply
message that is transmitted along the specified return path MUST be
set 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 1. If the echo reply message
Chen, et al. Expires January 2, 2010 [Page 7]
Internet-Draft Return Path Specified LSP Ping July 2009
is not intended for testing the specified return path, the same as
defined in [RFC 4379], the destination IP address is copied from the
source IP address of the echo request.
4.1. Sending an Echo Request
When sending an echo request, in addition to the rules and
processing defined in Section 4.3 of [RFC 4379], the reply mode of
the echo 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 includes one or several reply path sub-TLV(s) to identify the
return path(s) that is used to notify the egress which path(s) to
send along.
For Bidirectional LSP, since the ingress and egress of a
Bidirectional LSP are aware of the relationship between the forward
and backward direction LSPs, only a Bidirectional sub-TLV SHOULD be
carried within the RP TLV. If the operator wants the echo reply to
be sent along a different path other than the reverse LSP of the
Bidirectional LSP, another FEC sub-TLV SHOULD be carried in the RP
TLV instead.
In some cases, operators may want to detect two unidirectional LSPs
(one for each direction) as a pair. There may not be any binding
relationship between the two LSPs. Using the mechanism defined in
this document, operators can run LSP Ping one time from one end to
complete the failure detection on both unidirectional LSPs. In such
condition, when sending the echo request message, one specific FEC
sub-TLV MUST be carried in the RP TLV to notify the egress which
path to send along and detect.
4.2. Receiving an Echo Request
Those processing relevant to "ping" mode defined in Section 4.4 of
[RFC 4379] apply in this document. In addition, when an echo request
received, if the egress does not know the reply mode defined in this
document, an echo reply with return code set to "Malformed echo
request" and the Subcode set to zero SHOULD be send back to the
ingress. If the egress knows the reply mode, according to the RP TLV,
it SHOULD find and select a matched return path, if there is no such
a path, an echo reply with return code set to "The specified reply
path not existence" and the Subcode to zero SHOULD be sent back to
the ingress. If there is a match, an echo reply with return code set
to "Success to match the specified path" and Subcode to zero SHOULD
be sent back to the ingress.
Chen, et al. Expires January 2, 2010 [Page 8]
Internet-Draft Return Path Specified LSP Ping July 2009
When received an echo request with reply mode set to "Reply via
specified path", if there is no Any Candidate sub-TLV included in
the RP TLV, means that the echo reply is required to send along the
specified path and to detect the return path as well. Otherwise,
means that the echo reply is not required to detect the return path.
4.3. Sending an Echo Reply
As described in [RFC 4379], the echo reply message is a UDP packet,
and it MUST only be sent response to an MPLS echo request. The
source IP address is a routable IP address of the replier, the
source UDP port is the well-know UDP port for LSP ping.
When the echo reply is intended to test the return path, the
destination IP address of the echo reply message MUST be never used
in a forwarding decision. For the purpose of detection the specified
return MPLS LSP path, the echo reply message also needs to avoid IP
forward at the condition of the LSP being tested broken. So the
destination IP address of the echo reply message that is transmitted
along the specified return path MUST be set 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 1. If the echo reply is required to test the return
path, the echo reply MUST have an FEC stack TLV about the return
path, which is used for the ingress to perform FEC validation. The
FEC stack TLV of the forward path MUST NOT be copied to the echo
reply.
If the echo reply message is not intended for testing the specified
return path, the same as defined in [RFC 4379], the destination IP
address and UDP port are copied from the source IP address and
source UDP port of the echo request.
When sending the echo reply, the RP TLV carried in the received echo
request MAY be copied to the echo reply to give the Ingress enough
information about the back direction tested path to verify the
consistent of the data plane against control plane.
4.4. Receiving an Echo Reply
The rules and process defined in Section 4.6 of [RFC 4379] apply
here. And when an echo reply received, if the reply mode is "Reply
via specified path" and an FEC stack TLV exists, it means that the
echo reply has both Ping result reporting and reverse path checking
functions. The ingress MUST do FEC validation as an egress does when
received an echo request, the FEC validation process (relevant to
"ping" mode) defined in Section 4.4.1 of [RFC 4379] apply here.
Chen, et al. Expires January 2, 2010 [Page 9]
Internet-Draft Return Path Specified LSP Ping July 2009
When received an echo reply with return code set to "Malformed echo
request received" and the Subcode set to zero. It's possible that
the egress may not know the "Reply via specified path" reply mode,
the operator may choose to re-perform another LSP Ping by using one
of the four reply modes defined [RFC 4379].
When the LSP Ping initiator failed to receive the echo reply message,
the operator MAY initiate another LSP Ping by resending a new echo
request carrying a RP TLV that includes an Any Candidate sub-TLV and
the previous sent reply path sub-TLV(s) (Bidirectional sub-TLV or
FEC sub-TLVs) to notify the egress LSR to send echo reply message
along any other workable path (no matter what MPLS LSP or IP path)
excluding the path(s) identified by those Bidirectional sub-TLV
or/and FEC sub-TLVs. Hence it could improve the reliability of the
echo reply message. In such mode, the echo reply SHOULD NOT be used
to detect the return path.
5. Security Considerations
Security considerations discussed in [RFC 4379] applies to this
document.
6. IANA Considerations
IANA is requested to make the following allocations from registries
under its control.
6.1. Reply mode and return codes
IANA is requested to assign a new reply mode and two new return
codes as follows:
Reply mode:
Value Meaning
----- -------
5 Reply via specified path
Return codes:
Chen, et al. Expires January 2, 2010 [Page 10]
Internet-Draft Return Path Specified LSP Ping July 2009
Value Meaning
----- -------
14 Success to match the specified path
15 The specified reply path not existence
6.2. RP TLV
IANA is requested to assign a new TLV type (TBD) from the range of
0-16383. We suggest that the value 20 be assigned for the new RP TLV
type.
Type Value Field
----- -----------
20 Reply Path
6.3. Sub-TLVs for RP TLV
This document defines two new sub-TLV Types (described in Section
3.4 and 3.5) of RP TLV, and those FEC sub-TLVs defined in [RFC 4379]
are applicable for inclusion in RP TVL.
IANA is requested to assign sub-TLVs as follows. The following
numbers are suggested:
Chen, et al. Expires January 2, 2010 [Page 11]
Internet-Draft Return Path Specified LSP Ping July 2009
Sub-type Value Field Reference
-------- ----------- ---------
1 LDP IPv4 prefix RFC 4379
2 LDP IPv6 prefix RFC 4379
3 RSVP IPv4 LSP RFC 4379
4 RSVP IPv6 LSP RFC 4379
5 Not Assigned RFC 4379
6 VPN IPv4 prefix RFC 4379
7 VPN IPv6 prefix RFC 4379
8 L2 VPN endpoint RFC 4379
9 "FEC 128" Pseudowire (Deprecated) RFC 4379
10 "FEC 128" Pseudowire RFC 4379
11 "FEC 129" Pseudowire RFC 4379
12 BGP labeled IPv4 prefix RFC 4379
13 BGP labeled IPv6 prefix RFC 4379
14 Generic IPv4 prefix RFC 4379
15 Generic IPv6 prefix RFC 4379
16 Nil FEC RFC 4379
17 Bidirectional this document
18 Any Candidate this document
7. Acknowledgments
The authors would like to thank Adrian Farrel and Ehud Doron for
their review and comments to this document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 4379] K. Kompella., et al., "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", RFC 4379, February
2006.
Chen, et al. Expires January 2, 2010 [Page 12]
Internet-Draft Return Path Specified LSP Ping July 2009
8.2. Informative References
[RFC 3471] L. Berger, "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC 3473] L. Berger, "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling", RFC 3473, January 2003.
Chen, et al. Expires January 2, 2010 [Page 13]
Internet-Draft Return Path Specified LSP Ping July 2009
Authors' Addresses
Mach(Guoyi) Chen
Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District, Beijing 100085
P.R. China
EMail: mach@huawei.com
Xinchun Guo
Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District, Beijing 100085
P.R. China
EMail: guoxinchun@huawei.com
Wei Cao
Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District, Beijing 100085
P.R. China
EMail: caoweigne@chinamobile.com
So Ning
Verizon
2400 N. Glem Ave.,
Richerson, TX 75082
Phone: +1 972-729-7905
EMail: ning.so@verizonbusiness.com
Frederic Jounay
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
EMail: frederic.jounay@orange-ftgroup.com
Chen, et al. Expires January 2, 2010 [Page 14]
Internet-Draft Return Path Specified LSP Ping July 2009
Simon Delord
Telstra
242 Exhibition St
Melbourne VIC 3000
Australia
EMail: simon.a.delord@team.telstra.com
Chen, et al. Expires January 2, 2010 [Page 15]