draft-ietf-mpls-p2mp-lsp-ping-04.txt   draft-ietf-mpls-p2mp-lsp-ping-05.txt 
Network Working Group Seisho Yasukawa (Editor) Network Working Group Seisho Yasukawa (Editor)
Internet-Draft NTT Internet-Draft NTT
Intended Status: Standards Track Adrian Farrel (Editor) Intended Status: Standards Track Adrian Farrel (Editor)
Expires: September 2007 Old Dog Consulting Created: October 28, 2007 Old Dog Consulting
Expires: April 28, 2008
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-04.txt draft-ietf-mpls-p2mp-lsp-ping-05.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 46 skipping to change at page 1, line 48
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 recognised 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 mechanism 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 ......................................... 4
2. Notes on Motivation ............................................ 5 2. Notes on Motivation ............................................ 5
2.1. Basic Motivations for LSP Ping ............................... 5 2.1. Basic Motivations for LSP Ping ............................... 5
2.2. Motivations for LSP Ping for P2MP LSPs ....................... 6 2.2. Motivations for LSP Ping for P2MP LSPs ....................... 6
2.3 Bootstrapping other OAM Procedures using LSP Ping ............. 7 2.3 Bootstrapping Other OAM Procedures Using LSP Ping ............. 7
3. Operation of LSP Ping for a P2MP LSP ........................... 8 3. Operation of LSP Ping for a P2MP LSP ........................... 8
3.1. Identifying the LSP Under Test ............................... 8 3.1. Identifying the LSP Under Test ............................... 8
3.1.1. Identifying a P2MP MPLS TE LSP ............................. 8 3.1.1. Identifying a P2MP MPLS TE LSP ............................. 8
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV ........................... 8 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV ........................... 9
3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV ........................... 9 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV ........................... 9
3.1.2. Identifying a Multicast LDP LSP ............................ 9 3.1.2. Identifying a Multicast LDP LSP ........................... 10
3.1.2.1. Multicast LDP FEC Stack Sub-TLV ......................... 10 3.1.2.1. Multicast LDP FEC Stack Sub-TLV ......................... 10
3.2. Ping Mode Operation ......................................... 11 3.2. Ping Mode Operation ......................................... 11
3.2.1. Controlling Responses to LSP Pings ........................ 11 3.2.1. Controlling Responses to LSP Pings ........................ 11
3.2.2. Ping Mode Egress Procedures ............................... 12 3.2.2. Ping Mode Egress Procedures ............................... 12
3.2.3. Jittered Responses ........................................ 12 3.2.3. Jittered Responses ........................................ 12
3.2.4. P2MP Egress Identifier TLV and Sub-TLVs ................... 13 3.2.4. P2MP Egress Identifier TLV and Sub-TLVs ................... 13
3.2.5. Echo Jitter TLV ........................................... 14 3.2.5. Echo Jitter TLV ........................................... 14
3.3. Traceroute Mode Operation ................................... 14 3.3. Traceroute Mode Operation ................................... 14
3.3.1. Traceroute Responses at Non-Branch Nodes .................. 15 3.3.1. Traceroute Responses at Non-Branch Nodes .................. 15
3.3.1.1. Correlating Traceroute Responses ........................ 15 3.3.1.1. Correlating Traceroute Responses ........................ 15
skipping to change at page 3, line 23 skipping to change at page 3, line 23
- 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.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
- 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
- Change coordinates for Tom Nadeau. Section 13.
- Fix typos.
- Update references.
- Resolve all acronym expansions.
1. Introduction 1. Introduction
Simple and efficient mechanisms that can be used to detect data plane Simple and efficient mechanisms that can be used to detect data plane
failures in point-to-point (P2P) MPLS LSP are described in failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS)
[RFC4379]. The techniques involve information carried in an MPLS Label Switched Paths (LSP) are described in [RFC4379]. The techniques
involve information carried in an MPLS "echo request" and "echo
"echo request" and "echo reply", and mechanisms for transporting the reply", and mechanisms for transporting the echo reply. The echo
echo reply. The echo request and reply messages provide sufficient request and reply messages provide sufficient information to check
information to check correct operation of the data plane, as well as correct operation of the data plane, as well as a mechanism to verify
a mechanism to verify the data plane against the control plane, and the data plane against the control plane, and thereby localize
thereby localize faults. The use of reliable reply channels for echo faults. The use of reliable channels for echo reply messages as
request messages as described in [RFC4379] enables more robust fault described in [RFC4379] enables more robust fault isolation. This
isolation. This collection of mechanisms is commonly referred to as collection of mechanisms is commonly referred to as "LSP Ping".
"LSP Ping".
The requirements for point-to-multipoint (P2MP) MPLS traffic The requirements for point-to-multipoint (P2MP) MPLS traffic
engineered (TE) LSPs are stated in [RFC4461]. [P2MP-RSVP] specifies a engineered (TE) LSPs are stated in [RFC4461]. [RFC4875] specifies a
signaling solution for establishing P2MP MPLS TE LSPs. signaling solution for establishing P2MP MPLS TE LSPs.
The requirements for point-to-multipoint extensions to the Label The requirements for point-to-multipoint extensions to the Label
Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP] Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP]
specifies extensions to LDP for P2MP MPLS. specifies extensions to LDP for P2MP MPLS.
P2MP MPLS LSPs are at least as vulnerable to data plane faults or to P2MP MPLS LSPs are at least as vulnerable to data plane faults or to
discrepancies between the control and data planes as their P2P discrepancies between the control and data planes as their P2P
counterparts. Mechanisms are, therefore, desirable to detect such counterparts. Mechanisms are, therefore, desirable to detect such
data plane faults in P2MP MPLS LSPs as described in [RFC4687]. data plane faults in P2MP MPLS LSPs as described in [RFC4687].
This document extends the techniques described in [RFC4379] such This document extends the techniques described in [RFC4379] such
that they may be applied to P2MP MPLS LSPs and so that they can be that they may be applied to P2MP MPLS LSPs and so that they can be
used to bootstrap other OAM procedures such as [MCAST-CV]. This used to bootstrap other Operations and Management (OAM) procedures
document stresses the reuse of existing LSP Ping mechanisms used for such as [MCAST-CV]. This document stresses the reuse of existing LSP
P2P LSPs, and applies them to P2MP MPLS LSPs in order to simplify Ping mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs
implementation and network operation. in order to simplify implementation and network operation.
1.1 Design Considerations 1.1 Design Considerations
An important consideration for designing LSP Ping for P2MP MPLS LSPs An important consideration for designing LSP Ping for P2MP MPLS LSPs
is that every attempt is made to use or extend existing mechanisms is that every attempt is made to use or extend existing mechanisms
rather than invent new mechanisms. rather than invent new mechanisms.
As for P2P LSPs, a critical requirement is that the echo request As for P2P LSPs, a critical requirement is that the echo request
messages follow the same data path that normal MPLS packets would messages follow the same data path that normal MPLS packets traverse.
traverse. However, it can be seen this notion needs to be extended However, it can be seen this notion needs to be extended for P2MP
for P2MP MPLS LSPs, as in this case an MPLS packet is replicated so MPLS LSPs, as in this case an MPLS packet is replicated so that it
that it arrives at each egress (or leaf) of the P2MP tree. arrives at each egress (or leaf) of the P2MP tree.
MPLS echo requests are meant primarily to validate the data plane, MPLS echo requests are meant primarily to validate the data plane,
and they can then be used to validate data plane state against the and they can then be used to validate data plane state against the
control plane. They may also be used to bootsrap other OAM procedures control plane. They may also be used to bootstrap other OAM
such as [MPLS-BFD] and [MCAST-CV]. As pointed out in [RFC4379], procedures such as [MPLS-BFD] and [MCAST-CV]. As pointed out in
mechanisms to check the liveness, function, and consistency of the [RFC4379], mechanisms to check the liveness, function, and
control plane are valuable, but such mechanisms are not a feature of consistency of the control plane are valuable, but such mechanisms
LSP Ping and are not covered in this document. are not a feature of LSP Ping and are not covered in this document.
As is described in [RFC4379], to avoid potential Denial of Service As is described in [RFC4379], to avoid potential Denial of Service
attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to
the control plane. A rate limiter should be applied to the well-known the control plane. A rate limiter should be applied to the well-known
UDP port defined for use by LSP Ping traffic. UDP port defined for use by LSP Ping traffic.
2. Notes on Motivation 2. Notes on Motivation
2.1. Basic Motivations for LSP Ping 2.1. Basic Motivations for LSP Ping
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 would enable users to detect such traffic "black holes" or tool that enables users to detect such traffic "black holes" or
misrouting within a reasonable period of time; and a mechanism to misrouting within a reasonable period of time. A mechanism to isolate
isolate faults. faults is also required.
[RFC4379] describes a mechanism that accomplishes these goals. This [RFC4379] describes a mechanism that accomplishes these goals. This
mechanism is modeled after the ping/traceroute paradigm: ping (ICMP mechanism is modeled after the ping/traceroute paradigm: ping (ICMP
echo request [RFC792]) is used for connectivity checks, and echo request [RFC792]) is used for connectivity checks, and
traceroute is used for hop-by-hop fault localization as well as path traceroute is used for hop-by-hop fault localization as well as path
tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode
for testing MPLS LSPs. for testing MPLS LSPs.
The basic idea as expressed in [RFC4379] is to test that the packets The basic idea as expressed in [RFC4379] is to test that the packets
that belong to a particular Forwarding Equivalence Class (FEC) that belong to a particular Forwarding Equivalence Class (FEC)
skipping to change at page 6, line 7 skipping to change at page 6, line 16
that it is indeed a transit LSR for this path; this LSR also returns that it is indeed a transit LSR for this path; this LSR also returns
further information that helps to check the control plane against the further information that helps to check the control plane against the
data plane, i.e., that forwarding matches what the routing protocols data plane, i.e., that forwarding matches what the routing protocols
determined as the path. determined as the path.
One way these tools can be used is to periodically ping a FEC to One way these tools can be used is to periodically ping a FEC to
ensure connectivity. If the ping fails, one can then initiate a ensure connectivity. If the ping fails, one can then initiate a
traceroute to determine where the fault lies. One can also traceroute to determine where the fault lies. One can also
periodically traceroute FECs to verify that forwarding matches the periodically traceroute FECs to verify that forwarding matches the
control plane; however, this places a greater burden on transit LSRs control plane; however, this places a greater burden on transit LSRs
and thus should be used with caution. and should be used with caution.
2.2. Motivations for LSP Ping for P2MP LSPs 2.2. Motivations for LSP Ping for P2MP LSPs
As stated in [RFC4687], MPLS has been extended to encompass P2MP As stated in [RFC4687], MPLS has been extended to encompass P2MP
LSPs. As with P2P MPLS LSPs, the requirement to detect, handle and LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and
diagnose control and data plane defects is critical. For operators diagnose control and data plane defects is critical. For operators
deploying services based on P2MP MPLS LSPs the detection and deploying services based on P2MP MPLS LSPs, the detection and
specification of how to handle those defects is important because specification of how to handle those defects is important because
such defects may affect the fundamentals of an MPLS network, but also such defects may affect the fundamentals of an MPLS network, but also
because they may impact service level specification commitments for because they may impact service level specification commitments for
customers of their network. customers of their network.
P2MP LDP [P2MP-LDP] uses the Label Distribution Protocol to establish P2MP LDP [P2MP-LDP] uses the Label Distribution Protocol to establish
multicast LSPs. These LSPs distribute data from a single source to multicast LSPs. These LSPs distribute data from a single source to
one or more destinations across the network according to the next one or more destinations across the network according to the next
hops indicated by the routing protocols. Each LSP is identified by an hops indicated by the routing protocols. Each LSP is identified by an
MPLS multicast FEC. MPLS multicast FEC.
P2MP MPLS TE LSPs [P2MP-RSVP] may be viewed as MPLS tunnels with a P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a
single ingress and multiple egresses. The tunnels, built on P2MP single ingress and multiple egresses. The tunnels, built on P2MP
LSPs, are explicitly routed through the network. There is no concept LSPs, are explicitly routed through the network. There is no concept
or applicability of a FEC in the context of a P2MP MPLS TE LSP. or applicability of a FEC in the context of a P2MP MPLS TE LSP.
MPLS packets inserted at the ingress of a P2MP LSP are delivered MPLS packets inserted at the ingress of a P2MP LSP are delivered
equally (barring faults) to all egresses. In consequence, the basic equally (barring faults) to all egresses. In consequence, the basic
idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an
intention to test that packets that enter (at the ingress) a intention to test that packets that enter (at the ingress) a
particular P2MP LSP actually end their MPLS path on the LSRs that are particular P2MP LSP actually end their MPLS path on the LSRs that are
the (intended) egresses for that LSP. The idea may be extended to the (intended) egresses for that LSP. The idea may be extended to
check selectively that such packets reach specific egresses. check selectively that such packets reach specific egresses.
The technique in this document makes this test by sending an LSP Ping The technique in this document makes this test by sending an LSP Ping
echo request message along the same data path as the MPLS packets. An echo request message along the same data path as the MPLS packets. An
echo request also carries the identification of the P2MP MPLS LSP echo request also carries the identification of the P2MP MPLS LSP
(multicast LSP or P2MP TE LSP) that it is testing. The echo request (multicast LSP or P2MP TE LSP) that it is testing. The echo request
is forwarded just as any other packet using that LSP and so is is forwarded just as any other packet using that LSP, and so is
replicated at branch points of the LSP and should be delivered to all replicated at branch points of the LSP and should be delivered to all
egresses. In "ping" mode (basic connectivity check), the echo request egresses. In "ping" mode (basic connectivity check), the echo request
should reach the end of the path, at which point it is sent to the should reach the end of the path, at which point it is sent to the
control plane of the egress LSRs, which verify that they are indeed control 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 egress (leaf) of the P2MP LSP. An echo response message is sent by
an egress to the ingress to confirm the successful receipt (or an egress to the ingress to confirm the successful receipt (or
announce the erroneous arrival) of the echo request. announce the erroneous arrival) of the echo request.
In "traceroute" mode (fault isolation), the echo request is sent to In "traceroute" mode (fault isolation), the echo request is sent to
the control plane at each transit LSR, and the control plane checks the control plane at each transit LSR, and the control plane checks
skipping to change at page 7, line 24 skipping to change at page 7, line 33
LSP, it might be expected that a large number of echo responses would LSP, it might be expected that a large number of echo responses would
arrive at the ingress independently but at approximately the same arrive at the ingress independently but at approximately the same
time. Under some circumstances this might cause congestion at or time. Under some circumstances this might cause congestion at or
around the ingress LSR. Therefore, the procedures described in this around the ingress LSR. Therefore, the procedures described in this
document provide a 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 or a set of egresses. 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 utilise the LSP
Ping procedures in this document to provide bootstrapping mechanisms Ping procedures in this document to provide bootstrapping mechanisms
as described in Section 2.3. as described in Section 2.3.
LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure
connectivity to any or all of the egresses. If the ping fails, connectivity to any or all of the egresses. If the ping fails,
the operator or an automated process can then initiate a traceroute the operator or an automated process can then initiate a traceroute
to determine where the fault is located within the network. A to determine where the fault is located within the network. A
traceroute may also be used periodically to verify that data plane traceroute may also be used periodically to verify that data plane
forwarding matches the control plane state; however, this places an forwarding matches the control plane state; however, this places an
increased burden on transit LSRs and should be used infrequently and increased burden on transit LSRs and should be used infrequently and
with caution. with caution.
2.3 Bootstrapping other OAM Procedures using LSP Ping 2.3 Bootstrapping Other OAM Procedures Using LSP Ping
[MPLS-BFD] describes a process where LSP Ping [RFC4379] is used to [MPLS-BFD] describes a process where LSP Ping [RFC4379] is used to
bootstrap the Bidirectional Forwarding Detection (BFD) mechanism bootstrap the Bidirectional Forwarding Detection (BFD) mechanism
[BFD] for use to track the liveliness of an MPLS LSP. In particular [BFD] for use to track the liveliness of an MPLS LSP. In particular
BFD can be used to detect a data plane failure in the forwarding BFD can be used to detect a data plane failure in the forwarding
path 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 desribed in [MCAST-CV]. It relies on using the MPLS echo request and
Request/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 LSRs, 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
request message MUST carry a Target FEC Stack TLV, and this MUST request message MUST carry a Target FEC Stack TLV, and this MUST
carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4
Session or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs carry Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs
fields from the RSVP-TE P2MP Session and Sender-Template objects carry fields from the RSVP-TE P2MP Session and Sender-Template
[P2MP-RSVP] and so provide sufficient information to uniquely objects [RFC4875] and so provide sufficient information to uniquely
identify the LSP. identify the LSP.
The new sub-TLVs are assigned sub-type identifiers as follows, and The new sub-TLVs are assigned sub-type identifiers as follows, and
are described in the following sections. are described in the following sections.
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
TBD 20 RSVP P2MP IPv4 Session TBD 20 RSVP P2MP IPv4 Session
TBD 56 RSVP P2MP IPv6 Session TBD 56 RSVP P2MP IPv6 Session
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV
The format of the RSVP P2MP IPv4 Session Sub-TLV value field is The format of the RSVP P2MP IPv4 Session sub-TLV value field is
specified in the following figure. The value fields are taken from specified in the following figure. The value fields are taken from
the definitions of the P2MP IPv4 LSP Session Object, and the P2MP the definitions of the P2MP IPv4 LSP Session Object and the P2MP
IPv4 Sender-Template Object in [P2MP-RSVP]. Note that the Sub-Group IPv4 Sender-Template Object in [RFC4875]. Note that the Sub-Group
ID of the Sender-Template is not required. 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 the definitions of the P2MP IPv6 LSP Session Object, and the
P2MP IPv6 Sender-Template Object in [P2MP-RSVP]. Note that the P2MP IPv6 Sender-Template Object in [RFC4875]. Note that the
Sub-Group ID of the Sender-Template is not required. 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 9, line 51 skipping to change at page 10, line 9
| IPv6 tunnel sender address | | IPv6 tunnel sender address |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.2. Identifying a Multicast LDP LSP 3.1.2. Identifying a Multicast LDP LSP
[RFC4379] defines how a P2P LDP LSP under test may be identified in [RFC4379] defines how a P2P LDP LSP under test may be identified in
an echo request. A Target FEC Stack TLV is used to carry one or more an echo request. A Target FEC Stack TLV is used to carry one or more
Sub-TLVs (for example, an IPv4 Prefix FEC Sub-TLV) that identify the sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the
LSP. LSP.
In order to identify a multicast LDP LSP under test, the echo request In order to identify a multicast LDP LSP under test, the echo request
message MUST carry a Target FEC Stack TLV, and this MUST carry message MUST carry a Target FEC Stack TLV, and this MUST carry
exactly one new sub-TLVs: the Multicast LDP FEC Stack Sub-TLV. This exactly one new sub-TLV: the Multicast LDP FEC Stack sub-TLV. This
Sub-TLVs fields from the multicast LDP messages [P2MP-LDP] and so sub-TLV uses fields from the multicast LDP messages [P2MP-LDP] and so
provides sufficient information to uniquely identify the LSP. provides sufficient information to uniquely identify the LSP.
The new sub-TLV is assigned a sub-type identifier as follows, and The new sub-TLV is assigned a sub-type identifier as follows, and
is described in the following sections. is described in the following section.
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
TBD Variable Multicast LDP FEC Stack TBD Variable Multicast LDP FEC Stack
3.1.2.1. Multicast LDP FEC Stack Sub-TLV 3.1.2.1. Multicast LDP FEC Stack Sub-TLV
The format of the Multicast LDP FEC Stack Sub-TLV is shown below. The format of the Multicast LDP FEC Stack sub-TLV is shown below.
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 Family | Address Length| Root LSR Addr | | Address Family | Address Length| Root LSR Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Root LSR Address (Cont.) ~ ~ Root LSR Address (Cont.) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 11 skipping to change at page 12, line 11
Note that the ingress of a multicast LDP LSP will not know the Note that the ingress of a multicast LDP LSP will not know the
identities of the egresses of the LSP except by some external means identities of the egresses of the LSP except by some external means
such as running P2MP LSP Ping to all egresses. such as running P2MP LSP Ping to all egresses.
3.2.2. Ping Mode Egress Procedures 3.2.2. Ping Mode Egress Procedures
An egress LSR is RECOMMENDED to rate limit its receipt of echo An egress LSR is RECOMMENDED to rate limit its receipt of echo
request messages as described in [RFC4379]. After rate limiting, an request messages as described in [RFC4379]. After rate limiting, an
egress LSR that receives an echo request carrying an RSVP P2MP IPv4 egress LSR that receives an echo request carrying an RSVP P2MP IPv4
Session sub-TLV, an RSVP P2MP IPv6 Session sub-TLV, or a Multicast Session sub-TLV, an RSVP P2MP IPv6 Session sub-TLV, or a Multicast
LDP FEC Stack Sub-TLV MUST determine whether it is an intended egress LDP FEC Stack sub-TLV MUST determine whether it is an intended egress
of the P2MP LSP in question by checking with the control plane. If it of the P2MP LSP in question by checking with the control plane. If it
is not supposed to be an egress, it MUST respond according to the is not supposed to be an egress, it MUST respond according to the
setting of the Response Type field in the echo message following the setting of the Response Type field in the echo message following the
rules defined in [RFC4379]. rules defined in [RFC4379].
If the egress LSR that receives an echo request and allows it through If the egress LSR that receives an echo request and allows it through
its rate limiting is an intended egress of the P2MP LSP, the LSR MUST its rate limiting is an intended egress of the P2MP LSP, the LSR MUST
check to see whether it is an intended Ping recipient. If a P2MP check to see whether it is an intended Ping recipient. If a P2MP
Egress Identifier TLV is present and contains an address that Egress 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 LSR, the LSR 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]. If the P2MP Egress message following the rules defined in [RFC4379]. If the P2MP Egress
Identifier TLV is present, but does not identify the egress LSR, it Identifier TLV is present, but does not identify the egress LSR, it
MUST NOT respond to the echo request. If the P2MP Egress Identifier MUST NOT respond to the echo request. If the P2MP Egress Identifier
TLV is not present (or, in the error case, is present but does not TLV is not present (or, in the error case, is present but does not
a sub-TLVs), but the egress LSR that received the echo request is an contain any sub-TLVs), but the egress LSR that received the echo
intended egress of the LSP, the LSR MUST respond according to the request is an intended egress of the LSP, the LSR MUST respond
setting of the Response Type field in the echo message following the according to the setting of the Response Type field in the echo
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
pinged since it helps prevent the ingress (or nearby routers) from pinged since it helps prevent the ingress (or nearby routers) from
being swamped by responses, or from discarding responses due to rate being swamped by responses, or from discarding responses due to rate
limits that have been applied. limits that have been applied.
It is desirable for the ingress to be able to control the bounds It is desirable for the ingress to be able to control the bounds
within which the egress delays the response. If the tree size is within which the egress delays the response. If the tree size is
small only a small amount of jitter is required, but if the tree is small, only a small amount of jitter is required, but if the tree is
large greater jitter is needed. The ingress informs the egresses of large, greater jitter is needed. The ingress informs the egresses of
the jitter bound by supplying a value in a new TLV (the Echo Jitter the jitter bound by supplying a value in a new TLV (the Echo Jitter
TLV) carried on the Echo request message. If this TLV is present, TLV) carried on the echo request message. If this TLV is present,
the responding egress MUST delay sending a response for a random the responding egress MUST delay sending a response for a random
amount of time between zero seconds and the value indicated in the amount of time between zero seconds and the value indicated in the
TLV. If the TLV is absent, the responding egress SHOULD NOT introduce TLV. If the TLV is absent, the responding egress SHOULD NOT introduce
any additional delay in responding to the echo request. any additional delay in responding to the echo request.
LSP ping SHOULD NOT be used to attempt to measure the round-trip LSP ping SHOULD NOT be used to attempt to measure the round-trip
time for data delivery. This is because the LSPs are unidirectional, time for data delivery. This is because the 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/response MAY be used to The timestamp fields in the echo request/response MAY be used to
deduce some information about delivery times and particularly the deduce some information about delivery times and particularly the
skipping to change at page 13, line 47 skipping to change at page 13, line 47
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 Egress Identifier TLV only has meaning on an echo request
message. If present on an echo response message, it SHOULD be message. If present on an echo response message, it SHOULD be
ignored. ignored.
Two Sub-TLVs are defined for inclusion in the P2MP Egress Identifier Two sub-TLVs are defined for inclusion in the P2MP Egress Identifier
TLV carried on the echo request message. These are: TLV carried on the echo request message. These are:
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
1 4 IPv4 P2MP Egress Identifier 1 4 IPv4 P2MP Egress Identifier
2 16 IPv6 P2MP Egress Identifier 2 16 IPv6 P2MP Egress Identifier
The value of an IPv4 P2MP Egress Identifier consists of four octets The value of an IPv4 P2MP Egress Identifier consists of four octets
of an IPv4 address. The IPv4 address is in network byte order. 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 IPv6 P2MP Egress Identifier consists of sixteen
skipping to change at page 15, line 36 skipping to change at page 15, line 36
packet MUST be passed to the control plane as specified in [RFC4379]. packet MUST be passed to the control plane as specified in [RFC4379].
If the LSP under test is a multicast LDP LSP and if the echo request If the LSP under test is a multicast LDP LSP and if the echo request
carries a P2MP Egress Identifier TLV the LSR MUST treat the echo carries a P2MP Egress Identifier TLV the LSR MUST treat the echo
request as malformed and MUST process it according to the rules request as malformed and MUST process it according to the rules
specified in [RFC4379]. specified in [RFC4379].
Otherwise, the LSR MUST NOT return an echo response unless the Otherwise, the LSR MUST NOT return an echo response unless the
responding LSR lies on the path of the P2MP LSP to the egress responding LSR lies on the path of the P2MP LSP to the egress
identified by the P2MP Egress Identifier TLV carried on the request, identified by the P2MP Egress Identifier TLV carried on the request,
or if no such Sub-TLV is present. or if no such sub-TLV is present.
If sent, the echo response MUST identifiy the next hop of the path of If sent, the echo response MUST identifiy the next hop of the path of
the LSP in the data plane by including a Downstream Mapping TLV as the LSP in the data plane by including a Downstream Mapping TLV as
described in [RFC4379]. described in [RFC4379].
3.3.1.1. Correlating Traceroute Responses 3.3.1.1. Correlating Traceroute Responses
When traceroute is being simultaneously applied to multiple egresses, When traceroute is being simultaneously applied to multiple egresses,
it is important that the ingress should be able to correlate the echo it is important that the ingress should be able to correlate the echo
responses with the branches in the P2MP tree. Without this responses with the branches in the P2MP tree. Without this
skipping to change at page 20, line 11 skipping to change at page 20, line 11
Egress Address Egress Address
An egress of this P2MP MPLS TE LSP that is reached through the An egress of this P2MP MPLS TE LSP that is reached through the
interface indicated by the Downstream Mapping TLV and for which interface indicated by the Downstream Mapping TLV and for which
the traceroute echo request was enquiring. the traceroute echo request was enquiring.
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
the OAM procedures being bootstrapped, and to describe the bootstrap the OAM procedures being bootstrapped, and to describe the bootstrap
parameters. Further details of the bootstrapping processes and the parameters. Further details of the bootstrapping processes and the
bootstrapped OAM processes are described in other documents. For bootstrapped OAM processes are described in other documents. For
example, see [MPLS-BFD] and [MCAST-CV]. example, see [MPLS-BFD] and [MCAST-CV].
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
skipping to change at page 21, line 29 skipping to change at page 21, line 29
- A MIB module is required for the control and management of LSP Ping - A MIB module is required for the control and management of LSP Ping
operations, and to enable the reported information to be inspected. operations, and to enable the reported information to be inspected.
There is no reason to believe this should not be a simple extension There is no reason to believe this should not be a simple extension
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.
RSVP P2MP IPv4 Session (see Section 3.1.1) RSVP P2MP IPv4 Session (see Section 3.1.1)
RSVP P2MP IPv6 Session (see Section 3.1.1) RSVP P2MP IPv6 Session (see Section 3.1.1)
Multicast LDP FEC Stack (see Section 3.1.2) Multicast LDP FEC Stack (see Section 3.1.2)
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.
skipping to change at page 24, line 5 skipping to change at page 24, line 5
[RFC4461] Yasukawa, S., "Signaling Requirements for Point to [RFC4461] Yasukawa, S., "Signaling Requirements for Point to
Multipoint Traffic Engineered Multiprotocol Label Multipoint Traffic Engineered Multiprotocol Label
Switching (MPLS) Label Switched Paths (LSPs)", Switching (MPLS) Label Switched Paths (LSPs)",
RFC 4461, April 2006. RFC 4461, April 2006.
[RFC4687] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., [RFC4687] Yasukawa, S., Farrel, A., King, D., and Nadeau, T.,
"Operations and Management (OAM) Requirements for "Operations and Management (OAM) Requirements for
Point-to-Multipoint MPLS Networks", RFC 4687, September Point-to-Multipoint MPLS Networks", RFC 4687, September
2006. 2006.
[P2MP-RSVP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S.,
Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp, "Extensions to Resource Reservation Protocol - Traffic
work in progress. Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for
point-to-multipoint extensions to the Label Distribution point-to-multipoint extensions to the Label Distribution
Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress.
[P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol
Extensions for Point-to-Multipoint and Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths", Multipoint-to-Multipoint Label Switched Paths",
draft-ietf-mpls-ldp-p2mp, work in progress. draft-ietf-mpls-ldp-p2mp, work in progress.
skipping to change at page 25, line 14 skipping to change at page 25, line 18
United States United States
Email: fenner@research.att.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
Cisco Systems, Inc. British Telecom
1414 Massachusetts Ave BT Centre
Boxborough, MA 01719 81 Newgate Street
Email: tnadeau@cisco.com EC1A 7AJ
London
Email: tom.nadeau@bt.com
14. Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 44 change blocks. 
80 lines changed or deleted 94 lines changed or added

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