draft-ietf-mpls-p2mp-lsp-ping-10.txt   draft-ietf-mpls-p2mp-lsp-ping-11.txt 
Network Working Group S. Saxena, Ed. Network Working Group S. Saxena, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended Status: Standards Track A. Farrel Intended Status: Standards Track A. Farrel
Updates: 4379 (if approved) Old Dog Consulting Updates: 4379 (if approved) Old Dog Consulting
Created: March 07, 2010 S. Yasukawa Created: October 08, 2010 S. Yasukawa
Expires: Septemeber 07, 2010 NTT Corporation Expires: April 08, 2010 NTT Corporation
Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol
Label Switching (MPLS) - Extensions to LSP Ping Label Switching (MPLS) - Extensions to LSP Ping
draft-ietf-mpls-p2mp-lsp-ping-10.txt draft-ietf-mpls-p2mp-lsp-ping-11.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 21 skipping to change at page 2, line 21
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Contents Contents
1. Introduction.................................................... 5 1. Introduction.................................................... 5
1.1. Design Considerations......................................... 6 1.1. Design Considerations......................................... 6
2. Notes on Motivation............................................. 6 2. Notes on Motivation............................................. 6
2.1. Basic Motivations for LSP Ping................................ 6 2.1. Basic Motivations for LSP Ping................................ 7
2.2. Motivations for LSP Ping for P2MP LSPs........................ 7 2.2. Motivations for LSP Ping for P2MP LSPs........................ 7
3. Packet Format................................................... 9 3. Packet Format................................................... 9
3.1. Identifying the LSP Under Test................................ 9 3.1. Identifying the LSP Under Test................................ 9
3.1.1. Identifying a P2MP MPLS TE LSP.............................. 9 3.1.1. Identifying a P2MP MPLS TE LSP.............................. 9
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV............................ 9 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV........................... 10
3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV........................... 10 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV........................... 10
3.1.2. Identifying a Multicast LDP LSP............................ 11 3.1.2. Identifying a Multicast LDP LSP............................ 11
3.1.2.1. Multicast LDP FEC Stack Sub-TLVs......................... 11 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs......................... 11
3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 12 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 13
3.2. Limiting the Scope of Responses.............................. 13 3.2. Limiting the Scope of Responses.............................. 13
3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs.......... 13 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs.......... 14
3.2.2. Node Address P2MP Responder Identifier Sub-TLVs............ 14 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs............ 14
3.3. Preventing Congestion of Echo Responses...................... 14 3.3. Preventing Congestion of Echo Responses...................... 14
3.4. Respond Only If TTL Expired Flag............................. 15 3.4. Respond Only If TTL Expired Flag............................. 15
3.5. Downstream Detailed Mapping TLV.............................. 15 3.5. Downstream Detailed Mapping TLV.............................. 16
4. Operation of LSP Ping for a P2MP LSP........................... 16 4. Operation of LSP Ping for a P2MP LSP........................... 16
4.1. Initiating Router Operations................................. 16 4.1. Initiating Router Operations................................. 16
4.1.1. Limiting Responses to Echo Requests........................ 16 4.1.1. Limiting Responses to Echo Requests........................ 17
4.1.2. Jittered Responses to Echo Requests........................ 17 4.1.2. Jittered Responses to Echo Requests........................ 17
4.2. Responding Router Operations................................. 18 4.2. Responding Router Operations................................. 18
4.2.1. Echo Response Reporting.................................... 18 4.2.1. Echo Response Reporting.................................... 19
4.2.1.1. Responses from Transit and Branch nodes.................. 19 4.2.1.1. Responses from Transit and Branch nodes.................. 19
4.2.1.2. Responses from Egress Nodes.............................. 20 4.2.1.2. Responses from Egress Nodes.............................. 20
4.2.1.3. Responses from Bud Nodes................................. 20 4.2.1.3. Responses from Bud Nodes................................. 20
4.3. Special Considerations for Traceroute........................ 22 4.3. Special Considerations for Traceroute........................ 22
4.3.1. End of Processing for Traceroutes.......................... 22 4.3.1. End of Processing for Traceroutes.......................... 22
4.3.2. Multiple responses from Bud and Egress Nodes............... 22 4.3.2. Multiple responses from Bud and Egress Nodes............... 23
4.3.3. Non-Response to Traceroute Echo Requests................... 23 4.3.3. Non-Response to Traceroute Echo Requests................... 23
4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 23 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 23
5. Non-compliant Routers.......................................... 23 4.3.5 Cross Over Node Processing.................................. 24
6. OAM Considerations............................................. 24 5. Non-compliant Routers.......................................... 24
7. IANA Considerations............................................ 24 6. OAM Considerations............................................. 25
7.1. New Sub-TLV Types............................................ 24 7. IANA Considerations............................................ 25
7.2. New TLVs..................................................... 25 7.1. New Sub-TLV Types............................................ 25
8. Security Considerations........................................ 25 7.2. New TLVs..................................................... 26
9. Acknowledgements............................................... 25 8. Security Considerations........................................ 26
9. Acknowledgements............................................... 26
10. References.................................................... 26 10. References.................................................... 26
10.1. Normative References........................................ 26 10.1. Normative References........................................ 27
10.2. Informative References...................................... 26 10.2. Informative References...................................... 27
11. Authors' Addresses............................................ 27 11. Authors' Addresses............................................ 28
12. Full Copyright Statement...................................... 28 12. Full Copyright Statement...................................... 28
0. Change Log 0. Change Log
This section to be removed before publication as an RFC. This section to be removed before publication as an RFC.
0.1 Changes from 00 to 01 0.1 Changes from 00 to 01
- Update references. - Update references.
- Fix boilerplate. - Fix boilerplate.
skipping to change at page 5, line 26 skipping to change at page 5, line 28
merged. merged.
- Added a Respond if TTL Expired Flag. - Added a Respond if TTL Expired Flag.
- Removed reference to [MCAST-CV]. - Removed reference to [MCAST-CV].
0.10 Changes from 09 to 10 0.10 Changes from 09 to 10
- Removed references to bootstrapping other OAM protocols. This draft - Removed references to bootstrapping other OAM protocols. This draft
does not provide any details of such methods. Hence it is cleaner does not provide any details of such methods. Hence it is cleaner
to remove such references. to remove such references.
- Minor edits based on comments. - Minor edits based on comments.
0.11 Changes from 10 to 11
- Updated behavior of T bit when no label is present.
- Clarified that Egress Address TLV is not applicable to tracing in
Multicast LDP trees.
- Changed expected processing at bud nodes upon receipt of Node
Address Responder Identifier TLV from egress node only to
combination of egress and branch node.
- Added details on how Downstream Detailed Mapping TLV should be
filled for cross-over node scenario.
- Various edits based on comments.
1. Introduction 1. Introduction
Simple and efficient mechanisms that can be used to detect data plane Simple and efficient mechanisms that can be used to detect data plane
failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS)
Label Switched Paths (LSP) are described in [RFC4379]. The Label Switched Paths (LSP) are described in [RFC4379]. The
techniques involve information carried in MPLS "Echo Request" and techniques involve information carried in MPLS "Echo Request" and
"Echo Reply" messages, and mechanisms for transporting them. The "Echo Reply" messages, and mechanisms for transporting them. The
echo request and reply messages provide sufficient information to echo request and reply messages provide sufficient information to
check correct operation of the data plane, as well as a mechanism to check correct operation of the data plane, as well as a mechanism to
verify the data plane against the control plane, and thereby localize verify the data plane against the control plane, and thereby localize
skipping to change at page 13, line 52 skipping to change at page 14, line 14
The content of these Sub-TLVs are defined in the following sections. The content of these Sub-TLVs are defined in the following sections.
Also defined is the intended behavior of the responding node upon Also defined is the intended behavior of the responding node upon
receiving any of these Sub-TLVs. receiving any of these Sub-TLVs.
3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs
The IPv4 or IPv6 Egress Address P2MP Responder Identifier Sub-TLVs The IPv4 or IPv6 Egress Address P2MP Responder Identifier Sub-TLVs
MAY be used in an echo request carrying RSVP P2MP Session Sub-TLV. MAY be used in an echo request carrying RSVP P2MP Session Sub-TLV.
They SHOULD NOT be used with an echo request carrying Multicast LDP They SHOULD NOT be used with an echo request carrying Multicast LDP
FEC Stack Sub-TLV. FEC Stack Sub-TLV. If a node receives these TLVs in an echo request
carrying Multicast LDP then it SHOULD ignore these sub-TLVs and
respond as if they are not present. Hence these TLVs cannot be used
to traceroute to a single node when Multicast LDP FEC is used.
A node that receives an echo request with this Sub-TLV present MUST A node that receives an echo request with this Sub-TLV present MUST
respond only if the node lies on the path to the address in the respond only if the node lies on the path to the address in the
Sub-TLV. Sub-TLV.
The address in this Sub-TLV SHOULD be of an egress or bud node and The address in this Sub-TLV SHOULD be of an egress or bud node and
SHOULD NOT be of a transit or branch node. A transit or branch node, SHOULD NOT be of a transit or branch node. A transit or branch node,
should be able to determine if the address in this Sub-TLV is for an should be able to determine if the address in this Sub-TLV is for an
egress or bud node which is reachable through it. Hence, this egress or bud node which is reachable through it. Hence, this
address SHOULD be known to the nodes upstream of the target node, for address SHOULD be known to the nodes upstream of the target node, for
skipping to change at page 15, line 29 skipping to change at page 15, line 42
format of the Global Flags field is: format of the Global Flags field is:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |T|V| | MBZ |T|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The V flag is described in [RFC4379]. The V flag is described in [RFC4379].
The T (TTL Expired) flag SHOULD be set only in the echo request The T (Respond Only If TTL Expired) flag SHOULD be set only in the
packet by the sender. This flag SHOULD NOT be set in the echo reply echo request packet by the sender. This flag SHOULD NOT be set in
packet. If this flag is set in an echo reply packet, then it MUST be the echo reply packet. If this flag is set in an echo reply packet,
ignored. then it MUST be ignored.
If the T flag is set to 1, then the reciever SHOULD reply only if the If the T flag is set to 1, then the reciever SHOULD reply only if the
TTL of the incoming MPLS label is equal to 1; if the TTL is more than TTL of the incoming MPLS label is equal to 1; if the TTL is more than
1, then no response should be sent back. If the T flag is set to 0, 1, then no response should be sent back. If there is no incoming
then the receiver SHOULD reply as per regular processing. MPLS label on the echo request packet, then this bit SHOULD be
ignored.
If the T flag is set to 0, then the receiver SHOULD reply as per
regular processing.
3.5. Downstream Detailed Mapping TLV 3.5. Downstream Detailed Mapping TLV
Downstream Detailed Mapping TLV is described in [DDMT]. A transit, Downstream Detailed Mapping TLV is described in [DDMT]. A transit,
branch or bud node can use the Downstream Detailed Mapping TLV to branch or bud node can use the Downstream Detailed Mapping TLV to
return multiple Return Codes for different downstream paths. This return multiple Return Codes for different downstream paths. This
functionality can not be achieved via the Downstream Mapping TLV. As functionality can not be achieved via the Downstream Mapping TLV. As
per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in
[RFC4379] is being deprecated. [RFC4379] is being deprecated.
Therefore for P2MP, a node MUST support Downstream Detailed Mapping Therefore for P2MP, a node MUST support Downstream Detailed Mapping
TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP
traceroute functionality and SHOULD NOT be included in an Echo Request traceroute functionality and SHOULD NOT be included in an Echo Request
message. When responding to an RSVP IPv4/IPv6 P2MP Session FEC Type message. When responding to an RSVP IPv4/IPv6 P2MP Session FEC Type
or a Multicast P2MP/MP2MP LDP FEC Type, a node MUST ignore any or a Multicast P2MP/MP2MP LDP FEC Type, a node MUST ignore any
Downstream Mapping TLV it receives in the echo request. Downstream Mapping TLV it receives in the echo request and MUST
continue processing as if the Downstream Mapping TLV is not present.
The details of the Return Codes to be used in the Downstream Detailed The details of the Return Codes to be used in the Downstream Detailed
Mapping TLV are provided in section 4. Mapping TLV are provided in section 4.
4. Operation of LSP Ping for a P2MP LSP 4. Operation of LSP Ping for a P2MP LSP
This section describes how LSP Ping is applied to P2MP MPLS LSPs. As This section describes how LSP Ping is applied to P2MP MPLS LSPs. As
mentioned previously, an important design consideration has been to mentioned previously, an important design consideration has been to
extend existing LSP Ping mechanism in [RFC4379] rather than invent extend existing LSP Ping mechanism in [RFC4379] rather than invent
new mechanisms. new mechanisms.
skipping to change at page 20, line 44 skipping to change at page 21, line 9
Node behavior guidelines: Node behavior guidelines:
- If the Responder Identifier TLV is not present, then the node - If the Responder Identifier TLV is not present, then the node
will behave as a combination egress and branch node. will behave as a combination egress and branch node.
- If the Responder Identifier TLV containing a Node Address - If the Responder Identifier TLV containing a Node Address
sub-TLV is present, and: sub-TLV is present, and:
- If the address specified in the sub-TLV matches to an address - If the address specified in the sub-TLV matches to an address
in the node, then the node will behave like an egress node in the node, then the node will behave like an combination
only. egress and branch node.
- If the address specified in the sub-TLV does not match any - If the address specified in the sub-TLV does not match any
address in the node, then no response will be sent. address in the node, then no response will be sent.
- If the Responder Identifier TLV containing an Egress Address - If the Responder Identifier TLV containing an Egress Address
sub-TLV is present, and: sub-TLV is present, and:
- If the address specified in the sub-TLV matches to an address - If the address specified in the sub-TLV matches to an address
in the node, then the node will behave like an egress node in the node, then the node will behave like an egress node
only. only.
skipping to change at page 23, line 7 skipping to change at page 23, line 22
requests, these bud and egress nodes will keep on responding to the requests, these bud and egress nodes will keep on responding to the
traceroute echo requests. This can cause extra processing burden for traceroute echo requests. This can cause extra processing burden for
the initiating router and these bud or egress routers. the initiating router and these bud or egress routers.
To prevent a bud or egress node from sending multiple responses in To prevent a bud or egress node from sending multiple responses in
the same traceroute operation, a new "Respond Only If TTL Expired" the same traceroute operation, a new "Respond Only If TTL Expired"
flag is being introduced. This flag is described in Section 3.4. flag is being introduced. This flag is described in Section 3.4.
It is RECOMMENDED that this flag be used for P2MP traceroute mode It is RECOMMENDED that this flag be used for P2MP traceroute mode
only. By using this flag, extraneous responses from bud and egress only. By using this flag, extraneous responses from bud and egress
nodes can be reduced. nodes can be reduced. If PHP is being used in the P2MP tree, then
bud and egress nodes will not get any labels with the echo request
packet. Hence this mechanism will not be effective for PHP scenario.
4.3.3. Non-Response to Traceroute Echo Requests 4.3.3. Non-Response to Traceroute Echo Requests
There are multiple reasons for which an ingress node may not receive There are multiple reasons for which an ingress node may not receive
a response to its echo request. For example, the transit node has a response to its echo request. For example, the transit node has
failed, or the transit node does not support LSP Ping. failed, or the transit node does not support LSP Ping.
When no response to an echo request is received by the ingress, then When no response to an echo request is received by the ingress, then
as per [RFC4379] the subsequent echo request with a larger TTL SHOULD as per [RFC4379] the subsequent echo request with a larger TTL SHOULD
be sent. be sent.
skipping to change at page 23, line 41 skipping to change at page 24, line 10
If an Egress Address Responder Identifier sub-TLV is being used, then If an Egress Address Responder Identifier sub-TLV is being used, then
the traceroute is limited to only one path to one egress. Therefore the traceroute is limited to only one path to one egress. Therefore
this traceroute is effectively behaving like a P2P traceroute. In this traceroute is effectively behaving like a P2P traceroute. In
this scenario, as per section 4.2, the echo responses from this scenario, as per section 4.2, the echo responses from
intermediate nodes will contain only one Downstream Detailed Mapping intermediate nodes will contain only one Downstream Detailed Mapping
TLV corresponding to the downstream path required to reach the TLV corresponding to the downstream path required to reach the
address specified in the Egress Address sub-TLV. For this case, the address specified in the Egress Address sub-TLV. For this case, the
echo request packet MAY reuse a received Downstream Detailed Mapping echo request packet MAY reuse a received Downstream Detailed Mapping
TLV. TLV.
4.3.5 Cross Over Node Processing
A cross-over nodes will require slightly different processing for
traceroute mode. The following definition of cross-over is taken from
[RFC4875].
The term "cross-over" refers to the case of an ingress or transit
node that creates a branch of a P2MP LSP, a cross-over branch, that
intersects the P2MP LSP at another node farther down the tree. It
is unlike re-merge in that, at the intersecting node, the
cross-over branch has a different outgoing interface as well as a
different incoming interface.
During traceroute, a cross-over node will receive the echo requests
via each of its input interfaces. Therefore the Downstream Detailed
Mapping TLV in the echo response SHOULD carry information only about
the outgoing interface corresponding to the input interface.
Due to this restriction, the cross-over node will not duplicate the
outgoing interface information in each of the echo request it
receives via the different input interfaces. This will reflect the
actual packet replication in the data plane.
5. Non-compliant Routers 5. Non-compliant Routers
If a node for a P2MP LSP does not support MPLS LSP ping, then no If a node for a P2MP LSP does not support MPLS LSP ping, then no
reply will be sent, resulting in a "false negative" result. There is reply will be sent, resulting in a "false negative" result. There is
no protection for this situation, and operators may wish to ensure no protection for this situation, and operators may wish to ensure
that all nodes for P2MP LSPs are all equally capable of supporting that all nodes for P2MP LSPs are all equally capable of supporting
this function. this function.
If the non-compliant node is an egress, then the traceroute mode can If the non-compliant node is an egress, then the traceroute mode can
be used to verify the LSP nearly all the way to the egress, leaving be used to verify the LSP nearly all the way to the egress, leaving
 End of changes. 20 change blocks. 
32 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/