draft-ietf-mpls-p2mp-lsp-ping-00.txt   draft-ietf-mpls-p2mp-lsp-ping-01.txt 
Network Working Group Seisho Yasukawa (NTT) Network Working Group Seisho Yasukawa (NTT)
IETF Internet Draft Adrian Farrel (Olddog Consulting) IETF Internet Draft Adrian Farrel (Olddog Consulting)
Proposed Status: Standards Track Zafar Ali (Cisco Systems) Proposed Status: Standards Track Zafar Ali (Cisco Systems)
Expires: February 2006 Bill Fenner (AT&T Research) Expires: October 2006 Bill Fenner (AT&T Research)
August 2005 April 2006
Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic
Engineering - Extensions to LSP Ping Engineering - Extensions to LSP Ping
draft-ietf-mpls-p2mp-lsp-ping-00.txt draft-ietf-mpls-p2mp-lsp-ping-01.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 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
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.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
Recent proposals have extended the scope of Multi-Protocol Label Recent proposals have extended the scope of Multi-Protocol Label
Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs) Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs)
to encompass point-to-multipoint (P2MP) TE LSPs. to encompass point-to-multipoint (P2MP) TE 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".
skipping to change at page 3, line 9 skipping to change at page 3, line 9
9. Intellectual Property Considerations .......................... 16 9. Intellectual Property Considerations .......................... 16
10. Normative References ......................................... 17 10. Normative References ......................................... 17
11. Informational References ..................................... 17 11. Informational References ..................................... 17
12. Authors' Addresses ........................................... 17 12. Authors' Addresses ........................................... 17
13. Full Copyright Statement ..................................... 18 13. Full Copyright Statement ..................................... 18
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
[LSP-PING]. 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 [LSP-PING] 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 requirement for point-to-multipoint (P2MP) MPLS traffic
engineered (TE) LSPs is stated in [P2MP-REQ]. [P2MP-RSVP] specifies a engineered (TE) LSPs is 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. P2MP MPLS TE
LSPs are at least as vulnerable to data plane faults or to 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. LSP Ping Mechanisms are, therefore, also desirable to
detect such data plane faults in P2MP MPLS TE LSPs. detect such data plane faults in P2MP MPLS TE LSPs.
This document extends the techniques described in [LSP-PING] 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 TE LSPs. This document stresses
the reuse of existing LSP Ping mechanisms used for P2P LSPs, and the reuse of existing LSP Ping mechanisms used for P2P LSPs, and
applies them to P2MP MPLS TE LSPs in order to simplify implementation applies them to P2MP MPLS TE LSPs in order to simplify implementation
and network operation. and network operation.
1.1 Design Considerations 1.1 Design Considerations
As mentioned earlier, an important consideration for designing LSP As mentioned earlier, an important consideration for designing LSP
Ping for P2MP MPLS TE LSPs is that every attempt is made to use or Ping for P2MP MPLS TE LSPs is that every attempt is made to use or
extend existing mechanisms rather than invent new mechanisms. extend existing 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 TE LSPs, as in this case an MPLS packet is replicated
so that it arrives at each egress (or leaf) of the P2MP tree. so 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.
As pointed out in [LSP-PING], 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 covered in this document.
As is described in [LSP-PING], 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 [LSP-PING] 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 would enable 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; and a mechanism to
isolate faults. isolate faults.
[LSP-PING] 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. [LSP-PING] 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 [LSP-PING] 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)
actually end their MPLS path on an LSR that is an egress for that actually end their MPLS path on an LSR that is an egress for that
FEC. [LSP-PING] achieves this test by sending a packet (called an FEC. [RFC4379] achieves this test by sending a packet (called an
"MPLS echo request") along the same data path as other packets "MPLS echo request") along the same data path as other packets
belonging to this FEC. An MPLS echo request also carries information belonging to this FEC. An MPLS echo request also carries information
about the FEC whose MPLS path is being verified. This echo request is about the FEC whose MPLS path is being verified. This echo request is
forwarded just like any other packet belonging to that FEC. In "ping" forwarded just like any other packet belonging to that FEC. In "ping"
mode (basic connectivity check), the packet should reach the end of mode (basic connectivity check), the packet should reach the end of
the path, at which point it is sent to the control plane of the the path, at which point it is sent to the control plane of the
egress LSR, which then verifies that it is indeed an egress for the egress LSR, which then verifies that it is indeed an egress for the
FEC. In "traceroute" mode (fault isolation), the packet is sent to FEC. In "traceroute" mode (fault isolation), the packet is sent to
the control plane of each transit LSR, which performs various checks the control plane of each transit LSR, which performs various checks
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
skipping to change at page 6, line 25 skipping to change at page 6, line 25
3. Operation of LSP Ping for a P2MP TE LSP 3. Operation of LSP Ping for a P2MP TE LSP
This section describes how LSP Ping is applied to P2MP MPLS TE LSPs. This section describes how LSP Ping is applied to P2MP MPLS TE 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
[LSP-PING] 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 the various fields from the RSVP-TE P2MP Session and Sender-Template
objects [P2MP-RSVP] and so provide sufficient information to uniquely objects [P2MP-RSVP] and so provide sufficient information to uniquely
identify the LSP. identify the LSP.
skipping to change at page 8, line 20 skipping to change at page 8, line 20
be placed after the RSVP P2MP IPv4/6 Session sub-TLV. be placed after the RSVP P2MP IPv4/6 Session sub-TLV.
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 all P2MP Egress Identifier sub-TLVs.
An egress LSR that receives an echo request carrying an RSVP P2MP An egress LSR that receives an echo request carrying an RSVP P2MP
IPv4/6 Session sub-TLV MUST determine whether it is an intended IPv4/6 Session sub-TLV MUST determine whether it is an intended
egress of the P2MP LSP in question by checking with the control egress of the P2MP LSP in question by checking with the control
plane. If it is not supposed to be an egress, it MUST respond 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 according to the setting of the Response Type field in the echo
message following the rules defined in [LSP-PING]. message following the rules defined in [RFC4379].
If the egress that receives an echo request is an intended egress, If the egress that receives an echo request is an intended egress,
the LSR MUST check to see whether it is an intended Ping recipient. 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 If a P2MP Egress Identifier sub-TLV is present and contains an
address that indicates any address that is local to the egress LSR, address that indicates any address that is local to the egress LSR,
it MUST respond according to the setting of the Response Type field it MUST respond according to the setting of the Response Type field
in the echo message following the rules defined in [LSP-PING]. If the in the echo message following the rules defined in [RFC4379]. If the
P2MP Egress Identifier sub-TLV is present, but does not identify the P2MP Egress Identifier sub-TLV is present, but does not identify the
egress LSR, it MUST NOT respond to the echo request. If the P2MP egress LSR, it MUST NOT respond to the echo request. If the P2MP
Egress identifier is not present, but the egress that received the Egress identifier is not present, but the egress that received the
echo request is an intended egress, it MUST respond according to echo request is an intended 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 [LSP-PING]. the rules defined in [RFC4379].
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.
skipping to change at page 10, line 19 skipping to change at page 10, line 19
a random amount of time between zero seconds and the value a random amount of time between zero seconds and the value
specified in this field. specified in this field.
Jitter time is specified in milliseconds. Jitter time is specified in milliseconds.
The Echo Jitter TLV only has meaning on an echo request message. If The Echo Jitter TLV only has meaning on an echo request message. If
present on an echo response message, it SHOULD be ignored. present on an echo response message, it SHOULD be ignored.
3.3. Traceroute Mode Operation 3.3. Traceroute Mode Operation
The traceroute mode of operation is described in [LSP-PING]. Like The traceroute mode of operation is described in [RFC4379]. Like
other traceroute operations, it relies on the expiration of the TTL other traceroute operations, it relies on the expiration of the TTL
of the packet that carries the echo request. Echo requests may of the packet that carries the echo request. Echo requests may
include a Downstream Mapping TLV and when the TTL expires the echo include a Downstream Mapping TLV and when the TTL expires the echo
request is passed to the control plane on the transit LSR which request is passed to the control plane on the transit LSR which
responds according to the Response Type in the message. A responding responds according to the Response Type in the message. A responding
LSR fills in the fields of the Downstream Mapping TLV to indicate the LSR fills in the fields of the Downstream Mapping TLV to indicate the
downstream interfaces and labels used by the reported LSP from the downstream interfaces and labels used by the reported LSP from the
responding LSR. In this way, by successively sending out echo responding LSR. In this way, by successively sending out echo
requests with increasing TTLs, the ingress may gain a picture of the requests with increasing TTLs, the ingress may gain a picture of the
path and resources used by an LSP up to the point of failure when no path and resources used by an LSP up to the point of failure when no
skipping to change at page 11, line 7 skipping to change at page 11, line 7
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 and
the message is passed to the control plane, an echo response MUST the message is passed to the control plane, an echo response MUST
only be returned if the responding LSR lies on the path to the egress 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 identified by the IPv4/6 P2MP Egress Identifier carried on the
request, or if no such sub-TLV is present. request, or if no such sub-TLV is present.
The echo response identifies the next hop of the path in the data The echo response identifies the next hop of the path in the data
plane by including a Downstream Mapping TLV as described in plane by including a Downstream Mapping TLV as described in
[LSP-PING]. [RFC4379].
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 or
undesirable. Therefore, the echo response contains additional undesirable. Therefore, the echo response contains additional
information in the Multipath Information field of the Downstream information in the Multipath Information field of the Downstream
Mapping TLV that identifies to which egress/egresses the echo Mapping TLV that identifies to which egress/egresses the echo
skipping to change at page 11, line 32 skipping to change at page 11, line 32
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 TE 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.
[LSP-PING] 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 Just as with non-branches, it is important that the echo responses
provide correlation information that will allow the ingress to work provide correlation information that will allow the ingress to work
out to which branch of the LSP the response applies. Further, when out to which branch of the LSP the response applies. Further, when
multiple downstream interfaces are identified, it is necessary to multiple downstream interfaces are identified, it is necessary to
indicate which egresses are reached through which branches. This is indicate which egresses are reached through which branches. This is
achieved exactly as for non-branch nodes: that is, by including a achieved exactly as for non-branch nodes: that is, by including a
list of egresses as part of the Multipath Information field of the list of egresses as part of the Multipath Information field of the
skipping to change at page 12, line 52 skipping to change at page 12, line 52
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 (set to zero) or is a
branch (set to one). 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 (set to zero) or is
a bud node (set to one). 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 [LSP-PING] 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.
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 44 skipping to change at page 13, line 44
nodes that can be reached through the reported interface. nodes that can be reached through the reported interface.
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 [LSP-PING] (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 [LSP-PING]. 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (continued) | : | (continued) | :
+-+-+-+-+-+-+-+-+ : +-+-+-+-+-+-+-+-+ :
skipping to change at page 16, line 17 skipping to change at page 16, line 17
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. reported Multipath Information applies to an P2MP MPLS TE LSP.
IANA is requested to assign a new value as follows. IANA is requested to assign a new value as follows.
List of P2MP egresses (see section 3.3.6) List of P2MP egresses (see section 3.3.6)
7. Security Considerations 7. 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 [LSP-PING]. 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 TE 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 8. Acknowledgements
The authors would like to acknowledge the authors of [LSP-PING] 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 Dan 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 9. 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
skipping to change at page 17, line 16 skipping to change at page 17, line 16
[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, [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004. RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004.
[LSP-PING] Kompella, K., and Swallow, G., (Editors), "Detecting [RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol
MPLS Data Plane Failures", draft-ietf-mpls-lsp-ping, Label Switched (MPLS) Data Plane Failures", RFC 4379,
work in progress. February 2006.
11. Informational References 11. Informational References
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP: 26, RFC 2434, IANA Considerations Section in RFCs", BCP: 26, RFC 2434,
October 1998. October 1998.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3552] Rescorla E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP: 72, RFC 3552, Text on Security Considerations", BCP: 72, RFC 3552,
July 2003. July 2003.
[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792.
[P2MP-REQ] S. Yasukawa, et. al., "Signaling Requirements for Point [RFC4461] Yasukawa, S., "Signaling Requirements for Point to
to Multipoint Traffic Engineered MPLS LSPs", Multipoint Traffic Engineered Multiprotocol Label
draft-ietf-mpls-p2mp-sig-requirement, work in progress. Switching (MPLS) Label Switched Paths (LSPs)",
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 12. Authors' Addresses
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
9-11, Midori-Cho 3-Chome 9-11, Midori-Cho 3-Chome
skipping to change at page 18, line 24 skipping to change at page 18, line 24
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 13. Full Copyright Statement
Copyright (C) The Internet Society (2005). 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 14. Change History
This section to be removed before publication as an RFC This section to be removed before publication as an RFC
14.1. Changes from draft-yasukawa-mpls-p2mp-lsp-ping 01 to 02 14.1. Changes from draft-ietf-mpls-p2mp-lsp-ping 00 to 01
- Add Bill Fenner as co-author. - Update references.
- Add echo jitter response processing.
 End of changes. 33 change blocks. 
39 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/