draft-ietf-mpls-p2mp-lsp-ping-15.txt   draft-ietf-mpls-p2mp-lsp-ping-16.txt 
Network Working Group S. Saxena, Ed. Network Working Group S. Saxena, Ed.
Internet-Draft G. Swallow Internet-Draft G. Swallow
Intended Status: Standards Track Z. Ali Intended Status: Standards Track Z. Ali
Updates: 4379 (if approved) Cisco Systems, Inc. Updates: 4379 (if approved) Cisco Systems, Inc.
Expires: July 25, 2011 A. Farrel Expires: September 14, 2011 A. Farrel
Old Dog Consulting Old Dog Consulting
S. Yasukawa S. Yasukawa
NTT Corporation NTT Corporation
T. Nadeau T. Nadeau
LucidVision LucidVision
January 26, 2011 March 14, 2011
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-15.txt draft-ietf-mpls-p2mp-lsp-ping-16.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 42 skipping to change at page 1, line 42
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.txt. http://www.ietf.org/1id-abstracts.txt.
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
This document updates RFC 4379.
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 used The requirement for a simple and efficient mechanism that can be used
to detect data plane failures in point-to-point (P2P) MPLS LSPs has to detect data plane failures in point-to-point (P2P) MPLS LSPs has
been recognized and has led to the development of techniques for been recognized and has led to the development of techniques 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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.................................................... 3
1.1. Design Considerations......................................... 4 1.1. Design Considerations......................................... 4
1.2 Terminology.................................................... 4
2. Notes on Motivation............................................. 4 2. Notes on Motivation............................................. 4
2.1. Basic Motivations for LSP Ping................................ 4 2.1. Basic Motivations for LSP Ping................................ 4
2.2. Motivations for LSP Ping for P2MP LSPs........................ 5 2.2. Motivations for LSP Ping for P2MP LSPs........................ 5
3. Packet Format................................................... 7 3. Packet Format................................................... 7
3.1. Identifying the LSP Under Test................................ 7 3.1. Identifying the LSP Under Test................................ 7
3.1.1. Identifying a P2MP MPLS TE LSP.............................. 7 3.1.1. Identifying a P2MP MPLS TE LSP.............................. 7
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV............................ 7 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............................ 8
3.1.2. Identifying a Multicast LDP LSP............................. 8 3.1.2. Identifying a Multicast LDP LSP............................. 9
3.1.2.1. Multicast LDP FEC Stack Sub-TLVs.......................... 9 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs.......................... 9
3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 10 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 11
3.2. Limiting the Scope of Responses.............................. 10 3.2. Limiting the Scope of Responses.............................. 11
3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs.......... 11 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs.......... 12
3.2.2. Node Address P2MP Responder Identifier Sub-TLVs............ 12 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs............ 12
3.3. Preventing Congestion of Echo Responses...................... 12 3.3. Preventing Congestion of Echo Responses...................... 12
3.4. Respond Only If TTL Expired Flag............................. 13 3.4. Respond Only If TTL Expired Flag............................. 13
3.5. Downstream Detailed Mapping TLV.............................. 13 3.5. Downstream Detailed Mapping TLV.............................. 14
4. Operation of LSP Ping for a P2MP LSP........................... 14 4. Operation of LSP Ping for a P2MP LSP........................... 14
4.1. Initiating Router Operations................................. 14 4.1. Initiating LSR Operations.................................... 15
4.1.1. Limiting Responses to Echo Requests........................ 14 4.1.1. Limiting Responses to Echo Requests........................ 15
4.1.2. Jittered Responses to Echo Requests........................ 15 4.1.2. Jittered Responses to Echo Requests........................ 15
4.2. Responding Router Operations................................. 15 4.2. Responding LSR Operations.................................... 16
4.2.1. Echo Response Reporting.................................... 16 4.2.1. Echo Response Reporting.................................... 17
4.2.1.1. Responses from Transit and Branch nodes.................. 17 4.2.1.1. Responses from Transit and Branch Nodes.................. 18
4.2.1.2. Responses from Egress Nodes.............................. 17 4.2.1.2. Responses from Egress Nodes.............................. 18
4.2.1.3. Responses from Bud Nodes................................. 18 4.2.1.3. Responses from Bud Nodes................................. 18
4.3. Special Considerations for Traceroute........................ 19 4.3. Special Considerations for Traceroute........................ 20
4.3.1. End of Processing for Traceroutes.......................... 20 4.3.1. End of Processing for Traceroutes.......................... 20
4.3.2. Multiple responses from Bud and Egress Nodes............... 20 4.3.2. Multiple responses from Bud and Egress Nodes............... 21
4.3.3. Non-Response to Traceroute Echo Requests................... 21 4.3.3. Non-Response to Traceroute Echo Requests................... 21
4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 21 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 21
4.3.5 Cross Over Node Processing.................................. 21 4.3.5 Cross-Over Node Processing.................................. 22
5. Non-compliant Routers.......................................... 22 5. Non-compliant Routers.......................................... 22
6. OAM Considerations............................................. 22 6. OAM and Management Considerations.............................. 23
7. IANA Considerations............................................ 23 7. IANA Considerations............................................ 23
7.1. New Sub-TLV Types............................................ 23 7.1. New Sub-TLV Types............................................ 24
7.2. New TLVs..................................................... 23 7.2. New TLVs..................................................... 24
8. Security Considerations........................................ 24 8. Security Considerations........................................ 24
9. Acknowledgements............................................... 24 9. Acknowledgements............................................... 25
10. References.................................................... 24 10. References.................................................... 25
10.1. Normative References........................................ 24 10.1. Normative References........................................ 25
10.2. Informative References...................................... 25 10.2. Informative References...................................... 25
11. Authors' Addresses............................................ 25 11. Authors' Addresses............................................ 26
12. Full Copyright Statement...................................... 26 12. Full Copyright Statement...................................... 27
1. Introduction 1. Introduction
Simple and efficient mechanisms that can be used to detect data plane Simple and efficient mechanisms that can be used to detect data plane
failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS)
Label Switched Paths (LSP) are described in [RFC4379]. The Label Switched Paths (LSP) are described in [RFC4379]. The
techniques involve information carried in MPLS "Echo Request" and techniques involve information carried in MPLS "Echo Request" and
"Echo Reply" messages, and mechanisms for transporting them. The "Echo Reply" messages, and mechanisms for transporting them. The
echo request and reply messages provide sufficient information to echo request and reply messages provide sufficient information to
check correct operation of the data plane, as well as a mechanism to check correct operation of the data plane, as well as a mechanism to
skipping to change at page 4, line 31 skipping to change at page 4, line 33
procedures such as [RFC5884]. As pointed out in [RFC4379], procedures such as [RFC5884]. As pointed out in [RFC4379],
mechanisms to check the liveness, function, and consistency of the mechanisms to check the liveness, function, and consistency of the
control plane are valuable, but such mechanisms are not a feature of control plane are valuable, but such mechanisms 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 the control plane. A rate limiter should be applied to the
well-known UDP port defined for use by LSP Ping traffic. well-known UDP port defined for use by LSP Ping traffic.
1.2 Terminology
The terminology used in this document for P2MP MPLS can be found in
[RFC4461]. The terminology for MPLS OAM can be found in [RFC4379].
In particular, the notation <RSC> refers to the Return Subcode as
defined in section 3.1. of [RFC4379].
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
skipping to change at page 6, line 31 skipping to change at page 6, line 39
In "ping" mode (basic connectivity check), the echo request should In "ping" mode (basic connectivity check), the echo request should
reach the end of the path, at which point it is sent to the control 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 an egress plane of the egress LSRs, which verify that they are indeed an egress
(leaf) of the P2MP LSP. An echo response message is sent by an (leaf) of the P2MP LSP. An echo response message is sent by an
egress to the ingress to confirm the successful receipt (or announce egress to the ingress to confirm the successful receipt (or announce
the erroneous arrival) of the echo request. 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 returns information about the outgoing paths. This LSR returns information about the outgoing paths. This information
information can be used by ingress LSR to build topology or by can be used by ingress LSR to build topology or by downstream LSRs to
downstream LSRs to do extra label verification. do extra label verification.
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. The procedures described in this document around the ingress LSR. The procedures described in this document
provide two mechanisms to control echo responses. provide two mechanisms to control echo responses.
skipping to change at page 7, line 46 skipping to change at page 8, line 10
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 IPv4 the definitions of the P2MP IPv4 LSP Session Object and the P2MP IPv4
Sender-Template Object in [RFC4875]. Note that the Sub-Group ID of Sender-Template Object in Sections 19.1.1 and 19.2.1 of [RFC4875].
the Sender-Template is not required. Note that the Sub-Group ID 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 P2MP the definitions of the P2MP IPv6 LSP Session Object, and the P2MP
IPv6 Sender-Template Object in [RFC4875]. Note that the Sub-Group ID IPv6 Sender-Template Object in Sections 19.1.2 and 19.2.2 of
of the Sender-Template is not required. [RFC4875]. Note that the Sub-Group ID 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 13, line 7 skipping to change at page 13, line 31
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.4. Respond Only If TTL Expired Flag 3.4. Respond Only If TTL Expired Flag
A new flag is being introduced in the Global Flags field. The new A new flag is being introduced in the Global Flags field defined in
format of the Global Flags field is: [RFC4379]. The new format of the Global Flags field is:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |T|V| | MBZ |T|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The V flag is described in [RFC4379]. The V flag is described in [RFC4379].
The T (Respond Only If TTL Expired) flag SHOULD be set only in the The T (Respond Only If TTL Expired) flag SHOULD be set only in the
skipping to change at page 14, line 24 skipping to change at page 15, line 5
As specified in [RFC4379], MPLS LSPs can be tested via a "ping" mode 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 or a "traceroute" mode. The ping mode is also known as "connectivity
verification" and traceroute mode is also known as "fault isolation". verification" and traceroute mode is also known as "fault isolation".
Further details can be obtained from [RFC4379]. Further details can be obtained from [RFC4379].
This section specifies processing of echo requests for both ping and This section specifies processing of echo requests for both ping and
traceroute mode at various nodes (ingress, transit, etc.) of the P2MP traceroute mode at various nodes (ingress, transit, etc.) of the P2MP
LSP. LSP.
4.1. Initiating Router Operations 4.1. Initiating LSR Operations
The router initiating the echo request will follow the procedures in The LSR initiating the echo request will follow the procedures in
[RFC4379]. The echo request will contain a Target FEC Stack TLV. To [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 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 new sub-TLVs defined in section 3.1. Additionally there may be other
optional TLVs present. optional TLVs present.
4.1.1. Limiting Responses to Echo Requests 4.1.1. Limiting Responses to Echo Requests
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 P2MP ping or traceroute to a single egress. Since echo operation of P2MP ping or traceroute to a single egress. Since echo
requests are forwarded through the data plane without interception by requests are forwarded through the data plane without interception by
the control plane, there is no facility to limit the propagation of the control plane, there is no facility to limit the propagation of
echo requests, and they will automatically be forwarded to all echo requests, and they will automatically be forwarded to all
reachable egresses. reachable egresses.
However, a single egress may be identified by the inclusion of a P2MP 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 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 are in section 3.2. There are two main types of sub-TLV in the P2MP
Responder Identifier TLV: Node Address sub-TLV and Egress Address Responder Identifier TLV: Node Address sub-TLV and Egress Address
sub-TLV. sub-TLV.
These sub-TLVs limit the responses either to the specified router These sub-TLVs limit the responses either to the specified LSR only
only or to any router on the path to the specified router. The or to any LSR on the path to the specified LSR. The former
former capability is generally useful for ping mode, while the latter capability is generally useful for ping mode, while the latter is
is more suited to traceroute mode. An initiating router may indicate more suited to traceroute mode. An initiating LSR may indicate that
that it wishes all egresses to respond to an echo request by omitting it wishes all egresses to respond to an echo request by omitting the
the P2MP Responder Identifier TLV. P2MP Responder Identifier TLV.
4.1.2. Jittered Responses to Echo Requests 4.1.2. Jittered Responses to Echo Requests
The initiating router MAY request the responding routers to introduce The initiating LSR MAY request the responding LSRs to introduce a
a random delay (or jitter) before sending the response. The random delay (or jitter) before sending the response. The randomness
randomness of the delay allows the responses from multiple egresses of the delay allows the responses from multiple egresses to be spread
to be spread over a time period. Thus this technique is particularly over a time period. Thus this technique is particularly relevant
relevant when the entire P2MP LSP is being pinged or traced since it when the entire P2MP LSP is being pinged or traced since it helps
helps prevent the initiating (or nearby) routers from being swamped prevent the initiating (or nearby) LSRs from being swamped by
by responses, or from discarding responses due to rate limits that responses, or from discarding responses due to rate limits that have
have been applied. been applied.
It is desirable for the initiating rotuer to be able to control the It is desirable for the initiating LSR to be able to control the
bounds of the jitter. If the tree size is small, only a small amount 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 of jitter is required, but if the tree is large, greater jitter is
needed. needed.
The initiating router can supply the desired value of the jitter in The initiating LSR can supply the desired value of the jitter in the
the Echo Jitter TLV as defined section 3.3. If this TLV is present, Echo Jitter TLV as defined section 3.3. If this TLV is present, the
the responding router MUST delay sending a response for a random responding LSR MUST delay sending a response for a random amount of
amount of time between zero milliseconds and the value indicated in time between zero milliseconds and the value indicated in the TLV.
the TLV. If the TLV is absent, the responding egress SHOULD NOT If the TLV is absent, the responding egress SHOULD NOT introduce any
introduce any additional delay in responding to the echo request. additional delay in responding to the echo request.
LSP ping SHOULD NOT be used to attempt to measure the round-trip time 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, for data delivery. This is because the P2MP LSPs are unidirectional,
and the echo response is often sent back through the control plane. and the echo response is often sent back through the control plane.
The timestamp fields in the echo request and echo response packets The timestamp fields in the echo request and echo response packets
MAY be used to deduce some information about delivery times and MAY be used to deduce some information about delivery times and
particularly the variance in delivery times. particularly the variance in delivery times.
The use of echo jittering does not change the processes for gaining The use of echo jittering does not change the processes for gaining
information, but note that the responding node MUST set the value in information, but note that the responding node MUST set the value in
the Timestamp Received fields before applying any delay. the Timestamp Received fields before applying any delay.
Echo response jittering SHOULD be used for P2MP LSPs. If the Echo 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, Jitter TLV is present in an echo request for any other type of LSPs,
the responding egress MAY apply the jitter behavior as described the responding egress MAY apply the jitter behavior as described
here. here.
4.2. Responding Router Operations 4.2. Responding LSR Operations
Usually the echo request packet will reach the egress and bud nodes. 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 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 may stop at branch or transit nodes. In both scenarios, the echo
request will be passed on to control plane for reply processing. request will be passed on to control plane for reply processing.
The operations at the receiving node are an extenstion to the The operations at the receiving node are an extension to the existing
existing processing as specified in [RFC4379]. A responding router processing as specified in [RFC4379]. A responding LSR is
is RECOMMENDED to rate limit its receipt of echo request messages. RECOMMENDED to rate limit its receipt of echo request messages.
After rate limiting, the responding router must verify general sanity After rate limiting, the responding LSR must verify general sanity of
of the packet. If the packet is malformed, or certain TLVs are not the packet. If the packet is malformed, or certain TLVs are not
understood, the [RFC4379] procedures must be followed for echo reply. understood, the [RFC4379] procedures must be followed for echo reply.
Similarly the Reply Mode field determines if the response is required Similarly the Reply Mode field determines if the response is required
or not (and the mechanism to send it back). or not (and the mechanism to send it back).
For P2MP LSP ping and traceroute, i.e. if the echo request is 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 carrying an RSVP P2MP FEC or a Multicast LDP FEC, the responding LSR
router MUST determine whether it is part of the P2MP LSP in question MUST determine whether it is part of the P2MP LSP in question by
by checking with the control plane. checking with the control plane.
- If the node is not part of the P2MP LSP, it MUST respond - If the node is not part of the P2MP LSP, it MUST respond
according to [RFC4379] processing rules. according to [RFC4379] processing rules.
- If the node is part of the P2MP LSP, the node must check whether - If the node is part of the P2MP LSP, the node must check whether
the echo request is directed to it or not. the echo request is directed to it or not.
- If a P2MP Responder Identifier TLV is present, then the node - If a P2MP Responder Identifier TLV is present, then the node
must follow the procedures defined in section 3.2 to must follow the procedures defined in section 3.2 to
determine whether it should respond to the reqeust or not. determine whether it should respond to the reqeust or not.
skipping to change at page 17, line 22 skipping to change at page 18, line 5
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.
The following sections describe the expected values of Return Codes The following sections describe the expected values of Return Codes
for various nodes in a P2MP LSP. It is assumed that the sanity and for various nodes in a P2MP LSP. It is assumed that the sanity and
other checks have been performed and an echo response is being sent other checks have been performed and an echo response is being sent
back. As mentioned previously, the Return Code might change based on back. As mentioned previously, the Return Code might change based on
the presence of Responder Identifier TLV or Downstream Detailed the presence of Responder Identifier TLV or Downstream Detailed
Mapping TLV. Mapping TLV.
4.2.1.1. Responses from Transit and Branch nodes 4.2.1.1. Responses from Transit and Branch Nodes
The presence of a Responder Identifier TLV does not influence the The presence of a Responder Identifier TLV does not influence the
choice of the Return Code, which MAY be set to value 8 ('Label 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. switched at stack-depth <RSC>') or any other error value as needed.
The presence of a Downstream Detailed Mapping TLV will influence the The presence of a Downstream Detailed Mapping TLV will influence the
choice of Return Code. As per [DDMT], the Return Code in the echo choice of Return Code. As per [DDMT], the Return Code in the echo
response header MAY be set to value TBD ('See DDM TLV for Return Code response header MAY be set to value TBD ('See DDM TLV for Return Code
and Return SubCode') as defined in [DDMT]. The Return Code for each and Return SubCode') as defined in [DDMT]. The Return Code for each
Downstream Detailed Mapping TLV will depend on the downstream path as Downstream Detailed Mapping TLV will depend on the downstream path as
skipping to change at page 20, line 17 skipping to change at page 20, line 45
series of echo requests with sequentially increasing TTL values. For series of echo requests with sequentially increasing TTL values. For
regular P2P targets, this processing stops when a valid response is regular P2P targets, this processing stops when a valid response is
received from the intended egress or when some errored return code is received from the intended egress or when some errored return code is
received. received.
For P2MP targets, there may not be an easy way to figure out the end For P2MP targets, there may not be an easy way to figure out the end
of the traceroute processing, as there are multiple egress nodes. of the traceroute processing, as there are multiple egress nodes.
Receiving a valid response from an egress will not signal the end of Receiving a valid response from an egress will not signal the end of
processing. processing.
In P2MP TE LSP, the initiating router has a priori knowledge about For P2MP TE LSP, the initiating LSR has a priori knowledge about
number of egress nodes and their addresses. Hence it possible to number of egress nodes and their addresses. Hence it possible to
continue processing till a valid response has been received from each continue processing till a valid response has been received from each
end-point, provided the responses can be matched correctly to the end-point, provided the responses can be matched correctly to the
egress nodes. egress nodes.
However in Multicast LDP LSPs, the initiating router has no knowledge However for Multicast LDP LSP, the initiating LSR might not always
about the egress nodes. Hence it is not possible to estimate the end know about all the egress nodes. Hence there might not be a
of processing for traceroute in such scenarios. definitive way to estimate the end of processing for traceroute.
Therefore it is RECOMMENDED that traceroute operations provide for a Therefore it is RECOMMENDED that traceroute operations provide for a
configurable upper limit on TTL values. Hence the user can choose configurable upper limit on TTL values. Hence the user can choose
the depth to which the tree will be probed. the depth to which the tree will be probed.
4.3.2. Multiple responses from Bud and Egress Nodes 4.3.2. Multiple responses from Bud and Egress Nodes
The P2MP traceroute may continue even after it has received a valid The P2MP traceroute may continue even after it has received a valid
response from a bud or egress node, as there may be more nodes at response from a bud or egress node, as there may be more nodes at
deeper levels. Hence for subsequent TTL values, a bud or egress node deeper levels. Hence for subsequent TTL values, a bud or egress node
that has previously replied would continue to get new echo requests. that has previously replied would continue to get new echo requests.
Since each echo request is handled independently from previous Since each echo request is handled independently from previous
requests, these bud and egress nodes will keep on responding to the requests, these bud and egress nodes will keep on responding to the
traceroute echo requests. This can cause extra processing burden for traceroute echo requests. This can cause extra processing burden for
the initiating router and these bud or egress routers. the initiating LSR and these bud or egress LSRs.
To prevent a bud or egress node from sending multiple responses in To prevent a bud or egress node from sending multiple responses in
the same traceroute operation, a new "Respond Only If TTL Expired" the same traceroute operation, a new "Respond Only If TTL Expired"
flag is being introduced. This flag is described in Section 3.4. flag is being introduced. This flag is described in Section 3.4.
It is RECOMMENDED that this flag be used for P2MP traceroute mode It is RECOMMENDED that this flag be used for P2MP traceroute mode
only. By using this flag, extraneous responses from bud and egress only. By using this flag, extraneous responses from bud and egress
nodes can be reduced. If PHP is being used in the P2MP tree, then nodes can be reduced. If PHP is being used in the P2MP tree, then
bud and egress nodes will not get any labels with the echo request bud and egress nodes will not get any labels with the echo request
packet. Hence this mechanism will not be effective for PHP scenario. packet. Hence this mechanism will not be effective for PHP scenario.
skipping to change at page 21, line 17 skipping to change at page 21, line 46
There are multiple reasons for which an ingress node may not receive There are multiple reasons for which an ingress node may not receive
a response to its echo request. For example, the transit node has a response to its echo request. For example, the transit node has
failed, or the transit node does not support LSP Ping. failed, or the transit node does not support LSP Ping.
When no response to an echo request is received by the ingress, then When no response to an echo request is received by the ingress, then
as per [RFC4379] the subsequent echo request with a larger TTL SHOULD as per [RFC4379] the subsequent echo request with a larger TTL SHOULD
be sent. be sent.
4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request
As described in section 4.6 of [RFC4379], an initiating router, As described in section 4.6 of [RFC4379], an initiating LSR, during
during traceroute, SHOULD copy the Downstream Mapping(s) into its traceroute, SHOULD copy the Downstream Mapping(s) into its next echo
next echo request(s). However for P2MP LSPs, the intiating router request(s). However for P2MP LSPs, the intiating LSR will receive
will receive multiple sets of Downstream Detailed Mapping TLV from multiple sets of Downstream Detailed Mapping TLV from different
different nodes. It is not practical to copy all of them into the nodes. It is not practical to copy all of them into the next echo
next echo request. Hence this behavior is being modified for P2MP request. Hence this behavior is being modified for P2MP LSPs. In
LSPs. In the echo request packet, the "Downstream IP Address" field, the echo request packet, the "Downstream IP Address" field, of the
of the Downstream Detailed Mapping TLV, SHOULD be set to the Downstream Detailed Mapping TLV, SHOULD be set to the ALLROUTERS
ALLROUTERS multicast address. multicast address.
If an Egress Address Responder Identifier sub-TLV is being used, then If an Egress Address Responder Identifier sub-TLV is being used, then
the traceroute is limited to only one path to one egress. Therefore the traceroute is limited to only one path to one egress. Therefore
this traceroute is effectively behaving like a P2P traceroute. In this traceroute is effectively behaving like a P2P traceroute. In
this scenario, as per section 4.2, the echo responses from this scenario, as per section 4.2, the echo responses from
intermediate nodes will contain only one Downstream Detailed Mapping intermediate nodes will contain only one Downstream Detailed Mapping
TLV corresponding to the downstream path required to reach the TLV corresponding to the downstream path required to reach the
address specified in the Egress Address sub-TLV. For this case, the address specified in the Egress Address sub-TLV. For this case, the
echo request packet MAY reuse a received Downstream Detailed Mapping echo request packet MAY reuse a received Downstream Detailed Mapping
TLV. TLV.
4.3.5 Cross Over Node Processing 4.3.5 Cross-Over Node Processing
A cross-over nodes will require slightly different processing for A cross-over node will require slightly different processing for
traceroute mode. The following definition of cross-over is taken from traceroute mode. The following definition of cross-over is taken from
[RFC4875]. [RFC4875].
The term "cross-over" refers to the case of an ingress or transit The term "cross-over" refers to the case of an ingress or transit
node that creates a branch of a P2MP LSP, a cross-over branch, that node that creates a branch of a P2MP LSP, a cross-over branch, that
intersects the P2MP LSP at another node farther down the tree. It intersects the P2MP LSP at another node farther down the tree. It
is unlike re-merge in that, at the intersecting node, the is unlike re-merge in that, at the intersecting node, the
cross-over branch has a different outgoing interface as well as a cross-over branch has a different outgoing interface as well as a
different incoming interface. different incoming interface.
skipping to change at page 22, line 18 skipping to change at page 22, line 45
the outgoing interface corresponding to the input interface. the outgoing interface corresponding to the input interface.
Due to this restriction, the cross-over node will not duplicate the Due to this restriction, the cross-over node will not duplicate the
outgoing interface information in each of the echo request it outgoing interface information in each of the echo request it
receives via the different input interfaces. This will reflect the receives via the different input interfaces. This will reflect the
actual packet replication in the data plane. actual packet replication in the data plane.
5. Non-compliant Routers 5. Non-compliant Routers
If a node for a P2MP LSP does not support MPLS LSP ping, then no If a node for a P2MP LSP does not support MPLS LSP ping, then no
reply will be sent, resulting in a "false negative" result. There is reply will be sent, causing an incorrect result on the initiating
no protection for this situation, and operators may wish to ensure LSR. There is no protection for this situation, and operators may
that all nodes for P2MP LSPs are all equally capable of supporting wish to ensure that all nodes for P2MP LSPs are all equally capable
this function. of supporting this function.
If the non-compliant node is an egress, then the traceroute mode can If the non-compliant node is an egress, then the traceroute mode can
be used to verify the LSP nearly all the way to the egress, leaving be used to verify the LSP nearly all the way to the egress, leaving
the final hop to be verified manually. the final hop to be verified manually.
If the non-compliant node is a branch or transit node, then it should If the non-compliant node is a branch or transit node, then it should
not impact ping mode. However the node will not respond during not impact ping mode. However the node will not respond during
traceroute mode. traceroute mode.
6. OAM Considerations 6. OAM and Management 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 - Scaling concerns dictate that only cautious use of LSP Ping
should be made. In particular, sending an LSP Ping to all should be made. In particular, sending an LSP Ping to all
egresses of a P2MP MPLS LSP could result in congestion at or egresses of a P2MP MPLS LSP could result in congestion at or
near the ingress when the responses arrive. near the ingress when the responses arrive.
skipping to change at page 23, line 18 skipping to change at page 23, line 47
- A MIB module is required for the control and management of LSP - A MIB module is required for the control and management of LSP
Ping operations, and to enable the reported information to be Ping operations, and to enable the reported information to be
inspected. inspected.
There is no reason to believe this should not be a simple There is no reason to believe this should not be a simple
extension of the LSP Ping MIB module used for P2P LSPs. extension of the LSP Ping MIB module used for P2P LSPs.
7. IANA Considerations 7. IANA Considerations
[Note - to be removed before publication.] The values suggested in [Note - this paragraph to be removed before publication.] The values
this section have already been assigned using the IANA early suggested in this section have already been assigned using the IANA
allocation process [RFC4020]. early allocation process [RFC4020].
7.1. New Sub-TLV Types 7.1. New Sub-TLV Types
Four 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 sub-TLVs IANA is requested to assign sub-type values to the following sub-TLVs
under TLV type 1 (Target FEC Stack) from the "Multiprotocol Label under TLV type 1 (Target FEC Stack) from the "Multiprotocol Label
Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters
- TLVs" registry, "TLVs and sub-TLVs" sub-registry. - TLVs" registry, "TLVs and sub-TLVs" sub-registry.
skipping to change at page 24, line 18 skipping to change at page 24, line 48
Echo Jitter TLV (see Section 3.3) is a mandatory TLV. Suggested Echo Jitter TLV (see Section 3.3) is a mandatory TLV. Suggested
value 12. value 12.
8. 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 stronger implications of many egresses to P2MP MPLS LSPs, there is a stronger
concern to regulate the LSP Ping traffic passed to the control plane concern to regulate the LSP Ping traffic passed to the control plane
by the use of a rate limiter applied to the LSP Ping well-known UDP by the use of a rate limiter applied to the LSP Ping well-known UDP
port. Note that this rate limiting might lead to false positives. port. This rate limiting might lead to false indications of LSP
failure.
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 of thanks to the members of the MBONED working group for their review of
this material, to Daniel King and Mustapha Aissaoui for their review, this material, to Daniel King and Mustapha Aissaoui for their review,
and to Yakov Rekhter for useful discussions. and to Yakov Rekhter for useful discussions.
The authors would like to thank Bill Fenner, Vanson Lim, Danny The authors would like to thank Bill Fenner, Vanson Lim, Danny
skipping to change at page 25, line 39 skipping to change at page 26, line 20
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.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G.,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010 Switched Paths (LSPs)", RFC 5884, June 2010
[IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org
[RFC4461] S. Yasukawa, et al., "Signaling Requirements for
Point-to-Multipoint Traffic-Engineered MPLS Label
Switched Paths (LSPs)", RFC 4461, April 2006
[RFC4020] Kompella, K., Zinin, A., "Early Allocation of Standard [RFC4020] Kompella, K., Zinin, A., "Early Allocation of Standard
Code Points", RFC 4020, February 2005. Code Points", RFC 4020, February 2005.
11. 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
 End of changes. 44 change blocks. 
93 lines changed or deleted 109 lines changed or added

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