draft-ietf-mpls-p2mp-lsp-ping-08.txt   draft-ietf-mpls-p2mp-lsp-ping-09.txt 
Network Working Group A. Farrel (Editor) Network Working Group S. Saxena, Ed.
Internet-Draft Old Dog Consulting Internet-Draft Cisco Systems, Inc.
Intended Status: Standards Track S. Yasukawa Intended Status: Standards Track A. Farrel
Updates: RFC4379 NTT Updates: RFC4379 Old Dog Consulting
Created: August 11, 2009 Created: December 14, 2009 S. Yasukawa
Expires: February 11, 2010 Expires: June 14, 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-08.txt draft-ietf-mpls-p2mp-lsp-ping-09.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 1, line 41 skipping to change at page 1, line 41
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Recent proposals have extended the scope of Multiprotocol Label Recent proposals have extended the scope of Multiprotocol Label
Switching (MPLS) Label Switched Paths (LSPs) to encompass Switching (MPLS) Label Switched Paths (LSPs) to encompass
point-to-multipoint (P2MP) LSPs. point-to-multipoint (P2MP) LSPs.
The requirement for a simple and efficient mechanism that can be The requirement for a simple and efficient mechanism that can be used
used to detect data plane failures in point-to-point (P2P) MPLS LSPs to detect data plane failures in point-to-point (P2P) MPLS LSPs has
has been recognized and has led to the development of techniques been recognized and has led to the development of techniques for
for fault detection and isolation commonly referred to as "LSP Ping". fault detection and isolation commonly referred to as "LSP Ping".
The scope of this document is fault detection and isolation for P2MP The scope of this document is fault detection and isolation for P2MP
MPLS LSPs. This documents does not replace any of the mechanisms of MPLS LSPs. This documents does not replace any of the mechanisms of
LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and
extends the techniques and mechanisms of LSP Ping to the MPLS P2MP extends the techniques and mechanisms of LSP Ping to the MPLS P2MP
environment. environment.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
Conventions used in this document Conventions used in this document
skipping to change at page 2, line 4 skipping to change at page 2, line 11
LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and
extends the techniques and mechanisms of LSP Ping to the MPLS P2MP extends the techniques and mechanisms of LSP Ping to the MPLS P2MP
environment. environment.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
Conventions used in this document Conventions used in this document
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.................................................... 4 1. Introduction.................................................. 5
1.1 Design Considerations.......................................... 5 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.............................. 6
2.2. Motivations for LSP Ping for P2MP LSPs........................ 6 2.2. Motivations for LSP Ping for P2MP LSPs...................... 7
2.3 Bootstrapping Other OAM Procedures Using LSP Ping.............. 8 2.3. Bootstrapping Other OAM Procedures Using LSP Ping........... 9
3. Operation of LSP Ping for a P2MP LSP............................ 8 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............................ 9 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV......................... 10
3.1.2. Identifying a Multicast LDP LSP............................ 10 3.1.2. Identifying a Multicast LDP LSP.......................... 11
3.1.2.1. Multicast LDP FEC Stack Sub-TLVs......................... 10 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs....................... 11
3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 11 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs......... 12
3.2. Ping Mode Operation.......................................... 12 3.2. Limiting the Scope of Responses............................ 13
3.2.1. Controlling Responses to LSP Pings......................... 12 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs........ 14
3.2.2. Ping Mode Egress Procedures................................ 12 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs.......... 14
3.2.3. Jittered Responses......................................... 12 3.3. Preventing Congestion of Echo Responses.................... 14
3.2.4. P2MP Responder Identifier TLV and Sub-TLVs................. 13 3.4. Respond Only If TTL Expired Flag........................... 15
3.2.4.1. Egress Address P2MP Responder Identifier Sub-TLVs........ 14 3.5. Downstream Detailed Mapping TLV............................ 15
3.2.4.2. Node Address P2MP Responder Identifier Sub-TLVs.......... 14 4. Operation of LSP Ping for a P2MP LSP......................... 16
3.2.5. Echo Jitter TLV............................................ 15 4.1. Initiating Router Operations............................... 16
3.2.6. Echo Response Reporting.................................... 15 4.1.1. Limiting Responses to Echo Requests...................... 16
3.2.6.1 Ping Responses at Transit and Branch Nodes................ 16 4.1.2. Jittered Responses to Echo Requests...................... 17
3.2.6.2 Ping Responses at Egress and Bud Nodes.................... 16 4.2. Responding Router Operations............................... 18
3.3. Traceroute Mode Operation.................................... 16 4.2.1. Echo Response Reporting.................................. 19
3.3.1. Correlating Traceroute Responses........................... 17 4.2.1.1. Responses from Transit and Branch nodes................ 19
3.3.2. Traceroute Responses at Transit Nodes...................... 18 4.2.1.2. Responses from Egress Nodes............................ 20
3.3.3. Traceroute Responses at Branch Nodes....................... 18 4.2.1.3. Responses from Bud Nodes............................... 20
3.3.4. Traceroute Responses at Egress Nodes....................... 19 4.3. Special Considerations for Traceroute...................... 22
3.3.5. Traceroute Responses at Bud Nodes.......................... 19 4.3.1. End of Processing for Traceroutes........................ 22
3.3.6. Non-Response to Traceroute Echo Requests................... 20 4.3.2. Multiple responses from Bud and Egress Nodes............. 22
3.3.7 Use of Downstream Detailed Mapping TLV in Echo Request...... 20 4.3.3. Non-Response to Traceroute Echo Requests................. 23
4. Non-compliant Routers.......................................... 20 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request... 23
5. OAM Considerations............................................. 20 5. Non-compliant Routers........................................ 23
6. IANA Considerations............................................ 21 6. OAM Considerations........................................... 24
6.1. New Sub-TLV Types............................................ 21 7. IANA Considerations.......................................... 24
6.2. New TLVs..................................................... 21 7.1. New Sub-TLV Types.......................................... 25
7. Security Considerations........................................ 22 7.2. New TLVs................................................... 25
8. Acknowledgements............................................... 22 8. Security Considerations...................................... 25
9. References..................................................... 23 9. Acknowledgements............................................. 25
9.1 Normative References.......................................... 23 10. References.................................................. 26
9.2 Informative References........................................ 23 10.1. Normative References...................................... 26
10. Authors' Addresses............................................ 24 10.2. Informative References.................................... 26
11. Full Copyright Statement...................................... 25 11. Authors' Addresses.......................................... 27
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 4, line 40 skipping to change at page 5, line 4
- Section 11: Add reference draft-ietf-mpls-lsp-ping-enhanced-dsmap. - Section 11: Add reference draft-ietf-mpls-lsp-ping-enhanced-dsmap.
- Section 13: Update Bill Fenner's coordinates. - Section 13: Update Bill Fenner's coordinates.
0.8 Changes from 07 to 08 0.8 Changes from 07 to 08
- Removed the Node Properties TLV (Section 3.3.2.1 of version 07). - Removed the Node Properties TLV (Section 3.3.2.1 of version 07).
- Removed the New Multipath Type from Multipath Sub-TLV (Section - Removed the New Multipath Type from Multipath Sub-TLV (Section
3.3.5 of version 07). 3.3.5 of version 07).
- Removed the Return Code Sub-TLV from Downstream Detailed TLV - Removed the Return Code Sub-TLV from Downstream Detailed TLV
(Section 3.3.6.1 of version 07), as it is already included in (Section 3.3.6.1 of version 07), as it is already included in
draft-ietf-mpls-lsp-ping-enhanced-dsmap-02. draft-ietf-mpls-lsp-ping-enhanced-dsmap-02.
- Clarified the behavior of Responder Identifier TLV (Section - Clarified the behavior of Responder Identifier TLV (Section
3.2.4 of version 07). Two new Sub-TLVs are introduced. 3.2.4 of version 07). Two new Sub-TLVs are introduced.
- Downstream Detailed Mapping TLV is now mandatory for implementing - Downstream Detailed Mapping TLV is now mandatory for implementing
P2MP OAM functionality. P2MP OAM functionality.
- Split Multicast LDP TLV into two TLVs, one for P2MP and other for - Split Multicast LDP TLV into two TLVs, one for P2MP and other for
MP2MP. Also added description to allow MP2MP ping by using this MP2MP. Also added description to allow MP2MP ping by using this
draft. draft.
- Removed Section 4. as it was a duplicate of Section 2.3. - Removed Section 4. as it was a duplicate of Section 2.3.
0.9 Changes from 08 to 09
- Reformatted the document to follow the RFC4379 style. After the
Motivations section is the Packet Format section, followed by the
Operations section. The sections on Ping and Traceroute have been
merged.
- Added a Respond if TTL Expired Flag.
- Removed reference to [MCAST-CV].
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 techniques Label Switched Paths (LSP) are described in [RFC4379]. The
involve information carried in an MPLS "echo request" and "echo techniques involve information carried in MPLS "Echo Request" and
reply", and mechanisms for transporting the echo reply. The echo "Echo Reply" messages, and mechanisms for transporting them. The
request and reply messages provide sufficient information to check echo request and reply messages provide sufficient information to
correct operation of the data plane, as well as a mechanism to verify check correct operation of the data plane, as well as a mechanism to
the data plane against the control plane, and thereby localize verify the data plane against the control plane, and thereby localize
faults. The use of reliable channels for echo reply messages as faults. The use of reliable channels for echo reply messages as
described in [RFC4379] enables more robust fault isolation. This described in [RFC4379] enables more robust fault isolation. This
collection of mechanisms is commonly referred to as "LSP Ping". collection of mechanisms is commonly referred to as "LSP Ping".
The requirements for point-to-multipoint (P2MP) MPLS traffic The requirements for point-to-multipoint (P2MP) MPLS traffic
engineered (TE) LSPs are stated in [RFC4461]. [RFC4875] specifies a engineered (TE) LSPs are stated in [RFC4461]. [RFC4875] specifies a
signaling solution for establishing P2MP MPLS TE LSPs. signaling solution for establishing P2MP MPLS TE LSPs.
The requirements for point-to-multipoint extensions to the Label The requirements for point-to-multipoint extensions to the Label
Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP] Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP]
specifies extensions to LDP for P2MP MPLS. specifies extensions to LDP for P2MP MPLS.
P2MP MPLS LSPs are at least as vulnerable to data plane faults or to P2MP MPLS LSPs are at least as vulnerable to data plane faults or to
discrepancies between the control and data planes as their P2P discrepancies between the control and data planes as their P2P
counterparts. Mechanisms are, therefore, desirable to detect such counterparts. Therefore, mechanisms are needed to detect such data
data plane faults in P2MP MPLS LSPs as described in [RFC4687]. plane faults in P2MP MPLS LSPs as described in [RFC4687].
This document extends the techniques described in [RFC4379] such This document extends the techniques described in [RFC4379] such that
that they may be applied to P2MP MPLS LSPs and so that they can be they may be applied to P2MP MPLS LSPs and so that they can be used to
used to bootstrap other Operations and Management (OAM) procedures bootstrap other Operations and Management (OAM) procedures such as
such as [MCAST-CV]. This document stresses the reuse of existing LSP
Ping mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs
in order to simplify implementation and network operation.
1.1 Design Considerations [MPLS-BFD]. This document stresses the reuse of existing LSP Ping
mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs in
order to simplify implementation and network operation.
1.1. Design Considerations
An important consideration for designing LSP Ping for P2MP MPLS LSPs An important consideration for designing LSP Ping for P2MP MPLS LSPs
is that every attempt is made to use or extend existing mechanisms is that every attempt is made to use or extend existing mechanisms
rather than invent new mechanisms. rather than invent new mechanisms.
As for P2P LSPs, a critical requirement is that the echo request As for P2P LSPs, a critical requirement is that the echo request
messages follow the same data path that normal MPLS packets traverse. messages follow the same data path that normal MPLS packets traverse.
However, it can be seen this notion needs to be extended for P2MP However, it can be seen this notion needs to be extended for P2MP
MPLS LSPs, as in this case an MPLS packet is replicated so that it MPLS LSPs, as in this case an MPLS packet is replicated so that it
arrives at each egress (or leaf) of the P2MP tree. arrives at each egress (or leaf) of the P2MP tree.
MPLS echo requests are meant primarily to validate the data plane, MPLS echo requests are meant primarily to validate the data plane,
and they can then be used to validate data plane state against the and they can then be used to validate data plane state against the
control plane. They may also be used to bootstrap other OAM control plane. They may also be used to bootstrap other OAM
procedures such as [MPLS-BFD] and [MCAST-CV]. As pointed out in procedures such as [MPLS-BFD]. As pointed out in [RFC4379],
[RFC4379], mechanisms to check the liveness, function, and mechanisms to check the liveness, function, and consistency of the
consistency of the control plane are valuable, but such mechanisms control plane are valuable, but such mechanisms are not a feature of
are not a feature of LSP Ping and are not covered in this document. LSP Ping and are not covered in this document.
As is described in [RFC4379], to avoid potential Denial of Service As is described in [RFC4379], to avoid potential Denial of Service
attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to
the control plane. A rate limiter should be applied to the well-known the control plane. A rate limiter should be applied to the
UDP port defined for use by LSP Ping traffic. well-known UDP port defined for use by LSP Ping traffic.
2. Notes on Motivation 2. Notes on Motivation
2.1. Basic Motivations for LSP Ping 2.1. Basic Motivations for LSP Ping
The motivations listed in [RFC4379] are reproduced here for The motivations listed in [RFC4379] are reproduced here for
completeness. completeness.
When an LSP fails to deliver user traffic, the failure cannot always When an LSP fails to deliver user traffic, the failure cannot always
be detected by the MPLS control plane. There is a need to provide a be detected by the MPLS control plane. There is a need to provide a
tool that enables users to detect such traffic "black holes" or tool that enables users to detect such traffic "black holes" or
misrouting within a reasonable period of time. A mechanism to isolate misrouting within a reasonable period of time. A mechanism to
faults is also required. isolate faults is also required.
[RFC4379] describes a mechanism that accomplishes these goals. This [RFC4379] describes a mechanism that accomplishes these goals. This
mechanism is modeled after the ping/traceroute paradigm: ping (ICMP mechanism is modeled after the ping/traceroute paradigm: ping (ICMP
echo request [RFC792]) is used for connectivity checks, and echo request [RFC792]) is used for connectivity checks, and
traceroute is used for hop-by-hop fault localization as well as path traceroute is used for hop-by-hop fault localization as well as path
tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode
for testing MPLS LSPs. for testing MPLS LSPs.
The basic idea as expressed in [RFC4379] is to test that the packets The basic idea as expressed in [RFC4379] is to test that the packets
that belong to a particular Forwarding Equivalence Class (FEC) that belong to a particular Forwarding Equivalence Class (FEC)
actually end their MPLS path on an LSR that is an egress for that actually end their MPLS path on an LSR that is an egress for that
FEC. [RFC4379] achieves this test by sending a packet (called an FEC. [RFC4379] achieves this test by sending a packet (called an
"MPLS echo request") along the same data path as other packets "MPLS echo request") along the same data path as other packets
belonging to this FEC. An MPLS echo request also carries information belonging to this FEC. An MPLS echo request also carries information
about the FEC whose MPLS path is being verified. This echo request is about the FEC whose MPLS path is being verified. This echo request
forwarded just like any other packet belonging to that FEC. In "ping" is forwarded just like any other packet belonging to that FEC. In
mode (basic connectivity check), the packet should reach the end of "ping" mode (basic connectivity check), the packet should reach the
the path, at which point it is sent to the control plane of the end of the path, at which point it is sent to the control plane of
egress LSR, which then verifies that it is indeed an egress for the the egress LSR, which then verifies that it is indeed an egress for
FEC. In "traceroute" mode (fault isolation), the packet is sent to the FEC. In "traceroute" mode (fault isolation), the packet is sent
the control plane of each transit LSR, which performs various checks to the control plane of each transit LSR, which performs various
that it is indeed a transit LSR for this path; this LSR also returns checks that it is indeed a transit LSR for this path; this LSR also
further information that helps to check the control plane against the returns further information that helps to check the control plane
data plane, i.e., that forwarding matches what the routing protocols against the data plane, i.e., that forwarding matches what the
determined as the path. routing protocols determined as the path.
One way these tools can be used is to periodically ping a FEC to One way these tools can be used is to periodically ping a FEC to
ensure connectivity. If the ping fails, one can then initiate a ensure connectivity. If the ping fails, one can then initiate a
traceroute to determine where the fault lies. One can also traceroute to determine where the fault lies. One can also
periodically traceroute FECs to verify that forwarding matches the periodically traceroute FECs to verify that forwarding matches the
control plane; however, this places a greater burden on transit LSRs control plane; however, this places a greater burden on transit LSRs
and should be used with caution. and should be used with caution.
2.2. Motivations for LSP Ping for P2MP LSPs 2.2. Motivations for LSP Ping for P2MP LSPs
As stated in [RFC4687], MPLS has been extended to encompass P2MP As stated in [RFC4687], MPLS has been extended to encompass P2MP
LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and
diagnose control and data plane defects is critical. For operators diagnose control and data plane defects is critical. For operators
deploying services based on P2MP MPLS LSPs, the detection and deploying services based on P2MP MPLS LSPs, the detection and
specification of how to handle those defects is important because specification of how to handle those defects is important because
such defects may affect the fundamentals of an MPLS network, but also such defects may affect the fundamentals of an MPLS network, but also
because they may impact service level specification commitments for because they may impact service level specification commitments for
customers of their network. customers of their network.
P2MP LDP [P2MP-LDP] uses the Label Distribution Protocol to establish P2MP LDP [P2MP-LDP] uses the Label Distribution Protocol to establish
multicast LSPs. These LSPs distribute data from a single source to multicast LSPs. These LSPs distribute data from a single source to
one or more destinations across the network according to the next one or more destinations across the network according to the next
hops indicated by the routing protocols. Each LSP is identified by an hops indicated by the routing protocols. Each LSP is identified by
MPLS multicast FEC. an MPLS multicast FEC.
P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a
single ingress and multiple egresses. The tunnels, built on P2MP single ingress and multiple egresses. The tunnels, built on P2MP
LSPs, are explicitly routed through the network. There is no concept LSPs, are explicitly routed through the network. There is no concept
or applicability of a FEC in the context of a P2MP MPLS TE LSP. or applicability of a FEC in the context of a P2MP MPLS TE LSP.
MPLS packets inserted at the ingress of a P2MP LSP are delivered MPLS packets inserted at the ingress of a P2MP LSP are delivered
equally (barring faults) to all egresses. In consequence, the basic equally (barring faults) to all egresses. In consequence, the basic
idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an
intention to test that packets that enter (at the ingress) a intention to test that packets that enter (at the ingress) a
particular P2MP LSP actually end their MPLS path on the LSRs that are particular P2MP LSP actually end their MPLS path on the LSRs that are
the (intended) egresses for that LSP. The idea may be extended to the (intended) egresses for that LSP. The idea may be extended to
check selectively that such packets reach specific egresses. check selectively that such packets reach specific egresses.
The technique in this document makes this test by sending an LSP Ping The technique in this document makes this test by sending an LSP Ping
echo request message along the same data path as the MPLS packets. An echo request message along the same data path as the MPLS packets.
echo request also carries the identification of the P2MP MPLS LSP An echo request also carries the identification of the P2MP MPLS LSP
(multicast LSP or P2MP TE LSP) that it is testing. The echo request (multicast LSP or P2MP TE LSP) that it is testing. The echo request
is forwarded just as any other packet using that LSP, and so is is forwarded just as any other packet using that LSP, and so is
replicated at branch points of the LSP and should be delivered to all replicated at branch points of the LSP and should be delivered to all
egresses. In "ping" mode (basic connectivity check), the echo request egresses.
should reach the end of the path, at which point it is sent to the
control plane of the egress LSRs, which verify that they are indeed In "ping" mode (basic connectivity check), the echo request should
an egress (leaf) of the P2MP LSP. An echo response message is sent by reach the end of the path, at which point it is sent to the control
an egress to the ingress to confirm the successful receipt (or plane of the egress LSRs, which verify that they are indeed an egress
announce the erroneous arrival) of the echo request. (leaf) of the P2MP LSP. An echo response message is sent by an
egress to the ingress to confirm the successful receipt (or announce
the erroneous arrival) of the echo request.
In "traceroute" mode (fault isolation), the echo request is sent to In "traceroute" mode (fault isolation), the echo request is sent to
the control plane at each transit LSR, and the control plane checks the control plane at each transit LSR, and the control plane checks
that it is indeed a transit LSR for this P2MP MPLS LSP. The transit that it is indeed a transit LSR for this P2MP MPLS LSP. The transit
LSR also returns information on an echo response that helps verify LSR also returns information on an echo response that helps verify
the control plane against the data plane. That is, the information the control plane against the data plane. That is, the information
is used by the ingress to check that the data plane forwarding is used by the ingress to check that the data plane forwarding
matches what is signaled by the control plane. matches what is signaled by the control plane.
P2MP MPLS LSPs may have many egresses, and it is not necessarily the P2MP MPLS LSPs may have many egresses, and it is not necessarily the
intention of the initiator of the ping or traceroute operation to intention of the initiator of the ping or traceroute operation to
collect information about the connectivity or path to all egresses. collect information about the connectivity or path to all egresses.
Indeed, in the event of pinging all egresses of a large P2MP MPLS Indeed, in the event of pinging all egresses of a large P2MP MPLS
LSP, it might be expected that a large number of echo responses would LSP, it might be expected that a large number of echo responses would
arrive at the ingress independently but at approximately the same arrive at the ingress independently but at approximately the same
time. Under some circumstances this might cause congestion at or time. Under some circumstances this might cause congestion at or
around the ingress LSR. Therefore, the procedures described in this around the ingress LSR. The procedures described in this document
document provide a mechanism that allows the responders to randomly provide two mechanisms to control echo responses.
delay (or jitter) their responses so that the chances of swamping the
ingress are reduced.
Further, the procedures in this document allow the initiator to limit
the scope of an LSP Ping echo request (ping or traceroute mode) to
one specific intended egress.
The scalability issues surrounding LSP Ping for P2MP MPLS LSPs may be The first procedure allows the responders to randomly delay (or
addressed by other mechanisms such as [MCAST-CV] that utilize the LSP jitter) their responses so that the chances of swamping the ingress
Ping procedures in this document to provide bootstrapping mechanisms are reduced. The second procedures allows the initiator to limit the
as described in Section 2.3. scope of an LSP Ping echo request (ping or traceroute mode) to one
specific intended egress.
LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure
connectivity to any or all of the egresses. If the ping fails, connectivity to any or all of the egresses. If the ping fails, the
the operator or an automated process can then initiate a traceroute operator or an automated process can then initiate a traceroute to
to determine where the fault is located within the network. A determine where the fault is located within the network. A
traceroute may also be used periodically to verify that data plane traceroute may also be used periodically to verify that data plane
forwarding matches the control plane state; however, this places an forwarding matches the control plane state; however, this places an
increased burden on transit LSRs and should be used infrequently and increased burden on transit LSRs and should be used infrequently and
with caution. with caution.
2.3 Bootstrapping Other OAM Procedures Using LSP Ping 2.3. Bootstrapping Other OAM Procedures Using LSP Ping
[MPLS-BFD] describes a process where LSP Ping [RFC4379] is used to [MPLS-BFD] describes a process where LSP Ping [RFC4379] is used to
bootstrap the Bidirectional Forwarding Detection (BFD) mechanism bootstrap the Bidirectional Forwarding Detection (BFD) mechanism
[BFD] for use to track the liveliness of an MPLS LSP. In particular [BFD] for use to track the liveliness of an MPLS LSP. In particular
BFD can be used to detect a data plane failure in the forwarding BFD can be used to detect a data plane failure in the forwarding path
path of an MPLS LSP. of an MPLS LSP.
Requirements for MPLS P2MP LSPs extend to hundreds or even thousands
of endpoints. If a protocol required explicit acknowledgments to
each probe for connectivity verification, the response load at the
root would be overwhelming.
A more scalable approach to monitoring P2MP LSP connectivity is
described in [MCAST-CV]. It relies on using the MPLS echo request and
echo response messages of LSP Ping [RFC4379] to bootstrap the
monitoring mechanism in a manner similar to [MPLS-BFD]. The actual
monitoring is done using a separate process defined in [MCAST-CV].
Note that while the approach described in [MCAST-CV] was developed in
response to the multicast scalability problem, it can be applied to
P2P LSPs as well.
3. Operation of LSP Ping for a P2MP LSP 3. Packet Format
This section describes how LSP Ping is applied to P2MP MPLS LSPs. The basic structure of the LSP Ping packet remains the same as
It covers the mechanisms and protocol fields applicable to both ping described in [RFC4379]. Some new TLVs and sub-TLVs are required to
mode and traceroute mode. It explains the responsibilities of the support the new functionality. They are described in the following
initiator (ingress), transit nodes, and receivers (egresses). sections.
3.1. Identifying the LSP Under Test 3.1. Identifying the LSP Under Test
3.1.1. Identifying a P2MP MPLS TE LSP 3.1.1. Identifying a P2MP MPLS TE LSP
[RFC4379] defines how an MPLS TE LSP under test may be identified in [RFC4379] defines how an MPLS TE LSP under test may be identified in
an echo request. A Target FEC Stack TLV is used to carry either an an echo request. A Target FEC Stack TLV is used to carry either an
RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV. RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV.
In order to identify the P2MP MPLS TE LSP under test, the echo In order to identify the P2MP MPLS TE LSP under test, the echo
request message MUST carry a Target FEC Stack TLV, and this MUST request message MUST carry a Target FEC Stack TLV, and this MUST
carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4
Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs
carry fields from the RSVP-TE P2MP Session and Sender-Template carry fields from the RSVP-TE P2MP Session and Sender-Template
objects [RFC4875] and so provide sufficient information to uniquely objects [RFC4875] and so provide sufficient information to uniquely
identify the LSP. identify the LSP.
The new sub-TLVs are assigned sub-type identifiers as follows, and The new sub-TLVs are assigned sub-type identifiers as follows, and
are described in the following sections. are described in the following sections.
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
TBD 20 RSVP P2MP IPv4 Session TBD 20 RSVP P2MP IPv4 Session
TBD 56 RSVP P2MP IPv6 Session TBD 56 RSVP P2MP IPv6 Session
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV
The format of the RSVP P2MP IPv4 Session sub-TLV value field is The format of the RSVP P2MP IPv4 Session sub-TLV value field is
specified in the following figure. The value fields are taken from specified in the following figure. The value fields are taken from
the definitions of the P2MP IPv4 LSP Session Object and the P2MP the definitions of the P2MP IPv4 LSP Session Object and the P2MP IPv4
IPv4 Sender-Template Object in [RFC4875]. Note that the Sub-Group Sender-Template Object in [RFC4875]. Note that the Sub-Group ID of
ID of the Sender-Template is not required. the Sender-Template is not required.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID | | P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address | | IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV
The format of the RSVP P2MP IPv6 Session sub-TLV value field is The format of the RSVP P2MP IPv6 Session sub-TLV value field is
specified in the following figure. The value fields are taken from specified in the following figure. The value fields are taken from
the definitions of the P2MP IPv6 LSP Session Object, and the the definitions of the P2MP IPv6 LSP Session Object, and the P2MP
P2MP IPv6 Sender-Template Object in [RFC4875]. Note that the IPv6 Sender-Template Object in [RFC4875]. Note that the Sub-Group ID
Sub-Group ID of the Sender-Template is not required. of the Sender-Template is not required.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| P2MP ID | | P2MP ID |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 31 skipping to change at page 11, line 28
| | | |
| IPv6 tunnel sender address | | IPv6 tunnel sender address |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.2. Identifying a Multicast LDP LSP 3.1.2. Identifying a Multicast LDP LSP
[RFC4379] defines how a P2P LDP LSP under test may be identified in [RFC4379] defines how a P2P LDP LSP under test may be identified in
an echo request. A Target FEC Stack TLV is used to carry one or more an echo request. A Target FEC Stack TLV is used to carry one or more
sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the
LSP. LSP.
In order to identify a multicast LDP LSP under test, the echo request In order to identify a multicast LDP LSP under test, the echo request
message MUST carry a Target FEC Stack TLV, and this MUST carry message MUST carry a Target FEC Stack TLV, and this MUST carry
exactly one new sub-TLV: the Multicast LDP FEC Stack sub-TLV. This exactly one new sub-TLV: the Multicast LDP FEC Stack sub-TLV. This
sub-TLV uses fields from the multicast LDP messages [P2MP-LDP] and so sub-TLV uses fields from the multicast LDP messages [P2MP-LDP] and so
provides sufficient information to uniquely identify the LSP. provides sufficient information to uniquely identify the LSP.
The new sub-TLV is assigned a sub-type identifier as follows, and The new sub-TLV is assigned a sub-type identifier as follows, and is
is described in the following section. described in the following section.
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
TBD Variable Multicast P2MP LDP FEC Stack TBD Variable Multicast P2MP LDP FEC Stack
TBD Variable Multicast MP2MP LDP FEC Stack TBD Variable Multicast MP2MP LDP FEC Stack
3.1.2.1. Multicast LDP FEC Stack Sub-TLVs 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs
Both Multicast P2MP and MP2MP LDP FEC Stack have the same format, as Both Multicast P2MP and MP2MP LDP FEC Stack have the same format, as
specified in the following figure. specified in the following figure.
skipping to change at page 11, line 44 skipping to change at page 12, line 46
Opaque Length Opaque Length
The length of the Opaque Value, in octets. The length of the Opaque Value, in octets.
Opaque Value Opaque Value
An opaque value element which uniquely identifies the P2MP LSP in An opaque value element which uniquely identifies the P2MP LSP in
the context of the Root LSR. the context of the Root LSR.
If the Address Family is IPv4, the Address Length MUST be 4. If the If the Address Family is IPv4, the Address Length MUST be 4. If the
Address Family is IPv6, the Address Length MUST be 16. No other Address Family is IPv6, the Address Length MUST be 16. No other
Address Family values are defined at present. Address Family values are defined at present.
3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs
The mechanisms defined in this document can be extended to include The mechanisms defined in this document can be extended to include
Multipoint-to-Multipoint (MP2MP) Multicast LSPs. In an MP2MP LSP Multipoint-to-Multipoint (MP2MP) Multicast LSPs. In an MP2MP LSP
tree, any leaf node can be treated like a head node of a P2MP tree, any leaf node can be treated like a head node of a P2MP tree.
tree. In other words, for MPLS OAM purposes, the MP2MP tree can be In other words, for MPLS OAM purposes, the MP2MP tree can be treated
treated like a collection of P2MP trees, with each MP2MP leaf node like a collection of P2MP trees, with each MP2MP leaf node acting
acting like a P2MP head-end node. When a leaf node is acting like a like a P2MP head-end node. When a leaf node is acting like a P2MP
P2MP head-end node, the remaining leaf nodes act like egress nodes. head-end node, the remaining leaf nodes act like egress or bud nodes.
3.2. Ping Mode Operation
3.2.1. Controlling Responses to LSP Pings
As described in Section 2.2, it may be desirable to restrict the
operation of LSP Ping to a single egress. Since echo requests are
forwarded through the data plane without interception by the control
plane (compare with traceroute mode), there is no facility to limit
the propagation of echo requests, and they will automatically be
forwarded to all (reachable) egresses.
However, the intended egress under test can be identified by the
inclusion of a P2MP Responder Identifier TLV. The details of this TLV
and its Sub-TLVs are in section 3.2.4. The initiator may choose
whether only the node identified in the TLV responds or any node on
the path to the node identified in the TLV may respond.
An initiator may indicate that it wishes all egresses to respond to
an echo request by omitting the P2MP Responder Identifier TLV.
Note that the ingress of a multicast LDP LSP will not know the
identities of the egresses of the LSP except by some external means
such as running P2MP LSP Ping to all egresses.
3.2.2. Ping Mode Egress Procedures
An egress node is RECOMMENDED to rate limit its receipt of echo
request messages as described in [RFC4379]. After rate limiting, an
egress node that receives an echo request carrying an RSVP P2MP IPv4
Session sub-TLV, an RSVP P2MP IPv6 Session sub-TLV, or a Multicast
LDP FEC Stack sub-TLV MUST determine whether it is an egress of the
P2MP LSP in question by checking with the control plane.
- If the node is not an egress, it MUST respond according to the
setting of the Response Type field in the echo message following
the rules defined in [RFC4379].
- If the node is an egress of the P2MP LSP, the node must
check whether it is a receipient of the echo request.
- If a P2MP Responder Identifier TLV is present, then the node
must follow the procedures defined in section 3.2.4 to determine
whether it should respond to the reqeust or not.
- If the P2MP Responder Identifier TLV is not present (or, in the
error case, is present, but does not contain any sub-TLVs), and
the egress node that received the echo request is an intended
egress of the LSP, the node MUST respond according to the setting
of the Response Type field in the echo message following the
rules defined in [RFC4379].
3.2.3. Jittered Responses
The initiator (ingress) of a ping request MAY request the responding
egress to introduce a random delay (or jitter) before sending the
response. The randomness of the delay allows the responses from
multiple egresses to be spread over a time period. Thus this
technique is particularly relevant when the entire LSP tree is being
pinged since it helps prevent the ingress (or nearby routers) from
being swamped by responses, or from discarding responses due to rate
limits that have been applied.
It is desirable for the ingress to be able to control the bounds
within which the egress delays the response. If the tree size is
small, only a small amount of jitter is required, but if the tree is
large, greater jitter is needed. The ingress informs the egresses of
the jitter bound by supplying a value in a new TLV (the Echo Jitter
TLV) carried on the echo request message. If this TLV is present, the
responding egress MUST delay sending a response for a random amount
of time between zero milliseconds and the value indicated in the
TLV. If the TLV is absent, the responding egress SHOULD NOT introduce
any additional delay in responding to the echo request.
LSP ping SHOULD NOT be used to attempt to measure the round-trip
time for data delivery. This is because the LSPs are unidirectional,
and the echo response is often sent back through the control plane.
The timestamp fields in the echo request/response MAY be used to
deduce some information about delivery times and particularly the
variance in delivery times.
The use of echo jittering does not change the processes for gaining
information, but note that the responding egress MUST set the value
in the Timestamp Received fields before applying any delay.
It is RECOMMENDED that echo response jittering is not used except in
the case of P2MP LSPs. If the Echo Jitter TLV is present in an echo
request for any other type of TLV, the responding egress MAY apply
the jitter behavior described here.
3.2.4. P2MP Responder Identifier TLV and Sub-TLVs 3.2. Limiting the Scope of Responses
A new TLV is defined for inclusion in the Echo request message. A new TLV is defined for inclusion in the Echo request message.
The P2MP Responder Identifier TLV is assigned the TLV type value TBD The P2MP Responder Identifier TLV is assigned the TLV type value TBD
and is encoded as follows. and is encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=TBD(P2MP Responder ID TLV)| Length = Variable | |Type=TBD(P2MP Responder ID TLV)| Length = Variable |
skipping to change at page 14, line 4 skipping to change at page 13, line 25
The P2MP Responder Identifier TLV is assigned the TLV type value TBD The P2MP Responder Identifier TLV is assigned the TLV type value TBD
and is encoded as follows. and is encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=TBD(P2MP Responder ID TLV)| Length = Variable | |Type=TBD(P2MP Responder ID TLV)| Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~ ~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-TLVs: Sub-TLVs:
Zero, one or more sub-TLVs as defined below. Zero, one or more sub-TLVs as defined below.
If no sub-TLVs are present, the TLV MUST be processed as if it If no sub-TLVs are present, the TLV MUST be processed as if it
were absent. If more than one sub-TLV is present the first MUST were absent. If more than one sub-TLV is present the first MUST
be processed as described in this document, and subsequent be processed as described in this document, and subsequent
sub-TLVs SHOULD be ignored. sub-TLVs SHOULD be ignored.
The P2MP Responder Identifier TLV only has meaning on an echo request The P2MP Responder Identifier TLV only has meaning on an echo request
message. If present on an echo response message, it SHOULD be message. If present on an echo response message, it SHOULD be
ignored. ignored.
Four sub-TLVs are defined for inclusion in the P2MP Responder Four sub-TLVs are defined for inclusion in the P2MP Responder
Identifier TLV carried on the echo request message. These are: Identifier TLV carried on the echo request message. These are:
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
1 4 IPv4 Egress Address P2MP Responder Identifier 1 4 IPv4 Egress Address P2MP Responder Identifier
2 16 IPv6 Egress Address P2MP Responder Identifier 2 16 IPv6 Egress Address P2MP Responder Identifier
3 4 IPv4 Node Address P2MP Responder Identifier 3 4 IPv4 Node Address P2MP Responder Identifier
4 16 IPv6 Node Address P2MP Responder Identifier 4 16 IPv6 Node Address P2MP Responder Identifier
The content of these Sub-TLVs are defined in the following The content of these Sub-TLVs are defined in the following sections.
sections. Also defined is the intended behavior of the responding Also defined is the intended behavior of the responding node upon
node upon receiving any of these Sub-TLVs. Please note that the echo receiving any of these Sub-TLVs.
response is always controlled by Response Type field in the echo
message as defined in [RFC4379] and whether or not the responding
node is part for the P2MP tree being identified in the Target FEC
Stack TLV. The Sub-TLVs defined in this section provide additional
constraints to those requirements and are not a replacement for those
requirements.
3.2.4.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 MAY be used in an echo request carrying RSVP P2MP Session Sub-TLV.
Sub-TLV. They SHOULD NOT be used with an echo request carrying They SHOULD NOT be used with an echo request carrying Multicast LDP
Multicast LDP FEC Stack Sub-TLV. FEC Stack Sub-TLV.
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. This address MUST be known SHOULD NOT be of a transit or branch node. A transit or branch node,
to the nodes upstream of the target node, possibly via control plane should be able to determine if the address in this Sub-TLV is for an
signaling, such as RSVP. This Sub-TLV may be used to trace a specific egress or bud node which is reachable through it. Hence, this
egress or bud node in the P2MP tree. address SHOULD be known to the nodes upstream of the target node, for
instance via control plane signaling. As a case in point, if RSVP-TE
is used to signal the P2MP LSP, this address SHOULD be the address
used in destination address field of the S2L_SUB_LSP object, when
corresponding egress or bud node is signaled.
3.2.2. Node Address P2MP Responder Identifier Sub-TLVs
3.2.4.2. Node Address P2MP Responder Identifier Sub-TLVs
The IPv4 or IPv6 Node Address P2MP Responder Identifier Sub-TLVs MAY The IPv4 or IPv6 Node Address P2MP Responder Identifier Sub-TLVs MAY
be used in an echo request carrying either RSVP P2MP Session or be used in an echo request carrying either RSVP P2MP Session or
Multicast LDP FEC Stack Sub-TLV. Multicast LDP FEC Stack Sub-TLV.
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 address in the Sub-TLV corresponds to any address respond only if the address in the Sub-TLV corresponds to any address
that is local to the node. This address in the Sub-TLV may be of any that is local to the node. This address in the Sub-TLV may be of any
physical interface or may be the router id of the node itself. physical interface or may be the router id of the node itself.
The address in this Sub-TLV SHOULD be of any transit, branch, bud or The address in this Sub-TLV SHOULD be of any transit, branch, bud or
egress node for that P2MP tree. This Sub-TLV may be used to ping any egress node for that P2MP LSP.
specific node in the P2MP tree.
3.2.5. Echo Jitter TLV 3.3. Preventing Congestion of Echo Responses
A new TLV is defined for inclusion in the Echo request message. A new TLV is defined for inclusion in the Echo request message.
The Echo Jitter TLV is assigned the TLV type value TBD and is encoded The Echo Jitter TLV is assigned the TLV type value TBD and is encoded
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD (Jitter TLV) | Length = 4 | | Type = TBD (Jitter TLV) | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jitter time | | Jitter time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jitter time: Jitter time:
This field specifies the upper bound of the jitter period that This field specifies the upper bound of the jitter period that
should be applied by a responding node to determine how long to should be applied by a responding node to determine how long to
wait before sending an echo response. A responding node SHOULD wait before sending an echo response. A responding node SHOULD
wait a random amount of time between zero milliseconds and the wait a random amount of time between zero milliseconds and the
value specified in this field. value specified in this field.
Jitter time is specified in milliseconds. Jitter time is specified in milliseconds.
The Echo Jitter TLV only has meaning on an echo request message. If The Echo Jitter TLV only has meaning on an echo request message. If
present on an echo response message, it SHOULD be ignored. present on an echo response message, it SHOULD be ignored.
3.2.6. Echo Response Reporting 3.4. Respond Only If TTL Expired Flag
A new flag is being introduced in the Global Flags field. The new
format of the Global Flags field is:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |T|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The V flag is described in [RFC4379].
The T (TTL Expired) flag SHOULD be set only in the echo request
packet by the sender. This flag SHOULD NOT be set in the echo reply
packet. If this flag is set in an echo reply packet, then it MUST be
ignored.
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
1, then no response should be sent back. If the T flag is set to 0,
then the receiver SHOULD reply as per regular processing.
3.5. Downstream Detailed Mapping TLV
Downstream Detailed Mapping TLV is described in [DDMT]. A transit,
branch or bud node can use the Downstream Detailed Mapping TLV to
return multiple Return Codes for different downstream paths. This
functionality can not be achieved via the Downstream Mapping TLV. As
per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in
[RFC4379] is being deprecated.
Therefore for P2MP, a node MUST support Downstream Detailed Mapping
TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP
traceroute functionality and SHOULD NOT be included in an Echo Request
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
Downstream Mapping TLV it receives in the echo request.
The details of the Return Codes to be used in the Downstream Detailed
Mapping TLV are provided in section 4.
4. Operation of LSP Ping for a P2MP LSP
This section describes how LSP Ping is applied to P2MP MPLS LSPs. As
mentioned previously, an important design consideration has been to
extend existing LSP Ping mechanism in [RFC4379] rather than invent
new mechanisms.
As specified in [RFC4379], MPLS LSPs can be tested via a "ping" mode
or a "traceroute" mode. The ping mode is also known as "connectivity
verification" and traceroute mode is also known as "fault isolation".
Further details can be obtained from [RFC4379].
This section specifies processing of echo requests for both ping and
traceroute mode at various nodes (ingress, transit, etc.) of the P2MP
LSP.
4.1. Initiating Router Operations
The router initiating the echo request will follow the procedures in
[RFC4379]. The echo request will contain a Target FEC Stack TLV. To
identify the P2MP LSP under test, this TLV will contain one of the
new sub-TLVs defined in section 3.1. Additionally there may be other
optional TLVs present.
4.1.1. Limiting Responses to Echo Requests
As described in Section 2.2, it may be desirable to restrict the
operation of P2MP ping or traceroute to a single egress. Since echo
requests are forwarded through the data plane without interception by
the control plane, there is no facility to limit the propagation of
echo requests, and they will automatically be forwarded to all
reachable egresses.
However, a single egress may be identified by the inclusion of a P2MP
Responder Identifier TLV. The details of this TLV and its Sub-TLVs
are in section 3.2. There are two main types of sub-TLV in the P2MP
Responder Identifier TLV: Egress Address sub-TLV and Node Address
sub-TLV.
These sub-TLVs limit the responses either to the specified router
only or to any router on the path to the specified router. The
former capability is generally useful for ping mode, while the latter
is more suited to traceroute mode. An initiating router may indicate
that it wishes all egresses to respond to an echo request by omitting
the P2MP Responder Identifier TLV.
4.1.2. Jittered Responses to Echo Requests
The initiating router MAY request the responding routers to introduce
a random delay (or jitter) before sending the response. The
randomness of the delay allows the responses from multiple egresses
to be spread over a time period. Thus this technique is particularly
relevant when the entire P2MP LSP is being pinged or traced since it
helps prevent the initiating (or nearby) routers from being swamped
by responses, or from discarding responses due to rate limits that
have been applied.
It is desirable for the initiating rotuer to be able to control the
bounds of the jitter. If the tree size is small, only a small amount
of jitter is required, but if the tree is large, greater jitter is
needed.
The initiating router can supply the desired value of the jitter in
the Echo Jitter TLV as defined section 3.3. If this TLV is present,
the responding router MUST delay sending a response for a random
amount of time between zero milliseconds and the value indicated in
the TLV. If the TLV is absent, the responding egress SHOULD NOT
introduce any additional delay in responding to the echo request.
LSP ping SHOULD NOT be used to attempt to measure the round-trip time
for data delivery. This is because the P2MP LSPs are unidirectional,
and the echo response is often sent back through the control plane.
The timestamp fields in the echo request and echo response packets
MAY be used to deduce some information about delivery times and
particularly the variance in delivery times.
The use of echo jittering does not change the processes for gaining
information, but note that the responding node MUST set the value in
the Timestamp Received fields before applying any delay.
Echo response jittering SHOULD be used for P2MP LSPs. If the Echo
Jitter TLV is present in an echo request for any other type of LSPs,
the responding egress MAY apply the jitter behavior as described
here.
4.2. Responding Router Operations
Usually the echo request packet will reach the egress and bud nodes.
In case of TTL Expiry, i.e. traceroute mode, the echo request packet
may stop at branch or transit nodes. In both scenarios, the echo
request will be passed on to control plane for reply processing.
The operations at the receiving node are an extenstion to the
existing processing as specified in [RFC4379]. A responding router
is RECOMMENDED to rate limit its receipt of echo request messages.
After rate limiting, the responding router must verify general sanity
of the packet. If the packet is malformed, or certain TLVs are not
understood, the [RFC4379] procedures must be followed for echo reply.
Similarly the Reply Mode field determines if the response is required
or not (and the mechanism to send it back).
For P2MP LSP ping and traceroute, i.e. if the echo request is
carrying an RSVP P2MP FEC or a Multicast LDP FEC, the responding
router MUST determine whether it is part of the P2MP LSP in question
by checking with the control plane.
- If the node is not part of the P2MP LSP, it MUST respond
according to [RFC4379] processing rules.
- If the node is part of the P2MP LSP, the node must check whether
the echo request is directed to it or not.
- If a P2MP Responder Identifier TLV is present, then the node
must follow the procedures defined in section 3.2 to
determine whether it should respond to the reqeust or not.
The presence of a P2MP Responder Identifier TLV or a
Downstream Detailed Mapping TLV might affect the Return Code.
This is discussed in more detail later.
- If the P2MP Responder Identifier TLV is not present (or, in
the error case, is present, but does not contain any
sub-TLVs), then the node MUST respond according to [RFC4379]
processing rules.
4.2.1. Echo Response Reporting
Echo response messages carry return codes and subcodes to indicate Echo response messages carry return codes and subcodes to indicate
the result of the LSP Ping (when the ping mode is being used) as the result of the LSP Ping (when the ping mode is being used) as
described in [RFC4379]. described in [RFC4379].
When the responding node reports that it is an egress, it is clear When the responding node reports that it is an egress, it is clear
that the echo response applies only to the reporting node. Similarly, that the echo response applies only to the reporting node.
when a node reports that it does not form part of the LSP described Similarly, when a node reports that it does not form part of the LSP
by the FEC (i.e. there is a misconnection) then the echo response described by the FEC (i.e. there is a misconnection) then the echo
applies to the reporting node. response applies to the reporting node.
However, it should be noted that an echo response message that However, it should be noted that an echo response message that
reports an error from a transit node may apply to multiple egress reports an error from a transit node may apply to multiple egress
nodes (i.e. leaves) downstream of the reporting node. In the case of nodes (i.e. leaves) downstream of the reporting node. In the case of
the Ping mode of operation, it is not possible to correlate the the ping mode of operation, it is not possible to correlate the
reporting node to the affected egresses unless the shape of the P2MP reporting node to the affected egresses unless the topology of the
tree is already known, and it may be necessary to use the Traceroute P2MP tree is already known, and it may be necessary to use the
mode of operation (see Section 3.3) to further diagnose the LSP. traceroute mode of operation to further diagnose the LSP.
Note also that a transit node may discover an error but also Note also that a transit node may discover an error but also
determine that while it does lie on the path of the LSP under test, determine that while it does lie on the path of the LSP under test,
it does not lie on the path to the specific egress being tested. In it does not lie on the path to the specific egress being tested. In
this case, the node SHOULD NOT generate an echo response. this case, the node SHOULD NOT generate an echo response.
3.2.6.1 Ping Responses at Transit and Branch Nodes The following sections describe the expected values of Return Codes
for various nodes in a P2MP LSP. It is assumed that the sanity and
If the TTL of the MPLS packet carrying an echo request expires at a other checks have been performed and an echo response is being sent
transit or branch node, the packet MUST be passed to the control back. As mentioned previously, the Return Code might change based on
plane as specified in [RFC4379]. the presence of Responder Identifier TLV or Downstream Detailed
Mapping TLV.
If the P2MP Responder Identifier is not present or does not contain
any Sub-TLV, then the node MUST respond. If the P2MP Responder
Identifier Sub-TLV is present, then the node MUST respond as per
section 3.2.4.
If the echo response being sent is not indicating an error condition,
such as Malformed request, then the Return Code in the echo response
header may be set to value 8 ('Label switched at stack-depth <RSC>')
or any other error value as needed.
3.2.6.2 Ping Responses at Egress and Bud Nodes 4.2.1.1. Responses from Transit and Branch nodes
The echo request packet MUST be sent to the control plane at egress The presence of a Responder Identifier TLV does not influence the
and bud nodes. choice of the Return Code, which MAY be set to value 8 ('Label
switched at stack-depth <RSC>') or any other error value as needed.
If the P2MP Responder Identifier is not present or does not contain The presence of a Downstream Detailed Mapping TLV will influence the
any Sub-TLV, then the node MUST respond. If the P2MP Responder choice of Return Code. As per [DDMT], the Return Code in the echo
Identifier Sub-TLV is present, then the node MUST respond as per response header MAY be set to value TBD ('See DDM TLV for Return Code
section 3.2.4. and Return SubCode') as defined in [DDMT]. The Return Code for each
Downstream Detailed Mapping TLV will depend on the downstream path as
described in [DDMT].
If the echo response being sent is not indicating an error condition, There will be a Downstream Detailed Mapping TLV for each downstream
such as Malformed request, then the Return Code in the echo response path being reported in the echo response. Hence for transit nodes,
header may be set to value 3 ('Replying router is an egress for the there will be only one such TLV and for branch nodes, there will be
FEC at stack-depth <RSC>') or any other error value as needed. more than one. If there is an Egress Address Responder Identifier
Sub-TLV, then the branch node will include only one Downstream
Detailed Mapping TLV corresponding to the downstream path required to
reach the address specified in the Egress Address Sub-TLV.
3.3. Traceroute Mode Operation 4.2.1.2. Responses from Egress Nodes
The traceroute mode of operation is described in [RFC4379]. Like The presence of a Responder Identifier TLV does not influence the
other traceroute operations, it relies on the expiration of the TTL choice of the Return Code, which MAY be set to value 3 ('Replying
of the packet that carries the echo request. When the TTL expires the router is an egress for the FEC at stack-depth <RSC>') or any other
echo request is passed to the control plane on the transit node which error value as needed.
responds according to the Response Type in the message (and any
Responder Identifier TLV that may be present).
Echo requests MAY include a Downstream Detailed Mapping TLV, and a The presence of the Downstream Detailed Mapping TLV does not
responding node fills in the fields of the Downstream Detailed influence the choice of Return Code. Egress nodes do not put in any
Mapping TLV to indicate the downstream interfaces and labels used by Downstream Detailed Mapping TLV in the echo response.
the reported LSP from the responding node. In this way, by
successively sending out echo requests with increasing TTLs, the
ingress may gain a picture of the path and resources used by an
LSP. This process continues either to the point of failure when no
response is received, or an error response is generated by a node
where the control plane does not expect to be handling the LSP.
For P2MP Traceroute, a node MUST support Downstream Detailed Mapping 4.2.1.3. Responses from Bud Nodes
TLV [DDMT]. Downstream Mapping TLV [RFC4379] SHOULD NOT be used for
P2MP traceroute functionality. As per Section 4.3 of [DDMT],
Downstream Mapping TLV is being deprecated. A node MUST ignore any
Downstream Mapping TLV it receives in the echo request.
If there are nodes in the P2MP tree that do not support Downstream The case of bud nodes is more complex than other types of nodes. The
Detailed Mapping TLV, they will send an echo reply with Return Code node might behave as either an egress node or a transit node or a
set to 2. The ingress node upon receiving such a value SHOULD send combination of an egress and branch node. This behavior is
subsequent echo requests with a larger TTL. determined by the presence of any Responder Identifier TLV and the
type of sub-TLV in it. Similarly Downstream Detailed Mapping TLV can
influence the Return Code values.
The traceroute mode of operation is equally applicable to P2MP MPLS To determine the behavior of the bud node, use the following
TE LSP and P2MP Multicast LDP LSP and is described in the following guidelines. The intent of these guidelines is to figure out if the
sections. echo request is meant for all nodes, or just this node, or for
another node reachable through this node or for a different section
of the tree. In the first case, the node will behave like a
combination of egress and branch node; in the second case, the node
will behave like pure egress node; in the third case, the node will
behave like a transit node; and in the last case, no response will be
sent back.
The traceroute mode can be applied to all destinations of the P2MP Node behavior guidelines:
tree just as in the ping mode. In the case of P2MP MPLS TE LSPs, the
traceroute mode can also be applied to individual traceroute targets
identified by the presence of a P2MP Responder Identifier TLV. In
this case, the responding node must follow the behavior specified in
3.2.4. These targets SHOULD be egresses or bud nodes. However, since
a transit node of a multicast LDP LSP is unable to determine whether
it lies on the path to any one destination or any other transit node,
the traceroute mode limited to specific nodes of such an LSP MUST NOT
be used.
In the absence of a P2MP Responder Identifier TLV, the echo request - If the Responder Identifier TLV is not present, then the node
is asking for traceroute information applicable to all egresses. will behave as a combination egress and branch node.
The echo response jitter technique described for the ping mode is - If the Responder Identifier TLV containing a Node Address
equally applicable to the traceroute mode and is not additionally sub-TLV is present, and:
described in the procedures below.
3.3.1. Correlating Traceroute Responses - If the address specified in the sub-TLV matches to an address
in the node, then the node will behave like an egress node
only.
When traceroute is simultaneously applied to multiple responders - If the address specified in the sub-TLV does not match any
(e.g. egresses), it is important that the ingress is able to address in the node, then no response will be sent.
correlate the echo responses with the nodes in the P2MP tree. Without
this information the ingress will be unable to determine the correct
ordering of transit nodes. One possibility is for the ingress to poll
the path to each responder in turn, but this may be inefficient,
undesirable, or (in the case of multicast LDP LSPs) illegal.
The Downstream Detailed Mapping TLV MUST be included in the echo - If the Responder Identifier TLV containing an Egress Address
response from transit, bud, or branch nodes. The information from sub-TLV is present, and:
Downstream Detailed Mapping TLV can be pieced together by the ingress
to reconstruct the P2MP tree although it may be necessary to refer to
the routing information distributed by the IGP to correlate next hop
addresses and node reporting addresses in subsequent echo responses.
The following sections describe the Return Code used in the echo - If the address specified in the sub-TLV matches to an address
response header and in the Downstream Detailed Mapping TLV. It is in the node, then the node will behave like an egress node
possible to identify the type of node (transit, branch, bud and only.
egress) by using various values in the Return Code and presence of
Downstream Detailed Mapping TLV.
3.3.2. Traceroute Responses at Transit Nodes - If the node lies on the path to the address specified in the
sub-TLV, then the node will behave like a transit node.
When the TTL of the MPLS packet carrying an echo request expires the - If the node does not lie on the path to the address specified
packet MUST be passed to the control plane as specified in [RFC4379]. in the sub-TLV, then no response will be sent.
If the echo request packet contains an IPv4 or IPv6 Egress Address Once the node behavior has been determined, the possible values for
P2MP Responder Identifier TLV, and the FEC is IPv4 or IPv6 P2MP TE Return Codes are as follows:
LSP, then the node MUST respond only if the node lies on the path to
the egress specified in the Sub-TLV.
If the LSP under test is a multicast LDP LSP and echo request has an - If the node is behaving as an egress node only, then the Return
IPv4 or IPv6 Egress Address P2MP Responder Identifier TLV, then the Code MAY be set to value 3 ('Replying router is an egress for
node MUST treat the echo request as malformed and MUST process it the FEC at stack-depth <RSC>') or any other error value as
according to the rules specified in [RFC4379]. needed. The echo response MUST NOT contain any Downstream
Detailed Mapping TLV, even if one is present in the echo
request.
If the echo response being sent is not indicating an error condition, - If the node is behaving as a transit node, and:
such as Malformed request, it MUST identify the next hop of the path
of the LSP in the data plane by including a Downstream Detailed
Mapping TLV as described in [DDMT].
The Return Code in echo response header will be value TBD ('See DDM - If a Downstream Detailed Mapping TLV is not present, then
TLV for Return Code and Return SubCode') as defined in [DDMT]. The the Return Code MAY be set to value 8 ('Label switched at
Return Code for the Downstream Detailed Mapping TLV will depend on stack-depth <RSC>') or any other error value as needed.
the state of the output interface.
3.3.3. Traceroute Responses at Branch Nodes - If a Downstream Detailed Mapping TLV is present, then the
Return Code MAY be set to value TBD ('See DDM TLV for
Return Code and Return SubCode') as defined in [DDMT]. The
Return Code for the Downstream Detailed Mapping TLV will
depend on the downstream path as described in [DDMT].
There will be only one Downstream Detailed Mapping
corresponding to the downstream path to the address
specified in the Egress Address Sub-TLV.
A branch node MUST follow the procedures described in Section 3.3.2 - If the node is behaving as a combination egress and branch node,
to determine whether it should respond to an echo request. and:
If the P2MP Responder Identifier is not present or does not contain - If a Downstream Detailed Mapping TLV is not present, then
any Sub-TLV (that is, if all egresses are being traced), then the the Return Code MAY be set to value 3 ('Replying router is
branch node MUST add a Downstream Detailed Mapping TLV to the echo an egress for the FEC at stack-depth <RSC>') or any other
response for each outgoing branch that it reports. error value as needed.
If an IPv4 or IPv6 Egress Address P2MP Responder Identifier is - If a Downstream Detailed Mapping TLV is present, then the
present, it MUST report only the branch that is on the path to the Return Code MAY be set to value 3 ('Replying router is an
specified egress node and it MUST NOT report the other branches. egress for the FEC at stack-depth <RSC>') or any other
error value as needed. Return Code for the each Downstream
Detailed Mapping TLV will depend on the downstream path as
described in [DDMT]. There will be a Downstream Detailed
Mapping for each downstream path from the node.
The Return Code in echo response header will be value TBD ('See DDM 4.3. Special Considerations for Traceroute
TLV for Return Code and Return SubCode') as defined in [DDMT]. The
Return Code for each of the Downstream Detailed Mapping TLV will
depend on the state of the output interface being reported in this
TLV.
3.3.4. Traceroute Responses at Egress Nodes 4.3.1. End of Processing for Traceroutes
If P2MP Responder Identifier is not present or does not contain any As specified in [RFC4379], the traceroute mode operates by sending a
Sub-TLV (that is, if all egresses are being traced), then the egress series of echo requests with sequentially increasing TTL values. For
node MUST respond to the echo request. regular P2P targets, this processing stops when a valid response is
received from the intended egress or when some errored return code is
received.
If an IPv4 or IPv6 Egress Address P2MP Responder Identifier is For P2MP targets, there may not be an easy way to figure out the end
present, it MUST respond only if the specified address belongs the of the traceroute processing, as there are multiple egress nodes.
egress node. Receiving a valid response from an egress will not signal the end of
processing.
Egress node MUST NOT return a Downstream Detailed Mapping TLV. In P2MP TE LSP, the initiating router has a priori knowledge about
number of egress nodes and their addresses. Hence it possible to
continue processing till a valid response has been received from each
end-point, provided the responses can be matched correctly to the
egress nodes.
The Return Code in the echo response header will be value 3 ('Replying However in Multicast LDP LSPs, the initiating router has no knowledge
router is an egress for the FEC at stack-depth <RSC>') as defined in about the egress nodes. Hence it is not possible to estimate the end
[RFC4379]. of processing for traceroute in such scenarios.
3.3.5. Traceroute Responses at Bud Nodes Therefore it is RECOMMENDED that traceroute operations provide for a
configurable upper limit on TTL values. Hence the user can choose
the depth to which the tree will be probed.
Some nodes on a P2MP MPLS LSP may be an egress as well as a branch 4.3.2. Multiple responses from Bud and Egress Nodes
(i.e. have one or more downstream nodes). Such nodes are known as bud
nodes [RFC4461]. A bud node's response is a combination of branch
node and egress node behavior.
If P2MP Responder Identifier is not present or does not contain any The P2MP traceroute may continue even after it has received a valid
Sub-TLV (that is, if all egresses are being traced), then the bud response from a bud or egress node, as there may be more nodes at
node MUST respond to the echo request. It MUST add a Downstream deeper levels. Hence for subsequent TTL values, a bud or egress node
Detailed Mapping TLV to the echo response for each outgoing branch that has previously replied would continue to get new echo requests.
that it reports. The Return Code in the echo response header will be Since each echo request is handled independently from previous
value 3 ('Replying router is an egress for the FEC at stack-depth requests, these bud and egress nodes will keep on responding to the
<RSC>') as defined in [RFC4379]. The Return Code for each of the traceroute echo requests. This can cause extra processing burden for
Downstream Detailed Mapping TLV will depend on the state of the the initiating router and these bud or egress routers.
output interface being reported in this TLV.
If an IPv4 or IPv6 Egress Address P2MP Responder Identifier is To prevent a bud or egress node from sending multiple responses in
present, and the specified address belongs the bud node, then it MUST the same traceroute operation, a new "Respond Only If TTL Expired"
respond as if it were an egress node. The Return Code in the echo flag is being introduced. This flag is described in Section 3.4.
response header will be value 3 ('Replying router is an egress for
the FEC at stack-depth <RSC>') as defined in [RFC4379]. It MUST NOT
report any Downstream Detailed Mapping TLV.
If an IPv4 or IPv6 Egress Address P2MP Responder Identifier is It is RECOMMENDED that this flag be used for P2MP traceroute mode
present, and the bud node lies on the path to the specified egress only. By using this flag, extraneous responses from bud and egress
address, then it MUST respond as if it was a branch node. The Return nodes can be reduced.
Code in the echo response header will be value TBD ('See DDM TLV for
Return Code and Return SubCode') as defined in [DDMT]. The Return
Code for each of the Downstream Detailed Mapping TLV will depend on
the state of the output interface being reported in this TLV.
3.3.6. 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, perhaps because the a response to its echo request. For example, the transit node has
transit node has failed, or perhaps because the transit node does not failed, or the transit node does not support LSP Ping.
support LSP Ping, or the Responder Identifier TLV failed to match a
valid node.
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.
3.3.7 Use of Downstream Detailed Mapping TLV in Echo Request 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request
If no Responder Identifier TLV is being used, then in the Echo As described in section 4.6 of [RFC4379], an initiating router,
Request packet, the "Downstream IP Address" field, of the Downstream during traceroute, SHOULD copy the Downstream Mapping(s) into its
Detailed Mapping TLV, MUST be set to the ALLROUTERs multicast next echo request(s). However for P2MP LSPs, the intiating router
address. will receive multiple sets of Downstream Detailed Mapping TLV from
different nodes. It is not practical to copy all of them into the
next echo request. Hence this behavior is being modified for P2MP
LSPs. In the echo request packet, the "Downstream IP Address" field,
of the Downstream Detailed Mapping TLV, SHOULD be set to the
ALLROUTERS multicast address.
If a Responder Identifier TLV is being used, then the Echo Request If an Egress Address Responder Identifier sub-TLV is being used, then
packet MAY reuse a received Downstream Detailed Mapping TLV. the traceroute is limited to only one path to one egress. Therefore
this traceroute is effectively behaving like a P2P traceroute. In
this scenario, as per section 4.2, the echo responses from
intermediate nodes will contain only one Downstream Detailed Mapping
TLV corresponding to the downstream path required to reach the
address specified in the Egress Address sub-TLV. For this case, the
echo request packet MAY reuse a received Downstream Detailed Mapping
TLV.
4. Non-compliant Routers 5. Non-compliant Routers
If an egress 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 end points for P2MP LSPs are all equally capable of supporting that all nodes for P2MP LSPs are all equally capable of supporting
this function. Alternatively, the traceroute option can be used to this function.
verify the LSP nearly all the way to the egress, leaving the final
hop to be verified manually.
If, in "traceroute" mode, a transit node does not support LSP ping, If the non-compliant node is an egress, then the traceroute mode can
then no reply will be forthcoming from that node for some TTL, say n. be used to verify the LSP nearly all the way to the egress, leaving
The node originating the echo request SHOULD continue to send echo the final hop to be verified manually.
request with TTL=n+1, n+2, ..., n+k to probe nodes further down the
path. In such a case, the echo request for TTL > n SHOULD be sent If the non-compliant node is a branch or transit node, then it should
with Downstream Detailed Mapping TLV "Downstream IP Address" field not impact ping mode. However the node will not respond during
set to the ALLROUTERs multicast address as described in Section 3.3.4 traceroute mode.
until a reply is received with a Downstream Detailed Mapping TLV.
6. OAM Considerations
5. OAM Considerations
The procedures in this document provide OAM functions for P2MP MPLS The procedures in this document provide OAM functions for P2MP MPLS
LSPs and may be used to enable bootstrapping of other OAM procedures. LSPs and may be used to enable bootstrapping of other OAM procedures.
In order to be fully operational several considerations must be made. In order to be fully operational several considerations must be made.
- Scaling concerns dictate that only cautious use of LSP Ping should - Scaling concerns dictate that only cautious use of LSP Ping
be made. In particular, sending an LSP Ping to all egresses of a should be made. In particular, sending an LSP Ping to all
P2MP MPLS LSP could result in congestion at or near the ingress egresses of a P2MP MPLS LSP could result in congestion at or
when the responses arrive. near the ingress when the responses arrive.
Further, incautious use of timers to generate LSP Ping echo
requests either in ping mode or especially in traceroute may lead
to significant degradation of network performance.
- Management interfaces should allow an operator full control over Further, incautious use of timers to generate LSP Ping echo
the operation of LSP Ping. In particular, it SHOULD provide the requests either in ping mode or especially in traceroute may
ability to limit the scope of an LSP Ping echo request for a P2MP lead to significant degradation of network performance.
MPLS LSP to a single egress.
Such an interface SHOULD also provide the ability to disable all - Management interfaces should allow an operator full control over
active LSP Ping operations to provide a quick escape if the network the operation of LSP Ping. In particular, it SHOULD provide the
becomes congested. ability to limit the scope of an LSP Ping echo request for a
P2MP MPLS LSP to a single egress.
- A MIB module is required for the control and management of LSP Ping Such an interface SHOULD also provide the ability to disable all
operations, and to enable the reported information to be inspected. active LSP Ping operations to provide a quick escape if the
network becomes congested.
There is no reason to believe this should not be a simple extension - A MIB module is required for the control and management of LSP
of the LSP Ping MIB module used for P2P LSPs. Ping operations, and to enable the reported information to be
inspected.
6. IANA Considerations There is no reason to believe this should not be a simple
extension of the LSP Ping MIB module used for P2P LSPs.
6.1. New Sub-TLV Types 7. IANA Considerations
7.1. New Sub-TLV Types
Three new sub-TLV types are defined for inclusion within the LSP Ping Four new sub-TLV types are defined for inclusion within the LSP Ping
[RFC4379] Target FEC Stack TLV (TLV type 1). [RFC4379] Target FEC Stack TLV (TLV type 1).
IANA is requested to assign sub-type values to the following IANA is requested to assign sub-type values to the following sub-TLVs
sub-TLVs from the "Multiprotocol Label Switching Architecture (MPLS) from the "Multiprotocol Label Switching Architecture (MPLS) Label
Label Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and
sub-TLVs" sub-registry. sub-TLVs" sub-registry.
RSVP P2MP IPv4 Session (see Section 3.1.1). Suggested value 17. RSVP P2MP IPv4 Session (Section 3.1.1). Suggested value 17.
RSVP P2MP IPv6 Session (see Section 3.1.1). Suggested value 18. RSVP P2MP IPv6 Session (Section 3.1.1). Suggested value 18.
Multicast P2MP LDP FEC Stack (see Section 3.1.2). Suggested value 19. Multicast P2MP LDP FEC Stack (Section 3.1.2). Suggested value 19.
Multicast MP2MP LDP FEC Stack (see Section 3.1.2). Suggested value 20. Multicast MP2MP LDP FEC Stack (Section 3.1.2). Suggested value 20.
6.2. New TLVs 7.2. New TLVs
Two new LSP Ping TLV types are defined for inclusion in LSP Ping Two new LSP Ping TLV types are defined for inclusion in LSP Ping
messages. messages.
IANA is requested to assign a new value from the "Multi-Protocol IANA is requested to assign a new value from the "Multi-Protocol
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 as Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry as
follows using a Standards Action value. follows using a Standards Action value.
P2MP Responder Identifier TLV (see Section 3.2.4) is a mandatory P2MP Responder Identifier TLV (see Section 3.2.4) is a mandatory
TLV. Suggested value 11. Four sub-TLVs are defined. TLV. Suggested value 11. Four sub-TLVs are defined.
- Type 1: IPv4 Egress Address P2MP Responder Identifier - Type 1: IPv4 Egress Address P2MP Responder Identifier
- Type 2: IPv6 Egress Address P2MP Responder Identifier - Type 2: IPv6 Egress Address P2MP Responder Identifier
- Type 3: IPv4 Node Address P2MP Responder Identifier - Type 3: IPv4 Node Address P2MP Responder Identifier
- Type 4: IPv6 Node Address P2MP Responder Identifier - Type 4: IPv6 Node Address P2MP Responder Identifier
Echo Jitter TLV (see Section 3.2.5) is a mandatory TLV. Suggested Echo Jitter TLV (see Section 3.2.5) is a mandatory TLV. Suggested
value 12. value 12.
7. Security Considerations 8. Security Considerations
This document does not introduce security concerns over and above This document does not introduce security concerns over and above
those described in [RFC4379]. Note that because of the scalability those described in [RFC4379]. Note that because of the scalability
implications of many egresses to P2MP MPLS LSPs, there is a implications of many egresses to P2MP MPLS LSPs, there is a stronger
stronger concern to regulate the LSP Ping traffic passed to the concern to regulate the LSP Ping traffic passed to the control plane
control plane by the use of a rate limiter applied to the LSP Ping by the use of a rate limiter applied to the LSP Ping well-known UDP
well-known UDP port. Note that this rate limiting might lead to port. Note that this rate limiting might lead to false positives.
false positives.
8. Acknowledgements
9. Acknowledgements
The authors would like to acknowledge the authors of [RFC4379] for The authors would like to acknowledge the authors of [RFC4379] for
their work which is substantially re-used in this document. Also their work which is substantially re-used in this document. Also
thanks to the members of the MBONED working group for their review thanks to the members of the MBONED working group for their review of
of this material, to Daniel King and Mustapha Aissaoui for their this material, to Daniel King and Mustapha Aissaoui for their review,
review, and to Yakov Rekhter for useful discussions. and to Yakov Rekhter for useful discussions.
The authors would like to thank Vanson Lim, Danny Prairie, Reshad The authors would like to thank Bill Fenner, Vanson Lim, Danny
Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin Bahadur, Tetsuya Prairie, Reshad Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin
Murakami, Michael Hua, Michael Wildt, Dipa Thakkar and IJsbrand Bahadur, Tetsuya Murakami, Michael Hua, Michael Wildt, Dipa Thakkar
Wijnands for their comments and suggestions. and IJsbrand Wijnands for their comments and suggestions.
9. References 10. References
9.1 Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol [RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
[DDMT] Bahadur, N., Kompella, K., and Swallow, G., "Mechanism [DDMT] Bahadur, N., Kompella, K., and Swallow, G., "Mechanism
for Performing LSP-Ping over MPLS Tunnels", draft-ietf- for Performing LSP-Ping over MPLS Tunnels", draft-ietf-
mpls-lsp-ping-enhanced-dsmap, work in progress. mpls-lsp-ping-enhanced-dsmap, work in progress.
9.2 Informative References 10.2. Informative References
[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792.
[RFC4461] Yasukawa, S., "Signaling Requirements for Point to [RFC4461] Yasukawa, S., "Signaling Requirements for Point to
Multipoint Traffic Engineered Multiprotocol Label Multipoint Traffic Engineered Multiprotocol Label
Switching (MPLS) Label Switched Paths (LSPs)", Switching (MPLS) Label Switched Paths (LSPs)",
RFC 4461, April 2006. RFC 4461, April 2006.
[RFC4687] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., [RFC4687] Yasukawa, S., Farrel, A., King, D., and Nadeau, T.,
"Operations and Management (OAM) Requirements for "Operations and Management (OAM) Requirements for
skipping to change at page 24, line 8 skipping to change at page 27, line 11
[P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for
point-to-multipoint extensions to the Label Distribution point-to-multipoint extensions to the Label Distribution
Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress.
[P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol
Extensions for Point-to-Multipoint and Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths", Multipoint-to-Multipoint Label Switched Paths",
draft-ietf-mpls-ldp-p2mp, work in progress. draft-ietf-mpls-ldp-p2mp, work in progress.
[MCAST-CV] Swallow, G., and Nadeau, T., "Connectivity Verification
for Multicast Label Switched Paths",
draft-swallow-mpls-mcast-cv, work in progress.
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding
Detection", draft-ietf-bfd-base, work in progress. Detection", draft-ietf-bfd-base, work in progress.
[MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., [MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G.,
"BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in "BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in
progress. progress.
[IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org
10. Authors' Addresses 11. Authors' Addresses
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
(R&D Strategy Department) (R&D Strategy Department)
3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan
Phone: +81 3 5205 5341 Phone: +81 3 5205 5341
Email: s.yasukawa@hco.ntt.co.jp Email: yasukawa.seisho@lab.ntt.co.jp
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Zafar Ali Zafar Ali
Cisco Systems Inc. Cisco Systems Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, ON, K2K 3E8, Canada. Kanata, ON, K2K 3E8, Canada.
Phone: 613-889-6158 Phone: 613-889-6158
Email: zali@cisco.com Email: zali@cisco.com
Bill Fenner
Arastra, Inc.
275 Middlefield Rd.
Suite 50
Menlo Park, CA 94025
Email: fenner@fenron.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
Email: swallow@cisco.com Email: swallow@cisco.com
Thomas D. Nadeau Thomas D. Nadeau
British Telecom British Telecom
BT Centre BT Centre
81 Newgate Street 81 Newgate Street
EC1A 7AJ EC1A 7AJ
London London
Email: tom.nadeau@bt.com Email: tom.nadeau@bt.com
Shaleen Saxena Shaleen Saxena
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
Email: ssaxena@cisco.com Email: ssaxena@cisco.com
11. Full Copyright Statement 12. Full Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
 End of changes. 145 change blocks. 
570 lines changed or deleted 613 lines changed or added

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