+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 6 (VPN IPv4 prefix)| Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A description of the Types and Values of the top-level TLVs for LSP
ping are given below:
Type # Value Field
------ -----------
1 Target FEC Stack
2 Downstream Mapping
3 Pad
4 Not Assigned
5 Vendor Enterprise Number
6 Not Assigned
7 Interface and Label Stack
8 Not Assigned
9 Errored TLVs
10 Reply TOS Byte
Types less than 32768 (i.e., with the high-order bit equal to 0) are
mandatory TLVs that MUST either be supported by an implementation or
result in the return code of 2 ("One or more of the TLVs was not
understood") being sent in the echo response.
Types greater than or equal to 32768 (i.e., with the high-order bit
equal to 1) are optional TLVs that SHOULD be ignored if the
implementation does not understand or support them.
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 that specify that. For all other codes, the Return
Subcode MUST be set to zero.
Value Meaning
----- -------
0 No return code
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 Downstream Mapping Mismatch (See Note 1)
6 Upstream Interface Index Unknown (See Note 1)
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>
13 Premature termination of ping due to label stack
shrinking to a single label
Note 1
The Return Subcode contains the point in the label stack where
processing was terminated. If the RSC is 0, no labels were
processed. Otherwise the packet would have been label switched at
depth RSC.
3.2. Target FEC Stack
A Target FEC Stack is a list of sub-TLVs. The number of elements is
determined by looking at the sub-TLV length fields.
Sub-Type Length Value Field
-------- ------ -----------
1 5 LDP IPv4 prefix
2 17 LDP IPv6 prefix
3 20 RSVP IPv4 LSP
4 56 RSVP IPv6 LSP
5 Not Assigned
6 13 VPN IPv4 prefix
7 25 VPN IPv6 prefix
8 14 L2 VPN endpoint
9 10 "FEC 128" Pseudowire (deprecated)
10 14 "FEC 128" Pseudowire
11 16+ "FEC 129" Pseudowire
12 5 BGP labeled IPv4 prefix
13 17 BGP labeled IPv6 prefix
14 5 Generic IPv4 prefix
15 17 Generic IPv6 prefix
16 4 Nil FEC
Other FEC Types will be defined as needed.
Note that this TLV defines a stack of FECs, the first FEC element
corresponding to the top of the label stack, etc.
An MPLS echo request MUST have a Target FEC Stack that describes the
FEC Stack being tested. For example, if an LSR X has an LDP mapping
[LDP] for 192.168.1.1 (say, label 1001), then to verify that label
1001 does indeed reach an egress LSR that announced this prefix via
LDP, X can send an MPLS echo request with an FEC Stack TLV with one
FEC in it, namely, of type LDP IPv4 prefix, with prefix
192.168.1.1/32, and send the echo request with a label of 1001.
Say LSR X wanted to verify that a label stack of <1001, 23456> is the
right label stack to use to reach a VPN IPv4 prefix [see section
3.2.5] of 10/8 in VPN foo. Say further that LSR Y with loopback
address 192.168.1.1 announced prefix 10/8 with Route Distinguisher
RD-foo-Y (which may in general be different from the Route
Distinguisher that LSR X uses in its own advertisements for VPN foo),
label 23456 and BGP next hop 192.168.1.1 [BGP]. Finally, suppose
that LSR X receives a label binding of 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 an FEC Stack TLV 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 an FEC 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 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 example, 1001 is the "outer"
label and 23456 is the "inner" label.)
3.2.1. LDP IPv4 Prefix
The IPv4 Prefix FEC is defined in [LDP]. When an LDP IPv4 prefix is
encoded in a label stack, the following format is used. The value
consists of 4 octets of an IPv4 prefix followed by 1 octet of prefix
length in bits; the format is given below. The IPv4 prefix is in
network byte order; if the prefix is shorter than 32 bits, trailing
bits SHOULD be set to zero. See [LDP] for an example of a Mapping
for an IPv4 FEC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.2. LDP IPv6 Prefix
The IPv6 Prefix FEC is defined in [LDP]. When an LDP IPv6 prefix is
encoded in a label stack, the following format is used. The value
consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix
length in bits; the format is given below. The IPv6 prefix is in
network byte order; if the prefix is shorter than 128 bits, the
trailing bits SHOULD be set to zero. See [LDP] for an example of a
Mapping for an IPv6 FEC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.3. RSVP IPv4 LSP
The value has the format below. The value fields are taken from RFC
3209, sections 4.6.1.1 and 4.6.2.1. See [RSVP-TE].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.4. RSVP IPv6 LSP
The value has the format below. The value fields are taken from RFC
3209, sections 4.6.1.2 and 4.6.2.2. See [RSVP-TE].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.5. VPN IPv4 Prefix
VPN-IPv4 Network Layer Routing Information (NLRI) is defined in
[RFC4365]. This document uses the term VPN IPv4 prefix for a VPN-
IPv4 NLRI that has been advertised with an MPLS label in BGP. See
[BGP-LABEL].
When a VPN IPv4 prefix is encoded in a label stack, the following
format is used. The value field consists of the Route Distinguisher
advertised with the VPN IPv4 prefix, the IPv4 prefix (with trailing 0
bits to make 32 bits in all), and a prefix length, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Route Distinguisher (RD) is an 8-octet identifier; it does not
contain any inherent information. The purpose of the RD is solely to
allow one to create distinct routes to a common IPv4 address prefix.
The encoding of the RD is not important here. When matching this
field to the local FEC information, it is treated as an opaque value.
3.2.6. VPN IPv6 Prefix
VPN-IPv6 Network Layer Routing Information (NLRI) is defined in
[RFC4365]. This document uses the term VPN IPv6 prefix for a VPN-
IPv6 NLRI that has been advertised with an MPLS label in BGP. See
[BGP-LABEL].
When a VPN IPv6 prefix is encoded in a label stack, the following
format is used. The value field consists of the Route Distinguisher
advertised with the VPN IPv6 prefix, the IPv6 prefix (with trailing 0
bits to make 128 bits in all), and a prefix length, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Route Distinguisher is identical to the VPN IPv4 Prefix RD,
except that it functions here to allow the creation of distinct
routes to IPv6 prefixes. See section 3.2.5. When matching this
field to local FEC information, it is treated as an opaque value.
3.2.7. L2 VPN Endpoint
VPLS stands for Virtual Private LAN Service. The terms VPLS BGP NLRI
and VE ID (VPLS Edge Identifier) are defined in [VPLS-BGP]. This
document uses the simpler term L2 VPN endpoint when referring to a
VPLS BGP NLRI. The Route Distinguisher is an 8-octet identifier used
to distinguish information about various L2 VPNs advertised by a
node. The VE ID is a 2-octet identifier used to identify a
particular node that serves as the service attachment point within a
VPLS. The structure of these two identifiers is unimportant here;
when matching these fields to local FEC information, they are treated
as opaque values. The encapsulation type is identical to the PW Type
in section 3.2.8 below.
When an L2 VPN endpoint is encoded in a label stack, the following
format is used. The value field consists of a Route Distinguisher (8
octets), the sender (of the ping)’s VE ID (2 octets), the receiver’s
VE ID (2 octets), and an encapsulation type (2 octets), formatted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender’s VE ID | Receiver’s VE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.8. FEC 128 Pseudowire (Deprecated)
FEC 128 (0x80) is defined in [PW-CONTROL], as are the terms PW ID