draft-ietf-mpls-lsp-ping-03.txt   draft-ietf-mpls-lsp-ping-04.txt 
Network Working Group K. Kompella (Juniper) Network Working Group K. Kompella (Juniper)
Internet Draft P. Pan (Ciena) Internet Draft P. Pan (Ciena)
draft-ietf-mpls-lsp-ping-03.txt N. Sheth (Juniper) draft-ietf-mpls-lsp-ping-04.txt N. Sheth (Juniper)
Category: Standards Track D. Cooper (Global Crossing) Category: Standards Track D. Cooper (Global Crossing)
Expires: December 2003 G. Swallow (Cisco) Expires: April 2003 G. Swallow (Cisco)
S. Wadhwa (Juniper) S. Wadhwa (Juniper)
R. Bonica (WorldCom) R. Bonica (WorldCom)
June 2003 October 2003
Detecting MPLS Data Plane Failures Detecting MPLS Data Plane Failures
*** DRAFT *** *** DRAFT ***
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
used to detect data plane failures in Multi-Protocol Label Switching used to detect data plane failures in Multi-Protocol Label Switching
(MPLS) Label Switched Paths (LSPs). There are two parts to this (MPLS) Label Switched Paths (LSPs). There are two parts to this
document: information carried in an MPLS "echo request" and "echo document: information carried in an MPLS "echo request" and "echo
reply" for the purposes of fault detection and isolation; and reply" for the purposes of fault detection and isolation; and
mechanisms for reliably sending the echo reply. mechanisms for reliably sending the echo reply.
Changes since last revision Changes since last revision
(This section to be removed before publication.) (This section to be removed before publication.)
- Changed title to "Detecting MPLS Data Plane Failures" Clarified that an MPLS echo request/reply can be either an IPv4 or an
- removed section 5 "Reliable Reply Path" IPv6 packet.
- filled in IANA section
- added new top level TLV for Vendor Enterprise Code Expanded on Return Codes (section 3.1).
- Clarified Downstream Router ID and Downstream Interface Address
- Clarified receiving procedure Expanded and reformatted the section on Downstream Mapping.
- Example for multipath operation
Expanded the section on Receiving an MPLS Echo Request
Issues Issues
(This section to be removed before publication.) (This section to be removed before publication.)
- Question: use two bits from the TLV space to indicate Need to fill out Downstream Verification.
- Ignore TLV if not understood
- Reflect TLV in reply Need to address issues with pinging L3VPN FECs.
- Tweak error codes? Add stack depth?
- More multipath stuff?
1. Introduction 1. Introduction
This document describes a simple and efficient mechanism that can be This document describes a simple and efficient mechanism that can be
used to detect data plane failures in MPLS LSPs. There are two parts used to detect data plane failures in MPLS LSPs. There are two parts
to this document: information carried in an MPLS "echo request" and to this document: information carried in an MPLS "echo request" and
"echo reply"; and mechanisms for transporting the echo reply. The "echo reply"; and mechanisms for transporting the echo reply. The
first part aims at providing enough information to check correct first part aims at providing enough information to check correct
operation of the data plane, as well as a mechanism to verify the operation of the data plane, as well as a mechanism to verify the
data plane against the control plane, and thereby localize faults. data plane against the control plane, and thereby localize faults.
skipping to change at page 5, line 7 skipping to change at page 4, line 24
One way these tools can be used is to periodically ping a FEC to One way these tools can be used is to periodically ping a FEC to
ensure connectivity. If the ping fails, one can then initiate a ensure connectivity. If the ping fails, one can then initiate a
traceroute to determine where the fault lies. One can also traceroute to determine where the fault lies. One can also
periodically traceroute FECs to verify that forwarding matches the periodically traceroute FECs to verify that forwarding matches the
control plane; however, this places a greater burden on transit LSRs control plane; however, this places a greater burden on transit LSRs
and thus should be used with caution. and thus should be used with caution.
3. Packet Format 3. Packet Format
An MPLS echo request is a (possibly labelled) UDP packet; the An MPLS echo request is a (possibly labelled) IPv4 or IPv6 UDP
contents of the UDP packet have the following format: packet; the contents of the UDP packet have the following 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 6, line 10 skipping to change at page 5, line 29
1 MPLS Echo Request 1 MPLS Echo Request
2 MPLS Echo Reply 2 MPLS Echo Reply
The Reply Mode can take one of the following values: The Reply Mode can take one of the following values:
Value Meaning Value Meaning
----- ------- ----- -------
1 Do not reply 1 Do not reply
2 Reply via an IPv4 UDP packet 2 Reply via an IPv4 UDP packet
3 Reply via an IPv4 UDP packet with Router Alert 3 Reply via an IPv4 UDP packet with Router Alert
4 Reply via application level control channel
An MPLS echo request with "Do not reply" may be used for one-way An MPLS echo request with "Do not reply" may be used for one-way
connectivity tests; the receiving router may log gaps in the sequence connectivity tests; the receiving router may log gaps in the sequence
numbers and/or maintain delay/jitter statistics. An MPLS echo numbers and/or maintain delay/jitter statistics. An MPLS echo
request would normally have "Reply via an IPv4 UDP packet"; if the request would normally have "Reply via an IPv4 UDP packet"; if the
normal IPv4 return path is deemed unreliable, one may use "Reply via normal IPv4 return path is deemed unreliable, one may use "Reply via
an IPv4 UDP packet with Router Alert" (note that this requires that an IPv4 UDP packet with Router Alert" (note that this requires that
all intermediate routers understand and know how to forward MPLS echo all intermediate routers understand and know how to forward MPLS echo
replies). replies).
The Return Code is set to zero by the sender. The receiver can set Any application which supports an IP control channel between its
it to one of the following values: control entities may set the Reply Mode to 4 to ensure that replies
use that same channel. Further definition of this codepoint is
Value Meaning application specific and thus beyond the scope of this docuemnt.
----- -------
0 The error code is contained in the Error Code TLV
1 Malformed echo request received
2 One or more of the TLVs was not understood
3 Replying router is an egress for the FEC
4 Replying router has no mapping for the FEC
5 Replying router is not one of the "Downstream Routers"
6 Replying router is one of the "Downstream Routers",
and its mapping for this FEC on the received interface
is the given label
7 Replying router is one of the "Downstream Routers",
but its mapping for this FEC is not the given label
The Return Subcode is unused at present and SHOULD be set to zero. Return Codes and Subcodes are described in the next section.
The Sender's Handle is filled in by the sender, and returned The Sender's Handle is filled in by the sender, and returned
unchanged by the receiver in the echo reply (if any). There are no unchanged by the receiver in the echo reply (if any). There are no
semantics associated with this handle, although a sender may find semantics associated with this handle, although a sender may find
this useful for matching up requests with replies. this useful for matching up requests with replies.
The Sequence Number is assigned by the sender of the MPLS echo The Sequence Number is assigned by the sender of the MPLS echo
request, and can be (for example) used to detect missed replies. request, and can be (for example) used to detect missed replies.
The TimeStamp Sent is the time-of-day (in seconds and microseconds, The TimeStamp Sent is the time-of-day (in seconds and microseconds,
skipping to change at page 7, line 29 skipping to change at page 6, line 39
align to a four-octet boundary. align to a four-octet boundary.
Type # Value Field Type # Value Field
------ ----------- ------ -----------
1 Target FEC Stack 1 Target FEC Stack
2 Downstream Mapping 2 Downstream Mapping
3 Pad 3 Pad
4 Error Code 4 Error Code
5 Vendor Enterprise Code 5 Vendor Enterprise Code
3.1. Target FEC Stack 3.1. Return Codes
The Return Code is set to zero by the sender. The receiver can set
it to one of the values listed below. The notation <RSC> refers to
the Return Subcode. This field is filled in with the stack-depth for
those codes which specify that. For all other codes the Return
Subcode MUST be set to zero.
Value Meaning
----- -------
0 No return code or return code contained in the Error
Code TLV
1 Malformed echo request received
2 One or more of the TLVs was not understood
3 Replying router is an egress for the FEC at stack
depth <RSC>
4 Replying router has no mapping for the FEC at stack
depth <RSC>
5 Reserved
6 Reserved
7 Reserved
8 Label switched at stack-depth <RSC>
9 Label switched but no MPLS forwarding at stack-depth
<RSC>
10 Mapping for this FEC is not the given label at stack
depth <RSC>
11 No label entry at stack-depth <RSC>
12 Protocol not associated with interface at FEC stack
depth <RSC>
3.2. Target FEC Stack
A Target FEC Stack is a list of sub-TLVs. The number of elements is A Target FEC Stack is a list of sub-TLVs. The number of elements is
determined by the looking at the sub-TLV length fields. determined by the looking at the sub-TLV length fields.
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
1 5 LDP IPv4 prefix 1 5 LDP IPv4 prefix
2 17 LDP IPv6 prefix 2 17 LDP IPv6 prefix
3 20 RSVP IPv4 Session Query 3 20 RSVP IPv4 Session Query
4 56 RSVP IPv6 Session Query 4 56 RSVP IPv6 Session Query
skipping to change at page 8, line 27 skipping to change at page 8, line 33
1001 for 192.168.1.1 via LDP. X has two choices in sending an MPLS 1001 for 192.168.1.1 via LDP. X has two choices in sending an MPLS
echo request: X can send an MPLS echo request with a FEC Stack TLV echo request: X can send an MPLS echo request with a FEC Stack TLV
with a single FEC of type VPN IPv4 prefix with a prefix of 10/8 and a with a single FEC of type VPN IPv4 prefix with a prefix of 10/8 and a
Route Distinguisher of RD-foo-Y. Alternatively, X can send a FEC Route Distinguisher of RD-foo-Y. Alternatively, X can send a FEC
Stack TLV with two FECs, the first of type LDP IPv4 with a prefix of Stack TLV with two FECs, the first of type LDP IPv4 with a prefix of
192.168.1.1/32 and the second of type of IP VPN with a prefix 10/8 192.168.1.1/32 and the second of type of IP VPN with a prefix 10/8
with Route Distinguisher of RD-foo-Y. In either case, the MPLS echo with Route Distinguisher of RD-foo-Y. In either case, the MPLS echo
request would have a label stack of <1001, 23456>. (Note: in this request would have a label stack of <1001, 23456>. (Note: in this
example, 1001 is the "outer" label and 23456 is the "inner" label.) example, 1001 is the "outer" label and 23456 is the "inner" label.)
3.1.1. LDP IPv4 Prefix 3.2.1. LDP IPv4 Prefix
The value consists of four octets of an IPv4 prefix followed by one The value consists of four octets of an IPv4 prefix followed by one
octet of prefix length in bits. The IPv4 prefix is in network byte octet of prefix length in bits. The IPv4 prefix is in network byte
order. See [LDP] for an example of a Mapping for an IPv4 FEC. order. See [LDP] for an example of a Mapping for an IPv4 FEC.
3.1.2. LDP IPv6 Prefix 3.2.2. LDP IPv6 Prefix
The value consists of sixteen octets of an IPv6 prefix followed by The value consists of sixteen octets of an IPv6 prefix followed by
one octet of prefix length in bits. The IPv6 prefix is in network one octet of prefix length in bits. The IPv6 prefix is in network
byte order. See [LDP] for an example of a Mapping for an IPv6 FEC. byte order. See [LDP] for an example of a Mapping for an IPv6 FEC.
3.1.3. RSVP IPv4 Session 3.2.3. RSVP IPv4 Session
The value has the format below. The value fields are taken from The value has the format below. The value fields are taken from
[RFC3209, sections 4.6.1.1 and 4.6.2.1]. [RFC3209, sections 4.6.1.1 and 4.6.2.1].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address | | IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address | | IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.4. RSVP IPv6 Session 3.2.4. RSVP IPv6 Session
The value has the format below. The value fields are taken from The value has the format below. The value fields are taken from
[RFC3209, sections 4.6.1.2 and 4.6.2.2]. [RFC3209, sections 4.6.1.2 and 4.6.2.2].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address | | IPv6 tunnel end point address |
| | | |
| | | |
skipping to change at page 9, line 38 skipping to change at page 9, line 43
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address | | IPv6 tunnel sender address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.5. VPN IPv4 Prefix 3.2.5. VPN IPv4 Prefix
The value field consists of the Route Distinguisher advertised with The value field consists of the Route Distinguisher advertised with
the VPN IPv4 prefix, the IPv4 prefix and a prefix length, as follows: the VPN IPv4 prefix, the IPv4 prefix and a prefix length, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.6. VPN IPv6 Prefix 3.2.6. VPN IPv6 Prefix
The value field consists of the Route Distinguisher advertised with The value field consists of the Route Distinguisher advertised with
the VPN IPv6 prefix, the IPv6 prefix and a prefix length, as follows: the VPN IPv6 prefix, the IPv6 prefix and a prefix length, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix | | IPv6 prefix |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.7. L2 VPN Endpoint 3.2.7. L2 VPN Endpoint
The value field consists of a Route Distinguisher (8 octets), the The value field consists of a Route Distinguisher (8 octets), the
sender (of the ping)'s CE ID (2 octets), the receiver's CE ID (2 sender (of the ping)'s CE ID (2 octets), the receiver's CE ID (2
octets), and an encapsulation type (2 octets), formatted as follows: octets), and an encapsulation type (2 octets), formatted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's CE ID | Receiver's CE ID | | Sender's CE ID | Receiver's CE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero | | Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.8. L2 Circuit ID 3.2.8. L2 Circuit ID
The value field consists of a remote PE address (the address of the The value field consists of a remote PE address (the address of the
targetted LDP session), a VC ID and an encapsulation type, as targetted LDP session), a VC ID and an encapsulation type, as
follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address | | Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC ID | | VC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero | | Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2. Downstream Mapping 3.3. Downstream Mapping
The Downstream Mapping is an optional TLV in an echo request. The The Downstream Mapping object is an optional TLV. Only one
Length is 16 + 4*M + 4*N octets, where M is the Multipath Length, and Downstream Mapping request may appear in and echo request. The
N is the number of Downstream Labels. The Value field of a presence of a Downstream Mapping object is a request that Downstream
Mapping objects be included in the echo reply. If the replying
router is the destination of the FEC, then a Downstream Mapping TLV
SHOULD NOT be included in the echo reply. Otherwise Downstream
Mapping objects SHOULD include a Downstream Mapping object for each
interface over which this FEC could be forwarded.
The Length is 16 + M + 4*N octets, where M is the Multipath Length,
and N is the number of Downstream Labels. The Value field of a
Downstream Mapping has the following format: Downstream Mapping has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IPv4 Address | | MTU | Address Type | Resvd (SBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address | | Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash Key Type | Depth Limit | No of Multipaths | | Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address or Next Label | | Hash Key Type | Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. (more IP Addresses or Next Labels) . . (Multipath Information) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol | | Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol | | Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the interface to the downstream LSR is numbered, then the Maximum Transmission Unit (MTU)
Downstream IPv4 Address can either be the downstream LSR's Router ID
or the interface address of the downstream LSR. In this case, the
Address Type is set to IPv4 and the Downstream Interface Address is
set to the downstream LSR's interface address. If the interface to
the downstream LSR is unnumbered, the Downstream IPv4 Address MUST be
the downstream LSR's Router ID, and the Address Type MUST be
Unnumbered, and the Downstream Interface Address MUST be the index
assigned by the upstream LSR to the interface.
The MTU is the largest MPLS frame (including label stack) that fits The MTU is the largest MPLS frame (including label stack) that
on the interface to the Downstream LSR. The Downstream Interface fits on the interface to the Downstream LSR.
Address Type is one of:
Address Type
The Address Type indicates if the interface is numbered or
unnumbered and is set to one of the following values:
Type # Address Type Type # Address Type
------ ------------ ------ ------------
1 IPv4 1 IPv4
2 Unnumbered 2 Unnumbered
3 IPv6
'Protocol' is taken from the following table: The field marked SBZ SHOULD be set to zero when sending and
SHOULD be ignored on receipt.
Downstream IP Address and Downstream Interface Address
If the interface to the downstream LSR is numbered, then the
Address Type MUST be set to IPv4 or IPv6, the Downstream IP
Address MUST be set to either the downstream LSR's Router ID or
the interface address of the downstream LSR, and the Downstream
Interface Address MUST be set to the downstream LSR's interface
address.
If the interface to the downstream LSR is unnumbered, the Address
Type MUST be Unnumbered, the Downstream IP Address MUST be the
downstream LSR's Router ID (4 octets), and the Downstream
Interface Address MUST be set to the index assigned by the
upstream LSR to the interface.
Multipath Length
The length in octets of the Multipath Information.
Downstream Label(s)
The set of labels in the label stack as it would have appeared if
this router were forwarding the packet through this interface.
Any Implicit Null labels are explicitly inluded. Labels are
treated as numbers, i.e. they are right justified in the field.
Protocol
The Protocol is taken from the following table:
Protocol # Signaling Protocol Protocol # Signaling Protocol
---------- ------------------ ---------- ------------------
0 Unknown 0 Unknown
1 Static 1 Static
2 BGP 2 BGP
3 LDP 3 LDP
4 RSVP-TE 4 RSVP-TE
5 Reserved; see Appendix 5 Reserved; see Appendix
The notion of "downstream router" and "downstream interface" should The notion of "downstream router" and "downstream interface"
be explained. Consider an LSR X. If a packet that was originated should be explained. Consider an LSR X. If a packet that was
with TTL n>1 arrived with outermost label L at LSR X, X must be able originated with TTL n>1 arrived with outermost label L at LSR X,
to compute which LSRs could receive the packet if it was originated X must be able to compute which LSRs could receive the packet if
with TTL=n+1, over which interface the request would arrive and what it was originated with TTL=n+1, over which interface the request
label stack those LSRs would see. (It is outside the scope of this would arrive and what label stack those LSRs would see. (It is
document to specify how this computation is done.) The set of these outside the scope of this document to specify how this
LSRs/interfaces are the downstream routers/interfaces (and their computation is done.) The set of these LSRs/interfaces are the
corresponding labels) for X with respect to L. Each pair of downstream routers/interfaces (and their corresponding labels)
downstream router and interface requires a separate Downstream for X with respect to L. Each pair of downstream router and
Mapping to be added to the reply, and is given a unique DS Index. interface requires a separate Downstream Mapping to be added to
(Note that there are multiple Downstream Label fields in each TLV as the reply. (Note that there are multiple Downstream Label fields
the incoming label L may be swapped with a label stack.) in each TLV as the incoming label L may be swapped with a label
stack.)
The case where X is the LSR originating the echo request is a special The case where X is the LSR originating the echo request is a
case. X needs to figure out what LSRs would receive the MPLS echo special case. X needs to figure out what LSRs would receive the
request for a given FEC Stack that X originates with TTL=1. MPLS echo request for a given FEC Stack that X originates with
TTL=1.
The set of downstream routers at X may be alternative paths (see the The set of downstream routers at X may be alternative paths (see
discussion below on ECMP) or simultaneous paths (e.g., for MPLS the discussion below on ECMP) or simultaneous paths (e.g., for
multicast). In the former case, the Multipath sub-field is used as a MPLS multicast). In the former case, the Multipath sub-field is
hint to the sender as to how it may influence the choice of these used as a hint to the sender as to how it may influence the
alternatives. The "No of Multipaths" is the number of IP choice of these alternatives. The "No of Multipaths" is the
Address/Next Label fields. The Hash Key Type is taken from the number of IP Address/Next Label fields. The Hash Key Type is
following table: taken from the following table:
Hash Key Type IP Address or Next Label Key Type Multipath Information
-------------------- ------------------------ --- ---------------- ---------------------
0 no multipath (nothing; M = 0) 0 no multipath (empty; M = 0)
1 label M labels 1 label labels
2 IP address M IP addresses 2 IP address IP addresses
3 label range M/2 low/high label pairs 3 label range low/high label pairs
4 IP address range M/2 low/high address pairs 4 IP address range low/high address pairs
5 no more labels (nothing; M = 0) 5 no more labels (empty; M = 0)
6 All IP addresses (nothing; M = 0) 6 All IP addresses (empty; M = 0)
7 no match (nothing; M = 0) 7 no match (empty; M = 0)
8 Bit-masked IPv4 IP address prefix and bit mask
address set
9 Bit-masked label set Label prefix and bit mask
Type 0 indicates that all packets will be forwarded out this one
interface.
Types 1, 2, 3, 4, 8 and 9 specify that the supplied Multipath
Information will serve to execise this path.
Types 5 and 6 are TBD.
Type 7 indicates that no matches are possible given the Multipath
Information in the received DS mapping information.
Depth Limit
The Depth Limit is applicable only to a label stack, and is the The Depth Limit is applicable only to a label stack, and is the
maximum number of labels considered in the hash; this SHOULD be set maximum number of labels considered in the hash; this SHOULD be
to zero if unspecified or unlimited. set to zero if unspecified or unlimited.
IP Address or Next Label is an IP address from the range 127/8 or an Multipath Information
next label which will exercise this particular path.
The semantics of the Hash Key Type and IP Address/Next Label are as The multipath information encodes labels or addresses which will
follows: exercise this path. The multipath informaiton depends on the
hash key type. The contents of the field are shown in the table
above. IP addresses are drawn from the range 127/8. Labels are
treated as numbers, i.e. they are right justified in the field.
Label and Address pairs MUST NOT overlap and MUST be in ascending
sequence.
type 1 - a list of single labels is provided, any one of which Hash key 8 allows a denser encoding of IP address. The IPv4
will cause the hash to match this MP path. prefix is formatted as a base IPv4 address with the non-prefix
type 2 - a list of single IP addresses is provided, any one of low order bits set to zero. The maximum prefix length is 27.
which will cause the hash to match this MP path. Following the prefix is a mask of length 2^(32-prefix length)
type 3 - a list of label ranges is provided, any one of which will bits. Each bit set to one represents a valid address. The
cause the hash to match this MP path. address is the base IPv4 address plus the position of the bit in
type 4 - a list of IP address ranges is provided, any one of which the mask where the bits are numbered left to right begining with
will cause the hash to match this MP path. zero.
type 5 - if no more labels are provided on the stack, this MP path
will apply (can only appear once).
type 6 - Any IP addresses matches. Underlying labels may go
elsewhere, but all IP takes only one MP path (can only
appear once).
type 7 - no matches are possible given the set of "Multipath
Exercise TLV" provided by prior hops.
If prior hops provide a "Downstream Multipath Mapping TLV" the labels Hash key 9 allows a denser encoding of Labels. The label prefix
and IP addresses should be picked from the set provided in prior is formatted as a base label value with the non-prefix low order
"Multipath Exercise TLV" or "Hash Key Type" of 7 used. bits set to zero. The maximum prefix (including leading zeros
due to encoding) length is 27. Following the prefix is a mask of
length 2^(32-prefix length) bits. Each bit set to one represents
a valid Label. The label is the base label plus the position of
the bit in the mask where the bits are numbered left to right
begining with zero.
For example, suppose LSR X at hop 10 has two downstream LSRs Y and Z If the received DS mapping information is non-null the labels and
for the FEC in question. X could return Hash Key Type 4, with IP addresses MUST be picked from the set provided or the Hash Key
low/high IP addresses of 1.1.1.1->1.1.1.255 for downstream LSR Y and Type MUST be set to 7.
2.1.1.1->2.1.1.255 for downstream LSR Z. The head end reflects this
information to LSR Y. Y, which has three downstream LSRs U, V and W,
computes that 1.1.1.1->1.1.1.127 would go to U and 1.1.1.128->
1.1.1.255 would go to V. Y would then respond with 3 Downstream
Mappings: to U, with Hash Key Type 4 (1.1.1.1->1.1.1.127); to V, with
Hash Key Type 4 (1.1.1.127->1.1.1.255); and to W, with Hash Key Type
7.
3.3. Pad TLV For example, suppose LSR X at hop 10 has two downstream LSRs Y
and Z for the FEC in question. X could return Hash Key Type 4,
with low/high IP addresses of 1.1.1.1->1.1.1.255 for downstream
LSR Y and 2.1.1.1->2.1.1.255 for downstream LSR Z. The head end
reflects this information to LSR Y. Y, which has three
downstream LSRs U, V and W, computes that 1.1.1.1->1.1.1.127
would go to U and 1.1.1.128-> 1.1.1.255 would go to V. Y would
then respond with 3 Downstream Mappings: to U, with Hash Key Type
4 (1.1.1.1->1.1.1.127); to V, with Hash Key Type 4
(1.1.1.127->1.1.1.255); and to W, with Hash Key Type 7.
3.4. Pad TLV
The value part of the Pad TLV contains a variable number (>= 1) of The value part of the Pad TLV contains a variable number (>= 1) of
octets. The first octet takes values from the following table; all octets. The first octet takes values from the following table; all
the other octets (if any) are ignored. The receiver SHOULD verify the other octets (if any) are ignored. The receiver SHOULD verify
that the TLV is received in its entirety, but otherwise ignores the that the TLV is received in its entirety, but otherwise ignores the
contents of this TLV, apart from the first octet. contents of this TLV, apart from the first octet.
Value Meaning Value Meaning
----- ------- ----- -------
1 Drop Pad TLV from reply 1 Drop Pad TLV from reply
2 Copy Pad TLV to reply 2 Copy Pad TLV to reply
3-255 Reserved for future use 3-255 Reserved for future use
3.4. Error Code 3.5. Error Code
The Error Code TLV is currently not defined; its purpose is to The Error Code TLV is currently not defined; its purpose is to
provide a mechanism for a more elaborate error reporting structure, provide a mechanism for a more elaborate error reporting structure,
should the reason arise. should the reason arise.
3.5. Vendor Enterprise Code 3.6. Vendor Enterprise Code
The Length is always 4; the value is the SMI Enterprise code, in The Length is always 4; the value is the SMI Enterprise code, in
network octet order, of the vendor with a Vendor Private extension to network octet order, of the vendor with a Vendor Private extension to
any of the fields in the fixed part of the message, in which case any of the fields in the fixed part of the message, in which case
this TLV MUST be present. If none of the fields in the fixed part of this TLV MUST be present. If none of the fields in the fixed part of
the message have vendor private extensions, this TLV is OPTIONAL. the message have vendor private extensions, this TLV is OPTIONAL.
4. Theory of Operation 4. Theory of Operation
An MPLS echo request is used to test a particular LSP. The LSP to be An MPLS echo request is used to test a particular LSP. The LSP to be
skipping to change at page 16, line 47 skipping to change at page 18, line 26
being pinged SHOULD be sent in the echo request. For n>1, the being pinged SHOULD be sent in the echo request. For n>1, the
Downstream Mapping TLVs from the echo reply for TTL=(n-1) are copied Downstream Mapping TLVs from the echo reply for TTL=(n-1) are copied
to the echo request with TTL=n; the sender MAY choose to reduce the to the echo request with TTL=n; the sender MAY choose to reduce the
size of a "Downstream Multipath Mapping TLV" when copying into the size of a "Downstream Multipath Mapping TLV" when copying into the
next echo request as long as the Hash Key Type matching the label or next echo request as long as the Hash Key Type matching the label or
IP address used to exercise the current MP is still present. IP address used to exercise the current MP is still present.
4.3. Receiving an MPLS Echo Request 4.3. Receiving an MPLS Echo Request
An LSR X that receives an MPLS echo request first parses the packet An LSR X that receives an MPLS echo request first parses the packet
to ensure that it is a well-formed packet, and that the TLVs are to ensure that it is a well-formed packet, and that the TLVs that are
understood. If not, X SHOULD send an MPLS echo reply with the Return not marked "Ignore" are understood. If not, X SHOULD send an MPLS
Code set to "Malformed echo request received" or "TLV not understood" echo reply with the Return Code set to "Malformed echo request
(as appropriate), and the Subcode set to the appropriate value. received" or "TLV not understood" (as appropriate), and the Subcode
set to zero. In the latter case, the misunderstood TLVs (only) are
included in the reply.
If the echo request is good, X then checks whether it is a valid If the echo request is good, X notes the interface I over which the
transit or egress LSR for the FEC in the echo request. If not, X MAY echo was received, and the label stack with which it came. If the
log this fact. If it is, X notes that interface I over which the MPLS echo request contained a Downstream Verification object (TBD),
echo was received, and the label L with which it came. X checks then X must format this information as a Downstream Verification
whether it actually advertised L for the FEC in the echo request; X object and include it in its MPLS echo reply message.
MAY further check whether it expects L over interface I or not.
If the echo request contains a Downstream Mapping TLV, X MUST further X matches up the labels in the received label stack with the FECs
check whether its Router ID or one of its interface addresses matches contained in the FEC stack. The matching is done beginning at the
one of the Downstream IPv4 Address; if the Address Type is bottom of both stacks and working up. For reporting purposes the
Unnumbered, X further checks if the interface I has the given bottom of stack is consided to be stack-depth of 1. This is to
(upstream) index. If these check out, X determines whether the given establish an absolute reference for the case where the stack may have
Downstream Label is in fact the label that X sent as its mapping for more labels than are in the FEC stack and the sender of the ping has
the FEC over the downstream interface. The result of the checks in not requested that a Downstream Verification TLV be sent. If there
the previous and this paragraph are captured in the Return are more FECs than labels, the extra FECs are assumed to correspond
Code/Subcode. to Implicit Null Labels.
Note: in all the error codes listed in this draft a stack-depth of 0
means "no value specified". This allows compatibility with existing
implementations which do not use the Return Subcode field.
X sets a variable, call it current-stack-depth, to the number of
labels in the received label stack. Processing now continues with
the following steps:
1. Check if there is a FEC corresponding to the current-stack-
depth. If there is, go to step 2. If not, check if the label is
valid on interface I. If it is, continue with step 4. Otherwise
X MUST send an MPLS echo reply with a Return Code 11, "No label
entry at stack-depth" and a Return Subcode set to current-stack-
depth.
2. Check the FEC at the current-stack-depth to determine what
protocol was used to advertise it. If X can determine that no
protocol associated with interface I would have advertised a FEC
of that FEC-Type, X MUST send an MPLS echo reply with a Return
Code 12, "Protocol not associated with interface at FEC stack-
depth" and a Return Subcode set to current-stack-depth.
3. Check that the mapping for the FEC at the current-stack-depth is
the corresponding label.
If no mapping for the FEC exists, X MUST send an MPLS echo reply
with a Return Code 4, "Replying router has no mapping for the FEC
at stack-depth" and a Return Subcode set to current- stack-depth.
If a mapping is found, but the mapping is not the corresponding
label, X MUST send an MPLS echo reply with a Return Code 10,
"Mapping for this FEC is not the given label at stack-depth" and
a Return Subcode set to current-stack-depth.
4. X determines the label operation. If the operation is to pop and
continue processing, X checks the current-stack-depth. If it is
one, X MUST send an MPLS echo reply with a Return Code 3,
"Replying router is an egress for the FEC at stack depth" and a
Return Subcode set to one. Otherwise, X decrements current-
stack-depth and goes back to step 1.
If the label operation is pop and switch based on the popped
label, X then checks if it is valid to forward a labelled packet.
If it is not valid to forward a labelled packet, or the current-
stack-depth is one, X MUST send an MPLS echo reply with a Return
Code 9, "Label switched but no MPLS forwarding at stack-depth"
and a Return Subcode set to current-stack-depth. Otherwise, X
MUST send an MPLS echo reply with a Return Code 8, "Label
switched at stack-depth" and a Return Subcode set to current-
stack-depth.
If the label operation is swap, X MUST send an MPLS echo reply
with a Return Code 8, "Label switched at stack-depth" and a
Return Subcode set to current-stack-depth.
If the MPLS echo request contains a downstream mapping TLV, and the
MPLS echo reply has either a Return Code of 8, or a Return Code of 9
with a Return Subcode of 1 then Downstream mapping TLVs SHOULD be
included for each multipath.
If the echo request has a Reply Mode that wants a reply, X uses the If the echo request has a Reply Mode that wants a reply, X uses the
procedure in the next subsection to send the echo reply. procedure in the next subsection to send the echo reply.
4.4. Sending an MPLS Echo Reply 4.4. Sending an MPLS Echo Reply
An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response
to an MPLS echo request. The source IP address is a routable address to an MPLS echo request. The source IP address is a routable address
of the replier; the source port is the well-known UDP port for MPLS of the replier; the source port is the well-known UDP port for MPLS
ping. The destination IP address and UDP port are copied from the ping. The destination IP address and UDP port are copied from the
skipping to change at page 21, line 11 skipping to change at page 24, line 11
Private Use, the Length MUST be at least 4, and the first four octets Private Use, the Length MUST be at least 4, and the first four octets
MUST be that vendor's SMI Enterprise Code, in network octet order. MUST be that vendor's SMI Enterprise Code, in network octet order.
The rest of the Value field is private to the vendor. The rest of the Value field is private to the vendor.
Acknowledgments Acknowledgments
This document is the outcome of many discussions among many people, This document is the outcome of many discussions among many people,
that include Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa that include Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa
Gan, Brook Bailey, Eric Rosen and Ina Minei. Gan, Brook Bailey, Eric Rosen and Ina Minei.
The Multipath Exercise sub-field of the Downstream Mapping TLV was The Multipath Information sub-field of the Downstream Mapping TLV was
adapted from text suggested by Curtis Villamizar. adapted from text suggested by Curtis Villamizar.
Appendix Appendix
This appendix specifies non-normative aspects of detecting MPLS data This appendix specifies non-normative aspects of detecting MPLS data
plane liveness. plane liveness.
5.1. CR-LDP FEC 5.1. CR-LDP FEC
This section describes how a CR-LDP FEC can be included in an Echo This section describes how a CR-LDP FEC can be included in an Echo
Request using the following FEC subtype: Request using the following FEC subtype:
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -------------
5 6 CR-LDP LSP ID 5 6 CR-LDP LSP ID
The value consists of the LSPID of the LSP being pinged. An LSPID is The value consists of the LSPID of the LSP being pinged. An LSPID is
a four octet IPv4 address (a local address on the ingress LSR, for a four octet IPv4 address (a local address on the ingress LSR, for
example, the Router ID) plus a two octet identifier that is unique example, the Router ID) plus a two octet identifier that is unique
per LSP on a given ingress LSR. per LSP on a given ingress LSR.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 End of changes. 

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