idnits 2.17.1 draft-ietf-mpls-lsp-ping-11.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1831. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 42 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 (November 2005) is 6709 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: 'BGP' is defined on line 1588, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3107 (ref. 'BGP-LABEL') (Obsoleted by RFC 8277) -- Obsolete informational reference (is this intentional?): RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-vpls-bgp-05 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kireeti Kompella 3 Internet Draft Juniper Networks, Inc. 4 Category: Standards Track 5 Expiration Date: May 2006 6 George Swallow 7 Cisco Systems, Inc. 9 November 2005 11 Detecting MPLS Data Plane Failures 13 draft-ietf-mpls-lsp-ping-11.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 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 Contents 49 1 Introduction .............................................. 3 50 1.1 Conventions ............................................... 3 51 1.2 Structure of this document ................................ 3 52 1.3 Contributors .............................................. 3 53 2 Motivation ................................................ 4 54 3 Packet Format ............................................. 5 55 3.1 Return Codes .............................................. 9 56 3.2 Target FEC Stack .......................................... 10 57 3.2.1 LDP IPv4 Prefix ........................................... 11 58 3.2.2 LDP IPv6 Prefix ........................................... 11 59 3.2.3 RSVP IPv4 LSP ............................................. 12 60 3.2.4 RSVP IPv6 LSP ............................................. 12 61 3.2.5 VPN IPv4 Prefix ........................................... 13 62 3.2.6 VPN IPv6 Prefix ........................................... 14 63 3.2.7 L2 VPN Endpoint ........................................... 14 64 3.2.8 FEC 128 Pseudowire (Deprecated) ........................... 15 65 3.2.9 FEC 128 Pseudowire (Current) .............................. 15 66 3.2.10 FEC 129 Pseudowire ........................................ 16 67 3.2.11 BGP Labeled IPv4 Prefix ................................... 16 68 3.2.12 BGP Labeled IPv6 Prefix ................................... 17 69 3.2.13 Generic IPv4 Prefix ....................................... 17 70 3.2.14 Generic IPv6 Prefix ....................................... 18 71 3.2.15 Nil FEC ................................................... 18 72 3.3 Downstream Mapping ........................................ 19 73 3.3.1 Multipath Information Encoding ............................ 23 74 3.3.2 Downstream Router and Interface ........................... 25 75 3.4 Pad TLV ................................................... 25 76 3.5 Vendor Enterprise Code .................................... 26 77 3.6 Interface and Label Stack ................................. 26 78 3.7 Errored TLVs .............................................. 28 79 3.8 Reply TOS Byte TLV ........................................ 28 80 4 Theory of Operation ....................................... 29 81 4.1 Dealing with Equal-Cost Multi-Path (ECMP) ................. 29 82 4.2 Testing LSPs That Are Used to Carry MPLS Payloads ......... 30 83 4.3 Sending an MPLS Echo Request .............................. 30 84 4.4 Receiving an MPLS Echo Request ............................ 31 85 4.5 Sending an MPLS Echo Reply ................................ 34 86 4.6 Receiving an MPLS Echo Reply .............................. 35 87 4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 36 88 4.8 Non-compliant Routers ..................................... 36 89 5 References ................................................ 37 90 6 Security Considerations ................................... 38 91 7 IANA Considerations ....................................... 38 92 7.1 Message Types, Reply Modes, Return Codes .................. 39 93 7.2 TLVs ...................................................... 40 94 8 Acknowledgments ........................................... 41 96 1. Introduction 98 This document describes a simple and efficient mechanism that can be 99 used to detect data plane failures in MPLS LSPs. There are two parts 100 to this document: information carried in an MPLS "echo request" and 101 "echo reply"; and mechanisms for transporting the echo reply. The 102 first part aims at providing enough information to check correct 103 operation of the data plane, as well as a mechanism to verify the 104 data plane against the control plane, and thereby localize faults. 105 The second part suggests two methods of reliable reply channels for 106 the echo request message, for more robust fault isolation. 108 An important consideration in this design is that MPLS echo requests 109 follow the same data path that normal MPLS packets would traverse. 110 MPLS echo requests are meant primarily to validate the data plane, 111 and secondarily to verify the data plane against the control plane. 112 Mechanisms to check the control plane are valuable, but are not cov- 113 ered in this document. 115 1.1. Conventions 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 121 The term "Must be Zero" (MBZ) is used in object decriptions for 122 reserved fields. These fields MUST be set to zero when sent and 123 ignored on receipt. 125 1.2. Structure of this document 127 The body of this memo contains four main parts: motivation, MPLS echo 128 request/reply packet format, LSP ping operation, and a reliable 129 return path. It is suggested that first-time readers skip the actual 130 packet formats and read the Theory of Operation first; the document 131 is structured the way it is to avoid forward references. 133 1.3. Contributors 135 The following made vital contributions to all aspects of this docu- 136 ment, and much of the material came out of debate and discussion 137 among this group. 139 Ronald P. Bonica, Juniper Networks, Inc. 140 Dave Cooper, Global Crossing 141 Ping Pan, Hammerhead Systems 142 Nischal Sheth, Juniper Networks, Inc. 143 Sanjay Wadhwa, Juniper Networks, Inc. 145 2. Motivation 147 When an LSP fails to deliver user traffic, the failure cannot always 148 be detected by the MPLS control plane. There is a need to provide a 149 tool that would enable users to detect such traffic "black holes" or 150 misrouting within a reasonable period of time; and a mechanism to 151 isolate faults. 153 In this document, we describe a mechanism that accomplishes these 154 goals. This mechanism is modeled after the ping/traceroute paradigm: 155 ping (ICMP echo request [ICMP]) is used for connectivity checks, and 156 traceroute is used for hop-by-hop fault localization as well as path 157 tracing. This document specifies a "ping mode" and a "traceroute" 158 mode for testing MPLS LSPs. 160 The basic idea is to verify that packets that belong to a particular 161 Forwarding Equivalence Class (FEC) actually end their MPLS path on a 162 Label Switching Router (LSR) that is an egress for that FEC. This 163 document proposes that this test be carried out by sending a packet 164 (called an "MPLS echo request") along the same data path as other 165 packets belonging to this FEC. An MPLS echo request also carries 166 information about the FEC whose MPLS path is being verified. This 167 echo request is forwarded just like any other packet belonging to 168 that FEC. In "ping" mode (basic connectivity check), the packet 169 should reach the end of the path, at which point it is sent to the 170 control plane of the egress LSR, which then verifies whether it is 171 indeed an egress for the FEC. In "traceroute" mode (fault isola- 172 tion), the packet is sent to the control plane of each transit LSR, 173 which performs various checks that it is indeed a transit LSR for 174 this path; this LSR also returns further information that helps check 175 the control plane against the data plane, i.e., that forwarding 176 matches what the routing protocols determined as the path. 178 One way these tools can be used is to periodically ping a FEC to 179 ensure connectivity. If the ping fails, one can then initiate a 180 traceroute to determine where the fault lies. One can also periodi- 181 cally traceroute FECs to verify that forwarding matches the control 182 plane; however, this places a greater burden on transit LSRs and thus 183 should be used with caution. 185 3. Packet Format 187 An MPLS echo request is a (possibly labeled) IPv4 or IPv6 UDP packet; 188 the contents of the UDP packet have the following format: 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Version Number | Global Flags | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Message Type | Reply mode | Return Code | Return Subcode| 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Sender's Handle | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Sequence Number | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | TimeStamp Sent (seconds) | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | TimeStamp Sent (microseconds) | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | TimeStamp Received (seconds) | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | TimeStamp Received (microseconds) | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | TLVs ... | 210 . . 211 . . 212 . . 213 | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 The Version Number is currently 1. (Note: the Version Number is to 217 be incremented whenever a change is made that affects the ability of 218 an implementation to correctly parse or process an MPLS echo 219 request/reply. These changes include any syntactic or semantic 220 changes made to any of the fixed fields, or to any TLV or sub-TLV 221 assignment or format that is defined at a certain version number. 222 The Version Number may not need to be changed if an optional TLV or 223 sub-TLV is added.) 225 The Global Flags field is a bit vector with the following format: 227 0 1 228 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | MBZ |V| 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 One flag is defined for now, the V bit; the rest MUST be set to zero 234 when sending, and ignored on receipt. 236 The V (Validate FEC Stack) flag is set to 1 if the sender wants the 237 receiver to perform FEC stack validation; if V is 0, the choice is 238 left to the receiver. 240 The Message Type is one of the following: 242 Value Meaning 243 ----- ------- 244 1 MPLS Echo Request 245 2 MPLS Echo Reply 247 The Reply Mode can take one of the following values: 249 Value Meaning 250 ----- ------- 251 1 Do not reply 252 2 Reply via an IPv4/IPv6 UDP packet 253 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 254 4 Reply via application level control channel 256 An MPLS echo request with 1 (Do not reply) in the Reply Mode field 257 may be used for one-way connectivity tests; the receiving router may 258 log gaps in the sequence numbers and/or maintain delay/jitter statis- 259 tics. An MPLS echo request would normally have 2 (Reply via an 260 IPv4/IPv6 UDP packet) in the Reply Mode field. If the normal IP 261 return path is deemed unreliable, one may use 3 (Reply via an 262 IPv4/IPv6 UDP packet with Router Alert). Note that this requires 263 that all intermediate routers understand and know how to forward MPLS 264 echo replies. The echo reply uses the same IP version number as the 265 received echo request, i.e., an IPv4 encapsulated echo reply is sent 266 in response to an IPv4 encapsulated echo request. 268 Any application which supports an IP control channel between its con- 269 trol entities may set the Reply Mode to 4 (Reply via application 270 level control channel) to ensure that replies use that same channel. 271 Further definition of this codepoint is application specific and thus 272 beyond the scope of this document. 274 Return Codes and Subcodes are described in the next section. 276 the Sender's Handle is filled in by the sender, and returned 277 unchanged by the receiver in the echo reply (if any). There are no 278 semantics associated with this handle, although a sender may find 279 this useful for matching up requests with replies. 281 The Sequence Number is assigned by the sender of the MPLS echo 282 request, and can be (for example) used to detect missed replies. 284 The TimeStamp Sent is the time-of-day (in seconds and microseconds, 285 according to the sender's clock) when the MPLS echo request is sent. 286 The TimeStamp Received in an echo reply is the time-of-day (according 287 to the receiver's clock) that the corresponding echo request was 288 received. 290 TLVs (Type-Length-Value tuples) have the following format: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Value | 298 . . 299 . . 300 . . 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Types are defined below; Length is the length of the Value field in 305 octets. The Value field depends on the Type; it is zero padded to 306 align to a four-octet boundary. TLVs may be nested within other 307 TLVs, in which case the nested TLVs are called sub-TLVs. Sub-TLVs 308 have independent types and MUST also be four-octet aligned. 310 Two examples follow. The LDP IPv4 FEC sub-TLV has the following for- 311 mat: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type = 1 (LDP IPv4 FEC) | Length = 5 | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | IPv4 prefix | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Prefix Length | Must Be Zero | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 The Length for this TLV is 5. A Target FEC Stack TLV which contains 324 an LDP IPv4 FEC sub-TLV and a VPN IPv4 prefix sub-TLV has the format: 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Type = 1 (FEC TLV) | Length = 12 | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | sub-Type = 1 (LDP IPv4 FEC) | Length = 5 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | IPv4 prefix | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Prefix Length | Must Be Zero | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | sub-Type = 6 (VPN IPv4 prefix)| Length = 13 | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Route Distinguisher | 340 | (8 octets) | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | IPv4 prefix | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Prefix Length | Must Be Zero | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 A description of the Types and Values of the top level TLVs for LSP 348 ping are given below: 350 Type # Value Field 351 ------ ----------- 352 1 Target FEC Stack 353 2 Downstream Mapping 354 3 Pad 355 4 Not Assigned 356 5 Vendor Enterprise Code 357 6 Not Assigned 358 7 Interface and Label Stack 359 8 Not Assigned 360 9 Errored TLVs 361 10 Reply TOS Byte 363 Types less than 32768 (i.e., with the high order bit equal to 0) are 364 mandatory TLVs that MUST either be supported by an implementation or 365 result in the return code of 2 ("One or more of the TLVs was not 366 understood") being sent in the echo response. 368 Types greater than or equal to 32768 (i.e., with the high order bit 369 equal to 1) are optional TLVs that SHOULD be ignored if the implemen- 370 tation does not understand or support them. 372 3.1. Return Codes 374 The Return Code is set to zero by the sender. The receiver can set 375 it to one of the values listed below. The notation refers to 376 the Return Subcode. This field is filled in with the stack-depth for 377 those codes which specify that. For all other codes the Return Sub- 378 code MUST be set to zero. 380 Value Meaning 381 ----- ------- 383 0 No return code 385 1 Malformed echo request received 387 2 One or more of the TLVs was not understood 389 3 Replying router is an egress for the FEC at stack 390 depth 392 4 Replying router has no mapping for the FEC at stack 393 depth 395 5 Downstream Mapping Mismatch (See Note 1) 397 6 Upstream Interface Index Unknown (See Note 1) 399 7 Reserved 401 8 Label switched at stack-depth 403 9 Label switched but no MPLS forwarding at stack-depth 404 406 10 Mapping for this FEC is not the given label at stack 407 depth 409 11 No label entry at stack-depth 411 12 Protocol not associated with interface at FEC stack 412 depth 414 13 Premature termination of ping due to label stack 415 shrinking to a single label 417 Note 1 419 The Return Subcode contains the point in the label stack where pro- 420 cessing was terminated. If the RSC is 0, no labels were processed. 421 Otherwise the packet would have been label switched at depth RSC. 423 3.2. Target FEC Stack 425 A Target FEC Stack is a list of sub-TLVs. The number of elements is 426 determined by looking at the sub-TLV length fields. 428 Sub-Type Length Value Field 429 -------- ------ ----------- 430 1 5 LDP IPv4 prefix 431 2 17 LDP IPv6 prefix 432 3 20 RSVP IPv4 LSP 433 4 56 RSVP IPv6 LSP 434 5 Not Assigned 435 6 13 VPN IPv4 prefix 436 7 25 VPN IPv6 prefix 437 8 14 L2 VPN endpoint 438 9 10 "FEC 128" Pseudowire (deprecated) 439 10 14 "FEC 128" Pseudowire 440 11 16+ "FEC 129" Pseudowire 441 12 5 BGP labeled IPv4 prefix 442 13 17 BGP labeled IPv6 prefix 443 14 5 Generic IPv4 prefix 444 15 17 Generic IPv6 prefix 445 16 4 Nil FEC 447 Other FEC Types will be defined as needed. 449 Note that this TLV defines a stack of FECs, the first FEC element 450 corresponding to the top of the label stack, etc. 452 An MPLS echo request MUST have a Target FEC Stack that describes the 453 FEC stack being tested. For example, if an LSR X has an LDP mapping 454 [see LDP] for 192.168.1.1 (say label 1001), then to verify that label 455 1001 does indeed reach an egress LSR that announced this prefix via 456 LDP, X can send an MPLS echo request with a FEC Stack TLV with one 457 FEC in it, namely of type LDP IPv4 prefix, with prefix 458 192.168.1.1/32, and send the echo request with a label of 1001. 460 Say LSR X wanted to verify that a label stack of <1001, 23456> is the 461 right label stack to use to reach a VPN IPv4 prefix [see section 462 3.2.5] of 10/8 in VPN foo. Say further that LSR Y with loopback 463 address 192.168.1.1 announced prefix 10/8 with Route Distinguisher 464 RD-foo-Y (which may in general be different from the Route Distin- 465 guisher that LSR X uses in its own advertisements for VPN foo), label 466 23456 and BGP nexthop 192.168.1.1 [see BGP]. Finally, suppose that 467 LSR X receives a label binding of 1001 for 192.168.1.1 via LDP. X 468 has two choices in sending an MPLS echo request: X can send an MPLS 469 echo request with a FEC Stack TLV with a single FEC of type VPN IPv4 470 prefix with a prefix of 10/8 and a Route Distinguisher of RD-foo-Y. 471 Alternatively, X can send a FEC Stack TLV with two FECs, the first of 472 type LDP IPv4 with a prefix of 192.168.1.1/32 and the second of type 473 of IP VPN with a prefix 10/8 with Route Distinguisher of RD-foo-Y. 474 In either case, the MPLS echo request would have a label stack of 475 <1001, 23456>. (Note: in this example, 1001 is the "outer" label and 476 23456 is the "inner" label.) 478 3.2.1. LDP IPv4 Prefix 480 The IPv4 Prefix FEC is defined in [LDP]. When a LDP IPv4 prefix is 481 encoded in a label stack, the following format is used. The value 482 consists of four octets of an IPv4 prefix followed by one octet of 483 prefix length in bits; the format is given below. The IPv4 prefix is 484 in network byte order; if the prefix is shorter than 32 bits, trail- 485 ing bits SHOULD be set to zero. See [LDP] for an example of a Map- 486 ping for an IPv4 FEC. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | IPv4 prefix | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Prefix Length | Must Be Zero | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 3.2.2. LDP IPv6 Prefix 498 The IPv6 Prefix FEC is defined in [LDP]. When a LDP IPv6 prefix is 499 encoded in a label stack, the following format is used. The value 500 consists of sixteen octets of an IPv6 prefix followed by one octet of 501 prefix length in bits; the format is given below. The IPv6 prefix is 502 in network byte order; if the prefix is shorter than 128 bits, the 503 trailing bits SHOULD be set to zero. See [LDP] for an example of a 504 Mapping for an IPv6 FEC. 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | IPv6 prefix | 510 | (16 octets) | 511 | | 512 | | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Prefix Length | Must Be Zero | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 3.2.3. RSVP IPv4 LSP 519 The value has the format below. The value fields are taken from 520 RFC3209, sections 4.6.1.1 and 4.6.2.1. See [RSVP-TE]. 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | IPv4 tunnel end point address | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Must Be Zero | Tunnel ID | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Extended Tunnel ID | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | IPv4 tunnel sender address | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Must Be Zero | LSP ID | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 3.2.4. RSVP IPv6 LSP 538 The value has the format below. The value fields are taken from 539 RFC3209, sections 4.6.1.2 and 4.6.2.2. See [RSVP-TE]. 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | IPv6 tunnel end point address | 545 | | 546 | | 547 | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Must Be Zero | Tunnel ID | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Extended Tunnel ID | 552 | | 553 | | 554 | | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | IPv6 tunnel sender address | 557 | | 558 | | 559 | | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Must Be Zero | LSP ID | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 3.2.5. VPN IPv4 Prefix 566 VPN-IPv4 NLRI (Network Layer Routing Information) is defined in 567 [MPLS-L3-VPN]. This document uses the term VPN IPv4 prefix for a 568 VPN-IPv4 NLRI which has been advertised with an MPLS label in BGP. 569 See [BGP-LABEL]. 571 When a VPN IPv4 prefix is encoded in a label stack, the following 572 format is used. The value field consists of the Route Distinguisher 573 advertised with the VPN IPv4 prefix, the IPv4 prefix (with trailing 0 574 bits to make 32 bits in all) and a prefix length, as follows: 576 0 1 2 3 577 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Route Distinguisher | 580 | (8 octets) | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | IPv4 prefix | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Prefix Length | Must Be Zero | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 3.2.6. VPN IPv6 Prefix 589 VPN-IPv6 NLRI (Network Layer Routing Information) is defined in 590 [MPLS-L3-VPN]. This document uses the term VPN IPv6 prefix for a 591 VPN-IPv6 NLRI which has been advertised with an MPLS label in BGP. 592 See [BGP-LABEL]. 594 When a VPN IPv6 prefix is encoded in a label stack, the following 595 format is used. The value field consists of the Route Distinguisher 596 advertised with the VPN IPv6 prefix, the IPv6 prefix (with trailing 0 597 bits to make 128 bits in all) and a prefix length, as follows: 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Route Distinguisher | 603 | (8 octets) | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | IPv6 prefix | 606 | | 607 | | 608 | | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Prefix Length | Must Be Zero | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 3.2.7. L2 VPN Endpoint 615 VPLS BGP NLRI and VE ID are defined in [VPLS]. This document uses 616 the simpler term L2 VPN endpoint when refering to a VPLS BGP NLRI. 617 When an L2 VPN endpoint is encoded in a label stack, the following 618 format is used. The value field consists of a Route Distinguisher (8 619 octets), the sender (of the ping)'s VE ID (2 octets), the receiver's 620 VE ID (2 octets), and an encapsulation type (2 octets), formatted as 621 follows: 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Route Distinguisher | 627 | (8 octets) | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Sender's VE ID | Receiver's VE ID | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Encapsulation Type | Must Be Zero | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 3.2.8. FEC 128 Pseudowire (Deprecated) 636 FEC 128 and the term VC ID are defined in [PW-CONTROL]. When a FEC 637 128 is encoded in a label stack, the following format is used. The 638 value field consists of the remote PE address (the destination 639 address of the targeted LDP session), a VC ID and an encapsulation 640 type, as follows: 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Remote PE Address | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | VC ID | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Encapsulation Type | Must Be Zero | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 This FEC is deprecated and is retained only for backward compatibil- 653 ity. Implementations of LSP ping SHOULD accept and process this TLV, 654 but SHOULD send LSP ping echo requests with the new TLV (see next 655 section), unless explicitly configured to use the old TLV. 657 An LSR receiving this TLV SHOULD use the source IP address of the LSP 658 echo request to infer the Sender's PE Address. 660 3.2.9. FEC 128 Pseudowire (Current) 662 FEC 128 and the term VC ID are defined in [PW-CONTROL]. When a FEC 663 128 is encoded in a label stack, the following format is used. The 664 value field consists of the sender's PE address (the source address 665 of the targeted LDP session), the remote PE address (the destination 666 address of the targeted LDP session), a VC ID and an encapsulation 667 type, as follows: 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Sender's PE Address | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Remote PE Address | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | VC ID | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Encapsulation Type | Must Be Zero | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 3.2.10. FEC 129 Pseudowire 683 FEC 129 and the terms AII, AGI, SAII, and TAII are defined in [PW- 684 CONTROL]. When a FEC 129 is encoded in a label stack, the following 685 format is used. The Length of this TLV is 16 + AGI length + SAII 686 length + TAII length. Padding is used to make the total length a 687 multiple of 4; the length of the padding is not included in the 688 Length field. 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Sender's PE Address | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Remote PE Address | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | PW Type | AGI Type | AGI Length | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 ~ AGI Value ~ 700 | | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | AII Type | SAII Length | Value | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 ~ SAII Value (contd.) ~ 705 | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | AII Type | TAII Length | Value | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 ~ TAII Value (contd.) ~ 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Value (cont.)| 0-3 octets of zero padding | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 3.2.11. BGP Labeled IPv4 Prefix 716 BGP labeled IPv4 prefixes are defined in [BGP-LABEL]. When a BGP 717 labeled IPv4 prefix is encoded in a label stack, the following format 718 is used. The value field consists the IPv4 prefix (with trailing 0 719 bits to make 32 bits in all), and the prefix length, as follows: 721 0 1 2 3 722 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 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | IPv4 Prefix | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Prefix Length | Must Be Zero | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 3.2.12. BGP Labeled IPv6 Prefix 731 BGP labeled IPv6 prefixes are defined in [BGP-LABEL]. When a BGP 732 labeled IPv6 prefix is encoded in a label stack, the following format 733 is used. The value consists of sixteen octets of an IPv6 prefix fol- 734 lowed by one octet of prefix length in bits; the format is given 735 below. The IPv6 prefix is in network byte order; if the prefix is 736 shorter than 128 bits, the trailing bits SHOULD be set to zero. 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | IPv6 prefix | 742 | (16 octets) | 743 | | 744 | | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Prefix Length | Must Be Zero | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 3.2.13. Generic IPv4 Prefix 751 The value consists of four octets of an IPv4 prefix followed by one 752 octet of prefix length in bits; the format is given below. The IPv4 753 prefix is in network byte order; if the prefix is shorter than 32 754 bits, trailing bits SHOULD be set to zero. This FEC is used if the 755 protocol advertising the label is unknown, or may change during the 756 course of the LSP. An example is an inter-AS LSP that may be sig- 757 naled by LDP in one AS, by RSVP-TE [RSVP-TE] in another AS, and by 758 BGP between the ASes, such as is common for inter-AS VPNs. 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | IPv4 prefix | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Prefix Length | Must Be Zero | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 3.2.14. Generic IPv6 Prefix 770 The value consists of sixteen octets of an IPv6 prefix followed by 771 one octet of prefix length in bits; the format is given below. The 772 IPv6 prefix is in network byte order; if the prefix is shorter than 773 128 bits, the trailing bits SHOULD be set to zero. 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 | IPv6 prefix | 779 | (16 octets) | 780 | | 781 | | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Prefix Length | Must Be Zero | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 3.2.15. Nil FEC 788 At times labels from the reserved range, e.g. Router Alert and 789 Explicit-null, may be added to the label stack for various diagnostic 790 purposes such as influencing load-balancing. These labels may have 791 no explicit FEC associated with them. The Nil FEC stack is defined 792 to allow a Target FEC stack sub-TLV to be added to the target FEC 793 stack to account for such labels so that proper validation can still 794 be performed. 796 The Length is 4. Labels are 20 bit values treated as numbers. 797 stack. 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Label | MBZ | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Label is the actual label value inserted in the label stack; the MBZ 806 fields MUST be zero when sent, and ignored on receipt. 808 3.3. Downstream Mapping 810 The Downstream Mapping object is a TLV which MAY be included in an 811 echo request message. Only one Downstream Mapping object may appear 812 in an echo request. The presence of a Downstream Mapping object is a 813 request that Downstream Mapping objects be included in the echo 814 reply. If the replying router is the destination of the FEC, then a 815 Downstream Mapping TLV SHOULD NOT be included in the echo reply. 816 Otherwise the replying router SHOULD include a Downstream Mapping 817 object for each interface over which this FEC could be forwarded. 818 For a more precise definition of the notion of "downstream", see sec- 819 tion 3.3.2, "Downstream Router and Interface". 821 The Length is K + M + 4*N octets, where M is the Multipath Length, 822 and N is the number of Downstream Labels. Values for K are found in 823 the description of Address Type below. The Value field of a Down- 824 stream Mapping has the following format: 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | MTU | Address Type | DS Flags | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Downstream IP Address (4 or 16 octets) | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Downstream Interface Address (4 or 16 octets) | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Multipath Type| Depth Limit | Multipath Length | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 . . 838 . (Multipath Information) . 839 . . 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Downstream Label | Protocol | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 . . 844 . . 845 . . 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Downstream Label | Protocol | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 Maximum Transmission Unit (MTU) 852 The MTU is the size in octets of the largest MPLS frame (including 853 label stack) that fits on the interface to the Downstream LSR. 855 Address Type 857 The Address Type indicates if the interface is numbered or unnum- 858 bered. It also determines the length of the Downstream IP Address 859 and Downstream Interface fields. The resulting total for the initial 860 part of the TLV is listed in the table below as "K Octets". The 861 Address Type is set to one of the following values: 863 Type # Address Type K Octets 864 ------ ------------ -------- 865 1 IPv4 Numbered 16 866 2 IPv4 Unnumbered 16 867 3 IPv6 Numbered 40 868 4 IPv6 Unnumbered 28 870 DS Flags 872 The DS Flags field is a bit vector with the following format: 874 0 1 2 3 4 5 6 7 875 +-+-+-+-+-+-+-+-+ 876 | Rsvd(MBZ) |I|N| 877 +-+-+-+-+-+-+-+-+ 879 Two flags are defined currently, I and N. The remaining flags MUST 880 be set to zero when sending, and ignored on receipt. 882 Flag Name and Meaning 883 ---- ---------------- 885 I Interface and Label Stack Object Request 887 When this flag is set, it indicates that the replying 888 router SHOULD include an Interface and Label Stack 889 Object in the echo reply message 891 N Treat as a Non-IP Packet 893 Echo request messages will be used to diagnose non-IP 894 flows. However, these messages are carried in IP 895 packets. For a router which alters its ECMP algorithm 896 based on the FEC or deep packet examination, this flag 897 requests that the router treat this as it would if the 898 determination of an IP payload had failed. 900 Downstream IP Address and Downstream Interface Address 902 IPv4 addresses and and interface indices are encoded in 4 octets, 903 IPv6 addresses are encoded in 16 octets. 905 If the interface to the downstream LSR is numbered, then the Address 906 Type MUST be set to IPv4 or IPv6, the Downstream IP Address MUST be 907 set to either the downstream LSR's Router ID or the interface address 908 of the downstream LSR, and the Downstream Interface Address MUST be 909 set to the downstream LSR's interface address. 911 If the interface to the downstream LSR is unnumbered, the Address 912 Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP 913 Address MUST be the downstream LSR's Router ID, and the Downstream 914 Interface Address MUST be set to the index assigned by the upstream 915 LSR to the interface. 917 If an LSR does not know the IP address of its neighbor, then it MUST 918 set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. 919 For IPv4 it must set the Downstream IP Address to 127.0.0.1, for IPv6 920 the address is set to 0::1. In both cases the interface index MUST 921 be set to 0. If an LSR receives an Echo Request packet with either 922 of these addresses in the Downstream IP Address field, this indicates 923 that it MUST bypass interface verification but continue with label 924 validation. 926 If the originator of an Echo Request packet wishes to obtain Down- 927 stream mapping information but does not know the expected label stack 928 then it SHOULD set the Address Type to either IPv4 Unnumbered or IPv6 929 Unnumbered. For IPv4 it MUST set the Downstream IP Address to 930 224.0.0.2, for IPv6 the address MUST be set to FF02::2. In both 931 cases the interface index MUST be set to 0. If an LSR receives an 932 Echo Request packet with the all-routers multicast address, then this 933 indicates that it MUST bypass both interface and label stack valida- 934 tion, but return Downstream Mapping TLVs using the information pro- 935 vided. 937 Multipath Type 939 The following Multipath Types are defined: 941 Key Type Multipath Information 942 --- ---------------- --------------------- 943 0 no multipath Empty (Multipath Length = 0) 944 2 IP address IP addresses 945 4 IP address range low/high address pairs 946 8 Bit-masked IPv4 IP address prefix and bit mask 947 address set 948 9 Bit-masked label set Label prefix and bit mask 950 Type 0 indicates that all packets will be forwarded out this one 951 interface. 953 Types 2, 4, 8 and 9 specify that the supplied Multipath Information 954 will serve to exercise this path. 956 Depth Limit 958 The Depth Limit is applicable only to a label stack, and is the maxi- 959 mum number of labels considered in the hash; this SHOULD be set to 960 zero if unspecified or unlimited. 962 Multipath Length 964 The length in octets of the Multipath Information. 966 Multipath Information 968 Address or label values encoded according to the Multipath Type. See 969 the next section below for encoding details. 971 Downstream Label(s) 973 The set of labels in the label stack as it would have appeared if 974 this router were forwarding the packet through this interface. Any 975 Implicit Null labels are explicitly included. Labels are treated as 976 numbers, i.e. they are right justified in the field. 978 A Downstream Label is 24 bits, in the same format as an MPLS label 979 minus the TTL field, i.e., the MSBit of the label is bit 0, the LSbit 980 is bit 19, the EXP bits are bits 20-22, and bit 23 is the S bit. The 981 replying router SHOULD fill in the EXP and S bits; the LSR receiving 982 the echo reply MAY choose to ignore these bits. 984 Protocol 986 The Protocol is taken from the following table: 988 Protocol # Signaling Protocol 989 ---------- ------------------ 990 0 Unknown 991 1 Static 992 2 BGP 993 3 LDP 994 4 RSVP-TE 996 3.3.1. Multipath Information Encoding 998 The multipath information encodes labels or addresses which will 999 exercise this path. The multipath information depends on the multi- 1000 path type. The contents of the field are shown in the table above. 1001 IP addresses are drawn from the range 127/8. Labels are treated as 1002 numbers, i.e. they are right justified in the field. For Type 4, 1003 ranges indicated by Address pairs MUST NOT overlap and MUST be in 1004 ascending sequence. 1006 Type 8 allows a denser encoding of IP address. The IPv4 prefix is 1007 formatted as a base IPv4 address with the non-prefix low order bits 1008 set to zero. The maximum prefix length is 27. Following the prefix 1009 is a mask of length 2^(32-prefix length) bits. Each bit set to one 1010 represents a valid address. The address is the base IPv4 address 1011 plus the position of the bit in the mask where the bits are numbered 1012 left to right beginning with zero. For example the IP addresses 1013 127.2.1.0, 127.2.1.5-127.2.1.15, and 127.2.1.20-127.2.1.29 would be 1014 encoded as follows: 1016 0 1 2 3 1017 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 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 |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| 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 |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| 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 Type 9 allows a denser encoding of Labels. The label prefix is for- 1025 matted as a base label value with the non-prefix low order bits set 1026 to zero. The maximum prefix (including leading zeros due to encod- 1027 ing) length is 27. Following the prefix is a mask of length 1028 2^(32-prefix length) bits. Each bit set to one represents a valid 1029 Label. The label is the base label plus the position of the bit in 1030 the mask where the bits are numbered left to right beginning with 1031 zero. Label values of all the odd numbers between 1152 and 1279 1032 would be encoded as follows: 1034 0 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 |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| 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 |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| 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 |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| 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 |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| 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 |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| 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 If the received multipath information is non-null, the labels and IP 1049 addresses MUST be picked from the set provided. If none of these 1050 labels or addresses map to a particular downstream interface, then 1051 for that interface, the type MUST be set to 0. If the received mul- 1052 tipath information is null, (i.e. Multipath Length = 0, or for Types 1053 8 and 9 a mask of all zeroes) the receiver the type MUST be set to 0. 1055 For example, suppose LSR X at hop 10 has two downstream LSRs Y and Z 1056 for the FEC in question. The received X could return Multipath Type 1057 4, with low/high IP addresses of 127.1.1.1->127.1.1.255 for down- 1058 stream LSR Y and 127.2.1.1->127.2.1.255 for downstream LSR Z. The 1059 head end reflects this information to LSR Y. Y, which has three 1060 downstream LSRs U, V and W, computes that 127.1.1.1->127.1.1.127 1061 would go to U and 127.1.1.128-> 127.1.1.255 would go to V. Y would 1062 then respond with 3 Downstream Mappings: to U, with Multipath Type 4 1063 (127.1.1.1->127.1.1.127); to V, with Multipath Type 4 1064 (127.1.1.127->127.1.1.255); and to W, with Multipath Type 0. 1066 Note that computing multi-path information may impose a significant 1067 processing burden on the receiver. A receiver MAY thus choose to 1068 process a subset of the received prefixes. The sender, on receiving 1069 a reply to a Downstream Map with partial information, SHOULD assume 1070 that the prefixes missing in the reply were skipped by the receiver, 1071 and MAY re-request information about them in a new echo request. 1073 3.3.2. Downstream Router and Interface 1075 The notion of "downstream router" and "downstream interface" should 1076 be explained. Consider an LSR X. If a packet that was originated 1077 with TTL n>1 arrived with outermost label L and TTL=1 at LSR X, X 1078 must be able to compute which LSRs could receive the packet if it was 1079 originated with TTL=n+1, over which interface the request would 1080 arrive and what label stack those LSRs would see. (It is outside the 1081 scope of this document to specify how this computation is done.) The 1082 set of these LSRs/interfaces are the downstream routers/interfaces 1083 (and their corresponding labels) for X with respect to L. Each pair 1084 of downstream router and interface requires a separate Downstream 1085 Mapping to be added to the reply. 1087 The case where X is the LSR originating the echo request is a special 1088 case. X needs to figure out what LSRs would receive the MPLS echo 1089 request for a given FEC Stack that X originates with TTL=1. 1091 The set of downstream routers at X may be alternative paths (see the 1092 discussion below on ECMP) or simultaneous paths (e.g., for MPLS mul- 1093 ticast). In the former case, the Multipath Information is used as a 1094 hint to the sender as to how it may influence the choice of these 1095 alternatives. 1097 3.4. Pad TLV 1099 The value part of the Pad TLV contains a variable number (>= 1) of 1100 octets. The first octet takes values from the following table; all 1101 the other octets (if any) are ignored. The receiver SHOULD verify 1102 that the TLV is received in its entirety, but otherwise ignores the 1103 contents of this TLV, apart from the first octet. 1105 Value Meaning 1106 ----- ------- 1107 1 Drop Pad TLV from reply 1108 2 Copy Pad TLV to reply 1109 3-255 Reserved for future use 1111 3.5. Vendor Enterprise Code 1113 The Length is always 4; the value is the SMI Enterprise code, in net- 1114 work octet order, of the vendor with a Vendor Private extension to 1115 any of the fields in the fixed part of the message, in which case 1116 this TLV MUST be present. If none of the fields in the fixed part of 1117 the message have vendor private extensions, inclusion of this this 1118 TLV in is OPTIONAL. Vendor private ranges for Message Types, Reply 1119 Modes, and Return Codes have been defined. When any of these are 1120 used the Vendor Enterprise Code TLV MUST be included in the message. 1122 3.6. Interface and Label Stack 1124 The Interface and Label Stack TLV MAY be included in a reply message 1125 to report the interface on which the request message was received and 1126 the label stack which was on the packet when it was received. Only 1127 one such object may appear. The purpose of the object is to allow 1128 the upstream router to obtain the exact interface and label stack 1129 information as it appears at the replying LSR. 1131 The Length is K + 4*N octets, N is the number of labels in the Label 1132 Stack. Values for K are found in the description of Address Type 1133 below. The Value field of a Downstream Mapping has the following 1134 format: 1136 0 1 2 3 1137 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 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Address Type | Must be Zero | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | IP Address (4 or 16 octets) | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | Interface (4 or 16 octets) | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 . . 1146 . . 1147 . Label Stack . 1148 . . 1149 . . 1150 . . 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 Address Type 1155 The Address Type indicates if the interface is numbered or unnum- 1156 bered. It also determines the length of the IP Address and Interface 1157 fields. The resulting total for the initial part of the TLV is 1158 listed in the table below as "K Octets". The Address Type is set to 1159 one of the following values: 1161 Type # Address Type K Octets 1162 ------ ------------ -------- 1163 1 IPv4 Numbered 12 1164 2 IPv4 Unnumbered 12 1165 3 IPv6 Numbered 36 1166 4 IPv6 Unnumbered 24 1168 IP Address and Interface 1170 IPv4 addresses and and interface indices are encoded in 4 octets, 1171 IPv6 addresses are encoded in 16 octets. 1173 If the interface upon which the echo request message was received is 1174 numbered, then the Address Type MUST be set to IPv4 or IPv6, the IP 1175 Address MUST be set to either the LSR's Router ID or the interface 1176 address, and the Interface MUST be set to the interface address. 1178 If the interface unnumbered, the Address Type MUST be either IPv4 1179 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the LSR's 1180 Router ID, and the Interface MUST be set to the index assigned to the 1181 interface. 1183 Label Stack 1185 The label stack of the received echo request message. If any TTL 1186 values have been changed by this router, they SHOULD be restored. 1188 3.7. Errored TLVs 1190 The following TLV is a TLV which MAY be included in an echo reply to 1191 inform the sender of an echo request of Mandatory TLVs either not 1192 supported by an implementation, or parsed and found to be in error. 1194 The Value field contains the TLVs that were not understood, encoded 1195 as sub-TLVs. 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 | Type = 9 | Length | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Value | 1203 . . 1204 . . 1205 . . 1206 | | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 3.8. Reply TOS Byte TLV 1211 This TLV MAY be used by the originator of the echo request to 1212 request 1213 that a echo reply be sent with the IP header TOS byte set to 1214 the value specified in the TLV. This TLV has a length of 4 with 1215 the following value field. 1217 0 1 2 3 1218 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 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | Reply-TOS Byte| Must be zero | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 4. Theory of Operation 1225 An MPLS echo request is used to test a particular LSP. The LSP to be 1226 tested is identified by the "FEC Stack"; for example, if the LSP was 1227 set up via LDP, and is to an egress IP address of 10.1.1.1, the FEC 1228 stack contains a single element, namely, an LDP IPv4 prefix sub-TLV 1229 with value 10.1.1.1/32. If the LSP being tested is an RSVP LSP, the 1230 FEC stack consists of a single element that captures the RSVP Session 1231 and Sender Template which uniquely identifies the LSP. 1233 FEC stacks can be more complex. For example, one may wish to test a 1234 VPN IPv4 prefix of 10.1/8 that is tunneled over an LDP LSP with 1235 egress 10.10.1.1. The FEC stack would then contain two sub-TLVs, the 1236 bottom being a VPN IPv4 prefix, and the top being an LDP IPv4 prefix. 1237 If the underlying (LDP) tunnel were not known, or was considered 1238 irrelevant, the FEC stack could be a single element with just the VPN 1239 IPv4 sub-TLV. 1241 When an MPLS echo request is received, the receiver is expected to 1242 verify that the control plane and data plane are both healthy (for 1243 the FEC stack being pinged), and that the two planes are in sync. 1244 The procedures for this are in section 4.4 below. 1246 4.1. Dealing with Equal-Cost Multi-Path (ECMP) 1248 LSPs need not be simple point-to-point tunnels. Frequently, a single 1249 LSP may originate at several ingresses, and terminate at several 1250 egresses; this is very common with LDP LSPs. LSPs for a given FEC 1251 may also have multiple "next hops" at transit LSRs. At an ingress, 1252 there may also be several different LSPs to choose from to get to the 1253 desired endpoint. Finally, LSPs may have backup paths, detour paths 1254 and other alternative paths to take should the primary LSP go down. 1256 To deal with the last two first: it is assumed that the LSR sourcing 1257 MPLS echo requests can force the echo request into any desired LSP, 1258 so choosing among multiple LSPs at the ingress is not an issue. The 1259 problem of probing the various flavors of backup paths that will typ- 1260 ically not be used for forwarding data unless the primary LSP is down 1261 will not be addressed here. 1263 Since the actual LSP and path that a given packet may take may not be 1264 known a priori, it is useful if MPLS echo requests can exercise all 1265 possible paths. This, while desirable, may not be practical, because 1266 the algorithms that a given LSR uses to distribute packets over 1267 alternative paths may be proprietary. 1269 To achieve some degree of coverage of alternate paths, there is a 1270 certain latitude in choosing the destination IP address and source 1271 UDP port for an MPLS echo request. This is clearly not sufficient; 1272 in the case of traceroute, more latitude is offered by means of the 1273 Multipath Information of the Downstream Mapping TLV. This is used as 1274 follows. An ingress LSR periodically sends an MPLS traceroute mes- 1275 sage to determine whether there are multipaths for a given LSP. If 1276 so, each hop will provide some information how each of its downstream 1277 paths can be exercised. The ingress can then send MPLS echo requests 1278 that exercise these paths. If several transit LSRs have ECMP, the 1279 ingress may attempt to compose these to exercise all possible paths. 1280 However, full coverage may not be possible. 1282 4.2. Testing LSPs That Are Used to Carry MPLS Payloads 1284 To detect certain LSP breakages, it may be necessary to encapsulate 1285 an MPLS echo request packet with at least one additional label when 1286 testing LSPs that are used to carry MPLS payloads (such as LSPs used 1287 to carry L2VPN and L3VPN traffic. For example, when testing LDP or 1288 RSVP-TE LSPs, just sending an MPLS echo request packet may not detect 1289 instances where the router immediately upstream of the destination of 1290 the LSP ping may forward the MPLS echo request successfully over an 1291 interface not configured to carry MPLS payloads because of the use of 1292 penultimate hop popping. Since the receiving router has no means to 1293 differentiate whether the IP packet was sent unlabeled or implicitly 1294 labeled, the addition of labels shimmed above the MPLS echo request 1295 (using the Nil FEC) will prevent a router from forwarding such a 1296 packet out unlabeled interfaces. 1298 4.3. Sending an MPLS Echo Request 1300 An MPLS echo request is a (possibly) labeled UDP packet. The IP 1301 header is set as follows: the source IP address is a routable address 1302 of the sender; the destination IP address is a (randomly chosen) 1303 address from 127/8; the IP TTL is set to 1. The source UDP port is 1304 chosen by the sender; the destination UDP port is set to 3503 1305 (assigned by IANA for MPLS echo requests). The Router Alert option 1306 is set in the IP header. 1308 If the echo request is labeled, one may (depending on what is being 1309 pinged) set the TTL of the innermost label to 1, to prevent the ping 1310 request going farther than it should. Examples of this include ping- 1311 ing a VPN IPv4 or IPv6 prefix, an L2 VPN end point or a pseudowire. 1312 This can also be accomplished by inserting a router alert label above 1313 this label; however, this may lead to the undesired side effect that 1314 MPLS echo requests take a different data path than actual data. 1316 In "ping" mode (end-to-end connectivity check), the TTL in the outer- 1317 most label is set to 255. In "traceroute" mode (fault isolation 1318 mode), the TTL is set successively to 1, 2, .... 1320 The sender chooses a Sender's Handle, and a Sequence Number. When 1321 sending subsequent MPLS echo requests, the sender SHOULD increment 1322 the sequence number by 1. However, a sender MAY choose to send a 1323 group of echo requests with the same sequence number to improve the 1324 chance of arrival of at least one packet with that sequence number. 1326 The TimeStamp Sent is set to the time-of-day (in seconds and 1327 microseconds) that the echo request is sent. The TimeStamp Received 1328 is set to zero. 1330 An MPLS echo request MUST have a FEC Stack TLV. Also, the Reply Mode 1331 must be set to the desired reply mode; the Return Code and Subcode 1332 are set to zero. In the "traceroute" mode, the echo request SHOULD 1333 include a Downstream Mapping TLV. 1335 4.4. Receiving an MPLS Echo Request 1337 An LSR X that receives an MPLS echo request first parses the packet 1338 to ensure that it is a well-formed packet, and that the TLVs that are 1339 not marked "Ignore" are understood. If not, X SHOULD send an MPLS 1340 echo reply with the Return Code set to "Malformed echo request 1341 received" or "TLV not understood" (as appropriate), and the Subcode 1342 set to zero. In the latter case, the misunderstood TLVs (only) are 1343 included in the reply. 1345 If the echo request is good, X notes the interface I over which the 1346 echo was received, and the label stack with which it came. 1348 For reporting purposes the bottom of stack is considered to be stack- 1349 depth of 1. This is to establish an absolute reference for the case 1350 where the stack may have more labels than are in the FEC stack. Fur- 1351 ther, in all the error codes listed in this document a stack-depth of 1352 0 means "no value specified". This allows compatibility with exist- 1353 ing implementations which do not use the Return Subcode field. 1355 X employs two variables, called FEC-stack-depth and Label-stack- 1356 depth. X sets Label-stack-depth to the number of labels in the 1357 received label stack. If the label-stack-depth is 0, assume there is 1358 one implicit null label and set label-stack-depth to 1. FEC-stack- 1359 depth is used later and need not be initialized. Processing now con- 1360 tinues with the following steps: 1362 Label_Validation: 1364 If the label at Label-stack-depth is valid, goto Label_Operation. 1365 If not, set Best-return-code to 11, "No label entry at stack-depth" 1366 and Best-return-subcode to Label-stack-depth. Goto 1367 Send_Reply_Packet. 1369 Label_Operation: 1371 Switch on label operation. 1373 Case: Pop and Continue Processing (Note: this includes 1374 Explicit_Null and Router_Alert) 1376 If Label-stack-depth is greater than 1, decrement Label-stack- 1377 depth and goto Label_Validation. Otherwise, set FEC-stack-depth 1378 to 1, set Best-return-code to 3 "Replying router is an egress for 1379 the FEC at stack depth", set Best-return-subcode to 1 and goto 1380 Egress_Processing. 1382 Case: Swap or Pop and Switch based on Popped Label 1384 If the label operation is either swap or pop and switch based on 1385 the popped label, Best-return-code to 8, "Label switched at 1386 stack-depth" and Best-return-subcode to Label-stack-depth. 1388 If a Downstream Mapping TLV is present, a Downstream mapping TLVs 1389 SHOULD be created for each multipath. 1391 Determine the output interface. If it is not valid to forward a 1392 labeled packet on this interface, set Best-return-code to Return 1393 Code 9, "Label switched but no MPLS forwarding at stack-depth" 1394 and set Best-return-subcode to Label-stack-depth and goto 1395 Send_Reply_Packet. (Note: this return code is set even if Label- 1396 stack-depth is one.) 1398 If no Downstream Mapping TLV is present, or the Downstream IP 1399 Address is set to the All-Routers multicast address goto 1400 Send_Reply_Packet. 1402 Verify that the IP address, interface address and label stack 1403 match the received interface and label stack. If the IP address 1404 is either 127.0.0.1 or 0::1 bypass the interface check, and set 1405 Best-return-code to 6, "Upstream Interface Index Unknown". For 1406 any other error, set Best-return-code to 5, "Downstream Mapping 1407 Mis-match". For either error, an Interface and Label Stack TLV 1408 SHOULD be created. If Best-return-code equals 5, goto 1409 Send_Reply_Packet. 1411 If the "Validate FEC Stack" flag is not set, goto 1412 Send_Reply_Packet. 1414 Locate the label at Label-stack-depth in the Downstream Labels by 1415 counting from the bottom of the stack, skipping over, but count- 1416 ing Implicit Null labels and set FEC-stack-depth to that depth. 1417 (Note: If the Downstream Labels contain one or more Implicit Null 1418 labels, this may be at a depth greater than Label-stack-depth.) 1420 If the depth of the FEC stack is greater than or equal to FEC- 1421 stack-depth, Perform FEC Checking. If FEC-status is 2, set Best- 1422 return-code to 10, "Mapping for this FEC is not the given label 1423 at stack-depth". 1425 If the return code is 1 set Best-return-code to FEC-return-code 1426 and Best-return-subcode to FEC-stack-depth. 1428 Goto Send_Reply_Packet. 1430 Egress_Processing: 1432 If no Downstream Mapping TLV is present, goto Egress_FEC_Valida- 1433 tion. 1435 Verify that the IP address, interface address and label stack match 1436 the received interface and label stack. If not, set Best-return- 1437 code to 5, "Downstream Mapping Mis-match". A Received Interface 1438 and Label Stack TLV SHOULD be created. Goto Send_Reply_Packet. 1440 Egress_FEC_Validation: 1442 Perform FEC checking. If FEC-status is 1, set Best-return-code 1443 to FEC-code and Best-return-subcode to FEC-stack-depth. Goto 1444 Send_Reply_Packet. 1446 Increment FEC-stack-depth. If FEC-stack-depth is greater than 1447 the number of FECs in the FEC-stack, goto Send_Reply_Packet. If 1448 FEC-status is 0, increment Label-stack-depth. Goto 1449 Egress_FEC_Validation. 1451 Send_Reply_Packet: 1453 Send an MPLS echo reply with a Return Code of Best-return-code, 1454 and a Return Subcode of Best-return-subcode. Include any TLVs 1455 created during the above process. The procedures for sending the 1456 echo reply are found in the next subsection below. 1458 FEC_Checking: 1460 This routine accepts a FEC, Label, and Interface. It returns two 1461 values, FEC-status and FEC-return-code, both of which are 1462 initialized to 0. 1464 If the FEC is the Nil FEC, check that Label is either 1465 Explicit_Null or Router_Alert. If so return. Else 1466 set FEC-return-code to 10, "Mapping for this FEC is not the given 1467 label at stack-depth". Set FEC-status to 1 and return. 1469 Check that the label mapping for FEC. If no mapping exists, set 1470 FEC-return-code to Return 4, "Replying router has no mapping for 1471 the FEC at stack-depth". Set FEC-status to 1. Return. 1473 If the label mapping for FEC is Implicit Null, set FEC-status to 1474 2. Goto Check_Protocol. 1476 If the label mapping for FEC is Label, goto Check_Protocol. Else 1477 set FEC-return-code to 10, "Mapping for this FEC is not the given 1478 label at stack-depth". Set FEC-status to 1 and return. 1480 Check_Protocol: 1482 Check what protocol would be used to advertise FEC. If it can be 1483 determined that no protocol associated with interface I would 1484 have advertised a FEC of that FEC-Type, set FEC-return-code to 1485 12, "Protocol not associated with interface at FEC stack-depth". 1486 Set FEC-status to 1. Return. 1488 4.5. Sending an MPLS Echo Reply 1490 An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response 1491 to an MPLS echo request. The source IP address is a routable address 1492 of the replier; the source port is the well-known UDP port for LSP 1493 ping. The destination IP address and UDP port are copied from the 1494 source IP address and UDP port of the echo request. The IP TTL is 1495 set to 255. If the Reply Mode in the echo request is "Reply via an 1496 IPv4 UDP packet with Router Alert", then the IP header MUST contain 1497 the Router Alert IP option. If the reply is sent over an LSP, the 1498 topmost label MUST in this case be the Router Alert label (1) (see 1500 [LABEL-STACK]). 1502 The format of the echo reply is the same as the echo request. The 1503 Sender's Handle, the Sequence Number and TimeStamp Sent are copied 1504 from the echo request; the TimeStamp Received is set to the time-of- 1505 day that the echo request is received (note that this information is 1506 most useful if the time-of-day clocks on the requester and the 1507 replier are synchronized). The FEC Stack TLV from the echo request 1508 MAY be copied to the reply. 1510 The replier MUST fill in the Return Code and Subcode, as determined 1511 in the previous subsection. 1513 If the echo request contains a Pad TLV, the replier MUST interpret 1514 the first octet for instructions regarding how to reply. 1516 If the replying router is the destination of the FEC, then Downstream 1517 Mapping TLVs SHOULD NOT be included in the echo reply. 1519 If the echo request contains a Downstream Mapping TLV, and the reply- 1520 ing router is not the destination of the FEC, the replier SHOULD com- 1521 pute its downstream routers and corresponding labels for the incoming 1522 label, and add Downstream Mapping TLVs for each one to the echo reply 1523 it sends back. 1525 If the Downstream Mapping TLV contains multipath information requir- 1526 ing more processing than the receiving router is willing to perform, 1527 the responding router MAY choose to respond with only a subset of 1528 multipaths contained in the echo request Downstream Map. (Note: The 1529 originator of the echo request MAY send another echo request with the 1530 multipath information that was not included in the reply.) 1532 4.6. Receiving an MPLS Echo Reply 1534 An LSR X should only receive an MPLS echo reply in response to an 1535 MPLS echo request that it sent. Thus, on receipt of an MPLS echo 1536 reply, X should parse the packet to assure that it is well-formed, 1537 then attempt to match up the echo reply with an echo request that it 1538 had previously sent, using the destination UDP port and the Sender's 1539 Handle. If no match is found, then X jettisons the echo reply; oth- 1540 erwise, it checks the Sequence Number to see if it matches. Gaps in 1541 the Sequence Number MAY be logged and SHOULD be counted. Once an 1542 echo reply is received for a given Sequence Number (for a given UDP 1543 port and Handle), the Sequence Number for subsequent echo requests 1544 for that UDP port and Handle SHOULD be incremented. 1546 If the echo reply contains Downstream Mappings, and X wishes to 1547 traceroute further, it SHOULD copy the Downstream Mapping(s) into its 1548 next echo request(s) (with TTL incremented by one). 1550 4.7. Issue with VPN IPv4 and IPv6 Prefixes 1552 Typically, a LSP ping for a VPN IPv4 prefix or VPN IPv6 prefix is 1553 sent with a label stack of depth greater than 1, with the innermost 1554 label having a TTL of 1. This is to terminate the ping at the egress 1555 PE, before it gets sent to the customer device. However, under cer- 1556 tain circumstances, the label stack can shrink to a single label 1557 before the ping hits the egress PE; this will result in the ping ter- 1558 minating prematurely. One such scenario is a multi-AS Carrier's Car- 1559 rier VPN. 1561 To get around this problem, one approach is for the LSR that receives 1562 such a ping to realize that the ping terminated prematurely, and send 1563 back error code 13. In that case, the initiating LSR can retry the 1564 ping after incrementing the TTL on the VPN label. In this fashion, 1565 the ingress LSR will sequentially try TTL values until it finds one 1566 that allows the VPN ping to reach the egress PE. 1568 4.8. Non-compliant Routers 1570 If the egress for the FEC Stack being pinged does not support MPLS 1571 ping, then no reply will be sent, resulting in possible "false nega- 1572 tives". If in "traceroute" mode, a transit LSR does not support LSP 1573 ping, then no reply will be forthcoming from that LSR for some TTL, 1574 say n. The LSR originating the echo request SHOULD try sending the 1575 echo request with TTL=n+1, n+2, ..., n+k to probe LSRs further down 1576 the path. In such a case, the echo request for TTL > n SHOULD be 1577 sent with Downstream Mapping TLV "Downstream IP Address" field set to 1578 the ALLROUTERs multicast address until a reply is received with a 1579 Downstream Mapping TLV. The Label Stack MAY be omitted from the 1580 Downstream Mapping TLV. Further the "Validate FEC Stack" flag SHOULD 1581 NOT be set until an echo reply packet with a Downstream Mapping TLV 1582 is received. 1584 5. References 1586 Normative References 1588 [BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 1589 (BGP-4)", RFC 1771, March 1995. 1591 [IANA] Narten, T. and H. Alvestrand, "Guidelines for IANA 1592 Considerations", BCP 26, RFC 2434, October 1998. 1594 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1595 Requirement Levels", BCP 14, RFC 2119, March 1997. 1597 [LABEL-STACK] Rosen, E., et al, "MPLS Label Stack Encoding", 1598 RFC 3032, January 2001. 1600 Informative References 1602 [BGP-LABEL] Rekhter, Y. and E. Rosen, "Carrying Label Information 1603 in BGP-4", RFC 3107, May 2001. 1605 [ICMP] Postel, J., "Internet Control Message Protocol", 1606 RFC 792. 1608 [LDP] Andersson, L., et al, "LDP Specification", RFC 3036, 1609 January 2001. 1611 [MPLS-L3-VPN] Rekhter, Y. & Rosen, E., "BGP/MPLS IP VPNs", 1612 draft-ietf-l3vpn-rfc2547bis-03.txt, work-in-progress. 1614 [PW-CONTROL] Martini, L. et al., "Pseudowire Setup and Maintenance 1615 using the Label Distribution Protocol", 1616 draft-ietf-pwe3-control-protocol-17.txt, 1617 work-in-progress. 1619 [RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for 1620 LSP Tunnels", RFC 3209, December 2001. 1622 [VPLS] Kompella, K. and Rekhter, Y., "Virtual Private LAN 1623 Service", draft-ietf-l2vpn-vpls-bgp-05, 1624 work-in-progress. 1626 6. Security Considerations 1628 Overall, the security needs for LSP Ping are are similar to those of 1629 ICMP Ping. 1631 There are at least two approaches to attacking LSRs using the mecha- 1632 nisms defined here. One is a Denial of Service attack, by sending 1633 MPLS echo requests/replies to LSRs and thereby increasing their work- 1634 load. The other is obfuscating the state of the MPLS data plane 1635 liveness by spoofing, hijacking, replaying or otherwise tampering 1636 with MPLS echo requests and replies. 1638 To avoid potential Denial of Service attacks, it is RECOMMENDED that 1639 implementations regulate the LSP ping traffic going to the control 1640 plane. A rate limiter SHOULD be applied to the well-known UDP port 1641 defined below. 1643 Replay and spoofing attacks are unlikely to be effective given that 1644 the Sender's Handle and Sequence Number need to be valid. Thus a 1645 replay would be discarded as the sequence has moved on. A spoof has 1646 only a small window of opportunity, however an implementation MAY 1647 provide a validation on the TimeStamp Sent to limit the window to the 1648 resolution of the system clock. 1650 It is not clear how to prevent hijacking (non-delivery) of echo 1651 requests or replies; however, if these messages are indeed hijacked, 1652 LSP ping will report that the data plane isn't working as it should. 1654 It doesn't seem vital (at this point) to secure the data carried in 1655 MPLS echo requests and replies, although knowledge of the state of 1656 the MPLS data plane may be considered confidential by some. Imple- 1657 mentations SHOULD however provide a means of filtering the addresses 1658 to which Echo Reply messages may be sent. 1660 7. IANA Considerations 1662 The TCP and UDP port number 3503 has been allocated by IANA for LSP 1663 echo requests and replies. 1665 The following sections detail the new name spaces to be managed by 1666 IANA. For each of these name spaces, the space is divided into 1667 assignment ranges; the following terms are used in describing the 1668 procedures by which IANA allocates values: "Standards Action" (as 1669 defined in [IANA]); "Expert Review" and "Vendor Private Use". 1671 Values from "Expert Review" ranges MUST be registered with IANA. The 1672 request MUST be made via an Experimental RFC that describes the 1673 format and procedures for using the code point; the actual assignment 1674 is made during the IANA actions for the RFC. 1676 Values from "Vendor Private" ranges MUST NOT be registered with IANA; 1677 however, the message MUST contain an enterprise code as registered 1678 with the IANA SMI Network Management Private Enterprise Codes. For 1679 each name space that has a Vendor Private range, it must be specified 1680 where exactly the SMI Enterprise Code resides; see below for exam- 1681 ples. In this way, several enterprises (vendors) can use the same 1682 code point without fear of collision. 1684 7.1. Message Types, Reply Modes, Return Codes 1686 It is requested that IANA maintain registries for Message Types, 1687 Reply Modes, and Return Codes. Each of these can take values in the 1688 range 0-255. Assignments in the range 0-191 are via Standards 1689 Action; assignments in the range 192-251 are made via Expert Review; 1690 values in the range 252-255 are for Vendor Private Use, and MUST NOT 1691 be allocated. 1693 If any of these fields fall in the Vendor Private range, a top-level 1694 Vendor Enterprise Code TLV MUST be present in the message. 1696 Message Types defined in this document are: 1698 Value Meaning 1699 ----- ------- 1700 1 MPLS Echo Request 1701 2 MPLS Echo Reply 1703 Reply Modes defined in this document are: 1705 Value Meaning 1706 ----- ------- 1707 1 Do not reply 1708 2 Reply via an IPv4/IPv6 UDP packet 1709 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 1710 4 Reply via application level control channel 1712 Return Codes defined in this document are listed in section 3.1. 1714 7.2. TLVs 1716 It is requested that IANA maintain a registry for the Type field of 1717 top-level TLVs as well as for any associated sub-TLVs. Note the 1718 meaning of a sub-TLV is scoped by the TLV. The number spaces for the 1719 sub-TLVs of various TLVs are independent. 1721 The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the 1722 range 0-16383 and 32768-49161 are made via Standards Action as 1723 defined in [IANA]; assignments in the range 16384-31743 and 1724 49162-64511 are made via Expert Review as defined above; values in 1725 the range 31744-32767 and 64512-65535 are for Vendor Private Use, and 1726 MUST NOT be allocated. 1728 If a TLV or sub-TLV has a Type that falls in the range for Vendor 1729 Private Use, the Length MUST be at least 4, and the first four octets 1730 MUST be that vendor's SMI Enterprise Code, in network octet order. 1731 The rest of the Value field is private to the vendor. 1733 TLVs and sub-TLVs defined in this document are: 1735 Type Sub-Type Value Field 1736 ---- -------- ----------- 1737 1 Target FEC Stack 1738 1 LDP IPv4 prefix 1739 2 LDP IPv6 prefix 1740 3 RSVP IPv4 LSP 1741 4 RSVP IPv6 LSP 1742 5 Not Assigned 1743 6 VPN IPv4 prefix 1744 7 VPN IPv6 prefix 1745 8 L2 VPN endpoint 1746 9 "FEC 128" Pseudowire (Deprecated) 1747 10 "FEC 128" Pseudowire 1748 11 "FEC 129" Pseudowire 1749 12 BGP labeled IPv4 prefix 1750 13 BGP labeled IPv6 prefix 1751 14 Generic IPv4 prefix 1752 15 Generic IPv6 prefix 1753 16 Nil FEC 1754 2 Downstream Mapping 1755 3 Pad 1756 4 Not Assigned 1757 5 Vendor Enterprise Code 1758 6 Not Assigned 1759 7 Interface and Label Stack 1760 8 Not Assigned 1761 9 Errored TLVs 1762 Any value The TLV not understood 1763 10 Reply TOS Byte 1765 8. Acknowledgments 1767 This document is the outcome of many discussions among many people, 1768 that include Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa 1769 Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani Aggarwal and Vanson 1770 Lim. 1772 The description of the Multipath Information sub-field of the Down- 1773 stream Mapping TLV was adapted from text suggested by Curtis Vil- 1774 lamizar. 1776 Authors' Addresses 1778 Kireeti Kompella 1779 Juniper Networks 1780 1194 N.Mathilda Ave 1781 Sunnyvale, CA 94089 1782 Email: kireeti@juniper.net 1784 George Swallow 1785 Cisco Systems 1786 1414 Massachusetts Ave, 1787 Boxborough, MA 01719 1788 Phone: +1 978 936 1398 1789 Email: swallow@cisco.com 1791 Copyright Notice 1793 Copyright (C) The Internet Society (2005). This document is subject 1794 to the rights, licenses and restrictions contained in BCP 78, and 1795 except as set forth therein, the authors retain all their rights. 1797 Expiration Date 1799 May 2006 1801 Disclaimer of Validity 1803 This document and the information contained herein are provided on an 1804 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1805 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1806 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1807 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1808 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1809 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1811 The IETF takes no position regarding the validity or scope of any 1812 Intellectual Property Rights or other rights that might be claimed to 1813 pertain to the implementation or use of the technology described in 1814 this document or the extent to which any license under such rights 1815 might or might not be available; nor does it represent that it has 1816 made any independent effort to identify any such rights. Information 1817 on the procedures with respect to rights in RFC documents can be 1818 found in BCP 78 and BCP 79. 1820 Copies of IPR disclosures made to the IETF Secretariat and any 1821 assurances of licenses to be made available, or the result of an 1822 attempt made to obtain a general license or permission for the use of 1823 such proprietary rights by implementers or users of this 1824 specification can be obtained from the IETF on-line IPR repository at 1825 http://www.ietf.org/ipr. 1827 The IETF invites any interested party to bring to its attention any 1828 copyrights, patents or patent applications, or other proprietary 1829 rights that may cover technology that may be required to implement 1830 this standard. Please address the information to the IETF at 1831 ietf-ipr@ietf.org.