draft-ietf-mpls-remote-lsp-ping-02.txt   draft-ietf-mpls-remote-lsp-ping-03.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.
July 14, 2008 November 3, 2008
Proxy LSP Ping Proxy LSP Ping
draft-ietf-mpls-remote-lsp-ping-02.txt draft-ietf-mpls-remote-lsp-ping-03.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 8 skipping to change at page 2, line 8
Label Switched Protocol Pings on Label Switched Paths. A proxy Label Switched Protocol Pings on Label Switched Paths. A proxy
ping request is sent to any Label Switching Routers along a Label ping request is sent to any Label Switching Routers along a Label
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 ............................................... 4
2 Proxy Ping Overview ....................................... 4 2 Proxy Ping Overview ....................................... 4
3 Proxy MPLS Echo Request / 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 ............................ 8
4 Proxy Ping Request / Reply Messages ....................... 9 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 ....................... 11
4.3 Proxy Ping Reply Message Contents ......................... 11 4.3 Proxy Ping Reply Message Contents ......................... 11
5 Object formats ............................................ 11 5 Object formats ............................................ 12
5.1 Proxy Echo Parameters Object .............................. 11 5.1 Proxy Echo Parameters Object .............................. 12
5.1.1 Next Hop sub-Object ....................................... 13 5.1.1 Next Hop sub-Object ....................................... 14
5.2 Reply-to Address Object ................................... 14 5.2 Reply-to Address Object ................................... 15
5.3 Previous Hop Address Object ............................... 15 5.3 Previous Hop Address Object ............................... 15
6 Security Considerations ................................... 16 6 Security Considerations ................................... 16
7 IANA Considerations ....................................... 16 7 IANA Considerations ....................................... 17
7.1 Message and Object Type Assignments ....................... 16 8 References ................................................ 18
7.2 Return Code Assignments ................................... 17 8.1 Normative References ...................................... 18
8 References ................................................ 17 8.2 Informative References .................................... 18
8.1 Normative References ...................................... 17
8.2 Informative References .................................... 17
9 Authors' Addresses ........................................ 18 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
normal procedure for tracing - namely repeatedly pinging from the normal procedure for tracing - namely repeatedly pinging from the
root, incrementing the TTL by one after each three or so pings. Such root, incrementing the TTL by one after each three or so pings. Such
a procedure has the potential for producing a large amount of pro- a procedure has the potential for producing a large amount of pro-
cessing at the P2MP-LSP midpoints and egresses. It also could pro- cessing at the P2MP-LSP midpoints and egresses. It also could pro-
duce an unwieldy number of replies back to the root. duce an unwieldy number of replies back to the root.
One alternative would be to begin sending pings from points at or One alternative would be to begin sending pings from points at or
near the affected egress(es) and working backwards toward the root. near the affected egress(es) and working backwards toward the root.
The TTL could be held constant as say two, limiting the the number of The TTL could be held constant as say two, limiting the the number of
responses to the number of next-next-hops of the point where the ping responses to the number of next-next-hops of the point where a ping
was initiated. is initiated.
The above procedure does require that the root know the previous-hop This document defines protocol extensions to MPLS ping [RFC4379] to
node to the one which was pinged on the prior iteration. This infor- allow a third party to remotely cause an MPLS echo request message to
mation is readily available in [P2MP-TE]. This document provides a be sent down a Label Switched Path (LSP) or part of an LSP. The pro-
means for obtaining this information for [mLDP] as well as defining a cedure described in the paragraphs above does require that the ini-
means for remotely causing an MPLS echo request message to be sent tiator know the previous-hop node to the one which was pinged on the
down a Label Switched Path (LSP) or part of an LSP. prior iteration. This information is readily available in [P2MP-TE].
This also document provides a means for obtaining this information
for [mLDP].
While the motivaton for this document came from multicast scaling While the motivaton for this document came from multicast scaling
concerns, its applicability may be wider. However other uses of this concerns, its applicability may be wider. However other uses of this
facility are beyond the scope of this document. Further the discus- facility are beyond the scope of this document. In particular, the
sion is cauched in terms of multipoint LSPs. procedures defined in this document only allow testing of a FEC stack
consisting of a single FEC. It also does not allow the initiator to
specify the label assigned to that FEC, nor does it allow the initia-
tor to cause any additional labels to be added to the label stack of
the actual MPLS echo request message. Further the discussion is
cauched in terms of multipoint LSPs.
1.1. Conventions 1.1. Conventions
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 [KeyWords]. document are to be interpreted as described in RFC 2119 [KeyWords].
The term "Must Be Zero" (MBZ) is used in object descriptions for The term "Must Be Zero" (MBZ) is used in object descriptions for
reserved fields. These fields MUST be set to zero when sent and reserved fields. These fields MUST be set to zero when sent and
ignored on receipt. ignored on receipt.
Based on context the terms leaf and egress are used interchangeably. Based on context the terms leaf and egress are used interchangeably.
Egress is used where consistency with [RFC4379] was deemed appropri- Egress is used where consistency with [RFC4379] was deemed appropri-
ate. Receiver is used in the context of receiving protocol messages. ate. Receiver is used in the context of receiving protocol messages.
[Note (to be removed after assignments occur): <tba> = to be assigned [Note (to be removed after assignments occur): <tba> = to be assigned
by IANA] by IANA]
2. Proxy Ping Overview 2. Proxy Ping Overview
Two new LSP Ping messages are defined for remote pinging, the MPLS This document defines a protocol interaction between a first node and
proxy ping request and the MPLS proxy ping reply. a node which is part of an LSP to allow the first node to remotely
initiate a an LSP ping for the LSP. Two new LSP Ping messages are
defined for remote pinging, the MPLS proxy ping request and the MPLS
proxy ping reply.
A remote ping operation on a P2MP LSP involves at least three LSRs; A remote ping operation on a P2MP LSP involves at least three LSRs;
in some scenarios none of these are the ingress (root) or an egress in some scenarios none of these are the ingress (root) or an egress
(leaf) of the LSP. (leaf) of the LSP.
We refer to these nodes with the following terms: We refer to these nodes with the following terms:
Initiator - the node which initiates the ping operation by sending Initiator - the node which initiates the ping operation by sending
an MPLS proxy ping request message an MPLS proxy ping request message
skipping to change at page 4, line 43 skipping to change at page 5, line 13
previous hop, i.e. the LSR upstream of it on this LSP. previous hop, i.e. the LSR upstream of it on this LSP.
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 and that it is authorized to send the specified MPLS echo request FEC and that it is authorized to send the specified MPLS echo request
on behalf of the initiator. Depending on the Reply Mode carried in on behalf of the initiator. Depending on the Reply Mode carried in
the header of the proxy ping request message and the above results an the header of the proxy ping request message and the above results an
MPLS remote echo reply message might be sent back to the initiator. MPLS remote echo reply message might be sent back to the initiator.
This message may also communicate the address of the previous hop. This message may also communicate the address of the previous hop.
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 checks 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. Proxy MPLS Echo Request / 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 The message MUST contain a Proxy Echo Parameters object. In that
a single FEC as we have not yet fully considered the operational and object, the address type is set to either IPv4 or IPv6. The Destina-
security impacts of permitting more FECs] tion IP Address is set to the value to be used in the MPLS echo
request packet. If the Address Type is IPv4, an address from the
The message MUST contain a Proxy Echo Parameters object. The address range 127/8. If the Address Type is IPv6, an address from the range
type is set to either IPv4 or IPv6. The Destination IP Address is 0:0:0:0:0:FFFF:7F00:0/104.
set to the value to be used in the MPLS echo request packet. If the
Address Type is IPv4, an address from the range 127/8. If the
Address Type is IPv6, an address from the range
0:0:0:0:0:FFFF:127/104. By default the source address will be set to
an address of the proxy LSR.
The Reply mode and Global Flags of the Proxy Echo Parameters object The Reply mode and Global Flags of the Proxy Echo Parameters object
are set to the values to be used in the MPLS echo request message are set to the values to be used in the MPLS echo request message
header. The Source UDP Port is set to the value to be used in the header. The Source UDP Port is set to the value to be used in the
MPLS echo request packet. The TTL is set to the value to be used in MPLS echo request packet. The TTL is set to the value to be used in
the outgoing MPLS label stack. See section 5.2.2.2 for further the outgoing MPLS label stack. See section 5.2.2.2 for further
details. details.
Flags MAY be set to request the previous hop address and/or a down- If the previous hop address and/or a downstream mapping object from
stream mapping object from the proxy LSR. the proxy LSR is needed the corresponding flag in the Flags field of
the Proxy Echo Parameters object is set.
A list of Next Hop IP Addresses MAY be included to limit the next A list of Next Hop IP Addresses MAY be included to limit the next
hops towards which the MPLS echo request message will be sent. hops towards which the MPLS echo request message will be sent. These
are encoded as Next Hop sub-objects and included in the Proxy Echo
Parameters object.
Any of following objects MAY be included; these objects will be Any of following objects MAY be included; these objects will be
copied into the MPLS echo request messages: copied into the MPLS echo request messages:
Pad Pad
Vendor Enterprise Number Vendor Enterprise Number
Reply TOS Byte Reply TOS Byte
P2MP Egress Identifier [McstPing] P2MP Egress Identifier [McstPing]
Echo Jitter TLV [McstPing] Echo Jitter TLV [McstPing]
Vendor Private TLVs Vendor Private TLVs
skipping to change at page 6, line 37 skipping to change at page 7, line 5
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.
The proxy LSR then determines if it is authorized to send the speci- The proxy LSR then determines if it is authorized to send the speci-
fied MPLS echo request on behalf of the initiator. An LSR MUST be fied MPLS echo request on behalf of the initiator. An LSR MUST be
capable of filtering addresses to validate initiators. Other filters capable of filtering addresses to validate initiators. Other filters
on FECs or MPLS echo request contents MAY be applied. If a filter on FECs or MPLS echo request contents MAY be applied. If a filter
has been invoked (i.e. configured) and an address does not pass the has been invoked (i.e. configured) and an address does not pass the
filter, then an MPLS echo request message MUST NOT be sent, and the filter, then an MPLS echo request message MUST NOT be sent, and the
event SHOULD be logged. An MPLS proxy ping reply message may be sent event SHOULD be logged. An MPLS proxy ping reply message MAY be sent
with a Return Code of <tba>, "Remote Ping not authorized". with a Return Code of <tba>, "Remote Ping not authorized".
The destination address specified in the Proxy Echo Parameters object
is checked to ensure that it conforms to the address allowed IPv4 or
IPv6 address range. If not, it sets the Return Code set to "Mal-
formed echo request received" and the Subcode set to zero. If the
Reply Mode of the message header is not 1, an MPLS proxy ping reply
message SHOULD be sent as described below.
If the "Request for Previous Hop" flag is set, a Previous Hop Address If the "Request for Previous Hop" flag is set, a Previous Hop Address
Object is formatted for inclusion in the MPLS proxy ping reply. If Object is formatted for inclusion in the MPLS proxy ping reply. If
the previous HOP is unknown or ambiguous the Address Type is set to the previous HOP is unknown or ambiguous the Address Type is set to
"No Address Supplied". "No Address Supplied".
If there is a list of Next Hop addresses in the Proxy Echo Parameters If there are Next Hop sub-objexts 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 sub-objects are from the Proxy Echo
The updated Proxy Echo Parameters object is included in the MPLS Parameters object. The updated object is included in the MPLS proxy
proxy ping reply. 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 over which the MPLS echo
request will be sent out. request will be sent.
If the Reply Mode of the message header is not 1 or 5, an MPLS remote If the Reply Mode of the message header is 1 or is 5 and no errors or
echo reply message SHOULD be sent as described below. modificatons have occurred no MPLS proxy ping reply is sent. Other-
wise an MPLS proxy ping 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. The objects specified above are
specified above. The message is encapsulated in a UDP packet. The included. The message is encapsulated in a UDP packet. The source
source IP address is a routable address of the proxy LSR; the source IP address is a routable address of the proxy LSR; the source port is
port is the well-known UDP port for LSP ping. The destination IP the well-known UDP port for LSP ping. The destination IP address and
address and UDP port are copied from the source IP address and UDP UDP port are copied from the source IP address and UDP port of the
port of the echo request. The IP TTL is set to 255. echo request. The IP TTL is set to 255.
3.2.2. Sending the MPLS echo requests 3.2.2. Sending the MPLS echo requests
A base MPLS echo request is formed as decribed in the next section. A base MPLS echo request is formed as decribed in the next section.
The section below that describes how the base MPLS echo request is The section below that describes how the base MPLS echo request is
sent on each interface. sent on each interface.
3.2.2.1. Forming the base MPLS echo request 3.2.2.1. Forming the base MPLS echo request
A Next_Hop_List is created as follows. If Next Hop addresses were A Next_Hop_List is created as follows. If Next Hop sub-objects were
included in the received Proxy Parameters object, the Next_Hop_List included in the received Proxy Parameters object, the Next_Hop_List
is copied from the Proxy Echo Parameters object as adjusted above. created from the address in those sub-ojects as adjusted above. Oth-
Otherwise, the list is set to all the next hops to which the FEC erwise, the list is set to all the next hops to which the FEC would
would be forwarded. be forwarded.
The proxy LSR then formats an MPLS echo request message. The Global The proxy LSR then formats an MPLS echo request message. The Global
Flags and Reply Mode are copied from the Proxy Echo Parameters Flags and Reply Mode are copied from the Proxy Echo Parameters
object. The Return Code and Return Subcode are set to zero. object. The Return Code and Return Subcode are set to zero.
The Sender's Handle and Sequence Number are copied from the remote The Sender's Handle and Sequence Number are copied from the remote
echo request message. echo request message.
The TimeStamp Sent is set to the time-of-day (in seconds and The TimeStamp Sent is set to the time-of-day (in seconds and
microseconds) that the echo request is sent. The TimeStamp Received microseconds) that the echo request is sent. The TimeStamp Received
skipping to change at page 8, line 16 skipping to change at page 8, line 46
Target FEC Stack Target FEC Stack
Pad Pad
Vendor Enterprise Number Vendor Enterprise Number
Reply TOS Byte Reply TOS Byte
P2MP Egress Identifier [McstPing] P2MP Egress Identifier [McstPing]
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. The destina-
ports are copied from the proxy ping request message. tion port 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- 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 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- 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 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 Proxy Echo Parameters with the Explicit DSCP flag cleared MUST be
included in any MPLS proxy ping reply message. The return code MUST included in any MPLS proxy ping reply message. The return code MUST
skipping to change at page 8, line 39 skipping to change at page 9, line 22
the MPLS Proxy Echo Parameters SHOULD be set to the actual value the MPLS Proxy Echo Parameters SHOULD be set to the actual value
used. 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 topmost FEC in the FEC The TTL for the label corresponding to the FEC specified in the FEC
stack is set such that the TTL on the wire will be one less than the stack is set such that the TTL on the wire will be one less than the
TTL specified in the Proxy Echo Parameters. 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
Two new LSP Ping messages are defined for remote pinging, the MPLS This document defines two new LSP Ping messages, the MPLS proxy ping
proxy ping request message and the MPLS proxy ping reply. request and the MPLS proxy ping reply.
4.1. Proxy Ping Request / Reply Message formats 4.1. Proxy Ping Request / Reply Message formats
Except where noted, the definitions of all fields in the messages are Except where noted, the definitions of all fields in the messages are
identical to those found in [LSP-PING]. The messages have the fol- identical to those found in [RFC4379]. The messages have the follow-
lowing format: ing format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | MUST Be Zero | | Version Number | MUST Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode| | Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle | | Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 36 skipping to change at page 10, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... | | TLVs ... |
. . . .
. . . .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Number Version Number
The Version Number is currently 1. (Note: the Version Number is The Version Number is currently 1. (Note: the Version Number
to be incremented whenever a change is made that affects the is to be incremented whenever a change is made that affects the
ability of an implementation to correctly parse or process an ability of an implementation to correctly parse or process an
MPLS echo request/reply. These changes include any syntactic or MPLS echo request/reply. These changes include any syntactic
semantic changes made to any of the fixed fields, or to any TLV or semantic changes made to any of the fixed fields, or to any
or sub-TLV assignment or format that is defined at a certain TLV or sub-TLV assignment or format that is defined at a
version number. The Version Number may not need to be changed certain version number. The Version Number may not need to be
if an optional TLV or sub-TLV is added.) changed if an optional TLV or sub-TLV is added.)
Message Type Message Type
Type Message Type Message
---- ------- ---- -------
5 MPLS proxy ping request 5 MPLS proxy ping request
6 MPLS proxy ping reply 6 MPLS proxy ping reply
Reply mode Reply mode
The reply modes are the same as [LSP-PING] with the addtion of The reply modes are the same as [RFC4379] with the addtion of
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 or modified request is not fulfilled or is 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 13, line 18 skipping to change at page 14, line 4
receipt. When the flag is set this field contains the DSCP receipt. When the flag is set this field contains the DSCP
value to be used in the MPLS echo request packet IP header. 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:7F00:0/104
Sub-Objects Sub-Objects
A TLV encoded list of sub-objects. Currently one is defined. A TLV encoded list of sub-objects. Currently one is defined.
Sub-Type Length Value Field Sub-Type Length Value Field
-------- ------ ----------- -------- ------ -----------
1 8+ Next Hop 1 8+ Next Hop
5.1.1. Next Hop sub-Object 5.1.1. Next Hop sub-Object
skipping to change at page 16, line 30 skipping to change at page 16, line 30
the label for this FEC was exchanged, this address MUST be the the label for this FEC was exchanged, this address MUST be the
address used in that protocol exchange. address used in that protocol exchange.
Local Address Local Address
The local address used in the protocol adjacency exists by The local address used in the protocol adjacency exists by
which the label for this FEC was exchanged. which the label for this FEC was exchanged.
6. Security Considerations 6. Security Considerations
[To be written] The mechanisms described in this document are intended to be used
within a Service Provider network and to be initiated only under the
authority of that administration.
7. IANA Considerations If such a network also carries internet traffic, or permits IP access
from other administrations, MPLS proxy ping message SHOULD be dis-
carded at those points. This can be accomplished by filtering on
source address or by filtering all MPLS ping messages on UDP port.
[Not complete] Any node which acts as a proxy node SHOULD validate requests against
a set of valid source addresses. An implementation MUST provide such
filtering capabilities.
7.1. Message and Object Type Assignments MPLS proxy ping request messages are IP addressed directly to the
Proxy node. If a node which receives an MPLS proxy ping message via
TTL expiration, it MUST NOT be acted upon.
This document makes the following codepoint assigments (pending IANA MPLS proxy ping requests are limited to making their request via the
action): specification of a FEC. This ensures that only valid MPLS echo
request messages can be created. No label spoofing attacks are
possible.
Registry Codepoint Purpose 7. IANA Considerations
LSP Ping Message Type tba MPLS proxy ping request message This document makes the following assigments (pending IANA action):
LSP Ping Message Types
Type Value Field
---- -----------
tba MPLS proxy ping request message
tba MPLS proxy ping reply tba MPLS proxy ping reply
LSP Ping Object Type tba Proxy Echo Parameters Objects and Sub-Objects
Type Sub-Type Value Field
---- -------- -----------
tba Proxy Echo Parameters
1 Next Hop
tba Reply-to Address tba Reply-to Address
tba Previous Hop Address tba Previous Hop Address
7.2. Return Code Assignments Return Codes
Value Meaning Value Meaning
----- -------
tba Proxy ping request not authorized tba Remote ping not authorized
tba Proxy ping parameters modified tba Proxy ping parameters modified
Reply Modes [pending IANA assignment]
Value Meaning
----- -------
5 Reply via an IPv4/IPv6 UDP packet only if the
proxy request is not fulfilled or is modified
8. References 8. References
8.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-06.txt, June 2008. draft-ietf-mpls-p2mp-lsp-ping-07.txt, September 2008.
8.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", RFC 4875, May 2007. Point-to-Multipoint TE LSPs", RFC 4875, May 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-05.txt, May 2008. draft-ietf-mpls-ldp-p2mp-05.txt, May 2008.
skipping to change at page 18, line 42 skipping to change at page 19, line 26
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
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 ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Full Copyright Notice Full Copyright Notice
Copyright (C) The IETF Trust (2008). This document is subject Copyright (C) The IETF Trust (2008). This document is subject to the
to the rights, licenses and restrictions contained in BCP 78, and rights, licenses and restrictions contained in BCP 78, and except as
except as set forth therein, the authors retain all their rights. 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. 51 change blocks. 
100 lines changed or deleted 141 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/