(Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero
32-bit connection ID. The PW Type is a 15-bit number indicating the
encapsulation type. It is carried right justified in the field below
termed encapsulation type with the high-order bit set to zero. Both
of these fields are treated in this protocol as opaque values.
When an FEC 128 is encoded in a label stack, the following format is
used. The value field consists of the remote PE address (the
destination address of the targeted LDP session), the PW ID, and the
encapsulation type 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This FEC is deprecated and is retained only for backward
compatibility. Implementations of LSP ping SHOULD accept and process
this TLV, but SHOULD send LSP ping echo requests with the new TLV
(see next section), unless explicitly configured to use the old TLV.
An LSR receiving this TLV SHOULD use the source IP address of the LSP
echo request to infer the sender’s PE address.
3.2.9. FEC 128 Pseudowire (Current)
FEC 128 (0x80) is defined in [PW-CONTROL], as are the terms PW ID
(Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero
32-bit connection ID. The PW Type is a 15-bit number indicating the
encapsulation type. It is carried right justified in the field below
termed encapsulation type with the high-order bit set to zero.
Both of these fields are treated in this protocol as opaque values.
When matching these field to the local FEC information, the match
MUST be exact.
When an FEC 128 is encoded in a label stack, the following format is
used. The value field consists of the sender’s PE address (the
source address of the targeted LDP session), the remote PE address
(the destination address of the targeted LDP session), the PW ID, and
the encapsulation type 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender’s PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.10. FEC 129 Pseudowire
FEC 129 (0x81) and the terms PW Type, Attachment Group Identifier
(AGI), Attachment Group Identifier Type (AGI Type), Attachment
Individual Identifier Type (AII Type), Source Attachment Individual
Identifier (SAII), and Target Attachment Individual Identifier (TAII)
are defined in [PW-CONTROL]. The PW Type is a 15-bit number
indicating the encapsulation type. It is carried right justified in
the field below PW Type with the high-order bit set to zero. All the
other fields are treated as opaque values and copied directly from
the FEC 129 format. All of these values together uniquely define the
FEC within the scope of the LDP session identified by the source and
remote PE addresses.
When an FEC 129 is encoded in a label stack, the following format is
used. The Length of this TLV is 16 + AGI length + SAII length + TAII
length. Padding is used to make the total length a multiple of 4;
the length of the padding is not included in the Length 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender’s PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.11. BGP Labeled IPv4 Prefix
BGP labeled IPv4 prefixes are defined in [BGP-LABEL]. When a BGP
labeled IPv4 prefix is encoded in a label stack, the following format
is used. The value field consists the IPv4 prefix (with trailing 0
bits to make 32 bits in all), and the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.12. BGP Labeled IPv6 Prefix
BGP labeled IPv6 prefixes are defined in [BGP-LABEL]. When a BGP
labeled 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.
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.13. Generic IPv4 Prefix
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. This FEC is used if the
protocol advertising the label is unknown or may change during the
course of the LSP. An example is an inter-AS LSP that may be
signaled by LDP in one Autonomous System (AS), by RSVP-TE [RSVP-TE]
in another AS, and by BGP between the ASes, such as is common for
inter-AS VPNs.
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.14. Generic IPv6 Prefix
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.
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.15. Nil FEC
At times, labels from the reserved range, e.g., Router Alert and
Explicit-null, may be added to the label stack for various diagnostic
purposes such as influencing load-balancing. These labels may have
no explicit FEC associated with them. The Nil FEC Stack is defined
to allow a Target FEC Stack sub-TLV to be added to the Target FEC
Stack to account for such labels so that proper validation can still
be performed.
The Length is 4. Labels are 20-bit values treated as numbers.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label is the actual label value inserted in the label stack; the MBZ
fields MUST be zero when sent and ignored on receipt.
3.3. Downstream Mapping
The Downstream Mapping object is a TLV that MAY be included in an
echo request message. Only one Downstream Mapping object may appear
in an echo request. The 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 the replying router SHOULD include a Downstream Mapping
object for each interface over which this FEC could be forwarded.
For a more precise definition of the notion of "downstream", see
section 3.3.2, "Downstream Router and Interface".
The Length is K + M + 4*N octets, where M is the Multipath Length,
and N is the number of Downstream Labels. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Type| Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. (Multipath Information) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Maximum Transmission Unit (MTU)
The MTU is the size in octets of the largest MPLS frame (including
label stack) that fits on the interface to the Downstream LSR.
Address Type
The Address Type indicates if the interface is numbered or
unnumbered. It also determines the length of the Downstream IP
Address and Downstream 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 16
2 IPv4 Unnumbered 16
3 IPv6 Numbered 40
4 IPv6 Unnumbered 28
DS Flags
The DS Flags field is a bit vector with the following format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Rsvd(MBZ) |I|N|
+-+-+-+-+-+-+-+-+
Two flags are defined currently, I and N. The remaining flags
MUST be set to zero when sending and ignored on receipt.
Flag Name and Meaning
---- ----------------
I Interface and Label Stack Object Request
When this flag is set, it indicates that the replying
router SHOULD include an Interface and Label Stack
Object in the echo reply message.
N Treat as a Non-IP Packet
Echo request messages will be used to diagnose non-IP
flows. However, these messages are carried in IP
packets. For a router that alters its ECMP algorithm
based on the FEC or deep packet examination, this flag
requests that the router treat this as it would if the
determination of an IP payload had failed.
Downstream IP Address and Downstream Interface Address
IPv4 addresses and interface indices are encoded in 4 octets; IPv6
addresses are encoded in 16 octets.
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 IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP
Address MUST be the downstream LSR’s Router ID, and the Downstream
Interface Address MUST be set to the index assigned by the
upstream LSR to the interface.
If an LSR does not know the IP address of its neighbor, then it
MUST set the Address Type to either IPv4 Unnumbered or IPv6
Unnumbered. For IPv4, it must set the Downstream IP Address to
127.0.0.1; for IPv6 the address is set to 0::1. In both cases,
the interface index MUST be set to 0. If an LSR receives an Echo
Request packet with either of these addresses in the Downstream IP
Address field, this indicates that it MUST bypass interface
verification but continue with label validation.
If the originator of an Echo Request packet wishes to obtain
Downstream Mapping information but does not know the expected
label stack, then it SHOULD set the Address Type to either IPv4
Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set the
Downstream IP Address to 224.0.0.2; for IPv6 the address MUST be
set to FF02::2. In both cases, the interface index MUST be set to
0. If an LSR receives an Echo Request packet with the all-routers
multicast address, then this indicates that it MUST bypass both
interface and label stack validation, but return Downstream
Mapping TLVs using the information provided.
Multipath Type
The following Multipath Types are defined:
Key Type Multipath Information
--- ---------------- ---------------------
0 no multipath Empty (Multipath Length = 0)
2 IP address IP addresses
4 IP address range low/high address pairs
8 Bit-masked IP 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 2, 4, 8, and 9 specify that the supplied Multipath
Information will serve to exercise this path.
Depth Limit
The Depth Limit is applicable only to a label stack and is the