idnits 2.17.1 draft-ietf-mpls-lsp-ping-08.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 3979, Section 5, paragraph 1 on line 1760. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1773. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 41 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 (February 2005) is 7004 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) == Unused Reference: 'RSVP' is defined on line 1580, but no explicit reference was found in the text == Unused Reference: 'RSVP-REFRESH' is defined on line 1584, but no explicit reference was found in the text == Unused Reference: 'RSVP-TE' is defined on line 1587, but no explicit reference was found in the text ** 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: 7 errors (**), 0 flaws (~~), 7 warnings (==), 5 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: August 2005 5 George Swallow 6 Cisco Systems, Inc. 8 February 2005 10 Detecting MPLS Data Plane Failures 12 draft-ietf-mpls-lsp-ping-08.txt 14 Status of this Memo 16 By submitting this Internet-Draft, the authors certify that any 17 applicable patent or other IPR claims of which we are aware have been 18 disclosed, and any of which we become aware will be disclosed, in 19 accordance with RFC 3668. 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 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document describes a simple and efficient mechanism that can be 45 used to detect data plane failures in Multi-Protocol Label Switching 46 (MPLS) Label Switched Paths (LSPs). There are two parts to this 47 document: information carried in an MPLS "echo request" and "echo 48 reply" for the purposes of fault detection and isolation; and 49 mechanisms for reliably sending the echo reply. 51 Changes since last revision 53 (This section to be removed before publication.) 55 o added clarification of TLV lengths, with examples; 56 o added a Global Flags field in the header for the 57 'validate FEC' flag; 58 o fixed the optional vs. mandatory Types wording; 59 o added several new FEC sub-TLVs: 60 - 12 BGP labeled IPv4 prefix 61 + 12 BGP labeled IPv4 prefix 62 + 13 BGP labeled IPv6 prefix (TBD) 63 + 14 Generic IPv4 prefix 64 + 15 Generic IPv6 prefix 65 + 16 Nil FEC 66 o in Downstream Mapping TLV 67 + added an Address Type of IPv6 Unnumbered; 68 + added DS Flags to the DS Map, with 2 defined bits; 69 + renamed Hash key type to multipath type and dropped 70 codepoints for which no processing rules have been 71 defined; 72 o added "Reply TOS byte" TLV; 73 o updated processing rules to deal fully deal with implicit 74 null labels 75 o added text on processing fewer prefixes in DS maps; 76 o added text on "Testing LSPs That Are Used to Carry MPLS 77 Payloads"; 78 o fixed text on non-compatible routers. 80 Contents 82 1 Introduction .............................................. 5 83 1.1 Conventions ............................................... 5 84 1.2 Structure of this document ................................ 5 85 1.3 Contributors .............................................. 5 86 2 Motivation ................................................ 6 87 3 Packet Format ............................................. 7 88 3.1 Return Codes .............................................. 10 89 3.2 Target FEC Stack .......................................... 12 90 3.2.1 LDP IPv4 Prefix ........................................... 13 91 3.2.2 LDP IPv6 Prefix ........................................... 13 92 3.2.3 RSVP IPv4 Session ......................................... 14 93 3.2.4 RSVP IPv6 Session ......................................... 14 94 3.2.5 VPN IPv4 Prefix ........................................... 15 95 3.2.6 VPN IPv6 Prefix ........................................... 15 96 3.2.7 L2 VPN Endpoint ........................................... 15 97 3.2.8 FEC 128 Pseudowire (Deprecated) ........................... 16 98 3.2.9 FEC 128 Pseudowire (Current) .............................. 16 99 3.2.10 FEC 129 Pseudowire ........................................ 17 100 3.2.11 BGP Labeled IPv4 Prefix ................................... 17 101 3.2.12 Generic IPv4 Prefix ....................................... 18 102 3.2.13 Generic IPv6 Prefix ....................................... 18 103 3.2.14 Nil FEC ................................................... 19 104 3.3 Downstream Mapping ........................................ 20 105 3.3.1 Multipath Information Encoding ............................ 23 106 3.3.2 Downstream Router and Interface ........................... 24 107 3.4 Pad TLV ................................................... 25 108 3.5 Error Code ................................................ 25 109 3.6 Vendor Enterprise Code .................................... 25 110 3.7 Interface and Label Stack Object .......................... 26 111 3.7.1 IPv4 Interface and Label Stack Object ..................... 26 112 3.7.2 IPv6 Interface and Label Stack Object ..................... 27 113 3.8 Errored TLVs .............................................. 28 114 3.9 Reply TOS Byte TLV ........................................ 29 115 4 Theory of Operation ....................................... 29 116 4.1 Dealing with Equal-Cost Multi-Path (ECMP) ................. 29 117 4.2 Testing LSPs That Are Used to Carry MPLS Payloads ......... 30 118 4.3 Sending an MPLS Echo Request .............................. 31 119 4.4 Receiving an MPLS Echo Request ............................ 31 120 4.5 Sending an MPLS Echo Reply ................................ 35 121 4.6 Receiving an MPLS Echo Reply .............................. 36 122 4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 36 123 4.8 Non-compliant Routers ..................................... 37 124 5 References ................................................ 37 125 6 Security Considerations ................................... 38 126 7 IANA Considerations ....................................... 38 127 7.1 Message Types, Reply Modes, Return Codes .................. 39 128 7.2 TLVs ...................................................... 39 129 8 Acknowledgments ........................................... 39 130 A Appendix .................................................. 40 131 A.1 CR-LDP FEC ................................................ 40 132 A.2 Downstream Mapping for CR-LDP ............................. 40 134 1. Introduction 136 This document describes a simple and efficient mechanism that can be 137 used to detect data plane failures in MPLS LSPs. There are two parts 138 to this document: information carried in an MPLS "echo request" and 139 "echo reply"; and mechanisms for transporting the echo reply. The 140 first part aims at providing enough information to check correct 141 operation of the data plane, as well as a mechanism to verify the 142 data plane against the control plane, and thereby localize faults. 143 The second part suggests two methods of reliable reply channels for 144 the echo request message, for more robust fault isolation. 146 An important consideration in this design is that MPLS echo requests 147 follow the same data path that normal MPLS packets would traverse. 148 MPLS echo requests are meant primarily to validate the data plane, 149 and secondarily to verify the data plane against the control plane. 150 Mechanisms to check the control plane are valuable, but are not cov- 151 ered in this document. 153 To avoid potential Denial of Service attacks, it is recommended to 154 regulate the LSP ping traffic going to the control plane. A rate 155 limiter should be applied to the well-known UDP port defined below. 157 1.1. Conventions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 163 1.2. Structure of this document 165 The body of this memo contains four main parts: motivation, MPLS echo 166 request/reply packet format, LSP ping operation, and a reliable 167 return path. It is suggested that first-time readers skip the actual 168 packet formats and read the Theory of Operation first; the document 169 is structured the way it is to avoid forward references. 171 1.3. Contributors 173 The following made vital contributions to all aspects of this docu- 174 ment, and much of the material came out of debate and discussion 175 among this group. 177 Ronald P. Bonica, Juniper Networks, Inc. 178 Dave Cooper, Global Crossing 179 Ping Pan, Hammerhead Systems 180 Nischal Sheth, Juniper Networks, Inc. 181 Sanjay Wadhwa, Juniper Networks, Inc. 183 2. Motivation 185 When an LSP fails to deliver user traffic, the failure cannot always 186 be detected by the MPLS control plane. There is a need to provide a 187 tool that would enable users to detect such traffic "black holes" or 188 misrouting within a reasonable period of time; and a mechanism to 189 isolate faults. 191 In this document, we describe a mechanism that accomplishes these 192 goals. This mechanism is modeled after the ping/traceroute paradigm: 193 ping (ICMP echo request [ICMP]) is used for connectivity checks, and 194 traceroute is used for hop-by-hop fault localization as well as path 195 tracing. This document specifies a "ping mode" and a "traceroute" 196 mode for testing MPLS LSPs. 198 The basic idea is to verify that packets that belong to a particular 199 Forwarding Equivalence Class (FEC) actually end their MPLS path on an 200 LSR that is an egress for that FEC. This document proposes that this 201 test be carried out by sending a packet (called an "MPLS echo 202 request") along the same data path as other packets belonging to this 203 FEC. An MPLS echo request also carries information about the FEC 204 whose MPLS path is being verified. This echo request is forwarded 205 just like any other packet belonging to that FEC. In "ping" mode 206 (basic connectivity check), the packet should reach the end of the 207 path, at which point it is sent to the control plane of the egress 208 LSR, which then verifies whether it is indeed an egress for the FEC. 209 In "traceroute" mode (fault isolation), the packet is sent to the 210 control plane of each transit LSR, which performs various checks that 211 it is indeed a transit LSR for this path; this LSR also returns fur- 212 ther information that helps check the control plane against the data 213 plane, i.e., that forwarding matches what the routing protocols 214 determined as the path. 216 One way these tools can be used is to periodically ping a FEC to 217 ensure connectivity. If the ping fails, one can then initiate a 218 traceroute to determine where the fault lies. One can also periodi- 219 cally traceroute FECs to verify that forwarding matches the control 220 plane; however, this places a greater burden on transit LSRs and thus 221 should be used with caution. 223 3. Packet Format 225 An MPLS echo request is a (possibly labelled) IPv4 or IPv6 UDP 226 packet; the contents of the UDP packet have the following format: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Version Number | Global Flags | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Message Type | Reply mode | Return Code | Return Subcode| 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Sender's Handle | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Sequence Number | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | TimeStamp Sent (seconds) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | TimeStamp Sent (microseconds) | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | TimeStamp Received (seconds) | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | TimeStamp Received (microseconds) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | TLVs ... | 248 . . 249 . . 250 . . 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 The Version Number is currently 1. (Note: the Version Number is to 255 be incremented whenever a change is made that affects the ability of 256 an implementation to correctly parse or process an MPLS echo 257 request/reply. These changes include any syntactic or semantic 258 changes made to any of the fixed fields, or to any TLV or sub-TLV 259 assignment or format that is defined at a certain version number. 260 The Version Number may not need to be changed if an optional TLV or 261 sub-TLV is added.) 263 The Global Flags field is a bit vector with the following format: 265 0 1 266 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | SBZ |V| 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 One flag is defined for now, the V bit; the rest SHOULD be set to 272 zero when sending, and ignored on receipt. 274 The V (Validate FEC Stack) flag is set to 1 if the sender wants the 275 receiver to perform FEC stack validation; if V is 0, the choice is 276 left to the receiver. 278 The Message Type is one of the following: 280 Value Meaning 281 ----- ------- 282 1 MPLS Echo Request 283 2 MPLS Echo Reply 285 The Reply Mode can take one of the following values: 287 Value Meaning 288 ----- ------- 289 1 Do not reply 290 2 Reply via an IPv4/IPv6 UDP packet 291 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 292 4 Reply via application level control channel 294 An MPLS echo request with "Do not reply" may be used for one-way con- 295 nectivity tests; the receiving router may log gaps in the sequence 296 numbers and/or maintain delay/jitter statistics. An MPLS echo 297 request would normally have "Reply via an IPv4/IPv6 UDP packet"; if 298 the normal IP return path is deemed unreliable, one may use "Reply 299 via an IPv4/IPv6 UDP packet with Router Alert" (note that this 300 requires that all intermediate routers understand and know how to 301 forward MPLS echo replies). The echo reply uses the same IP version 302 number as the received echo request, i.e., an IPv4 encapsulated echo 303 reply is sent in response to an IPv4 encapsulated echo request. 305 Any application which supports an IP control channel between its con- 306 trol entities may set the Reply Mode to 4 to ensure that replies use 307 that same channel. Further definition of this codepoint is applica- 308 tion specific and thus beyond the scope of this docuemnt. 310 Return Codes and Subcodes are described in the next section. 312 the Sender's Handle is filled in by the sender, and returned 313 unchanged by the receiver in the echo reply (if any). There are no 314 semantics associated with this handle, although a sender may find 315 this useful for matching up requests with replies. 317 The Sequence Number is assigned by the sender of the MPLS echo 318 request, and can be (for example) used to detect missed replies. 320 The TimeStamp Sent is the time-of-day (in seconds and microseconds, 321 wrt the sender's clock) when the MPLS echo request is sent. The 322 TimeStamp Received in an echo reply is the time-of-day (wrt the 323 receiver's clock) that the corresponding echo request was received. 325 TLVs (Type-Length-Value tuples) have the following format: 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 | Length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Value | 333 . . 334 . . 335 . . 336 | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Types are defined below; Length is the length of the Value field in 340 octets. The Value field depends on the Type; it is zero padded to 341 align to a four-octet boundary. TLVs may be nested within other 342 TLVs, in which case the nested TLVs are called sub-TLVs. 344 Two examples follow. The LDP IPv4 FEC TLV has the following format: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type = 1 (LDP IPv4 FEC) | Length = 5 | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | IPv4 prefix | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Prefix Length | Must Be Zero | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 The Length for this TLV is 5. A FEC TLV which contains just an LDP 357 IPv4 FEC sub-TLV has the format: 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Type = 1 (FEC TLV) | Length = 12 | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | sub-Type = 1 (LDP IPv4 FEC) | Length = 5 | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | IPv4 prefix | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Prefix Length | Must Be Zero | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 A description of the Types and Values of the top level TLVs for LSP 372 ping are given below: 374 Type # Value Field 375 ------ ----------- 376 1 Target FEC Stack 377 2 Downstream Mapping 378 3 Pad 379 4 Error Code 380 5 Vendor Enterprise Code 381 6 TBD 382 7 IPv4 Interface and Label Stack Object 383 8 IPv6 Interface and Label Stack Object 384 9 Errored TLVs 385 10 Reply TOS Byte 387 Types less than 32768 (i.e., with the high order bit equal to 0) are 388 mandatory TLVs that MUST either be supported by an implementation or 389 result in the return code of 2 ("One or more of the TLVs was not 390 understood") being sent in the echo response. 392 Types greater than or equal to 32768 (i.e., with the high order bit 393 equal to 1) are optional TLVs that SHOULD be ignored if the implemen- 394 tation does not understand or support them. 396 3.1. Return Codes 398 The Return Code is set to zero by the sender. The receiver can set 399 it to one of the values listed below. The notation refers to 400 the Return Subcode. This field is filled in with the stack-depth for 401 those codes which specify that. For all other codes the Return Sub- 402 code MUST be set to zero. 404 Value Meaning 405 ----- ------- 407 0 No return code or return code contained in the Error 408 Code TLV 410 1 Malformed echo request received 412 2 One or more of the TLVs was not understood 414 3 Replying router is an egress for the FEC at stack 415 depth 417 4 Replying router has no mapping for the FEC at stack 418 depth 420 5 Downstream Mapping Mismatch (See Note 1) 422 6 Reserved 424 7 Reserved 426 8 Label switched at stack-depth 428 9 Label switched but no MPLS forwarding at stack-depth 429 431 10 Mapping for this FEC is not the given label at stack 432 depth 434 11 No label entry at stack-depth 436 12 Protocol not associated with interface at FEC stack 437 depth 439 13 Premature termination of ping due to label stack 440 shrinking to a single label 442 Note 1 444 The Return Subcode contains the point in the label stack" where pro- 445 cessing was terminated. If the RSC is 0, no labels were processed. 446 Otherwise the packet would have been label switched at depth RSC. 448 3.2. Target FEC Stack 450 A Target FEC Stack is a list of sub-TLVs. The number of elements is 451 determined by the looking at the sub-TLV length fields. 453 Sub-Type # Length Value Field 454 ---------- ------ ----------- 455 1 5 LDP IPv4 prefix 456 2 17 LDP IPv6 prefix 457 3 20 RSVP IPv4 Session Query 458 4 56 RSVP IPv6 Session Query 459 5 Reserved; see Appendix 460 6 13 VPN IPv4 prefix 461 7 25 VPN IPv6 prefix 462 8 14 L2 VPN endpoint 463 9 10 "FEC 128" Pseudowire (old) 464 10 14 "FEC 128" Pseudowire (new) 465 11 13+ "FEC 129" Pseudowire 466 12 9 BGP labeled IPv4 prefix 467 13 ?? BGP labeled IPv6 prefix (TBD) 468 14 5 Generic IPv4 prefix 469 15 17 Generic IPv6 prefix 470 16 4*N Nil FEC 472 Other FEC Types will be defined as needed. 474 Note that this TLV defines a stack of FECs, the first FEC element 475 corresponding to the top of the label stack, etc. 477 An MPLS echo request MUST have a Target FEC Stack that describes the 478 FEC stack being tested. For example, if an LSR X has an LDP mapping 479 for 192.168.1.1 (say label 1001), then to verify that label 1001 does 480 indeed reach an egress LSR that announced this prefix via LDP, X can 481 send an MPLS echo request with a FEC Stack TLV with one FEC in it, 482 namely of type LDP IPv4 prefix, with prefix 192.168.1.1/32, and send 483 the echo request with a label of 1001. 485 Say LSR X wanted to verify that a label stack of <1001, 23456> is the 486 right label stack to use to reach a VPN IPv4 prefix of 10/8 in VPN 487 foo. Say further that LSR Y with loopback address 192.168.1.1 488 announced prefix 10/8 with Route Distinguisher RD-foo-Y (which may in 489 general be different from the Route Distinguisher that LSR X uses in 490 its own advertisements for VPN foo), label 23456 and BGP nexthop 491 192.168.1.1. Finally, suppose that LSR X receives a label binding of 492 1001 for 192.168.1.1 via LDP. X has two choices in sending an MPLS 493 echo request: X can send an MPLS echo request with a FEC Stack TLV 494 with a single FEC of type VPN IPv4 prefix with a prefix of 10/8 and a 495 Route Distinguisher of RD-foo-Y. Alternatively, X can send a FEC 496 Stack TLV with two FECs, the first of type LDP IPv4 with a prefix of 497 192.168.1.1/32 and the second of type of IP VPN with a prefix 10/8 498 with Route Distinguisher of RD-foo-Y. In either case, the MPLS echo 499 request would have a label stack of <1001, 23456>. (Note: in this 500 example, 1001 is the "outer" label and 23456 is the "inner" label.) 502 3.2.1. LDP IPv4 Prefix 504 The value consists of four octets of an IPv4 prefix followed by one 505 octet of prefix length in bits; the format is given below. The IPv4 506 prefix is in network byte order; if the prefix is shorter than 32 507 bits, trailing bits SHOULD be set to zero. See [LDP] for an example 508 of a Mapping for an IPv4 FEC. 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | IPv4 prefix | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Prefix Length | Must Be Zero | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 3.2.2. LDP IPv6 Prefix 520 The value consists of sixteen octets of an IPv6 prefix followed by 521 one octet of prefix length in bits; the format is given below. The 522 IPv6 prefix is in network byte order; if the prefix is shorter than 523 128 bits, the trailing bits SHOULD be set to zero. See [LDP] for an 524 example of a Mapping for an IPv6 FEC. 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | IPv6 prefix | 530 | (16 octets) | 531 | | 532 | | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Prefix Length | Must Be Zero | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 3.2.3. RSVP IPv4 Session 539 The value has the format below. The value fields are taken from 540 [RFC3209, sections 4.6.1.1 and 4.6.2.1]. 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | IPv4 tunnel end point address | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Must Be Zero | Tunnel ID | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Extended Tunnel ID | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | IPv4 tunnel sender address | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Must Be Zero | LSP ID | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 3.2.4. RSVP IPv6 Session 558 The value has the format below. The value fields are taken from 559 [RFC3209, sections 4.6.1.2 and 4.6.2.2]. 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | IPv6 tunnel end point address | 565 | | 566 | | 567 | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Must Be Zero | Tunnel ID | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Extended Tunnel ID | 572 | | 573 | | 574 | | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | IPv6 tunnel sender address | 577 | | 578 | | 579 | | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Must Be Zero | LSP ID | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 3.2.5. VPN IPv4 Prefix 586 The value field consists of the Route Distinguisher advertised with 587 the VPN IPv4 prefix, the IPv4 prefix (with trailing 0 bits to make 32 588 bits in all) and a prefix length, as follows: 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Route Distinguisher | 594 | (8 octets) | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | IPv4 prefix | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Prefix Length | Must Be Zero | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 3.2.6. VPN IPv6 Prefix 603 The value field consists of the Route Distinguisher advertised with 604 the VPN IPv6 prefix, the IPv6 prefix (with trailing 0 bits to make 605 128 bits in all) and a prefix length, as follows: 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Route Distinguisher | 611 | (8 octets) | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | IPv6 prefix | 614 | | 615 | | 616 | | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Prefix Length | Must Be Zero | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 3.2.7. L2 VPN Endpoint 623 The value field consists of a Route Distinguisher (8 octets), the 624 sender (of the ping)'s CE ID (2 octets), the receiver's CE ID (2 625 octets), and an encapsulation type (2 octets), formatted as follows: 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Route Distinguisher | 631 | (8 octets) | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Sender's CE ID | Receiver's CE ID | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Encapsulation Type | Must Be Zero | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 3.2.8. FEC 128 Pseudowire (Deprecated) 640 The value field consists of the remote PE address (the destination 641 address of the targetted LDP session), a VC ID and an encapsulation 642 type, as follows: 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Remote PE Address | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | VC ID | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Encapsulation Type | Must Be Zero | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 This FEC will be deprecated, and is retained only for backward com- 655 patibility. Implementations of LSP ping SHOULD accept and process 656 this TLV, but SHOULD send LSP ping echo requests with the new TLV 657 (see next section), unless explicitly asked by configuration to use 658 the old TLV. 660 An LSR receiving this TLV SHOULD use the source IP address of the LSP 661 echo request to infer the Sender's PE Address. 663 3.2.9. FEC 128 Pseudowire (Current) 665 The value field consists of the sender's PE address (the source 666 address of the targetted LDP session), the remote PE address (the 667 destination address of the targetted LDP session), a VC ID and an 668 encapsulation type, as follows: 670 0 1 2 3 671 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 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Sender's PE Address | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Remote PE Address | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | VC ID | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Encapsulation Type | Must Be Zero | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 3.2.10. FEC 129 Pseudowire 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Sender's PE Address | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Remote PE Address | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | PW Type | AGI Length | SAII Length | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | TAII Length | AGI Value ... SAII Value ... TAII Value ... | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 . ... . 696 . . 697 . . 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | ... | 0-3 octets of zero padding | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 The Length of this TLV is 13 + AGI length + SAII length + TAII 703 length. Padding is used to make the total length a multiple of 4; 704 the length of the padding is not included in the Length field. 706 3.2.11. BGP Labeled IPv4 Prefix 708 The value field consists of the BGP Next Hop associated with the NLRI 709 advertising the prefix and label, the IPv4 prefix (with trailing 0 710 bits to make 32 bits in all), and the prefix length, as follows: 712 0 1 2 3 713 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 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | BGP Next Hop | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | IPv4 Prefix | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Prefix Length | Must Be Zero | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 3.2.12. Generic IPv4 Prefix 724 The value consists of four octets of an IPv4 prefix followed by one 725 octet of prefix length in bits; the format is given below. The IPv4 726 prefix is in network byte order; if the prefix is shorter than 32 727 bits, trailing bits SHOULD be set to zero. This FEC is used if the 728 protocol advertising the label is unknown, or may change during the 729 course of the LSP. An example is an inter-AS LSP that may be sig- 730 naled by LDP in one AS, by RSVP-TE in another AS, and by BGP between 731 the ASes, such as is common for inter-AS VPNs. 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | IPv4 prefix | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Prefix Length | Must Be Zero | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 3.2.13. Generic IPv6 Prefix 743 The value consists of sixteen octets of an IPv6 prefix followed by 744 one octet of prefix length in bits; the format is given below. The 745 IPv6 prefix is in network byte order; if the prefix is shorter than 746 128 bits, the trailing bits SHOULD be set to zero. 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | IPv6 prefix | 752 | (16 octets) | 753 | | 754 | | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Prefix Length | Must Be Zero | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 3.2.14. Nil FEC 761 At times labels from the reserved range, e.g. Router Alert and 762 Explicit-null, may be added to the label stack for various diagnostic 763 purposes such as influencing load-balancing. These labels may have 764 no explicit FEC associated with them. The Nil FEC stack is defined 765 to allow a Target FEC stack subtlv to be added to the target FEC 766 stack to account for such labels so that proper validation can still 767 be performed. 769 The Length is 4*N octets, where N is the number of Labels contained 770 in the Nil FEC stack. 772 Labels are 20 bit values treated as numbers. The first label speci- 773 fied correspond with the label nearest the top of the label stack. 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Label 1 | SBZ | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Label 2 | SBZ | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 . . 783 . . 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Label 1, Label 2, ... are the actual labels inserted in the label 787 stack; the SBZ fields SHOULD be zero when sent, and ignored on 788 receipt. 790 3.3. Downstream Mapping 792 The Downstream Mapping object is an optional TLV. Only one Down- 793 stream Mapping request may appear in and echo request. The presence 794 of a Downstream Mapping object is a request that Downstream Mapping 795 objects be included in the echo reply. If the replying router is the 796 destination of the FEC, then a Downstream Mapping TLV SHOULD NOT be 797 included in the echo reply. Otherwise Downstream Mapping objects 798 SHOULD include a Downstream Mapping object for each interface over 799 which this FEC could be forwarded. For a more precise definition of 800 the notion of "downstream", see the section named "Downstream". 802 The Length is 16 + M + 4*N octets, where M is the Multipath Length, 803 and N is the number of Downstream Labels. The Value field of a Down- 804 stream Mapping has the following format: 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | MTU | Address Type | DS Flags | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Downstream IP Address (4 or 16 octets) | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Downstream Interface Address (4 or 16 octets) | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Multipath Type| Depth Limit | Multipath Length | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 . . 818 . (Multipath Information) . 819 . . 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Downstream Label | Protocol | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 . . 824 . . 825 . . 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Downstream Label | Protocol | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 Maximum Transmission Unit (MTU) 832 The MTU is the largest MPLS frame (including label stack) that fits 833 on the interface to the Downstream LSR. 835 Address Type 837 The Address Type indicates if the interface is numbered or unnumbered 838 and is set to one of the following values: 840 Type # Address Type 841 ------ ------------ 842 1 IPv4 Numbered 843 2 IPv4 Unnumbered 844 3 IPv6 Numbered 845 4 IPv6 Unnumbered 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 examinition, 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 If the interface to the downstream LSR is numbered, then the Address 880 Type MUST be set to IPv4 or IPv6, the Downstream IP Address MUST be 881 set to either the downstream LSR's Router ID or the interface address 882 of the downstream LSR, and the Downstream Interface Address MUST be 883 set to the downstream LSR's interface address. 885 If the interface to the downstream LSR is unnumbered, the Address 886 Type MUST be Unnumbered, the Downstream IP Address MUST be the down- 887 stream LSR's Router ID (4 octets), and the Downstream Interface 888 Address MUST be set to the index assigned by the upstream LSR to the 889 interface. 891 Multipath Type 893 The follow Mutipath Types are defined: 895 Key Type Multipath Information 896 --- ---------------- --------------------- 897 0 no multipath (empty; M = 0) 898 2 IP address IP addresses 899 4 IP address range low/high address pairs 900 8 Bit-masked IPv4 IP address prefix and bit mask 901 address set 902 9 Bit-masked label set Label prefix and bit mask 904 Type 0 indicates that all packets will be forwarded out this one 905 interface. 907 Types 2, 4, 8 and 9 specify that the supplied Multipath Information 908 will serve to execise this path. 910 Depth Limit 912 The Depth Limit is applicable only to a label stack, and is the maxi- 913 mum number of labels considered in the hash; this SHOULD be set to 914 zero if unspecified or unlimited. 916 Multipath Length 918 The length in octets of the Multipath Information. 920 Multipath Information 922 Address or label values encoded according to the Multipath Type. See 923 the next section below for encoding details. 925 Downstream Label(s) 927 The set of labels in the label stack as it would have appeared if 928 this router were forwarding the packet through this interface. Any 929 Implicit Null labels are explicitly inluded. Labels are treated as 930 numbers, i.e. they are right justified in the field. 932 A Downstream Label is 24 bits, in the same format as an MPLS label 933 minus the TTL field, i.e., the MSBit of the label is bit 0, the LSbit 934 is bit 19, the EXP bits are bits 20-22, and bit 23 is the S bit. The 935 replying router SHOULD fill in the EXP and S bits; the LSR receiving 936 the echo reply MAY choose to ignore these bits. 938 Protocol 940 The Protocol is taken from the following table: 942 Protocol # Signaling Protocol 943 ---------- ------------------ 944 0 Unknown 945 1 Static 946 2 BGP 947 3 LDP 948 4 RSVP-TE 949 5 Reserved; see Appendix 951 3.3.1. Multipath Information Encoding 953 The multipath information encodes labels or addresses which will 954 exercise this path. The multipath informaiton depends on the multi- 955 path type. The contents of the field are shown in the table above. 956 IP addresses are drawn from the range 127/8. Labels are treated as 957 numbers, i.e. they are right justified in the field. Label and 958 Address pairs MUST NOT overlap and MUST be in ascending sequence. 960 Type 8 allows a denser encoding of IP address. The IPv4 prefix is 961 formatted as a base IPv4 address with the non-prefix low order bits 962 set to zero. The maximum prefix length is 27. Following the prefix 963 is a mask of length 2^(32-prefix length) bits. Each bit set to one 964 represents a valid address. The address is the base IPv4 address 965 plus the position of the bit in the mask where the bits are numbered 966 left to right begining with zero. 968 Type 9 allows a denser encoding of Labels. The label prefix is for- 969 matted as a base label value with the non-prefix low order bits set 970 to zero. The maximum prefix (including leading zeros due to encod- 971 ing) length is 27. Following the prefix is a mask of length 972 2^(32-prefix length) bits. Each bit set to one represents a valid 973 Label. The label is the base label plus the position of the bit in 974 the mask where the bits are numbered left to right begining with 975 zero. 977 If the received multipath information is non-null, the labels and IP 978 addresses MUST be picked from the set provided. If none of these 979 labels or addresses map to a particular downstream interface, then 980 for that interface, the type MUST be set to 0. If the received mul- 981 tipath information is null, the receiver simply returns null. 983 For example, suppose LSR X at hop 10 has two downstream LSRs Y and Z 984 for the FEC in question. The received X could return Hash Key Type 985 4, with low/high IP addresses of 1.1.1.1->1.1.1.255 for downstream 986 LSR Y and 2.1.1.1->2.1.1.255 for downstream LSR Z. The head end 987 reflects this information to LSR Y. Y, which has three downstream 988 LSRs U, V and W, computes that 1.1.1.1->1.1.1.127 would go to U and 989 1.1.1.128-> 1.1.1.255 would go to V. Y would then respond with 3 990 Downstream Mappings: to U, with Hash Key Type 4 (1.1.1.1->1.1.1.127); 991 to V, with Hash Key Type 4 (1.1.1.127->1.1.1.255); and to W, with 992 Hash Key Type 7. 994 Note that computing multi-path information may impose a significant 995 processing burden on the receiver. A receiver MAY thus choose to 996 process a subset of the received prefixes. The sender, on receiving 997 a reply to a Downstream Map with partial information, SHOULD assume 998 that the prefixes missing in the reply were skipped by the receiver, 999 and MAY re-request information about them in a new echo request. 1001 3.3.2. Downstream Router and Interface 1003 The notion of "downstream router" and "downstream interface" should 1004 be explained. Consider an LSR X. If a packet that was originated 1005 with TTL n>1 arrived with outermost label L at LSR X, X must be able 1006 to compute which LSRs could receive the packet if it was originated 1007 with TTL=n+1, over which interface the request would arrive and what 1008 label stack those LSRs would see. (It is outside the scope of this 1009 document to specify how this computation is done.) The set of these 1010 LSRs/interfaces are the downstream routers/interfaces (and their 1011 corresponding labels) for X with respect to L. Each pair of down- 1012 stream router and interface requires a separate Downstream Mapping to 1013 be added to the reply. (Note that there are multiple Downstream 1014 Label fields in each TLV as the incoming label L may be swapped with 1015 a label stack.) 1017 The case where X is the LSR originating the echo request is a special 1018 case. X needs to figure out what LSRs would receive the MPLS echo 1019 request for a given FEC Stack that X originates with TTL=1. 1021 The set of downstream routers at X may be alternative paths (see the 1022 discussion below on ECMP) or simultaneous paths (e.g., for MPLS mul- 1023 ticast). In the former case, the Multipath sub-field is used as a 1024 hint to the sender as to how it may influence the choice of these 1025 alternatives. The "No of Multipaths" is the number of IP 1026 Address/Next Label fields. 1028 3.4. Pad TLV 1030 The value part of the Pad TLV contains a variable number (>= 1) of 1031 octets. The first octet takes values from the following table; all 1032 the other octets (if any) are ignored. The receiver SHOULD verify 1033 that the TLV is received in its entirety, but otherwise ignores the 1034 contents of this TLV, apart from the first octet. 1036 Value Meaning 1037 ----- ------- 1038 1 Drop Pad TLV from reply 1039 2 Copy Pad TLV to reply 1040 3-255 Reserved for future use 1042 3.5. Error Code 1044 The Error Code TLV is currently not defined; its purpose is to pro- 1045 vide a mechanism for a more elaborate error reporting structure, 1046 should the reason arise. 1048 3.6. Vendor Enterprise Code 1050 The Length is always 4; the value is the SMI Enterprise code, in net- 1051 work octet order, of the vendor with a Vendor Private extension to 1052 any of the fields in the fixed part of the message, in which case 1053 this TLV MUST be present. If none of the fields in the fixed part of 1054 the message have vendor private extensions, this TLV is OPTIONAL. 1056 3.7. Interface and Label Stack Object 1058 The Interface and Label Stack Object is an optional TLV. It is used 1059 in a Reply message to report the interface on which the Request Mes- 1060 sage was received and the label stack which was on the packet when it 1061 was received. Only one such object may appear. The purpose of the 1062 object is to allow the upstream router to obtain the exact interface 1063 and label stack information as it appears at the replying LSR. It 1064 has two formats, type 7 for IPv4 and type 8 for IPv6 (to be assigned 1065 by IANA). 1067 3.7.1. IPv4 Interface and Label Stack Object 1069 The Length is 8 + 4*N octets, N is the number of Downstream Labels. 1070 The value field of a Interface and Label Stack TLV has the following 1071 format: 1073 0 1 2 3 1074 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 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Downstream IPv4 Address | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Downstream Interface Address | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 . . 1081 . . 1082 . Label Stack . 1083 . . 1084 . . 1085 . . 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 Downstream IPv4 Address 1090 If the address type is 'No Address', the address field MUST be 1091 set to zero and ignored on receipt. 1093 If the address type is 'IPv4', the address field MUST either be 1094 set to the downstream LSR's Router ID or the downstream LSR's 1095 interface address. 1097 If the address type is 'unnumbered', the address field MUST be 1098 set to the downstream LSR's Router ID. 1100 Downstream Interface Address 1102 If the address type is 'IPv4', the interface address field MUST 1103 MUST be set to the downstream LSR's interface address. 1105 If the address type is 'unnumbered', interface address field 1106 MUST be set to the index assigned by the downstream LSR to the 1107 interface. 1109 Label Stack 1111 The label stack of the received echo request message. If any 1112 TTL values have been changed by this router, they SHOULD be 1113 restored. 1115 3.7.2. IPv6 Interface and Label Stack Object 1117 The Length is 32 + 4*N octets, N is the number of Downstream Labels. 1118 The value field of a Interface and Label Stack TLV has the following 1119 format: 1121 0 1 2 3 1122 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 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Downstream IPv6 Address | 1125 | Downstream IPv6 Address (Cont.) | 1126 | Downstream IPv6 Address (Cont.) | 1127 | Downstream IPv6 Address (Cont.) | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Downstream Interface Address | 1130 | Downstream Interface Address (Cont.) | 1131 | Downstream Interface Address (Cont.) | 1132 | Downstream Interface Address (Cont.) | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 . . 1135 . . 1136 . Label Stack . 1137 . . 1138 . . 1139 . . 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 Downstream IPv6 Address 1144 If the address type is 'No Address', the address field MUST be 1145 set to zero and ignored on receipt. 1147 If the address type is 'IPv6', the address field MUST either be 1148 set to the downstream LSR's Router ID or the downstream LSR's 1149 interface address. 1151 If the address type is 'unnumbered', the address field MUST be 1152 set to the downstream LSR's Router ID. 1154 Downstream Interface Address 1156 If the address type is 'IPv6', the interface address field MUST 1157 MUST be set to the downstream LSR's interface address. 1159 If the address type is 'unnumbered', first four octets of 1160 interface address field MUST be set to the index assigned by 1161 the downstream LSR to the interface. The remaining 12 octets 1162 MUST be set to zero. 1164 Label Stack 1166 The label stack of the received echo request message. If any 1167 TTL values have been changed by this router, they SHOULD be 1168 restored. 1170 3.8. Errored TLVs 1172 The following TLV is an optional TLV defined to be sent back to the 1173 sender of an Echo Request to inform it 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 subtlvs. 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.9. Reply TOS Byte TLV 1192 This TLV is used by the originator of the echo request to request 1193 that a echo reply be sent with the IP header TOS byte set to 1194 the value specified in the TLV. This TLV has a length of 4 with 1195 the following value field. 1197 0 1 2 3 1198 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | Reply-TOS Byte| Must be zero | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 4. Theory of Operation 1205 An MPLS echo request is used to test a particular LSP. The LSP to be 1206 tested is identified by the "FEC Stack"; for example, if the LSP was 1207 set up via LDP, and is to an egress IP address of 10.1.1.1, the FEC 1208 stack contains a single element, namely, an LDP IPv4 prefix sub-TLV 1209 with value 10.1.1.1/32. If the LSP being tested is an RSVP LSP, the 1210 FEC stack consists of a single element that captures the RSVP Session 1211 and Sender Template which uniquely identifies the LSP. 1213 FEC stacks can be more complex. For example, one may wish to test a 1214 VPN IPv4 prefix of 10.1/8 that is tunneled over an LDP LSP with 1215 egress 10.10.1.1. The FEC stack would then contain two sub-TLVs, the 1216 first being a VPN IPv4 prefix, and the second being an LDP IPv4 pre- 1217 fix. If the underlying (LDP) tunnel were not known, or was consid- 1218 ered irrelevant, the FEC stack could be a single element with just 1219 the VPN IPv4 sub-TLV. 1221 When an MPLS echo request is received, the receiver is expected to do 1222 a number of tests that verify that the control plane and data plane 1223 are both healthy (for the FEC stack being pinged), and that the two 1224 planes are in sync. 1226 4.1. Dealing with Equal-Cost Multi-Path (ECMP) 1228 LSPs need not be simple point-to-point tunnels. Frequently, a single 1229 LSP may originate at several ingresses, and terminate at several 1230 egresses; this is very common with LDP LSPs. LSPs for a given FEC 1231 may also have multiple "next hops" at transit LSRs. At an ingress, 1232 there may also be several different LSPs to choose from to get to the 1233 desired endpoint. Finally, LSPs may have backup paths, detour paths 1234 and other alternative paths to take should the primary LSP go down. 1236 To deal with the last two first: it is assumed that the LSR sourcing 1237 MPLS echo requests can force the echo request into any desired LSP, 1238 so choosing among multiple LSPs at the ingress is not an issue. The 1239 problem of probing the various flavors of backup paths that will typ- 1240 ically not be used for forwarding data unless the primary LSP is down 1241 will not be addressed here. 1243 Since the actual LSP and path that a given packet may take may not be 1244 known a priori, it is useful if MPLS echo requests can exercise all 1245 possible paths. This, while desirable, may not be practical, because 1246 the algorithms that a given LSR uses to distribute packets over 1247 alternative paths may be proprietary. 1249 To achieve some degree of coverage of alternate paths, there is a 1250 certain lattitude in choosing the destination IP address and source 1251 UDP port for an MPLS echo request. This is clearly not sufficient; 1252 in the case of traceroute, more lattitude is offered by means of the 1253 "Multipath Exercise" sub-TLV of the Downstream Mapping TLV. This is 1254 used as follows. An ingress LSR periodically sends an MPLS tracer- 1255 oute message to determine whether there are multipaths for a given 1256 LSP. If so, each hop will provide some information how each of its 1257 downstreams can be exercised. The ingress can then send MPLS echo 1258 requests that exercise these paths. If several transit LSRs have 1259 ECMP, the ingress may attempt to compose these to exercise all possi- 1260 ble paths. However, full coverage may not be possible. 1262 4.2. Testing LSPs That Are Used to Carry MPLS Payloads 1264 To detect certain LSP breakages, it may be necessary to encapsulate 1265 an MPLS echo request packet with at least one additional label when 1266 testing LSPs that are used to carry MPLS payloads (such as LSPs used 1267 to carry L2VPN and L3VPN traffic. For example, when testing LDP or 1268 RSVP-TE LSPs, just sending an MPLS echo request packet may not detect 1269 instances where the router immediately upstream of the destination of 1270 the LSP ping may forward the MPLS echo request successfully over an 1271 interface not configured to carry MPLS payloads because of the use of 1272 penultimate hop popping. Since the receiving router has no means to 1273 differentiate whether the IP packet was sent unlabeled or implicitly 1274 labeled, the addition of labels shimmed above the MPLS echo request 1275 (using the Nil FEC) will prevent a router from forwarding such a 1276 packet out unlabeled interfaces. 1278 4.3. Sending an MPLS Echo Request 1280 An MPLS echo request is a (possibly) labelled UDP packet. The IP 1281 header is set as follows: the source IP address is a routable address 1282 of the sender; the destination IP address is a (randomly chosen) 1283 address from 127/8; the IP TTL is set to 1. The source UDP port is 1284 chosen by the sender; the destination UDP port is set to 3503 1285 (assigned by IANA for MPLS echo requests). The Router Alert option 1286 is set in the IP header. 1288 If the echo request is labelled, one may (depending on what is being 1289 pinged) set the TTL of the innermost label to 1, to prevent the ping 1290 request going farther than it should. Examples of this include ping- 1291 ing a VPN IPv4 or IPv6 prefix, an L2 VPN end point or a pseudowire. 1292 This can also be accomplished by inserting a router alert label above 1293 this label; however, this may lead to the undesired side effect that 1294 MPLS echo requests take a different data path than actual data. 1296 In "ping" mode (end-to-end connectivity check), the TTL in the outer- 1297 most label is set to 255. In "traceroute" mode (fault isolation 1298 mode), the TTL is set successively to 1, 2, .... 1300 The sender chooses a Sender's Handle, and a Sequence Number. When 1301 sending subsequent MPLS echo requests, the sender SHOULD increment 1302 the sequence number by 1. However, a sender MAY choose to send a 1303 group of echo requests with the same sequence number to improve the 1304 chance of arrival of at least one packet with that sequence number. 1306 The TimeStamp Sent is set to the time-of-day (in seconds and 1307 microseconds) that the echo request is sent. The TimeStamp Received 1308 is set to zero. 1310 An MPLS echo request MUST have a FEC Stack TLV. Also, the Reply Mode 1311 must be set to the desired reply mode; the Return Code and Subcode 1312 are set to zero. In the "traceroute" mode, the echo request SHOULD a 1313 Downstream Mapping TLV. 1315 4.4. Receiving an MPLS Echo Request 1317 An LSR X that receives an MPLS echo request first parses the packet 1318 to ensure that it is a well-formed packet, and that the TLVs that are 1319 not marked "Ignore" are understood. If not, X SHOULD send an MPLS 1320 echo reply with the Return Code set to "Malformed echo request 1321 received" or "TLV not understood" (as appropriate), and the Subcode 1322 set to zero. In the latter case, the misunderstood TLVs (only) are 1323 included in the reply. 1325 If the echo request is good, X notes the interface I over which the 1326 echo was received, and the label stack with which it came. 1328 X matches up the labels in the received label stack with the FECs 1329 contained in the FEC stack. The matching is done beginning at the 1330 bottom of both stacks, and working up. For reporting purposes the 1331 bottom of stack is consided to be stack-depth of 1. This is to 1332 establish an absolute reference for the case where the stack may have 1333 more labels than are in the FEC stack. 1335 If there are more FECs than labels, the extra FECs are assumed to 1336 correspond to Implicit Null Labels. Thus for the processing below, 1337 there is never the case where there is a FEC with no corresponding 1338 label. Further the label operation associated with an assumed Null 1339 Label is 'pop and continue processing'. 1341 Note: in all the error codes listed in this draft a stack-depth of 0 1342 means "no value specified". This allows compatibility with existing 1343 implementations which do not use the Return Subcode field. 1345 X sets two variables, called FEC-stack-depth and Label-stack-depth, 1346 to the number of labels in the received label stack. If the label- 1347 stack-depth is 0, assume there is one implicit null label and set 1348 label-stack-depth to 1. Processing now continues with the following 1349 steps: 1351 Label_Validation: 1353 If the label at Label-stack-depth is valid, goto Label_Operation. 1354 If not, set Best-return-code to 11, "No label entry at stack-depth" 1355 and Best-return-subcode to Label-stack-depth. Goto 1356 Send_Reply_Packet. 1358 Label_Operation: 1360 Switch on label operation. 1362 Case: Pop and Continue Processing (Note: this includes 1363 Explicit_Null and Router_Alert) 1365 If Label-stack-depth is greater than 1, decrement Label-stack- 1366 depth and goto Label_Validation. Otherwise, set FEC-stack-depth 1367 to 1, set Best-return-code to 3 "Replying router is an egress for 1368 the FEC at stack depth", set Best-return-subcode to 1 and goto 1369 Egress_Processing. 1371 Case: Swap or Pop and Switch based on Popped Label 1373 If the label operation is either swap or pop and switch based on 1374 the popped label, Best-return-code to 8, "Label switched at 1375 stack-depth" and Best-return-subcode to Label-stack-depth. 1377 If a Downstream Mapping TLV is present, a Downstream mapping TLVs 1378 SHOULD be created for each multipath. 1380 Determine the output interface. If it is not valid to forward a 1381 labelled packet on this interface, set Best-return-code to Return 1382 Code 9, "Label switched but no MPLS forwarding at stack-depth" 1383 and set Best-return-subcode to Label-stack-depth and goto 1384 Send_Reply_Packet. (Note: this return code is set even if Label- 1385 stack-depth is one.) 1387 If no Downstream Mapping TLV is present, or the Downstream IP 1388 Address is set to the All-Routers multicast address goto 1389 Send_Reply_Packet. 1391 Verify that the IP address, interface address and label stack 1392 match the received interface and label stack. If not, set Best- 1393 return-code to 5, "Downstream Mapping Mis-match". A Received 1394 Interface and Label Stack TLV SHOULD be created. Goto 1395 Send_Reply_Packet. 1397 If the "Validate FEC Stack" flag is not set, goto 1398 Send_Reply_Packet. 1400 Locate the label at Label-stack-depth in the Downstream Labels 1401 and set FEC-stack-depth to that depth. (Note: If the Downstream 1402 Labels contain one or more Implicit Null labels, this may be at a 1403 depth greater than Label-stack-depth. 1405 If the depth of the FEC stack is greater than or equal to FEC- 1406 stack-depth, Perform FEC Checking. If FEC-status is 2, set Best- 1407 return-code to 10, "Mapping for this FEC is not the given label 1408 at stack-depth". 1410 If the return code is 1 set Best-return-code to FEC-return-code 1411 and Best-return-subcode to FEC-stack-depth. 1413 Goto Send_Reply_Packet. 1415 Egress_Processing: 1417 If no Downstream Mapping TLV is present, goto 1418 Egress_FEC_Validation. 1420 Verify that the IP address, interface address and label stack match 1421 the received interface and label stack. If not, set Best-return- 1422 code to 5, "Downstream Mapping Mis-match". A Received Interface 1423 and Label Stack TLV SHOULD be created. Goto Send_Reply_Packet. 1425 Egress_FEC_Validation: 1427 Perform FEC checking. If FEC-status is 1, set Best-return-code 1428 to FEC-code and Best-return-subcode to FEC-stack-depth. Goto 1429 Send_Reply_Packet. 1431 Increment FEC-stack-depth. If FEC-stack-depth is greater than 1432 the number of FECs in the FEC-stack, goto Send_Reply_Packet. If 1433 FEC-status is 0, increment Label-stack-depth. Goto 1434 Egress_FEC_Validation. 1436 Send_Reply_Packet: 1438 Send an MPLS echo reply with a Return Code of Best-return-code, 1439 and a Return Subcode of Best-return-subcode. Include any TLVs 1440 created during the above process. The procedures for sending the 1441 echo reply are found in the next subsection below. 1443 FEC_Checking: 1445 This routine accepts a FEC, Label, and Interface. It returns two 1446 values, FEC-status and FEC-return-code, both of which are 1447 initialized to 0. 1449 If the FEC is the Nil FEC, check that Label is either 1450 Explicit_Null or Router_Alert. If so return. Else 1451 set FEC-return-code to 10, "Mapping for this FEC is not the given 1452 label at stack-depth". Set FEC-status to 1 and return. 1454 Check that the label mapping for FEC. If no mapping exists, set 1455 FEC-return-code to Return 4, "Replying router has no mapping for 1456 the FEC at stack-depth". Set FEC-status to 1. Return. 1458 If the label mapping for FEC is Implicit Null, set FEC-status to 1459 2. Goto Check_Protocol. 1461 If the label mapping for FEC is Label, goto Check_Protocol. Else 1462 set FEC-return-code to 10, "Mapping for this FEC is not the given 1463 label at stack-depth". Set FEC-status to 1 and return. 1465 Check_Protocol: 1467 Check what protocol would be used to advertise FEC. If it can be 1468 determined that no protocol associated with interface I would 1469 have advertised a FEC of that FEC-Type, set FEC-return-code to 1470 12, "Protocol not associated with interface at FEC stack-depth". 1471 Set FEC-status to 1. Return. 1473 4.5. Sending an MPLS Echo Reply 1475 An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response 1476 to an MPLS echo request. The source IP address is a routable address 1477 of the replier; the source port is the well-known UDP port for LSP 1478 ping. The destination IP address and UDP port are copied from the 1479 source IP address and UDP port of the echo request. The IP TTL is 1480 set to 255. If the Reply Mode in the echo request is "Reply via an 1481 IPv4 UDP packet with Router Alert", then the IP header MUST contain 1482 the Router Alert IP option. If the reply is sent over an LSP, the 1483 topmost label MUST in this case be the Router Alert label (1) (see 1484 [LABEL-STACK]). 1486 The format of the echo reply is the same as the echo request. The 1487 Sender's Handle, the Sequence Number and TimeStamp Sent are copied 1488 from the echo request; the TimeStamp Received is set to the time-of- 1489 day that the echo request is received (note that this information is 1490 most useful if the time-of-day clocks on the requestor and the 1491 replier are synchronized). The FEC Stack TLV from the echo request 1492 MAY be copied to the reply. 1494 The replier MUST fill in the Return Code and Subcode, as determined 1495 in the previous subsection. 1497 If the echo request contains a Pad TLV, the replier MUST interpret 1498 the first octet for instructions regarding how to reply. 1500 If the replying router is the destination of the FEC, then Downstream 1501 Mapping TLVs SHOULD NOT be included in the echo reply. 1503 If the echo request contains a Downstream Mapping TLV, and the reply- 1504 ing router is not the destination of the FEC, the replier SHOULD com- 1505 pute its downstream routers and corresponding labels for the incoming 1506 label, and add Downstream Mapping TLVs for each one to the echo reply 1507 it sends back. 1509 If the Downstream Mapping TLV contains multipath information requir- 1510 ing more processing than the receiving router is willing to perform, 1511 the responding router MAY choose to respond with only a subset of 1512 multipaths contained in the Echo Request Downstream Map. (Note: The 1513 originator of the echo request MAY send another echo request with the 1514 multipath information that was not included in the reply.) 1516 4.6. Receiving an MPLS Echo Reply 1518 An LSR X should only receive an MPLS Echo Reply in response to an 1519 MPLS Echo Request that it sent. Thus, on receipt of an MPLS Echo 1520 Reply, X should parse the packet to assure that it is well-formed, 1521 then attempt to match up the Echo Reply with an Echo Request that it 1522 had previously sent, using the destination UDP port and the Sender's 1523 Handle. If no match is found, then X jettisons the Echo Reply; oth- 1524 erwise, it checks the Sequence Number to see if it matches. Gaps in 1525 the Sequence Number MAY be logged and SHOULD be counted. Once an 1526 Echo Reply is received for a given Sequence Number (for a given UDP 1527 port and Handle), the Sequence Number for subsequent Echo Requests 1528 for that UDP port and Handle SHOULD be incremented. 1530 If the Echo Reply contains Downstream Mappings, and X wishes to 1531 traceroute further, it SHOULD copy the Downstream Mappings into its 1532 next Echo Request (with TTL incremented by one). 1534 4.7. Issue with VPN IPv4 and IPv6 Prefixes 1536 Typically, a LSP ping for a VPN IPv4 or IPv6 prefix is sent with a 1537 label stack of depth greater than 1, with the innermost label having 1538 a TTL of 1. This is to terminate the ping at the egress PE, before 1539 it gets sent to the customer device. However, under certain circum- 1540 stances, the label stack can shrink to a single label before the ping 1541 hits the egress PE; this will result in the ping terminating prema- 1542 turely. One such scenario is a multi-AS Carrier's Carrier VPN. 1544 To get around this problem, one approach is for the LSR that receives 1545 such a ping to realize that the ping terminated prematurely, and send 1546 back error code 13. In that case, the initiating LSR can retry the 1547 ping after incrementing the TTL on the VPN label. In this fashion, 1548 the ingress LSR will sequentially try TTL values until it finds one 1549 that allows the VPN ping to reach the egress PE. 1551 4.8. Non-compliant Routers 1553 If the egress for the FEC Stack being pinged does not support MPLS 1554 ping, then no reply will be sent, resulting in possible "false nega- 1555 tives". If in "traceroute" mode, a transit LSR does not support LSP 1556 ping, then no reply will be forthcoming from that LSR for some TTL, 1557 say n. The LSR originating the echo request SHOULD try sending the 1558 echo request with TTL=n+1, n+2, ..., n+k to probe LSRs further down 1559 the path. In such a case, the echo request for TTL > n SHOULD be 1560 sent with Downstream Mapping TLV "Downstream IP Address" field set to 1561 the ALLROUTERs multicast address until a reply is received with a 1562 Downstream Mapping TLV. The Label Stack MAY be omitted from the 1563 Downstream Mapping TLV. Further the "Validate FEC Stack" flag SHOULD 1564 NOT be set until an ECHO REQUEST packet with a Downstream Mapping TLV 1565 is received. 1567 5. References 1569 Normative References 1571 [IANA] Narten, T. and H. Alvestrand, "Guidelines for IANA 1572 Considerations", BCP 26, RFC 2434, October 1998. 1574 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1575 Requirement Levels", BCP 14, RFC 2119, March 1997. 1577 [LABEL-STACK] Rosen, E., et al, "MPLS Label Stack Encoding", 1578 RFC 3032, January 2001. 1580 [RSVP] Braden, R. (Editor), et al, "Resource ReSerVation 1581 Protocol (RSVP) -- Version 1 Functional 1582 Specification," RFC 2205, September 1997. 1584 [RSVP-REFRESH] Berger, L., et al, "RSVP Refresh Overhead Reduction 1585 Extensions", RFC 2961, April 2001. 1587 [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for 1588 LSP tunnels", RFC 3209, December 2001. 1590 Informative References 1592 [ICMP] Postel, J., "Internet Control Message Protocol", 1593 RFC 792. 1595 [LDP] Andersson, L., et al, "LDP Specification", RFC 3036, 1596 January 2001. 1598 6. Security Considerations 1600 There are at least two approaches to attacking LSRs using the mecha- 1601 nisms defined here. One is a Denial of Service attack, by sending 1602 MPLS echo requests/replies to LSRs and thereby increasing their work- 1603 load. The other is obfuscating the state of the MPLS data plane 1604 liveness by spoofing, hijacking, replaying or otherwise tampering 1605 with MPLS echo requests and replies. 1607 Authentication will help reduce the number of seemingly valid MPLS 1608 echo requests, and thus cut down the Denial of Service attacks; 1609 beyond that, each LSR must protect itself. 1611 Authentication sufficiently addresses spoofing, replay and most tam- 1612 pering attacks; one hopes to use some mechanism devised or suggested 1613 by the RPSec WG. It is not clear how to prevent hijacking (non- 1614 delivery) of echo requests or replies; however, if these messages are 1615 indeed hijacked, LSP ping will report that the data plane isn't work- 1616 ing as it should. 1618 It doesn't seem vital (at this point) to secure the data carried in 1619 MPLS echo requests and replies, although knowledge of the state of 1620 the MPLS data plane may be considered confidential by some. 1622 7. IANA Considerations 1624 The TCP and UDP port number 3503 has been allocated by IANA for LSP 1625 echo requests and replies. 1627 The following sections detail the new name spaces to be managed by 1628 IANA. For each of these name spaces, the space is divided into 1629 assignment ranges; the following terms are used in describing the 1630 procedures by which IANA allocates values: "Standards Action" (as 1631 defined in [IANA]); "Expert Review" and "Vendor Private Use". 1633 Values from "Expert Review" ranges MUST be registered with IANA, and 1634 MUST be accompanied by an Experimental RFC that describes the format 1635 and procedures for using the code point; the actual assignment is 1636 made during the IANA actions for the RFC. 1638 Values from "Vendor Private" ranges MUST NOT be registered with IANA; 1639 however, the message MUST contain an enterprise code as registered 1640 with the IANA SMI Network Management Private Enterprise Codes. For 1641 each name space that has a Vendor Private range, it must be specified 1642 where exactly the SMI Enterprise Code resides; see below for exam- 1643 ples. In this way, several enterprises (vendors) can use the same 1644 code point without fear of collision. 1646 7.1. Message Types, Reply Modes, Return Codes 1648 It is requested that IANA maintain registries for Message Types, 1649 Reply Modes, Return Codes and Return Subcodes. Each of these can 1650 take values in the range 0-255. Assignments in the range 0-191 are 1651 via Standards Action; assignments in the range 192-251 are made via 1652 Expert Review; values in the range 252-255 are for Vendor Private 1653 Use, and MUST NOT be allocated. 1655 If any of these fields fall in the Vendor Private range, a top-level 1656 Vendor Enterprise Code TLV MUST be present in the message. 1658 7.2. TLVs 1660 It is requested that IANA maintain registries for the Type field of 1661 top-level TLVs as well as for sub-TLVs. The valid range for each of 1662 these is 0-65535. Assignments in the range 0-16383 and 32768-49161 1663 are made via Standards Action as defined in [IANA]; assignments in 1664 the range 16384-31743 and 49162-64511 are made via Expert Review (see 1665 below); values in the range 31744-32746 and 64512-65535 are for Ven- 1666 dor Private Use, and MUST NOT be allocated. 1668 If a TLV or sub-TLV has a Type that falls in the range for Vendor 1669 Private Use, the Length MUST be at least 4, and the first four octets 1670 MUST be that vendor's SMI Enterprise Code, in network octet order. 1671 The rest of the Value field is private to the vendor. 1673 8. Acknowledgments 1675 This document is the outcome of many discussions among many people, 1676 that include Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa 1677 Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani Aggarwal and Vanson 1678 Lim. 1680 The description of the Multipath Information sub-field of the Down- 1681 stream Mapping TLV was adapted from text suggested by Curtis Vil- 1682 lamizar. 1684 A. Appendix 1686 This appendix specifies non-normative aspects of detecting MPLS data 1687 plane liveness. 1689 A.1. CR-LDP FEC 1691 This section describes how a CR-LDP FEC can be included in an Echo 1692 Request using the following FEC subtype: 1694 Sub-Type # Length Value Field 1695 ---------- ------ ------------- 1696 5 6 CR-LDP LSP ID 1698 The value consists of the LSPID of the LSP being pinged. An LSPID is 1699 a four octet IPv4 address (a local address on the ingress LSR, for 1700 example, the Router ID) plus a two octet identifier that is unique 1701 per LSP on a given ingress LSR. 1703 0 1 2 3 1704 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 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | Ingress LSR Router ID | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | Must Be Zero | LSP ID | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 A.2. Downstream Mapping for CR-LDP 1713 If a label in a Downstream Mapping was learned via CR-LDP, the Proto- 1714 col field in the Mapping TLV can use the following entry: 1716 Protocol # Signaling Protocol 1717 ---------- ------------------ 1718 5 CR-LDP 1720 Authors' Address 1722 Kireeti Kompella 1723 Juniper Networks 1724 1194 N.Mathilda Ave 1725 Sunnyvale, CA 94089 1726 Email: kireeti@juniper.net 1728 George Swallow 1729 Cisco Systems 1730 1414 Massachusetts Ave, 1731 Boxborough, MA 01719 1732 Phone: +1 978 936 1398 1733 Email: swallow@cisco.com 1735 Full Copyright and Intellectual Property Statements 1737 Copyright (C) The Internet Society (2005). This document is subject 1738 to the rights, licenses and restrictions contained in BCP 78, and 1739 except as set forth therein, the authors retain all their rights. 1741 Disclaimer of Validity 1743 This document and the information contained herein are provided on an 1744 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1745 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1746 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1747 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 1748 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 1749 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1751 Intellectual Property 1753 The IETF takes no position regarding the validity or scope of any 1754 Intellectual Property Rights or other rights that might be claimed to 1755 pertain to the implementation or use of the technology described in 1756 this document or the extent to which any license under such rights 1757 might or might not be available; nor does it represent that it has 1758 made any independent effort to identify any such rights. Information 1759 on the procedures with respect to rights in RFC documents can be 1760 found in BCP 78 and BCP 79. 1762 Copies of IPR disclosures made to the IETF Secretariat and any assur- 1763 ances of licenses to be made available, or the result of an attempt 1764 made to obtain a general license or permission for the use of such 1765 proprietary rights by implementers or users of this specification can 1766 be obtained from the IETF on-line IPR repository at 1767 http://www.ietf.org/ipr. 1769 The IETF invites any interested party to bring to its attention any 1770 copyrights, patents or patent applications, or other proprietary 1771 rights that may cover technology that may be required to implement 1772 this standard. Please address the information to the IETF at ietf- 1773 ipr@ietf.org. 1775 Acknowledgement 1777 Funding for the RFC Editor function is currently provided by the 1778 Internet Society.