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