draft-ietf-mpls-remote-lsp-ping-01.txt   draft-ietf-mpls-remote-lsp-ping-02.txt 
Network Working Group George Swallow Network Working Group George Swallow
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Category: Standards Track Category: Standards Track
Expiration Date: January 2009
Vanson Lim Vanson Lim
Cisco Systems, Inc. Cisco Systems, Inc.
November 2007 July 14, 2008
Proxy LSP Ping Proxy LSP Ping
draft-ietf-mpls-remote-lsp-ping-01.txt draft-ietf-mpls-remote-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 2, line 10 skipping to change at page 2, line 10
Switched Path. The primary motivations for this facility are Switched Path. The primary motivations for this facility are
first to limit the number of messages and related processing when first to limit the number of messages and related processing when
using LSP Ping in large Point-to-Multipoint LSPs, and second to using LSP Ping in large Point-to-Multipoint LSPs, and second to
enable leaf to root tracing. enable leaf to root tracing.
Contents Contents
1 Introduction .............................................. 3 1 Introduction .............................................. 3
1.1 Conventions ............................................... 3 1.1 Conventions ............................................... 3
2 Proxy Ping Overview ....................................... 4 2 Proxy Ping Overview ....................................... 4
3 Remote Echo / Reply Pprocedures ........................... 5 3 Proxy MPLS Echo Request / Reply Pprocedures ............... 5
3.1 Procedures for the initiator .............................. 5 3.1 Procedures for the initiator .............................. 5
3.2 Procedures for the proxy LSR .............................. 6 3.2 Procedures for the proxy LSR .............................. 6
3.2.1 Sending an MPLS proxy ping reply .......................... 7 3.2.1 Sending an MPLS proxy ping reply .......................... 7
3.2.2 Sending the MPLS echo requests ............................ 7 3.2.2 Sending the MPLS echo requests ............................ 7
4 Proxy Ping Request / Reply Messages ....................... 8 4 Proxy Ping Request / Reply Messages ....................... 9
4.1 Proxy Ping Request / Reply Message formats ................ 9 4.1 Proxy Ping Request / Reply Message formats ................ 9
4.2 Proxy Ping Request Message contents ....................... 10 4.2 Proxy Ping Request Message contents ....................... 10
4.3 Proxy Ping Reply Message Contents ......................... 10 4.3 Proxy Ping Reply Message Contents ......................... 11
5 Object formats ............................................ 11 5 Object formats ............................................ 11
5.1 Proxy Echo Parameters Object .............................. 11 5.1 Proxy Echo Parameters Object .............................. 11
5.2 Reply-to Address Object ................................... 12 5.1.1 Next Hop sub-Object ....................................... 13
5.3 Previous Hop Address Object ............................... 13 5.2 Reply-to Address Object ................................... 14
6 Security Considerations ................................... 13 5.3 Previous Hop Address Object ............................... 15
7 IANA Considerations ....................................... 13 6 Security Considerations ................................... 16
7.1 Message and Object Type Assignments ....................... 14 7 IANA Considerations ....................................... 16
7.2 Return Code Assignments ................................... 14 7.1 Message and Object Type Assignments ....................... 16
8 Acknowledgments ........................................... 14 7.2 Return Code Assignments ................................... 17
9 References ................................................ 14 8 References ................................................ 17
9.1 Normative References ...................................... 14 8.1 Normative References ...................................... 17
9.2 Informative References .................................... 15 8.2 Informative References .................................... 17
10 Authors' Addresses ........................................ 15 9 Authors' Addresses ........................................ 18
1. Introduction 1. Introduction
It is anticipated that very large Point-to-Multipoint (P2MP) Label It is anticipated that very large Point-to-Multipoint (P2MP) Label
Switched Paths (LSPs) will exist. Further it is anticipated that Switched Paths (LSPs) will exist. Further it is anticipated that
many of the applications for P2MP tunnels will require OAM that is many of the applications for P2MP tunnels will require OAM that is
both rigorous and scalable. both rigorous and scalable.
Suppose one wishes to trace a P2MP LSP to localize a fault which is Suppose one wishes to trace a P2MP LSP to localize a fault which is
affecting one egress or a set of egresses. Suppose one follows the affecting one egress or a set of egresses. Suppose one follows the
skipping to change at page 5, line 5 skipping to change at page 5, line 5
If the proxy LSR has a label mapping for the FEC and and all autho- If the proxy LSR has a label mapping for the FEC and and all autho-
rization check have passed, the proxy LSR formats an MPLS echo rization check have passed, the proxy LSR formats an MPLS echo
request. If the source address of the IP packet is not the initia- request. If the source address of the IP packet is not the initia-
tor, it includes a Reply-to Address object containing the initiator's tor, it includes a Reply-to Address object containing the initiator's
address. It then sends it inband of the LSP. address. It then sends it inband of the LSP.
The receivers process the MPLS echo request as normal, sending their The receivers process the MPLS echo request as normal, sending their
MPLS echo replies back to the initiator. MPLS echo replies back to the initiator.
3. Remote Echo / Reply Pprocedures 3. Proxy MPLS Echo Request / Reply Pprocedures
3.1. Procedures for the initiator 3.1. Procedures for the initiator
The initiator creates an MPLS proxy ping request message. The initiator creates an MPLS proxy ping request message.
The message MUST contain a Target FEC Stack that describes the FEC The message MUST contain a Target FEC Stack that describes the FEC
being tested. being tested.
[Note for the current version of the ID, the FEC stack is limited to [Note for the current version of the ID, the FEC stack is limited to
a single FEC as we have not yet fully considered the operational and a single FEC as we have not yet fully considered the operational and
skipping to change at page 6, line 19 skipping to change at page 6, line 19
routable address of the midpoint. The packet is then sent with the routable address of the midpoint. The packet is then sent with the
IP TTL is set to 255. IP TTL is set to 255.
3.2. Procedures for the proxy LSR 3.2. Procedures for the proxy LSR
A proxy LSR that receives an MPLS proxy ping request message, parses A proxy LSR that receives an MPLS proxy ping request message, parses
the packet to ensure that it is a well-formed packet. It checks that the packet to ensure that it is a well-formed packet. It checks that
the TLVs that are not marked "Ignore" are understood. If not, it the TLVs that are not marked "Ignore" are understood. If not, it
sets the Return Code set to "Malformed echo request received" or "TLV sets the Return Code set to "Malformed echo request received" or "TLV
not understood" (as appropriate), and the Subcode set to zero. If not understood" (as appropriate), and the Subcode set to zero. If
the Reply Mode of the message header is not 0, an MPLS proxy ping the Reply Mode of the message header is not 1, an MPLS proxy ping
reply message SHOULD be sent as described below. In the latter case, reply message SHOULD be sent as described below. In the latter case,
the misunderstood TLVs (only) are included in an Errored TLVs object. the misunderstood TLVs (only) are included in an Errored TLVs object.
The header fields Sender's Handle and Sequence Number are not exam- The header fields Sender's Handle and Sequence Number are not exam-
ined, but are saved to be included in the MPLS proxy ping reply and ined, but are saved to be included in the MPLS proxy ping reply and
MPLS echo request messages. MPLS echo request messages.
The proxy LSR validates that it has a label mapping for the specified The proxy LSR validates that it has a label mapping for the specified
FEC, it then determines if it is an egress, transit or bud node and FEC, it then determines if it is an egress, transit or bud node and
sets the Return Code as appropriate. sets the Return Code as appropriate.
skipping to change at page 7, line 7 skipping to change at page 7, line 7
If there is a list of Next Hop addresses in the Proxy Echo Parameters If there is a list of Next Hop addresses in the Proxy Echo Parameters
object, each address is examined to determine if it is a next hop for object, each address is examined to determine if it is a next hop for
this FEC. If any are not, those addresses are deleted from the list. this FEC. If any are not, those addresses are deleted from the list.
The updated Proxy Echo Parameters object is included in the MPLS The updated Proxy Echo Parameters object is included in the MPLS
proxy ping reply. proxy ping reply.
If the "Request for Downstream Mapping" flag is set the LSR formats a If the "Request for Downstream Mapping" flag is set the LSR formats a
Downstream Mapping object for each interface that the MPLS echo Downstream Mapping object for each interface that the MPLS echo
request will be sent out. request will be sent out.
If the Reply Mode of the message header is not 0 or 5, an MPLS remote If the Reply Mode of the message header is not 1 or 5, an MPLS remote
echo reply message SHOULD be sent as described below. echo reply message SHOULD be sent as described below.
3.2.1. Sending an MPLS proxy ping reply 3.2.1. Sending an MPLS proxy ping reply
The Reply mode, Sender's Handle and Sequence Number fields are copied The Reply mode, Sender's Handle and Sequence Number fields are copied
from the proxy ping request message. Various objects are included as from the proxy ping request message. Various objects are included as
specified above. The message is encapsulated in a UDP packet. The specified above. The message is encapsulated in a UDP packet. The
source IP address is a routable address of the proxy LSR; the source source IP address is a routable address of the proxy LSR; the source
port is the well-known UDP port for LSP ping. The destination IP port is the well-known UDP port for LSP ping. The destination IP
address and UDP port are copied from the source IP address and UDP address and UDP port are copied from the source IP address and UDP
skipping to change at page 8, line 22 skipping to change at page 8, line 22
Echo Jitter TLV [McstPing] Echo Jitter TLV [McstPing]
Vendor Private TLVs Vendor Private TLVs
The message is then encapsulated in a UDP packet. The source UDP The message is then encapsulated in a UDP packet. The source UDP
port is copied from the Proxy Echo Parameters object. destination port is copied from the Proxy Echo Parameters object. destination
ports are copied from the proxy ping request message. ports are copied from the proxy ping request message.
The source IP address is set to a routable address of the proxy LSR. The source IP address is set to a routable address of the proxy LSR.
Per usual the TTL of the IP packet is set to 1. Per usual the TTL of the IP packet is set to 1.
If the Explicit DSCP flag is set, the Requested DSCP byte is exam-
ined. If the setting is permitted then the DSCP byte of the IP
header of the MPLS Echo Request message is set to that value. Other-
wise the DSCP byte is set to a default value. In this case the MPLS
Proxy Echo Parameters with the Explicit DSCP flag cleared MUST be
included in any MPLS proxy ping reply message. The return code MUST
be set to <tba>, "Proxy ping parameters modified". The DSCP field of
the MPLS Proxy Echo Parameters SHOULD be set to the actual value
used.
3.2.2.2. Per interface sending procedures 3.2.2.2. Per interface sending procedures
The proxy LSR now iterates through the Next_Hop_List modifying the The proxy LSR now iterates through the Next_Hop_List modifying the
base MPLS echo request to form the MPLS echo request packet which is base MPLS echo request to form the MPLS echo request packet which is
then sent on that particular interface. then sent on that particular interface.
For each next hop address, the outgoing label stack is determained. For each next hop address, the outgoing label stack is determained.
The TTL for the label corresponding to the FEC in the FEC stack is The TTL for the label corresponding to the topmost FEC in the FEC
set such that the TTL on the wire will be one less than the TTL spec- stack is set such that the TTL on the wire will be one less than the
ified in the proxy ping request message. If any additional labels TTL specified in the Proxy Echo Parameters. If any additional labels
are pushed onto the stack, their TTLs are set to 255. are pushed onto the stack, their TTLs are set to 255.
If the MPLS proxy ping request message contained Downstream Mapping If the MPLS proxy ping request message contained Downstream Mapping
objects, they are examined. If the Downstream IP Address matches the objects, they are examined. If the Downstream IP Address matches the
next hop address that Downstream Mapping object is included in the next hop address that Downstream Mapping object is included in the
MPLS echo request. MPLS echo request.
The packet is then transmitted on this interface. The packet is then transmitted on this interface.
4. Proxy Ping Request / Reply Messages 4. Proxy Ping Request / Reply Messages
skipping to change at page 10, line 17 skipping to change at page 10, line 24
value 5. For completeness, the full list of reply modes value 5. For completeness, the full list of reply modes
follows: follows:
Value Meaning Value Meaning
----- ------- ----- -------
1 Do not reply 1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet 2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert 3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application level control channel 4 Reply via application level control channel
5 Reply via an IPv4/IPv6 UDP packet only if the proxy 5 Reply via an IPv4/IPv6 UDP packet only if the proxy
request is not fulfilled request is not fulfilled or modified
4.2. Proxy Ping Request Message contents 4.2. Proxy Ping Request Message contents
The MPLS proxy ping request message MAY contain the following The MPLS proxy ping request message MAY contain the following
objects: objects:
Type Object Type Object
---- ----------- ---- -----------
1 Target FEC Stack 1 Target FEC Stack
2 Downstream Mapping 2 Downstream Mapping
skipping to change at page 11, line 9 skipping to change at page 11, line 23
5 Vendor Enterprise Number 5 Vendor Enterprise Number
9 Errored TLVs 9 Errored TLVs
tba Proxy Echo Parameters tba Proxy Echo Parameters
tba Previous Hop Address tba Previous Hop Address
Vendor Private objects Vendor Private objects
5. Object formats 5. Object formats
5.1. Proxy Echo Parameters Object 5.1. Proxy Echo Parameters Object
The Proxy Echo Parameters object is a TLV that MUST be included in an
MPLS Proxy Echo Request message. The length of the TLV is 12 + K +
S, where K is the length of the Destination IP Address field and S is
the total length of the sub-objects.
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 | Flags | Reply mode | TTL | | Address Type | Flags | Reply mode | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rqst'd DSCP | Must be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source UDP Port | Global Flags | | Source UDP Port | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: Destination IP Address : : Destination IP Address :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: : : :
: Next Hop IP Addresses : : Sub-Objects :
: : : :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type Address Type
The type of address found in the in the Destination IP Address The type and length of the address found in the in the
and Next Hop IP Addresses fields. The type codes appear in the Destination IP Address and Next Hop IP Addresses fields.
table below: The type codes appear in the table below:
Address Family Type Address Family Type Length
IPv4 Numbered 1 IPv4 1 4
IPv6 Numbered 3 IPv6 3 16
Flags Flags
Request for Previous Hop 0x01 Request for Previous Hop 0x01
When set this requests that the proxy LSR supply the previous hop When set this requests that the proxy LSR supply the
address in the MPLS proxy ping reply message previous hop address in the MPLS proxy ping reply message
Request for Downstream Mapping 0x02 Request for Downstream Mapping 0x02
When set this requests that the proxy LSR supply a When set this requests that the proxy LSR supply a
Downstream Mapping object in the MPLS proxy ping reply Downstream Mapping object in the MPLS proxy ping reply
message message
Explicit DSCP Request 0x04
When set this requests that the proxy LSR supply a use
the supplied DSCP byte in the echo request message
Reply mode Reply mode
The reply mode to be sent in the MPLS Echo Request message; the The reply mode to be sent in the MPLS Echo Request message; the
values are as specified in [RFC4379] values are as specified in [RFC4379]
TTL TTL
The TTL to be used in the label corresponding to the FEC in the The TTL to be used in the label stack entry corresponding to
MPLS Echo Request packet the topmost FEC in the in the MPLS Echo Request packet
Requested DSCP
This field is valid only if the Explicit DSCP flag is set. If
not set, the field MUST be zero on transmission and ignored on
receipt. When the flag is set this field contains the DSCP
value to be used in the MPLS echo request packet IP header.
Source UDP Port Source UDP Port
The source UDP port to be sent in the MPLS Echo Request packet The source UDP port to be sent in the MPLS Echo Request packet
Global Flags Global Flags
The Global Flags to be sent in the MPLS Echo Request messge The Global Flags to be sent in the MPLS Echo Request messge
Destination IP Address Destination IP Address
If the Address Type is IPv4, an address from the range 127/8; If the Address Type is IPv4, an address from the range 127/8;
If the Address Type is IPv6, an address from the range If the Address Type is IPv6, an address from the range
0:0:0:0:0:FFFF:127/104 0:0:0:0:0:FFFF:127/104
Next Hop IP Addresses Sub-Objects
A list of next hop address that the echo request message is to A TLV encoded list of sub-objects. Currently one is defined.
Sub-Type Length Value Field
-------- ------ -----------
1 8+ Next Hop
5.1.1. Next Hop sub-Object
This sub-object is used to describe a particular next hop towards
which the Echo Request packet should be sent. If the topmost FEC in
the FEC-stack is a multipoint LSP, this sub-object may appear multi-
ple times.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Type | MUST be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Interface (0, 4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type
Type Type of Next Hop Addr Length IF Length
1 IPv4 Numbered 4 4
2 IPv4 Unnumbered 4 4
3 IPv6 Numbered 16 16
4 IPv6 Unnumbered 16 4
5 IPv4 Protocol Adj 4 0
6 IPv6 Protocol Adj 16 0
Note: Types 1-4 correspond to the types in the DS Mapping
object. They are expected to populated with information
obtained through a previously returned DS Mapping object.
Types 5 and 6 are intended to be populated from the local
address information obtained from a previously returned
Previous Hop Address Object.
Next Hop IP Address
A next hop address that the echo request message is to
be sent towards be sent towards
5.2. Reply-to Address Object Next Hop Interface
Identifier of the interface through which the echo request
message is to be sent
5.2. Reply-to Address Object
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | MUST be Zero | | Address Type | MUST be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: Reply-to Address : : Reply-to Address :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type Address Type
A type code as specified in the table below: A type code as specified in the table below:
Type Type of Address Type Type of Address
1 IPv4 1 IPv4
3 IPv6 3 IPv6
5.3. Previous Hop Address Object 5.3. Previous Hop Address Object
skipping to change at page 13, line 16 skipping to change at page 15, line 24
A type code as specified in the table below: A type code as specified in the table below:
Type Type of Address Type Type of Address
1 IPv4 1 IPv4
3 IPv6 3 IPv6
5.3. Previous Hop Address Object 5.3. Previous Hop Address Object
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | MUST be Zero | |PHOP Addr Type |Local Addr Type| MUST be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: Previous Hop Address : : Previous Hop Address :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Local Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PHOP Addr Type; Local Addr Type
Address Type These two fields determine the type and length of the
respective addresses. The codes are specified in the table
below:
A type code as specified in the table below: Type Type of Address Length
Type Type of Address 0 No Address Supplied 0
1 IPv4 4
3 IPv6 16
0 No Address Supplied Previous Hop Address
1 IPv4
3 IPv6 The address of the immediate upstream neighbor for the topmost
FEC in the FEC stack. If protocol adjacency exists by which
the label for this FEC was exchanged, this address MUST be the
address used in that protocol exchange.
Local Address
The local address used in the protocol adjacency exists by
which the label for this FEC was exchanged.
6. Security Considerations 6. Security Considerations
[To be written] [To be written]
7. IANA Considerations 7. IANA Considerations
[Not complete] [Not complete]
7.1. Message and Object Type Assignments 7.1. Message and Object Type Assignments
skipping to change at page 14, line 23 skipping to change at page 17, line 18
tba MPLS proxy ping reply tba MPLS proxy ping reply
LSP Ping Object Type tba Proxy Echo Parameters LSP Ping Object Type tba Proxy Echo Parameters
tba Reply-to Address tba Reply-to Address
tba Previous Hop Address tba Previous Hop Address
7.2. Return Code Assignments 7.2. Return Code Assignments
Value Meaning Value Meaning
tba Remote Ping not authorized tba Proxy ping request not authorized
tba Proxy ping parameters modified
8. Acknowledgments
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
[KeyWords] Bradner, S., "Key words for use in RFCs to Indicate [KeyWords] 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.
[McstPing] Farrel, A. et al, "Detecting Data Plane Failures in [McstPing] Farrel, A. et al, "Detecting Data Plane Failures in
Point-to-Multipoint MPLS Traffic Engineering - Point-to-Multipoint MPLS Traffic Engineering -
Extensions to LSP Ping", Extensions to LSP Ping",
draft-ietf-mpls-p2mp-lsp-ping-02.txt, September 2006. draft-ietf-mpls-p2mp-lsp-ping-06.txt, June 2008.
9.2. Informative References 8.2. Informative References
[P2MP-TE] Aggarwal, R., et al., "Extensions to RSVP-TE for [P2MP-TE] Aggarwal, R., et al., "Extensions to RSVP-TE for
Point-to-Multipoint TE LSPs", Point-to-Multipoint TE LSPs", RFC 4875, May 2007.
draft-ietf-mpls-rsvp-te-p2mp-07.txt, January 2007.
[mLDP] Minei, I., et. al., "Label Distribution Protocol [mLDP] Minei, I., et. al., "Label Distribution Protocol
Extensions for Point-to-Multipoint and Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths" Multipoint-to-Multipoint Label Switched Paths"
draft-ietf-mpls-ldp-p2mp-02.txt, October 2006. draft-ietf-mpls-ldp-p2mp-05.txt, May 2008.
10. Authors' Addresses 9. Authors' Addresses
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
Email: swallow@cisco.com Email: swallow@cisco.com
Vanson Lim Vanson Lim
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 15, line 43 skipping to change at page 18, line 32
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.
Copies of IPR disclosures made to the IETF Secretariat and any assur- Copies of IPR disclosures made to the IETF Secretariat and any
ances of licenses to be made available, or the result of an attempt assurances of licenses to be made available, or the result of an
made to obtain a general license or permission for the use of such attempt made to obtain a general license or permission for the use of
proprietary rights by implementers or users of this specification can such proprietary rights by implementers or users of this
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 ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Notice Full Copyright Notice
Copyright (C) The IETF Trust (2007). This document is subject to the Copyright (C) The IETF Trust (2008). This document is subject
rights, licenses and restrictions contained in BCP 78, and except as to the rights, licenses and restrictions contained in BCP 78, and
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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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.
 End of changes. 44 change blocks. 
64 lines changed or deleted 154 lines changed or added

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