draft-ietf-mpls-p2mp-lsp-ping-02.txt   draft-ietf-mpls-p2mp-lsp-ping-03.txt 
Network Working Group Seisho Yasukawa (Editor) Network Working Group Seisho Yasukawa (Editor)
IETF Internet Draft NTT Internet-Draft NTT
Proposed Status: Standards Track Adrian Farrel (Editor) Intended Status: Standards Track Adrian Farrel (Editor)
Expires: March 2007 Olddog Consulting Expires: September 2007 Old Dog Consulting
September 2006
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-02.txt draft-ietf-mpls-p2mp-lsp-ping-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
environment. environment.
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 ................................................... 3 1. Introduction ................................................... 4
1.1 Design Considerations ......................................... 4 1.1 Design Considerations ......................................... 4
2. Notes on Motivation ............................................ 4 2. Notes on Motivation ............................................ 5
2.1. Basic Motivations for LSP Ping ............................... 4 2.1. Basic Motivations for LSP Ping ............................... 5
2.2. Motivations for LSP Ping for P2MP LSPs ....................... 5 2.2. Motivations for LSP Ping for P2MP LSPs ....................... 6
2.3 Bootstrapping other OAM Procedures using LSP Ping ............. 7 2.3 Bootstrapping other OAM Procedures using LSP Ping ............. 7
3. Operation of LSP Ping for a P2MP LSP ........................... 7 3. Operation of LSP Ping for a P2MP LSP ........................... 8
3.1. Identifying the LSP Under Test ............................... 7 3.1. Identifying the LSP Under Test ............................... 8
3.1.1. Identifying a P2MP MPLS TE LSP ............................. 7 3.1.1. Identifying a P2MP MPLS TE LSP ............................. 8
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV ........................... 8 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV ........................... 8
3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV ........................... 8 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV ........................... 9
3.1.2. Identifying a Multicast LDP LSP ............................ 9 3.1.2. Identifying a Multicast LDP LSP ............................ 9
3.1.2.1. Multicast LDP FEC Stack Sub-TLV ......................... 10 3.1.2.1. Multicast LDP FEC Stack Sub-TLV ......................... 10
3.2. Ping Mode Operation ......................................... 11 3.2. Ping Mode Operation ......................................... 11
3.2.1. Controlling Responses to LSP Pings ........................ 11 3.2.1. Controlling Responses to LSP Pings ........................ 11
3.2.2. Ping Mode Egress Procedures ............................... 11 3.2.2. Ping Mode Egress Procedures ............................... 12
3.2.3. Jittered Responses ........................................ 12 3.2.3. Jittered Responses ........................................ 12
3.2.4. P2MP Egress Identifier TLV and Sub-TLVs ................... 12 3.2.4. P2MP Egress Identifier TLV and Sub-TLVs ................... 13
3.2.5. Echo Jitter TLV ........................................... 13 3.2.5. Echo Jitter TLV ........................................... 14
3.3. Traceroute Mode Operation ................................... 14 3.3. Traceroute Mode Operation ................................... 14
3.3.1. Traceroute Responses at Non-Branch Nodes .................. 15 3.3.1. Traceroute Responses at Non-Branch Nodes .................. 15
3.3.1.1. Correlating Traceroute Responses ........................ 15 3.3.1.1. Correlating Traceroute Responses ........................ 15
3.3.2. Traceroute Responses at Branch Nodes ..................... 16 3.3.2. Traceroute Responses at Branch Nodes ..................... 16
3.3.2.1. Correlating Traceroute Responses ........................ 16 3.3.2.1. Correlating Traceroute Responses ........................ 17
3.3.3. Traceroute Responses at Bud Nodes ......................... 17 3.3.3. Traceroute Responses at Bud Nodes ......................... 17
3.3.4. Non-Response to Traceroute Echo Requests .................. 17 3.3.4. Non-Response to Traceroute Echo Requests .................. 17
3.3.5. Modifications to the Downstream Mapping TLV ............... 17 3.3.5. Modifications to the Downstream Mapping TLV ............... 18
3.3.6. Additions to Downstream Mapping Multipath Information ..... 18 3.3.6. Additions to Downstream Mapping Multipath Information ..... 19
4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms .. 19 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms .. 20
5. Non-compliant Routers ......................................... 20 5. Non-compliant Routers ......................................... 20
6. OAM Considerations ............................................ 20 6. OAM Considerations ............................................ 20
7. IANA Considerations ........................................... 21 7. IANA Considerations ........................................... 21
7.1. New Sub-TLV Types ........................................... 21 7.1. New Sub-TLV Types ........................................... 21
7.2. New Multipath Type .......................................... 21 7.2. New Multipath Type .......................................... 21
7.3. New TLVs .................................................... 22 7.3. New TLVs .................................................... 22
8. Security Considerations ....................................... 22 8. Security Considerations ....................................... 22
9. Acknowledgements .............................................. 22 9. Acknowledgements .............................................. 22
10. Intellectual Property Considerations ......................... 22 10. Intellectual Property Considerations ......................... 23
11. Normative References ......................................... 23 11. Normative References ......................................... 23
12. Informative References ....................................... 23 12. Informative References ....................................... 23
13. Authors' Addresses ........................................... 24 13. Authors' Addresses ........................................... 24
14. Full Copyright Statement ..................................... 25 14. Full Copyright Statement ..................................... 25
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
skipping to change at page 3, line 31 skipping to change at page 3, line 31
egress identifier TLV. egress identifier TLV.
- Include Multicast LDP FEC Stack Sub-TLV definition from [MCAST-CV]. - Include Multicast LDP FEC Stack Sub-TLV definition from [MCAST-CV].
- Add brief section on use of LSP Ping for bootstrapping. - Add brief section on use of LSP Ping for bootstrapping.
- Add new references to References section. - Add new references to References section.
- Add details of two new authors. - Add details of two new authors.
0.3 Changes from 02 to 03
- Update references.
- Update boilerplate.
- Fix typos.
- Clarify in 3.2.2 that a recipient of an echo request must reply
only onced it has applied incoming rate limiting.
- Tidy references to bootstrapping for [MCAST-CV] in 1.1.
- Allow multiple sub-TLVs in the P2MP Egress Identifier TLV in
sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 3.3.4.
- Clarify how to handle a P2MP Egress Identifier TLV with no sub-TLVs
in sections 3.2.1 and 3.2.2.
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) MPLS LSP are described in failures in point-to-point (P2P) MPLS LSP are described in
[RFC4379]. The techniques involve information carried in an MPLS [RFC4379]. The techniques involve information carried in an MPLS
"echo request" and "echo reply", and mechanisms for transporting the "echo request" and "echo reply", and mechanisms for transporting the
echo reply. The echo request and reply messages provide sufficient echo reply. The echo request and reply messages provide sufficient
information to check correct operation of the data plane, as well as information to check correct operation of the data plane, as well as
a mechanism to verify the data plane against the control plane, and a mechanism to verify the data plane against the control plane, and
thereby localize faults. The use of reliable reply channels for echo thereby localize faults. The use of reliable reply channels for echo
request messages as described in [RFC4379] enables more robust fault request messages as described in [RFC4379] enables more robust fault
isolation. This collection of mechanisms is commonly referred to as isolation. This collection of mechanisms is commonly referred to as
"LSP Ping". "LSP Ping".
The requirements for point-to-multipoint (P2MP) MPLS traffic The requirements for point-to-multipoint (P2MP) MPLS traffic
skipping to change at page 4, line 5 skipping to change at page 4, line 31
engineered (TE) LSPs are stated in [RFC4461]. [P2MP-RSVP] specifies a engineered (TE) LSPs are stated in [RFC4461]. [P2MP-RSVP] 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. Mechanisms are, therefore, desirable to detect such
data plane faults in P2MP MPLS LSPs as described in [P2MP-OAM-REQ]. data 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 they may be applied to P2MP MPLS LSPs and so that they can be that they may be applied to P2MP MPLS LSPs and so that they can be
used to bootstrap other OAM procedures such as [MCAST-CV]. This used to bootstrap other OAM procedures such as [MCAST-CV]. This
document stresses the reuse of existing LSP Ping mechanisms used for document stresses the reuse of existing LSP Ping mechanisms used for
P2P LSPs, and applies them to P2MP MPLS LSPs in order to simplify P2P LSPs, and applies them to P2MP MPLS LSPs in order to simplify
implementation and network operation. implementation and network operation.
1.1 Design Considerations 1.1 Design Considerations
skipping to change at page 4, line 27 skipping to change at page 4, line 53
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 would messages follow the same data path that normal MPLS packets would
traverse. However, it can be seen this notion needs to be extended traverse. 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 for P2MP MPLS LSPs, as in this case an MPLS packet is replicated so
that it arrives at each egress (or leaf) of the P2MP tree. that it 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 against the control plane. They and they can then be used to validate data plane state against the
may also be used to bootsrap other OAM procedures such as [MPLS-BFD]. control plane. They may also be used to bootsrap other OAM procedures
As pointed out in [RFC4379], mechanisms to check the liveness, such as [MPLS-BFD] and [MCAST-CV]. As pointed out in [RFC4379],
function, and consistency of the control plane are valuable, but such mechanisms to check the liveness, function, and consistency of the
mechanisms are not a feature of LSP Ping and are not covered in this control plane are valuable, but such mechanisms are not a feature of
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 well-known
UDP port defined for use by LSP Ping traffic. 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
skipping to change at page 5, line 36 skipping to change at page 6, line 11
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 thus should be used with caution. and thus 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 [P2MP-OAM-REQ], MPLS has been extended to encompass As stated in [RFC4687], MPLS has been extended to encompass P2MP
P2MP LSPs. As with P2P MPLS LSPs, the requirement to detect, handle LSPs. As with P2P MPLS LSPs, the requirement to detect, handle and
and diagnose control and data plane defects is critical. For diagnose control and data plane defects is critical. For operators
operators deploying services based on P2MP MPLS LSPs the detection deploying services based on P2MP MPLS LSPs the detection and
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 an
MPLS multicast FEC. MPLS multicast FEC.
skipping to change at page 6, line 12 skipping to change at page 6, line 37
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 a specific egress. 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. An
echo request also carries the identification of the P2MP MPLS LSP 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. In "ping" mode (basic connectivity check), the echo request
should reach the end of the path, at which point it is sent to the should reach the end of the path, at which point it is sent to the
control plane of the egress LSRs, which then verify that they are control plane of the egress LSRs, which verify that they are indeed
indeed an egress (leaf) of the P2MP LSP. An echo response message is an egress (leaf) of the P2MP LSP. An echo response message is sent by
sent by an egress to the ingress to confirm the successful receipt an egress to the ingress to confirm the successful receipt (or
(or announce the erroneous arrival) of the echo request. 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. Therefore, the procedures described in this
document provide a procedure that allows the responders to randomly document provide a mechanism that allows the responders to randomly
delay (or jitter) their responses so that the chances of swamping the delay (or jitter) their responses so that the chances of swamping the
ingress are reduced. ingress are reduced.
Further, the procedures in this document allow the initiator to limit Further, the procedures in this document allow the initiator to limit
the scope of an LSP Ping echo request (ping or traceroute mode) to the scope of an LSP Ping echo request (ping or traceroute mode) to
one specific intended egress. one specific intended egress or a set of egresses.
The scalability issues surrounding LSP Ping for P2MP MPLS LSPs may be The scalability issues surrounding LSP Ping for P2MP MPLS LSPs may be
addressed by other mechanisms such as [MCAST-CV] that utilise the LSP addressed by other mechanisms such as [MCAST-CV] that utilise the LSP
Ping procedures in this document to provide bootstrapping mechanisms Ping procedures in this document to provide bootstrapping mechanisms
as described in Section 2.3. as described in Section 2.3.
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 operator or an automated process can then initiate a traceroute the operator or an automated process can then initiate a traceroute
to determine where the fault is located within the network. A to determine where the fault is located within the network. A
skipping to change at page 11, line 19 skipping to change at page 11, line 32
As described in Section 2.2, it may be desirable to restrict the 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 operation of LSP Ping to a single egress. Since echo requests are
forwarded through the data plane without interception by the control forwarded through the data plane without interception by the control
plane (compare with traceroute mode), there is no facility to limit plane (compare with traceroute mode), there is no facility to limit
the propagation of echo requests, and they will automatically be the propagation of echo requests, and they will automatically be
forwarded to all (reachable) egresses. forwarded to all (reachable) egresses.
However, the intended egress under test can be identified by the However, the intended egress under test can be identified by the
inclusion of a P2MP Egress Identifier TLV containing an IPv4 P2MP inclusion of a P2MP Egress Identifier TLV containing an IPv4 P2MP
Egress Identifier sub-TLV or an IPv6 P2MP Egress Identifier sub-TLV. Egress Identifier sub-TLV or an IPv6 P2MP Egress Identifier sub-TLV.
In this version of the protocol the P2MP Egress Identifier TLV SHOULD The P2MP Egress Identifier TLV MUST contain at least one sub-TLV and
contain precisely one sub-TLV. If the TLV contains no sub-TLVs it MAY contain more than one sub-TLV. If the P2MP Egress Identifier TLV
MUST be processed as if it were absent. If the TLV contains more than contains no sub-TLVs the echo request MUST be processed as if the TLV
one sub-TLV, the first MUST be precessed as described in this were absent (causing all egresses to respond as described below).
document and subsequent sub-TLVs MUST be ignored.
If the P2MP Egress Identifier TLV contains more than one sub-TLV,
each MUST be processed in turn as described in this document. An
initiator sending a P2MP echo request MUST be aware that processing
a very large number of sub-TLVs within a P2MP Egress Identifier TLV
may represent a burden to an egress LSR, so the number of sub-TLVs
SHOULD be limited to a 'reasonable' number. An upper threshold of
50 sub-TLVs is RECOMMENDED.
An initiator may indicate that it wishes all egresses to respond to An initiator may indicate that it wishes all egresses to respond to
an echo request by omitting the P2MP Egress Identifier TLV. an echo request by omitting the P2MP Egress Identifier TLV.
Note that the ingress of a multicast LDP LSP will not know the 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 identities of the egresses of the LSP except by some external means
such as running P2MP LSP Ping to all egresses. such as running P2MP LSP Ping to all egresses.
3.2.2. Ping Mode Egress Procedures 3.2.2. Ping Mode Egress Procedures
An egress LSR is RECOMMENDED to rate limit its receipt of echo An egress LSR is RECOMMENDED to rate limit its receipt of echo
request messages as described in [RFC4379]. After rate limiting, an request messages as described in [RFC4379]. After rate limiting, an
egress LSR that receives an echo request carrying an RSVP P2MP IPv4 egress LSR that receives an echo request carrying an RSVP P2MP IPv4
Session sub-TLV, an RSVP P2MP IPv6 Session sub-TLV, or a Multicast Session sub-TLV, an RSVP P2MP IPv6 Session sub-TLV, or a Multicast
LDP FEC Stack Sub-TLV MUST determine whether it is an intended egress LDP FEC Stack Sub-TLV MUST determine whether it is an intended egress
of the P2MP LSP in question by checking with the control plane. If it of the P2MP LSP in question by checking with the control plane. If it
is not supposed to be an egress, it MUST respond according to the is not supposed to be an egress, it MUST respond according to the
setting of the Response Type field in the echo message following the setting of the Response Type field in the echo message following the
rules defined in [RFC4379]. rules defined in [RFC4379].
If the egress LSR that receives an echo request is an intended egress If the egress LSR that receives an echo request and allows it through
of the P2MP LSP, the LSR MUST check to see whether it is an intended its rate limiting is an intended egress of the P2MP LSP, the LSR MUST
Ping recipient. If a P2MP Egress Identifier TLV is present and check to see whether it is an intended Ping recipient. If a P2MP
contains an address that indicates any address that is local to the Egress Identifier TLV is present and contains an address in any of
LSR, the LSR MUST respond according to the setting of the Response its sub-TLVs that indicates any address that is local to the LSR, the
Type field in the echo message following the rules defined in
[RFC4379]. If the P2MP Egress Identifier TLV is present, but does
not identify the egress LSR, it MUST NOT respond to the echo request.
If the P2MP Egress Identifier TLV is not present, but the egress LSR
that received the echo request is an intended egress of the LSP, the
LSR MUST respond according to the setting of the Response Type field LSR MUST respond according to the setting of the Response Type field
in the echo message following the rules defined in [RFC4379]. in the echo message following the rules defined in [RFC4379]. If the
P2MP Egress Identifier TLV is present, but does none of its sub-TLVs
identifies the egress LSR, it MUST NOT respond to the echo request.
If the P2MP Egress Identifier TLV is not present (or, in the error
case, is present but contains no sub-TLVs), but the egress LSR that
received the echo request is an intended egress of the LSP, the LSR
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 3.2.3. Jittered Responses
The initiator (ingress) of a ping request MAY request the responding The initiator (ingress) of a ping request MAY request the responding
egress to introduce a random delay (or jitter) before sending the egress to introduce a random delay (or jitter) before sending the
response. The randomness of the delay allows the responses from response. The randomness of the delay allows the responses from
multiple egresses to be spread over a time period. Thus this multiple egresses to be spread over a time period. Thus this
technique is particularly relevant when the entire LSP tree is being technique is particularly relevant when the entire LSP tree is being
pinged since it helps prevent the ingress (or nearby routers) from pinged since it helps prevent the ingress (or nearby routers) from
being swamped by responses, or from discarding responses due to rate being swamped by responses, or from discarding responses due to rate
skipping to change at page 13, line 16 skipping to change at page 13, line 37
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 Egress ID TLV)| Length = Variable | |Type = TBD (P2MP Egress 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. were absent. If more than one sub-TLV is present each MUST be
If more than one sub-TLV is present the first MUST be processed processed as described.
as described in this document, and subsequent sub-TLVs MUST be
ignored.
The P2MP Egress Identifier TLV only has meaning on an echo request The P2MP Egress 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.
Two Sub-TLVs are defined for inclusion in the P2MP Egress Identifier Two Sub-TLVs are defined for inclusion in the P2MP Egress Identifier
TLV carried on the echo request message. These are: TLV carried on the echo request message. These are:
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
skipping to change at page 14, line 22 skipping to change at page 14, line 43
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.3. Traceroute Mode Operation 3.3. Traceroute Mode Operation
The traceroute mode of operation is described in [RFC4379]. Like The traceroute mode of operation is described in [RFC4379]. Like
other traceroute operations, it relies on the expiration of the TTL other traceroute operations, it relies on the expiration of the TTL
of the packet that carries the echo request. Echo requests may of the packet that carries the echo request. Echo requests may
include a Downstream Mapping TLV and when the TTL expires the echo include a Downstream Mapping TLV, and when the TTL expires the echo
request is passed to the control plane on the transit LSR which request is passed to the control plane on the transit LSR which
responds according to the Response Type in the message. A responding responds according to the Response Type in the message. A responding
LSR fills in the fields of the Downstream Mapping TLV to indicate the LSR fills in the fields of the Downstream Mapping TLV to indicate the
downstream interfaces and labels used by the reported LSP from the downstream interfaces and labels used by the reported LSP from the
responding LSR. In this way, by successively sending out echo responding LSR. In this way, by successively sending out echo
requests with increasing TTLs, the ingress may gain a picture of the requests with increasing TTLs, the ingress may gain a picture of the
path and resources used by an LSP up to the point of failure when no path and resources used by an LSP up to the point of failure when no
response is received, or an error response is generated by an LSR response is received, or an error response is generated by an LSR
where the control plane does not expect to be handling the LSP. where the control plane does not expect to be handling the LSP.
This mode of operation is equally applicable to P2MP MPLS TE LSPs This mode of operation is equally applicable to P2MP MPLS TE LSPs
as described in the following sections. as described in the following sections.
The traceroute mode can be applied to all destinations of the P2MP The traceroute mode can be applied to all destinations of the P2MP
tree just as in the ping mode. In the case of P2MP MPLS TE LSPs, the tree just as in the ping mode. In the case of P2MP MPLS TE LSPs, the
traceroute mode can also be applied to individual destinations traceroute mode can also be applied to individual destinations
identified by the presence of a P2MP Egress Identifier TLV. However, identified by the presence of a P2MP Egress Identifier TLV. However,
since a transit LSR of a multicast LDP LSP is unable to determine since a transit LSR of a multicast LDP LSP is unable to determine
whether it lies on the path to any one destination, the traceroute whether it lies on the path to any one destination, the traceroute
mode limited to a single egress of such an LSP MUST NOT be used. mode limited to specific egresses of such an LSP MUST NOT be used.
In the absence of a P2MP Egress Identifier TLV, the echo request is In the absence of a P2MP Egress Identifier TLV, the echo request is
asking for traceroute information applicable to all egresses. asking for traceroute information applicable to all egresses.
The echo response jitter technique described for the ping mode is The echo response jitter technique described for the ping mode is
equally applicable to the traceroute mode and is not additionally equally applicable to the traceroute mode and is not additionally
described in the procedures below. described in the procedures below.
3.3.1. Traceroute Responses at Non-Branch Nodes 3.3.1. Traceroute Responses at Non-Branch Nodes
When the TTL for the MPLS packet carrying an echo request expires the When the TTL for the MPLS packet carrying an echo request expires the
packet MUST be passed to the control plane as specified in [RFC4379]. packet MUST be passed to the control plane as specified in [RFC4379].
If the LSP under test is a multicast LDP LSP and if the echo request If the LSP under test is a multicast LDP LSP and if the echo request
carries a P2MP Egress Identifier TLV the LSR MUST treat the echo carries a P2MP Egress Identifier TLV the LSR MUST treat the echo
request as malformed and MUST process it according to the rules request as malformed and MUST process it according to the rules
specified in [RFC4379]. specified in [RFC4379].
Otherwise, the LSR MUST NOT return an echo response unless the Otherwise, the LSR MUST NOT return an echo response unless the
responding LSR lies on the path of the P2MP LSP to the egress responding LSR lies on the path of the P2MP LSP to any of the
identified by the P2MP Egress Identifier TLV carried on the request, egresses identified by the P2MP Egress Identifier TLV carried on the
or if no such Sub-TLV is present. request, or if no such Sub-TLV is present.
If sent, the echo response MUST identifiy the next hop of the path of If sent, the echo response MUST identifiy the next hop of the path of
the LSP in the data plane by including a Downstream Mapping TLV as the LSP in the data plane by including a Downstream Mapping TLV as
described in [RFC4379]. described in [RFC4379].
3.3.1.1. Correlating Traceroute Responses 3.3.1.1. Correlating Traceroute Responses
When traceroute is being simultaneously applied to multiple egresses, When traceroute is being simultaneously applied to multiple egresses,
it is important that the ingress should be able to correlate the echo it is important that the ingress should be able to correlate the echo
responses with the branches in the P2MP tree. Without this responses with the branches in the P2MP tree. Without this
skipping to change at page 17, line 42 skipping to change at page 18, line 11
LSRs that must not reply to the request because, although they lie LSRs that must not reply to the request because, although they lie
on the P2MP tree, they do not lie on the path to the egress that is on the P2MP tree, they do not lie on the path to the egress that is
being traced. being traced.
Thus, an LSR on a P2MP MPLS LSP MUST NOT respond to an echo request Thus, an LSR on a P2MP MPLS LSP MUST NOT respond to an echo request
when the TTL has expired if any of the following applies: when the TTL has expired if any of the following applies:
- The Reply Type indicates that no reply is required - The Reply Type indicates that no reply is required
- There is a P2MP Egress Identifier TLV present on the echo request - There is a P2MP Egress Identifier TLV present on the echo request
(which means that the LSP is a P2MP MPLS TE LSP), but the address (which means that the LSP is a P2MP MPLS TE LSP), but none of the
does not identify an egress that is reached through this LSR for addresses identifies an egress that is reached through this LSR for
this particular P2MP MPLS LSP. this particular P2MP MPLS LSP.
3.3.5. Modifications to the Downstream Mapping TLV 3.3.5. Modifications to the Downstream Mapping TLV
A new B-flag is added to the Downstream Mapping TLV to indicate that A new B-flag is added to the Downstream Mapping TLV to indicate that
the reporting LSR is not a branch for this LSP (cleared to zero) or the reporting LSR is not a branch for this LSP (cleared to zero) or
is a branch (set to one). is a branch (set to one).
A new E-flag is added to the Downstream Mapping TLV to indicate that A new E-flag is added to the Downstream Mapping TLV to indicate that
the reporting LSR is not a bud node for this LSP (cleared to zero) or the reporting LSR is not a bud node for this LSP (cleared to zero) or
skipping to change at page 22, line 39 skipping to change at page 23, line 5
false positives. false positives.
9. 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 this material, to Daniel King for his review, and to Yakov Rekhter of this material, to Daniel King for his review, and to Yakov Rekhter
for useful discussions. for useful discussions.
The authors would like to thank Vanson Lim, Danny Prairie and Reshad The authors would like to thank Vanson Lim, Danny Prairie, Reshad
Rahman for their comments and suggestions. Rahman, and Ben Niven-Jenkins for their comments and suggestions.
10. Intellectual Property Considerations 10. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 23, line 12 skipping to change at page 23, line 29
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
11. Normative References 11. 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.
[P2MP-OAM-REQ] Yasukawa, S., Farrel, A., King, D., and Nadeau, T.,
"OAM Requirements for Point-to-Multipoint MPLS Networks",
draft-ietf-mpls-p2mp-oam-reqs, work in progress.
[IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org
12. Informative References 12. 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.,
"Operations and Management (OAM) Requirements for
Point-to-Multipoint MPLS Networks", RFC 4687, September
2006.
[P2MP-RSVP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to [P2MP-RSVP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to
Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp, Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp,
work in progress. work in progress.
[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
skipping to change at page 24, line 16 skipping to change at page 24, line 29
for Multicast Label Switched Paths", for Multicast Label Switched Paths",
draft-swallow-mpls-mcast-cv, work in progress. 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
13. Authors' Addresses 13. 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: s.yasukawa@hco.ntt.co.jp
Adrian Farrel Adrian Farrel
skipping to change at page 25, line 7 skipping to change at page 25, line 21
Email: swallow@cisco.com Email: swallow@cisco.com
Thomas D. Nadeau Thomas D. Nadeau
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
Email: tnadeau@cisco.com Email: tnadeau@cisco.com
14. Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 36 change blocks. 
86 lines changed or deleted 114 lines changed or added

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