idnits 2.17.1 draft-smack-mpls-rfc4379bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 8 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 26, 2015) is 3129 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FEC-stack-depth' is mentioned on line 1744, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4026 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Pignataro 3 Internet-Draft N. Kumar 4 Obsoletes: 4379 (if approved) Cisco 5 Intended status: Standards Track S. Aldrin 6 Expires: March 29, 2016 Google 7 M. Chen 8 Huawei 9 September 26, 2015 11 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures 12 draft-smack-mpls-rfc4379bis-02 14 Abstract 16 This document describes a simple and efficient mechanism that can be 17 used to detect data plane failures in Multi-Protocol Label Switching 18 (MPLS) Label Switched Paths (LSPs). There are two parts to this 19 document: information carried in an MPLS "echo request" and "echo 20 reply" for the purposes of fault detection and isolation, and 21 mechanisms for reliably sending the echo reply. 23 This document obsoletes RFC 4379. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 29, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Structure of This Document . . . . . . . . . . . . . . . 4 62 1.3. Contributors . . . . . . . . . . . . . . . . . . . . . . 4 63 1.4. Scope of RFC4379bis work . . . . . . . . . . . . . . . . 4 64 1.5. ToDo . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Use of Address Range 127/8 . . . . . . . . . . . . . . . 6 67 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 12 69 3.2. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 12 70 3.2.1. LDP IPv4 Prefix . . . . . . . . . . . . . . . . . . 14 71 3.2.2. LDP IPv6 Prefix . . . . . . . . . . . . . . . . . . 14 72 3.2.3. RSVP IPv4 LSP . . . . . . . . . . . . . . . . . . . 14 73 3.2.4. RSVP IPv6 LSP . . . . . . . . . . . . . . . . . . . 15 74 3.2.5. VPN IPv4 Prefix . . . . . . . . . . . . . . . . . . 15 75 3.2.6. VPN IPv6 Prefix . . . . . . . . . . . . . . . . . . 16 76 3.2.7. L2 VPN Endpoint . . . . . . . . . . . . . . . . . . 17 77 3.2.8. FEC 128 Pseudowire (Deprecated) . . . . . . . . . . 17 78 3.2.9. FEC 128 Pseudowire (Current) . . . . . . . . . . . . 18 79 3.2.10. FEC 129 Pseudowire . . . . . . . . . . . . . . . . . 19 80 3.2.11. BGP Labeled IPv4 Prefix . . . . . . . . . . . . . . 20 81 3.2.12. BGP Labeled IPv6 Prefix . . . . . . . . . . . . . . 20 82 3.2.13. Generic IPv4 Prefix . . . . . . . . . . . . . . . . 21 83 3.2.14. Generic IPv6 Prefix . . . . . . . . . . . . . . . . 21 84 3.2.15. Nil FEC . . . . . . . . . . . . . . . . . . . . . . 22 85 3.3. Downstream Mapping . . . . . . . . . . . . . . . . . . . 22 86 3.3.1. Multipath Information Encoding . . . . . . . . . . . 26 87 3.3.2. Downstream Router and Interface . . . . . . . . . . 28 88 3.4. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . 29 89 3.5. Vendor Enterprise Number . . . . . . . . . . . . . . . . 29 90 3.6. Interface and Label Stack . . . . . . . . . . . . . . . 29 91 3.7. Errored TLVs . . . . . . . . . . . . . . . . . . . . . . 31 92 3.8. Reply TOS Byte TLV . . . . . . . . . . . . . . . . . . . 31 93 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . 31 94 4.1. Dealing with Equal-Cost Multi-Path (ECMP) . . . . . . . 32 95 4.2. Testing LSPs That Are Used to Carry MPLS Payloads . . . 33 96 4.3. Sending an MPLS Echo Request . . . . . . . . . . . . . . 33 97 4.4. Receiving an MPLS Echo Request . . . . . . . . . . . . . 34 98 4.4.1. FEC Validation . . . . . . . . . . . . . . . . . . . 40 99 4.5. Sending an MPLS Echo Reply . . . . . . . . . . . . . . . 41 100 4.6. Receiving an MPLS Echo Reply . . . . . . . . . . . . . . 42 101 4.7. Issue with VPN IPv4 and IPv6 Prefixes . . . . . . . . . 42 102 4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . 42 103 5. Security Considerations . . . . . . . . . . . . . . . . . . 43 104 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 105 6.1. Message Types, Reply Modes, Return Codes . . . . . . . . 44 106 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 45 107 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 109 8.1. Normative References . . . . . . . . . . . . . . . . . . 47 110 8.2. Informative References . . . . . . . . . . . . . . . . . 48 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 113 1. Introduction 115 This document describes a simple and efficient mechanism that can be 116 used to detect data plane failures in MPLS Label Switched Paths 117 (LSPs). There are two parts to this document: information carried in 118 an MPLS "echo request" and "echo reply", and mechanisms for 119 transporting the echo reply. The first part aims at providing enough 120 information to check correct operation of the data plane, as well as 121 a mechanism to verify the data plane against the control plane, and 122 thereby localize faults. The second part suggests two methods of 123 reliable reply channels for the echo request message for more robust 124 fault isolation. 126 An important consideration in this design is that MPLS echo requests 127 follow the same data path that normal MPLS packets would traverse. 128 MPLS echo requests are meant primarily to validate the data plane, 129 and secondarily to verify the data plane against the control plane. 130 Mechanisms to check the control plane are valuable, but are not 131 covered in this document. 133 This document makes special use of the address range 127/8. This is 134 an exception to the behavior defined in RFC 1122 [RFC1122] and 135 updates that RFC. The motivation for this change and the details of 136 this exceptional use are discussed in section 2.1 below. 138 1.1. Conventions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 The term "Must Be Zero" (MBZ) is used in object descriptions for 145 reserved fields. These fields MUST be set to zero when sent and 146 ignored on receipt. 148 Terminology pertaining to L2 and L3 Virtual Private Networks (VPNs) 149 is defined in [RFC4026]. 151 Since this document refers to the MPLS Time to Live (TTL) far more 152 frequently than the IP TTL, the authors have chosen the convention of 153 using the unqualified "TTL" to mean "MPLS TTL" and using "IP TTL" for 154 the TTL value in the IP header. 156 1.2. Structure of This Document 158 The body of this memo contains four main parts: motivation, MPLS echo 159 request/reply packet format, LSP ping operation, and a reliable 160 return path. It is suggested that first-time readers skip the actual 161 packet formats and read the Theory of Operation first; the document 162 is structured the way it is to avoid forward references. 164 1.3. Contributors 166 A mechanism used to detect data plane failures in Multi-Protocol 167 Label Switching (MPLS) Label Switched Paths (LSPs) was originally 168 published as RFC 4379 in February 2006. It was produced by the MPLS 169 Working Group of the IETF and was jointly authored by Kireeti 170 Kompella and George Swallow. 172 The following made vital contributions to all aspects of the original 173 RFC 4379, and much of the material came out of debate and discussion 174 among this group. 176 Ronald P. Bonica, Juniper Networks, Inc. 177 Dave Cooper, Global Crossing 178 Ping Pan, Hammerhead Systems 179 Nischal Sheth, Juniper Networks, Inc. 180 Sanjay Wadhwa, Juniper Networks, Inc. 182 1.4. Scope of RFC4379bis work 184 The goal of this document is to take LSP Ping to an Internet 185 Standard. 187 [RFC4379] defines the basic mechanism for MPLS LSP validation that 188 can be used for fault detection and isolation. The scope of this 189 document also is to address various updates to MPLS LSP Ping, 190 including: 192 1. Updates to all references and citations. Obsoleted RFCs 2434, 193 2030, and 3036 are respectively replaced with RFCs 5226, 5905, 194 and 5036. Additionally, these three documents published as RFCs: 195 RFCs 4447, 5085, and 4761. 196 2. Incorporate all outstanding Errata. These include Errata with 197 IDs: 108, 1418, 1714, 1786, 3399, 742, and 2978. 199 1.5. ToDo 201 Please remove this ToDo prior to publication: 203 1. Review IANA Allocations 204 2. Fix pending figure mis-alignments 206 2. Motivation 208 When an LSP fails to deliver user traffic, the failure cannot always 209 be detected by the MPLS control plane. There is a need to provide a 210 tool that would enable users to detect such traffic "black holes" or 211 misrouting within a reasonable period of time, and a mechanism to 212 isolate faults. 214 In this document, we describe a mechanism that accomplishes these 215 goals. This mechanism is modeled after the ping/traceroute paradigm: 216 ping (ICMP echo request [RFC0792]) is used for connectivity checks, 217 and traceroute is used for hop-by-hop fault localization as well as 218 path tracing. This document specifies a "ping" mode and a 219 "traceroute" mode for testing MPLS LSPs. 221 The basic idea is to verify that packets that belong to a particular 222 Forwarding Equivalence Class (FEC) actually end their MPLS path on a 223 Label Switching Router (LSR) that is an egress for that FEC. This 224 document proposes that this test be carried out by sending a packet 225 (called an "MPLS echo request") along the same data path as other 226 packets belonging to this FEC. An MPLS echo request also carries 227 information about the FEC whose MPLS path is being verified. This 228 echo request is forwarded just like any other packet belonging to 229 that FEC. In "ping" mode (basic connectivity check), the packet 230 should reach the end of the path, at which point it is sent to the 231 control plane of the egress LSR, which then verifies whether it is 232 indeed an egress for the FEC. In "traceroute" mode (fault 233 isolation), the packet is sent to the control plane of each transit 234 LSR, which performs various checks that it is indeed a transit LSR 235 for this path; this LSR also returns further information that helps 236 check the control plane against the data plane, i.e., that forwarding 237 matches what the routing protocols determined as the path. 239 One way these tools can be used is to periodically ping an FEC to 240 ensure connectivity. If the ping fails, one can then initiate a 241 traceroute to determine where the fault lies. One can also 242 periodically traceroute FECs to verify that forwarding matches the 243 control plane; however, this places a greater burden on transit LSRs 244 and thus should be used with caution. 246 2.1. Use of Address Range 127/8 248 As described above, LSP ping is intended as a diagnostic tool. It is 249 intended to enable providers of an MPLS-based service to isolate 250 network faults. In particular, LSP ping needs to diagnose situations 251 where the control and data planes are out of sync. It performs this 252 by routing an MPLS echo request packet based solely on its label 253 stack. That is, the IP destination address is never used in a 254 forwarding decision. In fact, the sender of an MPLS echo request 255 packet may not know, a priori, the address of the router at the end 256 of the LSP. 258 Providers of MPLS-based services also need the ability to trace all 259 of the possible paths that an LSP may take. Since most MPLS services 260 are based on IP unicast forwarding, these paths are subject to 261 equal-cost multi-path (ECMP) load sharing. 263 This leads to the following requirements: 265 1. Although the LSP in question may be broken in unknown ways, the 266 likelihood of a diagnostic packet being delivered to a user of an 267 MPLS service MUST be held to an absolute minimum. 269 2. If an LSP is broken in such a way that it prematurely terminates, 270 the diagnostic packet MUST NOT be IP forwarded. 272 3. A means of varying the diagnostic packets such that they exercise 273 all ECMP paths is thus REQUIRED. 275 Clearly, using general unicast addresses satisfies neither of the 276 first two requirements. A number of other options for addresses were 277 considered, including a portion of the private address space (as 278 determined by the network operator) and the newly designated IPv4 279 link local addresses. Use of the private address space was deemed 280 ineffective since the leading MPLS-based service is an IPv4 Virtual 281 Private Network (VPN). VPNs often use private addresses. 283 The IPv4 link local addresses are more attractive in that the scope 284 over which they can be forwarded is limited. However, if one were to 285 use an address from this range, it would still be possible for the 286 first recipient of a diagnostic packet that "escaped" from a broken 287 LSP to have that address assigned to the interface on which it 288 arrived and thus could mistakenly receive such a packet. 289 Furthermore, the IPv4 link local address range has only recently been 290 allocated. Many deployed routers would forward a packet with an 291 address from that range toward the default route. 293 The 127/8 range for IPv4 and that same range embedded in as 294 IPv4-mapped IPv6 addresses for IPv6 was chosen for a number of 295 reasons. 297 RFC 1122 allocates the 127/8 as "Internal host loopback address" and 298 states: "Addresses of this form MUST NOT appear outside a host." 299 Thus, the default behavior of hosts is to discard such packets. This 300 helps to ensure that if a diagnostic packet is misdirected to a host, 301 it will be silently discarded. 303 RFC 1812 [RFC1812] states: 305 A router SHOULD NOT forward, except over a loopback interface, any 306 packet that has a destination address on network 127. A router 307 MAY have a switch that allows the network manager to disable these 308 checks. If such a switch is provided, it MUST default to 309 performing the checks. 311 This helps to ensure that diagnostic packets are never IP forwarded. 313 The 127/8 address range provides 16M addresses allowing wide 314 flexibility in varying addresses to exercise ECMP paths. Finally, as 315 an implementation optimization, the 127/8 provides an easy means of 316 identifying possible LSP packets. 318 3. Packet Format 320 An MPLS echo request is a (possibly labeled) IPv4 or IPv6 UDP packet; 321 the contents of the UDP packet have the following format: 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Version Number | Global Flags | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Message Type | Reply mode | Return Code | Return Subcode| 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Sender's Handle | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Sequence Number | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | TimeStamp Sent (seconds) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | TimeStamp Sent (seconds fraction) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | TimeStamp Received (seconds) | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | TimeStamp Received (seconds fraction) | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | TLVs ... | 343 . . 344 . . 345 . . 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 The Version Number is currently 1. (Note: the version number is to 350 be incremented whenever a change is made that affects the ability of 351 an implementation to correctly parse or process an MPLS echo 352 request/reply. These changes include any syntactic or semantic 353 changes made to any of the fixed fields, or to any Type-Length-Value 354 (TLV) or sub-TLV assignment or format that is defined at a certain 355 version number. The version number may not need to be changed if an 356 optional TLV or sub-TLV is added.) 358 The Global Flags field is a bit vector with the following format: 360 0 1 361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | MBZ |V| 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 One flag is defined for now, the V bit; the rest MUST be set to zero 367 when sending and ignored on receipt. 369 The V (Validate FEC Stack) flag is set to 1 if the sender wants the 370 receiver to perform FEC Stack validation; if V is 0, the choice is 371 left to the receiver. 373 The Message Type is one of the following: 375 Value Meaning 376 ----- ------- 377 1 MPLS echo request 378 2 MPLS echo reply 380 The Reply Mode can take one of the following values: 382 Value Meaning 383 ----- ------- 384 1 Do not reply 385 2 Reply via an IPv4/IPv6 UDP packet 386 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 387 4 Reply via application level control channel 389 An MPLS echo request with 1 (Do not reply) in the Reply Mode field 390 may be used for one-way connectivity tests; the receiving router may 391 log gaps in the Sequence Numbers and/or maintain delay/jitter 392 statistics. An MPLS echo request would normally have 2 (Reply via an 393 IPv4/IPv6 UDP packet) in the Reply Mode field. If the normal IP 394 return path is deemed unreliable, one may use 3 (Reply via an IPv4/ 395 IPv6 UDP packet with Router Alert). Note that this requires that all 396 intermediate routers understand and know how to forward MPLS echo 397 replies. The echo reply uses the same IP version number as the 398 received echo request, i.e., an IPv4 encapsulated echo reply is sent 399 in response to an IPv4 encapsulated echo request. 401 Some applications support an IP control channel. One such example is 402 the associated control channel defined in Virtual Circuit 403 Connectivity Verification (VCCV) [RFC5085]. Any application that 404 supports an IP control channel between its control entities may set 405 the Reply Mode to 4 (Reply via application level control channel) to 406 ensure that replies use that same channel. Further definition of 407 this codepoint is application specific and thus beyond the scope of 408 this document. 410 Return Codes and Subcodes are described in the next section. 412 The Sender's Handle is filled in by the sender, and returned 413 unchanged by the receiver in the echo reply (if any). There are no 414 semantics associated with this handle, although a sender may find 415 this useful for matching up requests with replies. 417 The Sequence Number is assigned by the sender of the MPLS echo 418 request and can be (for example) used to detect missed replies. 420 The TimeStamp Sent is the time-of-day (according to the sender's 421 clock) in NTP format [RFC5905] when the MPLS echo request is sent. 422 The TimeStamp Received in an echo reply is the time-of-day (according 423 to the receiver's clock) in NTP format that the corresponding echo 424 request was received. 426 TLVs (Type-Length-Value tuples) have the following format: 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Type | Length | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Value | 434 . . 435 . . 436 . . 437 | | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Types are defined below; Length is the length of the Value field in 441 octets. The Value field depends on the Type; it is zero padded to 442 align to a 4-octet boundary. TLVs may be nested within other TLVs, 443 in which case the nested TLVs are called sub-TLVs. Sub-TLVs have 444 independent types and MUST also be 4-octet aligned. 446 Two examples follow. The Label Distribution Protocol (LDP) IPv4 FEC 447 sub-TLV has the following format: 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type = 1 (LDP IPv4 FEC) | Length = 5 | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | IPv4 prefix | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Prefix Length | Must Be Zero | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 The Length for this TLV is 5. A Target FEC Stack TLV that contains 460 an LDP IPv4 FEC sub-TLV and a VPN IPv4 prefix sub-TLV has the 461 following format: 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Type = 1 (FEC TLV) | Length = 32 | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | sub-Type = 1 (LDP IPv4 FEC) | Length = 5 | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | IPv4 prefix | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Prefix Length | Must Be Zero | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | sub-Type = 6 (VPN IPv4 prefix)| Length = 13 | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Route Distinguisher | 477 | (8 octets) | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | IPv4 prefix | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Prefix Length | Must Be Zero | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 A description of the Types and Values of the top-level TLVs for LSP 485 ping are given below: 487 Type # Value Field 488 ------ ----------- 489 1 Target FEC Stack 490 2 Downstream Mapping 491 3 Pad 492 4 Not Assigned 493 5 Vendor Enterprise Number 494 6 Not Assigned 495 7 Interface and Label Stack 496 8 Not Assigned 497 9 Errored TLVs 498 10 Reply TOS Byte 500 Types less than 32768 (i.e., with the high-order bit equal to 0) are 501 mandatory TLVs that MUST either be supported by an implementation or 502 result in the return code of 2 ("One or more of the TLVs was not 503 understood") being sent in the echo response. 505 Types greater than or equal to 32768 (i.e., with the high-order bit 506 equal to 1) are optional TLVs that SHOULD be ignored if the 507 implementation does not understand or support them. 509 3.1. Return Codes 511 The Return Code is set to zero by the sender. The receiver can set 512 it to one of the values listed below. The notation refers to 513 the Return Subcode. This field is filled in with the stack-depth for 514 those codes that specify that. For all other codes, the Return 515 Subcode MUST be set to zero. 517 Value Meaning 518 ----- ------- 519 0 No return code 520 1 Malformed echo request received 521 2 One or more of the TLVs was not understood 522 3 Replying router is an egress for the FEC at stack- 523 depth 524 4 Replying router has no mapping for the FEC at stack- 525 depth 526 5 Downstream Mapping Mismatch (See Note 1) 527 6 Upstream Interface Index Unknown (See Note 1) 528 7 Reserved 529 8 Label switched at stack-depth 530 9 Label switched but no MPLS forwarding at stack-depth 531 532 10 Mapping for this FEC is not the given label at stack- 533 depth 534 11 No label entry at stack-depth 535 12 Protocol not associated with interface at FEC stack- 536 depth 537 13 Premature termination of ping due to label stack 538 shrinking to a single label 540 Note 1 542 The Return Subcode contains the point in the label stack where 543 processing was terminated. If the RSC is 0, no labels were 544 processed. Otherwise the packet would have been label switched at 545 depth RSC. 547 3.2. Target FEC Stack 549 A Target FEC Stack is a list of sub-TLVs. The number of elements is 550 determined by looking at the sub-TLV length fields. 552 Sub-Type Length Value Field 553 -------- ------ ----------- 554 1 5 LDP IPv4 prefix 555 2 17 LDP IPv6 prefix 556 3 20 RSVP IPv4 LSP 557 4 56 RSVP IPv6 LSP 558 5 Not Assigned 559 6 13 VPN IPv4 prefix 560 7 25 VPN IPv6 prefix 561 8 14 L2 VPN endpoint 562 9 10 "FEC 128" Pseudowire (deprecated) 563 10 14 "FEC 128" Pseudowire 564 11 16+ "FEC 129" Pseudowire 565 12 5 BGP labeled IPv4 prefix 566 13 17 BGP labeled IPv6 prefix 567 14 5 Generic IPv4 prefix 568 15 17 Generic IPv6 prefix 569 16 4 Nil FEC 571 Other FEC Types will be defined as needed. 573 Note that this TLV defines a stack of FECs, the first FEC element 574 corresponding to the top of the label stack, etc. 576 An MPLS echo request MUST have a Target FEC Stack that describes the 577 FEC Stack being tested. For example, if an LSR X has an LDP mapping 578 [RFC5036] for 192.168.1.1 (say, label 1001), then to verify that 579 label 1001 does indeed reach an egress LSR that announced this prefix 580 via LDP, X can send an MPLS echo request with an FEC Stack TLV with 581 one FEC in it, namely, of type LDP IPv4 prefix, with prefix 582 192.168.1.1/32, and send the echo request with a label of 1001. 584 Say LSR X wanted to verify that a label stack of <1001, 23456> is the 585 right label stack to use to reach a VPN IPv4 prefix [see section 586 3.2.5] of 10/8 in VPN foo. Say further that LSR Y with loopback 587 address 192.168.1.1 announced prefix 10/8 with Route Distinguisher 588 RD-foo-Y (which may in general be different from the Route 589 Distinguisher that LSR X uses in its own advertisements for VPN foo), 590 label 23456 and BGP next hop 192.168.1.1 [RFC4271]. Finally, suppose 591 that LSR X receives a label binding of 1001 for 192.168.1.1 via LDP. 592 X has two choices in sending an MPLS echo request: X can send an MPLS 593 echo request with an FEC Stack TLV with a single FEC of type VPN IPv4 594 prefix with a prefix of 10/8 and a Route Distinguisher of RD-foo-Y. 595 Alternatively, X can send an FEC Stack TLV with two FECs, the first 596 of type LDP IPv4 with a prefix of 192.168.1.1/32 and the second of 597 type of IP VPN with a prefix 10/8 with Route Distinguisher of RD-foo- 598 Y. In either case, the MPLS echo request would have a label stack of 599 <1001, 23456>. (Note: in this example, 1001 is the "outer" label and 600 23456 is the "inner" label.) 602 3.2.1. LDP IPv4 Prefix 604 The IPv4 Prefix FEC is defined in [RFC5036]. When an LDP IPv4 prefix 605 is encoded in a label stack, the following format is used. The value 606 consists of 4 octets of an IPv4 prefix followed by 1 octet of prefix 607 length in bits; the format is given below. The IPv4 prefix is in 608 network byte order; if the prefix is shorter than 32 bits, trailing 609 bits SHOULD be set to zero. See [RFC5036] for an example of a 610 Mapping for an IPv4 FEC. 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | IPv4 prefix | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Prefix Length | Must Be Zero | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 3.2.2. LDP IPv6 Prefix 622 The IPv6 Prefix FEC is defined in [RFC5036]. When an LDP IPv6 prefix 623 is encoded in a label stack, the following format is used. The value 624 consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix 625 length in bits; the format is given below. The IPv6 prefix is in 626 network byte order; if the prefix is shorter than 128 bits, the 627 trailing bits SHOULD be set to zero. See [RFC5036] for an example of 628 a Mapping for an IPv6 FEC. 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | IPv6 prefix | 634 | (16 octets) | 635 | | 636 | | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Prefix Length | Must Be Zero | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 3.2.3. RSVP IPv4 LSP 643 The value has the format below. The value fields are taken from RFC 644 3209, sections 4.6.1.1 and 4.6.2.1. See [RFC3209]. 646 0 1 2 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | IPv4 tunnel end point address | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Must Be Zero | Tunnel ID | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Extended Tunnel ID | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | IPv4 tunnel sender address | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Must Be Zero | LSP ID | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 3.2.4. RSVP IPv6 LSP 662 The value has the format below. The value fields are taken from RFC 663 3209, sections 4.6.1.2 and 4.6.2.2. See [RFC3209]. 665 0 1 2 3 666 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 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | IPv6 tunnel end point address | 669 | | 670 | | 671 | | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Must Be Zero | Tunnel ID | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Extended Tunnel ID | 676 | | 677 | | 678 | | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | IPv6 tunnel sender address | 681 | | 682 | | 683 | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Must Be Zero | LSP ID | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 3.2.5. VPN IPv4 Prefix 690 VPN-IPv4 Network Layer Routing Information (NLRI) is defined in 691 [RFC4365]. This document uses the term VPN IPv4 prefix for a VPN- 692 IPv4 NLRI that has been advertised with an MPLS label in BGP. See 693 [RFC3107]. 695 When a VPN IPv4 prefix is encoded in a label stack, the following 696 format is used. The value field consists of the Route Distinguisher 697 advertised with the VPN IPv4 prefix, the IPv4 prefix (with trailing 0 698 bits to make 32 bits in all), and a prefix length, as follows: 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Route Distinguisher | 704 | (8 octets) | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | IPv4 prefix | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Prefix Length | Must Be Zero | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 The Route Distinguisher (RD) is an 8-octet identifier; it does not 712 contain any inherent information. The purpose of the RD is solely to 713 allow one to create distinct routes to a common IPv4 address prefix. 714 The encoding of the RD is not important here. When matching this 715 field to the local FEC information, it is treated as an opaque value. 717 3.2.6. VPN IPv6 Prefix 719 VPN-IPv6 Network Layer Routing Information (NLRI) is defined in 720 [RFC4365]. This document uses the term VPN IPv6 prefix for a VPN- 721 IPv6 NLRI that has been advertised with an MPLS label in BGP. See 722 [RFC3107]. 724 When a VPN IPv6 prefix is encoded in a label stack, the following 725 format is used. The value field consists of the Route Distinguisher 726 advertised with the VPN IPv6 prefix, the IPv6 prefix (with trailing 0 727 bits to make 128 bits in all), and a prefix length, as follows: 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Route Distinguisher | 733 | (8 octets) | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | IPv6 prefix | 736 | | 737 | | 738 | | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Prefix Length | Must Be Zero | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 The Route Distinguisher is identical to the VPN IPv4 Prefix RD, 744 except that it functions here to allow the creation of distinct 745 routes to IPv6 prefixes. See section 3.2.5. When matching this 746 field to local FEC information, it is treated as an opaque value. 748 3.2.7. L2 VPN Endpoint 750 VPLS stands for Virtual Private LAN Service. The terms VPLS BGP NLRI 751 and VE ID (VPLS Edge Identifier) are defined in [RFC4761]. This 752 document uses the simpler term L2 VPN endpoint when referring to a 753 VPLS BGP NLRI. The Route Distinguisher is an 8-octet identifier used 754 to distinguish information about various L2 VPNs advertised by a 755 node. The VE ID is a 2-octet identifier used to identify a 756 particular node that serves as the service attachment point within a 757 VPLS. The structure of these two identifiers is unimportant here; 758 when matching these fields to local FEC information, they are treated 759 as opaque values. The encapsulation type is identical to the PW Type 760 in section 3.2.8 below. 762 When an L2 VPN endpoint is encoded in a label stack, the following 763 format is used. The value field consists of a Route Distinguisher (8 764 octets), the sender (of the ping)'s VE ID (2 octets), the receiver's 765 VE ID (2 octets), and an encapsulation type (2 octets), formatted as 766 follows: 768 0 1 2 3 769 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 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Route Distinguisher | 772 | (8 octets) | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Sender's VE ID | Receiver's VE ID | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Encapsulation Type | Must Be Zero | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 3.2.8. FEC 128 Pseudowire (Deprecated) 781 FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID 782 (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero 783 32-bit connection ID. The PW Type is a 15-bit number indicating the 784 encapsulation type. It is carried right justified in the field below 785 termed encapsulation type with the high-order bit set to zero. Both 786 of these fields are treated in this protocol as opaque values. 788 When an FEC 128 is encoded in a label stack, the following format is 789 used. The value field consists of the remote PE address (the 790 destination address of the targeted LDP session), the PW ID, and the 791 encapsulation type as follows: 793 0 1 2 3 794 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 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Remote PE Address | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | PW ID | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | PW Type | Must Be Zero | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 This FEC is deprecated and is retained only for backward 804 compatibility. Implementations of LSP ping SHOULD accept and process 805 this TLV, but SHOULD send LSP ping echo requests with the new TLV 806 (see next section), unless explicitly configured to use the old TLV. 808 An LSR receiving this TLV SHOULD use the source IP address of the LSP 809 echo request to infer the sender's PE address. 811 3.2.9. FEC 128 Pseudowire (Current) 813 FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID 814 (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero 815 32-bit connection ID. The PW Type is a 15-bit number indicating the 816 encapsulation type. It is carried right justified in the field below 817 termed encapsulation type with the high-order bit set to zero. 819 Both of these fields are treated in this protocol as opaque values. 820 When matching these field to the local FEC information, the match 821 MUST be exact. 823 When an FEC 128 is encoded in a label stack, the following format is 824 used. The value field consists of the sender's PE address (the 825 source address of the targeted LDP session), the remote PE address 826 (the destination address of the targeted LDP session), the PW ID, and 827 the encapsulation type as follows: 829 0 1 2 3 830 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 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Sender's PE Address | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Remote PE Address | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | PW ID | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | PW Type | Must Be Zero | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 3.2.10. FEC 129 Pseudowire 843 FEC 129 (0x81) and the terms PW Type, Attachment Group Identifier 844 (AGI), Attachment Group Identifier Type (AGI Type), Attachment 845 Individual Identifier Type (AII Type), Source Attachment Individual 846 Identifier (SAII), and Target Attachment Individual Identifier (TAII) 847 are defined in [RFC4447]. The PW Type is a 15-bit number indicating 848 the encapsulation type. It is carried right justified in the field 849 below PW Type with the high-order bit set to zero. All the other 850 fields are treated as opaque values and copied directly from the FEC 851 129 format. All of these values together uniquely define the FEC 852 within the scope of the LDP session identified by the source and 853 remote PE addresses. 855 When an FEC 129 is encoded in a label stack, the following format is 856 used. The Length of this TLV is 16 + AGI length + SAII length + TAII 857 length. Padding is used to make the total length a multiple of 4; 858 the length of the padding is not included in the Length field. 860 0 1 2 3 861 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 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Sender's PE Address | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Remote PE Address | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | PW Type | AGI Type | AGI Length | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 ~ AGI Value ~ 870 | | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | AII Type | SAII Length | SAII Value | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 ~ SAII Value (continued) ~ 875 | | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | AII Type | TAII Length | TAII Value | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 ~ TAII Value (continued) ~ 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | TAII (cont.) | 0-3 octets of zero padding | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 3.2.11. BGP Labeled IPv4 Prefix 886 BGP labeled IPv4 prefixes are defined in [RFC3107]. When a BGP 887 labeled IPv4 prefix is encoded in a label stack, the following format 888 is used. The value field consists the IPv4 prefix (with trailing 0 889 bits to make 32 bits in all), and the prefix length, as follows: 891 0 1 2 3 892 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 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | IPv4 Prefix | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Prefix Length | Must Be Zero | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 3.2.12. BGP Labeled IPv6 Prefix 901 BGP labeled IPv6 prefixes are defined in [RFC3107]. When a BGP 902 labeled IPv6 prefix is encoded in a label stack, the following format 903 is used. The value consists of 16 octets of an IPv6 prefix followed 904 by 1 octet of prefix length in bits; the format is given below. The 905 IPv6 prefix is in network byte order; if the prefix is shorter than 906 128 bits, the trailing bits SHOULD be set to zero. 908 0 1 2 3 909 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 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | IPv6 prefix | 912 | (16 octets) | 913 | | 914 | | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Prefix Length | Must Be Zero | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 3.2.13. Generic IPv4 Prefix 921 The value consists of 4 octets of an IPv4 prefix followed by 1 octet 922 of prefix length in bits; the format is given below. The IPv4 prefix 923 is in network byte order; if the prefix is shorter than 32 bits, 924 trailing bits SHOULD be set to zero. This FEC is used if the 925 protocol advertising the label is unknown or may change during the 926 course of the LSP. An example is an inter-AS LSP that may be 927 signaled by LDP in one Autonomous System (AS), by RSVP-TE [RFC3209] 928 in another AS, and by BGP between the ASes, such as is common for 929 inter-AS VPNs. 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | IPv4 prefix | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Prefix Length | Must Be Zero | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 3.2.14. Generic IPv6 Prefix 941 The value consists of 16 octets of an IPv6 prefix followed by 1 octet 942 of prefix length in bits; the format is given below. The IPv6 prefix 943 is in network byte order; if the prefix is shorter than 128 bits, the 944 trailing bits SHOULD be set to zero. 946 0 1 2 3 947 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 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | IPv6 prefix | 950 | (16 octets) | 951 | | 952 | | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Prefix Length | Must Be Zero | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 3.2.15. Nil FEC 959 At times, labels from the reserved range, e.g., Router Alert and 960 Explicit-null, may be added to the label stack for various diagnostic 961 purposes such as influencing load-balancing. These labels may have 962 no explicit FEC associated with them. The Nil FEC Stack is defined 963 to allow a Target FEC Stack sub-TLV to be added to the Target FEC 964 Stack to account for such labels so that proper validation can still 965 be performed. 967 The Length is 4. Labels are 20-bit values treated as numbers. 969 0 1 2 3 970 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 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Label | MBZ | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 Label is the actual label value inserted in the label stack; the MBZ 976 fields MUST be zero when sent and ignored on receipt. 978 3.3. Downstream Mapping 980 The Downstream Mapping object is a TLV that MAY be included in an 981 echo request message. Only one Downstream Mapping object may appear 982 in an echo request. The presence of a Downstream Mapping object is a 983 request that Downstream Mapping objects be included in the echo 984 reply. If the replying router is the destination of the FEC, then a 985 Downstream Mapping TLV SHOULD NOT be included in the echo reply. 986 Otherwise the replying router SHOULD include a Downstream Mapping 987 object for each interface over which this FEC could be forwarded. 988 For a more precise definition of the notion of "downstream", see 989 section 3.3.2, "Downstream Router and Interface". 991 The Length is K + M + 4*N octets, where M is the Multipath Length, 992 and N is the number of Downstream Labels. Values for K are found in 993 the description of Address Type below. The Value field of a 994 Downstream Mapping has the following format: 996 0 1 2 3 997 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 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | MTU | Address Type | DS Flags | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | Downstream IP Address (4 or 16 octets) | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | Downstream Interface Address (4 or 16 octets) | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Multipath Type| Depth Limit | Multipath Length | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 . . 1008 . (Multipath Information) . 1009 . . 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Downstream Label | Protocol | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 . . 1014 . . 1015 . . 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Downstream Label | Protocol | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 Maximum Transmission Unit (MTU) 1022 The MTU is the size in octets of the largest MPLS frame (including 1023 label stack) that fits on the interface to the Downstream LSR. 1025 Address Type 1027 The Address Type indicates if the interface is numbered or 1028 unnumbered. It also determines the length of the Downstream IP 1029 Address and Downstream Interface fields. The resulting total for 1030 the initial part of the TLV is listed in the table below as "K 1031 Octets". The Address Type is set to one of the following values: 1033 Type # Address Type K Octets 1034 ------ ------------ -------- 1035 1 IPv4 Numbered 16 1036 2 IPv4 Unnumbered 16 1037 3 IPv6 Numbered 40 1038 4 IPv6 Unnumbered 28 1040 DS Flags 1042 The DS Flags field is a bit vector with the following format: 1044 0 1 2 3 4 5 6 7 1045 +-+-+-+-+-+-+-+-+ 1046 | Rsvd(MBZ) |I|N| 1047 +-+-+-+-+-+-+-+-+ 1049 Two flags are defined currently, I and N. The remaining flags MUST 1050 be set to zero when sending and ignored on receipt. 1052 Flag Name and Meaning 1053 ---- ---------------- 1054 I Interface and Label Stack Object Request 1056 When this flag is set, it indicates that the replying 1057 router SHOULD include an Interface and Label Stack 1058 Object in the echo reply message. 1060 N Treat as a Non-IP Packet 1062 Echo request messages will be used to diagnose non-IP 1063 flows. However, these messages are carried in IP 1064 packets. For a router that alters its ECMP algorithm 1065 based on the FEC or deep packet examination, this flag 1066 requests that the router treat this as it would if the 1067 determination of an IP payload had failed. 1069 Downstream IP Address and Downstream Interface Address 1071 IPv4 addresses and interface indices are encoded in 4 octets; IPv6 1072 addresses are encoded in 16 octets. 1074 If the interface to the downstream LSR is numbered, then the 1075 Address Type MUST be set to IPv4 or IPv6, the Downstream IP 1076 Address MUST be set to either the downstream LSR's Router ID or 1077 the interface address of the downstream LSR, and the Downstream 1078 Interface Address MUST be set to the downstream LSR's interface 1079 address. 1081 If the interface to the downstream LSR is unnumbered, the Address 1082 Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP 1083 Address MUST be the downstream LSR's Router ID, and the Downstream 1084 Interface Address MUST be set to the index assigned by the 1085 upstream LSR to the interface. 1087 If an LSR does not know the IP address of its neighbor, then it 1088 MUST set the Address Type to either IPv4 Unnumbered or IPv6 1089 Unnumbered. For IPv4, it must set the Downstream IP Address to 1090 127.0.0.1; for IPv6 the address is set to 0::1. In both cases, 1091 the interface index MUST be set to 0. If an LSR receives an Echo 1092 Request packet with either of these addresses in the Downstream IP 1093 Address field, this indicates that it MUST bypass interface 1094 verification but continue with label validation. 1096 If the originator of an Echo Request packet wishes to obtain 1097 Downstream Mapping information but does not know the expected 1098 label stack, then it SHOULD set the Address Type to either IPv4 1099 Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set the 1100 Downstream IP Address to 224.0.0.2; for IPv6 the address MUST be 1101 set to FF02::2. In both cases, the interface index MUST be set to 1102 0. If an LSR receives an Echo Request packet with the all-routers 1103 multicast address, then this indicates that it MUST bypass both 1104 interface and label stack validation, but return Downstream 1105 Mapping TLVs using the information provided. 1107 Multipath Type 1109 The following Multipath Types are defined: 1111 Key Type Multipath Information 1112 --- ---------------- --------------------- 1113 0 no multipath Empty (Multipath Length = 0) 1114 2 IP address IP addresses 1115 4 IP address range low/high address pairs 1116 8 Bit-masked IP IP address prefix and bit mask 1117 address set 1118 9 Bit-masked label set Label prefix and bit mask 1120 Type 0 indicates that all packets will be forwarded out this one 1121 interface. 1123 Types 2, 4, 8, and 9 specify that the supplied Multipath Information 1124 will serve to exercise this path. 1126 Depth Limit 1128 The Depth Limit is applicable only to a label stack and is the 1129 maximum number of labels considered in the hash; this SHOULD be 1130 set to zero if unspecified or unlimited. 1132 Multipath Length 1134 The length in octets of the Multipath Information. 1136 Multipath Information 1138 Address or label values encoded according to the Multipath Type. 1139 See the next section below for encoding details. 1141 Downstream Label(s) 1143 The set of labels in the label stack as it would have appeared if 1144 this router were forwarding the packet through this interface. 1145 Any Implicit Null labels are explicitly included. Labels are 1146 treated as numbers, i.e., they are right justified in the field. 1148 A Downstream Label is 24 bits, in the same format as an MPLS label 1149 minus the TTL field, i.e., the MSBit of the label is bit 0, the 1150 LSBit is bit 19, the EXP bits are bits 20-22, and bit 23 is the S 1151 bit. The replying router SHOULD fill in the EXP and S bits; the 1152 LSR receiving the echo reply MAY choose to ignore these bits. 1153 Protocol 1155 The Protocol is taken from the following table: 1157 Protocol # Signaling Protocol 1158 ---------- ------------------ 1159 0 Unknown 1160 1 Static 1161 2 BGP 1162 3 LDP 1163 4 RSVP-TE 1165 3.3.1. Multipath Information Encoding 1167 The Multipath Information encodes labels or addresses that will 1168 exercise this path. The Multipath Information depends on the 1169 Multipath Type. The contents of the field are shown in the table 1170 above. IPv4 addresses are drawn from the range 127/8; IPv6 addresses 1171 are drawn from the range 0:0:0:0:0:FFFF:7F00/104. Labels are treated 1172 as numbers, i.e., they are right justified in the field. For Type 4, 1173 ranges indicated by Address pairs MUST NOT overlap and MUST be in 1174 ascending sequence. 1176 Type 8 allows a more dense encoding of IP addresses. The IP prefix 1177 is formatted as a base IP address with the non-prefix low-order bits 1178 set to zero. The maximum prefix length is 27. Following the prefix 1179 is a mask of length 2^(32-prefix length) bits for IPv4 and 1180 2^(128-prefix length) bits for IPv6. Each bit set to 1 represents a 1181 valid address. The address is the base IPv4 address plus the 1182 position of the bit in the mask where the bits are numbered left to 1183 right beginning with zero. For example, the IPv4 addresses 1184 127.2.1.0, 127.2.1.5-127.2.1.15, and 127.2.1.20-127.2.1.29 would be 1185 encoded as follows: 1187 0 1 2 3 1188 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 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 |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| 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 |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| 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 Those same addresses embedded in IPv6 would be encoded as follows: 1197 0 1 2 3 1198 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 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 |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| 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 |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| 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 |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| 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 |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| 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 |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| 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 Type 9 allows a more dense encoding of labels. The label prefix is 1212 formatted as a base label value with the non-prefix low-order bits 1213 set to zero. The maximum prefix (including leading zeros due to 1214 encoding) length is 27. Following the prefix is a mask of length 1215 2^(32-prefix length) bits. Each bit set to one represents a valid 1216 label. The label is the base label plus the position of the bit in 1217 the mask where the bits are numbered left to right beginning with 1218 zero. Label values of all the odd numbers between 1152 and 1279 1219 would be encoded as follows: 1221 0 1 2 3 1222 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 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 |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| 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 |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| 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 |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| 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 |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| 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 |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| 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 If the received Multipath Information is non-null, the labels and IP 1235 addresses MUST be picked from the set provided. If none of these 1236 labels or addresses map to a particular downstream interface, then 1237 for that interface, the type MUST be set to 0. If the received 1238 Multipath Information is null (i.e., Multipath Length = 0, or for 1239 Types 8 and 9, a mask of all zeros), the type MUST be set to 0. 1241 For example, suppose LSR X at hop 10 has two downstream LSRs, Y and 1242 Z, for the FEC in question. The received X could return Multipath 1243 Type 4, with low/high IP addresses of 127.1.1.1->127.1.1.255 for 1244 downstream LSR Y and 127.2.1.1->127.2.1.255 for downstream LSR Z. 1245 The head end reflects this information to LSR Y. Y, which has three 1246 downstream LSRs, U, V, and W, computes that 127.1.1.1->127.1.1.127 1247 would go to U and 127.1.1.128-> 127.1.1.255 would go to V. Y would 1248 then respond with 3 Downstream Mappings: to U, with Multipath Type 4 1249 (127.1.1.1->127.1.1.127); to V, with Multipath Type 4 1250 (127.1.1.127->127.1.1.255); and to W, with Multipath Type 0. 1252 Note that computing Multipath Information may impose a significant 1253 processing burden on the receiver. A receiver MAY thus choose to 1254 process a subset of the received prefixes. The sender, on receiving 1255 a reply to a Downstream Mapping with partial information, SHOULD 1256 assume that the prefixes missing in the reply were skipped by the 1257 receiver, and MAY re-request information about them in a new echo 1258 request. 1260 3.3.2. Downstream Router and Interface 1262 The notion of "downstream router" and "downstream interface" should 1263 be explained. Consider an LSR X. If a packet that was originated 1264 with TTL n>1 arrived with outermost label L and TTL=1 at LSR X, X 1265 must be able to compute which LSRs could receive the packet if it was 1266 originated with TTL=n+1, over which interface the request would 1267 arrive and what label stack those LSRs would see. (It is outside the 1268 scope of this document to specify how this computation is done.) The 1269 set of these LSRs/interfaces consists of the downstream routers/ 1270 interfaces (and their corresponding labels) for X with respect to L. 1271 Each pair of downstream router and interface requires a separate 1272 Downstream Mapping to be added to the reply. 1274 The case where X is the LSR originating the echo request is a special 1275 case. X needs to figure out what LSRs would receive the MPLS echo 1276 request for a given FEC Stack that X originates with TTL=1. 1278 The set of downstream routers at X may be alternative paths (see the 1279 discussion below on ECMP) or simultaneous paths (e.g., for MPLS 1280 multicast). In the former case, the Multipath Information is used as 1281 a hint to the sender as to how it may influence the choice of these 1282 alternatives. 1284 3.4. Pad TLV 1286 The value part of the Pad TLV contains a variable number (>= 1) of 1287 octets. The first octet takes values from the following table; all 1288 the other octets (if any) are ignored. The receiver SHOULD verify 1289 that the TLV is received in its entirety, but otherwise ignores the 1290 contents of this TLV, apart from the first octet. 1292 Value Meaning 1293 ----- ------- 1294 1 Drop Pad TLV from reply 1295 2 Copy Pad TLV to reply 1296 3-255 Reserved for future use 1298 3.5. Vendor Enterprise Number 1300 SMI Private Enterprise Numbers are maintained by IANA. The Length is 1301 always 4; the value is the SMI Private Enterprise code, in network 1302 octet order, of the vendor with a Vendor Private extension to any of 1303 the fields in the fixed part of the message, in which case this TLV 1304 MUST be present. If none of the fields in the fixed part of the 1305 message have Vendor Private extensions, inclusion of this TLV is 1306 OPTIONAL. Vendor Private ranges for Message Types, Reply Modes, and 1307 Return Codes have been defined. When any of these are used, the 1308 Vendor Enterprise Number TLV MUST be included in the message. 1310 3.6. Interface and Label Stack 1312 The Interface and Label Stack TLV MAY be included in a reply message 1313 to report the interface on which the request message was received and 1314 the label stack that was on the packet when it was received. Only 1315 one such object may appear. The purpose of the object is to allow 1316 the upstream router to obtain the exact interface and label stack 1317 information as it appears at the replying LSR. 1319 The Length is K + 4*N octets; N is the number of labels in the label 1320 stack. Values for K are found in the description of Address Type 1321 below. The Value field of a Downstream Mapping has the following 1322 format: 1324 0 1 2 3 1325 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 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | Address Type | Must Be Zero | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | IP Address (4 or 16 octets) | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Interface (4 or 16 octets) | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 . . 1334 . . 1335 . Label Stack . 1336 . . 1337 . . 1338 . . 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 Address Type 1343 The Address Type indicates if the interface is numbered or 1344 unnumbered. It also determines the length of the IP Address and 1345 Interface fields. The resulting total for the initial part of the 1346 TLV is listed in the table below as "K Octets". The Address Type 1347 is set to one of the following values: 1349 Type # Address Type K Octets 1350 ------ ------------ -------- 1351 1 IPv4 Numbered 12 1352 2 IPv4 Unnumbered 12 1353 3 IPv6 Numbered 36 1354 4 IPv6 Unnumbered 24 1356 IP Address and Interface 1358 IPv4 addresses and interface indices are encoded in 4 octets; IPv6 1359 addresses are encoded in 16 octets. 1361 If the interface upon which the echo request message was received 1362 is numbered, then the Address Type MUST be set to IPv4 or IPv6, 1363 the IP Address MUST be set to either the LSR's Router ID or the 1364 interface address, and the Interface MUST be set to the interface 1365 address. 1367 If the interface is unnumbered, the Address Type MUST be either 1368 IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the 1369 LSR's Router ID, and the Interface MUST be set to the index 1370 assigned to the interface. 1372 Label Stack 1374 The label stack of the received echo request message. If any TTL 1375 values have been changed by this router, they SHOULD be restored. 1377 3.7. Errored TLVs 1379 The following TLV is a TLV that MAY be included in an echo reply to 1380 inform the sender of an echo request of mandatory TLVs either not 1381 supported by an implementation or parsed and found to be in error. 1383 The Value field contains the TLVs that were not understood, encoded 1384 as sub-TLVs. 1386 0 1 2 3 1387 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 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | Type = 9 | Length | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | Value | 1392 . . 1393 . . 1394 . . 1395 | | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 3.8. Reply TOS Byte TLV 1400 This TLV MAY be used by the originator of the echo request to request 1401 that an echo reply be sent with the IP header TOS byte set to the 1402 value specified in the TLV. This TLV has a length of 4 with the 1403 following value field. 1405 0 1 2 3 1406 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 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | Reply-TOS Byte| Must Be Zero | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 4. Theory of Operation 1413 An MPLS echo request is used to test a particular LSP. The LSP to be 1414 tested is identified by the "FEC Stack"; for example, if the LSP was 1415 set up via LDP, and is to an egress IP address of 10.1.1.1, the FEC 1416 Stack contains a single element, namely, an LDP IPv4 prefix sub-TLV 1417 with value 10.1.1.1/32. If the LSP being tested is an RSVP LSP, the 1418 FEC Stack consists of a single element that captures the RSVP Session 1419 and Sender Template that uniquely identifies the LSP. 1421 FEC Stacks can be more complex. For example, one may wish to test a 1422 VPN IPv4 prefix of 10.1/8 that is tunneled over an LDP LSP with 1423 egress 10.10.1.1. The FEC Stack would then contain two sub-TLVs, the 1424 bottom being a VPN IPv4 prefix, and the top being an LDP IPv4 prefix. 1425 If the underlying (LDP) tunnel were not known, or was considered 1426 irrelevant, the FEC Stack could be a single element with just the VPN 1427 IPv4 sub-TLV. 1429 When an MPLS echo request is received, the receiver is expected to 1430 verify that the control plane and data plane are both healthy (for 1431 the FEC Stack being pinged) and that the two planes are in sync. The 1432 procedures for this are in section 4.4 below. 1434 4.1. Dealing with Equal-Cost Multi-Path (ECMP) 1436 LSPs need not be simple point-to-point tunnels. Frequently, a single 1437 LSP may originate at several ingresses, and terminate at several 1438 egresses; this is very common with LDP LSPs. LSPs for a given FEC 1439 may also have multiple "next hops" at transit LSRs. At an ingress, 1440 there may also be several different LSPs to choose from to get to the 1441 desired endpoint. Finally, LSPs may have backup paths, detour paths, 1442 and other alternative paths to take should the primary LSP go down. 1444 To deal with the last two first: it is assumed that the LSR sourcing 1445 MPLS echo requests can force the echo request into any desired LSP, 1446 so choosing among multiple LSPs at the ingress is not an issue. The 1447 problem of probing the various flavors of backup paths that will 1448 typically not be used for forwarding data unless the primary LSP is 1449 down will not be addressed here. 1451 Since the actual LSP and path that a given packet may take may not be 1452 known a priori, it is useful if MPLS echo requests can exercise all 1453 possible paths. This, although desirable, may not be practical, 1454 because the algorithms that a given LSR uses to distribute packets 1455 over alternative paths may be proprietary. 1457 To achieve some degree of coverage of alternate paths, there is a 1458 certain latitude in choosing the destination IP address and source 1459 UDP port for an MPLS echo request. This is clearly not sufficient; 1460 in the case of traceroute, more latitude is offered by means of the 1461 Multipath Information of the Downstream Mapping TLV. This is used as 1462 follows. An ingress LSR periodically sends an MPLS traceroute 1463 message to determine whether there are multipaths for a given LSP. 1464 If so, each hop will provide some information how each of its 1465 downstream paths can be exercised. The ingress can then send MPLS 1466 echo requests that exercise these paths. If several transit LSRs 1467 have ECMP, the ingress may attempt to compose these to exercise all 1468 possible paths. However, full coverage may not be possible. 1470 4.2. Testing LSPs That Are Used to Carry MPLS Payloads 1472 To detect certain LSP breakages, it may be necessary to encapsulate 1473 an MPLS echo request packet with at least one additional label when 1474 testing LSPs that are used to carry MPLS payloads (such as LSPs used 1475 to carry L2VPN and L3VPN traffic. For example, when testing LDP or 1476 RSVP-TE LSPs, just sending an MPLS echo request packet may not detect 1477 instances where the router immediately upstream of the destination of 1478 the LSP ping may forward the MPLS echo request successfully over an 1479 interface not configured to carry MPLS payloads because of the use of 1480 penultimate hop popping. Since the receiving router has no means to 1481 differentiate whether the IP packet was sent unlabeled or implicitly 1482 labeled, the addition of labels shimmed above the MPLS echo request 1483 (using the Nil FEC) will prevent a router from forwarding such a 1484 packet out unlabeled interfaces. 1486 4.3. Sending an MPLS Echo Request 1488 An MPLS echo request is a UDP packet. The IP header is set as 1489 follows: the source IP address is a routable address of the sender; 1490 the destination IP address is a (randomly chosen) IPv4 address from 1491 the range 127/8 or IPv6 address from the range 1492 0:0:0:0:0:FFFF:7F00/104. The IP TTL is set to 1. The source UDP 1493 port is chosen by the sender; the destination UDP port is set to 3503 1494 (assigned by IANA for MPLS echo requests). The Router Alert option 1495 MUST be set in the IP header. 1497 An MPLS echo request is sent with a label stack corresponding to the 1498 FEC Stack being tested. Note that further labels could be applied 1499 if, for example, the normal route to the topmost FEC in the stack is 1500 via a Traffic Engineered Tunnel [RFC3209]. If all of the FECs in the 1501 stack correspond to Implicit Null labels, the MPLS echo request is 1502 considered unlabeled even if further labels will be applied in 1503 sending the packet. 1505 If the echo request is labeled, one MAY (depending on what is being 1506 pinged) set the TTL of the innermost label to 1, to prevent the ping 1507 request going farther than it should. Examples of where this SHOULD 1508 be done include pinging a VPN IPv4 or IPv6 prefix, an L2 VPN endpoint 1509 or a pseudowire. Preventing the ping request from going too far can 1510 also be accomplished by inserting a Router Alert label above this 1511 label; however, this may lead to the undesired side effect that MPLS 1512 echo requests take a different data path than actual data. For more 1513 information on how these mechanisms can be used for pseudowire 1514 connectivity verification, see [RFC5085]. 1516 In "ping" mode (end-to-end connectivity check), the TTL in the 1517 outermost label is set to 255. In "traceroute" mode (fault isolation 1518 mode), the TTL is set successively to 1, 2, and so on. 1520 The sender chooses a Sender's Handle and a Sequence Number. When 1521 sending subsequent MPLS echo requests, the sender SHOULD increment 1522 the Sequence Number by 1. However, a sender MAY choose to send a 1523 group of echo requests with the same Sequence Number to improve the 1524 chance of arrival of at least one packet with that Sequence Number. 1526 The TimeStamp Sent is set to the time-of-day in NTP format that the 1527 echo request is sent. The TimeStamp Received is set to zero. 1529 An MPLS echo request MUST have an FEC Stack TLV. Also, the Reply 1530 Mode must be set to the desired reply mode; the Return Code and 1531 Subcode are set to zero. In the "traceroute" mode, the echo request 1532 SHOULD include a Downstream Mapping TLV. 1534 4.4. Receiving an MPLS Echo Request 1536 Sending an MPLS echo request to the control plane is triggered by one 1537 of the following packet processing exceptions: Router Alert option, 1538 IP TTL expiration, MPLS TTL expiration, MPLS Router Alert label, or 1539 the destination address in the 127/8 address range. The control 1540 plane further identifies it by UDP destination port 3503. 1542 For reporting purposes the bottom of stack is considered to be stack- 1543 depth of 1. This is to establish an absolute reference for the case 1544 where the actual stack may have more labels than there are FECs in 1545 the Target FEC Stack. 1547 Furthermore, in all the error codes listed in this document, a stack- 1548 depth of 0 means "no value specified". This allows compatibility 1549 with existing implementations that do not use the Return Subcode 1550 field. 1552 An LSR X that receives an MPLS echo request then processes it as 1553 follows. 1555 1. General packet sanity is verified. If the packet is not well- 1556 formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code 1557 set to "Malformed echo request received" and the Subcode to zero. 1558 If there are any TLVs not marked as "Ignore" that LSR X does not 1559 understand, LSR X SHOULD send an MPLS "TLV not understood" (as 1560 appropriate), and the Subcode set to zero. In the latter case, 1561 the misunderstood TLVs (only) are included as sub-TLVs in an 1562 Errored TLVs TLV in the reply. The header fields Sender's 1563 Handle, Sequence Number, and Timestamp Sent are not examined, but 1564 are included in the MPLS echo reply message. 1566 The algorithm uses the following variables and identifiers: 1568 Interface-I: the interface on which the MPLS echo request was 1569 received. 1571 Stack-R: the label stack on the packet as it was received. 1573 Stack-D: the label stack carried in the Downstream Mapping 1574 TLV (not always present) 1576 Label-L: the label from the actual stack currently being 1577 examined. Requires no initialization. 1579 Label-stack-depth: the depth of label being verified. Initialized 1580 to the number of labels in the received label 1581 stack S. 1583 FEC-stack-depth: depth of the FEC in the Target FEC Stack that 1584 should be used to verify the current actual 1585 label. Requires no initialization. 1587 Best-return-code: contains the return code for the echo reply 1588 packet as currently best known. As the algorithm 1589 progresses, this code may change depending on the 1590 results of further checks that it performs. 1592 Best-rtn-subcode: similar to Best-return-code, but for the Echo 1593 Reply Subcode. 1595 FEC-status: result value returned by the FEC Checking 1596 algorithm described in section 4.4.1. 1598 /* Save receive context information */ 1600 2. If the echo request is good, LSR X stores the interface over 1601 which the echo was received in Interface-I, and the label stack 1602 with which it came in Stack-R. 1604 /* The rest of the algorithm iterates over the labels in Stack-R, 1605 verifies validity of label values, reports associated label switching 1606 operations (for traceroute), verifies correspondence between the 1607 Stack-R and the Target FEC Stack description in the body of the echo 1608 request, and reports any errors. */ 1610 /* The algorithm iterates as follows. */ 1611 3. Label Validation: 1613 If Label-stack-depth is 0 { 1615 /* The LSR needs to report its being a tail-end for the LSP */ 1617 Set FEC-stack-depth to 1, set Label-L to 3 (Implicit Null). 1618 Set Best-return-code to 3 ("Replying router is an egress for 1619 the FEC at stack depth"), set Best-rtn-subcode to the value of 1620 FEC-stack-depth (1) and go to step 5 (Egress Processing). 1622 } 1624 /* This step assumes there is always an entry for well-known label 1625 values */ 1627 Set Label-L to the value extracted from Stack-R at depth Label- 1628 stack-depth. Look up Label-L in the Incoming Label Map (ILM) to 1629 determine if the label has been allocated and an operation is 1630 associated with it. 1632 If there is no entry for L { 1634 /* Indicates a temporary or permanent label synchronization 1635 problem the LSR needs to report an error */ 1637 Set Best-return-code to 11 ("No label entry at stack-depth") 1638 and Best-rtn-subcode to Label-stack-depth. Go to step 7 (Send 1639 Reply Packet). 1641 } 1643 Else { 1645 Retrieve the associated label operation from the corresponding 1646 NHLFE and proceed to step 4 (Label Operation check). 1648 } 1650 4. Label Operation Check 1652 If the label operation is "Pop and Continue Processing" { 1654 /* Includes Explicit Null and Router Alert label cases */ 1656 Iterate to the next label by decrementing Label-stack-depth and 1657 loop back to step 3 (Label Validation). 1659 } 1661 If the label operation is "Swap or Pop and Switch based on Popped 1662 Label" { 1664 Set Best-return-code to 8 ("Label switched at stack-depth") and 1665 Best-rtn-subcode to Label-stack-depth to report transit 1666 switching. 1668 If a Downstream Mapping TLV is present in the received echo 1669 request { 1671 If the IP address in the TLV is 127.0.0.1 or 0::1 { 1673 Set Best-return-code to 6 ("Upstream Interface Index 1674 Unknown"). An Interface and Label Stack TLV SHOULD be 1675 included in the reply and filled with Interface-I and 1676 Stack-R. 1678 } 1680 Else { 1682 Verify that the IP address, interface address, and label 1683 stack in the Downstream Mapping TLV match Interface-I and 1684 Stack-R. If there is a mismatch, set Best-return-code to 1685 5, "Downstream Mapping Mismatch". An Interface and Label 1686 Stack TLV SHOULD be included in the reply and filled in 1687 based on Interface-I and Stack-R. Go to step 7 (Send 1688 Reply Packet). 1690 } 1692 } 1694 For each available downstream ECMP path { 1696 Retrieve output interface from the NHLFE entry. 1698 /* Note: this return code is set even if Label-stack-depth 1699 is one */ 1701 If the output interface is not MPLS enabled { 1703 Set Best-return-code to Return Code 9, "Label switched 1704 but no MPLS forwarding at stack-depth" and set Best-rtn- 1705 subcode to Label-stack-depth and goto Send_Reply_Packet. 1707 } 1709 If a Downstream Mapping TLV is present { 1711 A Downstream Mapping TLV SHOULD be included in the echo 1712 reply (see section 3.3) filled in with information about 1713 the current ECMP path. 1715 } 1717 } 1719 If no Downstream Mapping TLV is present, or the Downstream IP 1720 Address is set to the ALLROUTERS multicast address, go to step 1721 7 (Send Reply Packet). 1723 If the "Validate FEC Stack" flag is not set and the LSR is not 1724 configured to perform FEC checking by default, go to step 7 1725 (Send Reply Packet). 1727 /* Validate the Target FEC Stack in the received echo request. 1729 First determine FEC-stack-depth from the Downstream Mapping 1730 TLV. This is done by walking through Stack-D (the Downstream 1731 labels) from the bottom, decrementing the number of labels for 1732 each non-Implicit Null label, while incrementing FEC-stack- 1733 depth for each label. If the Downstream Mapping TLV contains 1734 one or more Implicit Null labels, FEC-stack-depth may be 1735 greater than Label-stack-depth. To be consistent with the 1736 above stack-depths, the bottom is considered to be entry 1. 1737 */ 1739 Set FEC-stack-depth to 0. Set i to Label-stack-depth. 1741 While (i > 0 ) do { 1743 ++FEC-stack-depth. 1744 if Stack-D[FEC-stack-depth] != 3 (Implicit Null) 1745 --i. 1746 } 1748 If the number of FECs in the FEC stack is greater than or equal 1749 to FEC-stack-depth { 1750 Perform the FEC Checking procedure (see subsection 4.4.1 1751 below). 1753 If FEC-status is 2, set Best-return-code to 10 ("Mapping for 1754 this FEC is not the given label at stack-depth"). 1756 If the return code is 1, set Best-return-code to FEC-return- 1757 code and Best-rtn-subcode to FEC-stack-depth. 1758 } 1760 Go to step 7 (Send Reply Packet). 1761 } 1763 5. Egress Processing: 1765 /* These steps are performed by the LSR that identified itself as 1766 the tail-end LSR for an LSP. */ 1768 If received echo request contains no Downstream Mapping TLV, or 1769 the Downstream IP Address is set to 127.0.0.1 or 0::1 go to step 6 1770 (Egress FEC Validation). 1772 Verify that the IP address, interface address, and label stack in 1773 the Downstream Mapping TLV match Interface-I and Stack-R. If not, 1774 set Best-return-code to 5, "Downstream Mapping Mis-match". A 1775 Received Interface and Label Stack TLV SHOULD be created for the 1776 echo response packet. Go to step 7 (Send Reply Packet). 1778 6. Egress FEC Validation: 1780 /* This is a loop for all entries in the Target FEC Stack starting 1781 with FEC-stack-depth. */ 1783 Perform FEC checking by following the algorithm described in 1784 subsection 4.4.1 for Label-L and the FEC at FEC-stack-depth. 1786 Set Best-return-code to FEC-code and Best-rtn-subcode to the value 1787 in FEC-stack-depth. 1789 If FEC-status (the result of the check) is 1, 1790 go to step 7 (Send Reply Packet). 1792 /* Iterate to the next FEC entry */ 1794 ++FEC-stack-depth. 1795 If FEC-stack-depth > the number of FECs in the FEC-stack, 1796 go to step 7 (Send Reply Packet). 1798 If FEC-status is 0 { 1800 ++Label-stack-depth. 1801 If Label-stack-depth > the number of labels in Stack-R, 1802 Go to step 7 (Send Reply Packet). 1804 Label-L = extracted label from Stack-R at depth 1805 Label-stack-depth. 1806 Loop back to step 6 (Egress FEC Validation). 1807 } 1809 7. Send Reply Packet: 1811 Send an MPLS echo reply with a Return Code of Best-return-code, 1812 and a Return Subcode of Best-rtn-subcode. Include any TLVs 1813 created during the above process. The procedures for sending the 1814 echo reply are found in subsection 4.5. 1816 4.4.1. FEC Validation 1818 /* This subsection describes validation of an FEC entry within the 1819 Target FEC Stack and accepts an FEC, Label-L, and Interface-I. The 1820 algorithm performs the following steps. */ 1822 1. Two return values, FEC-status and FEC-return-code, are 1823 initialized to 0. 1825 2. If the FEC is the Nil FEC { 1827 If Label-L is either Explicit_Null or Router_Alert, return. 1829 Else { 1831 Set FEC-return-code to 10 ("Mapping for this FEC is not the 1832 given label at stack-depth"). 1833 Set FEC-status to 1 1834 Return. 1835 } 1837 } 1839 3. Check the FEC label mapping that describes how traffic received 1840 on the LSP is further switched or which application it is 1841 associated with. If no mapping exists, set FEC-return-code to 1842 Return 4, "Replying router has no mapping for the FEC at stack- 1843 depth". Set FEC-status to 1. Return. 1845 4. If the label mapping for FEC is Implicit Null, set FEC-status to 1846 2 and proceed to step 5. Otherwise, if the label mapping for FEC 1847 is Label-L, proceed to step 5. Otherwise, set FEC-return-code to 1848 10 ("Mapping for this FEC is not the given label at stack- 1849 depth"), set FEC-status to 1, and return. 1851 5. This is a protocol check. Check what protocol would be used to 1852 advertise FEC. If it can be determined that no protocol 1853 associated with Interface-I would have advertised an FEC of that 1854 FEC-Type, set FEC-return-code to 12 ("Protocol not associated 1855 with interface at FEC stack-depth"). Set FEC-status to 1. 1857 6. Return. 1859 4.5. Sending an MPLS Echo Reply 1861 An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response 1862 to an MPLS echo request. The source IP address is a routable address 1863 of the replier; the source port is the well-known UDP port for LSP 1864 ping. The destination IP address and UDP port are copied from the 1865 source IP address and UDP port of the echo request. The IP TTL is 1866 set to 255. If the Reply Mode in the echo request is "Reply via an 1867 IPv4 UDP packet with Router Alert", then the IP header MUST contain 1868 the Router Alert IP option. If the reply is sent over an LSP, the 1869 topmost label MUST in this case be the Router Alert label (1) (see 1870 [RFC3032]). 1872 The format of the echo reply is the same as the echo request. The 1873 Sender's Handle, the Sequence Number, and TimeStamp Sent are copied 1874 from the echo request; the TimeStamp Received is set to the time-of- 1875 day that the echo request is received (note that this information is 1876 most useful if the time-of-day clocks on the requester and the 1877 replier are synchronized). The FEC Stack TLV from the echo request 1878 MAY be copied to the reply. 1880 The replier MUST fill in the Return Code and Subcode, as determined 1881 in the previous subsection. 1883 If the echo request contains a Pad TLV, the replier MUST interpret 1884 the first octet for instructions regarding how to reply. 1886 If the replying router is the destination of the FEC, then Downstream 1887 Mapping TLVs SHOULD NOT be included in the echo reply. 1889 If the echo request contains a Downstream Mapping TLV, and the 1890 replying router is not the destination of the FEC, the replier SHOULD 1891 compute its downstream routers and corresponding labels for the 1892 incoming label, and add Downstream Mapping TLVs for each one to the 1893 echo reply it sends back. 1895 If the Downstream Mapping TLV contains Multipath Information 1896 requiring more processing than the receiving router is willing to 1897 perform, the responding router MAY choose to respond with only a 1898 subset of multipaths contained in the echo request Downstream 1899 Mapping. (Note: The originator of the echo request MAY send another 1900 echo request with the Multipath Information that was not included in 1901 the reply.) 1903 Except in the case of Reply Mode 4, "Reply via application level 1904 control channel", echo replies are always sent in the context of the 1905 IP/MPLS network. 1907 4.6. Receiving an MPLS Echo Reply 1909 An LSR X should only receive an MPLS echo reply in response to an 1910 MPLS echo request that it sent. Thus, on receipt of an MPLS echo 1911 reply, X should parse the packet to ensure that it is well-formed, 1912 then attempt to match up the echo reply with an echo request that it 1913 had previously sent, using the destination UDP port and the Sender's 1914 Handle. If no match is found, then X jettisons the echo reply; 1915 otherwise, it checks the Sequence Number to see if it matches. 1917 If the echo reply contains Downstream Mappings, and X wishes to 1918 traceroute further, it SHOULD copy the Downstream Mapping(s) into its 1919 next echo request(s) (with TTL incremented by one). 1921 4.7. Issue with VPN IPv4 and IPv6 Prefixes 1923 Typically, an LSP ping for a VPN IPv4 prefix or VPN IPv6 prefix is 1924 sent with a label stack of depth greater than 1, with the innermost 1925 label having a TTL of 1. This is to terminate the ping at the egress 1926 PE, before it gets sent to the customer device. However, under 1927 certain circumstances, the label stack can shrink to a single label 1928 before the ping hits the egress PE; this will result in the ping 1929 terminating prematurely. One such scenario is a multi-AS Carrier's 1930 Carrier VPN. 1932 To get around this problem, one approach is for the LSR that receives 1933 such a ping to realize that the ping terminated prematurely, and send 1934 back error code 13. In that case, the initiating LSR can retry the 1935 ping after incrementing the TTL on the VPN label. In this fashion, 1936 the ingress LSR will sequentially try TTL values until it finds one 1937 that allows the VPN ping to reach the egress PE. 1939 4.8. Non-compliant Routers 1941 If the egress for the FEC Stack being pinged does not support MPLS 1942 ping, then no reply will be sent, resulting in possible "false 1943 negatives". If in "traceroute" mode, a transit LSR does not support 1944 LSP ping, then no reply will be forthcoming from that LSR for some 1945 TTL, say, n. The LSR originating the echo request SHOULD try sending 1946 the echo request with TTL=n+1, n+2, ..., n+k to probe LSRs further 1947 down the path. In such a case, the echo request for TTL > n SHOULD 1948 be sent with Downstream Mapping TLV "Downstream IP Address" field set 1949 to the ALLROUTERs multicast address until a reply is received with a 1950 Downstream Mapping TLV. The label stack MAY be omitted from the 1951 Downstream Mapping TLV. Furthermore, the "Validate FEC Stack" flag 1952 SHOULD NOT be set until an echo reply packet with a Downstream 1953 Mapping TLV is received. 1955 5. Security Considerations 1957 Overall, the security needs for LSP ping are similar to those of ICMP 1958 ping. 1960 There are at least three approaches to attacking LSRs using the 1961 mechanisms defined here. One is a Denial-of-Service attack, by 1962 sending MPLS echo requests/replies to LSRs and thereby increasing 1963 their workload. The second is obfuscating the state of the MPLS data 1964 plane liveness by spoofing, hijacking, replaying, or otherwise 1965 tampering with MPLS echo requests and replies. The third is an 1966 unauthorized source using an LSP ping to obtain information about the 1967 network. To avoid potential Denial-of-Service attacks, it is 1968 RECOMMENDED that implementations regulate the LSP ping traffic going 1969 to the control plane. A rate limiter SHOULD be applied to the well- 1970 known UDP port defined below. 1972 Unsophisticated replay and spoofing attacks involving faking or 1973 replaying MPLS echo reply messages are unlikely to be effective. 1974 These replies would have to match the Sender's Handle and Sequence 1975 Number of an outstanding MPLS echo request message. A non-matching 1976 replay would be discarded as the sequence has moved on, thus a spoof 1977 has only a small window of opportunity. However, to provide a 1978 stronger defense, an implementation MAY also validate the TimeStamp 1979 Sent by requiring an exact match on this field. 1981 To protect against unauthorized sources using MPLS echo request 1982 messages to obtain network information, it is RECOMMENDED that 1983 implementations provide a means of checking the source addresses of 1984 MPLS echo request messages against an access list before accepting 1985 the message. 1987 It is not clear how to prevent hijacking (non-delivery) of echo 1988 requests or replies; however, if these messages are indeed hijacked, 1989 LSP ping will report that the data plane is not working as it should. 1991 It does not seem vital (at this point) to secure the data carried in 1992 MPLS echo requests and replies, although knowledge of the state of 1993 the MPLS data plane may be considered confidential by some. 1995 Implementations SHOULD, however, provide a means of filtering the 1996 addresses to which echo reply messages may be sent. 1998 Although this document makes special use of 127/8 address, these are 1999 used only in conjunction with the UDP port 3503. Furthermore, these 2000 packets are only processed by routers. All other hosts MUST treat 2001 all packets with a destination address in the range 127/8 in 2002 accordance to RFC 1122. Any packet received by a router with a 2003 destination address in the range 127/8 without a destination UDP port 2004 of 3503 MUST be treated in accordance to RFC 1812. In particular, 2005 the default behavior is to treat packets destined to a 127/8 address 2006 as "martians". 2008 6. IANA Considerations 2010 The TCP and UDP port number 3503 has been allocated by IANA for LSP 2011 echo requests and replies. 2013 The following sections detail the new name spaces to be managed by 2014 IANA. For each of these name spaces, the space is divided into 2015 assignment ranges; the following terms are used in describing the 2016 procedures by which IANA allocates values: "Standards Action" (as 2017 defined in [RFC5226]), "Specification Required", and "Vendor Private 2018 Use". 2020 Values from "Specification Required" ranges MUST be registered with 2021 IANA. The request MUST be made via an Experimental RFC that 2022 describes the format and procedures for using the code point; the 2023 actual assignment is made during the IANA actions for the RFC. 2025 Values from "Vendor Private" ranges MUST NOT be registered with IANA; 2026 however, the message MUST contain an enterprise code as registered 2027 with the IANA SMI Private Network Management Private Enterprise 2028 Numbers. For each name space that has a Vendor Private range, it 2029 must be specified where exactly the SMI Private Enterprise Number 2030 resides; see below for examples. In this way, several enterprises 2031 (vendors) can use the same code point without fear of collision. 2033 6.1. Message Types, Reply Modes, Return Codes 2035 The IANA has created and will maintain registries for Message Types, 2036 Reply Modes, and Return Codes. Each of these can take values in the 2037 range 0-255. Assignments in the range 0-191 are via Standards 2038 Action; assignments in the range 192-251 are made via "Specification 2039 Required"; values in the range 252-255 are for Vendor Private Use, 2040 and MUST NOT be allocated. 2042 If any of these fields fall in the Vendor Private range, a top-level 2043 Vendor Enterprise Number TLV MUST be present in the message. 2045 Message Types defined in this document are the following: 2047 Value Meaning 2048 ----- ------- 2049 1 MPLS echo request 2050 2 MPLS echo reply 2052 Reply Modes defined in this document are the following: 2054 Value Meaning 2055 ----- ------- 2056 1 Do not reply 2057 2 Reply via an IPv4/IPv6 UDP packet 2058 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 2059 4 Reply via application level control channel 2061 Return Codes defined in this document are listed in section 3.1. 2063 6.2. TLVs 2065 The IANA has created and will maintain a registry for the Type field 2066 of top-level TLVs as well as for any associated sub-TLVs. Note the 2067 meaning of a sub-TLV is scoped by the TLV. The number spaces for the 2068 sub-TLVs of various TLVs are independent. 2070 The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the 2071 range 0-16383 and 32768-49161 are made via Standards Action as 2072 defined in [RFC5226]; assignments in the range 16384-31743 and 2073 49162-64511 are made via "Specification Required" as defined above; 2074 values in the range 31744-32767 and 64512-65535 are for Vendor 2075 Private Use, and MUST NOT be allocated. 2077 If a TLV or sub-TLV has a Type that falls in the range for Vendor 2078 Private Use, the Length MUST be at least 4, and the first four octets 2079 MUST be that vendor's SMI Private Enterprise Number, in network octet 2080 order. The rest of the Value field is private to the vendor. TLVs 2081 and sub-TLVs defined in this document are the following: 2083 Type Sub-Type Value Field 2084 ---- -------- ----------- 2085 1 Target FEC Stack 2086 1 LDP IPv4 prefix 2087 2 LDP IPv6 prefix 2088 3 RSVP IPv4 LSP 2089 4 RSVP IPv6 LSP 2090 5 Not Assigned 2091 6 VPN IPv4 prefix 2092 7 VPN IPv6 prefix 2093 8 L2 VPN endpoint 2094 9 "FEC 128" Pseudowire (Deprecated) 2095 10 "FEC 128" Pseudowire 2096 11 "FEC 129" Pseudowire 2097 12 BGP labeled IPv4 prefix 2098 13 BGP labeled IPv6 prefix 2099 14 Generic IPv4 prefix 2100 15 Generic IPv6 prefix 2101 16 Nil FEC 2102 2 Downstream Mapping 2103 3 Pad 2104 4 Not Assigned 2105 5 Vendor Enterprise Number 2106 6 Not Assigned 2107 7 Interface and Label Stack 2108 8 Not Assigned 2109 9 Errored TLVs 2110 Any value The TLV not understood 2111 10 Reply TOS Byte 2113 7. Acknowledgements 2115 The original acknowledgements from RFC 4379 state the following: 2117 This document is the outcome of many discussions among many 2118 people, including Manoj Leelanivas, Paul Traina, Yakov Rekhter, 2119 Der-Hwa Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani 2120 Aggarwal, and Vanson Lim. 2122 The description of the Multipath Information sub-field of the 2123 Downstream Mapping TLV was adapted from text suggested by Curtis 2124 Villamizar. 2126 We would like to thank Loa Andersson for motivating the advancement 2127 of this bis specification. 2129 8. References 2131 8.1. Normative References 2133 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2134 Communication Layers", STD 3, RFC 1122, DOI 10.17487/ 2135 RFC1122, October 1989, 2136 . 2138 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2139 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2140 . 2142 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2143 Requirement Levels", BCP 14, RFC 2119, March 1997. 2145 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 2146 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 2147 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 2148 . 2150 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 2151 Private Network (VPN) Terminology", RFC 4026, DOI 2152 10.17487/RFC4026, March 2005, 2153 . 2155 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2156 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 2157 10.17487/RFC4271, January 2006, 2158 . 2160 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 2161 Label Switched (MPLS) Data Plane Failures", RFC 4379, 2162 February 2006. 2164 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2165 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2166 DOI 10.17487/RFC5226, May 2008, 2167 . 2169 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2170 "Network Time Protocol Version 4: Protocol and Algorithms 2171 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2172 . 2174 8.2. Informative References 2176 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2177 RFC 792, September 1981. 2179 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 2180 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 2181 . 2183 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2184 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2185 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2186 . 2188 [RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP 2189 Virtual Private Networks (VPNs)", RFC 4365, DOI 10.17487/ 2190 RFC4365, February 2006, 2191 . 2193 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 2194 G. Heron, "Pseudowire Setup and Maintenance Using the 2195 Label Distribution Protocol (LDP)", RFC 4447, DOI 2196 10.17487/RFC4447, April 2006, 2197 . 2199 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 2200 LAN Service (VPLS) Using BGP for Auto-Discovery and 2201 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 2202 . 2204 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 2205 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 2206 October 2007, . 2208 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 2209 Connectivity Verification (VCCV): A Control Channel for 2210 Pseudowires", RFC 5085, December 2007. 2212 Authors' Addresses 2214 Carlos Pignataro 2215 Cisco Systems, Inc. 2217 Email: cpignata@cisco.com 2218 Nagendra Kumar 2219 Cisco Systems, Inc. 2221 Email: naikumar@cisco.com 2223 Sam Aldrin 2224 Google 2226 Email: aldrin.ietf@gmail.com 2228 Mach(Guoyi) Chen 2229 Huawei 2231 Email: mach.chen@huawei.com