draft-ietf-mpls-p2mp-lsp-ping-06.txt   draft-ietf-mpls-p2mp-lsp-ping-07.txt 
Network Working Group Seisho Yasukawa (Editor) Network Working Group A. Farrel (Editor)
Internet-Draft NTT Internet-Draft Old Dog Consulting
Intended Status: Standards Track Adrian Farrel (Editor) Intended Status: Standards Track S. Yasukawa
Created: June 1, 2008 Old Dog Consulting Updates: RFC4379 NTT
Expires: December 1, 2008 Created: September 10, 2008
Expires: March 10, 2009
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-06.txt draft-ietf-mpls-p2mp-lsp-ping-07.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 1, line 44 skipping to change at page 1, line 45
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Recent proposals have extended the scope of Multiprotocol Label Recent proposals have extended the scope of Multiprotocol Label
Switching (MPLS) Label Switched Paths (LSPs) to encompass Switching (MPLS) Label Switched Paths (LSPs) to encompass
point-to-multipoint (P2MP) LSPs. point-to-multipoint (P2MP) LSPs.
The requirement for a simple and efficient mechanism that can be The requirement for a simple and efficient mechanism that can be
used to detect data plane failures in point-to-point (P2P) MPLS LSPs used to detect data plane failures in point-to-point (P2P) MPLS LSPs
has been recognised and has led to the development of techniques has been recognized and has led to the development of techniques
for fault detection and isolation commonly referred to as "LSP Ping". for fault detection and isolation commonly referred to as "LSP Ping".
The scope of this document is fault detection and isolation for P2MP The scope of this document is fault detection and isolation for P2MP
MPLS LSPs. This documents does not replace any of the mechanisms of MPLS LSPs. This documents does not replace any of the mechanisms of
LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and
extends the techniques and mechanisms of LSP Ping to the MPLS P2MP extends the techniques and mechanisms of LSP Ping to the MPLS P2MP
environment. environment.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Contents Contents
1. Introduction ................................................... 4 1. Introduction ................................................... 4
1.1 Design Considerations ......................................... 4 1.1 Design Considerations ......................................... 5
2. Notes on Motivation ............................................ 5 2. Notes on Motivation ............................................ 6
2.1. Basic Motivations for LSP Ping ............................... 5 2.1. Basic Motivations for LSP Ping ............................... 6
2.2. Motivations for LSP Ping for P2MP LSPs ....................... 6 2.2. Motivations for LSP Ping for P2MP LSPs ....................... 8
2.3 Bootstrapping Other OAM Procedures Using LSP Ping ............. 7 2.3 Bootstrapping Other OAM Procedures Using LSP Ping ............. 9
3. Operation of LSP Ping for a P2MP LSP ........................... 8 3. Operation of LSP Ping for a P2MP LSP ........................... 9
3.1. Identifying the LSP Under Test ............................... 8 3.1. Identifying the LSP Under Test ............................... 9
3.1.1. Identifying a P2MP MPLS TE LSP ............................. 8 3.1.1. Identifying a P2MP MPLS TE LSP ............................. 9
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV ........................... 9 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV ........................... 9
3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV ........................... 9 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV .......................... 10
3.1.2. Identifying a Multicast LDP LSP ........................... 10 3.1.2. Identifying a Multicast LDP LSP ........................... 10
3.1.2.1. Multicast LDP FEC Stack Sub-TLV ......................... 10 3.1.2.1. Multicast LDP FEC Stack Sub-TLV ......................... 11
3.2. Ping Mode Operation ......................................... 11 3.2. Ping Mode Operation ......................................... 12
3.2.1. Controlling Responses to LSP Pings ........................ 11 3.2.1. Controlling Responses to LSP Pings ........................ 12
3.2.2. Ping Mode Egress Procedures ............................... 12 3.2.2. Ping Mode Egress Procedures ............................... 12
3.2.3. Jittered Responses ........................................ 12 3.2.3. Jittered Responses ........................................ 13
3.2.4. P2MP Egress Identifier TLV and Sub-TLVs ................... 13 3.2.4. P2MP Responder Identifier TLV and Sub-TLVs ................ 14
3.2.5. Echo Jitter TLV ........................................... 14 3.2.5. Echo Jitter TLV ........................................... 15
3.3. Traceroute Mode Operation ................................... 14 3.2.6. Echo Response Reporting ................................... 15
3.3.1. Traceroute Responses at Non-Branch Nodes .................. 15 3.3. Traceroute Mode Operation ................................... 16
3.3.1.1. Correlating Traceroute Responses ........................ 15 3.3.1. Traceroute Responses at Non-Branch Nodes .................. 17
3.3.2. Traceroute Responses at Branch Nodes ..................... 16 3.3.1.1. Correlating Traceroute Responses ........................ 17
3.3.2.1. Correlating Traceroute Responses ........................ 17 3.3.2. Traceroute Responses at Branch Nodes ..................... 18
3.3.3. Traceroute Responses at Bud Nodes ......................... 17 3.3.2.1. Node Properties TLV ..................................... 18
3.3.4. Non-Response to Traceroute Echo Requests .................. 17 3.3.2.2. Branching Properties Sub-TLV ............................ 19
3.3.5. Modifications to the Downstream Mapping TLV ............... 18 3.3.2.3. Egress Address Sub-TLV .................................. 20
3.3.6. Additions to Downstream Mapping Multipath Information ..... 19 3.3.2.4. Correlating Traceroute Responses ........................ 21
4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms .. 20 3.3.3. Traceroute Responses at Bud Nodes ......................... 21
5. Non-compliant Routers ......................................... 20 3.3.4. Non-Response to Traceroute Echo Requests .................. 22
6. OAM Considerations ............................................ 20 3.3.5. Additions to Downstream Mapping Multipath Information ..... 22
7. IANA Considerations ........................................... 21 3.3.6. Echo Response Reporting ................................... 24
7.1. New Sub-TLV Types ........................................... 21 3.3.6.1. Reporting Multiple Conditions Using The DDM TLV ......... 24
7.2. New Multipath Type .......................................... 21 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms .. 25
7.3. New TLVs .................................................... 22 5. Non-compliant Routers ......................................... 26
8. Security Considerations ....................................... 22 6. OAM Considerations ............................................ 26
9. Acknowledgements .............................................. 22 7. IANA Considerations ........................................... 27
10. Intellectual Property Considerations ......................... 23 7.1. New Sub-TLV Types ........................................... 27
11. Normative References ......................................... 23 7.2. New Multipath Type .......................................... 27
12. Informative References ....................................... 23 7.3. New TLVs .................................................... 28
13. Authors' Addresses ........................................... 24 7.4. New Return Code ............................................. 28
14. Full Copyright Statement ..................................... 25 7.5. New Sub-TLV Value for the Downstream Detailed Mapping TLV ... 28
8. Security Considerations ....................................... 29
9. Acknowledgements .............................................. 29
10. Intellectual Property Considerations ......................... 29
11. Normative References ......................................... 30
12. Informative References ....................................... 30
13. Authors' Addresses ........................................... 31
14. Full Copyright Statement ..................................... 32
0. Change Log 0. Change Log
This section to be removed before publication as an RFC. This section to be removed before publication as an RFC.
0.1 Changes from 00 to 01 0.1 Changes from 00 to 01
- Update references. - Update references.
- Fix boilerplate. - Fix boilerplate.
0.2 Changes from 01 to 02 0.2 Changes from 01 to 02
- Update entire document so that it is not specific to MPLS-TE, but - Update entire document so that it is not specific to MPLS-TE, but
also includes multicast LDP LSPs. also includes multicast LDP LSPs.
- Move the egress identifier sub-TLVs from the FEC Stack TLV to a new - Move the egress identifier sub-TLVs from the FEC Stack TLV to a new
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 0.3 Changes from 02 to 03
- Update references. - Update references.
- Update boilerplate. - Update boilerplate.
- Fix typos. - Fix typos.
- Clarify in 3.2.2 that a recipient of an echo request must reply - Clarify in 3.2.2 that a recipient of an echo request must reply
only once it has applied incoming rate limiting. only once it has applied incoming rate limiting.
- Tidy references to bootstrapping for [MCAST-CV] in 1.1. - Tidy references to bootstrapping for [MCAST-CV] in 1.1.
- Allow multiple sub-TLVs in the P2MP Egress Identifier TLV in - 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. 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 - Clarify how to handle a P2MP Egress Identifier TLV with no sub-TLVs
in sections 3.2.1 and 3.2.2. in sections 3.2.1 and 3.2.2.
0.4 Changes from 03 to 04 0.4 Changes from 03 to 04
- Revert to previous text in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and - Revert to previous text in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and
3.3.4 with respect to multiple sub-TLVs in the P2MP Egress 3.3.4 with respect to multiple sub-TLVs in the P2MP Egress
Identifier TLV. Identifier TLV.
0.5 Changes from 04 to 05 0.5 Changes from 04 to 05
skipping to change at page 4, line 8 skipping to change at page 4, line 8
0.4 Changes from 03 to 04 0.4 Changes from 03 to 04
- Revert to previous text in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and - Revert to previous text in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and
3.3.4 with respect to multiple sub-TLVs in the P2MP Egress 3.3.4 with respect to multiple sub-TLVs in the P2MP Egress
Identifier TLV. Identifier TLV.
0.5 Changes from 04 to 05 0.5 Changes from 04 to 05
- Change coordinates for Tom Nadeau. Section 13. - Change coordinates for Tom Nadeau. Section 13.
- Fix typos. - Fix typos.
- Update references. - Update references.
- Resolve all acronym expansions. - Resolve all acronym expansions.
0.6 Changes from 05 to 06
- New section, 3.2.6, to explain echo response reporting in the Ping
case.
- New section, 3.3.7, to explain echo response reporting in the
Traceroute case.
- Sections 3.3.2, 3.3.5, and 5. Retire the E-flag for identification
of bud nodes. Use the B-flag in a Downstream Mapping TLV with a
zero address to provide the necessary indication.
- Section 3.3.4. Note the use of ALLROUTERS address as per RFC 4379
- Section 7. Suggest values for IANA assignment.
- Rename "P2MP Responder Identifier TLV" to "P2MP Responder
Identifier TLV", "Egress Identifier sub-TLV" to "Responder
Identifier sub-TLV", and "P2MP egresses" multipath type to "P2MP
responder". This allows any LSR on the P2MP LSP to be the target
of, or responder to, an echo request.
0.7 Changes from 06 to 07
- Sections 3.3.2 and 3.3.3. Delete section 3.3.5. New sections
3.3.2.1 through 3.3.2.3: Retire B-flag from Downstream Mapping TLV.
Introduce new Node Properties TLV with Branching Properties and
Egress Address sub-TLVs.
- Section 3.3.2.4: Clarify rules on presence of Multipath Information
in Downstream Mapping TLVs.
- Section 3.3.5: Clarify padding rules.
- Section 3.3.6: Updated to use Downstream Detailed Mapping TLVs for
multiple return conditions reported by a single echo response.
- Section 7: Update IANA values and add new sub-sections.
- Section 11: Add reference draft-ietf-mpls-lsp-ping-enhanced-dsmap.
- Section 13: Update Bill Fenner's coordinates.
1. Introduction 1. Introduction
Simple and efficient mechanisms that can be used to detect data plane Simple and efficient mechanisms that can be used to detect data plane
failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS)
Label Switched Paths (LSP) are described in [RFC4379]. The techniques Label Switched Paths (LSP) are described in [RFC4379]. The techniques
involve information carried in an MPLS "echo request" and "echo involve information carried in an MPLS "echo request" and "echo
reply", and mechanisms for transporting the echo reply. The echo reply", and mechanisms for transporting the echo reply. The echo
request and reply messages provide sufficient information to check request and reply messages provide sufficient information to check
correct operation of the data plane, as well as a mechanism to verify correct operation of the data plane, as well as a mechanism to verify
the data plane against the control plane, and thereby localize the data plane against the control plane, and thereby localize
skipping to change at page 7, line 36 skipping to change at page 8, line 17
around the ingress LSR. Therefore, the procedures described in this around the ingress LSR. Therefore, the procedures described in this
document provide a mechanism 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.
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 utilize 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
traceroute may also be used periodically to verify that data plane traceroute may also be used periodically to verify that data plane
forwarding matches the control plane state; however, this places an forwarding matches the control plane state; however, this places an
increased burden on transit LSRs and should be used infrequently and increased burden on transit LSRs and should be used infrequently and
skipping to change at page 8, line 13 skipping to change at page 8, line 44
[BFD] for use to track the liveliness of an MPLS LSP. In particular [BFD] for use to track the liveliness of an MPLS LSP. In particular
BFD can be used to detect a data plane failure in the forwarding BFD can be used to detect a data plane failure in the forwarding
path of an MPLS LSP. path of an MPLS LSP.
Requirements for MPLS P2MP LSPs extend to hundreds or even thousands Requirements for MPLS P2MP LSPs extend to hundreds or even thousands
of endpoints. If a protocol required explicit acknowledgments to of endpoints. If a protocol required explicit acknowledgments to
each probe for connectivity verification, the response load at the each probe for connectivity verification, the response load at the
root would be overwhelming. root would be overwhelming.
A more scalable approach to monitoring P2MP LSP connectivity is A more scalable approach to monitoring P2MP LSP connectivity is
desribed in [MCAST-CV]. It relies on using the MPLS echo request and described in [MCAST-CV]. It relies on using the MPLS echo request and
echo response messages of LSP Ping [RFC4379] to bootstrap the echo response messages of LSP Ping [RFC4379] to bootstrap the
monitoring mechanism in a manner similar to [MPLS-BFD]. The actual monitoring mechanism in a manner similar to [MPLS-BFD]. The actual
monitoring is done using a separate process defined in [MCAST-CV]. monitoring is done using a separate process defined in [MCAST-CV].
Note that while the approach described in [MCAST-CV] was developed in Note that while the approach described in [MCAST-CV] was developed in
response to the multicast scalability problem, it can be applied to response to the multicast scalability problem, it can be applied to
P2P LSPs as well. P2P LSPs as well.
3. Operation of LSP Ping for a P2MP LSP 3. Operation of LSP Ping for a P2MP LSP
This section describes how LSP Ping is applied to P2MP MPLS LSPs. This section describes how LSP Ping is applied to P2MP MPLS LSPs.
It covers the mechanisms and protocol fields applicable to both ping It covers the mechanisms and protocol fields applicable to both ping
mode and traceroute mode. It explains the responsibilities of the mode and traceroute mode. It explains the responsibilities of the
initiator (ingress), transit LSRs, and receivers (egresses). initiator (ingress), transit nodes, and receivers (egresses).
3.1. Identifying the LSP Under Test 3.1. Identifying the LSP Under Test
3.1.1. Identifying a P2MP MPLS TE LSP 3.1.1. Identifying a P2MP MPLS TE LSP
[RFC4379] defines how an MPLS TE LSP under test may be identified in [RFC4379] defines how an MPLS TE LSP under test may be identified in
an echo request. A Target FEC Stack TLV is used to carry either an an echo request. A Target FEC Stack TLV is used to carry either an
RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV. RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV.
In order to identify the P2MP MPLS TE LSP under test, the echo In order to identify the P2MP MPLS TE LSP under test, the echo
skipping to change at page 11, line 35 skipping to change at page 12, line 30
3.2.1. Controlling Responses to LSP Pings 3.2.1. Controlling Responses to LSP Pings
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 Responder Identifier TLV containing an IPv4 P2MP
Egress Identifier sub-TLV or an IPv6 P2MP Egress Identifier sub-TLV. Responder Identifier sub-TLV or an IPv6 P2MP Responder Identifier
The P2MP Egress Identifier TLV SHOULD contain precisely one sub-TLV. sub-TLV. The P2MP Responder Identifier TLV SHOULD contain precisely
If the TLV contains no sub-TLVs it SHOULD be processed as if the one sub-TLV. If the TLV contains no sub-TLVs it SHOULD be processed
whole TLV were absent (causing all egresses to respond as described as if the whole TLV were absent (causing all egresses to respond as
below). If the TLV contains more than one sub-TLV, the first MUST be described below). If the TLV contains more than one sub-TLV, the
precessed as described in this document, and subsequent sub-TLVs first MUST be processed as described in this document, and subsequent
SHOULD be ignored. sub-TLVs SHOULD be ignored.
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 Responder 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 node 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 node 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 and allows it through If the egress node that receives an echo request and allows it
its rate limiting is an intended egress of the P2MP LSP, the LSR MUST through its rate limiting is an intended egress of the P2MP LSP, the
check to see whether it is an intended Ping recipient. If a P2MP node MUST check to see whether it is an intended Ping recipient. If a
Egress Identifier TLV is present and contains an address that P2MP Responder Identifier TLV is present and contains an address that
indicates any address that is local to the LSR, the LSR MUST respond indicates any address that is local to the node, the node MUST
according to the setting of the Response Type field in the echo respond according to the setting of the Response Type field in the
message following the rules defined in [RFC4379]. If the P2MP Egress echo message following the rules defined in [RFC4379]. If the P2MP
Identifier TLV is present, but does not identify the egress LSR, it Responder Identifier TLV is present, but does not identify the egress
MUST NOT respond to the echo request. If the P2MP Egress Identifier node, it MUST NOT respond to the echo request. If the P2MP Responder
TLV is not present (or, in the error case, is present but does not Identifier TLV is not present (or, in the error case, is present, but
contain any sub-TLVs), but the egress LSR that received the echo does not contain any sub-TLVs), but the egress node that received the
request is an intended egress of the LSP, the LSR MUST respond echo request is an intended egress of the LSP, the node MUST respond
according to the setting of the Response Type field in the echo according to the setting of the Response Type field in the echo
message following the rules defined in [RFC4379]. 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
skipping to change at page 13, line 19 skipping to change at page 14, line 10
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 egress MUST set the value information, but note that the responding egress MUST set the value
in the Timestamp Received fields before applying any delay. in the Timestamp Received fields before applying any delay.
It is RECOMMENDED that echo response jittering is not used except in It is RECOMMENDED that echo response jittering is not used except in
the case of P2MP LSPs. If the Echo Jitter TLV is present in an echo the case of P2MP LSPs. If the Echo Jitter TLV is present in an echo
request for any other type of TLV, the responding egress MAY apply request for any other type of TLV, the responding egress MAY apply
the jitter behavior described here. the jitter behavior described here.
3.2.4. P2MP Egress Identifier TLV and Sub-TLVs 3.2.4. P2MP Responder Identifier TLV and Sub-TLVs
A new TLV is defined for inclusion in the Echo request message. A new TLV is defined for inclusion in the Echo request message.
The P2MP Egress Identifier TLV is assigned the TLV type value TBD and The P2MP Responder Identifier TLV is assigned the TLV type value TBD
is encoded as follows. and is encoded as follows.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = TBD (P2MP Egress ID TLV)| Length = Variable | |Type=TBD(P2MP Responder ID TLV)| Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~ ~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-TLVs: Sub-TLVs:
Zero, one or more sub-TLVs as defined below. Zero, one or more sub-TLVs as defined below.
If no sub-TLVs are present, the TLV MUST be processed as if it If no sub-TLVs are present, the TLV MUST be processed as if it
were absent. If more than one sub-TLV is present the first MUST were absent. If more than one sub-TLV is present the first MUST
be processed as described in this document, and subsequent be processed as described in this document, and subsequent
sub-TLVs SHOULD be ignored. sub-TLVs SHOULD be ignored.
The P2MP Egress Identifier TLV only has meaning on an echo request The P2MP Responder Identifier TLV only has meaning on an echo request
message. If present on an echo response message, it SHOULD be message. If present on an echo response message, it SHOULD be
ignored. ignored.
Two sub-TLVs are defined for inclusion in the P2MP Egress Identifier Two sub-TLVs are defined for inclusion in the P2MP Responder
TLV carried on the echo request message. These are: Identifier TLV carried on the echo request message. These are:
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
1 4 IPv4 P2MP Egress Identifier 1 4 IPv4 P2MP Responder Identifier
2 16 IPv6 P2MP Egress Identifier 2 16 IPv6 P2MP Responder Identifier
The value of an IPv4 P2MP Egress Identifier consists of four octets
of an IPv4 address. The IPv4 address is in network byte order.
The value of an IPv6 P2MP Egress Identifier consists of sixteen The value of an IPv4 P2MP Responder Identifier consists of four
octets of an IPv4 address. The IPv4 address is in network byte order.
The value of an IPv6 P2MP Responder Identifier consists of sixteen
octets of an IPv6 address. The IPv6 address is in network byte order. octets of an IPv6 address. The IPv6 address is in network byte order.
3.2.5. Echo Jitter TLV 3.2.5. Echo Jitter TLV
A new TLV is defined for inclusion in the Echo request message. A new TLV is defined for inclusion in the Echo request message.
The Echo Jitter TLV is assigned the TLV type value TBD and is encoded The Echo Jitter TLV is assigned the TLV type value TBD and is encoded
as follows. as follows.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD (Jitter TLV) | Length = 4 | | Type = TBD (Jitter TLV) | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jitter time | | Jitter time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jitter time: Jitter time:
This field specifies the upper bound of the jitter period that This field specifies the upper bound of the jitter period that
should be applied by a responding egress to determine how long should be applied by a responding node to determine how long to
to wait before sending an echo response. An egress SHOULD wait wait before sending an echo response. A responding node SHOULD
a random amount of time between zero seconds and the value wait a random amount of time between zero seconds and the value
specified in this field. specified in this field.
Jitter time is specified in milliseconds. Jitter time is specified in milliseconds.
The Echo Jitter TLV only has meaning on an echo request message. If The Echo Jitter TLV only has meaning on an echo request message. If
present on an echo response message, it SHOULD be ignored. present on an echo response message, it SHOULD be ignored.
3.2.6. Echo Response Reporting
Echo response messages carry return codes and subcodes to indicate
the result of the LSP Ping (when the ping mode is being used) as
described in [RFC4379].
When the responding node reports that it is an egress, it is clear
that the echo response applies only to the reporting node. Similarly,
when a node reports that it does not form part of the LSP described
by the FEC (i.e. their is a misconnection) then the echo response
applies to the reporting node.
However, it should be noted that an echo response message that
reports an error from a transit node may apply to multiple egress
nodes (i.e. leaves) downstream of the reporting node. In the case of
the Ping mode of operation, it is not possible to correlate the
reporting node to the affected egresses unless the shape of the P2MP
tree is already known, and it may be necessary to use the Traceroute
mode of operation (see Section 3.3) to further diagnose the LSP.
Note also that a transit node may discover an error but also
determine that while it does lie on the path of the LSP under test,
it does not lie on the path to the specific egress being tested. In
this case, the node SHOULD NOT generate an echo response.
A reporting node that is a branch node may need to report multiple
different errors (for different downstream branches). This is
discussed further in Section 3.3.6.
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 node 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 node fills in the fields of the Downstream Mapping TLV to indicate
downstream interfaces and labels used by the reported LSP from the the downstream interfaces and labels used by the reported LSP from
responding LSR. In this way, by successively sending out echo the responding node. 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 a node
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 traceroute targets
identified by the presence of a P2MP Egress Identifier TLV. However, identified by the presence of a P2MP Responder Identifier TLV. These
since a transit LSR of a multicast LDP LSP is unable to determine targets may be egresses or transit nodes. However, since a transit
whether it lies on the path to any one destination, the traceroute node of a multicast LDP LSP is unable to determine whether it lies on
mode limited to specific egresses of such an LSP MUST NOT be used. the path to any one destination or any other transit node, the
traceroute mode limited to specific nodes of such an LSP MUST NOT be
used.
In the absence of a P2MP Egress Identifier TLV, the echo request is Note that the addresses specified in the P2MP Responder Identifier
asking for traceroute information applicable to all egresses. TLV need not be egresses: they could be transit nodes on the LSP. The
processing rules here and in the following sections apply equally to
egress and transit nodes.
In the absence of a P2MP Responder Identifier TLV, the echo request
is 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 Responder Identifier TLV the node 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 node MUST NOT return an echo response unless the
responding LSR lies on the path of the P2MP LSP to the egress responding node lies on the path of the P2MP LSP to the node (egress
identified by the P2MP Egress Identifier TLV carried on the request, or transit) identified by the P2MP Responder Identifier TLV carried
or if no such sub-TLV is present. on the 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 identify 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
it is important that the ingress should be able to correlate the echo responders (e.g., egresses), it is important that the ingress should
responses with the branches in the P2MP tree. Without this be able to correlate the echo responses with the branches in the P2MP
information the ingress will be unable to determine the correct tree. Without this information the ingress will be unable to
ordering of transit nodes. One possibility is for the ingress to poll determine the correct ordering of transit nodes. One possibility is
the path to each egress in turn, but this may be inefficient, for the ingress to poll the path to each responder in turn, but this
undesirable, or (in the case of multicast LDP LSPs) illegal. may be inefficient, undesirable, or (in the case of multicast LDP
LSPs) illegal.
The Downstream Mapping TLV that MUST be included in the echo response The Downstream Mapping TLV that MUST be included in the echo response
indicates the next hop from each responding LSR, and this information indicates the next hop from each responding node, and this
supplied by a non-branch LSR can be pieced together by the ingress to information supplied by a non-branch node can be pieced together by
reconstruct the P2MP tree although it may be necessary to refer to the ingress to reconstruct the P2MP tree although it may be necessary
the routing information distributed by the IGP to correlate next hop to refer to the routing information distributed by the IGP to
addresses and LSR reporting addresses in subsequent echo responses. correlate next hop addresses and node reporting addresses in
subsequent echo responses.
In order to facilitate more easy correlation of echo responses, the In order to facilitate more easy correlation of echo responses, the
Downstream Mapping TLV can also contain Multipath Information as Downstream Mapping TLV can also contain Multipath Information as
described in [RFC4379] to identify to which egress/egresses the echo described in [RFC4379] to identify to which responders (transit
response applies, and indicates. This information: nodes or egresses) the echo response applies. This information:
- MUST NOT be present for multicast LDP LSPs
- SHOULD be present for P2MP MPLS TE LSPs when the echo request - Cannot be present when the information is not known by the
applies to all egresses responding node. For example, for a multicast LDP LSP, the branch
node will not know through normal LDP signaling which leaf nodes
lie on which downstream branch.
- is RECCOMMENDED to be present for P2MP MPLS TE LSPs when the echo - SHOULD be present when the information is known by the responding
request is limited to a single egress. node. That is for P2MP MPLS TE LSPs when the echo request applies
to all egresses or to a specific single transit node or egress.
The format of the information in the Downstream Mapping TLV for The format of the information in the Downstream Mapping TLV for
P2MP MPLS LSPs is described in section 3.3.5 and 3.3.6. P2MP MPLS LSPs is described in section 3.3.5.
3.3.2. Traceroute Responses at Branch Nodes 3.3.2. Traceroute Responses at Branch Nodes
A branch node may need to identify more than one downstream interface A branch node may need to identify more than one downstream interface
in a traceroute echo response if some of the egresses that are being in a traceroute echo response if some of the nodes identified in the
traced lie on different branches. This will always be the case for P2MP Responder Identifier TLV that are being traced lie on different
any branch node if all egresses are being traced. branches. This will always be the case for any branch node if all
egresses are being traced.
[RFC4379] describes how multiple Downstream Mapping TLVs should be [RFC4379] describes how multiple Downstream Mapping TLVs should be
included in an echo response, each identifying exactly one downstream included in an echo response, each identifying exactly one downstream
interface that is applicable to the LSP. interface that is applicable to the LSP.
A branch node MUST follow the procedures described in Section 3.3.1 A branch node MUST follow the procedures described in Section 3.3.1
to determine whether it should respond to an echo request. The branch to determine whether it should respond to an echo request. The branch
node MUST add a Downstream Mapping TLV to the echo response for each node MUST add a Downstream Mapping TLV (or Downstream Detailed
Mapping TLV - see Section 3.3.7) to the echo response for each
outgoing branch that it reports, but it MUST NOT report branches that outgoing branch that it reports, but it MUST NOT report branches that
do not lie on the path to one of the destinations being traced. Thus do not lie on the path to one of the destinations being traced. Thus
a branch node may sometimes only need to respond with a single a branch node may sometimes only need to respond with a single
Downstream Mapping TLV, for example, consider the case where the Downstream Mapping TLV; for example, consider the case where the
traceroute is directed to only a single egress node. Therefore, traceroute is directed to only a single egress node. Therefore,
the presence of only one Downstream Mapping TLV in an echo response the presence of only one Downstream Mapping TLV in an echo response
does not guarantee that the reporting LSR is not a branch node. does not guarantee that the reporting node is not a branch node.
To report on the fact that an LSR is a branch node for the P2MP MPLS To report on its branching properties on a particular LSP, the
LSP a new B-flag is added to the Downstream Mapping TLV. The flag is responding node MAY include an optional TLV called the Node
set to zero to indicate that the reporting LSR is not a branch for Properties TLV. This new TLV (see Section 3.3.2.1) can carry sub-
this LSP, and is set to one to indicate that it is a branch. The flag TLVs, one of which (the Branching Properties sub-TLV - see Section
is placed in the fourth byte of the TLV that was previously reserved. 3.3.2.2) allows the reporting node to describe the branching
characteristics of the LSP at the reporting node.
The format of the information in the Downstream Mapping TLV for 3.3.2.1. Node Properties TLV
P2MP MPLS LSPs is described in section 3.3.5 and 3.3.6.
3.3.2.1. Correlating Traceroute Responses A new TLV has been added to the set of optional TLVs that may be
carried on an echo response message.
Type # Value Field
------ ------------
TBD Node properties
The Node Properties TLV MAY be included in an echo response message.
If more than one such TLV is present, the first MUST be processed and
subsequent instances SHOULD be ignored.
The Node Properties TLV is used to report characteristics of the
reporting node, and the LSP at that node. This distinguishes it from
the Downstream Mapping TLV [RFC4379] and the Downstream Detailed
Mapping TLV [DDMT] used to report characteristics of specific out-
segments an LSP.
The Node Properties TLV is a standard LSP Ping TLV as defined in
[RFC4379]. It has the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: First Sub-TLV :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ Further Sub-TLVs ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The content of the Node Properties TLV is a series of one or more
sub-TLVs. The Nore Properties TLV SHOULD contain one or more sub-TLVs
and MUST be ignored if there are no sub-TLVs present.
Each sub-TLV consists of the following fields as per [RFC4379]:
- Two octet Type field: A value indicating the sub-TLV type.
- Two octet Length field: A value indicating the total length of the
Value field.
- A Value field carrying the data of the sub-TLV. The content of the
Value field is padded to a four byte boundary with zero-filled
octets so that the Length field is always a multiple of 4.
3.3.2.2. Branching Properties Sub-TLV
This document defines the Branching Properties sub-TLV carried in the
Node Properties TLV. The Branching Properties sub-TLV is optional. If
more than one such sub-TLV is found in a Node Properties TLV, the
first MUST be processed and subsequent instances SHOULD be ignored.
The sub-TLV may be used for P2MP and P2P LSPs.
The Branching Properties sub-TLV is formed as described in Section
3.3.2.1. The Value field has the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Branch Count | Egress Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Downstream Branch Count
This field reports the number of downstream branches from the
reporting node for this LSP. The number may be zero for an egress,
one for a non-branch node, and more than one for a branch node.
Note that the value reported here may be greater than the number
of Downstream Mapping TLVs present in the echo response message
since those TLVs only report on the specific egresses queried. This
value may be of use in detecting faults caused by delay introduced
by the data replication mechanism at branch nodes.
Egress Count
This field reports the number of egresses local to the reporting
node. Thus, for non-zero values the reporting node is either a leaf
or a bud. When the value reported is non-zero, the reporting node
MAY also include an Egress Address Sub-TLV for each local egress
(see Section 3.3.2.3).
For example, a branch node that has two downstream next hops on the
LSP and that also delivers payload data to one local egress would set
the two fields to 2 and 1 respectively.
3.3.2.3. Egress Address Sub-TLV
This document defines the IPv4 and IPv6 Egress Address sub-TLVs
carried in the Node Properties TLV. These TLVs are optional, and more
than one instance of the sub-TLVs may legitimately be present.
The Egress Address sub-TLVs are formed as described in Section
3.3.2.1. The Value field has the following formats.
IPv4 Egress Address Sub-TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Egress Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Egress Address Sub-TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Egress Address |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Egress Address sub-TLVs are optional. They MAY be included in a
Node Properties TLV when reporting node is an egress (leaf or bud)
for the LSP being tested. The sub-TLV may be used for P2MP and P2P
LSPs.
When one or more Egress Address sub-TLVs are present and the Branch
Properties sub-TLV is also present, the value of the Egress Count
field in the Branch Properties sub-TLV SHOULD be the same as the
number of Egress Address sub-TLVs.
The address contained in an Egress Address sub-TLV is the egress
address to which the data is delivered. If there is just one egress
and if the egress address is the same as the local node address
carried in the main echo response message, both the Branching
Properties sub-TLV and the Egress Address sub-TLV MAY be omitted as
in legacy LSP Ping implementations.
3.3.2.4. Correlating Traceroute Responses
Just as with non-branches, it is important that the echo responses Just as with non-branches, it is important that the echo responses
from branch nodes provide correlation information that will allow the from branch nodes provide correlation information that will allow the
ingress to work out to which branch of the LSP the response applies. ingress to work out to which branch of the LSP the response applies.
The P2MP tree can be determined by the ingress using the identity of The P2MP tree can be determined by the ingress using the identity of
the reporting node and the next hop information from the previous the reporting node and the next hop information from the previous
echo response, just as with echo responses from non-branch nodes. echo response, just as with echo responses from non-branch nodes.
As with non-branch nodes, in order to facilitate more easy As with non-branch nodes, in order to facilitate more easy
correlation of echo responses, the Downstream Mapping TLV can also correlation of echo responses, the Downstream Mapping TLV can also
contain Multipath Information as described in [RFC4379] to identify contain Multipath Information as described in [RFC4379] to identify
to which egress/egresses the echo response applies, and indicates. to which nodes the echo response applies. This information:
This information:
- MUST NOT be present for multicast LDP LSPs
- SHOULD be present for P2MP MPLS TE LSPs when the echo request - Cannot be present when the information is not known by the
applies to all egresses responding node. For example, for a multicast LDP LSP, the branch
node will not know through normal LDP signaling which leaf nodes
lie on which downstream branch.
- is RECCOMMENDED to be present for P2MP MPLS TE LSPs when the echo - SHOULD be present when the information is known by the responding
request is limited to a single egress. node. That is for P2MP MPLS TE LSPs when the echo request applies
to all egresses or to a specific single transit node or egress.
The format of the information in the Downstream Mapping TLV for The format of the information in the Downstream Mapping TLV for
P2MP MPLS LSPs is described in section 3.3.5 and 3.3.6. P2MP MPLS LSPs is described in section 3.3.5.
3.3.3. Traceroute Responses at Bud Nodes 3.3.3. Traceroute Responses at Bud Nodes
Some nodes on a P2MP MPLS LSP may be egresses, but also have Some nodes on a P2MP MPLS LSP may be egresses, but also have
downstream LSRs. Such LSRs are known as bud nodes [RFC4461]. downstream node. Such nodes are known as bud nodes [RFC4461].
A bud node MUST respond to a traceroute echo request just as a branch A bud node MUST respond to a traceroute echo request just as a branch
node would, but it MUST also indicates to the ingress that it is an node would, but it MUST also indicate to the ingress that it is an
egress in its own right. This is achieved through the use of a new egress in its own right. The issue to be resolved here is how to
E-flag in the Downstream Mapping TLV that indicates that the indicate that the reporting node is an egress when it is also
reporting LSR is not a bud for this LSP (cleared to zero) or is a bud providing one or more Downstream Mapping TLVs that indicate that it
(set to one). A normal egress MUST NOT set this flag. has downstream neighbors.
The flag is placed in the fourth byte of the TLV that was previously This is achieved by the inclusion of a Node Properties TLV with a
reserved. Branch Properties sub-TLV indicating the number of local egresses and
the number of downstream branches. The bud node MAY also include one
or more Egress Address sub-TLVs in the Node Properties TLV to report
on the local egresses.
3.3.4. Non-Response to Traceroute Echo Requests 3.3.4. Non-Response to Traceroute Echo Requests
The nature of P2MP MPLS TE LSPs in the data plane means that The nature of P2MP MPLS TE LSPs in the data plane means that
traceroute echo requests may be delivered to the control plane of traceroute echo requests may be delivered to the control plane of
LSRs that must not reply to the request because, although they lie nodes 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 node that is
being traced. being traced.
Thus, an LSR on a P2MP MPLS LSP MUST NOT respond to an echo request Thus, a node 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 [RFC4379]
- 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
does not identify an egress that is reached through this LSR for
this particular P2MP MPLS LSP.
3.3.5. Modifications to the Downstream Mapping TLV
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
is a branch (set to one).
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
is a bud node (set to one).
The flags are placed in the fourth byte of the TLV that was - There is a P2MP Responder Identifier TLV present on the echo
previously reserved as shown below. All other fields are unchanged request (which means that the LSP is a P2MP MPLS TE LSP), but the
from their definitions in [RFC4379] except for the additional address does not identify a node that is reached through this node
information that can be carried in the Multipath Information (see for this particular P2MP MPLS LSP.
Section 3.3.6).
0 1 2 3 Note that when no response to an echo request is received by the
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 ingress (perhaps because the transit node has failed, or perhaps
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ because the transit node does not support LSP Ping), then as per
| MTU | Address Type | Reserved |E|B| [RFC4379] the subsequent echo request (with a larger TTL) SHOULD be
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sent with Downstream Mapping TLV "Downstream IP Address" field set to
| Downstream IP Address (4 or 16 octets) | the ALLROUTERs multicast address until a reply is received with a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Downstream Mapping TLV.
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash Key Type | Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. (Multipath Information) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.6. Additions to Downstream Mapping Multipath Information 3.3.5. Additions to Downstream Mapping Multipath Information
A new value for the Multipath Type is defined to indicate that the A new value for the Multipath Type is defined to indicate that the
reported Multipath Information applies to a P2MP MPLS TE LSP and reported Multipath Information applies to a P2MP MPLS TE LSP and may
may contain a list of egress identifiers that indicate the egress contain a list of node identifiers that indicate the egress nodes and
nodes that can be reached through the reported interface. This (in the case where the P2MP Responder Identifier TLV was used on the
Multipath Type MUST NOT be used for a multicast LDP LSP. echo request to identify non-egress nodes) transit nodes that can be
reached through the reported interface. This Multipath Type MUST NOT
be used for a multicast LDP LSP.
Type # Address Type Multipath Information Type # Address Type Multipath Information
--- ---------------- --------------------- --- ---------------- ------------------------------
TBD P2MP egresses List of P2MP egresses TBD P2MP responders List of reachable P2MP nodes
Note that a list of egresses may include IPv4 and IPv6 identifiers Note that a list of nodes may include IPv4 and IPv6 identifiers since
since these may be mixed in the P2MP MPLS TE LSP. these may be mixed in the P2MP MPLS TE LSP.
The Multipath Length field continues to identify the length of the The Multipath Length field continues to identify the length of the
Multipath Information just as in [RFC4379] (that is, not including Multipath Information just as in [RFC4379] (that is, not including
the downstream labels), and the downstream label (or potential the downstream labels), and the downstream label (or potential stack
stack thereof) is also handled just as in [RFC4379]. The format thereof) is also handled just as in [RFC4379]. The format of the
of the Multipath Information for a Multipath Type of P2MP Egresses Multipath Information for a Multipath Type of P2MP responders is as
is as follows. follows.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Egress Address (4 or 16 octets) | | Address Type | Responder Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (continued) | : | (continued) | :
+-+-+-+-+-+-+-+-+ : +-+-+-+-+-+-+-+-+ :
: Further Address Types and Egress Addresses : : Further Address Types and Responder Addresses :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type Address Type
This field indicates whether the egress address that follows is This field indicates whether the address that follows is an IPv4
an IPv4 or IPv6 address, and so implicitly encodes the length of or IPv6 address, and so implicitly encodes the length of the
the address. address.
Two values are defined and mirror the values used in the Address Two values are defined and mirror the values used in the Address
Type field of the Downstream Mapping TLV itself. Type field of the Downstream Mapping TLV itself.
Type # Address Type Type # Address Type
------ ------------ ------ ------------
1 IPv4 1 IPv4
3 IPv6 3 IPv6
Egress Address Responder Address
An egress of this P2MP MPLS TE LSP that is reached through the An egress or transit node of this P2MP MPLS TE LSP that is
interface indicated by the Downstream Mapping TLV and for which reached through the interface indicated by the Downstream
the traceroute echo request was enquiring. Mapping TLV and for which the traceroute echo request was
enquiring.
Note that padding to ensure that the whole Multipath information is
aligned to a four-octet boundary is applied only after the last
responder address in the list. That is, each successive Address Type
follows on immediately after the previous Responder Address.
3.3.6. Echo Response Reporting
Echo responses are generated in response to traceroute echo requests
at transit, branch, and bud nodes as described in Sections 3.3.1,
3.3.2, and 3.3.3, while egress responses are as described in
[RFC4379].
Note, however, that a branch or bud node may have multiple downstream
branches, and a transit node may have multiple downstream egresses
(reached on the same branch). It may be the case that different
conditions need to be reported for different branches or egresses.
The echo response message defined in [RFC4379] has space for only a
single return code and subcode pair, so where more than one return
condition is reported by a single node it acts as follows.
- It SHOULD use the Downstream Detailed Mapping TLV [DDMT] in place
of the Downstream Mapping TLV, and encode the return code as
described in Section 3.3.6.1.
- It MAY report each condition in a separate echo response in which
case MUST limit the downstream mapping information on each echo
response to those branches/egresses to which the response applies.
The use of multiple echo response messages to report errors might
cause issues for an initiator that does not know how many responses
it should wait for. For that reason, multiple messages should be
used with care.
3.3.6.1. Reporting Multiple Conditions Using The DDM TLV
When multiple different return codes are indicated on a single echo
response message they MUST be carried in separate instances on the
Downstream Detailed Mapping (DDM) TLV [DDMT]. That is, each instance
of a DDM TLV carries one return code, and all information carried in
that TLV MUST be limited to branches/egresses to which that return
code applies. However, more than one DDM TLV on the same echo
response MAY carry the same return code.
The echo response message still carries a Return Code and a Return
Subcode field. In order to clearly indicate that the relevant return
codes are carried in the DDM TLV, a new return code is defined to be
carried in the Return Code field of the echo response message as
follows:
Value Meaning
----- -------
TBD See DDM TLV for more details
The Return Subcode for this Return Code MUST be set to zero and
MUST be ignored.
The DDM TLV is defined as carrying a set of sub-TLVs. A new sub-TLV,
the Return Code sub-TLV, is defined here to carry a return code and
return subcode.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Return Subcode| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of the Return Code sub-TLV is 8.
Return Code
As defined for inclusion in the echo response message in [RFC4379].
Return Subcode
As defined for inclusion in the echo response message in [RFC4379].
Reserved
SHOULD be set to zero on transmission and MUST be ignored on
receipt.
If the Return Code of the echo response message is not set to "See
DDM TLV for more details" then any Return Code sub-TLV present in a
DDM TLV SHOULD be ignored.
If the Return Code of the echo response message is set to "See DDM
TLV for more details" then a Return Code sub-TLV MUST be present in
each DDM TLV. Subsequent Return Code sub-TLVs present in the same DDM
TLV SHOULD be ignored.
4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms
Bootstrapping of other OAM procedures can be achieved using the Bootstrapping of other OAM procedures can be achieved using the
MPLS Echo Request/Response messages. The LSP(s) under test are MPLS Echo Request/Response messages. The LSP(s) under test are
identified using the RSVP P2MP IPv4 or IPv6 Session sub-TLVs identified using the RSVP P2MP IPv4 or IPv6 Session sub-TLVs
(see Section 3.1.1) or the Multicast LDP FEC Stack sub-TLV (see Section 3.1.1) or the Multicast LDP FEC Stack sub-TLV
(see Section 3.1.2). (see Section 3.1.2).
Other sub-TLVs may be defined in other specifications to indicate Other sub-TLVs may be defined in other specifications to indicate
skipping to change at page 20, line 31 skipping to change at page 26, line 15
5. Non-compliant Routers 5. Non-compliant Routers
If an egress for a P2MP LSP does not support MPLS LSP ping, then no If an egress for a P2MP LSP does not support MPLS LSP ping, then no
reply will be sent, resulting in a "false negative" result. There is reply will be sent, resulting in a "false negative" result. There is
no protection for this situation, and operators may wish to ensure no protection for this situation, and operators may wish to ensure
that end points for P2MP LSPs are all equally capable of supporting that end points for P2MP LSPs are all equally capable of supporting
this function. Alternatively, the traceroute option can be used to this function. Alternatively, the traceroute option can be used to
verify the LSP nearly all the way to the egress, leaving the final verify the LSP nearly all the way to the egress, leaving the final
hop to be verified manually. hop to be verified manually.
If, in "traceroute" mode, a transit LSR does not support LSP ping, If, in "traceroute" mode, a transit node does not support LSP ping,
then no reply will be forthcoming from that LSR for some TTL, say n. then no reply will be forthcoming from that node for some TTL, say n.
The LSR originating the echo request SHOULD continue to send echo The node originating the echo request SHOULD continue to send echo
requests with TTL=n+1, n+2, ..., n+k in the hope that some transit request with TTL=n+1, n+2, ..., n+k to probe nodes further down the
LSR further downstream may support MPLS echo requests and reply. In path. In such a case, the echo request for TTL > n SHOULD be sent
such a case, the echo request for TTL > n MUST NOT have Downstream with Downstream Mapping TLV "Downstream IP Address" field set to the
Mapping TLVs, until a reply is received with a Downstream Mapping. ALLROUTERs multicast address as described in Section 3.3.4 until a
reply is received with a Downstream Mapping TLV.
Note that the settings of the new bit flags in the Downstream Mapping
TLV are such that a legacy LSR would return them with value zero
which most closely matches the likely default behavior of a legacy
LSR.
6. OAM Considerations 6. OAM Considerations
The procedures in this document provide OAM functions for P2MP MPLS The procedures in this document provide OAM functions for P2MP MPLS
LSPs and may be used to enable bootstrapping of other OAM procedures. LSPs and may be used to enable bootstrapping of other OAM procedures.
In order to be fully operational several considerations must be made. In order to be fully operational several considerations must be made.
- Scaling concerns dictate that only cautious use of LSP Ping should - Scaling concerns dictate that only cautious use of LSP Ping should
be made. In particular, sending an LSP Ping to all egresses of a be made. In particular, sending an LSP Ping to all egresses of a
skipping to change at page 21, line 33 skipping to change at page 27, line 13
of the LSP Ping MIB module used for P2P LSPs. of the LSP Ping MIB module used for P2P LSPs.
7. IANA Considerations 7. IANA Considerations
7.1. New Sub-TLV Types 7.1. New Sub-TLV Types
Three new sub-TLV types are defined for inclusion within the LSP Ping Three new sub-TLV types are defined for inclusion within the LSP Ping
[RFC4379] Target FEC Stack TLV (TLV type 1). [RFC4379] Target FEC Stack TLV (TLV type 1).
IANA is requested to assign sub-type values to the following IANA is requested to assign sub-type values to the following
sub-TLVs from the Multiprotocol Label Switching Architecture (MPLS) sub-TLVs from the "Multiprotocol Label Switching Architecture (MPLS)
Label Switched Paths (LSPs) Parameters - TLVs registry. Label Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and
sub-TLVs" sub-registry.
RSVP P2MP IPv4 Session (see Section 3.1.1) RSVP P2MP IPv4 Session (see Section 3.1.1). Suggested value 17.
RSVP P2MP IPv6 Session (see Section 3.1.1) RSVP P2MP IPv6 Session (see Section 3.1.1). Suggested value 18.
Multicast LDP FEC Stack (see Section 3.1.2) Multicast LDP FEC Stack (see Section 3.1.2). Suggested value 19.
7.2. New Multipath Type 7.2. New Multipath Type
Section 3.3 of [RFC4379] defines a set of values for the LSP Ping Section 3.3 of [RFC4379] defines a set of values for the LSP Ping
Multipath Type. These values are currently not tracked by IANA. Multipath Type. These values are currently not tracked by IANA.
A new value for the LSP Ping Multipath Type is defined in Section A new value for the LSP Ping Multipath Type is defined in Section
3.3.6 of this document to indicate that the reported Multipath 3.3.5 of this document to indicate that the reported Multipath
Information applies to a P2MP MPLS TE LSP. Information applies to a P2MP MPLS TE LSP.
IANA is requested to create a new registry as follows: IANA is requested to create a new registry as follows:
Multiprotocol Label Switching Architecture (MPLS) Label Switched "Multiprotocol Label Switching Architecture (MPLS) Label Switched
Paths (LSPs) - Multipath Types Paths (LSPs) - Multipath Types"
Key Type Multipath Information Key Type Multipath Information
--- ---------------- --------------------- --- ---------------- ---------------------
0 no multipath Empty (Multipath Length = 0) [RFC4379] 0 no multipath Empty (Multipath Length = 0) [RFC4379]
2 IP address IP addresses [RFC4379] 2 IP address IP addresses [RFC4379]
4 IP address range low/high address pairs [RFC4379] 4 IP address range low/high address pairs [RFC4379]
8 Bit-masked IP IP address prefix and bit mask [RFC4379] 8 Bit-masked IP IP address prefix and bit mask [RFC4379]
address set address set
9 Bit-masked label set Label prefix and bit mask [RFC4379] 9 Bit-masked label set Label prefix and bit mask [RFC4379]
xx P2MP egress IP List of P2MP egresses [thisDoc] xx P2MP responder IP List of P2MP responders [thisDoc]
addresses addresses
A suggested value of xx is TBD by the MPLS Working Group. A suggested value of xx is 16.
New values from this registry are to be assigned only by Standards New values from this registry are to be assigned only by Standards
Action. Action.
7.3. New TLVs 7.3. New TLVs
Two new LSP Ping TLV types are defined for inclusion in LSP Ping Three new LSP Ping TLV types are defined for inclusion in LSP Ping
messages. messages.
IANA is reuqested to assign a new value from the Multiprotocol Label IANA is requested to assign a new value from the "Multi-Protocol
Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters Label Switching Architecture (MPLS) Label Switched Paths (LSPs)
- TLVs registry as follows using a Standards Action value. Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry as
follows using a Standards Action value.
P2MP Responder Identifier TLV (see Section 3.2.4) is a mandatory
TLV. Suggested value 11.
P2MP Egress Identifier TLV (see Section 3.2.4)
Two sub-TLVs are defined Two sub-TLVs are defined
- Type 1: IPv4 P2MP Egress Identifier (see Section 3.2.4) - Type 1: IPv4 P2MP Responder Identifier (see Section 3.2.4)
- Type 2: IPv6 P2MP Egress Identifier (see Section 3.2.4) - Type 2: IPv6 P2MP Responder Identifier (see Section 3.2.4)
Echo Jitter TLV (see Section 3.2.5) Echo Jitter TLV (see Section 3.2.5) is a mandatory TLV. Suggested
value 12.
Node Properties TLV (see Section 3.2.2.1) is an optional TLV.
Suggested value 32768.
Three sub-TLVs are defined
- Type 1: IPv4 Egress Address
- Type 2: IPv6 Egress Address
- Type 3: Branch Properties
7.4. New Return Code
A new Return Code is defined in Section 3.3.6.1.
IANA is requested to assign a new Return Code value for the "Multi-
Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Parameters" registry, "Return Codes" sub-registry as follows using a
Standards Action value.
Value Meaning
----- -------
TBD See DDM TLV for more details
Suggested value 14.
7.5. New Sub-TLV Value for the Downstream Detailed Mapping TLV
[DDMT] defines a TLV called the Downstream Detailed Mapping TLV and
requests IANA to maintain a registry of sub-TLVs that it can carry.
Section 3.3.6.1 of this document defines a new sub-TLV.
IANA is requested to assign a TLV type value as follows using a
Standards Action value from the range 0-32767.
Sub-Type Value Field
--------- ------------
TBD Return Code
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 implications of many egresses to P2MP MPLS LSPs, there is a
stronger concern to regulate the LSP Ping traffic passed to the stronger concern to regulate the LSP Ping traffic passed to the
control plane by the use of a rate limiter applied to the LSP Ping control plane by the use of a rate limiter applied to the LSP Ping
well-known UDP port. Note that this rate limiting might lead to well-known UDP port. Note that this rate limiting might lead to
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 and Mustapha Aissaoui for their
for useful discussions. review, and to Yakov Rekhter for useful discussions.
The authors would like to thank Vanson Lim, Danny Prairie, Reshad The authors would like to thank Vanson Lim, Danny Prairie, Reshad
Rahman, and Ben Niven-Jenkins for their comments and suggestions. Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin Bahadur, Tetsuya
Murakami and Michael Hua 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 41 skipping to change at page 30, line 14
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.
[DDMT] Bahadur, N., Kompella, K., and Swallow, G., "Mechanism
for Performing LSP-Ping over MPLS Tunnels", draft-ietf-
mpls-lsp-ping-enhanced-dsmap, work in progress.
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., [RFC4687] Yasukawa, S., Farrel, A., King, D., and Nadeau, T.,
skipping to change at page 25, line 4 skipping to change at page 31, line 30
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Zafar Ali Zafar Ali
Cisco Systems Inc. Cisco Systems Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, ON, K2K 3E8, Canada. Kanata, ON, K2K 3E8, Canada.
Phone: 613-889-6158 Phone: 613-889-6158
Email: zali@cisco.com Email: zali@cisco.com
Bill Fenner Bill Fenner
AT&T Labs -- Research Arastra, Inc.
75 Willow Rd. 275 Middlefield Rd.
Suite 50
Menlo Park, CA 94025 Menlo Park, CA 94025
United States Email: fenner@fenron.com
Email: fenner@research.att.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
Email: swallow@cisco.com Email: swallow@cisco.com
Thomas D. Nadeau Thomas D. Nadeau
British Telecom British Telecom
BT Centre BT Centre
 End of changes. 102 change blocks. 
278 lines changed or deleted 579 lines changed or added

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