draft-ietf-mpls-p2mp-lsp-ping-01.txt   draft-ietf-mpls-p2mp-lsp-ping-02.txt 
Network Working Group Seisho Yasukawa (NTT) Network Working Group Seisho Yasukawa (Editor)
IETF Internet Draft Adrian Farrel (Olddog Consulting) IETF Internet Draft NTT
Proposed Status: Standards Track Zafar Ali (Cisco Systems) Proposed Status: Standards Track Adrian Farrel (Editor)
Expires: October 2006 Bill Fenner (AT&T Research) Expires: March 2007 Olddog Consulting
Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic
Engineering - Extensions to LSP Ping
draft-ietf-mpls-p2mp-lsp-ping-01.txt September 2006
Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol
Label Switching (MPLS) - Extensions to LSP Ping
draft-ietf-mpls-p2mp-lsp-ping-02.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 36 skipping to change at page 1, line 39
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.txt. http://www.ietf.org/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Recent proposals have extended the scope of Multi-Protocol Label Recent proposals have extended the scope of Multiprotocol Label
Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs) Switching (MPLS) Label Switched Paths (LSPs) to encompass
to encompass point-to-multipoint (P2MP) TE 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 TE LSPs. This documents does not replace any of the mechanism of MPLS LSPs. This documents does not replace any of the mechanism of
LSP Ping, but clarifies their applicability to P2MP MPLS TE LSPs, and LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and
extends the techniques and mechanisms of LSP Ping to the P2MP TE 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 ................................................... 3 1. Introduction ................................................... 3
1.1 Design Considerations ...................................... 3 1.1 Design Considerations ......................................... 4
2. Notes on Motivation ............................................ 4 2. Notes on Motivation ............................................ 4
2.1. Basic Motivations for LSP Ping ............................ 4 2.1. Basic Motivations for LSP Ping ............................... 4
2.2. Motivations for LSP Ping for P2MP TE LSPs ................. 5 2.2. Motivations for LSP Ping for P2MP LSPs ....................... 5
3. Operation of LSP Ping for a P2MP TE LSP ........................ 6 2.3 Bootstrapping other OAM Procedures using LSP Ping ............. 7
3.1. Identifying the LSP Under Test ............................ 6 3. Operation of LSP Ping for a P2MP LSP ........................... 7
3.1.1. RSVP P2MP IPv4 Session Sub-TLV .......................... 6 3.1. Identifying the LSP Under Test ............................... 7
3.1.2. RSVP P2MP IPv6 Session Sub-TLV .......................... 7 3.1.1. Identifying a P2MP MPLS TE LSP ............................. 7
3.2. Ping Mode Operation ....................................... 7 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV ........................... 8
3.2.1. Controlling Responses to LSP Pings ...................... 7 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV ........................... 8
3.2.2. P2MP Egress Identifier sub-TLVs ......................... 9 3.1.2. Identifying a Multicast LDP LSP ............................ 9
3.2.3. Echo Jitter TLV ......................................... 9 3.1.2.1. Multicast LDP FEC Stack Sub-TLV ......................... 10
3.3. Traceroute Mode Operation ................................ 10 3.2. Ping Mode Operation ......................................... 11
3.3.1. Traceroute Responses at Non-Branch Nodes ............... 10 3.2.1. Controlling Responses to LSP Pings ........................ 11
3.3.2. Traceroute Responses at Branch Nodes .................. 11 3.2.2. Ping Mode Egress Procedures ............................... 11
3.3.3. Traceroute Responses at Bud Nodes ...................... 12 3.2.3. Jittered Responses ........................................ 12
3.3.4. Non-Response to Traceroute Echo Requests ............... 12 3.2.4. P2MP Egress Identifier TLV and Sub-TLVs ................... 12
3.3.5. Modifications to the Downstream Mapping TLV ............ 12 3.2.5. Echo Jitter TLV ........................................... 13
3.3.6. Additions to Downstream Mapping Multipath Information .. 13 3.3. Traceroute Mode Operation ................................... 14
4. Non-compliant Routers ......................................... 14 3.3.1. Traceroute Responses at Non-Branch Nodes .................. 15
5. OAM Considerations ............................................ 15 3.3.1.1. Correlating Traceroute Responses ........................ 15
6. IANA Considerations ........................................... 15 3.3.2. Traceroute Responses at Branch Nodes ..................... 16
6.1. New Sub TLV Types ........................................ 15 3.3.2.1. Correlating Traceroute Responses ........................ 16
6.2. New Multipath Type ....................................... 16 3.3.3. Traceroute Responses at Bud Nodes ......................... 17
7. Security Considerations ....................................... 16 3.3.4. Non-Response to Traceroute Echo Requests .................. 17
8. Acknowledgements .............................................. 16 3.3.5. Modifications to the Downstream Mapping TLV ............... 17
9. Intellectual Property Considerations .......................... 16 3.3.6. Additions to Downstream Mapping Multipath Information ..... 18
10. Normative References ......................................... 17 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms .. 19
11. Informational References ..................................... 17 5. Non-compliant Routers ......................................... 20
12. Authors' Addresses ........................................... 17 6. OAM Considerations ............................................ 20
13. Full Copyright Statement ..................................... 18 7. IANA Considerations ........................................... 21
7.1. New Sub-TLV Types ........................................... 21
7.2. New Multipath Type .......................................... 21
7.3. New TLVs .................................................... 22
8. Security Considerations ....................................... 22
9. Acknowledgements .............................................. 22
10. Intellectual Property Considerations ......................... 22
11. Normative References ......................................... 23
12. Informative References ....................................... 23
13. Authors' Addresses ........................................... 24
14. Full Copyright Statement ..................................... 25
0. Change Log
This section to be removed before publication as an RFC.
0.1 Changes from 00 to 01
- Update references.
- Fix boilerplate.
0.2 Changes from 01 to 02
- Update entire document so that it is not specific to MPLS-TE, but
also includes multicast LDP LSPs.
- Move the egress identifier sub-TLVs from the FEC Stack TLV to a new
egress identifier TLV.
- Include Multicast LDP FEC Stack Sub-TLV definition from [MCAST-CV].
- Add brief section on use of LSP Ping for bootstrapping.
- Add new references to References section.
- Add details of two new authors.
1. Introduction 1. Introduction
Simple and efficient mechanisms that can be used to detect data plane Simple and efficient mechanisms that can be used to detect data plane
failures in point-to-point (P2P) MPLS LSP are described in failures in point-to-point (P2P) MPLS LSP are described in
[RFC4379]. The techniques involve information carried in an MPLS [RFC4379]. The techniques involve information carried in an MPLS
"echo request" and "echo reply", and mechanisms for transporting the "echo request" and "echo reply", and mechanisms for transporting the
echo reply. The echo request and reply messages provide sufficient echo reply. The echo request and reply messages provide sufficient
information to check correct operation of the data plane, as well as information to check correct operation of the data plane, as well as
a mechanism to verify the data plane against the control plane, and a mechanism to verify the data plane against the control plane, and
thereby localize faults. The use of reliable reply channels for echo thereby localize faults. The use of reliable reply channels for echo
request messages as described in [RFC4379] enables more robust fault request messages as described in [RFC4379] enables more robust fault
isolation. This collection of mechanisms is commonly referred to as isolation. This collection of mechanisms is commonly referred to as
"LSP Ping". "LSP Ping".
The requirement for point-to-multipoint (P2MP) MPLS traffic The requirements for point-to-multipoint (P2MP) MPLS traffic
engineered (TE) LSPs is stated in [RFC4461]. [P2MP-RSVP] specifies a engineered (TE) LSPs are stated in [RFC4461]. [P2MP-RSVP] specifies a
signaling solution for establishing P2MP MPLS TE LSPs. P2MP MPLS TE signaling solution for establishing P2MP MPLS TE LSPs.
LSPs are at least as vulnerable to data plane faults or to
The requirements for point-to-multipoint extensions to the Label
Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP]
specifies extensions to LDP for P2MP MPLS.
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. LSP Ping Mechanisms are, therefore, also desirable to counterparts. Mechanisms are, therefore, desirable to detect such
detect such data plane faults in P2MP MPLS TE LSPs. data plane faults in P2MP MPLS LSPs as described in [P2MP-OAM-REQ].
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 TE LSPs. This document stresses that they may be applied to P2MP MPLS LSPs and so that they can be
the reuse of existing LSP Ping mechanisms used for P2P LSPs, and used to bootstrap other OAM procedures such as [MCAST-CV]. This
applies them to P2MP MPLS TE LSPs in order to simplify implementation document stresses the reuse of existing LSP Ping mechanisms used for
and network operation. P2P LSPs, and applies them to P2MP MPLS LSPs in order to simplify
implementation and network operation.
1.1 Design Considerations 1.1 Design Considerations
As mentioned earlier, an important consideration for designing LSP An important consideration for designing LSP Ping for P2MP MPLS LSPs
Ping for P2MP MPLS TE LSPs is that every attempt is made to use or is that every attempt is made to use or extend existing mechanisms
extend existing mechanisms rather than invent new mechanisms. rather than invent new mechanisms.
As for P2P LSPs, a critical requirement is that the echo request As for P2P LSPs, a critical requirement is that the echo request
messages follow the same data path that normal MPLS packets would messages follow the same data path that normal MPLS packets would
traverse. However, it can be seen this notion needs to be extended traverse. However, it can be seen this notion needs to be extended
for P2MP MPLS TE LSPs, as in this case an MPLS packet is replicated for P2MP MPLS LSPs, as in this case an MPLS packet is replicated so
so that it arrives at each egress (or leaf) of the P2MP tree. that it arrives at each egress (or leaf) of the P2MP tree.
MPLS echo requests are meant primarily to validate the data plane, MPLS echo requests are meant primarily to validate the data plane,
and they can then be used to validate against the control plane. and they can then be used to validate against the control plane. They
may also be used to bootsrap other OAM procedures such as [MPLS-BFD].
As pointed out in [RFC4379], mechanisms to check the liveness, As pointed out in [RFC4379], mechanisms to check the liveness,
function and consistency of the control plane are valuable, but such function, and consistency of the control plane are valuable, but such
mechanisms are not covered in this document. mechanisms 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
skipping to change at page 5, line 5 skipping to change at page 5, line 34
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 thus should be used with caution.
2.2. Motivations for LSP Ping for P2MP TE LSPs 2.2. Motivations for LSP Ping for P2MP LSPs
P2MP MPLS TE LSPs may be viewed as MPLS tunnels with a single ingress As stated in [P2MP-OAM-REQ], MPLS has been extended to encompass
and multiple egresses. MPLS packets inserted at the ingress are P2MP LSPs. As with P2P MPLS LSPs, the requirement to detect, handle
delivered equally (barring faults) to all egresses. There is no and diagnose control and data plane defects is critical. For
concept or applicability of an FEC in the context of a P2MP MPLS TE operators deploying services based on P2MP MPLS LSPs the detection
LSP. and specification of how to handle those defects is important because
such defects may affect the fundamentals of an MPLS network, but also
because they may impact service level specification commitments for
customers of their network.
In consequence, the basic idea of LSP Ping for P2MP MPLS TE LSPs may P2MP LDP [P2MP-LDP] uses the Label Distribution Protocol to establish
be expressed as an intention to test that packets that enter (at the multicast LSPs. These LSPs distribute data from a single source to
ingress) a particular P2MP MPLS TE LSP actually end their MPLS path one or more destinations across the network according to the next
on the LSRs that are the (intended) egresses for that LSP. The idea hops indicated by the routing protocols. Each LSP is identified by an
may be extended to check selectively that such packets reach a MPLS multicast FEC.
specific egress.
P2MP MPLS TE LSPs [P2MP-RSVP] may be viewed as MPLS tunnels with a
single ingress and multiple egresses. The tunnels, built on P2MP
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.
MPLS packets inserted at the ingress of a P2MP LSP are delivered
equally (barring faults) to all egresses. In consequence, the basic
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
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
check selectively that such packets reach a specific egress.
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 TE LSP echo request also carries the identification of the P2MP MPLS LSP
that it is testing. The echo request is forwarded just as any other (multicast LSP or P2MP TE LSP) that it is testing. The echo request
packet using that LSP. In "ping" mode (basic connectivity check), the is forwarded just as any other packet using that LSP and so is
echo request should reach the end of the path, at which point it is replicated at branch points of the LSP and should be delivered to all
sent to the control plane of the egress LSR, which then verifies that egresses. In "ping" mode (basic connectivity check), the echo request
it is indeed an egress (leaf) of the P2MP MPLS TE LSP. An echo should reach the end of the path, at which point it is sent to the
response message is sent by the egress to the ingress to confirm the control plane of the egress LSRs, which then verify that they are
successful receipt (or announce the erroneous arrival) of the echo indeed an egress (leaf) of the P2MP LSP. An echo response message is
request. sent by an egress to the ingress to confirm the successful receipt
(or announce the erroneous arrival) of the echo request.
In "traceroute" mode (fault isolation), the echo request is sent to In "traceroute" mode (fault isolation), the echo request is sent to
the control plane at each transit LSR, and the control plane checks the control plane at each transit LSR, and the control plane checks
that it is indeed a transit LSR for this P2MP MPLS TE LSP. The that it is indeed a transit LSR for this P2MP MPLS LSP. The transit
transit LSR also returns information on an echo response that helps LSR also returns information on an echo response that helps verify
verify the control plane against the data plane. That is, the the control plane against the data plane. That is, the information
information is used by the ingress to check that the data plane is used by the ingress to check that the data plane forwarding
forwarding matches what is signaled by the control plane. matches what is signaled by the control plane.
P2MP MPLS TE LSPs may have many egresses, and it is not necessarily P2MP MPLS LSPs may have many egresses, and it is not necessarily the
the intention of the initiator of the ping or traceroute operation to intention of the initiator of the ping or traceroute operation to
collect information about the connectivity or path to all egresses. collect information about the connectivity or path to all egresses.
Indeed, in the event of pinging all egresses of a large P2MP MPLS TE Indeed, in the event of pinging all egresses of a large P2MP MPLS
LSP, it might be expected that a large number of echo responses would LSP, it might be expected that a large number of echo responses would
arrive at the ingress independently but at approximately the same arrive at the ingress independently but at approximately the same
time. Under some circumstances this might cause congestion at or time. Under some circumstances this might cause congestion at or
around the ingress LSR. Therefore, the procedures described in this around the ingress LSR. Therefore, the procedures described in this
document provide the ability for the initiator to limit the scope of document provide a procedure that allows the responders to randomly
an LSP Ping echo request (ping or traceroute mode) to one specific delay (or jitter) their responses so that the chances of swamping the
intended egress of the P2MP MPLS TE LSP, or to target all egresses. ingress are reduced.
Further, in the event that the initiator wishes to use ping or
traceroute to a large number of leaves simultaneously, this document
provides a procedure that allows the responders to randomly delay or
jitter their responses so that the chances of swamping the ingress
are reduced.
LSP Ping can be used to periodically ping a P2MP MPLS TE LSP to Further, the procedures in this document allow the initiator to limit
ensure connectivity to any or all of the egresses. If the ping fails, the scope of an LSP Ping echo request (ping or traceroute mode) to
one specific intended egress.
The scalability issues surrounding LSP Ping for P2MP MPLS LSPs may be
addressed by other mechanisms such as [MCAST-CV] that utilise the LSP
Ping procedures in this document to provide bootstrapping mechanisms
as described in Section 2.3.
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,
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.
3. Operation of LSP Ping for a P2MP TE LSP 2.3 Bootstrapping other OAM Procedures using LSP Ping
This section describes how LSP Ping is applied to P2MP MPLS TE LSPs. [MPLS-BFD] describes a process where LSP Ping [RFC4379] is used to
bootstrap the Bidirectional Forwarding Detection (BFD) mechanism
[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
path of an MPLS LSP.
Requirements for MPLS P2MP LSPs extend to hundreds or even thousands
of endpoints. If a protocol required explicit acknowledgments to
each probe for connectivity verification, the response load at the
root would be overwhelming.
A more scalable approach to monitoring P2MP LSP connectivity is
desribed in [MCAST-CV]. It relies on using the MPLS Echo
Request/Response messages of LSP Ping [RFC4379] to bootstrap the
monitoring mechanism in a manner similar to [MPLS-BFD]. The actual
monitoring is done using a separate process defined in [MCAST-CV].
Note that while the approach described in [MCAST-CV] was developed in
response to the multicast scalability problem, it can be applied to
P2P LSPs as well.
3. Operation of LSP Ping for a P2MP LSP
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
[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 or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs carry
the various fields from the RSVP-TE P2MP Session and Sender-Template fields from the RSVP-TE P2MP Session and Sender-Template objects
objects [P2MP-RSVP] and so provide sufficient information to uniquely [P2MP-RSVP] 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. 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 [P2MP-RSVP]. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 19 skipping to change at page 8, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.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 [P2MP-RSVP]. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 47 skipping to change at page 9, line 25
| Extended Tunnel ID | | Extended Tunnel ID |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| 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
[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
Sub-TLVs (for example, an IPv4 Prefix FEC Sub-TLV) that identify the
LSP.
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
exactly one new sub-TLVs: the Multicast LDP FEC Stack Sub-TLV. This
Sub-TLVs fields from the multicast LDP messages [P2MP-LDP] and so
provides sufficient information to uniquely identify the LSP.
The new sub-TLV is assigned a sub-type identifier as follows, and
is described in the following sections.
Sub-Type # Length Value Field
---------- ------ -----------
TBD Variable Multicast LDP FEC Stack
3.1.2.1. Multicast LDP FEC Stack Sub-TLV
The format of the Multicast LDP FEC Stack Sub-TLV is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address Length| Root LSR Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Root LSR Address (Cont.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family
A two octet quantity containing a value from ADDRESS FAMILY
NUMBERS in [IANA-PORT] that encodes the address family for the
Root LSR Address.
Address Length
The length of the Root LSR Address in octets.
Root LSR Address
An address of the LSR at the root of the P2MP LSP encoded
according to the Address Family field.
Opaque Length
The length of the Opaque Value, in octets.
Opaque Value
An opaque value elements of which uniquely identifies the P2MP LSP
in the context of the Root LSR.
If the Address Family is IPv4, the Address Length MUST be 4. If the
Address Family is IPv6, the Address Length MUST be 16. No other
Address Family values are defined at present.
3.2. Ping Mode Operation 3.2. Ping Mode Operation
3.2.1. Controlling Responses to LSP Pings 3.2.1. Controlling Responses to LSP Pings
As described above, it may be desirable to restrict the operation As described in Section 2.2, it may be desirable to restrict the
of LSP Ping to a single egress. Since echo requests are forwarded operation of LSP Ping to a single egress. Since echo requests are
through the data plane without interception by the control plane forwarded through the data plane without interception by the control
(compare with traceroute mode), there is no facility to limit the plane (compare with traceroute mode), there is no facility to limit
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 is identified in the FEC However, the intended egress under test can be identified by the
Stack TLV by the inclusion of an IPv4 P2MP Egress Identifier sub-TLV inclusion of a P2MP Egress Identifier TLV containing an IPv4 P2MP
or an IPv6 P2MP Egress Identifier sub-TLV. Such TLVs, if used, MUST Egress Identifier sub-TLV or an IPv6 P2MP Egress Identifier sub-TLV.
be placed after the RSVP P2MP IPv4/6 Session sub-TLV. In this version of the protocol the P2MP Egress Identifier TLV SHOULD
contain precisely one sub-TLV. If the TLV contains no sub-TLVs it
MUST be processed as if it were absent. If the TLV contains more than
one sub-TLV, the first MUST be precessed as described in this
document and subsequent sub-TLVs MUST 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 all P2MP Egress Identifier sub-TLVs. an echo request by omitting the P2MP Egress Identifier TLV.
An egress LSR that receives an echo request carrying an RSVP P2MP Note that the ingress of a multicast LDP LSP will not know the
IPv4/6 Session sub-TLV MUST determine whether it is an intended identities of the egresses of the LSP except by some external means
egress of the P2MP LSP in question by checking with the control such as running P2MP LSP Ping to all egresses.
plane. If it 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 rules defined in [RFC4379].
If the egress that receives an echo request is an intended egress, 3.2.2. Ping Mode Egress Procedures
the LSR MUST check to see whether it is an intended Ping recipient.
If a P2MP Egress Identifier sub-TLV is present and contains an An egress LSR is RECOMMENDED to rate limit its receipt of echo
address that indicates any address that is local to the egress LSR, request messages as described in [RFC4379]. After rate limiting, an
it MUST respond according to the setting of the Response Type field egress LSR that receives an echo request carrying an RSVP P2MP IPv4
in the echo message following the rules defined in [RFC4379]. If the Session sub-TLV, an RSVP P2MP IPv6 Session sub-TLV, or a Multicast
P2MP Egress Identifier sub-TLV is present, but does not identify the LDP FEC Stack Sub-TLV MUST determine whether it is an intended egress
egress LSR, it MUST NOT respond to the echo request. If the P2MP of the P2MP LSP in question by checking with the control plane. If it
Egress identifier is not present, but the egress that received the is not supposed to be an egress, it MUST respond according to the
echo request is an intended egress, it MUST respond according to setting of the Response Type field in the echo message following the
the setting of the Response Type field in the echo message following rules defined in [RFC4379].
the rules defined in [RFC4379].
If the egress LSR that receives an echo request is an intended egress
of the P2MP LSP, the LSR MUST check to see whether it is an intended
Ping recipient. If a P2MP Egress Identifier TLV is present and
contains an address that 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 message following the rules defined in
[RFC4379]. If the P2MP Egress Identifier TLV is present, but does
not identify the egress LSR, it MUST NOT respond to the echo request.
If the P2MP Egress Identifier TLV is not present, but the egress LSR
that received the echo request is an intended egress of the LSP, the
LSR MUST respond according to the setting of the Response Type field
in the echo message following the rules defined in [RFC4379].
3.2.3. Jittered Responses
The initiator (ingress) of a ping request MAY request the responding 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
skipping to change at page 9, line 21 skipping to change at page 12, line 44
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.2. P2MP Egress Identifier sub-TLVs 3.2.4. P2MP Egress Identifier TLV and Sub-TLVs
Two new sub-TLVs are defined for inclusion in the Target FEC Stack A new TLV is defined for inclusion in the Echo request message.
TLV (type 1) carried on the echo request message. These are:
The P2MP Egress Identifier TLV is assigned the TLV type value TBD and
is encoded as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = TBD (P2MP Egress ID TLV)| Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-TLVs:
Zero, one or more sub-TLVs as defined below.
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 be processed
as described in this document, and subsequent sub-TLVs MUST be
ignored.
The P2MP Egress Identifier TLV only has meaning on an echo request
message. If present on an echo response message, it SHOULD be
ignored.
Two Sub-TLVs are defined for inclusion in the P2MP Egress Identifier
TLV carried on the echo request message. These are:
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
(TBD) 4 IPv4 P2MP Egress Identifier 1 4 IPv4 P2MP Egress Identifier
(TBD) 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
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.3. 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 |
skipping to change at page 10, line 36 skipping to change at page 14, line 36
downstream interfaces and labels used by the reported LSP from the downstream interfaces and labels used by the reported LSP from the
responding LSR. In this way, by successively sending out echo responding LSR. In this way, by successively sending out echo
requests with increasing TTLs, the ingress may gain a picture of the requests with increasing TTLs, the ingress may gain a picture of the
path and resources used by an LSP up to the point of failure when no path and resources used by an LSP up to the point of failure when no
response is received, or an error response is generated by an LSR response is received, or an error response is generated by an LSR
where the control plane does not expect to be handling the LSP. where the control plane does not expect to be handling the LSP.
This mode of operation is equally applicable to P2MP MPLS TE LSPs This mode of operation is equally applicable to P2MP MPLS TE LSPs
as described in the following sections. as described in the following sections.
The traceroute mode can be applied to a single destination, or to all The traceroute mode can be applied to all destinations of the P2MP
destinations of the P2MP tree just as in the ping mode. That is, the tree just as in the ping mode. In the case of P2MP MPLS TE LSPs, the
IPv4/6 P2MP Egress Identifier sub-TLVs may be used to identify a traceroute mode can also be applied to individual destinations
specific egress for which traceroute information is requested. In the identified by the presence of a P2MP Egress Identifier TLV. However,
absence of an IPv4/6 P2MP Egress Identifier sub-TLV, the echo request since a transit LSR of a multicast LDP LSP is unable to determine
is asking for traceroute information applicable to all egresses. whether it lies on the path to any one destination, the traceroute
mode limited to a single egress of such an LSP MUST NOT be used.
In the absence of a P2MP Egress 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 and When the TTL for the MPLS packet carrying an echo request expires the
the message is passed to the control plane, an echo response MUST packet MUST be passed to the control plane as specified in [RFC4379].
only be returned if the responding LSR lies on the path to the egress
identified by the IPv4/6 P2MP Egress Identifier carried on the
request, or if no such sub-TLV is present.
The echo response identifies the next hop of the path in the data If the LSP under test is a multicast LDP LSP and if the echo request
plane by including a Downstream Mapping TLV as described in carries a P2MP Egress Identifier TLV the LSR MUST treat the echo
[RFC4379]. request as malformed and MUST process it according to the rules
specified in [RFC4379].
Otherwise, the LSR MUST NOT return an echo response unless the
responding LSR lies on the path of the P2MP LSP to the egress
identified by the P2MP Egress Identifier TLV carried 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
the LSP in the data plane by including a Downstream Mapping TLV as
described in [RFC4379].
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
information the ingress will be unable to determine the correct information the ingress will be unable to determine the correct
ordering of transit nodes. One possibility is for the ingress to poll ordering of transit nodes. One possibility is for the ingress to poll
the path to each egress in turn, but this may be inefficient or the path to each egress in turn, but this may be inefficient,
undesirable. Therefore, the echo response contains additional undesirable, or (in the case of multicast LDP LSPs) illegal.
information in the Multipath Information field of the Downstream
Mapping TLV that identifies to which egress/egresses the echo The Downstream Mapping TLV that MUST be included in the echo response
response applies. This information MUST be present when the echo indicates the next hop from each responding LSR, and this information
request applies to all egresses, and is RECCOMMENDED to be present supplied by a non-branch LSR can be pieced together by the ingress to
even when the echo request is limited to a single egress. reconstruct the P2MP tree although it may be necessary to refer to
the routing information distributed by the IGP to correlate next hop
addresses and LSR reporting addresses in subsequent echo responses.
In order to facilitate more easy correlation of echo responses, the
Downstream Mapping TLV can also contain Multipath Information as
described in [RFC4379] to identify to which egress/egresses the echo
response applies, and indicates. This information:
- MUST NOT be present for multicast LDP LSPs
- SHOULD be present for P2MP MPLS TE LSPs when the echo request
applies to all egresses
- is RECCOMMENDED to be present for P2MP MPLS TE LSPs when the echo
request is limited to a single 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 TE LSPs is described in section 3.3.5 and 3.3.6. P2MP MPLS LSPs is described in section 3.3.5 and 3.3.6.
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 egresses that are being
traced lie on different branches. This will always be the case for traced lie on different branches. This will always be the case for
any branch node if all egresses are being traced. 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.
Just as with non-branches, it is important that the echo responses A branch node MUST follow the procedures described in Section 3.3.1
provide correlation information that will allow the ingress to work to determine whether it should respond to an echo request. The branch
out to which branch of the LSP the response applies. Further, when node MUST add a Downstream Mapping TLV to the echo response for each
multiple downstream interfaces are identified, it is necessary to outgoing branch that it reports, but it MUST NOT report branches that
indicate which egresses are reached through which branches. This is do not lie on the path to one of the destinations being traced. Thus
achieved exactly as for non-branch nodes: that is, by including a a branch node may sometimes only need to respond with a single
list of egresses as part of the Multipath Information field of the Downstream Mapping TLV, for example, consider the case where the
appropriate Downstream Mapping TLV. traceroute is directed to only a single egress node. Therefore,
Note also that a branch node may sometimes only need to respond with
a single Downstream Mapping TLV. For example, consider the case where
the 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 LSR is not a branch node.
To report on the fact that an LSR is or is not a branch node for the To report on the fact that an LSR is a branch node for the P2MP MPLS
P2MP MPLS TE LSP a new B-flag is added to the Downstream Mapping TLV. LSP a new B-flag is added to the Downstream Mapping TLV. The flag is
The flag is set to zero to indicate that the reporting LSR is not a set to zero to indicate that the reporting LSR is not a branch for
branch for this LSP, and is set to one to indicate that it is a this LSP, and is set to one to indicate that it is a branch. The flag
branch. The flag is placed in the fourth byte of the TLV that was is placed in the fourth byte of the TLV that was previously reserved.
previously reserved.
The format of the information in the Downstream Mapping TLV for The format of the information in the Downstream Mapping TLV for
P2MP MPLS TE LSPs is described in section 3.3.5 and 3.3.6. P2MP MPLS LSPs is described in section 3.3.5 and 3.3.6.
3.3.2.1. Correlating Traceroute Responses
Just as with non-branches, it is important that the echo responses
from branch nodes provide correlation information that will allow the
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 reporting node and the next hop information from the previous
echo response, just as with echo responses from non-branch nodes.
As with non-branch nodes, in order to facilitate more easy
correlation of echo responses, the Downstream Mapping TLV can also
contain Multipath Information as described in [RFC4379] to identify
to which egress/egresses the echo response applies, and indicates.
This information:
- MUST NOT be present for multicast LDP LSPs
- SHOULD be present for P2MP MPLS TE LSPs when the echo request
applies to all egresses
- is RECCOMMENDED to be present for P2MP MPLS TE LSPs when the echo
request is limited to a single egress.
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.
3.3.3. Traceroute Responses at Bud Nodes 3.3.3. Traceroute Responses at Bud Nodes
Some nodes on an P2MP MPLS TE 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. downstream LSRs. Such LSRs are known as bud nodes [RFC4461].
A bud node will 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 is also important that it indicates to the ingress node would, but it MUST also indicates to the ingress that it is an
that it is an egress in its own right. This is achieved through the egress in its own right. This is achieved through the use of a new
use of a new E-flag in the Downstream Mapping TLV that indicates that E-flag in the Downstream Mapping TLV that indicates that the
the reporting LSR is not a bud for this LSP (set to zero) or is a bud reporting LSR is not a bud for this LSP (cleared to zero) or is a bud
(set to one). A normal egress is not required to set this flag. (set to one). A normal egress MUST NOT set this flag.
The flag is placed in the fourth byte of the TLV that was previously The flag is placed in the fourth byte of the TLV that was previously
reserved. reserved.
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 LSRs that must not reply to the request because, although they lie
on the P2MP tree, they do not lie on the path to the egress that is on the P2MP tree, they do not lie on the path to the egress that is
being traced. being traced.
Thus, an LSR on a P2MP MPLS TE LSP MUST NOT respond to an echo Thus, an LSR on a P2MP MPLS LSP MUST NOT respond to an echo request
request when the TTL has expired if any of the following applies: when the TTL has expired if any of the following applies:
- The Reply Type indicates that no reply is required - The Reply Type indicates that no reply is required
- There is an IPv4/6 P2MP Egress Identifier present on the echo
request, but the address does not identify an egress that is - There is a P2MP Egress Identifier TLV present on the echo request
reached through this LSR for this particular P2MP MPLS TE LSP. (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 3.3.5. Modifications to the Downstream Mapping TLV
A new B-flag is added to the Downstream Mapping TLV to indicate that A new B-flag is added to the Downstream Mapping TLV to indicate that
the reporting LSR is not a branch for this LSP (set to zero) or is a the reporting LSR is not a branch for this LSP (cleared to zero) or
branch (set to one). is a branch (set to one).
A new E-flag is added to the Downstream Mapping TLV to indicate that A new E-flag is added to the Downstream Mapping TLV to indicate that
the reporting LSR is not a bud node for this LSP (set to zero) or is the reporting LSR is not a bud node for this LSP (cleared to zero) or
a bud node (set to one). is a bud node (set to one).
The flags are placed in the fourth byte of the TLV that was The flags are placed in the fourth byte of the TLV that was
previously reserved as shown below. All other fields are unchanged previously reserved as shown below. All other fields are unchanged
from their definitions in [RFC4379] except for the additional from their definitions in [RFC4379] except for the additional
information that can be carried in the Multipath Information. information that can be carried in the Multipath Information (see
Section 3.3.6).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | Reserved |E|B| | MTU | Address Type | Reserved |E|B|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) | | Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) | | Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 32 skipping to change at page 18, line 39
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol | | Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.6. Additions to Downstream Mapping Multipath Information 3.3.6. 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 an P2MP MPLS TE LSP and reported Multipath Information applies to a P2MP MPLS TE LSP and
may contain a list of egress identifiers that indicate the egress may contain a list of egress identifiers that indicate the egress
nodes that can be reached through the reported interface. 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 egresses List of P2MP egresses
Note that a list of egresses may include IPv4 and IPv6 identifiers Note that a list of egresses may include IPv4 and IPv6 identifiers
since these may be mixed in the P2MP MPLS TE LSP. since 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 thereof) is also handled just as in [RFC4379]. The format stack thereof) is also handled just as in [RFC4379]. The format
of the Multipath Information for a Multipath Type of P2MP Egresses of the Multipath Information for a Multipath Type of P2MP Egresses
is as follows. is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Egress Address (4 or 16 octets) | | Address Type | Egress Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 36 skipping to change at page 19, line 39
------ ------------ ------ ------------
1 IPv4 1 IPv4
3 IPv6 3 IPv6
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. Non-compliant Routers 4. Operation of LSP Ping for Bootstrapping Other OAM Mechanisms
Bootstrapping of other OAM procedures can be achieved using the
MPLS Echo Request/Response messages. The LSP(s) under test are
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.2).
Other Sub-TLVs may be defined in other specifications to indicate
the OAM procedures being bootstrapped, and to describe the bootstrap
parameters. Further details of the bootstrapping processes and the
bootstrapped OAM processes are described in other documents. For
example, see [MPLS-BFD] and [MCAST-CV].
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 LSR 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 LSR for some TTL, say n.
The LSR originating the echo request SHOULD continue to send echo The LSR originating the echo request SHOULD continue to send echo
requests with TTL=n+1, n+2, ..., n+k in the hope that some transit requests with TTL=n+1, n+2, ..., n+k in the hope that some transit
LSR further downstream may support MPLS echo requests and reply. In LSR further downstream may support MPLS echo requests and reply. In
such a case, the echo request for TTL > n MUST NOT have Downstream such a case, the echo request for TTL > n MUST NOT have Downstream
Mapping TLVs, until a reply is received with a Downstream Mapping. Mapping TLVs, until a reply is received with a Downstream Mapping.
5. OAM Considerations 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.
This draft clearly facilitates OAM procedures for P2MP MPLS TE LSPs. 6. OAM Considerations
The procedures in this document provide OAM functions for P2MP MPLS
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
P2MP MPLS TE LSP could result in congestion at or near the ingress P2MP MPLS LSP could result in congestion at or near the ingress
when the responses arrive. when the responses arrive.
Further, incautious use of timers to generate LSP Ping echo Further, incautious use of timers to generate LSP Ping echo
requests either in ping mode or especially in traceroute may lead requests either in ping mode or especially in traceroute may lead
to significant degradation of network performance. to significant degradation of network performance.
- Management interfaces should allow an operator full control over - Management interfaces should allow an operator full control over
the operation of LSP Ping. In particular, it SHOULD provide the the operation of LSP Ping. In particular, it SHOULD provide the
ability to limit the scope of an LSP Ping echo request for a P2MP ability to limit the scope of an LSP Ping echo request for a P2MP
MPLS TE LSP to a single egress. MPLS LSP to a single egress.
Such an interface SHOULD also provide the ability to disable all Such an interface SHOULD also provide the ability to disable all
active LSP Ping operations to provide a quick escape if the network active LSP Ping operations to provide a quick escape if the network
becomes congested. becomes congested.
- 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.
6. IANA Considerations 7. IANA Considerations
6.1. New Sub TLV Types 7.1. New Sub-TLV Types
Four new sub-TLV types are defined for inclusion within the Target Three new Sub-TLV types are defined for inclusion within the LSP Ping
FEC Stack TLV (TLV type 1). [RFC4379] Target FEC Stack TLV (TLV type 1).
IANA is requested to assign sub-type values to the following IANA is requested to assign sub-type values to the following
sub-TLVs. Sub-TLVs from the Multiprotocol Label Switching Architecture (MPLS)
Label Switched Paths (LSPs) Parameters - TLVs registry.
RSVP P2MP IPv4 Session (see section 3.1) RSVP P2MP IPv4 Session (see Section 3.1.1)
RSVP P2MP IPv6 Session (see section 3.1) RSVP P2MP IPv6 Session (see Section 3.1.1)
IPv4 P2MP Egress Identifier (see section 3.2.2) Multicast LDP FEC Stack (see Section 3.1.2)
IPv6 P2MP Egress Identifier (see section 3.2.2)
6.2. New Multipath Type 7.2. New Multipath Type
A new value for the Multipath Type is defined to indicate that the Section 3.3 of [RFC4379] defines a set of values for the LSP Ping
reported Multipath Information applies to an P2MP MPLS TE LSP. Multipath Type. These values are currently not tracked by IANA.
IANA is requested to assign a new value as follows. 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
Information applies to a P2MP MPLS TE LSP.
List of P2MP egresses (see section 3.3.6) IANA is requested to create a new registry as follows:
7. Security Considerations Multiprotocol Label Switching Architecture (MPLS) Label Switched
Paths (LSPs) - Multipath Types
Key Type Multipath Information
--- ---------------- ---------------------
0 no multipath Empty (Multipath Length = 0) [RFC4379]
2 IP address IP addresses [RFC4379]
4 IP address range low/high address pairs [RFC4379]
8 Bit-masked IP IP address prefix and bit mask [RFC4379]
address set
9 Bit-masked label set Label prefix and bit mask [RFC4379]
xx P2MP egress IP List of P2MP egresses [thisDoc]
addresses
A suggested value of xx is TBD by the MPLS Working Group.
New values from this registry are to be assigned only by Standards
Action.
7.3. New TLVs
Two new LSP Ping TLV types are defined for inclusion in LSP Ping
messages.
IANA is reuqested to assign a new value from the Multiprotocol Label
Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters
- TLVs registry as follows using a Standards Action value.
P2MP Egress Identifier TLV (see Section 3.2.4)
Two sub-TLVs are defined
- Type 1: IPv4 P2MP Egress Identifier (see Section 3.2.4)
- Type 2: IPv6 P2MP Egress Identifier (see Section 3.2.4)
Echo Jitter TLV (see Section 3.2.5)
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 TE 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.
8. Acknowledgements 9. Acknowledgements
The authors would like to acknowledge the authors of [RFC4379] for The authors would like to acknowledge the authors of [RFC4379] for
their work which is substantially re-used in this document. Also their work which is substantially re-used in this document. Also
thanks to the members of the MBONED working group for their review thanks to the members of the MBONED working group for their review
of this material, to Daniel King for his review, and to Yakov Rekhter of this material, to Daniel King for his review, and to Yakov Rekhter
for useful discussions. for useful discussions.
9. Intellectual Property Considerations The authors would like to thank Vanson Lim, Danny Prairie and Reshad
Rahman for their comments and suggestions.
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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 17, line 5 skipping to change at page 23, line 15
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
10. 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.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[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.
11. Informational References [P2MP-OAM-REQ] Yasukawa, S., Farrel, A., King, D., and Nadeau, T.,
"OAM Requirements for Point-to-Multipoint MPLS Networks",
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an draft-ietf-mpls-p2mp-oam-reqs, work in progress.
IANA Considerations Section in RFCs", BCP: 26, RFC 2434,
October 1998.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3552] Rescorla E. and B. Korver, "Guidelines for Writing RFC 12. Informative References
Text on Security Considerations", BCP: 72, RFC 3552,
July 2003.
[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.
[P2MP-RSVP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to [P2MP-RSVP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to
Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp, Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp,
work in progress. work in progress.
12. Authors' Addresses [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for
point-to-multipoint extensions to the Label Distribution
Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress.
[P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol
Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths",
draft-ietf-mpls-ldp-p2mp, work in progress.
[MCAST-CV] Swallow, G., and Nadeau, T., "Connectivity Verification
for Multicast Label Switched Paths",
draft-swallow-mpls-mcast-cv, work in progress.
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding
Detection", draft-ietf-bfd-base, work in progress.
[MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G.,
"BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in
progress.
13. Authors' Addresses
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
9-11, Midori-Cho 3-Chome (R&D Strategy Department)
Musashino-Shi, Tokyo 180-8585, 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan
Japan Phone: +81 3 5205 5341
Phone: +81 422 59 4769 Email: s.yasukawa@hco.ntt.co.jp
Email: yasukawa.seisho@lab.ntt.co.jp
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Zafar Ali Zafar Ali
Cisco Systems Inc. Cisco Systems Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, ON, K2K 3E8, Canada. Kanata, ON, K2K 3E8, Canada.
Phone: 613-889-6158 Phone: 613-889-6158
Email: zali@cisco.com Email: zali@cisco.com
Bill Fenner Bill Fenner
AT&T Labs -- Research AT&T Labs -- Research
75 Willow Rd. 75 Willow Rd.
Menlo Park, CA 94025 Menlo Park, CA 94025
United States United States
Email: fenner@research.att.com Email: fenner@research.att.com
13. Full Copyright Statement George Swallow
Cisco Systems, Inc.
1414 Massachusetts Ave
Boxborough, MA 01719
Email: swallow@cisco.com
Thomas D. Nadeau
Cisco Systems, Inc.
1414 Massachusetts Ave
Boxborough, MA 01719
Email: tnadeau@cisco.com
14. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Change History
This section to be removed before publication as an RFC
14.1. Changes from draft-ietf-mpls-p2mp-lsp-ping 00 to 01
- Update references.
 End of changes. 85 change blocks. 
251 lines changed or deleted 588 lines changed or added

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