idnits 2.17.00 (12 Aug 2021) /tmp/idnits12083/draft-ietf-mpls-rfc4379bis-09.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 2 instances 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 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC7537, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 28, 2016) is 2024 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) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) -- Obsolete informational reference (is this intentional?): RFC 6829 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 7537 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella 3 Internet-Draft Juniper Networks, Inc. 4 Obsoletes: 4379, 6424, 6829, 7537 (if G. Swallow 5 approved) C. Pignataro, Ed. 6 Intended status: Standards Track N. Kumar 7 Expires: May 1, 2017 Cisco 8 S. Aldrin 9 Google 10 M. Chen 11 Huawei 12 October 28, 2016 14 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures 15 draft-ietf-mpls-rfc4379bis-09 17 Abstract 19 This document describes a simple and efficient mechanism that can be 20 used to detect data plane failures in Multi-Protocol Label Switching 21 (MPLS) Label Switched Paths (LSPs). There are two parts to this 22 document: information carried in an MPLS "echo request" and "echo 23 reply" for the purposes of fault detection and isolation, and 24 mechanisms for reliably sending the echo reply. 26 This document obsoletes RFCs 4379, 6424, 6829, and 7537. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 1, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.2. Structure of This Document . . . . . . . . . . . . . . . 5 77 1.3. Contributors . . . . . . . . . . . . . . . . . . . . . . 5 78 1.4. Scope of RFC4379bis work . . . . . . . . . . . . . . . . 5 79 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 2.1. Use of Address Range 127/8 . . . . . . . . . . . . . . . 8 81 2.2. Router Alert Option . . . . . . . . . . . . . . . . . . . 9 82 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 9 83 3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 14 84 3.2. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 16 85 3.2.1. LDP IPv4 Prefix . . . . . . . . . . . . . . . . . . . 17 86 3.2.2. LDP IPv6 Prefix . . . . . . . . . . . . . . . . . . . 18 87 3.2.3. RSVP IPv4 LSP . . . . . . . . . . . . . . . . . . . . 18 88 3.2.4. RSVP IPv6 LSP . . . . . . . . . . . . . . . . . . . . 18 89 3.2.5. VPN IPv4 Prefix . . . . . . . . . . . . . . . . . . . 19 90 3.2.6. VPN IPv6 Prefix . . . . . . . . . . . . . . . . . . . 20 91 3.2.7. L2 VPN Endpoint . . . . . . . . . . . . . . . . . . . 20 92 3.2.8. FEC 128 Pseudowire - IPv4 (Deprecated) . . . . . . . 21 93 3.2.9. FEC 128 Pseudowire - IPv4 (Current) . . . . . . . . . 21 94 3.2.10. FEC 129 Pseudowire - IPv4 . . . . . . . . . . . . . . 22 95 3.2.11. FEC 128 Pseudowire - IPv6 . . . . . . . . . . . . . . 23 96 3.2.12. FEC 129 Pseudowire - IPv6 . . . . . . . . . . . . . . 24 97 3.2.13. BGP Labeled IPv4 Prefix . . . . . . . . . . . . . . . 25 98 3.2.14. BGP Labeled IPv6 Prefix . . . . . . . . . . . . . . . 25 99 3.2.15. Generic IPv4 Prefix . . . . . . . . . . . . . . . . . 25 100 3.2.16. Generic IPv6 Prefix . . . . . . . . . . . . . . . . . 26 101 3.2.17. Nil FEC . . . . . . . . . . . . . . . . . . . . . . . 26 102 3.3. Downstream Mapping (Deprecated) . . . . . . . . . . . . . 27 103 3.4. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 27 104 3.4.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 30 105 3.4.2. Downstream Router and Interface . . . . . . . . . . . 37 106 3.5. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . . 38 107 3.6. Vendor Enterprise Number . . . . . . . . . . . . . . . . 38 108 3.7. Interface and Label Stack . . . . . . . . . . . . . . . . 38 109 3.8. Errored TLVs . . . . . . . . . . . . . . . . . . . . . . 40 110 3.9. Reply TOS Octet TLV . . . . . . . . . . . . . . . . . . . 40 111 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 41 112 4.1. Dealing with Equal-Cost Multi-Path (ECMP) . . . . . . . . 41 113 4.2. Testing LSPs That Are Used to Carry MPLS Payloads . . . . 42 114 4.3. Sending an MPLS Echo Request . . . . . . . . . . . . . . 42 115 4.4. Receiving an MPLS Echo Request . . . . . . . . . . . . . 43 116 4.4.1. FEC Validation . . . . . . . . . . . . . . . . . . . 49 117 4.5. Sending an MPLS Echo Reply . . . . . . . . . . . . . . . 50 118 4.5.1. Addition of a New Tunnel . . . . . . . . . . . . . . 51 119 4.5.2. Transition between Tunnels . . . . . . . . . . . . . 52 120 4.6. Receiving an MPLS Echo Reply . . . . . . . . . . . . . . 53 121 4.7. Issue with VPN IPv4 and IPv6 Prefixes . . . . . . . . . . 55 122 4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . . 56 123 5. Security Considerations . . . . . . . . . . . . . . . . . . . 56 124 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 125 6.1. TCP and UDP Port Number . . . . . . . . . . . . . . . . . 58 126 6.2. MPLS LSP Ping Parameters . . . . . . . . . . . . . . . . 58 127 6.2.1. Message Types, Reply Modes, Return Codes . . . . . . 58 128 6.2.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . 59 129 6.2.3. Global Flags . . . . . . . . . . . . . . . . . . . . 60 130 6.2.4. Downstream Detailed Mapping Address Type . . . . . . 61 131 6.2.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . 61 132 6.2.6. Multipath 133 Types . . . . . . . . . . . . . . . . . . . . . . . . 62 134 6.2.7. Pad Type . . . . . . . . . . . . . . . . . . . . . . 62 135 6.2.8. Interface and Label Stack Address Type . . . . . . . 63 136 6.3. IPv4 Special-Purpose Address Registry . . . . . . . . . . 64 137 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64 138 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 139 8.1. Normative References . . . . . . . . . . . . . . . . . . 64 140 8.2. Informative References . . . . . . . . . . . . . . . . . 65 142 Appendix A. Deprecated TLVs and sub-TLVs (Non-normative) . . . . 68 143 A.1. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 68 144 A.1.1. FEC 128 Pseudowire - IPv4 (Deprecated) . . . . . . . 68 145 A.2. Downstream Mapping (Deprecated) . . . . . . . . . . . . . 68 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 148 1. Introduction 150 This document describes a simple and efficient mechanism that can be 151 used to detect data plane failures in MPLS Label Switched Paths 152 (LSPs). There are two parts to this document: information carried in 153 an MPLS "echo request" and "echo reply", and mechanisms for 154 transporting the echo reply. The first part aims at providing enough 155 information to check correct operation of the data plane, as well as 156 a mechanism to verify the data plane against the control plane, and 157 thereby localize faults. The second part suggests two methods of 158 providing reliable reply channels for the echo request message for 159 more robust fault isolation. 161 An important consideration in this design is that MPLS echo requests 162 follow the same data path that normal MPLS packets would traverse. 163 MPLS echo requests are meant primarily to validate the data plane, 164 and secondarily to verify the data plane against the control plane. 165 Mechanisms to check the control plane are valuable, but are not 166 covered in this document. 168 This document makes special use of the address range 127/8. This is 169 an exception to the behavior defined in RFC 1122 [RFC1122] and 170 updates that RFC. The motivation for this change and the details of 171 this exceptional use are discussed in Section 2.1 below. 173 This document obsoletes RFC 4379 [RFC4379], RFC 6424 [RFC6424], RFC 174 6829 [RFC6829], and RFC 7537 [RFC7537]. 176 1.1. Conventions 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in RFC 2119 [RFC2119]. 182 The term "Must Be Zero" (MBZ) is used in object descriptions for 183 reserved fields. These fields MUST be set to zero when sent and 184 ignored on receipt. 186 Terminology pertaining to L2 and L3 Virtual Private Networks (VPNs) 187 is defined in [RFC4026]. 189 Since this document refers to the MPLS Time to Live (TTL) far more 190 frequently than the IP TTL, the authors have chosen the convention of 191 using the unqualified "TTL" to mean "MPLS TTL" and using "IP TTL" for 192 the TTL value in the IP header. 194 1.2. Structure of This Document 196 The body of this memo contains four main parts: motivation, MPLS echo 197 request/reply packet format, LSP ping operation, and a reliable 198 return path. It is suggested that first-time readers skip the actual 199 packet formats and read the Theory of Operation first; the document 200 is structured the way it is to avoid forward references. 202 1.3. Contributors 204 A mechanism used to detect data plane failures in Multi-Protocol 205 Label Switching (MPLS) Label Switched Paths (LSPs) was originally 206 published as RFC 4379 in February 2006. It was produced by the MPLS 207 Working Group of the IETF and was jointly authored by Kireeti 208 Kompella and George Swallow. 210 The following made vital contributions to all aspects of the original 211 RFC 4379, and much of the material came out of debate and discussion 212 among this group. 214 Ronald P. Bonica, Juniper Networks, Inc. 215 Dave Cooper, Global Crossing 216 Ping Pan, Hammerhead Systems 217 Nischal Sheth, Juniper Networks, Inc. 218 Sanjay Wadhwa, Juniper Networks, Inc. 220 1.4. Scope of RFC4379bis work 222 The primary goal of this document is to provide a clean and updated 223 LSP Ping specification. 225 [RFC4379] defines the basic mechanism for MPLS LSP validation that 226 can be used for fault detection and isolation. The scope of this 227 document also is to address various updates to MPLS LSP Ping, 228 including: 230 o Update all references and citations. 232 * Obsoleted RFCs 2434, 2030, and 3036 are respectively replaced 233 with RFCs 5226, 5905, and 5036. 235 * Additionally, these three documents published as RFCs: RFCs 236 4447, 4761, and 5085. 238 o Incorporate all outstanding Errata. 240 * Erratum with IDs: 108, 1418, 1714, 1786, 3399, 742, and 2978. 242 o Replace EXP with Traffic Class (TC), based on the update from RFC 243 5462. 245 o Incorporate the updates from RFC 6829, by adding the pseudowire 246 (PW) Forwarding Equivalence Classes (FECs) advertised over IPv6, 247 and obsoleting RFC 6829. 249 o Incorporate the updates from RFC 7506, by adding IPv6 Router Alert 250 Option for MPLS OAM. 252 o Incorporate newly defined bits on the Global Flags field, from RFC 253 6425 and RFC 6426. 255 o Update the IPv4 addresses used in examples to utilize the 256 documentation prefix. Add examples with IPv6 addresses. 258 o Incorporate the updates from RFC 6424, by deprecating the 259 Downstream Mapping TLV (DSMAP) and adding the Downstream Detailed 260 Mapping TLV (DDMAP), updating two new return codes, adding the 261 motivations of tunneled or stitched LSP, updating the procedures, 262 IANA Considerations Section, Security Considerations, and 263 obsoleting RFC 6424. 265 o Incorporate the updates from RFC 7537, by updating the IANA 266 Considerations Section, and obsoleting RFC 7537. 268 o Finally, obsolete RFC 4379. 270 2. Motivation 272 When an LSP fails to deliver user traffic, the failure cannot always 273 be detected by the MPLS control plane. There is a need to provide a 274 tool that would enable users to detect such traffic "black holes" or 275 misrouting within a reasonable period of time, and a mechanism to 276 isolate faults. 278 In this document, we describe a mechanism that accomplishes these 279 goals. This mechanism is modeled after the ping/traceroute paradigm: 280 ping (ICMP echo request [RFC0792]) is used for connectivity checks, 281 and traceroute is used for hop-by-hop fault localization as well as 282 path tracing. This document specifies a "ping" mode and a 283 "traceroute" mode for testing MPLS LSPs. 285 The basic idea is to verify that packets that belong to a particular 286 Forwarding Equivalence Class (FEC) actually end their MPLS path on a 287 Label Switching Router (LSR) that is an egress for that FEC. This 288 document proposes that this test be carried out by sending a packet 289 (called an "MPLS echo request") along the same data path as other 290 packets belonging to this FEC. An MPLS echo request also carries 291 information about the FEC whose MPLS path is being verified. This 292 echo request is forwarded just like any other packet belonging to 293 that FEC. In "ping" mode (basic connectivity check), the packet 294 should reach the end of the path, at which point it is sent to the 295 control plane of the egress LSR, which then verifies whether it is 296 indeed an egress for the FEC. In "traceroute" mode (fault 297 isolation), the packet is sent to the control plane of each transit 298 LSR, which performs various checks that it is indeed a transit LSR 299 for this path; this LSR also returns further information that helps 300 check the control plane against the data plane, i.e., that forwarding 301 matches what the routing protocols determined as the path. 303 An LSP traceroute may cross a tunneled or stitched LSP en route to 304 the destination. While performing end-to-end LSP validation in such 305 scenarios, the FEC information included in the packet by Initiator 306 may be different from the one assigned by transit node in different 307 segment of a stitched LSP or tunnel. Let us consider a simple case. 309 A B C D E 310 o -------- o -------- o --------- o --------- o 311 \_____/ | \______/ \______/ | \______/ 312 LDP | RSVP RSVP | LDP 313 | | 314 \____________________/ 315 LDP 317 When an LSP traceroute is initiated from Router A to Router E, the 318 FEC information included in the packet will be LDP while Router C 319 along the path is a pure RSVP node and does not run LDP. 320 Consequently, node C will be unable to perform FEC validation. The 321 MPLS echo request should contain sufficient information to allow any 322 transit node within stitched or tunneled LSP to perform FEC 323 validations to detect any misrouted echo request. 325 One way these tools can be used is to periodically ping an FEC to 326 ensure connectivity. If the ping fails, one can then initiate a 327 traceroute to determine where the fault lies. One can also 328 periodically traceroute FECs to verify that forwarding matches the 329 control plane; however, this places a greater burden on transit LSRs 330 and thus should be used with caution. 332 2.1. Use of Address Range 127/8 334 As described above, LSP ping is intended as a diagnostic tool. It is 335 intended to enable providers of an MPLS-based service to isolate 336 network faults. In particular, LSP ping needs to diagnose situations 337 where the control and data planes are out of sync. It performs this 338 by routing an MPLS echo request packet based solely on its label 339 stack. That is, the IP destination address is never used in a 340 forwarding decision. In fact, the sender of an MPLS echo request 341 packet may not know, a priori, the address of the router at the end 342 of the LSP. 344 Providers of MPLS-based services also need the ability to trace all 345 of the possible paths that an LSP may take. Since most MPLS services 346 are based on IP unicast forwarding, these paths are subject to equal- 347 cost multi-path (ECMP) load sharing. 349 This leads to the following requirements: 351 1. Although the LSP in question may be broken in unknown ways, the 352 likelihood of a diagnostic packet being delivered to a user of an 353 MPLS service MUST be held to an absolute minimum. 355 2. If an LSP is broken in such a way that it prematurely terminates, 356 the diagnostic packet MUST NOT be IP forwarded. 358 3. A means of varying the diagnostic packets such that they exercise 359 all ECMP paths is thus REQUIRED. 361 Clearly, using general unicast addresses satisfies neither of the 362 first two requirements. A number of other options for addresses were 363 considered, including a portion of the private address space (as 364 determined by the network operator) and the IPv4 link local 365 addresses. Use of the private address space was deemed ineffective 366 since the leading MPLS-based service is an IPv4 Virtual Private 367 Network (VPN). VPNs often use private addresses. 369 The IPv4 link local addresses are more attractive in that the scope 370 over which they can be forwarded is limited. However, if one were to 371 use an address from this range, it would still be possible for the 372 first recipient of a diagnostic packet that "escaped" from a broken 373 LSP to have that address assigned to the interface on which it 374 arrived and thus could mistakenly receive such a packet. Older 375 deployed routers may not (correctly) implement IPv4 link local 376 addresses and would forward a packet with an address from that range 377 toward the default route. 379 The 127/8 range for IPv4 and that same range embedded in an 380 IPv4-mapped IPv6 addresses for IPv6 was chosen for a number of 381 reasons. 383 RFC 1122 allocates the 127/8 as "Internal host loopback address" and 384 states: "Addresses of this form MUST NOT appear outside a host." 385 Thus, the default behavior of hosts is to discard such packets. This 386 helps to ensure that if a diagnostic packet is misdirected to a host, 387 it will be silently discarded. 389 RFC 1812 [RFC1812] states: 391 A router SHOULD NOT forward, except over a loopback interface, any 392 packet that has a destination address on network 127. A router 393 MAY have a switch that allows the network manager to disable these 394 checks. If such a switch is provided, it MUST default to 395 performing the checks. 397 This helps to ensure that diagnostic packets are never IP forwarded. 399 The 127/8 address range provides 16M addresses allowing wide 400 flexibility in varying addresses to exercise ECMP paths. Finally, as 401 an implementation optimization, the 127/8 provides an easy means of 402 identifying possible LSP packets. 404 2.2. Router Alert Option 406 This document requires the use of the Router Alert Option (RAO) set 407 in IP header in order to have the transit node process the MPLS OAM 408 payload. 410 [RFC2113] defines a generic Option Value 0x0 for IPv4 RAO that alerts 411 transit router to examine the IPv4 packet. [RFC7506] defines MPLS 412 OAM Option Value 69 for IPv6 RAO to alert transit routers to examine 413 the IPv6 packet more closely for MPLS OAM purposes. 415 The use of the Router Alert IP Option in this document is as follows: 417 In case of an IPv4 header, the generic IPv4 RAO value 0x0 418 [RFC2113] SHOULD be used. In case of an IPv6 header, the IPv6 RAO 419 value (69) for MPLS OAM [RFC7506] MUST be used. 421 3. Packet Format 423 An MPLS echo request/reply is a (possibly labeled) IPv4 or IPv6 UDP 424 packet; the contents of the UDP packet have the following format: 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Version Number | Global Flags | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Message Type | Reply mode | Return Code | Return Subcode| 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Sender's Handle | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Sequence Number | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | TimeStamp Sent (seconds) | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | TimeStamp Sent (seconds fraction) | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | TimeStamp Received (seconds) | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | TimeStamp Received (seconds fraction) | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | TLVs ... | 446 . . 447 . . 448 . . 449 | | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 The Version Number is currently 1. (Note: the version number is to 453 be incremented whenever a change is made that affects the ability of 454 an implementation to correctly parse or process an MPLS echo request/ 455 reply. These changes include any syntactic or semantic changes made 456 to any of the fixed fields, or to any Type-Length-Value (TLV) or sub- 457 TLV assignment or format that is defined at a certain version number. 458 The version number may not need to be changed if an optional TLV or 459 sub-TLV is added.) 461 The Global Flags field is a bit vector with the following format: 463 0 1 464 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | MBZ |R|T|V| 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 At the time of writing three flags are defined, the R, T, and V bits; 470 the rest MUST be set to zero when sending and ignored on receipt. 472 The V (Validate FEC Stack) flag is set to 1 if the sender wants the 473 receiver to perform FEC Stack validation; if V is 0, the choice is 474 left to the receiver. 476 The T (Respond Only If TTL Expired) flag MUST be set only in the echo 477 request packet by the sender. If the T flag is set to 1 in an 478 incoming echo request, and the TTL of the incoming MPLS label is more 479 than 1, then the receiving node MUST drop the incoming echo request 480 and MUST NOT send any echo reply to the sender. This flag MUST NOT 481 be set in the echo reply packet. If this flag is set in an echo 482 reply packet, then it MUST be ignored. The T flag is defined in 483 Section 3.4 of [RFC6425]. 485 The R (Validate Reverse Path) flag is defined in [RFC6426]. When 486 this flag is set in the echo request, the Responder SHOULD return 487 reverse-path FEC information, as described in Section 3.4.2 of 488 [RFC6426]. 490 The Message Type is one of the following: 492 Value Meaning 493 ----- ------- 494 1 MPLS echo request 495 2 MPLS echo reply 497 The Reply Mode can take one of the following values: 499 Value Meaning 500 ----- ------- 501 1 Do not reply 502 2 Reply via an IPv4/IPv6 UDP packet 503 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 504 4 Reply via application level control channel 506 An MPLS echo request with 1 (Do not reply) in the Reply Mode field 507 may be used for one-way connectivity tests; the receiving router may 508 log gaps in the Sequence Numbers and/or maintain delay/jitter 509 statistics. An MPLS echo request would normally have 2 (Reply via an 510 IPv4/IPv6 UDP packet) in the Reply Mode field. If the normal IP 511 return path is deemed unreliable, one may use 3 (Reply via an IPv4/ 512 IPv6 UDP packet with Router Alert). Note that this requires that all 513 intermediate routers understand and know how to forward MPLS echo 514 replies. The echo reply uses the same IP version number as the 515 received echo request, i.e., an IPv4 encapsulated echo reply is sent 516 in response to an IPv4 encapsulated echo request. 518 Some applications support an IP control channel. One such example is 519 the associated control channel defined in Virtual Circuit 520 Connectivity Verification (VCCV) [RFC5085]. Any application that 521 supports an IP control channel between its control entities may set 522 the Reply Mode to 4 (Reply via application level control channel) to 523 ensure that replies use that same channel. Further definition of 524 this codepoint is application specific and thus beyond the scope of 525 this document. 527 Return Codes and Subcodes are described in Section 3.1. 529 The Sender's Handle is filled in by the sender, and returned 530 unchanged by the receiver in the echo reply (if any). There are no 531 semantics associated with this handle, although a sender may find 532 this useful for matching up requests with replies. 534 The Sequence Number is assigned by the sender of the MPLS echo 535 request and can be (for example) used to detect missed replies. 537 The TimeStamp Sent is the time-of-day (according to the sender's 538 clock) in 64-bit NTP Timestamp format [RFC5905] when the MPLS echo 539 request is sent. The TimeStamp Received in an echo reply is the 540 time-of-day (according to the receiver's clock) in 64-bit NTP 541 Timestamp format that the corresponding echo request was received. 543 TLVs (Type-Length-Value tuples) have the following format: 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Type | Length | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Value | 551 . . 552 . . 553 . . 554 | | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Types are defined below; Length is the length of the Value field in 558 octets. The Value field depends on the Type; it is zero padded to 559 align to a 4-octet boundary. TLVs may be nested within other TLVs, 560 in which case the nested TLVs are called sub-TLVs. Sub-TLVs have 561 independent types and MUST also be 4-octet aligned. 563 Two examples of how TLV and sub-TLV length are computed, and of how 564 sub-TLVs are padded to be 4-octet aligned as follows: 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type = 1 (LDP IPv4 FEC) | Length = 5 | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | IPv4 prefix | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Prefix Length | Must Be Zero | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 The Length for this TLV is 5. A Target FEC Stack TLV that contains 577 an LDP IPv4 FEC sub-TLV and a VPN IPv4 prefix sub-TLV has the 578 following format: 580 0 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Type = 1 (FEC TLV) | Length = 32 | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | sub-Type = 1 (LDP IPv4 FEC) | Length = 5 | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | IPv4 prefix | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Prefix Length | Must Be Zero | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | sub-Type = 6 (VPN IPv4 prefix)| Length = 13 | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Route Distinguisher | 594 | (8 octets) | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | IPv4 prefix | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Prefix Length | Must Be Zero | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 A description of the Types and Values of the top-level TLVs for LSP 602 ping are given below: 604 Type # Value Field 605 ------ ----------- 606 1 Target FEC Stack 607 2 Downstream Mapping (Deprecated) 608 3 Pad 609 4 Unassigned 610 5 Vendor Enterprise Number 611 6 Unassigned 612 7 Interface and Label Stack 613 8 Unassigned 614 9 Errored TLVs 615 10 Reply TOS Byte 616 20 Downstream Detailed Mapping 618 Types less than 32768 (i.e., with the high-order bit equal to 0) are 619 mandatory TLVs that MUST either be supported by an implementation or 620 result in the return code of 2 ("One or more of the TLVs was not 621 understood") being sent in the echo response. 623 Types greater than or equal to 32768 (i.e., with the high-order bit 624 equal to 1) are optional TLVs that SHOULD be ignored if the 625 implementation does not understand or support them. 627 In Section 3.2 through Section 3.9 and their various subsections, 628 only the Value field of the TLV is included. 630 3.1. Return Codes 632 The Return Code is set to zero by the sender of an Echo Request. The 633 receiver of said Echo Request can set it to one of the values listed 634 below in the corresponding Echo Reply that it generates. The 635 notation refers to the Return Subcode. This field is filled in 636 with the stack-depth for those codes that specify that. For all 637 other codes, the Return Subcode MUST be set to zero. 639 Value Meaning 640 ----- ------- 641 0 No return code 642 1 Malformed echo request received 643 2 One or more of the TLVs was not understood 644 3 Replying router is an egress for the FEC at stack- 645 depth 646 4 Replying router has no mapping for the FEC at stack- 647 depth 648 5 Downstream Mapping Mismatch (See Note 1) 649 6 Upstream Interface Index Unknown (See Note 1) 650 7 Reserved 651 8 Label switched at stack-depth 652 9 Label switched but no MPLS forwarding at stack-depth 653 654 10 Mapping for this FEC is not the given label at stack- 655 depth 656 11 No label entry at stack-depth 657 12 Protocol not associated with interface at FEC stack- 658 depth 659 13 Premature termination of ping due to label stack 660 shrinking to a single label 661 14 See DDMAP TLV for Return Code and Return Subcode 662 (See Note 2) 663 15 Label switched with FEC change 665 Note 1 667 The Return Subcode contains the point in the label stack where 668 processing was terminated. If the RSC is 0, no labels were 669 processed. Otherwise the packet would have been label switched at 670 depth RSC. 672 Note 2 674 The Return Code is per Downstream Detailed Mapping TLV 675 (Section 3.4). This Return Code MUST be used only in the message 676 header and MUST be set only in the MPLS echo reply message. If 677 the Return Code is set in the MPLS echo request message, then it 678 MUST be ignored. When this Return Code is set, each Downstream 679 Detailed Mapping TLV MUST have an appropriate Return Code and 680 Return Subcode. This Return Code MUST be used when there are 681 multiple downstreams for a given node (such as Point to Multipoint 682 (P2MP) or Equal Cost Multi-Path (ECMP)), and the node needs to 683 return a Return Code/Return Subcode for each downstream. This 684 Return Code MAY be used even when there is only one downstream for 685 a given node. 687 3.2. Target FEC Stack 689 A Target FEC Stack is a list of sub-TLVs. The number of elements is 690 determined by looking at the sub-TLV length fields. 692 Sub-Type Length Value Field 693 -------- ------ ----------- 694 1 5 LDP IPv4 prefix 695 2 17 LDP IPv6 prefix 696 3 20 RSVP IPv4 LSP 697 4 56 RSVP IPv6 LSP 698 5 Unassigned 699 6 13 VPN IPv4 prefix 700 7 25 VPN IPv6 prefix 701 8 14 L2 VPN endpoint 702 9 10 "FEC 128" Pseudowire - IPv4 (deprecated) 703 10 14 "FEC 128" Pseudowire - IPv4 704 11 16+ "FEC 129" Pseudowire - IPv4 705 12 5 BGP labeled IPv4 prefix 706 13 17 BGP labeled IPv6 prefix 707 14 5 Generic IPv4 prefix 708 15 17 Generic IPv6 prefix 709 16 4 Nil FEC 710 24 38 "FEC 128" Pseudowire - IPv6 711 25 40+ "FEC 129" Pseudowire - IPv6 713 Other FEC Types will be defined as needed. 715 Note that this TLV defines a stack of FECs, the first FEC element 716 corresponding to the top of the label stack, etc. 718 An MPLS echo request MUST have a Target FEC Stack that describes the 719 FEC Stack being tested. For example, if an LSR X has an LDP mapping 720 [RFC5036] for 192.0.2.1 (say, label 1001), then to verify that label 721 1001 does indeed reach an egress LSR that announced this prefix via 722 LDP, X can send an MPLS echo request with an FEC Stack TLV with one 723 FEC in it, namely, of type LDP IPv4 prefix, with prefix 192.0.2.1/32, 724 and send the echo request with a label of 1001. 726 Say LSR X wanted to verify that a label stack of <1001, 23456> is the 727 right label stack to use to reach a VPN IPv4 prefix [see 728 Section 3.2.5] of 203.0.113.0/24 in VPN foo. Say further that LSR Y 729 with loopback address 192.0.2.1 announced prefix 203.0.113.0/24 with 730 Route Distinguisher RD-foo-Y (which may in general be different from 731 the Route Distinguisher that LSR X uses in its own advertisements for 732 VPN foo), label 23456 and BGP next hop 192.0.2.1 [RFC4271]. Finally, 733 suppose that LSR X receives a label binding of 1001 for 192.0.2.1 via 734 LDP. X has two choices in sending an MPLS echo request: X can send 735 an MPLS echo request with an FEC Stack TLV with a single FEC of type 736 VPN IPv4 prefix with a prefix of 203.0.113.0/24 and a Route 737 Distinguisher of RD-foo-Y. Alternatively, X can send an FEC Stack 738 TLV with two FECs, the first of type LDP IPv4 with a prefix of 739 192.0.2.1/32 and the second of type of IP VPN with a prefix 740 203.0.113.0/24 with Route Distinguisher of RD-foo-Y. In either case, 741 the MPLS echo request would have a label stack of <1001, 23456>. 742 (Note: in this example, 1001 is the "outer" label and 23456 is the 743 "inner" label.) 745 If, for example, an LSR Y has an LDP mapping for the IPv6 address 746 2001:db8::1 (say, label 2001), then to verify that label 2001 does 747 reach an egress LSR that announced this prefix via LDP, LSR Y can 748 send an MPLS echo request with an FEC Stack TLV with one LDP IPv6 749 prefix FEC, with prefix 2001:db8::1/128, and with a label of 2001. 751 If an end-to-end path comprises of one or more tunneled or stitched 752 LSPs, each transit node that is the originating point of a new tunnel 753 or segment SHOULD reply back notifying the FEC stack change along 754 with the new FEC details. For example, if LSR X has an LDP mapping 755 for IPv4 prefix 192.0.2.10 on LSR Z (say, label 3001). Say further 756 that LSR A and LSR B are transit nodes along the path which also have 757 an RSVP tunnel over which LDP is enabled. While replying back, A 758 SHOULD notify that the FEC changes from LDP to . If the 759 new tunnel is a transparent pipe, i.e., the data-plane trace will not 760 expire in the middle of the tunnel, then the transit node SHOULD NOT 761 reply back notifying the FEC stack change or the new FEC details. If 762 the transit node wishes to hide the nature of the tunnel from the 763 ingress of the echo request, then the transit node MAY notify the FEC 764 stack change and include Nil FEC as the new FEC. 766 3.2.1. LDP IPv4 Prefix 768 The IPv4 Prefix FEC is defined in [RFC5036]. When an LDP IPv4 prefix 769 is encoded in a label stack, the following format is used. The value 770 consists of 4 octets of an IPv4 prefix followed by 1 octet of prefix 771 length in bits; the format is given below. The IPv4 prefix is in 772 network byte order; if the prefix is shorter than 32 bits, trailing 773 bits SHOULD be set to zero. See [RFC5036] for an example of a 774 Mapping for an IPv4 FEC. 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | IPv4 prefix | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Prefix Length | Must Be Zero | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 3.2.2. LDP IPv6 Prefix 786 The IPv6 Prefix FEC is defined in [RFC5036]. When an LDP IPv6 prefix 787 is encoded in a label stack, the following format is used. The value 788 consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix 789 length in bits; the format is given below. The IPv6 prefix is in 790 network byte order; if the prefix is shorter than 128 bits, the 791 trailing bits SHOULD be set to zero. See [RFC5036] for an example of 792 a Mapping for an IPv6 FEC. 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | IPv6 prefix | 798 | (16 octets) | 799 | | 800 | | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Prefix Length | Must Be Zero | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 3.2.3. RSVP IPv4 LSP 807 The value has the format below. The value fields are taken from RFC 808 3209, Sections 4.6.1.1 and 4.6.2.1. See [RFC3209]. 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | IPv4 tunnel end point address | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Must Be Zero | Tunnel ID | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Extended Tunnel ID | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | IPv4 tunnel sender address | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Must Be Zero | LSP ID | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 3.2.4. RSVP IPv6 LSP 826 The value has the format below. The value fields are taken from RFC 827 3209, Sections 4.6.1.2 and 4.6.2.2. See [RFC3209]. 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 | IPv6 tunnel end point address | 833 | | 834 | | 835 | | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Must Be Zero | Tunnel ID | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Extended Tunnel ID | 840 | | 841 | | 842 | | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | IPv6 tunnel sender address | 845 | | 846 | | 847 | | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Must Be Zero | LSP ID | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 3.2.5. VPN IPv4 Prefix 854 VPN-IPv4 Network Layer Routing Information (NLRI) is defined in 855 [RFC4365]. This document uses the term VPN IPv4 prefix for a VPN- 856 IPv4 NLRI that has been advertised with an MPLS label in BGP. See 857 [RFC3107]. 859 When a VPN IPv4 prefix is encoded in a label stack, the following 860 format is used. The value field consists of the Route Distinguisher 861 advertised with the VPN IPv4 prefix, the IPv4 prefix (with trailing 0 862 bits to make 32 bits in all), and a prefix length, as follows: 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Route Distinguisher | 868 | (8 octets) | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | IPv4 prefix | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Prefix Length | Must Be Zero | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 The Route Distinguisher (RD) is an 8-octet identifier; it does not 876 contain any inherent information. The purpose of the RD is solely to 877 allow one to create distinct routes to a common IPv4 address prefix. 878 The encoding of the RD is not important here. When matching this 879 field to the local FEC information, it is treated as an opaque value. 881 3.2.6. VPN IPv6 Prefix 883 VPN-IPv6 Network Layer Routing Information (NLRI) is defined in 884 [RFC4365]. This document uses the term VPN IPv6 prefix for a VPN- 885 IPv6 NLRI that has been advertised with an MPLS label in BGP. See 886 [RFC3107]. 888 When a VPN IPv6 prefix is encoded in a label stack, the following 889 format is used. The value field consists of the Route Distinguisher 890 advertised with the VPN IPv6 prefix, the IPv6 prefix (with trailing 0 891 bits to make 128 bits in all), and a prefix length, as follows: 893 0 1 2 3 894 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 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Route Distinguisher | 897 | (8 octets) | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | IPv6 prefix | 900 | | 901 | | 902 | | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Prefix Length | Must Be Zero | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 The Route Distinguisher is identical to the VPN IPv4 Prefix RD, 908 except that it functions here to allow the creation of distinct 909 routes to IPv6 prefixes. See Section 3.2.5. When matching this 910 field to local FEC information, it is treated as an opaque value. 912 3.2.7. L2 VPN Endpoint 914 VPLS stands for Virtual Private LAN Service. The terms VPLS BGP NLRI 915 and VE ID (VPLS Edge Identifier) are defined in [RFC4761]. This 916 document uses the simpler term L2 VPN endpoint when referring to a 917 VPLS BGP NLRI. The Route Distinguisher is an 8-octet identifier used 918 to distinguish information about various L2 VPNs advertised by a 919 node. The VE ID is a 2-octet identifier used to identify a 920 particular node that serves as the service attachment point within a 921 VPLS. The structure of these two identifiers is unimportant here; 922 when matching these fields to local FEC information, they are treated 923 as opaque values. The encapsulation type is identical to the PW Type 924 in Section 3.2.9. 926 When an L2 VPN endpoint is encoded in a label stack, the following 927 format is used. The value field consists of a Route Distinguisher (8 928 octets), the sender (of the ping)'s VE ID (2 octets), the receiver's 929 VE ID (2 octets), and an encapsulation type (2 octets), formatted as 930 follows: 932 0 1 2 3 933 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 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Route Distinguisher | 936 | (8 octets) | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Sender's VE ID | Receiver's VE ID | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Encapsulation Type | Must Be Zero | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 3.2.8. FEC 128 Pseudowire - IPv4 (Deprecated) 945 See Appendix A.1.1 for details 947 3.2.9. FEC 128 Pseudowire - IPv4 (Current) 949 FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID 950 (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero 951 32-bit connection ID. The PW Type is a 15-bit number indicating the 952 encapsulation type. It is carried right justified in the field below 953 termed encapsulation type with the high-order bit set to zero. 955 Both of these fields are treated in this protocol as opaque values. 956 When matching these field to the local FEC information, the match 957 MUST be exact. 959 When an FEC 128 is encoded in a label stack, the following format is 960 used. The value field consists of the Sender's Provider Edge (PE) 961 IPv4 Address (the source address of the targeted LDP session), the 962 Remote PE IPv4 Address (the destination address of the targeted LDP 963 session), the PW ID, and the encapsulation type as follows: 965 0 1 2 3 966 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 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Sender's PE IPv4 Address | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Remote PE IPv4 Address | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | PW ID | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | PW Type | Must Be Zero | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 3.2.10. FEC 129 Pseudowire - IPv4 979 FEC 129 (0x81) and the terms PW Type, Attachment Group Identifier 980 (AGI), Attachment Group Identifier Type (AGI Type), Attachment 981 Individual Identifier Type (AII Type), Source Attachment Individual 982 Identifier (SAII), and Target Attachment Individual Identifier (TAII) 983 are defined in [RFC4447]. The PW Type is a 15-bit number indicating 984 the encapsulation type. It is carried right justified in the field 985 below PW Type with the high-order bit set to zero. All the other 986 fields are treated as opaque values and copied directly from the FEC 987 129 format. All of these values together uniquely define the FEC 988 within the scope of the LDP session identified by the source and 989 remote PE IPv4 addresses. 991 When an FEC 129 is encoded in a label stack, the following format is 992 used. The Length of this TLV is 16 + AGI length + SAII length + TAII 993 length. Padding is used to make the total length a multiple of 4; 994 the length of the padding is not included in the Length field. 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 | Sender's PE IPv4 Address | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | Remote PE IPv4 Address | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | PW Type | AGI Type | AGI Length | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 ~ AGI Value ~ 1006 | | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | AII Type | SAII Length | SAII Value | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 ~ SAII Value (continued) ~ 1011 | | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | AII Type | TAII Length | TAII Value | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 ~ TAII Value (continued) ~ 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | TAII (cont.) | 0-3 octets of zero padding | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 3.2.11. FEC 128 Pseudowire - IPv6 1022 The FEC 128 Pseudowire IPv6 sub-TLV has a structure consistent with 1023 the FEC 128 Pseudowire IPv4 sub-TLV as described in Section 3.2.9. 1024 The value field consists of the Sender's PE IPv6 Address (the source 1025 address of the targeted LDP session), the Remote PE IPv6 Address (the 1026 destination address of the targeted LDP session), the PW ID, and the 1027 encapsulation type as follows: 1029 0 1 2 3 1030 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 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 ~ Sender's PE IPv6 Address ~ 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 ~ Remote PE IPv6 Address ~ 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | PW ID | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | PW Type | Must Be Zero | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 Sender's PE IPv6 Address: The source IP address of the target IPv6 1042 LDP session. 16 octets. 1044 Remote PE IPv6 Address: The destination IP address of the target IPv6 1045 LDP session. 16 octets. 1047 PW ID: Same as FEC 128 Pseudowire IPv4 in Section 3.2.9. 1049 PW Type: Same as FEC 128 Pseudowire IPv4 in Section 3.2.9. 1051 3.2.12. FEC 129 Pseudowire - IPv6 1053 The FEC 129 Pseudowire IPv6 sub-TLV has a structure consistent with 1054 the FEC 129 Pseudowire IPv4 sub-TLV as described in Section 3.2.10. 1055 When an FEC 129 is encoded in a label stack, the following format is 1056 used. The length of this TLV is 40 + AGI (Attachment Group 1057 Identifier) length + SAII (Source Attachment Individual Identifier) 1058 length + TAII (Target Attachment Individual Identifier) length. 1059 Padding is used to make the total length a multiple of 4; the length 1060 of the padding is not included in the Length field. 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 ~ Sender's PE IPv6 Address ~ 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 ~ Remote PE IPv6 Address ~ 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | PW Type | AGI Type | AGI Length | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 ~ AGI Value ~ 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | AII Type | SAII Length | SAII Value | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 ~ SAII Value (continued) ~ 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | AII Type | TAII Length | TAII Value | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 ~ TAII Value (continued) ~ 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | TAII (cont.) | 0-3 octets of zero padding | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 Sender's PE IPv6 Address: The source IP address of the target IPv6 1085 LDP session. 16 octets. 1087 Remote PE IPv6 Address: The destination IP address of the target IPv6 1088 LDP session. 16 octets. 1090 The other fields are the same as FEC 129 Pseudowire IPv4 in 1091 Section 3.2.10. 1093 3.2.13. BGP Labeled IPv4 Prefix 1095 BGP labeled IPv4 prefixes are defined in [RFC3107]. When a BGP 1096 labeled IPv4 prefix is encoded in a label stack, the following format 1097 is used. The value field consists the IPv4 prefix (with trailing 0 1098 bits to make 32 bits in all), and the prefix length, as follows: 1100 0 1 2 3 1101 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 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | IPv4 Prefix | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Prefix Length | Must Be Zero | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 3.2.14. BGP Labeled IPv6 Prefix 1110 BGP labeled IPv6 prefixes are defined in [RFC3107]. When a BGP 1111 labeled IPv6 prefix is encoded in a label stack, the following format 1112 is used. The value consists of 16 octets of an IPv6 prefix followed 1113 by 1 octet of prefix length in bits; the format is given below. The 1114 IPv6 prefix is in network byte order; if the prefix is shorter than 1115 128 bits, the trailing bits SHOULD be set to zero. 1117 0 1 2 3 1118 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 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | IPv6 prefix | 1121 | (16 octets) | 1122 | | 1123 | | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Prefix Length | Must Be Zero | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 3.2.15. Generic IPv4 Prefix 1130 The value consists of 4 octets of an IPv4 prefix followed by 1 octet 1131 of prefix length in bits; the format is given below. The IPv4 prefix 1132 is in network byte order; if the prefix is shorter than 32 bits, 1133 trailing bits SHOULD be set to zero. This FEC is used if the 1134 protocol advertising the label is unknown or may change during the 1135 course of the LSP. An example is an inter-AS LSP that may be 1136 signaled by LDP in one Autonomous System (AS), by RSVP-TE [RFC3209] 1137 in another AS, and by BGP between the ASes, such as is common for 1138 inter-AS VPNs. 1140 0 1 2 3 1141 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 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | IPv4 prefix | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Prefix Length | Must Be Zero | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 3.2.16. Generic IPv6 Prefix 1150 The value consists of 16 octets of an IPv6 prefix followed by 1 octet 1151 of prefix length in bits; the format is given below. The IPv6 prefix 1152 is in network byte order; if the prefix is shorter than 128 bits, the 1153 trailing bits SHOULD be set to zero. 1155 0 1 2 3 1156 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 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | IPv6 prefix | 1159 | (16 octets) | 1160 | | 1161 | | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | Prefix Length | Must Be Zero | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 3.2.17. Nil FEC 1168 At times, labels from the reserved range, e.g., Router Alert and 1169 Explicit-null, may be added to the label stack for various diagnostic 1170 purposes such as influencing load-balancing. These labels may have 1171 no explicit FEC associated with them. The Nil FEC Stack is defined 1172 to allow a Target FEC Stack sub-TLV to be added to the Target FEC 1173 Stack to account for such labels so that proper validation can still 1174 be performed. 1176 The Length is 4. Labels are 20-bit values treated as numbers. 1178 0 1 2 3 1179 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 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Label | MBZ | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 Label is the actual label value inserted in the label stack; the MBZ 1185 fields MUST be zero when sent and ignored on receipt. 1187 3.3. Downstream Mapping (Deprecated) 1189 See Appendix A.2 for more details. 1191 3.4. Downstream Detailed Mapping TLV 1193 The Downstream Detailed Mapping object is a TLV that MAY be included 1194 in an MPLS echo request message. Only one Downstream Detailed 1195 Mapping object may appear in an echo request. The presence of a 1196 Downstream Detailed Mapping object is a request that Downstream 1197 Detailed Mapping objects be included in the MPLS echo reply. If the 1198 replying router is the destination (Label Edge Router) of the FEC, 1199 then a Downstream Detailed Mapping TLV SHOULD NOT be included in the 1200 MPLS echo reply. Otherwise, the replying router SHOULD include a 1201 Downstream Detailed Mapping object for each interface over which this 1202 FEC could be forwarded. For a more precise definition of the notion 1203 of "downstream", see Section 3.4.2, "Downstream Router and 1204 Interface". 1206 0 1 2 3 1207 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 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | MTU | Address Type | DS Flags | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 | Downstream Address (4 or 16 octets) | 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | Downstream Interface Address (4 or 16 octets) | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Return Code | Return Subcode| Sub-tlv Length | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 . . 1218 . List of Sub-TLVs . 1219 . . 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 The Downstream Detailed Mapping TLV format is derived from the 1223 deprecated Downstream Mapping TLV format (see Appendix A.2.) The key 1224 change is that variable length and optional fields have been 1225 converted into sub-TLVs. 1227 Maximum Transmission Unit (MTU) 1229 The MTU is the size in octets of the largest MPLS frame (including 1230 label stack) that fits on the interface to the Downstream Label 1231 Switching Router (LSR). 1233 Address Type 1234 The Address Type indicates if the interface is numbered or 1235 unnumbered. It also determines the length of the Downstream IP 1236 Address and Downstream Interface fields. The Address Type is set 1237 to one of the following values: 1239 Type # Address Type 1240 ------ ------------ 1241 1 IPv4 Numbered 1242 2 IPv4 Unnumbered 1243 3 IPv6 Numbered 1244 4 IPv6 Unnumbered 1246 DS Flags 1248 The DS Flags field is a bit vector of various flags with the 1249 following format: 1251 0 1 2 3 4 5 6 7 1252 +-+-+-+-+-+-+-+-+ 1253 | Rsvd(MBZ) |I|N| 1254 +-+-+-+-+-+-+-+-+ 1256 Two flags are defined currently, I and N. The remaining flags 1257 MUST be set to zero when sending and ignored on receipt. 1259 Flag Name and Meaning 1260 ---- ---------------- 1261 I Interface and Label Stack Object Request 1263 When this flag is set, it indicates that the replying 1264 router SHOULD include an Interface and Label Stack 1265 Object in the echo reply message. 1267 N Treat as a Non-IP Packet 1269 Echo request messages will be used to diagnose non-IP 1270 flows. However, these messages are carried in IP 1271 packets. For a router that alters its ECMP algorithm 1272 based on the FEC or deep packet examination, this flag 1273 requests that the router treat this as it would if the 1274 determination of an IP payload had failed. 1276 Downstream Address and Downstream Interface Address 1278 IPv4 addresses and interface indices are encoded in 4 octets; IPv6 1279 addresses are encoded in 16 octets. 1281 If the interface to the downstream LSR is numbered, then the 1282 Address Type MUST be set to IPv4 or IPv6, the Downstream Address 1283 MUST be set to either the downstream LSR's Router ID or the 1284 interface address of the downstream LSR, and the Downstream 1285 Interface Address MUST be set to the downstream LSR's interface 1286 address. 1288 If the interface to the downstream LSR is unnumbered, the Address 1289 Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream 1290 Address MUST be the downstream LSR's Router ID, and the Downstream 1291 Interface Address MUST be set to the index assigned by the 1292 upstream LSR to the interface. 1294 If an LSR does not know the IP address of its neighbor, then it 1295 MUST set the Address Type to either IPv4 Unnumbered or IPv6 1296 Unnumbered. For IPv4, it must set the Downstream Address to 1297 127.0.0.1; for IPv6 the address is set to 0::1. In both cases, 1298 the interface index MUST be set to 0. If an LSR receives an Echo 1299 Request packet with either of these addresses in the Downstream 1300 Address field, this indicates that it MUST bypass interface 1301 verification but continue with label validation. 1303 If the originator of an Echo Request packet wishes to obtain 1304 Downstream Detailed Mapping information but does not know the 1305 expected label stack, then it SHOULD set the Address Type to 1306 either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set 1307 the Downstream Address to 224.0.0.2; for IPv6 the address MUST be 1308 set to FF02::2. In both cases, the interface index MUST be set to 1309 0. If an LSR receives an Echo Request packet with the all-routers 1310 multicast address, then this indicates that it MUST bypass both 1311 interface and label stack validation, but return Downstream 1312 Mapping TLVs using the information provided. 1314 Return Code 1316 The Return Code is set to zero by the sender of an Echo Request. 1317 The receiver of said Echo Request can set it in the corresponding 1318 Echo Reply that it generates to one of the values specified in 1319 Section 3.1 other than 14. 1321 If the receiver sets a non-zero value of the Return Code field in 1322 the Downstream Detailed Mapping TLV, then the receiver MUST also 1323 set the Return Code field in the echo reply header to "See DDMAP 1324 TLV for Return Code and Return Subcode" (Section 3.1.) An 1325 exception to this is if the receiver is a bud node [RFC4461] and 1326 is replying as both an egress and a transit node with a Return 1327 Code of 3 ("Replying router is an egress for the FEC at stack- 1328 depth ") in the echo reply header. 1330 If the Return Code of the echo reply message is not set to either 1331 "See DDMAP TLV for Return Code and Return Subcode" (Section 3.1) 1332 or "Replying router is an egress for the FEC at stack-depth 1333 ", then the Return Code specified in the Downstream Detailed 1334 Mapping TLV MUST be ignored. 1336 Return Subcode 1338 The Return Subcode is set to zero by the sender. The receiver can 1339 set this field to an appropriate value as specified in 1340 Section 3.1: The Return Subcode is filled in with the stack-depth 1341 for those codes that specify the stack-depth. For all other 1342 codes, the Return Subcode MUST be set to zero. 1344 If the Return Code of the echo reply message is not set to either 1345 "See DDMAP TLV for Return Code and Return Subcode" (Section 3.1) 1346 or "Replying router is an egress for the FEC at stack-depth 1347 ", then the Return Subcode specified in the Downstream 1348 Detailed Mapping TLV MUST be ignored. 1350 Sub-tlv Length 1352 Total length in octets of the sub-TLVs associated with this TLV. 1354 3.4.1. Sub-TLVs 1356 This section defines the sub-TLVs that MAY be included as part of the 1357 Downstream Detailed Mapping TLV. 1359 Sub-Type Value Field 1360 --------- ------------ 1361 1 Multipath data 1362 2 Label stack 1363 3 FEC stack change 1365 3.4.1.1. Multipath Data Sub-TLV 1366 0 1 2 3 1367 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 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 |Multipath Type | Multipath Length |Reserved (MBZ) | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | | 1372 | (Multipath Information) | 1373 | | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 The multipath data sub-TLV includes Multipath Information. 1378 Multipath Type 1380 The type of the encoding for the Multipath Information. 1382 The following Multipath Types are defined: 1384 Key Type Multipath Information 1385 --- ---------------- --------------------- 1386 0 no multipath Empty (Multipath Length = 0) 1387 2 IP address IP addresses 1388 4 IP address range low/high address pairs 1389 8 Bit-masked IP IP address prefix and bit mask 1390 address set 1391 9 Bit-masked label set Label prefix and bit mask 1393 Type 0 indicates that all packets will be forwarded out this one 1394 interface. 1396 Types 2, 4, 8, and 9 specify that the supplied Multipath 1397 Information will serve to exercise this path. 1399 Multipath Length 1401 The length in octets of the Multipath Information. 1403 MBZ 1405 MUST be set to zero when sending; MUST be ignored on receipt. 1407 Multipath Information 1409 Encoded multipath data (e.g., encoded address or label values), 1410 according to the Multipath Type. See Section 3.4.1.1.1 for 1411 encoding details. 1413 3.4.1.1.1. Multipath Information Encoding 1415 The Multipath Information encodes labels or addresses that will 1416 exercise this path. The Multipath Information depends on the 1417 Multipath Type. The contents of the field are shown in the table 1418 above. IPv4 addresses are drawn from the range 127/8; IPv6 addresses 1419 are drawn from the range 0:0:0:0:0:FFFF:7F00:0/104. Labels are 1420 treated as numbers, i.e., they are right justified in the field. For 1421 Type 4, ranges indicated by Address pairs MUST NOT overlap and MUST 1422 be in ascending sequence. 1424 Type 8 allows a more dense encoding of IP addresses. The IP prefix 1425 is formatted as a base IP address with the non-prefix low-order bits 1426 set to zero. The maximum prefix length is 27. Following the prefix 1427 is a mask of length 2^(32-prefix length) bits for IPv4 and 1428 2^(128-prefix length) bits for IPv6. Each bit set to 1 represents a 1429 valid address. The address is the base IPv4 address plus the 1430 position of the bit in the mask where the bits are numbered left to 1431 right beginning with zero. For example, the IPv4 addresses 1432 127.2.1.0, 127.2.1.5-127.2.1.15, and 127.2.1.20-127.2.1.29 would be 1433 encoded as follows: 1435 0 1 2 3 1436 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 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 |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| 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 |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| 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 Those same addresses embedded in IPv6 would be encoded as follows: 1445 0 1 2 3 1446 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 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 |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| 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 |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| 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 |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| 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 |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| 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 |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| 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 Type 9 allows a more dense encoding of labels. The label prefix is 1460 formatted as a base label value with the non-prefix low-order bits 1461 set to zero. The maximum prefix (including leading zeros due to 1462 encoding) length is 27. Following the prefix is a mask of length 1463 2^(32-prefix length) bits. Each bit set to one represents a valid 1464 label. The label is the base label plus the position of the bit in 1465 the mask where the bits are numbered left to right beginning with 1466 zero. Label values of all the odd numbers between 1152 and 1279 1467 would be encoded as follows: 1469 0 1 2 3 1470 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 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 |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| 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 |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| 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 |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| 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 |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| 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 |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| 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 If the received Multipath Information is non-null, the labels and IP 1484 addresses MUST be picked from the set provided. If none of these 1485 labels or addresses map to a particular downstream interface, then 1486 for that interface, the type MUST be set to 0. If the received 1487 Multipath Information is null (i.e., Multipath Length = 0, or for 1488 Types 8 and 9, a mask of all zeros), the type MUST be set to 0. 1490 For example, suppose LSR X at hop 10 has two downstream LSRs, Y and 1491 Z, for the FEC in question. The received X could return Multipath 1492 Type 4, with low/high IP addresses of 127.1.1.1->127.1.1.255 for 1493 downstream LSR Y and 127.2.1.1->127.2.1.255 for downstream LSR Z. 1494 The head end reflects this information to LSR Y. Y, which has three 1495 downstream LSRs, U, V, and W, computes that 127.1.1.1->127.1.1.127 1496 would go to U and 127.1.1.128-> 127.1.1.255 would go to V. Y would 1497 then respond with 3 Downstream Detailed Mapping TLVs: to U, with 1498 Multipath Type 4 (127.1.1.1->127.1.1.127); to V, with Multipath Type 1499 4 (127.1.1.127->127.1.1.255); and to W, with Multipath Type 0. 1501 Note that computing Multipath Information may impose a significant 1502 processing burden on the receiver. A receiver MAY thus choose to 1503 process a subset of the received prefixes. The sender, on receiving 1504 a reply to a Downstream Detailed Mapping with partial information, 1505 SHOULD assume that the prefixes missing in the reply were skipped by 1506 the receiver, and MAY re-request information about them in a new echo 1507 request. 1509 The encoding of Multipath information in scenarios where few LSRs 1510 apply Entropy label based load balancing while other LSRs are non-EL 1511 (IP based) load balancing will be defined in a different document. 1513 The encoding of multipath information in scenarios where LSR have 1514 Layer 2 ECMP over Link Aggregation Group (LAG) interfaces will be 1515 defined in different document. 1517 3.4.1.2. Label Stack Sub-TLV 1519 0 1 2 3 1520 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 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | Downstream Label | Protocol | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 . . 1525 . . 1526 . . 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | Downstream Label | Protocol | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 The Label stack sub-TLV contains the set of labels in the label stack 1532 as it would have appeared if this router were forwarding the packet 1533 through this interface. Any Implicit Null labels are explicitly 1534 included. The number of label/protocol pairs present in the sub-TLV 1535 is determined based on the sub-TLV data length. When the Downstream 1536 Detailed Mapping TLV is sent in the echo reply, this sub-TLV MUST be 1537 included. 1539 Downstream Label 1541 A Downstream label is 24 bits, in the same format as an MPLS label 1542 minus the Time to Live (TTL) field, i.e., the MSBit of the label 1543 is bit 0, the LSBit is bit 19, the Traffic Class (TC) field 1544 [RFC5462] is bits 20-22, and S is bit 23. The replying router 1545 SHOULD fill in the TC field and S bit; the LSR receiving the echo 1546 reply MAY choose to ignore these. 1548 Protocol 1550 This specifies the label distribution protocol for the Downstream 1551 label. Protocol values are taken from the following table: 1553 Protocol # Signaling Protocol 1554 ---------- ------------------ 1555 0 Unknown 1556 1 Static 1557 2 BGP 1558 3 LDP 1559 4 RSVP-TE 1561 3.4.1.3. FEC Stack Change Sub-TLV 1563 A router MUST include the FEC stack change sub-TLV when the 1564 downstream node in the echo reply has a different FEC Stack than the 1565 FEC Stack received in the echo request. One or more FEC stack change 1566 sub-TLVs MAY be present in the Downstream Detailed Mapping TLV. The 1567 format is as below. 1569 0 1 2 3 1570 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 2 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 |Operation Type | Address Type | FEC-tlv length| Reserved | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | Remote Peer Address (0, 4 or 16 octets) | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 . . 1577 . FEC TLV . 1578 . . 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 Operation Type 1583 The operation type specifies the action associated with the FEC 1584 stack change. The following operation types are defined: 1586 Type # Operation 1587 ------ --------- 1588 1 Push 1589 2 Pop 1591 Address Type 1593 The Address Type indicates the remote peer's address type. The 1594 Address Type is set to one of the following values. The length of 1595 the peer address is determined based on the address type. The 1596 address type MAY be different from the address type included in 1597 the Downstream Detailed Mapping TLV. This can happen when the LSP 1598 goes over a tunnel of a different address family. The address 1599 type MAY be set to Unspecified if the peer address is either 1600 unavailable or the transit router does not wish to provide it for 1601 security or administrative reasons. 1603 Type # Address Type Address length 1604 ------ ------------ -------------- 1606 0 Unspecified 0 1607 1 IPv4 4 1608 2 IPv6 16 1610 FEC TLV Length 1612 Length in octets of the FEC TLV. 1614 Reserved 1616 This field is reserved for future use and MUST be set to zero. 1618 Remote Peer Address 1620 The remote peer address specifies the remote peer that is the 1621 next-hop for the FEC being currently traced. If the operation 1622 type is PUSH, the remote peer address is the address of the peer 1623 from which the FEC being pushed was learned. If the operation 1624 type is POP, the remote peer address MAY be set to Unspecified. 1626 For upstream-assigned labels [RFC5331], an operation type of POP 1627 will have a remote peer address (the upstream node that assigned 1628 the label) and this SHOULD be included in the FEC stack change 1629 sub-TLV. The remote peer address MAY be set to Unspecified if the 1630 address needs to be hidden. 1632 FEC TLV 1634 The FEC TLV is present only when the FEC-tlv length field is non- 1635 zero. The FEC TLV specifies the FEC associated with the FEC stack 1636 change operation. This TLV MAY be included when the operation 1637 type is POP. It MUST be included when the operation type is PUSH. 1638 The FEC TLV contains exactly one FEC from the list of FECs 1639 specified in Section 3.2. A Nil FEC MAY be associated with a PUSH 1640 operation if the responding router wishes to hide the details of 1641 the FEC being pushed. 1643 FEC stack change sub-TLV operation rules are as follows: 1645 a. A FEC stack change sub-TLV containing a PUSH operation MUST NOT 1646 be followed by a FEC stack change sub-TLV containing a POP 1647 operation. 1649 b. One or more POP operations MAY be followed by one or more PUSH 1650 operations. 1652 c. One FEC stack change sub-TLV MUST be included per FEC stack 1653 change. For example, if 2 labels are going to be pushed, then 1654 one FEC stack change sub-TLV MUST be included for each FEC. 1656 d. A FEC splice operation (an operation where one FEC ends and 1657 another FEC starts, MUST be performed by including a POP type FEC 1658 stack change sub-TLV followed by a PUSH type FEC stack change 1659 sub-TLV. 1661 e. A Downstream Detailed Mapping TLV containing only one FEC stack 1662 change sub-TLV with Pop operation is equivalent to IS_EGRESS 1663 (Return Code 3, Section 3.1) for the outermost FEC in the FEC 1664 stack. The ingress router performing the MPLS traceroute MUST 1665 treat such a case as an IS_EGRESS for the outermost FEC. 1667 3.4.2. Downstream Router and Interface 1669 The notion of "downstream router" and "downstream interface" should 1670 be explained. Consider an LSR X. If a packet that was originated 1671 with TTL n>1 arrived with outermost label L and TTL=1 at LSR X, X 1672 must be able to compute which LSRs could receive the packet if it was 1673 originated with TTL=n+1, over which interface the request would 1674 arrive and what label stack those LSRs would see. (It is outside the 1675 scope of this document to specify how this computation is done.) The 1676 set of these LSRs/interfaces consists of the downstream routers/ 1677 interfaces (and their corresponding labels) for X with respect to L. 1678 Each pair of downstream router and interface requires a separate 1679 Downstream Detailed Mapping to be added to the reply. 1681 The case where X is the LSR originating the echo request is a special 1682 case. X needs to figure out what LSRs would receive the MPLS echo 1683 request for a given FEC Stack that X originates with TTL=1. 1685 The set of downstream routers at X may be alternative paths (see the 1686 discussion below on ECMP) or simultaneous paths (e.g., for MPLS 1687 multicast). In the former case, the Multipath Information is used as 1688 a hint to the sender as to how it may influence the choice of these 1689 alternatives. 1691 3.5. Pad TLV 1693 The value part of the Pad TLV contains a variable number (>= 1) of 1694 octets. The first octet takes values from the following table; all 1695 the other octets (if any) are ignored. The receiver SHOULD verify 1696 that the TLV is received in its entirety, but otherwise ignores the 1697 contents of this TLV, apart from the first octet. 1699 Value Meaning 1700 ----- ------- 1701 0 Reserved 1702 1 Drop Pad TLV from reply 1703 2 Copy Pad TLV to reply 1704 3-250 Unassigned 1705 251-254 Experimental Use 1706 255 Reserved 1708 The Pad TLV can be added to an Echo Request to create a message of a 1709 specific length in cases where messages of various sizes are needed 1710 for troubleshooting. The first octet allows for controlling the 1711 inclusion of this additional padding in the respective Echo Reply. 1713 3.6. Vendor Enterprise Number 1715 "Private Enterprise Numbers" [IANA-ENT] are maintained by IANA. The 1716 Length of this TLV is always 4; the value is the SMI Private 1717 Enterprise Code, in network octet order, of the vendor with a Vendor 1718 Private extension to any of the fields in the fixed part of the 1719 message, in which case this TLV MUST be present. If none of the 1720 fields in the fixed part of the message have Vendor Private 1721 extensions, inclusion of this TLV is OPTIONAL. Vendor Private ranges 1722 for Message Types, Reply Modes, and Return Codes have been defined. 1723 When any of these are used, the Vendor Enterprise Number TLV MUST be 1724 included in the message. 1726 3.7. Interface and Label Stack 1728 The Interface and Label Stack TLV MAY be included in a reply message 1729 to report the interface on which the request message was received and 1730 the label stack that was on the packet when it was received. Only 1731 one such object may appear. The purpose of the object is to allow 1732 the upstream router to obtain the exact interface and label stack 1733 information as it appears at the replying LSR. 1735 The Length is K + 4*N octets; N is the number of labels in the label 1736 stack. Values for K are found in the description of Address Type 1737 below. The Value field of this TLV has the following format: 1739 0 1 2 3 1740 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 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | Address Type | Must Be Zero | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | IP Address (4 or 16 octets) | 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 | Interface (4 or 16 octets) | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 . . 1749 . . 1750 . Label Stack . 1751 . . 1752 . . 1753 . . 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 Address Type 1758 The Address Type indicates if the interface is numbered or 1759 unnumbered. It also determines the length of the IP Address and 1760 Interface fields. The resulting total for the initial part of the 1761 TLV is listed in the table below as "K Octets". The Address Type 1762 is set to one of the following values: 1764 Type # Address Type K Octets 1765 ------ ------------ -------- 1766 0 Reserved 4 1767 1 IPv4 Numbered 12 1768 2 IPv4 Unnumbered 12 1769 3 IPv6 Numbered 36 1770 4 IPv6 Unnumbered 24 1771 5-250 Unassigned 1772 251-254 Experimental Use 1773 255 Reserved 1775 IP Address and Interface 1777 IPv4 addresses and interface indices are encoded in 4 octets; IPv6 1778 addresses are encoded in 16 octets. 1780 If the interface upon which the echo request message was received 1781 is numbered, then the Address Type MUST be set to IPv4 or IPv6, 1782 the IP Address MUST be set to either the LSR's Router ID or the 1783 interface address, and the Interface MUST be set to the interface 1784 address. 1786 If the interface is unnumbered, the Address Type MUST be either 1787 IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the 1788 LSR's Router ID, and the Interface MUST be set to the index 1789 assigned to the interface. 1791 Label Stack 1793 The label stack of the received echo request message. If any TTL 1794 values have been changed by this router, they SHOULD be restored. 1796 3.8. Errored TLVs 1798 The following TLV is a TLV that MAY be included in an echo reply to 1799 inform the sender of an echo request of mandatory TLVs either not 1800 supported by an implementation or parsed and found to be in error. 1802 The Value field contains the TLVs that were not understood, encoded 1803 as sub-TLVs. 1805 0 1 2 3 1806 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 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | Type = 9 | Length | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 | Value | 1811 . . 1812 . . 1813 . . 1814 | | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 3.9. Reply TOS Octet TLV 1819 This TLV MAY be used by the originator of the echo request to request 1820 that an echo reply be sent with the IP header TOS octet set to the 1821 value specified in the TLV. This TLV has a length of 4 with the 1822 following value field. 1824 0 1 2 3 1825 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 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | Reply-TOS Byte| Must Be Zero | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 4. Theory of Operation 1832 An MPLS echo request is used to test a particular LSP. The LSP to be 1833 tested is identified by the "FEC Stack"; for example, if the LSP was 1834 set up via LDP, and is to an egress IP address of 198.51.100.1, the 1835 FEC Stack contains a single element, namely, an LDP IPv4 prefix sub- 1836 TLV with value 198.51.100.1/32. If the LSP being tested is an RSVP 1837 LSP, the FEC Stack consists of a single element that captures the 1838 RSVP Session and Sender Template that uniquely identifies the LSP. 1840 FEC Stacks can be more complex. For example, one may wish to test a 1841 VPN IPv4 prefix of 203.0.113.0/24 that is tunneled over an LDP LSP 1842 with egress 192.0.2.1. The FEC Stack would then contain two sub- 1843 TLVs, the bottom being a VPN IPv4 prefix, and the top being an LDP 1844 IPv4 prefix. If the underlying (LDP) tunnel were not known, or was 1845 considered irrelevant, the FEC Stack could be a single element with 1846 just the VPN IPv4 sub-TLV. 1848 When an MPLS echo request is received, the receiver is expected to 1849 verify that the control plane and data plane are both healthy (for 1850 the FEC Stack being pinged) and that the two planes are in sync. The 1851 procedures for this are in Section 4.4. 1853 4.1. Dealing with Equal-Cost Multi-Path (ECMP) 1855 LSPs need not be simple point-to-point tunnels. Frequently, a single 1856 LSP may originate at several ingresses, and terminate at several 1857 egresses; this is very common with LDP LSPs. LSPs for a given FEC 1858 may also have multiple "next hops" at transit LSRs. At an ingress, 1859 there may also be several different LSPs to choose from to get to the 1860 desired endpoint. Finally, LSPs may have backup paths, detour paths, 1861 and other alternative paths to take should the primary LSP go down. 1863 To deal with the last two first: it is assumed that the LSR sourcing 1864 MPLS echo requests can force the echo request into any desired LSP, 1865 so choosing among multiple LSPs at the ingress is not an issue. The 1866 problem of probing the various flavors of backup paths that will 1867 typically not be used for forwarding data unless the primary LSP is 1868 down will not be addressed here. 1870 Since the actual LSP and path that a given packet may take may not be 1871 known a priori, it is useful if MPLS echo requests can exercise all 1872 possible paths. This, although desirable, may not be practical, 1873 because the algorithms that a given LSR uses to distribute packets 1874 over alternative paths may be proprietary. 1876 To achieve some degree of coverage of alternate paths, there is a 1877 certain latitude in choosing the destination IP address and source 1878 UDP port for an MPLS echo request. This is clearly not sufficient; 1879 in the case of traceroute, more latitude is offered by means of the 1880 Multipath Information of the Downstream Detailed Mapping TLV. This 1881 is used as follows. An ingress LSR periodically sends an MPLS 1882 traceroute message to determine whether there are multipaths for a 1883 given LSP. If so, each hop will provide some information as to how 1884 each of its downstream paths can be exercised. The ingress can then 1885 send MPLS echo requests that exercise these paths. If several 1886 transit LSRs have ECMP, the ingress may attempt to compose these to 1887 exercise all possible paths. However, full coverage may not be 1888 possible. 1890 4.2. Testing LSPs That Are Used to Carry MPLS Payloads 1892 To detect certain LSP breakages, it may be necessary to encapsulate 1893 an MPLS echo request packet with at least one additional label when 1894 testing LSPs that are used to carry MPLS payloads (such as LSPs used 1895 to carry L2VPN and L3VPN traffic. For example, when testing LDP or 1896 RSVP-TE LSPs, just sending an MPLS echo request packet may not detect 1897 instances where the router immediately upstream of the destination of 1898 the LSP ping may forward the MPLS echo request successfully over an 1899 interface not configured to carry MPLS payloads because of the use of 1900 penultimate hop popping. Since the receiving router has no means to 1901 ascertain whether the IP packet was sent unlabeled or implicitly 1902 labeled, the addition of labels shimmed above the MPLS echo request 1903 (using the Nil FEC) will prevent a router from forwarding such a 1904 packet out unlabeled interfaces. 1906 4.3. Sending an MPLS Echo Request 1908 An MPLS echo request is a UDP packet. The IP header is set as 1909 follows: the source IP address is a routable address of the sender; 1910 the destination IP address is a (randomly chosen) IPv4 address from 1911 the range 127/8 or IPv6 address from the range 1912 0:0:0:0:0:FFFF:7F00:0/104. The IP TTL is set to 1. The source UDP 1913 port is chosen by the sender; the destination UDP port is set to 3503 1914 (assigned by IANA for MPLS echo requests). The Router Alert IP 1915 option of value 0x0 [RFC2113] for IPv4 or value 69 [RFC7506] for IPv6 1916 MUST be set in the IP header. 1918 An MPLS echo request is sent with a label stack corresponding to the 1919 FEC Stack being tested. Note that further labels could be applied 1920 if, for example, the normal route to the topmost FEC in the stack is 1921 via a Traffic Engineered Tunnel [RFC3209]. If all of the FECs in the 1922 stack correspond to Implicit Null labels, the MPLS echo request is 1923 considered unlabeled even if further labels will be applied in 1924 sending the packet. 1926 If the echo request is labeled, one MAY (depending on what is being 1927 pinged) set the TTL of the innermost label to 1, to prevent the ping 1928 request going farther than it should. Examples of where this SHOULD 1929 be done include pinging a VPN IPv4 or IPv6 prefix, an L2 VPN endpoint 1930 or a pseudowire. Preventing the ping request from going too far can 1931 also be accomplished by inserting a Router Alert label above this 1932 label; however, this may lead to the undesired side effect that MPLS 1933 echo requests take a different data path than actual data. For more 1934 information on how these mechanisms can be used for pseudowire 1935 connectivity verification, see [RFC5085]. 1937 In "ping" mode (end-to-end connectivity check), the TTL in the 1938 outermost label is set to 255. In "traceroute" mode (fault isolation 1939 mode), the TTL is set successively to 1, 2, and so on. 1941 The sender chooses a Sender's Handle and a Sequence Number. When 1942 sending subsequent MPLS echo requests, the sender SHOULD increment 1943 the Sequence Number by 1. However, a sender MAY choose to send a 1944 group of echo requests with the same Sequence Number to improve the 1945 chance of arrival of at least one packet with that Sequence Number. 1947 The TimeStamp Sent is set to the time-of-day in NTP format that the 1948 echo request is sent. The TimeStamp Received is set to zero. 1950 An MPLS echo request MUST have an FEC Stack TLV. Also, the Reply 1951 Mode must be set to the desired reply mode; the Return Code and 1952 Subcode are set to zero. In the "traceroute" mode, the echo request 1953 SHOULD include a Downstream Detailed Mapping TLV. 1955 4.4. Receiving an MPLS Echo Request 1957 Sending an MPLS echo request to the control plane is triggered by one 1958 of the following packet processing exceptions: Router Alert option, 1959 IP TTL expiration, MPLS TTL expiration, MPLS Router Alert label, or 1960 the destination address in the 127/8 address range. The control 1961 plane further identifies it by UDP destination port 3503. 1963 For reporting purposes the bottom of stack is considered to be stack- 1964 depth of 1. This is to establish an absolute reference for the case 1965 where the actual stack may have more labels than there are FECs in 1966 the Target FEC Stack. 1968 Furthermore, in all the error codes listed in this document, a stack- 1969 depth of 0 means "no value specified". This allows compatibility 1970 with existing implementations that do not use the Return Subcode 1971 field. 1973 An LSR X that receives an MPLS echo request then processes it as 1974 follows. 1976 1. General packet sanity is verified. If the packet is not well- 1977 formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code 1978 set to "Malformed echo request received" and the Subcode to zero. 1979 If there are any TLVs not marked as "Ignore" (i.e., if the TLV 1980 type is less than 32768, see Section 3) that LSR X does not 1981 understand, LSR X SHOULD send an MPLS "TLV not understood" (as 1982 appropriate), and the Subcode set to zero. In the latter case, 1983 the misunderstood TLVs (only) are included as sub-TLVs in an 1984 Errored TLVs TLV in the reply. The header fields Sender's 1985 Handle, Sequence Number, and Timestamp Sent are not examined, but 1986 are included in the MPLS echo reply message. 1988 The algorithm uses the following variables and identifiers: 1990 Interface-I: the interface on which the MPLS echo request was 1991 received. 1993 Stack-R: the label stack on the packet as it was received. 1995 Stack-D: the label stack carried in the "Label Stack sub- 1996 TLV" in Downstream Detailed Mapping TLV (not 1997 always present) 1999 Label-L: the label from the actual stack currently being 2000 examined. Requires no initialization. 2002 Label-stack-depth: the depth of label being verified. Initialized 2003 to the number of labels in the received label 2004 stack S. 2006 FEC-stack-depth: depth of the FEC in the Target FEC Stack that 2007 should be used to verify the current actual 2008 label. Requires no initialization. 2010 Best-return-code: contains the return code for the echo reply 2011 packet as currently best known. As the algorithm 2012 progresses, this code may change depending on the 2013 results of further checks that it performs. 2015 Best-rtn-subcode: similar to Best-return-code, but for the Echo 2016 Reply Subcode. 2018 FEC-status: result value returned by the FEC Checking 2019 algorithm described in Section 4.4.1. 2021 /* Save receive context information */ 2023 2. If the echo request is good, LSR X stores the interface over 2024 which the echo was received in Interface-I, and the label stack 2025 with which it came in Stack-R. 2027 /* The rest of the algorithm iterates over the labels in Stack-R, 2028 verifies validity of label values, reports associated label switching 2029 operations (for traceroute), verifies correspondence between the 2030 Stack-R and the Target FEC Stack description in the body of the echo 2031 request, and reports any errors. */ 2033 /* The algorithm iterates as follows. */ 2035 3. Label Validation: 2037 If Label-stack-depth is 0 { 2039 /* The LSR needs to report its being a tail-end for the LSP */ 2041 Set FEC-stack-depth to 1, set Label-L to 3 (Implicit Null). 2042 Set Best-return-code to 3 ("Replying router is an egress for 2043 the FEC at stack depth"), set Best-rtn-subcode to the value of 2044 FEC-stack-depth (1) and go to step 5 (Egress Processing). 2046 } 2048 /* This step assumes there is always an entry for well-known label 2049 values */ 2051 Set Label-L to the value extracted from Stack-R at depth Label- 2052 stack-depth. Look up Label-L in the Incoming Label Map (ILM) to 2053 determine if the label has been allocated and an operation is 2054 associated with it. 2056 If there is no entry for Label-L { 2058 /* Indicates a temporary or permanent label synchronization 2059 problem the LSR needs to report an error */ 2061 Set Best-return-code to 11 ("No label entry at stack-depth") 2062 and Best-rtn-subcode to Label-stack-depth. Go to step 7 (Send 2063 Reply Packet). 2065 } 2067 Else { 2068 Retrieve the associated label operation from the corresponding 2069 NHLFE and proceed to step 4 (Label Operation check). 2071 } 2073 4. Label Operation Check 2075 If the label operation is "Pop and Continue Processing" { 2077 /* Includes Explicit Null and Router Alert label cases */ 2079 Iterate to the next label by decrementing Label-stack-depth and 2080 loop back to step 3 (Label Validation). 2082 } 2084 If the label operation is "Swap or Pop and Switch based on Popped 2085 Label" { 2087 Set Best-return-code to 8 ("Label switched at stack-depth") and 2088 Best-rtn-subcode to Label-stack-depth to report transit 2089 switching. 2091 If a Downstream Detailed Mapping TLV is present in the received 2092 echo request { 2094 If the IP address in the TLV is 127.0.0.1 or 0::1 { 2096 Set Best-return-code to 6 ("Upstream Interface Index 2097 Unknown"). An Interface and Label Stack TLV SHOULD be 2098 included in the reply and filled with Interface-I and 2099 Stack-R. 2101 } 2103 Else { 2105 Verify that the IP address, interface address, and label 2106 stack in the Downstream Detailed Mapping TLV match 2107 Interface-I and Stack-R. If there is a mismatch, set 2108 Best-return-code to 5, "Downstream Mapping Mismatch". An 2109 Interface and Label Stack TLV SHOULD be included in the 2110 reply and filled in based on Interface-I and Stack-R. Go 2111 to step 7 (Send Reply Packet). 2113 } 2115 } 2116 For each available downstream ECMP path { 2118 Retrieve output interface from the NHLFE entry. 2120 /* Note: this return code is set even if Label-stack-depth 2121 is one */ 2123 If the output interface is not MPLS enabled { 2125 Set Best-return-code to Return Code 9, "Label switched 2126 but no MPLS forwarding at stack-depth" and set Best-rtn- 2127 subcode to Label-stack-depth and go to step 7 (Send Reply 2128 Packet). 2130 } 2132 If a Downstream Detailed Mapping TLV is present { 2134 A Downstream Detailed Mapping TLV SHOULD be included in 2135 the echo reply (see Section 3.4) filled in with 2136 information about the current ECMP path. 2138 } 2140 } 2142 If no Downstream Detailed Mapping TLV is present, or the 2143 Downstream IP Address is set to the ALLROUTERS multicast 2144 address, go to step 7 (Send Reply Packet). 2146 If the "Validate FEC Stack" flag is not set and the LSR is not 2147 configured to perform FEC checking by default, go to step 7 2148 (Send Reply Packet). 2150 /* Validate the Target FEC Stack in the received echo request. 2152 First determine FEC-stack-depth from the Downstream Detailed 2153 Mapping TLV. This is done by walking through Stack-D (the 2154 Downstream labels) from the bottom, decrementing the number of 2155 labels for each non-Implicit Null label, while incrementing 2156 FEC-stack-depth for each label. If the Downstream Detailed 2157 Mapping TLV contains one or more Implicit Null labels, FEC- 2158 stack-depth may be greater than Label-stack-depth. To be 2159 consistent with the above stack-depths, the bottom is 2160 considered to be entry 1. 2161 */ 2163 Set FEC-stack-depth to 0. Set i to Label-stack-depth. 2165 While (i > 0) do { 2167 ++FEC-stack-depth. 2168 if Stack-D [ FEC-stack-depth ] != 3 (Implicit Null) 2169 --i. 2170 } 2172 If the number of FECs in the FEC stack is greater than or equal 2173 to FEC-stack-depth { 2174 Perform the FEC Checking procedure (see Section 4.4.1). 2176 If FEC-status is 2, set Best-return-code to 10 ("Mapping for 2177 this FEC is not the given label at stack-depth"). 2179 If the return code is 1, set Best-return-code to FEC-return- 2180 code and Best-rtn-subcode to FEC-stack-depth. 2181 } 2183 Go to step 7 (Send Reply Packet). 2184 } 2186 5. Egress Processing: 2188 /* These steps are performed by the LSR that identified itself as 2189 the tail-end LSR for an LSP. */ 2191 If received echo request contains no Downstream Detailed Mapping 2192 TLV, or the Downstream IP Address is set to 127.0.0.1 or 0::1 go 2193 to step 6 (Egress FEC Validation). 2195 Verify that the IP address, interface address, and label stack in 2196 the Downstream Detailed Mapping TLV match Interface-I and Stack-R. 2197 If not, set Best-return-code to 5, "Downstream Mapping Mis-match". 2198 A Received Interface and Label Stack TLV SHOULD be created for the 2199 echo response packet. Go to step 7 (Send Reply Packet). 2201 6. Egress FEC Validation: 2203 /* This is a loop for all entries in the Target FEC Stack starting 2204 with FEC-stack-depth. */ 2206 Perform FEC checking by following the algorithm described in 2207 Section 4.4.1 for Label-L and the FEC at FEC-stack-depth. 2209 Set Best-return-code to FEC-code and Best-rtn-subcode to the value 2210 in FEC-stack-depth. 2212 If FEC-status (the result of the check) is 1, 2213 go to step 7 (Send Reply Packet). 2215 /* Iterate to the next FEC entry */ 2217 ++FEC-stack-depth. 2218 If FEC-stack-depth > the number of FECs in the FEC-stack, 2219 go to step 7 (Send Reply Packet). 2221 If FEC-status is 0 { 2223 ++Label-stack-depth. 2224 If Label-stack-depth > the number of labels in Stack-R, 2225 Go to step 7 (Send Reply Packet). 2227 Label-L = extracted label from Stack-R at depth 2228 Label-stack-depth. 2229 Loop back to step 6 (Egress FEC Validation). 2230 } 2232 7. Send Reply Packet: 2234 Send an MPLS echo reply with a Return Code of Best-return-code, 2235 and a Return Subcode of Best-rtn-subcode. Include any TLVs 2236 created during the above process. The procedures for sending the 2237 echo reply are found in Section 4.5. 2239 4.4.1. FEC Validation 2241 /* This section describes validation of an FEC entry within the 2242 Target FEC Stack and accepts an FEC, Label-L, and Interface-I. 2244 If the outermost FEC of the target FEC stack is the Nil FEC, then the 2245 node MUST skip the target FEC validation completely. This is to 2246 support FEC hiding, in which the outer hidden FEC can be the Nil FEC. 2247 Else, the algorithm performs the following steps. */ 2249 1. Two return values, FEC-status and FEC-return-code, are 2250 initialized to 0. 2252 2. If the FEC is the Nil FEC { 2254 If Label-L is either Explicit_Null or Router_Alert, return. 2256 Else { 2257 Set FEC-return-code to 10 ("Mapping for this FEC is not the 2258 given label at stack-depth"). 2259 Set FEC-status to 1 2260 Return. 2261 } 2263 } 2265 3. Check the FEC label mapping that describes how traffic received 2266 on the LSP is further switched or which application it is 2267 associated with. If no mapping exists, set FEC-return-code to 2268 Return 4, "Replying router has no mapping for the FEC at stack- 2269 depth". Set FEC-status to 1. Return. 2271 4. If the label mapping for FEC is Implicit Null, set FEC-status to 2272 2 and proceed to step 5. Otherwise, if the label mapping for FEC 2273 is Label-L, proceed to step 5. Otherwise, set FEC-return-code to 2274 10 ("Mapping for this FEC is not the given label at stack- 2275 depth"), set FEC-status to 1, and return. 2277 5. This is a protocol check. Check what protocol would be used to 2278 advertise the FEC. If it can be determined that no protocol 2279 associated with Interface-I would have advertised an FEC of that 2280 FEC-Type, set FEC-return-code to 12 ("Protocol not associated 2281 with interface at FEC stack-depth"). Set FEC-status to 1. 2283 6. Return. 2285 4.5. Sending an MPLS Echo Reply 2287 An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response 2288 to an MPLS echo request. The source IP address is a routable address 2289 of the replier; the source port is the well-known UDP port for LSP 2290 ping. The destination IP address and UDP port are copied from the 2291 source IP address and UDP port of the echo request. The IP TTL is 2292 set to 255. If the Reply Mode in the echo request is "Reply via an 2293 IPv4 UDP packet with Router Alert", then the IP header MUST contain 2294 the Router Alert IP option of value 0x0 [RFC2113] for IPv4 or 69 2295 [RFC7506] for IPv6. If the reply is sent over an LSP, the topmost 2296 label MUST in this case be the Router Alert label (1) (see 2297 [RFC3032]). 2299 The format of the echo reply is the same as the echo request. The 2300 Sender's Handle, the Sequence Number, and TimeStamp Sent are copied 2301 from the echo request; the TimeStamp Received is set to the time-of- 2302 day that the echo request is received (note that this information is 2303 most useful if the time-of-day clocks on the requester and the 2304 replier are synchronized). The FEC Stack TLV from the echo request 2305 MAY be copied to the reply. 2307 The replier MUST fill in the Return Code and Subcode, as determined 2308 in the previous section. 2310 If the echo request contains a Pad TLV, the replier MUST interpret 2311 the first octet for instructions regarding how to reply. 2313 If the replying router is the destination of the FEC, then Downstream 2314 Detailed Mapping TLVs SHOULD NOT be included in the echo reply. 2316 If the echo request contains a Downstream Detailed Mapping TLV, and 2317 the replying router is not the destination of the FEC, the replier 2318 SHOULD compute its downstream routers and corresponding labels for 2319 the incoming label, and add Downstream Detailed Mapping TLVs for each 2320 one to the echo reply it sends back. A replying node should follow 2321 the procedures defined in Section 4.5.1 if there is an FEC stack 2322 change due to tunneled LSP. If the FEC stack change is due to 2323 stitched LSP, it should follow the procedures defined in 2324 Section 4.5.2. 2326 If the Downstream Detailed Mapping TLV contains Multipath Information 2327 requiring more processing than the receiving router is willing to 2328 perform, the responding router MAY choose to respond with only a 2329 subset of multipaths contained in the echo request Downstream 2330 Detailed Mapping. (Note: The originator of the echo request MAY send 2331 another echo request with the Multipath Information that was not 2332 included in the reply.) 2334 Except in the case of Reply Mode 4, "Reply via application level 2335 control channel", echo replies are always sent in the context of the 2336 IP/MPLS network. 2338 4.5.1. Addition of a New Tunnel 2340 A transit node knows when the FEC being traced is going to enter a 2341 tunnel at that node. Thus, it knows about the new outer FEC. All 2342 transit nodes that are the origination point of a new tunnel SHOULD 2343 add the FEC stack change sub-TLV (Section 3.4.1.3) to the Downstream 2344 Detailed Mapping TLV in the echo reply. The transit node SHOULD add 2345 one FEC stack change sub-TLV of operation type PUSH, per new tunnel 2346 being originated at the transit node. 2348 A transit node that sends a Downstream FEC stack change sub-TLV in 2349 the echo reply SHOULD fill the address of the remote peer; which is 2350 the peer of the current LSP being traced. If the transit node does 2351 not know the address of the remote peer, it MUST set the address type 2352 to Unspecified. 2354 The Label stack sub-TLV MUST contain one additional label per FEC 2355 being PUSHed. The label MUST be encoded as defined in 2356 Section 3.4.1.2. The label value MUST be the value used to switch 2357 the data traffic. If the tunnel is a transparent pipe to the node, 2358 i.e., the data-plane trace will not expire in the middle of the new 2359 tunnel, then a FEC stack change sub-TLV SHOULD NOT be added and the 2360 Label stack sub-TLV SHOULD NOT contain a label corresponding to the 2361 hidden tunnel. 2363 If the transit node wishes to hide the nature of the tunnel from the 2364 ingress of the echo request, then it MAY not want to send details 2365 about the new tunnel FEC to the ingress. In such a case, the transit 2366 node SHOULD use the Nil FEC. The echo reply would then contain a FEC 2367 stack change sub-TLV with operation type PUSH and a Nil FEC. The 2368 value of the label in the Nil FEC MUST be set to zero. The remote 2369 peer address type MUST be set to Unspecified. The transit node 2370 SHOULD add one FEC stack change sub-TLV of operation type PUSH, per 2371 new tunnel being originated at the transit node. The Label stack 2372 sub-TLV MUST contain one additional label per FEC being PUSHed. The 2373 label value MUST be the value used to switch the data traffic. 2375 4.5.2. Transition between Tunnels 2377 A transit node stitching two LSPs SHOULD include two FEC stack change 2378 sub-TLVs. One with a POP operation for the old FEC (ingress) and one 2379 with the PUSH operation for the new FEC (egress). The replying node 2380 SHOULD set the Return Code to "Label switched with FEC change" to 2381 indicate change in FEC being traced. 2383 If the replying node wishes to perform FEC hiding, it SHOULD respond 2384 back with two FEC stack change sub-TLVs, one POP followed by one 2385 PUSH. The POP operation MAY either exclude the FEC TLV (by setting 2386 the FEC TLV length to 0) or set the FEC TLV to contain the LDP FEC. 2387 The PUSH operation SHOULD have the FEC TLV containing the Nil FEC. 2388 The Return Code SHOULD be set to "Label switched with FEC change". 2390 If the replying node wishes to perform FEC hiding, it MAY choose to 2391 not send any FEC stack change sub-TLVs in the echo reply if the 2392 number of labels does not change for the downstream node and the FEC 2393 type also does not change (Nil FEC). In such case, the replying node 2394 MUST NOT set the Return Code to "Label switched with FEC change". 2396 4.6. Receiving an MPLS Echo Reply 2398 An LSR X should only receive an MPLS echo reply in response to an 2399 MPLS echo request that it sent. Thus, on receipt of an MPLS echo 2400 reply, X should parse the packet to ensure that it is well-formed, 2401 then attempt to match up the echo reply with an echo request that it 2402 had previously sent, using the destination UDP port and the Sender's 2403 Handle. If no match is found, then X jettisons the echo reply; 2404 otherwise, it checks the Sequence Number to see if it matches. 2406 If the echo reply contains Downstream Detailed Mappings, and X wishes 2407 to traceroute further, it SHOULD copy the Downstream Detailed 2408 Mapping(s) into its next echo request(s) (with TTL incremented by 2409 one). 2411 If one or more FEC stack change sub-TLVs are received in the MPLS 2412 echo reply, the ingress node SHOULD process them and perform some 2413 validation. 2415 The FEC stack changes are associated with a downstream neighbor and 2416 along a particular path of the LSP. Consequently, the ingress will 2417 need to maintain a FEC stack per path being traced (in case of 2418 multipath). All changes to the FEC stack resulting from the 2419 processing of FEC stack change sub-TLV(s) should be applied only for 2420 the path along a given downstream neighbor. The following algorithm 2421 should be followed for processing FEC stack change sub-TLVs. 2423 push_seen = FALSE 2424 fec_stack_depth = current-depth-of-fec-stack-being-traced 2425 saved_fec_stack = current_fec_stack 2427 while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv)) 2429 if (sub-tlv == NULL) break 2431 if (sub-tlv.type == FEC-Stack-Change) { 2433 if (sub-tlv.operation == POP) { 2434 if (push_seen) { 2435 Drop the echo reply 2436 current_fec_stack = saved_fec_stack 2437 return 2438 } 2440 if (fec_stack_depth == 0) { 2441 Drop the echo reply 2442 current_fec_stack = saved_fec_stack 2443 return 2444 } 2446 Pop FEC from FEC stack being traced 2447 fec_stack_depth--; 2448 } 2450 if (sub-tlv.operation == PUSH) { 2451 push_seen = 1 2452 Push FEC on FEC stack being traced 2453 fec_stack_depth++; 2454 } 2455 } 2456 } 2458 if (fec_stack_depth == 0) { 2459 Drop the echo reply 2460 current_fec_stack = saved_fec_stack 2461 return 2462 } 2464 The next MPLS echo request along the same path should use the 2465 modified FEC stack obtained after processing the FEC stack change 2466 sub-TLVs. A non-Nil FEC guarantees that the next echo request along 2467 the same path will have the Downstream Detailed Mapping TLV validated 2468 for IP address, Interface address, and label stack mismatches. 2470 If the top of the FEC stack is a Nil FEC and the MPLS echo reply does 2471 not contain any FEC stack change sub-TLVs, then it does not 2472 necessarily mean that the LSP has not started traversing a different 2473 tunnel. It could be that the LSP associated with the Nil FEC 2474 terminated at a transit node and at the same time a new LSP started 2475 at the same transit node. The Nil FEC would now be associated with 2476 the new LSP (and the ingress has no way of knowing this). Thus, it 2477 is not possible to build an accurate hierarchical LSP topology if a 2478 traceroute contains Nil FECs. 2480 A reply from a downstream node with Return Code 3, may not 2481 necessarily be for the FEC being traced. It could be for one of the 2482 new FECs that was added. On receipt of an IS_EGRESS reply, the LSP 2483 ingress should check if the depth of Target FEC sent to the node that 2484 just responded, was the same as the depth of the FEC that was being 2485 traced. If it was not, then it should pop an entry from the Target 2486 FEC stack and resend the request with the same TTL (as previously 2487 sent). The process of popping a FEC is to be repeated until either 2488 the LSP ingress receives a non-IS_EGRESS reply or until all the 2489 additional FECs added to the FEC stack have already been popped. 2490 Using an IS_EGRESS reply, an ingress can build a map of the 2491 hierarchical LSP structure traversed by a given FEC. 2493 When the MPLS echo reply Return Code is "Label switched with FEC 2494 change", the ingress node SHOULD manipulate the FEC stack as per the 2495 FEC stack change sub-TLVs contained in the Downstream Detailed 2496 Mapping TLV. A transit node can use this Return Code for stitched 2497 LSPs and for hierarchical LSPs. In case of ECMP or P2MP, there could 2498 be multiple paths and Downstream Detailed Mapping TLVs with different 2499 Return Codes (see Section 3.1, Note 2). The ingress node should 2500 build the topology based on the Return Code per ECMP path/P2MP 2501 branch. 2503 4.7. Issue with VPN IPv4 and IPv6 Prefixes 2505 Typically, an LSP ping for a VPN IPv4 prefix or VPN IPv6 prefix is 2506 sent with a label stack of depth greater than 1, with the innermost 2507 label having a TTL of 1. This is to terminate the ping at the egress 2508 PE, before it gets sent to the customer device. However, under 2509 certain circumstances, the label stack can shrink to a single label 2510 before the ping hits the egress PE; this will result in the ping 2511 terminating prematurely. One such scenario is a multi-AS Carrier's 2512 Carrier VPN. 2514 To get around this problem, one approach is for the LSR that receives 2515 such a ping to realize that the ping terminated prematurely, and send 2516 back error code 13. In that case, the initiating LSR can retry the 2517 ping after incrementing the TTL on the VPN label. In this fashion, 2518 the ingress LSR will sequentially try TTL values until it finds one 2519 that allows the VPN ping to reach the egress PE. 2521 4.8. Non-compliant Routers 2523 If the egress for the FEC Stack being pinged does not support MPLS 2524 ping, then no reply will be sent, resulting in possible "false 2525 negatives". If in "traceroute" mode, a transit LSR does not support 2526 LSP ping, then no reply will be forthcoming from that LSR for some 2527 TTL, say, n. The LSR originating the echo request SHOULD try sending 2528 the echo request with TTL=n+1, n+2, ..., n+k to probe LSRs further 2529 down the path. In such a case, the echo request for TTL > n SHOULD 2530 be sent with Downstream Detailed Mapping TLV "Downstream IP Address" 2531 field set to the ALLROUTERs multicast address until a reply is 2532 received with a Downstream Detailed Mapping TLV. The label stack TLV 2533 MAY be omitted from the Downstream Detailed Mapping TLV. 2534 Furthermore, the "Validate FEC Stack" flag SHOULD NOT be set until an 2535 echo reply packet with a Downstream Detailed Mapping TLV is received. 2537 5. Security Considerations 2539 Overall, the security needs for LSP ping are similar to those of ICMP 2540 ping. 2542 There are at least three approaches to attacking LSRs using the 2543 mechanisms defined here. One is a Denial-of-Service attack, by 2544 sending MPLS echo requests/replies to LSRs and thereby increasing 2545 their workload. The second is obfuscating the state of the MPLS data 2546 plane liveness by spoofing, hijacking, replaying, or otherwise 2547 tampering with MPLS echo requests and replies. The third is an 2548 unauthorized source using an LSP ping to obtain information about the 2549 network. 2551 To avoid potential Denial-of-Service attacks, it is RECOMMENDED that 2552 implementations regulate the LSP ping traffic going to the control 2553 plane. A rate limiter SHOULD be applied to the well-known UDP port 2554 defined in Section 6.1. 2556 Unsophisticated replay and spoofing attacks involving faking or 2557 replaying MPLS echo reply messages are unlikely to be effective. 2558 These replies would have to match the Sender's Handle and Sequence 2559 Number of an outstanding MPLS echo request message. A non-matching 2560 replay would be discarded as the sequence has moved on, thus a spoof 2561 has only a small window of opportunity. However, to provide a 2562 stronger defense, an implementation MAY also validate the TimeStamp 2563 Sent by requiring an exact match on this field. 2565 To protect against unauthorized sources using MPLS echo request 2566 messages to obtain network information, it is RECOMMENDED that 2567 implementations provide a means of checking the source addresses of 2568 MPLS echo request messages against an access list before accepting 2569 the message. 2571 It is not clear how to prevent hijacking (non-delivery) of echo 2572 requests or replies; however, if these messages are indeed hijacked, 2573 LSP ping will report that the data plane is not working as it should. 2575 It does not seem vital (at this point) to secure the data carried in 2576 MPLS echo requests and replies, although knowledge of the state of 2577 the MPLS data plane may be considered confidential by some. 2578 Implementations SHOULD, however, provide a means of filtering the 2579 addresses to which echo reply messages may be sent. 2581 The value part of the Pad TLV contains a variable number of octets. 2582 With the exception of the first octet, these contents, if any, are 2583 ignored on receipt, and can therefore serve as a clandestine channel. 2585 When MPLS LSP Ping is used within an administrative domain, a 2586 deployment can increase security by using border filtering of 2587 incoming LSP Ping packets as well as outgoing LSP Ping packets. 2589 Although this document makes special use of 127/8 address, these are 2590 used only in conjunction with the UDP port 3503. Furthermore, these 2591 packets are only processed by routers. All other hosts MUST treat 2592 all packets with a destination address in the range 127/8 in 2593 accordance to RFC 1122. Any packet received by a router with a 2594 destination address in the range 127/8 without a destination UDP port 2595 of 3503 MUST be treated in accordance to RFC 1812. In particular, 2596 the default behavior is to treat packets destined to a 127/8 address 2597 as "martians". 2599 If a network operator wants to prevent tracing inside a tunnel, one 2600 can use the Pipe Model [RFC3443], i.e., hide the outer MPLS tunnel by 2601 not propagating the MPLS TTL into the outer tunnel (at the start of 2602 the outer tunnel). By doing this, MPLS traceroute packets will not 2603 expire in the outer tunnel and the outer tunnel will not get traced. 2605 If one doesn't wish to expose the details of the new outer LSP, then 2606 the Nil FEC can be used to hide those details. Using the Nil FEC 2607 ensures that the trace progresses without false negatives and all 2608 transit nodes (of the new outer tunnel) perform some minimal 2609 validations on the received MPLS echo requests. 2611 6. IANA Considerations 2613 6.1. TCP and UDP Port Number 2615 The TCP and UDP port number 3503 has been allocated by IANA for LSP 2616 echo requests and replies. 2618 6.2. MPLS LSP Ping Parameters 2620 IANA maintains all the registries within the "Multi-Protocol Label 2621 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" at 2622 [IANA-MPLS-LSP-PING]. 2624 The following subsections detail the name spaces managed by IANA. 2625 For some of these name spaces, the space is divided into assignment 2626 ranges; the following terms are used in describing the procedures by 2627 which IANA allocates values: "Standards Action" (as defined in 2628 [RFC5226]), "Specification Required", and "Vendor Private Use". 2630 Values from "Specification Required" ranges MUST be registered with 2631 IANA. The request MUST be made via an Experimental RFC that 2632 describes the format and procedures for using the code point; the 2633 actual assignment is made during the IANA actions for the RFC. 2635 Values from "Vendor Private" ranges MUST NOT be registered with IANA; 2636 however, the message MUST contain an enterprise code as registered 2637 with the IANA SMI Private Network Management Private Enterprise 2638 Numbers. For each name space that has a Vendor Private range, it 2639 must be specified where exactly the SMI Private Enterprise Number 2640 resides; see below for examples. In this way, several enterprises 2641 (vendors) can use the same code point without fear of collision. 2643 6.2.1. Message Types, Reply Modes, Return Codes 2645 The IANA has created and will maintain registries for Message Types, 2646 Reply Modes, and Return Codes. Each of these can take values in the 2647 range 0-255. Assignments in the range 0-191 are via Standards 2648 Action; assignments in the range 192-251 are made via "Specification 2649 Required"; values in the range 252-255 are for Vendor Private Use, 2650 and MUST NOT be allocated. 2652 If any of these fields fall in the Vendor Private range, a top-level 2653 Vendor Enterprise Number TLV MUST be present in the message. 2655 Message Types defined in this document are the following: 2657 Value Meaning 2658 ----- ------- 2659 1 MPLS echo request 2660 2 MPLS echo reply 2662 Reply Modes defined in this document are the following: 2664 Value Meaning 2665 ----- ------- 2666 1 Do not reply 2667 2 Reply via an IPv4/IPv6 UDP packet 2668 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 2669 4 Reply via application level control channel 2671 Return Codes defined in this document are listed in Section 3.1. 2673 IANA is requested to update the Reference to all these values to 2674 point to this document. 2676 6.2.2. TLVs 2678 The IANA has created and maintains a registry for the Type field of 2679 top-level TLVs as well as for any associated sub-TLVs. Note the 2680 meaning of a sub-TLV is scoped by the TLV. The number spaces for the 2681 sub-TLVs of various TLVs are independent. 2683 The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the 2684 range 0-16383 and 32768-49161 are made via Standards Action as 2685 defined in [RFC5226]; assignments in the range 16384-31743 and 2686 49162-64511 are made via "Specification Required" as defined above; 2687 values in the range 31744-32767 and 64512-65535 are for Vendor 2688 Private Use, and MUST NOT be allocated. 2690 If a TLV or sub-TLV has a Type that falls in the range for Vendor 2691 Private Use, the Length MUST be at least 4, and the first four octets 2692 MUST be that vendor's SMI Private Enterprise Number, in network octet 2693 order. The rest of the Value field is private to the vendor. 2695 TLVs and sub-TLVs defined in this document are the following: 2697 Type Sub-Type Value Field 2698 ---- -------- ----------- 2699 1 Target FEC Stack 2700 1 LDP IPv4 prefix 2701 2 LDP IPv6 prefix 2702 3 RSVP IPv4 LSP 2703 4 RSVP IPv6 LSP 2704 5 Unassigned 2705 6 VPN IPv4 prefix 2706 7 VPN IPv6 prefix 2707 8 L2 VPN endpoint 2708 9 "FEC 128" Pseudowire - IPv4 (Deprecated) 2709 10 "FEC 128" Pseudowire - IPv4 2710 11 "FEC 129" Pseudowire - IPv4 2711 12 BGP labeled IPv4 prefix 2712 13 BGP labeled IPv6 prefix 2713 14 Generic IPv4 prefix 2714 15 Generic IPv6 prefix 2715 16 Nil FEC 2716 24 "FEC 128" Pseudowire - IPv6 2717 25 "FEC 129" Pseudowire - IPv6 2718 2 Downstream Mapping (Deprecated) 2719 3 Pad 2720 4 Unassigned 2721 5 Vendor Enterprise Number 2722 6 Unassigned 2723 7 Interface and Label Stack 2724 8 Unassigned 2725 9 Errored TLVs 2726 Any value The TLV not understood 2727 10 Reply TOS Byte 2728 20 Downstream Detailed Mapping 2730 IANA is requested to update the Reference to all these values to 2731 point to this document. 2733 6.2.3. Global Flags 2735 IANA has created a sub-registry of the "Multi-Protocol Label 2736 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 2737 registry. The sub-registry is called the "Global Flags" registry. 2739 This registry tracks the assignment of 16 flags in the Global Flags 2740 field of the MPLS LSP ping echo request message. The flags are 2741 numbered from 0 (most significant bit, transmitted first) to 15. 2743 New entries are assigned by Standards Action. 2745 Initial entries in the registry are as follows: 2747 Bit number | Name | Reference 2748 ------------+----------------------------+-------------- 2749 15 | V Flag | This Document 2750 14 | T Flag | [RFC6425] 2751 13 | R Flag | [RFC6426] 2752 12-0 | Unassigned | This Document 2754 6.2.4. Downstream Detailed Mapping Address Type 2756 This document extends RFC 4379 by defining a new address type for use 2757 with the Downstream Mapping and Downstream Detailed Mapping TLVs. 2758 IANA has established a registry to assign address types for use with 2759 the Downstream Mapping and Downstream Detailed Mapping TLVs, 2760 initially allocates the following assignments: 2762 Type # Address Type K Octets Reference 2763 ------ ------------ -------- ------------------------- 2764 1 IPv4 Numbered 16 This document 2765 2 IPv4 Unnumbered 16 This document 2766 3 IPv6 Numbered 40 This document 2767 4 IPv6 Unnumbered 28 This document 2768 5 Non IP 12 RFC 6426 2770 Downstream Mapping Address Type Registry 2772 Because the field in this case is an 8-bit field, the allocation 2773 policy for this registry is "Standards Action." 2775 6.2.5. DS Flags 2777 This document defines the Downstream Mapping (DSMAP) TLV and the 2778 Downstream Detailed Mapping (DDMAP) TLV, which have Type 2 and Type 2779 20 respectively assigned from the "Multi-Protocol Label Switching 2780 (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry. 2782 DSMAP has been deprecated by DDMAP, but both TLVs share a field: DS 2783 Flags. 2785 IANA has created and now maintains a registry entitled "DS Flags". 2787 The registration policy for this registry is Standards Action 2788 [RFC5226]. 2790 IANA has made the following initial assignments: 2792 Registry Name: DS Flags 2794 Bit number Name Reference 2795 ---------- ---------------------------------------- --------- 2796 7 N: Treat as a Non-IP Packet This RFC 2797 6 I: Interface and Label Stack Object Request This RFC 2798 5-0 Unassigned 2800 6.2.6. Multipath Types 2802 IANA has created and now maintains a registry entitled "Multipath 2803 Types". 2805 The registration policies [RFC5226] for this registry are as follows: 2807 0-250 Standards Action 2808 251-254 Experimental Use 2809 255 Standards Action 2811 IANA has made the following initial assignments: 2813 Registry Name: Multipath Types 2815 Value Meaning Reference 2816 ---------- ---------------------------------------- --------- 2817 0 no multipath This document 2818 1 Unassigned 2819 2 IP address This document 2820 3 Unassigned 2821 4 IP address range This document 2822 5-7 Unassigned 2823 8 Bit-masked IP address set This document 2824 9 Bit-masked label set This document 2825 10-250 Unassigned 2826 251-254 Experimental Use This document 2827 255 Reserved This document 2829 6.2.7. Pad Type 2831 IANA has created and now maintain a registry entitled "Pad Types". 2833 The registration policies [RFC5226] for this registry are: 2835 0-250 Standards Action 2836 251-254 Experimental Use 2837 255 Standards Action 2839 IANA has made the following initial assignments: 2841 Registry Name: Pad Types 2843 Value Meaning Reference 2844 ---------- ---------------------------------------- --------- 2845 0 Reserved This document 2846 1 Drop Pad TLV from reply This document 2847 2 Copy Pad TLV to reply This document 2848 3-250 Unassigned 2849 251-254 Experimental Use This document 2850 255 Reserved This document 2852 6.2.8. Interface and Label Stack Address Type 2854 IANA has created and now maintains a registry entitled "Interface and 2855 Label Stack Address Types". 2857 The registration policies [RFC5226] for this registry are: 2859 0-250 Standards Action 2860 251-254 Experimental Use 2861 255 Standards Action 2863 IANA has made the following initial assignments: 2865 Registry Name: Interface and Label Stack Address Types 2867 Value Meaning Reference 2868 ---------- ---------------------------------------- --------- 2869 0 Reserved This document 2870 1 IPv4 Numbered This document 2871 2 IPv4 Unnumbered This document 2872 3 IPv6 Numbered This document 2873 4 IPv6 Unnumbered This document 2874 5-250 Unassigned 2875 251-254 Experimental Use This document 2876 255 Reserved This document 2878 6.3. IPv4 Special-Purpose Address Registry 2880 IANA is requested to update the reference in Note 1 of the IANA IPv4 2881 Special-Purpose Address Registry [IANA-SPECIAL-IPv4] to point to this 2882 document. 2884 7. Acknowledgements 2886 The original acknowledgements from RFC 4379 state the following: 2888 This document is the outcome of many discussions among many 2889 people, including Manoj Leelanivas, Paul Traina, Yakov Rekhter, 2890 Der-Hwa Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani 2891 Aggarwal, and Vanson Lim. 2893 The description of the Multipath Information sub-field of the 2894 Downstream Mapping TLV was adapted from text suggested by Curtis 2895 Villamizar. 2897 We would like to thank Loa Andersson for motivating the advancement 2898 of this bis specification. 2900 We also would like to thank Alexander Vainshtein, Yimin Shen, Curtis 2901 Villamizar, David Allan, Vincent Roca, Mirja Kuhlewind, and Elwyn 2902 Davies for their review and useful comments. 2904 8. References 2906 8.1. Normative References 2908 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2909 Communication Layers", STD 3, RFC 1122, 2910 DOI 10.17487/RFC1122, October 1989, 2911 . 2913 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2914 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2915 . 2917 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 2918 DOI 10.17487/RFC2113, February 1997, 2919 . 2921 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2922 Requirement Levels", BCP 14, RFC 2119, 2923 DOI 10.17487/RFC2119, March 1997, 2924 . 2926 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 2927 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 2928 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 2929 . 2931 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2932 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2933 DOI 10.17487/RFC4271, January 2006, 2934 . 2936 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 2937 Label Switched (MPLS) Data Plane Failures", RFC 4379, 2938 DOI 10.17487/RFC4379, February 2006, 2939 . 2941 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2942 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2943 DOI 10.17487/RFC5226, May 2008, 2944 . 2946 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2947 "Network Time Protocol Version 4: Protocol and Algorithms 2948 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2949 . 2951 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 2952 Performing Label Switched Path Ping (LSP Ping) over MPLS 2953 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 2954 . 2956 [RFC7506] Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert 2957 Option for MPLS Operations, Administration, and 2958 Maintenance (OAM)", RFC 7506, DOI 10.17487/RFC7506, April 2959 2015, . 2961 8.2. Informative References 2963 [IANA-ENT] 2964 Internet Assigned Numbers Authority (IANA), "PRIVATE 2965 ENTERPRISE NUMBERS", 2966 . 2968 [IANA-MPLS-LSP-PING] 2969 Internet Assigned Numbers Authority (IANA), "Multi- 2970 Protocol Label Switching (MPLS) Label Switched Paths 2971 (LSPs) Ping Parameters", . 2974 [IANA-SPECIAL-IPv4] 2975 Internet Assigned Numbers Authority (IANA), "IANA IPv4 2976 Special-Purpose Address Registry", 2977 . 2980 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2981 RFC 792, DOI 10.17487/RFC0792, September 1981, 2982 . 2984 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 2985 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 2986 . 2988 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2989 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2990 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2991 . 2993 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 2994 in Multi-Protocol Label Switching (MPLS) Networks", 2995 RFC 3443, DOI 10.17487/RFC3443, January 2003, 2996 . 2998 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 2999 Private Network (VPN) Terminology", RFC 4026, 3000 DOI 10.17487/RFC4026, March 2005, 3001 . 3003 [RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP 3004 Virtual Private Networks (VPNs)", RFC 4365, 3005 DOI 10.17487/RFC4365, February 2006, 3006 . 3008 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 3009 G. Heron, "Pseudowire Setup and Maintenance Using the 3010 Label Distribution Protocol (LDP)", RFC 4447, 3011 DOI 10.17487/RFC4447, April 2006, 3012 . 3014 [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- 3015 Multipoint Traffic-Engineered MPLS Label Switched Paths 3016 (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, 3017 . 3019 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 3020 LAN Service (VPLS) Using BGP for Auto-Discovery and 3021 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 3022 . 3024 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 3025 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 3026 October 2007, . 3028 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 3029 Circuit Connectivity Verification (VCCV): A Control 3030 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 3031 December 2007, . 3033 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 3034 Label Assignment and Context-Specific Label Space", 3035 RFC 5331, DOI 10.17487/RFC5331, August 2008, 3036 . 3038 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 3039 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 3040 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 3041 2009, . 3043 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 3044 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 3045 Failures in Point-to-Multipoint MPLS - Extensions to LSP 3046 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 3047 . 3049 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 3050 On-Demand Connectivity Verification and Route Tracing", 3051 RFC 6426, DOI 10.17487/RFC6426, November 2011, 3052 . 3054 [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label 3055 Switched Path (LSP) Ping for Pseudowire Forwarding 3056 Equivalence Classes (FECs) Advertised over IPv6", 3057 RFC 6829, DOI 10.17487/RFC6829, January 2013, 3058 . 3060 [RFC7537] Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and 3061 S. Aldrin, "IANA Registries for LSP Ping Code Points", 3062 RFC 7537, DOI 10.17487/RFC7537, May 2015, 3063 . 3065 Appendix A. Deprecated TLVs and sub-TLVs (Non-normative) 3067 This appendix describes deprecated elements, which are non-normative 3068 for an implementation. They are included in this document for 3069 historical and informational purposes. 3071 A.1. Target FEC Stack 3073 A.1.1. FEC 128 Pseudowire - IPv4 (Deprecated) 3075 FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID 3076 (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero 3077 32-bit connection ID. The PW Type is a 15-bit number indicating the 3078 encapsulation type. It is carried right justified in the field below 3079 termed encapsulation type with the high-order bit set to zero. Both 3080 of these fields are treated in this protocol as opaque values. 3082 When an FEC 128 is encoded in a label stack, the following format is 3083 used. The value field consists of the Remote PE IPv4 Address (the 3084 destination address of the targeted LDP session), the PW ID, and the 3085 encapsulation type as follows: 3087 0 1 2 3 3088 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 3089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3090 | Remote PE IPv4 Address | 3091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3092 | PW ID | 3093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3094 | PW Type | Must Be Zero | 3095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3097 This FEC is deprecated and is retained only for backward 3098 compatibility. Implementations of LSP ping SHOULD accept and process 3099 this TLV, but SHOULD send LSP ping echo requests with the new TLV 3100 (see Section 3.2.9), unless explicitly configured to use the old TLV. 3102 An LSR receiving this TLV SHOULD use the source IP address of the LSP 3103 echo request to infer the sender's PE address. 3105 A.2. Downstream Mapping (Deprecated) 3107 The Downstream Mapping object is a TLV that MAY be included in an 3108 echo request message. Only one Downstream Mapping object may appear 3109 in an echo request. The presence of a Downstream Mapping object is a 3110 request that Downstream Mapping objects be included in the echo 3111 reply. If the replying router is the destination of the FEC, then a 3112 Downstream Mapping TLV SHOULD NOT be included in the echo reply. 3114 Otherwise the replying router SHOULD include a Downstream Mapping 3115 object for each interface over which this FEC could be forwarded. 3116 For a more precise definition of the notion of "downstream", see 3117 Section 3.4.2, "Downstream Router and Interface". 3119 The Length is K + M + 4*N octets, where M is the Multipath Length, 3120 and N is the number of Downstream Labels. Values for K are found in 3121 the description of Address Type below. The Value field of a 3122 Downstream Mapping has the following format: 3124 0 1 2 3 3125 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 3126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3127 | MTU | Address Type | DS Flags | 3128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3129 | Downstream IP Address (4 or 16 octets) | 3130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3131 | Downstream Interface Address (4 or 16 octets) | 3132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3133 | Multipath Type| Depth Limit | Multipath Length | 3134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3135 . . 3136 . (Multipath Information) . 3137 . . 3138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3139 | Downstream Label | Protocol | 3140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3141 . . 3142 . . 3143 . . 3144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3145 | Downstream Label | Protocol | 3146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3148 Maximum Transmission Unit (MTU) 3150 The MTU is the size in octets of the largest MPLS frame (including 3151 label stack) that fits on the interface to the Downstream LSR. 3153 Address Type 3155 The Address Type indicates if the interface is numbered or 3156 unnumbered. It also determines the length of the Downstream IP 3157 Address and Downstream Interface fields. The resulting total for 3158 the initial part of the TLV is listed in the table below as "K 3159 Octets". The Address Type is set to one of the following values: 3161 Type # Address Type K Octets 3162 ------ ------------ -------- 3163 1 IPv4 Numbered 16 3164 2 IPv4 Unnumbered 16 3165 3 IPv6 Numbered 40 3166 4 IPv6 Unnumbered 28 3168 DS Flags 3170 The DS Flags field is a bit vector with the following format: 3172 0 1 2 3 4 5 6 7 3173 +-+-+-+-+-+-+-+-+ 3174 | Rsvd(MBZ) |I|N| 3175 +-+-+-+-+-+-+-+-+ 3177 Two flags are defined currently, I and N. The remaining flags MUST 3178 be set to zero when sending and ignored on receipt. 3180 Flag Name and Meaning 3181 ---- ---------------- 3182 I Interface and Label Stack Object Request 3184 When this flag is set, it indicates that the replying 3185 router SHOULD include an Interface and Label Stack 3186 Object in the echo reply message. 3188 N Treat as a Non-IP Packet 3190 Echo request messages will be used to diagnose non-IP 3191 flows. However, these messages are carried in IP 3192 packets. For a router that alters its ECMP algorithm 3193 based on the FEC or deep packet examination, this flag 3194 requests that the router treat this as it would if the 3195 determination of an IP payload had failed. 3197 Downstream IP Address and Downstream Interface Address 3199 IPv4 addresses and interface indices are encoded in 4 octets; IPv6 3200 addresses are encoded in 16 octets. 3202 If the interface to the downstream LSR is numbered, then the 3203 Address Type MUST be set to IPv4 or IPv6, the Downstream IP 3204 Address MUST be set to either the downstream LSR's Router ID or 3205 the interface address of the downstream LSR, and the Downstream 3206 Interface Address MUST be set to the downstream LSR's interface 3207 address. 3209 If the interface to the downstream LSR is unnumbered, the Address 3210 Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP 3211 Address MUST be the downstream LSR's Router ID, and the Downstream 3212 Interface Address MUST be set to the index assigned by the 3213 upstream LSR to the interface. 3215 If an LSR does not know the IP address of its neighbor, then it 3216 MUST set the Address Type to either IPv4 Unnumbered or IPv6 3217 Unnumbered. For IPv4, it must set the Downstream IP Address to 3218 127.0.0.1; for IPv6 the address is set to 0::1. In both cases, 3219 the interface index MUST be set to 0. If an LSR receives an Echo 3220 Request packet with either of these addresses in the Downstream IP 3221 Address field, this indicates that it MUST bypass interface 3222 verification but continue with label validation. 3224 If the originator of an Echo Request packet wishes to obtain 3225 Downstream Mapping information but does not know the expected 3226 label stack, then it SHOULD set the Address Type to either IPv4 3227 Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set the 3228 Downstream IP Address to 224.0.0.2; for IPv6 the address MUST be 3229 set to FF02::2. In both cases, the interface index MUST be set to 3230 0. If an LSR receives an Echo Request packet with the all-routers 3231 multicast address, then this indicates that it MUST bypass both 3232 interface and label stack validation, but return Downstream 3233 Mapping TLVs using the information provided. 3235 Multipath Type 3237 The following Multipath Types are defined: 3239 Key Type Multipath Information 3240 --- ---------------- --------------------- 3241 0 no multipath Empty (Multipath Length = 0) 3242 2 IP address IP addresses 3243 4 IP address range low/high address pairs 3244 8 Bit-masked IP IP address prefix and bit mask 3245 address set 3246 9 Bit-masked label set Label prefix and bit mask 3248 Type 0 indicates that all packets will be forwarded out this one 3249 interface. 3251 Types 2, 4, 8, and 9 specify that the supplied Multipath 3252 Information will serve to exercise this path. 3254 Depth Limit 3255 The Depth Limit is applicable only to a label stack and is the 3256 maximum number of labels considered in the hash; this SHOULD be 3257 set to zero if unspecified or unlimited. 3259 Multipath Length 3261 The length in octets of the Multipath Information. 3263 Multipath Information 3265 Address or label values encoded according to the Multipath Type. 3266 See Section 3.4.1.1.1 for encoding details. 3268 Downstream Label(s) 3270 The set of labels in the label stack as it would have appeared if 3271 this router were forwarding the packet through this interface. 3272 Any Implicit Null labels are explicitly included. Labels are 3273 treated as numbers, i.e., they are right justified in the field. 3275 A Downstream Label is 24 bits, in the same format as an MPLS label 3276 minus the TTL field, i.e., the MSBit of the label is bit 0, the 3277 LSBit is bit 19, the Traffic Class (TC) bits are bits 20-22, and 3278 bit 23 is the S bit. The replying router SHOULD fill in the TC 3279 and S bits; the LSR receiving the echo reply MAY choose to ignore 3280 these bits. 3282 Protocol 3284 The Protocol is taken from the following table: 3286 Protocol # Signaling Protocol 3287 ---------- ------------------ 3288 0 Unknown 3289 1 Static 3290 2 BGP 3291 3 LDP 3292 4 RSVP-TE 3294 Authors' Addresses 3296 Kireeti Kompella 3297 Juniper Networks, Inc. 3299 Email: kireeti.kompella@gmail.com 3300 George Swallow 3301 Cisco Systems, Inc. 3303 Email: swallow.ietf@gmail.com 3305 Carlos Pignataro (editor) 3306 Cisco Systems, Inc. 3308 Email: cpignata@cisco.com 3310 Nagendra Kumar 3311 Cisco Systems, Inc. 3313 Email: naikumar@cisco.com 3315 Sam Aldrin 3316 Google 3318 Email: aldrin.ietf@gmail.com 3320 Mach(Guoyi) Chen 3321 Huawei 3323 Email: mach.chen@huawei.com