RFC 8029
Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures
Pages: 78
Proposed Standard
→ Errata
Obsoletes: 4379 6424 6829 7537
Updates: 1122
Updated by: 8611 9041
Proposed Standard
→ Errata
Obsoletes: 4379 6424 6829 7537
Updates: 1122
Updated by: 8611 9041
Part 4 of 4 – Pages 61 to 78
6. IANA Considerations
6.1. TCP and UDP Port Number
The TCP and UDP port number 3503 has been allocated by IANA for LSP echo requests and replies.6.2. MPLS LSP Ping Parameters
IANA maintains the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry at [IANA-MPLS-LSP-PING]. The following subsections detail the name spaces managed by IANA. For some of these name spaces, the space is divided into assignment ranges; the following terms are used in describing the procedures by which IANA allocates values: "Standards Action" (as defined in [RFC5226]), "Specification Required", and "Vendor Private Use". Values from "Specification Required" ranges MUST be registered with IANA. The request MUST be made via an RFC that describes the format and procedures for using the code point; the actual assignment is made during the IANA actions for the RFC. Values from "Vendor Private" ranges MUST NOT be registered with IANA; however, the message MUST contain an enterprise code as registered with the IANA SMI Private Network Management Private Enterprise Numbers. For each name space that has a Vendor Private range, it must be specified where exactly the SMI Private Enterprise Number resides; see below for examples. In this way, several enterprises (vendors) can use the same code point without fear of collision.6.2.1. Message Types, Reply Modes, Return Codes
IANA has created and will maintain registries for Message Types, Reply Modes, and Return Codes. Each of these can take values in the range 0-255. Assignments in the range 0-191 are via Standards Action; assignments in the range 192-251 are made via "Specification Required"; values in the range 252-255 are for Vendor Private Use and MUST NOT be allocated. If any of these fields fall in the Vendor Private range, a top-level Vendor Enterprise Number TLV MUST be present in the message.
Message Types defined in this document are the following:
Value Meaning
----- -------
1 MPLS Echo Request
2 MPLS Echo Reply
Reply Modes defined in this document are the following:
Value Meaning
----- -------
1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application-level control channel
Return Codes defined in this document are listed in Section 3.1.
IANA has updated the reference for each these values to this
document.
6.2.2. TLVs
IANA has created and maintains a registry for the Type field of top-
level TLVs as well as for any associated sub-TLVs. Note that the
meaning of a sub-TLV is scoped by the TLV. The number spaces for the
sub-TLVs of various TLVs are independent.
The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the
ranges 0-16383 and 32768-49161 are made via Standards Action as
defined in [RFC5226]; assignments in the ranges 16384-31743 and
49162-64511 are made via "Specification Required"; values in the
ranges 31744-32767 and 64512-65535 are for Vendor Private Use and
MUST NOT be allocated.
If a TLV or sub-TLV has a Type that falls in the range for Vendor
Private Use, the Length MUST be at least 4, and the first four octets
MUST be that vendor's SMI Private Enterprise Number, in network octet
order. The rest of the Value field is private to the vendor.
TLVs and sub-TLVs defined in this document are the following:
Type Sub-Type Value Field
---- -------- -----------
1 Target FEC Stack
1 LDP IPv4 prefix
2 LDP IPv6 prefix
3 RSVP IPv4 LSP
4 RSVP IPv6 LSP
5 Unassigned
6 VPN IPv4 prefix
7 VPN IPv6 prefix
8 L2 VPN endpoint
9 "FEC 128" Pseudowire - IPv4 (Deprecated)
10 "FEC 128" Pseudowire - IPv4
11 "FEC 129" Pseudowire - IPv4
12 BGP labeled IPv4 prefix
13 BGP labeled IPv6 prefix
14 Generic IPv4 prefix
15 Generic IPv6 prefix
16 Nil FEC
24 "FEC 128" Pseudowire - IPv6
25 "FEC 129" Pseudowire - IPv6
2 Downstream Mapping (Deprecated)
3 Pad
4 Unassigned
5 Vendor Enterprise Number
6 Unassigned
7 Interface and Label Stack
8 Unassigned
9 Errored TLVs
Any value The TLV not understood
10 Reply TOS Byte
20 Downstream Detailed Mapping
IANA has updated the reference for each of these values to this
document.
6.2.3. Global Flags
IANA has created a "Global Flags" subregistry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. This registry tracks the assignment of 16 flags in the Global Flags field of the MPLS LSP ping echo request message. The flags are numbered from 0 (most significant bit, transmitted first) to 15. New entries are assigned by Standards Action. Initial entries in the registry are as follows: Bit number | Name | Reference ------------+----------------------------+-------------- 15 | V Flag | [RFC8029] 14 | T Flag | [RFC6425] 13 | R Flag | [RFC6426] 12-0 | Unassigned | [RFC8029]6.2.4. Downstream Detailed Mapping Address Type
This document extends RFC 4379 by defining a new address type for use with the Downstream Mapping and Downstream Detailed Mapping TLVs. IANA has established a registry to assign address types for use with the Downstream Mapping and Downstream Detailed Mapping TLVs, which initially allocates the following assignments: Type # Address Type K Octets Reference ------ ------------ -------- --------- 1 IPv4 Numbered 16 [RFC8029] 2 IPv4 Unnumbered 16 [RFC8029] 3 IPv6 Numbered 40 [RFC8029] 4 IPv6 Unnumbered 28 [RFC8029] 5 Non IP 12 [RFC6426] Downstream Detailed Mapping Address Type Registry Because the field in this case is an 8-bit field, the allocation policy for this registry is "Standards Action".
6.2.5. DS Flags
This document defines the Downstream Mapping (DSMAP) TLV and the Downstream Detailed Mapping (DDMAP) TLV, which have Type 2 and Type 20, respectively, assigned from the "TLVs" subregistry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. DSMAP has been deprecated by DDMAP, but both TLVs share a field: DS Flags. IANA has created and now maintains a registry entitled "DS Flags". The registration policy for this registry is Standards Action [RFC5226]. IANA has made the following assignments: Bit Number Name Reference ---------- ------------------------------------------- --------- 7 N: Treat as a Non-IP Packet [RFC8029] 6 I: Interface and Label Stack Object Request [RFC8029] 5 E: ELI/EL push indicator [RFC8012] 4 L: Label-based load balance indicator [RFC8012] 3-0 Unassigned
6.2.6. Multipath Types
IANA has created and now maintains a registry entitled "Multipath Types". The registration policy [RFC5226] for this registry is Standards Action. IANA has made the following assignments: Value Meaning Reference ---------- ---------------------------------------- --------- 0 no multipath [RFC8029] 1 Unassigned 2 IP address [RFC8029] 3 Unassigned 4 IP address range [RFC8029] 5-7 Unassigned 8 Bit-masked IP address set [RFC8029] 9 Bit-masked label set [RFC8029] 10 IP and label set [RFC8012] 11-250 Unassigned 251-254 Reserved for Experimental Use [RFC8029] 255 Reserved [RFC8029]6.2.7. Pad Type
IANA has created and now maintains a registry entitled "Pad Types". The registration policy [RFC5226] for this registry is Standards Action. IANA has made the following initial assignments: Registry Name: Pad Types Value Meaning Reference ---------- ---------------------------------------- --------- 0 Reserved [RFC8029] 1 Drop Pad TLV from reply [RFC8029] 2 Copy Pad TLV to reply [RFC8029] 3-250 Unassigned 251-254 Experimental Use [RFC8029] 255 Reserved [RFC8029]
6.2.8. Interface and Label Stack Address Type
IANA has created and now maintains a registry entitled "Interface and Label Stack Address Types". The registration policy [RFC5226] for this registry is Standards Action. IANA has made the following initial assignments: Registry Name: Interface and Label Stack Address Types Value Meaning Reference ---------- ---------------------------------------- --------- 0 Reserved [RFC8029] 1 IPv4 Numbered [RFC8029] 2 IPv4 Unnumbered [RFC8029] 3 IPv6 Numbered [RFC8029] 4 IPv6 Unnumbered [RFC8029] 5-250 Unassigned 251-254 Experimental Use [RFC8029] 255 Reserved [RFC8029]6.3. IPv4 Special-Purpose Address Registry
IANA has updated the reference in Note 1 of the "IANA IPv4 Special- Purpose Address Registry" [IANA-SPECIAL-IPv4] to point to this document.7. References
7.1. Normative References
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>. [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <http://www.rfc-editor.org/info/rfc1812>. [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, DOI 10.17487/RFC2113, February 1997, <http://www.rfc-editor.org/info/rfc2113>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <http://www.rfc-editor.org/info/rfc3032>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>. [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, <http://www.rfc-editor.org/info/rfc6424>. [RFC7506] Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM)", RFC 7506, DOI 10.17487/RFC7506, April 2015, <http://www.rfc-editor.org/info/rfc7506>.7.2. Informative References
[Err108] RFC Errata, Erratum ID 108, RFC 4379. [Err742] RFC Errata, Erratum ID 742, RFC 4379. [Err1418] RFC Errata, Erratum ID 1418, RFC 4379.
[Err1714] RFC Errata, Erratum ID 1714, RFC 4379. [Err1786] RFC Errata, Erratum ID 1786, RFC 4379. [Err2978] RFC Errata, Erratum ID 2978, RFC 4379. [Err3399] RFC Errata, Erratum ID 3399, RFC 4379. [IANA-ENT] IANA, "PRIVATE ENTERPRISE NUMBERS", <http://www.iana.org/assignments/enterprise-numbers>. [IANA-MPLS-LSP-PING] IANA, "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", <http://www.iana.org/assignments/ mpls-lsp-ping-parameters>. [IANA-SPECIAL-IPv4] IANA, "IANA IPv4 Special-Purpose Address Registry", <http://www.iana.org/assignments/ iana-ipv4-special-registry>. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>. [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, <http://www.rfc-editor.org/info/rfc3107>. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>. [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, <http://www.rfc-editor.org/info/rfc3443>. [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, <http://www.rfc-editor.org/info/rfc4026>.
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, DOI 10.17487/RFC4365, February 2006, <http://www.rfc-editor.org/info/rfc4365>. [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, <http://www.rfc-editor.org/info/rfc4461>. [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <http://www.rfc-editor.org/info/rfc4761>. [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>. [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>. [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <http://www.rfc-editor.org/info/rfc5331>. [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <http://www.rfc-editor.org/info/rfc5462>. [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, DOI 10.17487/RFC5885, June 2010, <http://www.rfc-editor.org/info/rfc5885>. [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, <http://www.rfc-editor.org/info/rfc6425>.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, DOI 10.17487/RFC6426, November 2011, <http://www.rfc-editor.org/info/rfc6426>. [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6", RFC 6829, DOI 10.17487/RFC6829, January 2013, <http://www.rfc-editor.org/info/rfc6829>. [RFC7537] Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and S. Aldrin, "IANA Registries for LSP Ping Code Points", RFC 7537, DOI 10.17487/RFC7537, May 2015, <http://www.rfc-editor.org/info/rfc7537>. [RFC8012] Akiya, N., Swallow, G., Pignataro, C., Malis, A., and S. Aldrin, "Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs)", RFC 8012, DOI 10.17487/RFC8012, November 2016, <http://www.rfc-editor.org/info/rfc8012>. [RFC8077] Martini, L., Ed., and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <http://www.rfc-editor.org/info/rfc8077>.
Appendix A. Deprecated TLVs and Sub-TLVs (Non-normative)
This appendix describes deprecated elements, which are non-normative for an implementation. They are included in this document for historical and informational purposes.A.1. Target FEC Stack
A.1.1. FEC 128 Pseudowire - IPv4 (Deprecated)
FEC 128 (0x80) is defined in [RFC4447], 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 a FEC 128 is encoded in a label stack, the following format is used. The Value field consists of the Remote PE IPv4 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 IPv4 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 Section 3.2.9), 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.A.2. Downstream Mapping (Deprecated)
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.4.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
5 Non IP 12
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
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 Section 3.4.1.1.1 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 TC bits are bits 20-22, and bit 23 is the S
bit. The replying router SHOULD fill in the TC 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
Acknowledgements
The original acknowledgements from RFC 4379 state the following:
This document is the outcome of many discussions among many
people, including Manoj Leelanivas, Paul Traina, Yakov Rekhter,
Der-Hwa Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani
Aggarwal, and Vanson Lim.
The description of the Multipath Information sub-field of the
Downstream Mapping TLV was adapted from text suggested by Curtis
Villamizar.
We would like to thank Loa Andersson for motivating the advancement
of this specification.
We also would like to thank Alexander Vainshtein, Yimin Shen, Curtis
Villamizar, David Allan, Vincent Roca, Mirja Kuhlewind, and Elwyn
Davies for their review and useful comments.
Contributors
A mechanism used to detect data-plane failures in MPLS LSPs was
originally published as RFC 4379 in February 2006. It was produced
by the MPLS Working Group of the IETF and was jointly authored by
Kireeti Kompella and George Swallow.
The following made vital contributions to all aspects of the original
RFC 4379, and much of the material came out of debate and discussion
among this group.
Ronald P. Bonica, Juniper Networks, Inc.
Dave Cooper, Global Crossing
Ping Pan, Hammerhead Systems
Nischal Sheth, Juniper Networks, Inc.
Sanjay Wadhwa, Juniper Networks, Inc.
Authors' Addresses
Kireeti Kompella Juniper Networks, Inc. Email: kireeti.kompella@gmail.com George Swallow Cisco Systems, Inc. Email: swallow.ietf@gmail.com Carlos Pignataro (editor) Cisco Systems, Inc. Email: cpignata@cisco.com Nagendra Kumar Cisco Systems, Inc. Email: naikumar@cisco.com Sam Aldrin Google Email: aldrin.ietf@gmail.com Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com