draft-ietf-mpls-return-path-specified-lsp-ping-05.txt   draft-ietf-mpls-return-path-specified-lsp-ping-06.txt 
Network Working Group M. Chen Network Working Group M. Chen
Internet-Draft W. Cao Internet-Draft W. Cao
Intended status: Standards Track Huawei Technologies Co., Ltd Intended status: Standards Track Huawei Technologies Co., Ltd
Expires: January 3, 2013 S. Ning Expires: February 2, 2013 S. Ning
Tata Communications Tata Communications
F. Jounay F. Jounay
Orange CH Orange CH
S. Delord S. Delord
Alcatel-Lucent Alcatel-Lucent
July 2, 2012 August 1, 2012
Return Path Specified LSP Ping Return Path Specified LSP Ping
draft-ietf-mpls-return-path-specified-lsp-ping-05.txt draft-ietf-mpls-return-path-specified-lsp-ping-06.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 robustness. It may also be used by Bidirectional Forwarding
Detection (BFD) for MPLS bootstrap signaling thereby making BFD for Detection (BFD) for MPLS bootstrap signaling thereby making BFD for
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2013. This Internet-Draft will expire on February 2, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 47 skipping to change at page 2, line 47
4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 13 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 13
4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 14 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 14
4.3. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 15 4.3. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 15
4.4. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 15 4.4. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.1. New Sub-TLVs . . . . . . . . . . . . . . . . . . . . . 17 6.2.1. New Sub-TLVs . . . . . . . . . . . . . . . . . . . . . 17
6.2.2. New Reply Mode . . . . . . . . . . . . . . . . . . . . 17 6.2.2. New Reply Mode . . . . . . . . . . . . . . . . . . . . 17
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. Reply Path Return Code . . . . . . . . . . . . . . . . . . 17
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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)[RFC5880], [RFC5884]session for a bidirectional LSP or for a (BFD)[RFC5880], [RFC5884]session for a bidirectional LSP or for a
pair of unidirectional LSPs (one for each direction). pair of unidirectional LSPs (one for each direction).
skipping to change at page 6, line 32 skipping to change at page 6, line 32
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 LSP being tested which indicates which MPLS path
being verified, along the same data path as other normal data packets is being verified, along the same data path as other normal data
belonging to the FEC. 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, a new TLV, the Reply Path TLV, is defined in this In addition, a new TLV, the Reply Path TLV, is defined in this
document. The Reply Path TLV contains one nested sub-TLV that can be document. The Reply Path TLV contains one nested sub-TLV 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 request that the remote
receiving the LSP Ping echo request message to send back the echo LSR receiving the LSP Ping echo request message sends 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 an optional TLV, if the Reply via
message. It carries the specified return paths that the echo reply Specified Path mode requested, the Reply Path (RP) TLV MUST be
message is required to follow. The format of Reply Path TLV is as included in an echo request message. It carries the specified return
follows: paths that the echo reply message is required to follow. The format
of Reply Path 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 | Flag | | Reply Path return code | Flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Paths | | Reply Paths |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure3 IPv6 PSN Tunnel sub-TLV format Figure 1 Reply Path TLV
Reply Path TLV Type field is 2 octets in length, and the type value Reply Path TLV Type field is 2 octets in length, and the type value
is TBD by IANA. is TBD by 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 Reply Path return code, Flag and Reply Paths fields. octets of the Reply Path return code, Flag and Reply Paths fields.
Reply Path return code is 2 octets in length. It is defined for the Reply Path return code is 2 octets in length. It is defined for the
egress LSR of the forward LSP to report the results of Reply Path TLV egress LSR of the forward LSP to report the results of Reply Path TLV
processing and return path selection. When sending echo request, processing and return path selection. When sending echo request,
these codes MUST be set to zero. Reply Path return code only used these codes MUST be set to zero. Reply Path return code only used
when sending echo reply, and it MUST be ignored when processing echo when sending echo reply, and it MUST be ignored when processing echo
request message. This document defines the following Reply Path request message. This document defines the following Reply Path
return codes: return codes:
Value Meaning Value Meaning
0 No return code ------ ----------------------
1 Malformed Reply Path TLV was received 0x0000 No return code
2 One or more of the sub-TLVs in Reply Path TLV was not understood 0x0001 Malformed Reply Path TLV was received
3 The echo reply was sent successfully using the specified Reply Path 0x0002 One or more of the sub-TLVs in Reply Path TLV was not understood
4 The specified Reply Path was not found, the echo reply was sent via 0x0003 The echo reply was sent successfully using the specified Reply Path
other LSP 0x0004 The specified Reply Path was not found, the echo reply was sent via
5 The specified Reply Path was not found, the echo reply was sent via other LSP
IP path 0x0005 The specified Reply Path was not found, the echo reply was sent via
6 The Reply mode in echo request was not set to 5(replay via IP path
specified path) although Reply Path TLV exists 0x0006 The Reply mode in echo request was not set to 5(Reply via
7 Reply Path TLV was missing in echo request Specified Path) although Reply Path TLV exists
0x0007 Reply Path TLV was missing in echo request
0x0008-0xffff Reserved
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| | MUST be zero |A|B|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 forced to follow a non-default return path. Here, the default path
is no need to carry any specific reply path sub-TLVs, and when refers to the path that the egress LSR will use to send the echo
received, the sub-TLVs SHOULD be ignored.. reply when the return path is not explicitly specified as defined in
this document. 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 ignored.
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. If B bit is set, there is direction of the tested bidirectional LSP. If B bit is set, there is
no need to carry any specific reply path sub-TLVs, and when received, no need to carry any specific reply path sub-TLVs, and when received,
the sub-TLVs SHOULD be ignored. the sub-TLVs SHOULD be ignored.
The A bit and B bit set MUST NOT both be set, otherwise, an echo The A bit and B bit set MUST NOT both be set, otherwise, an echo
reply with the RP return code set to "Malformed RP TLV was received" reply with the RP return code set to "Malformed RP TLV was received"
SHOULD be returned. SHOULD be returned.
The Reply Paths field is variable in length, only one sub-TLV SHOULD The Reply Paths field is variable in length, not more than one sub-
be carried, which describes the specified path that the echo reply TLV MUST be carried, which describes the specified path that the echo
message is required to follow. When the Reply Mode field is set to reply message is required to follow. When the Reply Mode field is
"Reply via specified path" in an LSP echo request message, the Reply set to "Reply via Specified Path" in an LSP echo request message, the
Path TLV MUST be present. Reply Path TLV MUST be present.
3.3. Reply Path sub-TLVs 3.3. Reply Path sub-TLVs
Each of the FEC sub-TLVs for the Target FEC Stack TLV[RFC4379] is Each of the FEC sub-TLVs for the Target FEC Stack TLV[RFC4379] is
applicable to be a sub-TLV for inclusion in the Reply Path TLV for applicable to be a sub-TLV for inclusion in the Reply Path TLV for
expressing a specific return path. expressing 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 Static Tunnel sub-TLV. sub-TLV, IPv6 RSVP Tunnel sub-TLV and Static Tunnel sub-TLV.
Detailed definition is in the following sections. Detailed definition is in the following sections.
skipping to change at page 10, line 18 skipping to change at page 10, line 18
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 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 [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
skipping to change at page 11, line 28 skipping to change at page 11, line 29
| Extended Tunnel ID | | Extended Tunnel ID |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address | | IPv6 tunnel sender address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 IPv6 RSVP Tunnel sub-TLV
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 type value is TBD. the type value is TBD.
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
skipping to change at page 12, line 10 skipping to change at page 12, line 10
the egress LSR will then choose an LSP from the specified Tunnel as the egress LSR will then choose an LSP from the specified Tunnel as
the return path. The format of Static RSVP Tunnel sub-TLV is as the return path. The format of Static RSVP Tunnel sub-TLV is as
follows. The value fields are taken from the definitions in follows. The value fields are taken from the definitions in
[RFC6370]. [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 Gloabl ID | | Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID | | Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Gloabl ID | | Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID | | Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Num | Destination Tunnel Num | | Source Tunnel Num | Destination Tunnel Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flag | Must Be Zero | | Flag | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Static Tunnel sub-TLV
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.1. described in Section 3.3.1.
3.4. Reply TC TLV 3.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
skipping to change at page 13, line 13 skipping to change at page 13, line 13
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 "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) which 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, this of course cuts in half the operational steps
required to verify the end to end bidirectional connectivity and required to verify the end to end bidirectional connectivity and
integrity of an LSP. 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(when the A bit is not set in the previous received echo request path(when the A bit is not set in the previous received echo request
skipping to change at page 13, line 40 skipping to change at page 13, line 40
set to 255. Of course when the echo reply message is not intended set to 255. Of course when the echo reply message is not intended
for testing the specified return path (when the A bit is set in the for testing the specified return path (when the A bit is set in the
previous received echo request message) , the procedures defined in previous received echo request message) , the procedures defined in
[RFC4379] (the destination IP address is copied from the source IP [RFC4379] (the destination IP address is copied from the source IP
address) apply unchanged. 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 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 different path other than the reverse direction of the
bidirectional LSP, the "A" bit SHOULD be set or another FEC sub-TLV bidirectional LSP, the "A" bit SHOULD be set or another FEC sub-TLV
skipping to change at page 15, line 13 skipping to change at page 15, line 13
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 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 echo reply is intended to test the return path (the A is not When the echo reply is intended to test the return path (the A is not
set in the previous received echo request), the destination IP set in the previous received echo request), the destination IP
address of the echo reply message MUST never be used in a forwarding address of the echo reply message MUST never be used in a forwarding
decision. To avoid this problem, the IP destination address of the decision. To avoid this problem, the IP destination address of the
echo reply message that is transmitted along the specified return echo reply message that is transmitted along the specified return
path MUST be set to numbers from the range 127/8 for IPv4 or 0:0:0:0: 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 to 1, the TTL in 0:FFFF:127/104 for IPv6, and the IP TTL MUST be set to 1, the TTL in
the outermost label MUST be set to 255. Otherwise, the same as the outermost label MUST be set to 255. Otherwise, the same as
skipping to change at page 15, line 43 skipping to change at page 15, line 43
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 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 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 retun path", and if the A bit sent successfully using the specified retun path", and if the A bit
is not set. The ingress LSR MUST perform FEC validation (based on is not set. The ingress LSR MUST perform FEC validation (based on
the FEC stack information of the return path carried in the Reply the FEC stack information of the return path carried in the Reply
Path TLV) as an egress LSR does when receiving an echo request, the Path TLV) as an egress LSR does when receiving an echo request, the
FEC validation process (relevant to "ping" mode) defined in Section FEC validation process (relevant to "ping" mode) defined in Section
4.4.1 of [RFC4379] applies here. 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.
5. Security Considerations 5. Security Considerations
skipping to change at page 16, line 49 skipping to change at page 16, line 49
----- ------- --------- ----- ------- ---------
21 Reply Path TLV this document (sect 3.2) 21 Reply Path TLV this document (sect 3.2)
TBD Reply TC TLV this document (sect 3.4) TBD Reply TC TLV this document (sect 3.4)
6.2. Sub-TLVs 6.2. Sub-TLVs
Reply Path TLV is designed to share the existing and any future new Reply Path TLV is designed to share the existing and any future new
defiend sub-TLVs of the Target FEC Stack TLV. At the same time, defiend sub-TLVs of the Target FEC Stack TLV. At the same time,
Reply Path TLV will define its own dedicated sub-TLV(see Section Reply Path TLV will define its own dedicated sub-TLV(see Section
3.3.1, 3.3.2 and 3.3.3). Reply Path TLV has its own sub-TLV space, 3.3.1, 3.3.2 and 3.3.3). Reply Path TLV has its own sub-TLV space,
but for those shared sub-TLVs, the sub-TLV assignment for Reply Path but for those shared sub-TLVs, the assignment MUST be kept the same
TLV MUST be kept the same as for Target FEC Stack TLV. For the as for those sub-TLVs of Target FEC Stack TLV. So, the sub-TLV range
dedicated sub-TLVs to Reply Path TLV, they MUST be asssigned from the of Reply Path TLV are partitioned as following:
range of 31744-32767(this range, for the Target FEC Stack TLV, is
left for "Vendor Private Use", hence it will not be assigned to any 0-31743 - This range MUST be kept as the same as Target FEC Stack TLV
standards sub-TLVs, so for Reply Path TLV, this range can be safely and sub-TLVs[RFC4379].
assigned to its own dedicated sub-TLVs).
31744-32767 - Standards Action;
32768-64511 - This range MUST be kept as the same as Target FEC Stack
TLV and sub-TLVs [RFC4379].
64512-65535 - Standards Action.
6.2.1. 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). As explained above, the registry for the Reply Path TLV (Type 21). As explained above, the
following sub-type MUST be assigned from the range of 31744-32767. following sub-type MUST be assigned from the range of 31744-32767 or
64512-65535.
Sub-type Value Field Reference Sub-type Value Field Reference
------- ----------- --------- ------- ----------- ---------
TBD IPv4 RSVP Tunnel this document (sect 3.3.1) TBD IPv4 RSVP Tunnel this document (sect 3.3.1)
TBD IPv6 RSVP Tunnel this document (sect 3.3.2) TBD IPv6 RSVP Tunnel this document (sect 3.3.2)
TBD Static Tunnel this document (sect 3.3.3) TBD Static Tunnel this document (sect 3.3.3)
6.2.2. New Reply Mode 6.2.2. New Reply Mode
IANA is requested to assign a new reply mode code point from the IANA is requested to assign a new reply mode code point from the
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Parameters" registry, the "Reply Mode" subregistry. 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)
6.3. Reply Path Return Code
IANA is requested to create a new registry for Reply Path return
code.
This document (Section 3.2) defines the following return codes:
Value Meaning Reference
------ ---------------------- --------------
0x0000 No return code this document
0x0001 Malformed Reply Path TLV was received this document
0x0002 One or more of the sub-TLVs in Reply Path TLV was not understood this document
0x0003 The echo reply was sent successfully using the specified Reply Path this document
0x0004 The specified Reply Path was not found, the echo reply was sent via
other LSP this document
0x0005 The specified Reply Path was not found, the echo reply was sent via
IP path this document
0x0006 The Reply mode in echo request was not set to 5(replay via
specified path) although Reply Path TLV exists this document
0x0007 Reply Path TLV was missing in echo request this document
0x0008-0xffff Reserved
The range of 0x0008-0xffff are reserved for future extensions.
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
Xinchun Guo Xinchun Guo
EMail: guoxinchun@huawei.com EMail: guoxinchun@huawei.com
8. Acknowledgements 8. 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 and Tom Petch for their review, suggestion and Sriganesh Kini, Gregory Mirsky and Tom Petch for their review,
comments to this document. suggestion and comments to this document.
9. References 9. References
9.1. Normative References 9.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
 End of changes. 36 change blocks. 
66 lines changed or deleted 101 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/