maximum number of labels considered in the hash; this SHOULD be
set to zero if unspecified or unlimited.
Multipath Length
The length in octets of the Multipath Information.
Multipath Information
Address or label values encoded according to the Multipath Type.
See the next section below for encoding details.
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 included. Labels are
treated as numbers, i.e., they are right justified in the field.
A Downstream Label is 24 bits, in the same format as an MPLS label
minus the TTL field, i.e., the MSBit of the label is bit 0, the
LSBit is bit 19, the EXP bits are bits 20-22, and bit 23 is the S
bit. The replying router SHOULD fill in the EXP and S bits; the
LSR receiving the echo reply MAY choose to ignore these bits.
Protocol
The Protocol is taken from the following table:
Protocol # Signaling Protocol
---------- ------------------
0 Unknown
1 Static
2 BGP
3 LDP
4 RSVP-TE
3.3.1. Multipath Information Encoding
The Multipath Information encodes labels or addresses that will
exercise this path. The Multipath Information depends on the
Multipath Type. The contents of the field are shown in the table
above. IPv4 addresses are drawn from the range 127/8; IPv6 addresses
are drawn from the range 0:0:0:0:0:FFFF:127/104. Labels are treated
as numbers, i.e., they are right justified in the field. For Type 4,
ranges indicated by Address pairs MUST NOT overlap and MUST be in
ascending sequence.
Type 8 allows a more dense encoding of IP addresses. The IP prefix
is formatted as a base IP address with the non-prefix low-order bits
set to zero. The maximum prefix length is 27. Following the prefix
is a mask of length 2^(32-prefix length) bits for IPv4 and 2^(128-
prefix length) bits for IPv6. Each bit set to 1 represents a valid
address. The address is the base IPv4 address plus the position of
the bit in the mask where the bits are numbered left to right
beginning with zero. For example, the IPv4 addresses 127.2.1.0,
127.2.1.5-127.2.1.15, and 127.2.1.20-127.2.1.29 would be encoded as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Those same addresses embedded in IPv6 would be encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 9 allows a more dense encoding of labels. The label prefix is
formatted as a base label value with the non-prefix low-order 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 beginning with
zero. Label values of all the odd numbers between 1152 and 1279
would be encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0| +-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the received Multipath Information is non-null, the labels and IP
addresses MUST be picked from the set provided. If none of these
labels or addresses map to a particular downstream interface, then
for that interface, the type MUST be set to 0. If the received
Multipath Information is null (i.e., Multipath Length = 0, or for
Types 8 and 9, a mask of all zeros), the type MUST be set to 0.
For example, suppose LSR X at hop 10 has two downstream LSRs, Y and
Z, for the FEC in question. The received X could return Multipath
Type 4, with low/high IP addresses of 127.1.1.1->127.1.1.255 for
downstream LSR Y and 127.2.1.1->127.2.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 127.1.1.1->127.1.1.127
would go to U and 127.1.1.128-> 127.1.1.255 would go to V. Y would
then respond with 3 Downstream Mappings: to U, with Multipath Type 4
(127.1.1.1->127.1.1.127); to V, with Multipath Type 4
(127.1.1.127->127.1.1.255); and to W, with Multipath Type 0.
Note that computing Multipath Information may impose a significant
processing burden on the receiver. A receiver MAY thus choose to
process a subset of the received prefixes. The sender, on receiving
a reply to a Downstream Mapping with partial information, SHOULD
assume that the prefixes missing in the reply were skipped by the
receiver, and MAY re-request information about them in a new echo
request.
3.3.2. Downstream Router and Interface
The notion of "downstream router" and "downstream interface" should
be explained. Consider an LSR X. If a packet that was originated
with TTL n>1 arrived with outermost label L and TTL=1 at LSR X, X
must be able to compute which LSRs could receive the packet if it was
originated with TTL=n+1, over which interface the request would
arrive and what label stack those LSRs would see. (It is outside the
scope of this document to specify how this computation is done.) The
set of these LSRs/interfaces consists of the downstream
routers/interfaces (and their corresponding labels) for X with
respect to L. Each pair of downstream router and interface requires
a separate Downstream Mapping to be added to the reply.
The case where X is the LSR originating the echo request is a special
case. X needs to figure out what LSRs would receive the 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
discussion below on ECMP) or simultaneous paths (e.g., for MPLS
multicast). In the former case, the Multipath Information is used as
a hint to the sender as to how it may influence the choice of these
alternatives.
3.4. Pad TLV
The value part of the Pad TLV contains a variable number (>= 1) of
octets. The first octet takes values from the following table; all
the other octets (if any) are ignored. The receiver SHOULD verify
that the TLV is received in its entirety, but otherwise ignores the
contents of this TLV, apart from the first octet.
Value Meaning
----- -------
1 Drop Pad TLV from reply
2 Copy Pad TLV to reply
3-255 Reserved for future use
3.5. Vendor Enterprise Number
SMI Private Enterprise Numbers are maintained by IANA. The Length is
always 4; the value is the SMI Private Enterprise code, in 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 this TLV
MUST be present. If none of the fields in the fixed part of the
message have Vendor Private extensions, inclusion of this TLV is
OPTIONAL. Vendor Private ranges for Message Types, Reply Modes, and
Return Codes have been defined. When any of these are used, the
Vendor Enterprise Number TLV MUST be included in the message.
3.6. Interface and Label Stack
The Interface and Label Stack TLV MAY be included in a reply message
to report the interface on which the request message was received and
the label stack that was on the packet when it was received. Only
one such object may appear. The purpose of the object is to allow
the upstream router to obtain the exact interface and label stack
information as it appears at the replying LSR.
The Length is K + 4*N octets; N is the number of labels in the label
stack. Values for K are found in the description of Address Type
below. The Value field of a Downstream Mapping has the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Label Stack .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type
The Address Type indicates if the interface is numbered or
unnumbered. It also determines the length of the IP Address and
Interface fields. The resulting total for the initial part of the
TLV is listed in the table below as "K Octets". The Address Type
is set to one of the following values:
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 12
2 IPv4 Unnumbered 12
3 IPv6 Numbered 36
4 IPv6 Unnumbered 24
IP Address and Interface
IPv4 addresses and interface indices are encoded in 4 octets; IPv6
addresses are encoded in 16 octets.
If the interface upon which the echo request message was received
is numbered, then the Address Type MUST be set to IPv4 or IPv6,
the IP Address MUST be set to either the LSR’s Router ID or the
interface address, and the Interface MUST be set to the interface
address.
If the interface is unnumbered, the Address Type MUST be either
IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the
LSR’s Router ID, and the Interface MUST be set to the index
assigned to the interface.
Label Stack
The label stack of the received echo request message. If any TTL
values have been changed by this router, they SHOULD be restored.
3.7. Errored TLVs
The following TLV is a TLV that MAY be included in an echo reply to
inform the sender of an echo request of mandatory TLVs either not
supported by an implementation or parsed and found to be in error.
The Value field contains the TLVs that were not understood, encoded
as sub-TLVs.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8. Reply TOS Byte TLV
This TLV MAY be used by the originator of the echo request to request
that an echo reply be sent with the IP header TOS byte set to the
value specified in the TLV. This TLV has a length of 4 with the
following value field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply-TOS Byte| Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Theory of Operation
An MPLS echo request is used to test a particular LSP. The LSP to be
tested is identified by the "FEC Stack"; for example, if the LSP was
set up via LDP, and is to an egress IP address of 10.1.1.1, the FEC
Stack contains a single element, namely, an LDP IPv4 prefix sub-TLV
with value 10.1.1.1/32. If the LSP being tested is an RSVP LSP, the
FEC Stack consists of a single element that captures the RSVP Session
and Sender Template that uniquely identifies the LSP.
FEC Stacks can be more complex. For example, one may wish to test a
VPN IPv4 prefix of 10.1/8 that is tunneled over an LDP LSP with
egress 10.10.1.1. The FEC Stack would then contain two sub-TLVs, the
bottom being a VPN IPv4 prefix, and the top being an LDP IPv4 prefix.
If the underlying (LDP) tunnel were not known, or was considered
irrelevant, the FEC Stack could be a single element with just the VPN
IPv4 sub-TLV.
When an MPLS echo request is received, the receiver is expected to
verify that the control plane and data plane are both healthy (for
the FEC Stack being pinged) and that the two planes are in sync. The
procedures for this are in section 4.4 below.
4.1. Dealing with Equal-Cost Multi-Path (ECMP)
LSPs need not be simple point-to-point tunnels. Frequently, a single
LSP may originate at several ingresses, and terminate at several
egresses; this is very common with LDP LSPs. LSPs for a given FEC
may also have multiple "next hops" at transit LSRs. At an ingress,
there may also be several different LSPs to choose from to get to the
desired endpoint. Finally, LSPs may have backup paths, detour paths,
and other alternative paths to take should the primary LSP go down.
To deal with the last two first: it is assumed that the LSR sourcing
MPLS echo requests can force the echo request into any desired LSP,
so choosing among multiple LSPs at the ingress is not an issue. The
problem of probing the various flavors of backup paths that will
typically not be used for forwarding data unless the primary LSP is
down will not be addressed here.
Since the actual LSP and path that a given packet may take may not be
known a priori, it is useful if MPLS echo requests can exercise all
possible paths. This, although desirable, may not be practical,
because the algorithms that a given LSR uses to distribute packets
over alternative paths may be proprietary.
To achieve some degree of coverage of alternate paths, there is a
certain latitude in choosing the destination IP address and source
UDP port for an MPLS echo request. This is clearly not sufficient;
in the case of traceroute, more latitude is offered by means of the
Multipath Information of the Downstream Mapping TLV. This is used as
follows. An ingress LSR periodically sends an MPLS traceroute
message to determine whether there are multipaths for a given LSP.
If so, each hop will provide some information how each of its
downstream paths can be exercised. The ingress can then send MPLS
echo requests that exercise these paths. If several transit LSRs
have ECMP, the ingress may attempt to compose these to exercise all
possible paths. However, full coverage may not be possible.
4.2. Testing LSPs That Are Used to Carry MPLS Payloads
To detect certain LSP breakages, it may be necessary to encapsulate
an MPLS echo request packet with at least one additional label when
testing LSPs that are used to carry MPLS payloads (such as LSPs used
to carry L2VPN and L3VPN traffic. For example, when testing LDP or
RSVP-TE LSPs, just sending an MPLS echo request packet may not detect
instances where the router immediately upstream of the destination of
the LSP ping may forward the MPLS echo request successfully over an
interface not configured to carry MPLS payloads because of the use of
penultimate hop popping. Since the receiving router has no means to
differentiate whether the IP packet was sent unlabeled or implicitly
labeled, the addition of labels shimmed above the MPLS echo request
(using the Nil FEC) will prevent a router from forwarding such a
packet out unlabeled interfaces.
4.3. Sending an MPLS Echo Request
An MPLS echo request is a UDP packet. The IP header is set as
follows: the source IP address is a routable address of the sender;
the destination IP address is a (randomly chosen) IPv4 address from
the range 127/8 or IPv6 address from the range
0:0:0:0:0:FFFF:127/104. The IP TTL is set to 1. The source UDP port
is chosen by the sender; the destination UDP port is set to 3503
(assigned by IANA for MPLS echo requests). The Router Alert option
MUST be set in the IP header.
An MPLS echo request is sent with a label stack corresponding to the
FEC Stack being tested. Note that further labels could be applied
if, for example, the normal route to the topmost FEC in the stack is
via a Traffic Engineered Tunnel [RSVP-TE]. If all of the FECs in the
stack correspond to Implicit Null labels, the MPLS echo request is
considered unlabeled even if further labels will be applied in
sending the packet.
If the echo request is labeled, one MAY (depending on what is being
pinged) set the TTL of the innermost label to 1, to prevent the ping
request going farther than it should. Examples of where this SHOULD
be done include pinging a VPN IPv4 or IPv6 prefix, an L2 VPN endpoint
or a pseudowire. Preventing the ping request from going too far can
also be accomplished by inserting a Router Alert label above this
label; however, this may lead to the undesired side effect that MPLS
echo requests take a different data path than actual data. For more
information on how these mechanisms can be used for pseudowire
connectivity verification, see [VCCV].
In "ping" mode (end-to-end connectivity check), the TTL in the
outermost label is set to 255. In "traceroute" mode (fault isolation
mode), the TTL is set successively to 1, 2, and so on.
The sender chooses a Sender’s Handle and a Sequence Number. When