idnits 2.17.1 draft-ietf-mpls-lsp-ping-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == The page length should not exceed 58 lines per page, but there was 40 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 8 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2005) is 6892 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Kireeti Kompella 2 Internet Draft Juniper Networks, Inc. 3 Category: Standards Track 4 Expiration Date: November 2005 5 George Swallow 6 Cisco Systems, Inc. 8 May 2005 10 Detecting MPLS Data Plane Failures 12 draft-ietf-mpls-lsp-ping-09.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 5 of RFC3667. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 This document describes a simple and efficient mechanism that can be 41 used to detect data plane failures in Multi-Protocol Label Switching 42 (MPLS) Label Switched Paths (LSPs). There are two parts to this 43 document: information carried in an MPLS "echo request" and "echo 44 reply" for the purposes of fault detection and isolation; and 45 mechanisms for reliably sending the echo reply. 47 Changes since last revision 49 (This section to be removed before publication.) 51 o fixed the optional vs. mandatory TLV wording 52 o Removed the Error TLV (which never found use and was undefined) 53 o Removed an extraneous paragraph from the processing rules and did 54 some further word-smithing 55 o Removed Appendix A on CR-LDP 56 o Added an Address Type field to the Address and Interface Object; 57 combined the IPv4 & IPv6 formats into a single TLV 58 o Modified example TLV / Sub-TLV to be more instructive on 59 determining (Sub-)TLV lengths 60 o Removed the BGP Next Hop field from the BGP Labeled IPv4 FEC 61 o Added the BGP Labeled IPv6 FEC 62 o Corrected the length calculation for the Downsteam Mapping TLV 63 o Added two special values for the Downstream Router ID 64 o Added an error code for upstream Interface Index Unknown 65 o Added all requested allocations to the IANA section 66 o Spelling and Word-smithing 68 Contents 70 1 Introduction .............................................. 4 71 1.1 Conventions ............................................... 4 72 1.2 Structure of this document ................................ 4 73 1.3 Contributors .............................................. 4 74 2 Motivation ................................................ 5 75 3 Packet Format ............................................. 6 76 3.1 Return Codes .............................................. 10 77 3.2 Target FEC Stack .......................................... 11 78 3.2.1 LDP IPv4 Prefix ........................................... 12 79 3.2.2 LDP IPv6 Prefix ........................................... 12 80 3.2.3 RSVP IPv4 LSP ............................................. 13 81 3.2.4 RSVP IPv6 LSP ............................................. 13 82 3.2.5 VPN IPv4 Prefix ........................................... 14 83 3.2.6 VPN IPv6 Prefix ........................................... 14 84 3.2.7 L2 VPN Endpoint ........................................... 15 85 3.2.8 FEC 128 Pseudowire (Deprecated) ........................... 15 86 3.2.9 FEC 128 Pseudowire (Current) .............................. 16 87 3.2.10 FEC 129 Pseudowire ........................................ 16 88 3.2.11 BGP Labeled IPv4 Prefix ................................... 17 89 3.2.12 BGP Labeled IPv6 Prefix ................................... 17 90 3.2.13 Generic IPv4 Prefix ....................................... 18 91 3.2.14 Generic IPv6 Prefix ....................................... 18 92 3.2.15 Nil FEC ................................................... 19 93 3.3 Downstream Mapping ........................................ 19 94 3.3.1 Multipath Information Encoding ............................ 24 95 3.3.2 Downstream Router and Interface ........................... 26 96 3.4 Pad TLV ................................................... 26 97 3.5 Vendor Enterprise Code .................................... 27 98 3.6 Interface and Label Stack ................................. 27 99 3.7 Errored TLVs .............................................. 28 100 3.8 Reply TOS Byte TLV ........................................ 29 101 4 Theory of Operation ....................................... 29 102 4.1 Dealing with Equal-Cost Multi-Path (ECMP) ................. 30 103 4.2 Testing LSPs That Are Used to Carry MPLS Payloads ......... 31 104 4.3 Sending an MPLS Echo Request .............................. 31 105 4.4 Receiving an MPLS Echo Request ............................ 32 106 4.5 Sending an MPLS Echo Reply ................................ 35 107 4.6 Receiving an MPLS Echo Reply .............................. 36 108 4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 36 109 4.8 Non-compliant Routers ..................................... 37 110 5 References ................................................ 37 111 6 Security Considerations ................................... 38 112 7 IANA Considerations ....................................... 38 113 7.1 Message Types, Reply Modes, Return Codes .................. 39 114 7.2 TLVs ...................................................... 39 115 8 Acknowledgments ........................................... 40 117 1. Introduction 119 This document describes a simple and efficient mechanism that can be 120 used to detect data plane failures in MPLS LSPs. There are two parts 121 to this document: information carried in an MPLS "echo request" and 122 "echo reply"; and mechanisms for transporting the echo reply. The 123 first part aims at providing enough information to check correct 124 operation of the data plane, as well as a mechanism to verify the 125 data plane against the control plane, and thereby localize faults. 126 The second part suggests two methods of reliable reply channels for 127 the echo request message, for more robust fault isolation. 129 An important consideration in this design is that MPLS echo requests 130 follow the same data path that normal MPLS packets would traverse. 131 MPLS echo requests are meant primarily to validate the data plane, 132 and secondarily to verify the data plane against the control plane. 133 Mechanisms to check the control plane are valuable, but are not cov- 134 ered in this document. 136 1.1. Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 142 1.2. Structure of this document 144 The body of this memo contains four main parts: motivation, MPLS echo 145 request/reply packet format, LSP ping operation, and a reliable 146 return path. It is suggested that first-time readers skip the actual 147 packet formats and read the Theory of Operation first; the document 148 is structured the way it is to avoid forward references. 150 1.3. Contributors 152 The following made vital contributions to all aspects of this docu- 153 ment, and much of the material came out of debate and discussion 154 among this group. 156 Ronald P. Bonica, Juniper Networks, Inc. 157 Dave Cooper, Global Crossing 158 Ping Pan, Hammerhead Systems 159 Nischal Sheth, Juniper Networks, Inc. 160 Sanjay Wadhwa, Juniper Networks, Inc. 162 2. Motivation 164 When an LSP fails to deliver user traffic, the failure cannot always 165 be detected by the MPLS control plane. There is a need to provide a 166 tool that would enable users to detect such traffic "black holes" or 167 misrouting within a reasonable period of time; and a mechanism to 168 isolate faults. 170 In this document, we describe a mechanism that accomplishes these 171 goals. This mechanism is modeled after the ping/traceroute paradigm: 172 ping (ICMP echo request [ICMP]) is used for connectivity checks, and 173 traceroute is used for hop-by-hop fault localization as well as path 174 tracing. This document specifies a "ping mode" and a "traceroute" 175 mode for testing MPLS LSPs. 177 The basic idea is to verify that packets that belong to a particular 178 Forwarding Equivalence Class (FEC) actually end their MPLS path on an 179 LSR that is an egress for that FEC. This document proposes that this 180 test be carried out by sending a packet (called an "MPLS echo 181 request") along the same data path as other packets belonging to this 182 FEC. An MPLS echo request also carries information about the FEC 183 whose MPLS path is being verified. This echo request is forwarded 184 just like any other packet belonging to that FEC. In "ping" mode 185 (basic connectivity check), the packet should reach the end of the 186 path, at which point it is sent to the control plane of the egress 187 LSR, which then verifies whether it is indeed an egress for the FEC. 188 In "traceroute" mode (fault isolation), the packet is sent to the 189 control plane of each transit LSR, which performs various checks that 190 it is indeed a transit LSR for this path; this LSR also returns fur- 191 ther information that helps check the control plane against the data 192 plane, i.e., that forwarding matches what the routing protocols 193 determined as the path. 195 One way these tools can be used is to periodically ping a FEC to 196 ensure connectivity. If the ping fails, one can then initiate a 197 traceroute to determine where the fault lies. One can also periodi- 198 cally traceroute FECs to verify that forwarding matches the control 199 plane; however, this places a greater burden on transit LSRs and thus 200 should be used with caution. 202 3. Packet Format 204 An MPLS echo request is a (possibly labeled) IPv4 or IPv6 UDP packet; 205 the contents of the UDP packet have the following format: 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Version Number | Global Flags | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Message Type | Reply mode | Return Code | Return Subcode| 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Sender's Handle | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Sequence Number | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | TimeStamp Sent (seconds) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | TimeStamp Sent (microseconds) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | TimeStamp Received (seconds) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | TimeStamp Received (microseconds) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | TLVs ... | 227 . . 228 . . 229 . . 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 The Version Number is currently 1. (Note: the Version Number is to 234 be incremented whenever a change is made that affects the ability of 235 an implementation to correctly parse or process an MPLS echo 236 request/reply. These changes include any syntactic or semantic 237 changes made to any of the fixed fields, or to any TLV or sub-TLV 238 assignment or format that is defined at a certain version number. 239 The Version Number may not need to be changed if an optional TLV or 240 sub-TLV is added.) 242 The Global Flags field is a bit vector with the following format: 244 0 1 245 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | MBZ |V| 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 One flag is defined for now, the V bit; the rest MUST be set to zero 251 when sending, and ignored on receipt. 253 The V (Validate FEC Stack) flag is set to 1 if the sender wants the 254 receiver to perform FEC stack validation; if V is 0, the choice is 255 left to the receiver. 257 The Message Type is one of the following: 259 Value Meaning 260 ----- ------- 261 1 MPLS Echo Request 262 2 MPLS Echo Reply 264 The Reply Mode can take one of the following values: 266 Value Meaning 267 ----- ------- 268 1 Do not reply 269 2 Reply via an IPv4/IPv6 UDP packet 270 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 271 4 Reply via application level control channel 273 An MPLS echo request with "Do not reply" may be used for one-way con- 274 nectivity tests; the receiving router may log gaps in the sequence 275 numbers and/or maintain delay/jitter statistics. An MPLS echo 276 request would normally have "Reply via an IPv4/IPv6 UDP packet"; if 277 the normal IP return path is deemed unreliable, one may use "Reply 278 via an IPv4/IPv6 UDP packet with Router Alert" (note that this 279 requires that all intermediate routers understand and know how to 280 forward MPLS echo replies). The echo reply uses the same IP version 281 number as the received echo request, i.e., an IPv4 encapsulated echo 282 reply is sent in response to an IPv4 encapsulated echo request. 284 Any application which supports an IP control channel between its con- 285 trol entities may set the Reply Mode to 4 to ensure that replies use 286 that same channel. Further definition of this codepoint is applica- 287 tion specific and thus beyond the scope of this document. 289 Return Codes and Subcodes are described in the next section. 291 the Sender's Handle is filled in by the sender, and returned 292 unchanged by the receiver in the echo reply (if any). There are no 293 semantics associated with this handle, although a sender may find 294 this useful for matching up requests with replies. 296 The Sequence Number is assigned by the sender of the MPLS echo 297 request, and can be (for example) used to detect missed replies. 299 The TimeStamp Sent is the time-of-day (in seconds and microseconds, 300 wrt the sender's clock) when the MPLS echo request is sent. The 301 TimeStamp Received in an echo reply is the time-of-day (wrt the 302 receiver's clock) that the corresponding echo request was received. 304 TLVs (Type-Length-Value tuples) have the following format: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type | Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Value | 312 . . 313 . . 314 . . 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Types are defined below; Length is the length of the Value field in 319 octets. The Value field depends on the Type; it is zero padded to 320 align to a four-octet boundary. TLVs may be nested within other 321 TLVs, in which case the nested TLVs are called sub-TLVs. Sub-TLVs 322 have independent types and MUST also be four-octet aligned. 324 Two examples follow. The LDP IPv4 FEC sub-TLV has the following for- 325 mat: 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type = 1 (LDP IPv4 FEC) | Length = 5 | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | IPv4 prefix | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Prefix Length | Must Be Zero | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 The Length for this TLV is 5. A Target FEC Stack TLV which contains 338 an LDP IPv4 FEC sub-TLV and a VPN IPv4 FEC sub-TLV has the format: 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Type = 1 (FEC TLV) | Length = 12 | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | sub-Type = 1 (LDP IPv4 FEC) | Length = 5 | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | IPv4 prefix | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Prefix Length | Must Be Zero | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | sub-Type = 6 (VPN IPv4 FEC) | Length = 13 | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Route Distinguisher | 354 | (8 octets) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | IPv4 prefix | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Prefix Length | Must Be Zero | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 A description of the Types and Values of the top level TLVs for LSP 362 ping are given below: 364 Type # Value Field 365 ------ ----------- 366 1 Target FEC Stack 367 2 Downstream Mapping 368 3 Pad 369 4 Not Assigned 370 5 Vendor Enterprise Code 371 6 Not Assigned 372 7 Interface and Label Stack 373 8 Not Assigned 374 9 Errored TLVs 375 10 Reply TOS Byte 377 Types less than 32768 (i.e., with the high order bit equal to 0) are 378 mandatory TLVs that MUST either be supported by an implementation or 379 result in the return code of 2 ("One or more of the TLVs was not 380 understood") being sent in the echo response. 382 Types greater than or equal to 32768 (i.e., with the high order bit 383 equal to 1) are optional TLVs that SHOULD be ignored if the implemen- 384 tation does not understand or support them. 386 3.1. Return Codes 388 The Return Code is set to zero by the sender. The receiver can set 389 it to one of the values listed below. The notation refers to 390 the Return Subcode. This field is filled in with the stack-depth for 391 those codes which specify that. For all other codes the Return Sub- 392 code MUST be set to zero. 394 Value Meaning 395 ----- ------- 397 0 No return code 399 1 Malformed echo request received 401 2 One or more of the TLVs was not understood 403 3 Replying router is an egress for the FEC at stack 404 depth 406 4 Replying router has no mapping for the FEC at stack 407 depth 409 5 Downstream Mapping Mismatch (See Note 1) 411 6 Upstream Interface Index Unknown (See Note 1) 413 7 Reserved 415 8 Label switched at stack-depth 417 9 Label switched but no MPLS forwarding at stack-depth 418 420 10 Mapping for this FEC is not the given label at stack 421 depth 423 11 No label entry at stack-depth 425 12 Protocol not associated with interface at FEC stack 426 depth 428 13 Premature termination of ping due to label stack 429 shrinking to a single label 431 Note 1 433 The Return Subcode contains the point in the label stack where pro- 434 cessing was terminated. If the RSC is 0, no labels were processed. 435 Otherwise the packet would have been label switched at depth RSC. 437 3.2. Target FEC Stack 439 A Target FEC Stack is a list of sub-TLVs. The number of elements is 440 determined by the looking at the sub-TLV length fields. 442 Sub-Type Length Value Field 443 -------- ------ ----------- 444 1 5 LDP IPv4 prefix 445 2 17 LDP IPv6 prefix 446 3 20 RSVP IPv4 LSP 447 4 56 RSVP IPv6 LSP 448 5 Not Assigned 449 6 13 VPN IPv4 prefix 450 7 25 VPN IPv6 prefix 451 8 14 L2 VPN endpoint 452 9 10 "FEC 128" Pseudowire (deprecated) 453 10 14 "FEC 128" Pseudowire 454 11 13+ "FEC 129" Pseudowire 455 12 5 BGP labeled IPv4 prefix 456 13 17 BGP labeled IPv6 prefix 457 14 5 Generic IPv4 prefix 458 15 17 Generic IPv6 prefix 459 16 4*N Nil FEC 461 Other FEC Types will be defined as needed. 463 Note that this TLV defines a stack of FECs, the first FEC element 464 corresponding to the top of the label stack, etc. 466 An MPLS echo request MUST have a Target FEC Stack that describes the 467 FEC stack being tested. For example, if an LSR X has an LDP mapping 468 for 192.168.1.1 (say label 1001), then to verify that label 1001 does 469 indeed reach an egress LSR that announced this prefix via LDP, X can 470 send an MPLS echo request with a FEC Stack TLV with one FEC in it, 471 namely of type LDP IPv4 prefix, with prefix 192.168.1.1/32, and send 472 the echo request with a label of 1001. 474 Say LSR X wanted to verify that a label stack of <1001, 23456> is the 475 right label stack to use to reach a VPN IPv4 prefix of 10/8 in VPN 476 foo. Say further that LSR Y with loopback address 192.168.1.1 477 announced prefix 10/8 with Route Distinguisher RD-foo-Y (which may in 478 general be different from the Route Distinguisher that LSR X uses in 479 its own advertisements for VPN foo), label 23456 and BGP nexthop 480 192.168.1.1. Finally, suppose that LSR X receives a label binding of 481 1001 for 192.168.1.1 via LDP. X has two choices in sending an MPLS 482 echo request: X can send an MPLS echo request with a FEC Stack TLV 483 with a single FEC of type VPN IPv4 prefix with a prefix of 10/8 and a 484 Route Distinguisher of RD-foo-Y. Alternatively, X can send a FEC 485 Stack TLV with two FECs, the first of type LDP IPv4 with a prefix of 486 192.168.1.1/32 and the second of type of IP VPN with a prefix 10/8 487 with Route Distinguisher of RD-foo-Y. In either case, the MPLS echo 488 request would have a label stack of <1001, 23456>. (Note: in this 489 example, 1001 is the "outer" label and 23456 is the "inner" label.) 491 3.2.1. LDP IPv4 Prefix 493 The value consists of four octets of an IPv4 prefix followed by one 494 octet of prefix length in bits; the format is given below. The IPv4 495 prefix is in network byte order; if the prefix is shorter than 32 496 bits, trailing bits SHOULD be set to zero. See [LDP] for an example 497 of a Mapping for an IPv4 FEC. 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | IPv4 prefix | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Prefix Length | Must Be Zero | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 3.2.2. LDP IPv6 Prefix 509 The value consists of sixteen octets of an IPv6 prefix followed by 510 one octet of prefix length in bits; the format is given below. The 511 IPv6 prefix is in network byte order; if the prefix is shorter than 512 128 bits, the trailing bits SHOULD be set to zero. See [LDP] for an 513 example of a Mapping for an IPv6 FEC. 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | IPv6 prefix | 519 | (16 octets) | 520 | | 521 | | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Prefix Length | Must Be Zero | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 3.2.3. RSVP IPv4 LSP 528 The value has the format below. The value fields are taken from 529 [RFC3209, sections 4.6.1.1 and 4.6.2.1]. 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | IPv4 tunnel end point address | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Must Be Zero | Tunnel ID | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Extended Tunnel ID | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | IPv4 tunnel sender address | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Must Be Zero | LSP ID | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 3.2.4. RSVP IPv6 LSP 547 The value has the format below. The value fields are taken from 548 [RFC3209, sections 4.6.1.2 and 4.6.2.2]. 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | IPv6 tunnel end point address | 554 | | 555 | | 556 | | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Must Be Zero | Tunnel ID | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Extended Tunnel ID | 561 | | 562 | | 563 | | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | IPv6 tunnel sender address | 566 | | 567 | | 568 | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Must Be Zero | LSP ID | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 3.2.5. VPN IPv4 Prefix 575 The value field consists of the Route Distinguisher advertised with 576 the VPN IPv4 prefix, the IPv4 prefix (with trailing 0 bits to make 32 577 bits in all) and a prefix length, as follows: 579 0 1 2 3 580 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 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Route Distinguisher | 583 | (8 octets) | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | IPv4 prefix | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Prefix Length | Must Be Zero | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 3.2.6. VPN IPv6 Prefix 592 The value field consists of the Route Distinguisher advertised with 593 the VPN IPv6 prefix, the IPv6 prefix (with trailing 0 bits to make 594 128 bits in all) and a prefix length, as follows: 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Route Distinguisher | 600 | (8 octets) | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | IPv6 prefix | 603 | | 604 | | 605 | | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Prefix Length | Must Be Zero | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 3.2.7. L2 VPN Endpoint 612 The value field consists of a Route Distinguisher (8 octets), the 613 sender (of the ping)'s VE ID (2 octets), the receiver's VE ID (2 614 octets), and an encapsulation type (2 octets), formatted as follows: 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Route Distinguisher | 620 | (8 octets) | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Sender's VE ID | Receiver's VE ID | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Encapsulation Type | Must Be Zero | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 3.2.8. FEC 128 Pseudowire (Deprecated) 629 The value field consists of the remote PE address (the destination 630 address of the targeted LDP session), a VC ID and an encapsulation 631 type, as follows: 633 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Remote PE Address | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | VC ID | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Encapsulation Type | Must Be Zero | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 This FEC will be deprecated, and is retained only for backward com- 644 patibility. Implementations of LSP ping SHOULD accept and process 645 this TLV, but SHOULD send LSP ping echo requests with the new TLV 646 (see next section), unless explicitly asked by configuration to use 647 the old TLV. 649 An LSR receiving this TLV SHOULD use the source IP address of the LSP 650 echo request to infer the Sender's PE Address. 652 3.2.9. FEC 128 Pseudowire (Current) 654 The value field consists of the sender's PE address (the source 655 address of the targeted LDP session), the remote PE address (the des- 656 tination address of the targeted LDP session), a VC ID and an encap- 657 sulation type, as follows: 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Sender's PE Address | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Remote PE Address | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | VC ID | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Encapsulation Type | Must Be Zero | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 3.2.10. FEC 129 Pseudowire 673 The Length of this TLV is 13 + AGI length + SAII length + TAII 674 length. Padding is used to make the total length a multiple of 4; 675 the length of the padding is not included in the Length field. 677 0 1 2 3 678 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 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Sender's PE Address | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Remote PE Address | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | PW Type | AGI Length | SAII Length | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | TAII Length | AGI Value ... SAII Value ... TAII Value ... | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 . ... . 689 . . 690 . . 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | ... | 0-3 octets of zero padding | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 3.2.11. BGP Labeled IPv4 Prefix 697 The value field consists the IPv4 prefix (with trailing 0 bits to 698 make 32 bits in all), and the prefix length, as follows: 700 0 1 2 3 701 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | IPv4 Prefix | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Prefix Length | Must Be Zero | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 3.2.12. BGP Labeled IPv6 Prefix 710 The value consists of sixteen octets of an IPv6 prefix followed by 711 one octet of prefix length in bits; the format is given below. The 712 IPv6 prefix is in network byte order; if the prefix is shorter than 713 128 bits, the trailing bits SHOULD be set to zero. 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | IPv6 prefix | 719 | (16 octets) | 720 | | 721 | | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Prefix Length | Must Be Zero | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 3.2.13. Generic IPv4 Prefix 728 The value consists of four octets of an IPv4 prefix followed by one 729 octet of prefix length in bits; the format is given below. The IPv4 730 prefix is in network byte order; if the prefix is shorter than 32 731 bits, trailing bits SHOULD be set to zero. This FEC is used if the 732 protocol advertising the label is unknown, or may change during the 733 course of the LSP. An example is an inter-AS LSP that may be sig- 734 naled by LDP in one AS, by RSVP-TE in another AS, and by BGP between 735 the ASes, such as is common for inter-AS VPNs. 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | IPv4 prefix | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Prefix Length | Must Be Zero | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 3.2.14. Generic IPv6 Prefix 747 The value consists of sixteen octets of an IPv6 prefix followed by 748 one octet of prefix length in bits; the format is given below. The 749 IPv6 prefix is in network byte order; if the prefix is shorter than 750 128 bits, the trailing bits SHOULD be set to zero. 752 0 1 2 3 753 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 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | IPv6 prefix | 756 | (16 octets) | 757 | | 758 | | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Prefix Length | Must Be Zero | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 3.2.15. Nil FEC 765 At times labels from the reserved range, e.g. Router Alert and 766 Explicit-null, may be added to the label stack for various diagnostic 767 purposes such as influencing load-balancing. These labels may have 768 no explicit FEC associated with them. The Nil FEC stack is defined 769 to allow a Target FEC stack sub-TLV to be added to the target FEC 770 stack to account for such labels so that proper validation can still 771 be performed. 773 The Length is 4. Labels are 20 bit values treated as numbers. 774 stack. 776 0 1 2 3 777 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Label | MBZ | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Label is the actual label value inserted in the label stack; the MBZ 783 fields MUST be zero when sent, and ignored on receipt. 785 3.3. Downstream Mapping 787 The Downstream Mapping object is a TLV which MAY be included in an 788 echo request message. Only one Downstream Mapping object may appear 789 in an echo request. The presence of a Downstream Mapping object is a 790 request that Downstream Mapping objects be included in the echo 791 reply. If the replying router is the destination of the FEC, then a 792 Downstream Mapping TLV SHOULD NOT be included in the echo reply. 793 Otherwise the replying router SHOULD include a Downstream Mapping 794 object for each interface over which this FEC could be forwarded. 795 For a more precise definition of the notion of "downstream", see the 796 section named "Downstream". 798 The Length is K + M + 4*N octets, where M is the Multipath Length, 799 and N is the number of Downstream Labels. Values for K are found in 800 the description of Address Type below. The Value field of a Down- 801 stream Mapping has the following format: 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 | MTU | Address Type | DS Flags | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Downstream IP Address (4 or 16 octets) | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Downstream Interface Address (4 or 16 octets) | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Multipath Type| Depth Limit | Multipath Length | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 . . 815 . (Multipath Information) . 816 . . 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Downstream Label | Protocol | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 . . 821 . . 822 . . 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Downstream Label | Protocol | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 Maximum Transmission Unit (MTU) 829 The MTU is the largest MPLS frame (including label stack) that fits 830 on the interface to the Downstream LSR. 832 Address Type 834 The Address Type indicates if the interface is numbered or unnum- 835 bered. It also determines the length of the Downstream IP Address 836 and Downstream Interface fields. The resulting total for the initial 837 part of the TLV is listed in the table below as "K Octets". The 838 Address Type is set to one of the following values: 840 Type # Address Type K Octets 841 ------ ------------ -------- 842 1 IPv4 Numbered 16 843 2 IPv4 Unnumbered 16 844 3 IPv6 Numbered 40 845 4 IPv6 Unnumbered 28 847 DS Flags 849 The DS Flags field is a bit vector with the following format: 851 0 1 2 3 4 5 6 7 852 +-+-+-+-+-+-+-+-+ 853 | Rsvd(MBZ) |I|N| 854 +-+-+-+-+-+-+-+-+ 856 Two flags are defined currently, I and N. The remaining flags MUST 857 be set to zero when sending, and ignored on receipt. 859 Flag Name and Meaning 860 ---- ---------------- 862 I Interface and Label Stack Object Request 864 When this flag is set, it indicates that the replying 865 router SHOULD include an Interface and Label Stack 866 Object in the echo reply message 868 N Treat as a Non-IP Packet 870 Echo request messages will be used to diagnose non-IP 871 flows. However, these messages are carried in IP 872 packets. For a router which alters its ECMP algorithm 873 based on the FEC or deep packet examination, this flag 874 requests that the router treat this as it would if the 875 determination of an IP payload had failed. 877 Downstream IP Address and Downstream Interface Address 879 IPv4 addresses and and interface indices are encoded in 4 octets, 880 IPv6 addresses are encoded in 16 octets. 882 If the interface to the downstream LSR is numbered, then the Address 883 Type MUST be set to IPv4 or IPv6, the Downstream IP Address MUST be 884 set to either the downstream LSR's Router ID or the interface address 885 of the downstream LSR, and the Downstream Interface Address MUST be 886 set to the downstream LSR's interface address. 888 If the interface to the downstream LSR is unnumbered, the Address 889 Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP 890 Address MUST be the downstream LSR's Router ID, and the Downstream 891 Interface Address MUST be set to the index assigned by the upstream 892 LSR to the interface. 894 If an LSR does not know the IP address of its neighbor, then it MUST 895 set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. 896 For IPv4 it must set the Downstream IP Address to 127.0.0.1, for IPv6 897 the address is set to 0::1. In both cases the interface index MUST 898 be set to 0. If an LSR receives an Echo Request packet with either 899 of these addresses in the Downstream IP Address field, this indicates 900 that it MUST bypass interface verification but continue with label 901 validation. 903 If the originator of an Echo Request packet wishes to obtain Down- 904 stream mapping information but does not know the expected label stack 905 then it SHOULD set the Address Type to either IPv4 Unnumbered or IPv6 906 Unnumbered. For IPv4 it MUST set the Downstream IP Address to 907 224.0.0.2, for IPv6 the address MUST be set to FF02::2. In both 908 cases the interface index MUST be set to 0. If an LSR receives an 909 Echo Request packet with the all-routers multicast address, then this 910 indicates that it MUST bypass both interface and label stack valida- 911 tion, but return Downstream Mapping TLVs using the information pro- 912 vided. 914 Multipath Type 916 The following Mutipath Types are defined: 918 Key Type Multipath Information 919 --- ---------------- --------------------- 920 0 no multipath Empty (Multipath Length = 0) 921 2 IP address IP addresses 922 4 IP address range low/high address pairs 923 8 Bit-masked IPv4 IP address prefix and bit mask 924 address set 925 9 Bit-masked label set Label prefix and bit mask 927 Type 0 indicates that all packets will be forwarded out this one 928 interface. 930 Types 2, 4, 8 and 9 specify that the supplied Multipath Information 931 will serve to exercise this path. 933 Depth Limit 935 The Depth Limit is applicable only to a label stack, and is the maxi- 936 mum number of labels considered in the hash; this SHOULD be set to 937 zero if unspecified or unlimited. 939 Multipath Length 941 The length in octets of the Multipath Information. 943 Multipath Information 945 Address or label values encoded according to the Multipath Type. See 946 the next section below for encoding details. 948 Downstream Label(s) 950 The set of labels in the label stack as it would have appeared if 951 this router were forwarding the packet through this interface. Any 952 Implicit Null labels are explicitly included. Labels are treated as 953 numbers, i.e. they are right justified in the field. 955 A Downstream Label is 24 bits, in the same format as an MPLS label 956 minus the TTL field, i.e., the MSBit of the label is bit 0, the LSbit 957 is bit 19, the EXP bits are bits 20-22, and bit 23 is the S bit. The 958 replying router SHOULD fill in the EXP and S bits; the LSR receiving 959 the echo reply MAY choose to ignore these bits. 961 Protocol 963 The Protocol is taken from the following table: 965 Protocol # Signaling Protocol 966 ---------- ------------------ 967 0 Unknown 968 1 Static 969 2 BGP 970 3 LDP 971 4 RSVP-TE 973 3.3.1. Multipath Information Encoding 975 The multipath information encodes labels or addresses which will 976 exercise this path. The multipath information depends on the multi- 977 path type. The contents of the field are shown in the table above. 978 IP addresses are drawn from the range 127/8. Labels are treated as 979 numbers, i.e. they are right justified in the field. For Type 4, 980 ranges indicated by Address pairs MUST NOT overlap and MUST be in 981 ascending sequence. 983 Type 8 allows a denser encoding of IP address. The IPv4 prefix is 984 formatted as a base IPv4 address with the non-prefix low order bits 985 set to zero. The maximum prefix length is 27. Following the prefix 986 is a mask of length 2^(32-prefix length) bits. Each bit set to one 987 represents a valid address. The address is the base IPv4 address 988 plus the position of the bit in the mask where the bits are numbered 989 left to right beginning with zero. For example the IP addresses 990 127.2.1.0, 127.2.1.5-127.2.1.15, and 127.2.1.20-127.2.1.29 would be 991 encoded as follows: 993 0 1 2 3 994 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 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 |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| 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 |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| 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 Type 9 allows a denser encoding of Labels. The label prefix is for- 1002 matted as a base label value with the non-prefix low order bits set 1003 to zero. The maximum prefix (including leading zeros due to encod- 1004 ing) length is 27. Following the prefix is a mask of length 1005 2^(32-prefix length) bits. Each bit set to one represents a valid 1006 Label. The label is the base label plus the position of the bit in 1007 the mask where the bits are numbered left to right beginning with 1008 zero. Label values of all the odd numbers between 1152 and 1279 1009 would be encoded as follows: 1011 0 1 2 3 1012 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 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 |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| 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 |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| 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 |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| 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 |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| 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 |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| 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 If the received multipath information is non-null, the labels and IP 1026 addresses MUST be picked from the set provided. If none of these 1027 labels or addresses map to a particular downstream interface, then 1028 for that interface, the type MUST be set to 0. If the received mul- 1029 tipath information is null, (i.e. Multipath Length = 0, or for Types 1030 8 and 9 a mask of all zeroes) the receiver the type MUST be set to 0. 1032 For example, suppose LSR X at hop 10 has two downstream LSRs Y and Z 1033 for the FEC in question. The received X could return Multipath Type 1034 4, with low/high IP addresses of 127.1.1.1->127.1.1.255 for down- 1035 stream LSR Y and 127.2.1.1->127.2.1.255 for downstream LSR Z. The 1036 head end reflects this information to LSR Y. Y, which has three 1037 downstream LSRs U, V and W, computes that 127.1.1.1->127.1.1.127 1038 would go to U and 127.1.1.128-> 127.1.1.255 would go to V. Y would 1039 then respond with 3 Downstream Mappings: to U, with Multipath Type 4 1040 (127.1.1.1->127.1.1.127); to V, with Multipath Type 4 1041 (127.1.1.127->127.1.1.255); and to W, with Multipath Type 0. 1043 Note that computing multi-path information may impose a significant 1044 processing burden on the receiver. A receiver MAY thus choose to 1045 process a subset of the received prefixes. The sender, on receiving 1046 a reply to a Downstream Map with partial information, SHOULD assume 1047 that the prefixes missing in the reply were skipped by the receiver, 1048 and MAY re-request information about them in a new echo request. 1050 3.3.2. Downstream Router and Interface 1052 The notion of "downstream router" and "downstream interface" should 1053 be explained. Consider an LSR X. If a packet that was originated 1054 with TTL n>1 arrived with outermost label L and TTL=1 at LSR X, X 1055 must be able to compute which LSRs could receive the packet if it was 1056 originated with TTL=n+1, over which interface the request would 1057 arrive and what label stack those LSRs would see. (It is outside the 1058 scope of this document to specify how this computation is done.) The 1059 set of these LSRs/interfaces are the downstream routers/interfaces 1060 (and their corresponding labels) for X with respect to L. Each pair 1061 of downstream router and interface requires a separate Downstream 1062 Mapping to be added to the reply. 1064 The case where X is the LSR originating the echo request is a special 1065 case. X needs to figure out what LSRs would receive the MPLS echo 1066 request for a given FEC Stack that X originates with TTL=1. 1068 The set of downstream routers at X may be alternative paths (see the 1069 discussion below on ECMP) or simultaneous paths (e.g., for MPLS mul- 1070 ticast). In the former case, the Multipath Information is used as a 1071 hint to the sender as to how it may influence the choice of these 1072 alternatives. 1074 3.4. Pad TLV 1076 The value part of the Pad TLV contains a variable number (>= 1) of 1077 octets. The first octet takes values from the following table; all 1078 the other octets (if any) are ignored. The receiver SHOULD verify 1079 that the TLV is received in its entirety, but otherwise ignores the 1080 contents of this TLV, apart from the first octet. 1082 Value Meaning 1083 ----- ------- 1084 1 Drop Pad TLV from reply 1085 2 Copy Pad TLV to reply 1086 3-255 Reserved for future use 1088 3.5. Vendor Enterprise Code 1090 The Length is always 4; the value is the SMI Enterprise code, in net- 1091 work octet order, of the vendor with a Vendor Private extension to 1092 any of the fields in the fixed part of the message, in which case 1093 this TLV MUST be present. If none of the fields in the fixed part of 1094 the message have vendor private extensions, inclusion of this this 1095 TLV in is OPTIONAL. Vendor private ranges for Message Types, Reply 1096 Modes, and Return Codes have been defined. When any of these are 1097 used the Vendor Enterprise Code TLV MUST be included in the message. 1099 3.6. Interface and Label Stack 1101 The Interface and Label Stack TLV MAY be included in a reply message 1102 to report the interface on which the request message was received and 1103 the label stack which was on the packet when it was received. Only 1104 one such object may appear. The purpose of the object is to allow 1105 the upstream router to obtain the exact interface and label stack 1106 information as it appears at the replying LSR. 1108 The Length is K + 4*N octets, N is the number of labels in the Label 1109 Stack. Values for K are found in the description of Address Type 1110 below. The Value field of a Downstream Mapping has the following 1111 format: 1113 The value field of a Interface and Label Stack TLV has the following 1114 format: 1116 0 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Address Type | Must be Zero | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | IP Address (4 or 16 octets) | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Interface (4 or 16 octets) | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Downstream Interface Address | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 . . 1128 . . 1129 . Label Stack . 1130 . . 1131 . . 1132 . . 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 Address Type 1137 The Address Type indicates if the interface is numbered or unnum- 1138 bered. It also determines the length of the Downstream IP Address 1139 and Downstream Interface fields. The resulting total for the initial 1140 part of the TLV is listed in the table below as "K Octets". The 1141 Address Type is set to one of the following values: 1143 Type # Address Type K Octets 1144 ------ ------------ -------- 1145 1 IPv4 Numbered 12 1146 2 IPv4 Unnumbered 12 1147 3 IPv6 Numbered 36 1148 4 IPv6 Unnumbered 24 1150 IP Address and Interface 1152 IPv4 addresses and and interface indices are encoded in 4 octets, 1153 IPv6 addresses are encoded in 16 octets. 1155 If the interface upon which the echo request message was received is 1156 numbered, then the Address Type MUST be set to IPv4 or IPv6, the IP 1157 Address MUST be set to either the LSR's Router ID or the interface 1158 address, and the Interface MUST be set to the interface address. 1160 If the interface unnumbered, the Address Type MUST be either IPv4 1161 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the LSR's 1162 Router ID, and the Interface MUST be set to the index assigned to the 1163 interface. 1165 Label Stack 1167 The label stack of the received echo request message. If any TTL 1168 values have been changed by this router, they SHOULD be restored. 1170 3.7. Errored TLVs 1172 The following TLV is a TLV which MAY be included in an echo reply to 1173 inform the sender of an echo request of Mandatory TLVs either not 1174 supported by an implementation, or parsed and found to be in error. 1176 The Value field contains the TLVs not understood encoded as sub-TLVs. 1178 0 1 2 3 1179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Type = 9 | Length | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Value | 1184 . . 1185 . . 1186 . . 1187 | | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 3.8. Reply TOS Byte TLV 1192 This TLV MAY be used by the originator of the echo request to 1193 request 1194 that a echo reply be sent with the IP header TOS byte set to 1195 the value specified in the TLV. This TLV has a length of 4 with 1196 the following value field. 1198 0 1 2 3 1199 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 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Reply-TOS Byte| Must be zero | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 4. Theory of Operation 1206 An MPLS echo request is used to test a particular LSP. The LSP to be 1207 tested is identified by the "FEC Stack"; for example, if the LSP was 1208 set up via LDP, and is to an egress IP address of 10.1.1.1, the FEC 1209 stack contains a single element, namely, an LDP IPv4 prefix sub-TLV 1210 with value 10.1.1.1/32. If the LSP being tested is an RSVP LSP, the 1211 FEC stack consists of a single element that captures the RSVP Session 1212 and Sender Template which uniquely identifies the LSP. 1214 FEC stacks can be more complex. For example, one may wish to test a 1215 VPN IPv4 prefix of 10.1/8 that is tunneled over an LDP LSP with 1216 egress 10.10.1.1. The FEC stack would then contain two sub-TLVs, the 1217 bottom being a VPN IPv4 prefix, and the top being an LDP IPv4 prefix. 1218 If the underlying (LDP) tunnel were not known, or was considered 1219 irrelevant, the FEC stack could be a single element with just the VPN 1220 IPv4 sub-TLV. 1222 When an MPLS echo request is received, the receiver is expected to 1223 verify that the control plane and data plane are both healthy (for 1224 the FEC stack being pinged), and that the two planes are in sync. 1225 The procedures for this are in section 4.4 below. 1227 4.1. Dealing with Equal-Cost Multi-Path (ECMP) 1229 LSPs need not be simple point-to-point tunnels. Frequently, a single 1230 LSP may originate at several ingresses, and terminate at several 1231 egresses; this is very common with LDP LSPs. LSPs for a given FEC 1232 may also have multiple "next hops" at transit LSRs. At an ingress, 1233 there may also be several different LSPs to choose from to get to the 1234 desired endpoint. Finally, LSPs may have backup paths, detour paths 1235 and other alternative paths to take should the primary LSP go down. 1237 To deal with the last two first: it is assumed that the LSR sourcing 1238 MPLS echo requests can force the echo request into any desired LSP, 1239 so choosing among multiple LSPs at the ingress is not an issue. The 1240 problem of probing the various flavors of backup paths that will typ- 1241 ically not be used for forwarding data unless the primary LSP is down 1242 will not be addressed here. 1244 Since the actual LSP and path that a given packet may take may not be 1245 known a priori, it is useful if MPLS echo requests can exercise all 1246 possible paths. This, while desirable, may not be practical, because 1247 the algorithms that a given LSR uses to distribute packets over 1248 alternative paths may be proprietary. 1250 To achieve some degree of coverage of alternate paths, there is a 1251 certain latitude in choosing the destination IP address and source 1252 UDP port for an MPLS echo request. This is clearly not sufficient; 1253 in the case of traceroute, more latitude is offered by means of the 1254 Multipath Information of the Downstream Mapping TLV. This is used as 1255 follows. An ingress LSR periodically sends an MPLS traceroute mes- 1256 sage to determine whether there are multipaths for a given LSP. If 1257 so, each hop will provide some information how each of its downstream 1258 paths can be exercised. The ingress can then send MPLS echo requests 1259 that exercise these paths. If several transit LSRs have ECMP, the 1260 ingress may attempt to compose these to exercise all possible paths. 1261 However, full coverage may not be possible. 1263 4.2. Testing LSPs That Are Used to Carry MPLS Payloads 1265 To detect certain LSP breakages, it may be necessary to encapsulate 1266 an MPLS echo request packet with at least one additional label when 1267 testing LSPs that are used to carry MPLS payloads (such as LSPs used 1268 to carry L2VPN and L3VPN traffic. For example, when testing LDP or 1269 RSVP-TE LSPs, just sending an MPLS echo request packet may not detect 1270 instances where the router immediately upstream of the destination of 1271 the LSP ping may forward the MPLS echo request successfully over an 1272 interface not configured to carry MPLS payloads because of the use of 1273 penultimate hop popping. Since the receiving router has no means to 1274 differentiate whether the IP packet was sent unlabeled or implicitly 1275 labeled, the addition of labels shimmed above the MPLS echo request 1276 (using the Nil FEC) will prevent a router from forwarding such a 1277 packet out unlabeled interfaces. 1279 4.3. Sending an MPLS Echo Request 1281 An MPLS echo request is a (possibly) labeled UDP packet. The IP 1282 header is set as follows: the source IP address is a routable address 1283 of the sender; the destination IP address is a (randomly chosen) 1284 address from 127/8; the IP TTL is set to 1. The source UDP port is 1285 chosen by the sender; the destination UDP port is set to 3503 1286 (assigned by IANA for MPLS echo requests). The Router Alert option 1287 is set in the IP header. 1289 If the echo request is labeled, one may (depending on what is being 1290 pinged) set the TTL of the innermost label to 1, to prevent the ping 1291 request going farther than it should. Examples of this include ping- 1292 ing a VPN IPv4 or IPv6 prefix, an L2 VPN end point or a pseudowire. 1293 This can also be accomplished by inserting a router alert label above 1294 this label; however, this may lead to the undesired side effect that 1295 MPLS echo requests take a different data path than actual data. 1297 In "ping" mode (end-to-end connectivity check), the TTL in the outer- 1298 most label is set to 255. In "traceroute" mode (fault isolation 1299 mode), the TTL is set successively to 1, 2, .... 1301 The sender chooses a Sender's Handle, and a Sequence Number. When 1302 sending subsequent MPLS echo requests, the sender SHOULD increment 1303 the sequence number by 1. However, a sender MAY choose to send a 1304 group of echo requests with the same sequence number to improve the 1305 chance of arrival of at least one packet with that sequence number. 1307 The TimeStamp Sent is set to the time-of-day (in seconds and 1308 microseconds) that the echo request is sent. The TimeStamp Received 1309 is set to zero. 1311 An MPLS echo request MUST have a FEC Stack TLV. Also, the Reply Mode 1312 must be set to the desired reply mode; the Return Code and Subcode 1313 are set to zero. In the "traceroute" mode, the echo request SHOULD 1314 include a Downstream Mapping TLV. 1316 4.4. Receiving an MPLS Echo Request 1318 An LSR X that receives an MPLS echo request first parses the packet 1319 to ensure that it is a well-formed packet, and that the TLVs that are 1320 not marked "Ignore" are understood. If not, X SHOULD send an MPLS 1321 echo reply with the Return Code set to "Malformed echo request 1322 received" or "TLV not understood" (as appropriate), and the Subcode 1323 set to zero. In the latter case, the misunderstood TLVs (only) are 1324 included in the reply. 1326 If the echo request is good, X notes the interface I over which the 1327 echo was received, and the label stack with which it came. 1329 For reporting purposes the bottom of stack is considered to be stack- 1330 depth of 1. This is to establish an absolute reference for the case 1331 where the stack may have more labels than are in the FEC stack. Fur- 1332 ther, in all the error codes listed in this document a stack-depth of 1333 0 means "no value specified". This allows compatibility with exist- 1334 ing implementations which do not use the Return Subcode field. 1336 X employs two variables, called FEC-stack-depth and Label-stack- 1337 depth. X sets Label-stack-depth to the number of labels in the 1338 received label stack. If the label-stack-depth is 0, assume there is 1339 one implicit null label and set label-stack-depth to 1. FEC-stack- 1340 depth is used later and need not be initialized. Processing now con- 1341 tinues with the following steps: 1343 Label_Validation: 1345 If the label at Label-stack-depth is valid, goto Label_Operation. 1346 If not, set Best-return-code to 11, "No label entry at stack-depth" 1347 and Best-return-subcode to Label-stack-depth. Goto 1348 Send_Reply_Packet. 1350 Label_Operation: 1352 Switch on label operation. 1354 Case: Pop and Continue Processing (Note: this includes 1355 Explicit_Null and Router_Alert) 1357 If Label-stack-depth is greater than 1, decrement Label-stack- 1358 depth and goto Label_Validation. Otherwise, set FEC-stack-depth 1359 to 1, set Best-return-code to 3 "Replying router is an egress for 1360 the FEC at stack depth", set Best-return-subcode to 1 and goto 1361 Egress_Processing. 1363 Case: Swap or Pop and Switch based on Popped Label 1365 If the label operation is either swap or pop and switch based on 1366 the popped label, Best-return-code to 8, "Label switched at 1367 stack-depth" and Best-return-subcode to Label-stack-depth. 1369 If a Downstream Mapping TLV is present, a Downstream mapping TLVs 1370 SHOULD be created for each multipath. 1372 Determine the output interface. If it is not valid to forward a 1373 labeled packet on this interface, set Best-return-code to Return 1374 Code 9, "Label switched but no MPLS forwarding at stack-depth" 1375 and set Best-return-subcode to Label-stack-depth and goto 1376 Send_Reply_Packet. (Note: this return code is set even if Label- 1377 stack-depth is one.) 1379 If no Downstream Mapping TLV is present, or the Downstream IP 1380 Address is set to the All-Routers multicast address goto 1381 Send_Reply_Packet. 1383 Verify that the IP address, interface address and label stack 1384 match the received interface and label stack. If the IP address 1385 is either 127.0.0.1 or 0::1 bypass the interface check, and set 1386 Best-return-code to 6, "Upstream Interface Index Unknown". For 1387 any other error, set Best-return-code to 5, "Downstream Mapping 1388 Mis-match". For either error, an Interface and Label Stack TLV 1389 SHOULD be created. If Best-return-code equals 5, goto 1390 Send_Reply_Packet. 1392 If the "Validate FEC Stack" flag is not set, goto 1393 Send_Reply_Packet. 1395 Locate the label at Label-stack-depth in the Downstream Labels by 1396 counting from the bottom of the stack, skipping over, but count- 1397 ing Implicit Null labels and set FEC-stack-depth to that depth. 1398 (Note: If the Downstream Labels contain one or more Implicit Null 1399 labels, this may be at a depth greater than Label-stack-depth.) 1401 If the depth of the FEC stack is greater than or equal to FEC- 1402 stack-depth, Perform FEC Checking. If FEC-status is 2, set Best- 1403 return-code to 10, "Mapping for this FEC is not the given label 1404 at stack-depth". 1406 If the return code is 1 set Best-return-code to FEC-return-code 1407 and Best-return-subcode to FEC-stack-depth. 1409 Goto Send_Reply_Packet. 1411 Egress_Processing: 1413 If no Downstream Mapping TLV is present, goto Egress_FEC_Valida- 1414 tion. 1416 Verify that the IP address, interface address and label stack match 1417 the received interface and label stack. If not, set Best-return- 1418 code to 5, "Downstream Mapping Mis-match". A Received Interface 1419 and Label Stack TLV SHOULD be created. Goto Send_Reply_Packet. 1421 Egress_FEC_Validation: 1423 Perform FEC checking. If FEC-status is 1, set Best-return-code 1424 to FEC-code and Best-return-subcode to FEC-stack-depth. Goto 1425 Send_Reply_Packet. 1427 Increment FEC-stack-depth. If FEC-stack-depth is greater than 1428 the number of FECs in the FEC-stack, goto Send_Reply_Packet. If 1429 FEC-status is 0, increment Label-stack-depth. Goto 1430 Egress_FEC_Validation. 1432 Send_Reply_Packet: 1434 Send an MPLS echo reply with a Return Code of Best-return-code, 1435 and a Return Subcode of Best-return-subcode. Include any TLVs 1436 created during the above process. The procedures for sending the 1437 echo reply are found in the next subsection below. 1439 FEC_Checking: 1441 This routine accepts a FEC, Label, and Interface. It returns two 1442 values, FEC-status and FEC-return-code, both of which are 1443 initialized to 0. 1445 If the FEC is the Nil FEC, check that Label is either 1446 Explicit_Null or Router_Alert. If so return. Else 1447 set FEC-return-code to 10, "Mapping for this FEC is not the given 1448 label at stack-depth". Set FEC-status to 1 and return. 1450 Check that the label mapping for FEC. If no mapping exists, set 1451 FEC-return-code to Return 4, "Replying router has no mapping for 1452 the FEC at stack-depth". Set FEC-status to 1. Return. 1454 If the label mapping for FEC is Implicit Null, set FEC-status to 1455 2. Goto Check_Protocol. 1457 If the label mapping for FEC is Label, goto Check_Protocol. Else 1458 set FEC-return-code to 10, "Mapping for this FEC is not the given 1459 label at stack-depth". Set FEC-status to 1 and return. 1461 Check_Protocol: 1463 Check what protocol would be used to advertise FEC. If it can be 1464 determined that no protocol associated with interface I would 1465 have advertised a FEC of that FEC-Type, set FEC-return-code to 1466 12, "Protocol not associated with interface at FEC stack-depth". 1467 Set FEC-status to 1. Return. 1469 4.5. Sending an MPLS Echo Reply 1471 An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response 1472 to an MPLS echo request. The source IP address is a routable address 1473 of the replier; the source port is the well-known UDP port for LSP 1474 ping. The destination IP address and UDP port are copied from the 1475 source IP address and UDP port of the echo request. The IP TTL is 1476 set to 255. If the Reply Mode in the echo request is "Reply via an 1477 IPv4 UDP packet with Router Alert", then the IP header MUST contain 1478 the Router Alert IP option. If the reply is sent over an LSP, the 1479 topmost label MUST in this case be the Router Alert label (1) (see 1480 [LABEL-STACK]). 1482 The format of the echo reply is the same as the echo request. The 1483 Sender's Handle, the Sequence Number and TimeStamp Sent are copied 1484 from the echo request; the TimeStamp Received is set to the time-of- 1485 day that the echo request is received (note that this information is 1486 most useful if the time-of-day clocks on the requester and the 1487 replier are synchronized). The FEC Stack TLV from the echo request 1488 MAY be copied to the reply. 1490 The replier MUST fill in the Return Code and Subcode, as determined 1491 in the previous subsection. 1493 If the echo request contains a Pad TLV, the replier MUST interpret 1494 the first octet for instructions regarding how to reply. 1496 If the replying router is the destination of the FEC, then Downstream 1497 Mapping TLVs SHOULD NOT be included in the echo reply. 1499 If the echo request contains a Downstream Mapping TLV, and the reply- 1500 ing router is not the destination of the FEC, the replier SHOULD com- 1501 pute its downstream routers and corresponding labels for the incoming 1502 label, and add Downstream Mapping TLVs for each one to the echo reply 1503 it sends back. 1505 If the Downstream Mapping TLV contains multipath information requir- 1506 ing more processing than the receiving router is willing to perform, 1507 the responding router MAY choose to respond with only a subset of 1508 multipaths contained in the echo request Downstream Map. (Note: The 1509 originator of the echo request MAY send another echo request with the 1510 multipath information that was not included in the reply.) 1512 4.6. Receiving an MPLS Echo Reply 1514 An LSR X should only receive an MPLS echo reply in response to an 1515 MPLS echo request that it sent. Thus, on receipt of an MPLS echo 1516 reply, X should parse the packet to assure that it is well-formed, 1517 then attempt to match up the echo reply with an echo request that it 1518 had previously sent, using the destination UDP port and the Sender's 1519 Handle. If no match is found, then X jettisons the echo reply; oth- 1520 erwise, it checks the Sequence Number to see if it matches. Gaps in 1521 the Sequence Number MAY be logged and SHOULD be counted. Once an 1522 echo reply is received for a given Sequence Number (for a given UDP 1523 port and Handle), the Sequence Number for subsequent echo requests 1524 for that UDP port and Handle SHOULD be incremented. 1526 If the echo reply contains Downstream Mappings, and X wishes to 1527 traceroute further, it SHOULD copy the Downstream Mapping(s) into its 1528 next echo request(s) (with TTL incremented by one). 1530 4.7. Issue with VPN IPv4 and IPv6 Prefixes 1532 Typically, a LSP ping for a VPN IPv4 or IPv6 prefix is sent with a 1533 label stack of depth greater than 1, with the innermost label having 1534 a TTL of 1. This is to terminate the ping at the egress PE, before 1535 it gets sent to the customer device. However, under certain circum- 1536 stances, the label stack can shrink to a single label before the ping 1537 hits the egress PE; this will result in the ping terminating prema- 1538 turely. One such scenario is a multi-AS Carrier's Carrier VPN. 1540 To get around this problem, one approach is for the LSR that receives 1541 such a ping to realize that the ping terminated prematurely, and send 1542 back error code 13. In that case, the initiating LSR can retry the 1543 ping after incrementing the TTL on the VPN label. In this fashion, 1544 the ingress LSR will sequentially try TTL values until it finds one 1545 that allows the VPN ping to reach the egress PE. 1547 4.8. Non-compliant Routers 1549 If the egress for the FEC Stack being pinged does not support MPLS 1550 ping, then no reply will be sent, resulting in possible "false nega- 1551 tives". If in "traceroute" mode, a transit LSR does not support LSP 1552 ping, then no reply will be forthcoming from that LSR for some TTL, 1553 say n. The LSR originating the echo request SHOULD try sending the 1554 echo request with TTL=n+1, n+2, ..., n+k to probe LSRs further down 1555 the path. In such a case, the echo request for TTL > n SHOULD be 1556 sent with Downstream Mapping TLV "Downstream IP Address" field set to 1557 the ALLROUTERs multicast address until a reply is received with a 1558 Downstream Mapping TLV. The Label Stack MAY be omitted from the 1559 Downstream Mapping TLV. Further the "Validate FEC Stack" flag SHOULD 1560 NOT be set until an echo reply packet with a Downstream Mapping TLV 1561 is received. 1563 5. References 1565 Normative References 1567 [IANA] Narten, T. and H. Alvestrand, "Guidelines for IANA 1568 Considerations", BCP 26, RFC 2434, October 1998. 1570 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1571 Requirement Levels", BCP 14, RFC 2119, March 1997. 1573 [LABEL-STACK] Rosen, E., et al, "MPLS Label Stack Encoding", 1574 RFC 3032, January 2001. 1576 Informative References 1578 [ICMP] Postel, J., "Internet Control Message Protocol", 1579 RFC 792. 1581 [LDP] Andersson, L., et al, "LDP Specification", RFC 3036, 1582 January 2001. 1584 6. Security Considerations 1586 There are at least two approaches to attacking LSRs using the mecha- 1587 nisms defined here. One is a Denial of Service attack, by sending 1588 MPLS echo requests/replies to LSRs and thereby increasing their work- 1589 load. The other is obfuscating the state of the MPLS data plane 1590 liveness by spoofing, hijacking, replaying or otherwise tampering 1591 with MPLS echo requests and replies. 1593 Authentication will help reduce the number of seemingly valid MPLS 1594 echo requests, and thus cut down the Denial of Service attacks; 1595 beyond that, each LSR must protect itself. To avoid potential Denial 1596 of Service attacks, it is RECOMMENDED that implementations regulate 1597 the LSP ping traffic going to the control plane. A rate limiter 1598 SHOULD be applied to the well-known UDP port defined below. 1600 Authentication sufficiently addresses spoofing, replay and most tam- 1601 pering attacks; one hopes to use some mechanism devised or suggested 1602 by the RPSec WG. It is not clear how to prevent hijacking (non- 1603 delivery) of echo requests or replies; however, if these messages are 1604 indeed hijacked, LSP ping will report that the data plane isn't work- 1605 ing as it should. 1607 It doesn't seem vital (at this point) to secure the data carried in 1608 MPLS echo requests and replies, although knowledge of the state of 1609 the MPLS data plane may be considered confidential by some. 1611 7. IANA Considerations 1613 The TCP and UDP port number 3503 has been allocated by IANA for LSP 1614 echo requests and replies. 1616 The following sections detail the new name spaces to be managed by 1617 IANA. For each of these name spaces, the space is divided into 1618 assignment ranges; the following terms are used in describing the 1619 procedures by which IANA allocates values: "Standards Action" (as 1620 defined in [IANA]); "Expert Review" and "Vendor Private Use". 1622 Values from "Expert Review" ranges MUST be registered with IANA, and 1623 MUST be accompanied by an Experimental RFC that describes the format 1624 and procedures for using the code point; the actual assignment is 1625 made during the IANA actions for the RFC. 1627 Values from "Vendor Private" ranges MUST NOT be registered with IANA; 1628 however, the message MUST contain an enterprise code as registered 1629 with the IANA SMI Network Management Private Enterprise Codes. For 1630 each name space that has a Vendor Private range, it must be specified 1631 where exactly the SMI Enterprise Code resides; see below for exam- 1632 ples. In this way, several enterprises (vendors) can use the same 1633 code point without fear of collision. 1635 7.1. Message Types, Reply Modes, Return Codes 1637 It is requested that IANA maintain registries for Message Types, 1638 Reply Modes, and Return Codes. Each of these can take values in the 1639 range 0-255. Assignments in the range 0-191 are via Standards 1640 Action; assignments in the range 192-251 are made via Expert Review; 1641 values in the range 252-255 are for Vendor Private Use, and MUST NOT 1642 be allocated. 1644 If any of these fields fall in the Vendor Private range, a top-level 1645 Vendor Enterprise Code TLV MUST be present in the message. 1647 Message Types defined in this document are: 1649 Value Meaning 1650 ----- ------- 1651 1 MPLS Echo Request 1652 2 MPLS Echo Reply 1654 Reply Modes defined in this document are: 1656 Value Meaning 1657 ----- ------- 1658 1 Do not reply 1659 2 Reply via an IPv4/IPv6 UDP packet 1660 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 1661 4 Reply via application level control channel 1663 Return Codes defined in this document are listed in section 3.1. 1665 7.2. TLVs 1667 It is requested that IANA maintain a registry for the Type field of 1668 top-level TLVs as well as for any associated sub-TLVs. Note the 1669 meaning of a sub-TLV is scoped by the TLV. The valid range for each 1670 of these is 0-65535. Assignments in the range 0-16383 and 1671 32768-49161 are made via Standards Action as defined in [IANA]; 1672 assignments in the range 16384-31743 and 49162-64511 are made via 1673 Expert Review (see below); values in the range 31744-32746 and 1674 64512-65535 are for Vendor Private Use, and MUST NOT be allocated. 1676 If a TLV or sub-TLV has a Type that falls in the range for Vendor 1677 Private Use, the Length MUST be at least 4, and the first four octets 1678 MUST be that vendor's SMI Enterprise Code, in network octet order. 1679 The rest of the Value field is private to the vendor. 1681 TLVs and sub-TLVs defined in this document are: 1683 Type Sub-Type Value Field 1684 ---- -------- ----------- 1685 1 Target FEC Stack 1686 1 LDP IPv4 prefix 1687 2 LDP IPv6 prefix 1688 3 RSVP IPv4 LSP 1689 4 RSVP IPv6 LSP 1690 5 Not Assigned 1691 6 VPN IPv4 prefix 1692 7 VPN IPv6 prefix 1693 8 L2 VPN endpoint 1694 9 "FEC 128" Pseudowire (Deprecated) 1695 10 "FEC 128" Pseudowire 1696 11 "FEC 129" Pseudowire 1697 12 BGP labeled IPv4 prefix 1698 13 BGP labeled IPv6 prefix 1699 14 Generic IPv4 prefix 1700 15 Generic IPv6 prefix 1701 16 Nil FEC 1702 2 Downstream Mapping 1703 3 Pad 1704 4 Not Assigned 1705 5 Vendor Enterprise Code 1706 6 Not Assigned 1707 7 Interface and Label Stack 1708 8 Not Assigned 1709 9 Errored TLVs 1710 Any value The TLV not understood 1711 10 Reply TOS Byte 1713 8. Acknowledgments 1715 This document is the outcome of many discussions among many people, 1716 that include Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa 1717 Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani Aggarwal and Vanson 1718 Lim. 1720 The description of the Multipath Information sub-field of the Down- 1721 stream Mapping TLV was adapted from text suggested by Curtis Vil- 1722 lamizar. 1724 Authors' Address 1726 Kireeti Kompella 1727 Juniper Networks 1728 1194 N.Mathilda Ave 1729 Sunnyvale, CA 94089 1730 Email: kireeti@juniper.net 1732 George Swallow 1733 Cisco Systems 1734 1414 Massachusetts Ave, 1735 Boxborough, MA 01719 1736 Phone: +1 978 936 1398 1737 Email: swallow@cisco.com 1739 Copyright Notice 1741 Copyright (C) The Internet Society (2005). This document is subject 1742 to the rights, licenses and restrictions contained in BCP 78, and 1743 except as set forth therein, the authors retain all their rights. 1745 Expiration Date 1747 November 2005 1749 Disclaimer of Validity 1751 This document and the information contained herein are provided on an 1752 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1753 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1754 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1755 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 1756 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 1757 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.