idnits 2.17.1 draft-ietf-mpls-lsp-ping-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. 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 == Line 1184 has weird spacing: '...for the purpo...' -- 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 (October 2003) is 7499 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) == Missing Reference: 'IANA' is mentioned on line 1020, but not defined == Unused Reference: 'RSVP' is defined on line 970, but no explicit reference was found in the text == Unused Reference: 'RSVP-REFRESH' is defined on line 974, but no explicit reference was found in the text == Unused Reference: 'RSVP-TE' is defined on line 977, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Kompella (Juniper) 2 Internet Draft P. Pan (Ciena) 3 draft-ietf-mpls-lsp-ping-04.txt N. Sheth (Juniper) 4 Category: Standards Track D. Cooper (Global Crossing) 5 Expires: April 2003 G. Swallow (Cisco) 6 S. Wadhwa (Juniper) 7 R. Bonica (WorldCom) 8 October 2003 10 Detecting MPLS Data Plane Failures 12 *** DRAFT *** 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This document describes a simple and efficient mechanism that can be 42 used to detect data plane failures in Multi-Protocol Label Switching 43 (MPLS) Label Switched Paths (LSPs). There are two parts to this 44 document: information carried in an MPLS "echo request" and "echo 45 reply" for the purposes of fault detection and isolation; and 46 mechanisms for reliably sending the echo reply. 48 Changes since last revision 50 (This section to be removed before publication.) 52 Clarified that an MPLS echo request/reply can be either an IPv4 or an 53 IPv6 packet. 55 Expanded on Return Codes (section 3.1). 57 Expanded and reformatted the section on Downstream Mapping. 59 Expanded the section on Receiving an MPLS Echo Request 61 Issues 63 (This section to be removed before publication.) 65 Need to fill out Downstream Verification. 67 Need to address issues with pinging L3VPN FECs. 69 1. Introduction 71 This document describes a simple and efficient mechanism that can be 72 used to detect data plane failures in MPLS LSPs. There are two parts 73 to this document: information carried in an MPLS "echo request" and 74 "echo reply"; and mechanisms for transporting the echo reply. The 75 first part aims at providing enough information to check correct 76 operation of the data plane, as well as a mechanism to verify the 77 data plane against the control plane, and thereby localize faults. 78 The second part suggests two methods of reliable reply channels for 79 the echo request message, for more robust fault isolation. 81 An important consideration in this design is that MPLS echo requests 82 follow the same data path that normal MPLS packets would traverse. 83 MPLS echo requests are meant primarily to validate the data plane, 84 and secondarily to verify the data plane against the control plane. 85 Mechanisms to check the control plane are valuable, but are not 86 covered in this document. 88 To avoid potential Denial of Service attacks, it is recommended to 89 regulate the MPLS ping traffic going to the control plane. A rate 90 limiter should be applied to the well-known UDP port defined below. 92 1.1. Conventions 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 98 1.2. Structure of this document 100 The body of this memo contains four main parts: motivation, MPLS echo 101 request/reply packet format, MPLS ping operation, and a reliable 102 return path. It is suggested that first-time readers skip the actual 103 packet formats and read the Theory of Operation first; the document 104 is structured the way it is to avoid forward references. 106 The last section (reliable return path for RSVP LSPs) may be removed 107 in a future revision. 109 2. Motivation 111 When an LSP fails to deliver user traffic, the failure cannot always 112 be detected by the MPLS control plane. There is a need to provide a 113 tool that would enable users to detect such traffic "black holes" or 114 misrouting within a reasonable period of time; and a mechanism to 115 isolate faults. 117 In this document, we describe a mechanism that accomplishes these 118 goals. This mechanism is modeled after the ping/traceroute paradigm: 119 ping (ICMP echo request [ICMP]) is used for connectivity checks, and 120 traceroute is used for hop-by-hop fault localization as well as path 121 tracing. This document specifies a "ping mode" and a "traceroute" 122 mode for testing MPLS LSPs. 124 The basic idea is to test that packets that belong to a particular 125 Forwarding Equivalence Class (FEC) actually end their MPLS path on an 126 LSR that is an egress for that FEC. This document proposes that this 127 test be carried out by sending a packet (called an "MPLS echo 128 request") along the same data path as other packets belonging to this 129 FEC. An MPLS echo request also carries information about the FEC 130 whose MPLS path is being verified. This echo request is forwarded 131 just like any other packet belonging to that FEC. In "ping" mode 132 (basic connectivity check), the packet should reach the end of the 133 path, at which point it is sent to the control plane of the egress 134 LSR, which then verifies that it is indeed an egress for the FEC. In 135 "traceroute" mode (fault isolation), the packet is sent to the 136 control plane of each transit LSR, which performs various checks that 137 it is indeed a transit LSR for this path; this LSR also returns 138 further information that helps check the control plane against the 139 data plane, i.e., that forwarding matches what the routing protocols 140 determined as the path. 142 One way these tools can be used is to periodically ping a FEC to 143 ensure connectivity. If the ping fails, one can then initiate a 144 traceroute to determine where the fault lies. One can also 145 periodically traceroute FECs to verify that forwarding matches the 146 control plane; however, this places a greater burden on transit LSRs 147 and thus should be used with caution. 149 3. Packet Format 151 An MPLS echo request is a (possibly labelled) IPv4 or IPv6 UDP 152 packet; the contents of the UDP packet have the following format: 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Version Number | Must Be Zero | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Message Type | Reply mode | Return Code | Return Subcode| 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Sender's Handle | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Sequence Number | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | TimeStamp Sent (seconds) | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | TimeStamp Sent (microseconds) | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | TimeStamp Received (seconds) | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | TimeStamp Received (microseconds) | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | TLVs ... | 174 . . 175 . . 176 . . 177 | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 The Version Number is currently 1. (Note: the Version Number is to 181 be incremented whenever a change is made that affects the ability of 182 an implementation to correctly parse or process an MPLS echo 183 request/reply. These changes include any syntactic or semantic 184 changes made to any of the fixed fields, or to any TLV or sub-TLV 185 assignment or format that is defined at a certain version number. 186 The Version Number may not need to be changed if an optional TLV or 187 sub-TLV is added.) 189 The Message Type is one of the following: 191 Value Meaning 192 ----- ------- 193 1 MPLS Echo Request 194 2 MPLS Echo Reply 196 The Reply Mode can take one of the following values: 198 Value Meaning 199 ----- ------- 200 1 Do not reply 201 2 Reply via an IPv4 UDP packet 202 3 Reply via an IPv4 UDP packet with Router Alert 203 4 Reply via application level control channel 205 An MPLS echo request with "Do not reply" may be used for one-way 206 connectivity tests; the receiving router may log gaps in the sequence 207 numbers and/or maintain delay/jitter statistics. An MPLS echo 208 request would normally have "Reply via an IPv4 UDP packet"; if the 209 normal IPv4 return path is deemed unreliable, one may use "Reply via 210 an IPv4 UDP packet with Router Alert" (note that this requires that 211 all intermediate routers understand and know how to forward MPLS echo 212 replies). 214 Any application which supports an IP control channel between its 215 control entities may set the Reply Mode to 4 to ensure that replies 216 use that same channel. Further definition of this codepoint is 217 application specific and thus beyond the scope of this docuemnt. 219 Return Codes and Subcodes are described in the next section. 221 The Sender's Handle is filled in by the sender, and returned 222 unchanged by the receiver in the echo reply (if any). There are no 223 semantics associated with this handle, although a sender may find 224 this useful for matching up requests with replies. 226 The Sequence Number is assigned by the sender of the MPLS echo 227 request, and can be (for example) used to detect missed replies. 229 The TimeStamp Sent is the time-of-day (in seconds and microseconds, 230 wrt the sender's clock) when the MPLS echo request is sent. The 231 TimeStamp Received in an echo reply is the time-of-day (wrt the 232 receiver's clock) that the corresponding echo request was received. 234 TLVs (Type-Length-Value tuples) have the following format: 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Type | Length | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Value | 242 . . 243 . . 244 . . 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Types are defined below; Length is the length of the Value field in 249 octets. The Value field depends on the Type; it is zero padded to 250 align to a four-octet boundary. 252 Type # Value Field 253 ------ ----------- 254 1 Target FEC Stack 255 2 Downstream Mapping 256 3 Pad 257 4 Error Code 258 5 Vendor Enterprise Code 260 3.1. Return Codes 262 The Return Code is set to zero by the sender. The receiver can set 263 it to one of the values listed below. The notation refers to 264 the Return Subcode. This field is filled in with the stack-depth for 265 those codes which specify that. For all other codes the Return 266 Subcode MUST be set to zero. 268 Value Meaning 269 ----- ------- 271 0 No return code or return code contained in the Error 272 Code TLV 274 1 Malformed echo request received 276 2 One or more of the TLVs was not understood 278 3 Replying router is an egress for the FEC at stack 279 depth 281 4 Replying router has no mapping for the FEC at stack 282 depth 284 5 Reserved 286 6 Reserved 288 7 Reserved 290 8 Label switched at stack-depth 292 9 Label switched but no MPLS forwarding at stack-depth 293 295 10 Mapping for this FEC is not the given label at stack 296 depth 298 11 No label entry at stack-depth 300 12 Protocol not associated with interface at FEC stack 301 depth 303 3.2. Target FEC Stack 305 A Target FEC Stack is a list of sub-TLVs. The number of elements is 306 determined by the looking at the sub-TLV length fields. 308 Sub-Type # Length Value Field 309 ---------- ------ ----------- 310 1 5 LDP IPv4 prefix 311 2 17 LDP IPv6 prefix 312 3 20 RSVP IPv4 Session Query 313 4 56 RSVP IPv6 Session Query 314 5 Reserved; see Appendix 315 6 13 VPN IPv4 prefix 316 7 25 VPN IPv6 prefix 317 8 14 L2 VPN endpoint 318 9 10 L2 circuit ID 320 Other FEC Types will be defined as needed. 322 Note that this TLV defines a stack of FECs, the first FEC element 323 corresponding to the top of the label stack, etc. 325 An MPLS echo request MUST have a Target FEC Stack that describes the 326 FEC stack being tested. For example, if an LSR X has an LDP mapping 327 for 192.168.1.1 (say label 1001), then to verify that label 1001 does 328 indeed reach an egress LSR that announced this prefix via LDP, X can 329 send an MPLS echo request with a FEC Stack TLV with one FEC in it, 330 namely of type LDP IPv4 prefix, with prefix 192.168.1.1/32, and send 331 the echo request with a label of 1001. 333 Say LSR X wanted to verify that a label stack of <1001, 23456> is the 334 right label stack to use to reach a VPN IPv4 prefix of 10/8 in VPN 335 foo. Say further that LSR Y with loopback address 192.168.1.1 336 announced prefix 10/8 with Route Distinguisher RD-foo-Y (which may in 337 general be different from the Route Distinguisher that LSR X uses in 338 its own advertisements for VPN foo), label 23456 and BGP nexthop 339 192.168.1.1. Finally, suppose that LSR X receives a label binding of 340 1001 for 192.168.1.1 via LDP. X has two choices in sending an MPLS 341 echo request: X can send an MPLS echo request with a FEC Stack TLV 342 with a single FEC of type VPN IPv4 prefix with a prefix of 10/8 and a 343 Route Distinguisher of RD-foo-Y. Alternatively, X can send a FEC 344 Stack TLV with two FECs, the first of type LDP IPv4 with a prefix of 345 192.168.1.1/32 and the second of type of IP VPN with a prefix 10/8 346 with Route Distinguisher of RD-foo-Y. In either case, the MPLS echo 347 request would have a label stack of <1001, 23456>. (Note: in this 348 example, 1001 is the "outer" label and 23456 is the "inner" label.) 350 3.2.1. LDP IPv4 Prefix 352 The value consists of four octets of an IPv4 prefix followed by one 353 octet of prefix length in bits. The IPv4 prefix is in network byte 354 order. See [LDP] for an example of a Mapping for an IPv4 FEC. 356 3.2.2. LDP IPv6 Prefix 358 The value consists of sixteen octets of an IPv6 prefix followed by 359 one octet of prefix length in bits. The IPv6 prefix is in network 360 byte order. See [LDP] for an example of a Mapping for an IPv6 FEC. 362 3.2.3. RSVP IPv4 Session 364 The value has the format below. The value fields are taken from 365 [RFC3209, sections 4.6.1.1 and 4.6.2.1]. 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | IPv4 tunnel end point address | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Must Be Zero | Tunnel ID | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Extended Tunnel ID | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | IPv4 tunnel sender address | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Must Be Zero | LSP ID | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 3.2.4. RSVP IPv6 Session 383 The value has the format below. The value fields are taken from 384 [RFC3209, sections 4.6.1.2 and 4.6.2.2]. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | IPv6 tunnel end point address | 390 | | 391 | | 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Must Be Zero | Tunnel ID | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Extended Tunnel ID | 397 | | 398 | | 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | IPv6 tunnel sender address | 402 | | 403 | | 404 | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Must Be Zero | LSP ID | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 3.2.5. VPN IPv4 Prefix 411 The value field consists of the Route Distinguisher advertised with 412 the VPN IPv4 prefix, the IPv4 prefix and a prefix length, as follows: 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Route Distinguisher | 418 | (8 octets) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | IPv4 prefix | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Prefix Length | Must Be Zero | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 3.2.6. VPN IPv6 Prefix 427 The value field consists of the Route Distinguisher advertised with 428 the VPN IPv6 prefix, the IPv6 prefix and a prefix length, as follows: 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Route Distinguisher | 434 | (8 octets) | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | IPv6 prefix | 437 | | 438 | | 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Prefix Length | Must Be Zero | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 3.2.7. L2 VPN Endpoint 446 The value field consists of a Route Distinguisher (8 octets), the 447 sender (of the ping)'s CE ID (2 octets), the receiver's CE ID (2 448 octets), and an encapsulation type (2 octets), formatted as follows: 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Route Distinguisher | 454 | (8 octets) | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Sender's CE ID | Receiver's CE ID | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Encapsulation Type | Must Be Zero | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 3.2.8. L2 Circuit ID 463 The value field consists of a remote PE address (the address of the 464 targetted LDP session), a VC ID and an encapsulation type, as 465 follows: 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Remote PE Address | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | VC ID | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Encapsulation Type | Must Be Zero | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 3.3. Downstream Mapping 479 The Downstream Mapping object is an optional TLV. Only one 480 Downstream Mapping request may appear in and echo request. The 481 presence of a Downstream Mapping object is a request that Downstream 482 Mapping objects be included in the echo reply. If the replying 483 router is the destination of the FEC, then a Downstream Mapping TLV 484 SHOULD NOT be included in the echo reply. Otherwise Downstream 485 Mapping objects SHOULD include a Downstream Mapping object for each 486 interface over which this FEC could be forwarded. 488 The Length is 16 + M + 4*N octets, where M is the Multipath Length, 489 and N is the number of Downstream Labels. The Value field of a 490 Downstream Mapping has the following format: 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | MTU | Address Type | Resvd (SBZ) | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Downstream IP Address (4 or 16 octets) | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Downstream Interface Address (4 or 16 octets) | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Hash Key Type | Depth Limit | Multipath Length | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 . . 504 . (Multipath Information) . 505 . . 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Downstream Label | Protocol | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 . . 510 . . 511 . . 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Downstream Label | Protocol | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Maximum Transmission Unit (MTU) 518 The MTU is the largest MPLS frame (including label stack) that 519 fits on the interface to the Downstream LSR. 521 Address Type 523 The Address Type indicates if the interface is numbered or 524 unnumbered and is set to one of the following values: 526 Type # Address Type 527 ------ ------------ 528 1 IPv4 529 2 Unnumbered 530 3 IPv6 532 The field marked SBZ SHOULD be set to zero when sending and 533 SHOULD be ignored on receipt. 535 Downstream IP Address and Downstream Interface Address 537 If the interface to the downstream LSR is numbered, then the 538 Address Type MUST be set to IPv4 or IPv6, the Downstream IP 539 Address MUST be set to either the downstream LSR's Router ID or 540 the interface address of the downstream LSR, and the Downstream 541 Interface Address MUST be set to the downstream LSR's interface 542 address. 544 If the interface to the downstream LSR is unnumbered, the Address 545 Type MUST be Unnumbered, the Downstream IP Address MUST be the 546 downstream LSR's Router ID (4 octets), and the Downstream 547 Interface Address MUST be set to the index assigned by the 548 upstream LSR to the interface. 550 Multipath Length 552 The length in octets of the Multipath Information. 554 Downstream Label(s) 556 The set of labels in the label stack as it would have appeared if 557 this router were forwarding the packet through this interface. 558 Any Implicit Null labels are explicitly inluded. Labels are 559 treated as numbers, i.e. they are right justified in the field. 561 Protocol 563 The Protocol is taken from the following table: 565 Protocol # Signaling Protocol 566 ---------- ------------------ 567 0 Unknown 568 1 Static 569 2 BGP 570 3 LDP 571 4 RSVP-TE 572 5 Reserved; see Appendix 574 The notion of "downstream router" and "downstream interface" 575 should be explained. Consider an LSR X. If a packet that was 576 originated with TTL n>1 arrived with outermost label L at LSR X, 577 X must be able to compute which LSRs could receive the packet if 578 it was originated with TTL=n+1, over which interface the request 579 would arrive and what label stack those LSRs would see. (It is 580 outside the scope of this document to specify how this 581 computation is done.) The set of these LSRs/interfaces are the 582 downstream routers/interfaces (and their corresponding labels) 583 for X with respect to L. Each pair of downstream router and 584 interface requires a separate Downstream Mapping to be added to 585 the reply. (Note that there are multiple Downstream Label fields 586 in each TLV as the incoming label L may be swapped with a label 587 stack.) 589 The case where X is the LSR originating the echo request is a 590 special case. X needs to figure out what LSRs would receive the 591 MPLS echo request for a given FEC Stack that X originates with 592 TTL=1. 594 The set of downstream routers at X may be alternative paths (see 595 the discussion below on ECMP) or simultaneous paths (e.g., for 596 MPLS multicast). In the former case, the Multipath sub-field is 597 used as a hint to the sender as to how it may influence the 598 choice of these alternatives. The "No of Multipaths" is the 599 number of IP Address/Next Label fields. The Hash Key Type is 600 taken from the following table: 602 Key Type Multipath Information 603 --- ---------------- --------------------- 604 0 no multipath (empty; M = 0) 605 1 label labels 606 2 IP address IP addresses 607 3 label range low/high label pairs 608 4 IP address range low/high address pairs 609 5 no more labels (empty; M = 0) 610 6 All IP addresses (empty; M = 0) 611 7 no match (empty; M = 0) 612 8 Bit-masked IPv4 IP address prefix and bit mask 613 address set 614 9 Bit-masked label set Label prefix and bit mask 616 Type 0 indicates that all packets will be forwarded out this one 617 interface. 619 Types 1, 2, 3, 4, 8 and 9 specify that the supplied Multipath 620 Information will serve to execise this path. 622 Types 5 and 6 are TBD. 624 Type 7 indicates that no matches are possible given the Multipath 625 Information in the received DS mapping information. 627 Depth Limit 629 The Depth Limit is applicable only to a label stack, and is the 630 maximum number of labels considered in the hash; this SHOULD be 631 set to zero if unspecified or unlimited. 633 Multipath Information 635 The multipath information encodes labels or addresses which will 636 exercise this path. The multipath informaiton depends on the 637 hash key type. The contents of the field are shown in the table 638 above. IP addresses are drawn from the range 127/8. Labels are 639 treated as numbers, i.e. they are right justified in the field. 640 Label and Address pairs MUST NOT overlap and MUST be in ascending 641 sequence. 643 Hash key 8 allows a denser encoding of IP address. The IPv4 644 prefix is formatted as a base IPv4 address with the non-prefix 645 low order bits set to zero. The maximum prefix length is 27. 646 Following the prefix is a mask of length 2^(32-prefix length) 647 bits. Each bit set to one represents a valid address. The 648 address is the base IPv4 address plus the position of the bit in 649 the mask where the bits are numbered left to right begining with 650 zero. 652 Hash key 9 allows a denser encoding of Labels. The label prefix 653 is formatted as a base label value with the non-prefix low order 654 bits set to zero. The maximum prefix (including leading zeros 655 due to encoding) length is 27. Following the prefix is a mask of 656 length 2^(32-prefix length) bits. Each bit set to one represents 657 a valid Label. The label is the base label plus the position of 658 the bit in the mask where the bits are numbered left to right 659 begining with zero. 661 If the received DS mapping information is non-null the labels and 662 IP addresses MUST be picked from the set provided or the Hash Key 663 Type MUST be set to 7. 665 For example, suppose LSR X at hop 10 has two downstream LSRs Y 666 and Z for the FEC in question. X could return Hash Key Type 4, 667 with low/high IP addresses of 1.1.1.1->1.1.1.255 for downstream 668 LSR Y and 2.1.1.1->2.1.1.255 for downstream LSR Z. The head end 669 reflects this information to LSR Y. Y, which has three 670 downstream LSRs U, V and W, computes that 1.1.1.1->1.1.1.127 671 would go to U and 1.1.1.128-> 1.1.1.255 would go to V. Y would 672 then respond with 3 Downstream Mappings: to U, with Hash Key Type 673 4 (1.1.1.1->1.1.1.127); to V, with Hash Key Type 4 674 (1.1.1.127->1.1.1.255); and to W, with Hash Key Type 7. 676 3.4. Pad TLV 678 The value part of the Pad TLV contains a variable number (>= 1) of 679 octets. The first octet takes values from the following table; all 680 the other octets (if any) are ignored. The receiver SHOULD verify 681 that the TLV is received in its entirety, but otherwise ignores the 682 contents of this TLV, apart from the first octet. 684 Value Meaning 685 ----- ------- 686 1 Drop Pad TLV from reply 687 2 Copy Pad TLV to reply 688 3-255 Reserved for future use 690 3.5. Error Code 692 The Error Code TLV is currently not defined; its purpose is to 693 provide a mechanism for a more elaborate error reporting structure, 694 should the reason arise. 696 3.6. Vendor Enterprise Code 698 The Length is always 4; the value is the SMI Enterprise code, in 699 network octet order, of the vendor with a Vendor Private extension to 700 any of the fields in the fixed part of the message, in which case 701 this TLV MUST be present. If none of the fields in the fixed part of 702 the message have vendor private extensions, this TLV is OPTIONAL. 704 4. Theory of Operation 706 An MPLS echo request is used to test a particular LSP. The LSP to be 707 tested is identified by the "FEC Stack"; for example, if the LSP was 708 set up via LDP, and is to an egress IP address of 10.1.1.1, the FEC 709 stack contains a single element, namely, an LDP IPv4 prefix sub-TLV 710 with value 10.1.1.1/32. If the LSP being tested is an RSVP LSP, the 711 FEC stack consists of a single element that captures the RSVP Session 712 and Sender Template which uniquely identifies the LSP. 714 FEC stacks can be more complex. For example, one may wish to test a 715 VPN IPv4 prefix of 10.1/8 that is tunneled over an LDP LSP with 716 egress 10.10.1.1. The FEC stack would then contain two sub-TLVs, the 717 first being a VPN IPv4 prefix, and the second being an LDP IPv4 718 prefix. If the underlying (LDP) tunnel were not known, or was 719 considered irrelevant, the FEC stack could be a single element with 720 just the VPN IPv4 sub-TLV. 722 When an MPLS echo request is received, the receiver is expected to do 723 a number of tests that verify that the control plane and data plane 724 are both healthy (for the FEC stack being pinged), and that the two 725 planes are in sync. 727 4.1. Dealing with Equal-Cost Multi-Path (ECMP) 729 LSPs need not be simple point-to-point tunnels. Frequently, a single 730 LSP may originate at several ingresses, and terminate at several 731 egresses; this is very common with LDP LSPs. LSPs for a given FEC 732 may also have multiple "next hops" at transit LSRs. At an ingress, 733 there may also be several different LSPs to choose from to get to the 734 desired endpoint. Finally, LSPs may have backup paths, detour paths 735 and other alternative paths to take should the primary LSP go down. 737 To deal with the last two first: it is assumed that the LSR sourcing 738 MPLS echo requests can force the echo request into any desired LSP, 739 so choosing among multiple LSPs at the ingress is not an issue. The 740 problem of probing the various flavors of backup paths that will 741 typically not be used for forwarding data unless the primary LSP is 742 down will not be addressed here. 744 Since the actual LSP and path that a given packet may take may not be 745 known a priori, it is useful if MPLS echo requests can exercise all 746 possible paths. This, while desirable, may not be practical, because 747 the algorithms that a given LSR uses to distribute packets over 748 alternative paths may be proprietary. 750 To achieve some degree of coverage of alternate paths, there is a 751 certain lattitude in choosing the destination IP address and source 752 UDP port for an MPLS echo request. This is clearly not sufficient; 753 in the case of traceroute, more lattitude is offered by means of the 754 "Multipath Exercise" sub-TLV of the Downstream Mapping TLV. This is 755 used as follows. An ingress LSR periodically sends an MPLS 756 traceroute message to determine whether there are multipaths for a 757 given LSP. If so, each hop will provide some information how each of 758 its downstreams can be exercised. The ingress can then send MPLS 759 echo requests that exercise these paths. If several transit LSRs 760 have ECMP, the ingress may attempt to compose these to exercise all 761 possible paths. However, full coverage may not be possible. 763 4.2. Sending an MPLS Echo Request 765 An MPLS echo request is a (possibly) labelled UDP packet. The IP 766 header is set as follows: the source IP address is a routable address 767 of the sender; the destination IP address is a (randomly chosen) 768 address from 127/8; the IP TTL is set to 1. The source UDP port is 769 chosen by the sender; the destination UDP port is set to 3503 770 (assigned by IANA for MPLS echo requests). The Router Alert option 771 is set in the IP header. 773 If the echo request is labelled, one may (depending on what is being 774 pinged) set the TTL of the innermost label to 1, to prevent the ping 775 request going farther than it should. Examples of this include 776 pinging a VPN IPv4 or IPv6 prefix, an L2 VPN end point or an L2 777 circuit ID. This can also be accomplished by inserting a router 778 alert label above this label; however, this may lead to the undesired 779 side effect that MPLS echo requests take a different data path than 780 actual data. 782 In "ping" mode (end-to-end connectivity check), the TTL in the 783 outermost label is set to 255. In "traceroute" mode (fault isolation 784 mode), the TTL is set successively to 1, 2, .... 786 The sender chooses a Sender's Handle, and a Sequence Number. When 787 sending subsequent MPLS echo requests, the sender SHOULD increment 788 the sequence number by 1. However, a sender MAY choose to send a 789 group of echo requests with the same sequence number to improve the 790 chance of arrival of at least one packet with that sequence number. 792 The TimeStamp Sent is set to the time-of-day (in seconds and 793 microseconds) that the echo request is sent. The TimeStamp Received 794 is set to zero. 796 An MPLS echo request MUST have a FEC Stack TLV. Also, the Reply Mode 797 must be set to the desired reply mode; the Return Code and Subcode 798 are set to zero. 800 In the "traceroute" mode, the echo request SHOULD contain one or more 801 Downstream Mapping TLVs. For TTL=1, all the downstream routers (and 802 corresponding labels) for the sender with respect to the FEC Stack 803 being pinged SHOULD be sent in the echo request. For n>1, the 804 Downstream Mapping TLVs from the echo reply for TTL=(n-1) are copied 805 to the echo request with TTL=n; the sender MAY choose to reduce the 806 size of a "Downstream Multipath Mapping TLV" when copying into the 807 next echo request as long as the Hash Key Type matching the label or 808 IP address used to exercise the current MP is still present. 810 4.3. Receiving an MPLS Echo Request 812 An LSR X that receives an MPLS echo request first parses the packet 813 to ensure that it is a well-formed packet, and that the TLVs that are 814 not marked "Ignore" are understood. If not, X SHOULD send an MPLS 815 echo reply with the Return Code set to "Malformed echo request 816 received" or "TLV not understood" (as appropriate), and the Subcode 817 set to zero. In the latter case, the misunderstood TLVs (only) are 818 included in the reply. 820 If the echo request is good, X notes the interface I over which the 821 echo was received, and the label stack with which it came. If the 822 MPLS echo request contained a Downstream Verification object (TBD), 823 then X must format this information as a Downstream Verification 824 object and include it in its MPLS echo reply message. 826 X matches up the labels in the received label stack with the FECs 827 contained in the FEC stack. The matching is done beginning at the 828 bottom of both stacks and working up. For reporting purposes the 829 bottom of stack is consided to be stack-depth of 1. This is to 830 establish an absolute reference for the case where the stack may have 831 more labels than are in the FEC stack and the sender of the ping has 832 not requested that a Downstream Verification TLV be sent. If there 833 are more FECs than labels, the extra FECs are assumed to correspond 834 to Implicit Null Labels. 836 Note: in all the error codes listed in this draft a stack-depth of 0 837 means "no value specified". This allows compatibility with existing 838 implementations which do not use the Return Subcode field. 840 X sets a variable, call it current-stack-depth, to the number of 841 labels in the received label stack. Processing now continues with 842 the following steps: 844 1. Check if there is a FEC corresponding to the current-stack- 845 depth. If there is, go to step 2. If not, check if the label is 846 valid on interface I. If it is, continue with step 4. Otherwise 847 X MUST send an MPLS echo reply with a Return Code 11, "No label 848 entry at stack-depth" and a Return Subcode set to current-stack- 849 depth. 851 2. Check the FEC at the current-stack-depth to determine what 852 protocol was used to advertise it. If X can determine that no 853 protocol associated with interface I would have advertised a FEC 854 of that FEC-Type, X MUST send an MPLS echo reply with a Return 855 Code 12, "Protocol not associated with interface at FEC stack- 856 depth" and a Return Subcode set to current-stack-depth. 858 3. Check that the mapping for the FEC at the current-stack-depth is 859 the corresponding label. 861 If no mapping for the FEC exists, X MUST send an MPLS echo reply 862 with a Return Code 4, "Replying router has no mapping for the FEC 863 at stack-depth" and a Return Subcode set to current- stack-depth. 865 If a mapping is found, but the mapping is not the corresponding 866 label, X MUST send an MPLS echo reply with a Return Code 10, 867 "Mapping for this FEC is not the given label at stack-depth" and 868 a Return Subcode set to current-stack-depth. 870 4. X determines the label operation. If the operation is to pop and 871 continue processing, X checks the current-stack-depth. If it is 872 one, X MUST send an MPLS echo reply with a Return Code 3, 873 "Replying router is an egress for the FEC at stack depth" and a 874 Return Subcode set to one. Otherwise, X decrements current- 875 stack-depth and goes back to step 1. 877 If the label operation is pop and switch based on the popped 878 label, X then checks if it is valid to forward a labelled packet. 879 If it is not valid to forward a labelled packet, or the current- 880 stack-depth is one, X MUST send an MPLS echo reply with a Return 881 Code 9, "Label switched but no MPLS forwarding at stack-depth" 882 and a Return Subcode set to current-stack-depth. Otherwise, X 883 MUST send an MPLS echo reply with a Return Code 8, "Label 884 switched at stack-depth" and a Return Subcode set to current- 885 stack-depth. 887 If the label operation is swap, X MUST send an MPLS echo reply 888 with a Return Code 8, "Label switched at stack-depth" and a 889 Return Subcode set to current-stack-depth. 891 If the MPLS echo request contains a downstream mapping TLV, and the 892 MPLS echo reply has either a Return Code of 8, or a Return Code of 9 893 with a Return Subcode of 1 then Downstream mapping TLVs SHOULD be 894 included for each multipath. 896 If the echo request has a Reply Mode that wants a reply, X uses the 897 procedure in the next subsection to send the echo reply. 899 4.4. Sending an MPLS Echo Reply 901 An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response 902 to an MPLS echo request. The source IP address is a routable address 903 of the replier; the source port is the well-known UDP port for MPLS 904 ping. The destination IP address and UDP port are copied from the 905 source IP address and UDP port of the echo request. The IP TTL is 906 set to 255. If the Reply Mode in the echo request is "Reply via an 907 IPv4 UDP packet with Router Alert", then the IP header MUST contain 908 the Router Alert IP option. If the reply is sent over an LSP, the 909 topmost label MUST in this case be the Router Alert label (1) (see 910 [LABEL-STACK]). 912 The format of the echo reply is the same as the echo request. The 913 Sender's Handle, the Sequence Number and TimeStamp Sent are copied 914 from the echo request; the TimeStamp Received is set to the time-of- 915 day that the echo request is received (note that this information is 916 most useful if the time-of-day clocks on the requestor and the 917 replier are synchronized). The FEC Stack TLV from the echo request 918 MAY be copied to the reply. 920 The replier MUST fill in the Return Code and Subcode, as determined 921 in the previous subsection. 923 If the echo request contains a Pad TLV, the replier MUST interpret 924 the first octet for instructions regarding how to reply. 926 If the echo request contains a Downstream Mapping TLV, the replier 927 SHOULD compute its downstream routers and corresponding labels for 928 the incoming label, and add Downstream Mapping TLVs for each one to 929 the echo reply it sends back. 931 4.5. Receiving an MPLS Echo Reply 933 An LSR X should only receive an MPLS Echo Reply in response to an 934 MPLS Echo Request that it sent. Thus, on receipt of an MPLS Echo 935 Reply, X should parse the packet to assure that it is well-formed, 936 then attempt to match up the Echo Reply with an Echo Request that it 937 had previously sent, using the destination UDP port and the Sender's 938 Handle. If no match is found, then X jettisons the Echo Reply; 939 otherwise, it checks the Sequence Number to see if it matches. Gaps 940 in the Sequence Number MAY be logged and SHOULD be counted. Once an 941 Echo Reply is received for a given Sequence Number (for a given UDP 942 port and Handle), the Sequence Number for subsequent Echo Requests 943 for that UDP port and Handle SHOULD be incremented. 945 If the Echo Reply contains Downstream Mappings, and X wishes to 946 traceroute further, it SHOULD copy the Downstream Mappings into its 947 next Echo Request (with TTL incremented by one). 949 4.6. Non-compliant Routers 951 If the egress for the FEC Stack being pinged does not support MPLS 952 ping, then no reply will be sent, resulting in possible "false 953 negatives". If in "traceroute" mode, a transit LSR does not support 954 MPLS ping, then no reply will be forthcoming from that LSR for some 955 TTL, say n. The LSR originating the echo request SHOULD try sending 956 the echo request with TTL=n+1, n+2, ..., n+k in the hope that some 957 transit LSR further downstream may support MPLS echo requests and 958 reply. In such a case, the echo request for TTL>n MUST NOT have 959 Downstream Mapping TLVs, until a reply is received with a Downstream 960 Mapping. 962 Normative References 964 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 965 Requirement Levels", BCP 14, RFC 2119, March 1997. 967 [LABEL-STACK] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 968 3032, January 2001. 970 [RSVP] Braden, R. (Editor), et al, "Resource ReSerVation protocol 971 (RSVP) -- Version 1 Functional Specification," RFC 2205, 972 September 1997. 974 [RSVP-REFRESH] Berger, L., et al, "RSVP Refresh Overhead Reduction 975 Extensions", RFC 2961, April 2001. 977 [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP 978 tunnels", RFC 3209, December 2001. 980 Informative References 982 [ICMP] Postel, J., "Internet Control Message Protocol", RFC 792. 984 [LDP] Andersson, L., et al, "LDP Specification", RFC 3036, January 985 2001. 987 Security Considerations 989 There are at least two approaches to attacking LSRs using the 990 mechanisms defined here. One is a Denial of Service attack, by 991 sending MPLS echo requests/replies to LSRs and thereby increasing 992 their workload. The other is obfuscating the state of the MPLS data 993 plane liveness by spoofing, hijacking, replaying or otherwise 994 tampering with MPLS echo requests and replies. 996 Authentication will help reduce the number of seemingly valid MPLS 997 echo requests, and thus cut down the Denial of Service attacks; 998 beyond that, each LSR must protect itself. 1000 Authentication sufficiently addresses spoofing, replay and most 1001 tampering attacks; one hopes to use some mechanism devised or 1002 suggested by the RPSec WG. It is not clear how to prevent hijacking 1003 (non-delivery) of echo requests or replies; however, if these 1004 messages are indeed hijacked, MPLS ping will report that the data 1005 plane isn't working as it should. 1007 It doesn't seem vital (at this point) to secure the data carried in 1008 MPLS echo requests and replies, although knowledge of the state of 1009 the MPLS data plane may be considered confidential by some. 1011 5. IANA Considerations 1013 The TCP and UDP port number 3503 has been allocated by IANA for LSP 1014 echo requests and replies. 1016 The following sections detail the new name spaces to be managed by 1017 IANA. For each of these name spaces, the space is divided into 1018 assignment ranges; the following terms are used in describing the 1019 procedures by which IANA allocates values: "Standards Action" (as 1020 defined in [IANA]); "Expert Review" and "Vendor Private Use". 1022 Values from "Expert Review" ranges MUST be registered with IANA, and 1023 MUST be accompanied by an Experimental RFC that describes the format 1024 and procedures for using the code point. 1026 Values from "Vendor Private" ranges MUST NOT be registered with IANA; 1027 however, the message MUST contain an enterprise code as registered 1028 with the IANA SMI Network Management Private Enterprise Codes. For 1029 each name space that has a Vendor Private range, it must be specified 1030 where exactly the SMI Enterprise Code resides; see below for 1031 examples. In this way, several enterprises (vendors) can use the 1032 same code point without fear of collision. 1034 5.1. Message Types, Reply Modes, Return Codes 1036 It is requested that IANA maintain registries for Message Types, 1037 Reply Modes, Return Codes and Return Subcodes. Each of these can 1038 take values in the range 0-255. Assignments in the range 0-191 are 1039 via Standards Action; assignments in the range 192-251 are made via 1040 Expert Review; values in the range 252-255 are for Vendor Private 1041 Use, and MUST NOT be allocated. 1043 If any of these fields fall in the Vendor Private range, a top-level 1044 Vendor Enterprise Code TLV MUST be present in the message. 1046 5.2. TLVs 1048 It is requested that IANA maintain registries for the Type field of 1049 top-level TLVs as well as for sub-TLVs. The valid range for each of 1050 these is 0-65535. Assignments in the range 0-32767 are made via 1051 Standards Action; assignments in the range 32768-64511 are made via 1052 Expert Review; values in the range 64512-65535 are for Vendor Private 1053 Use, and MUST NOT be allocated. 1055 If a TLV or sub-TLV has a Type that falls in the range for Vendor 1056 Private Use, the Length MUST be at least 4, and the first four octets 1057 MUST be that vendor's SMI Enterprise Code, in network octet order. 1058 The rest of the Value field is private to the vendor. 1060 Acknowledgments 1062 This document is the outcome of many discussions among many people, 1063 that include Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa 1064 Gan, Brook Bailey, Eric Rosen and Ina Minei. 1066 The Multipath Information sub-field of the Downstream Mapping TLV was 1067 adapted from text suggested by Curtis Villamizar. 1069 Appendix 1071 This appendix specifies non-normative aspects of detecting MPLS data 1072 plane liveness. 1074 5.1. CR-LDP FEC 1076 This section describes how a CR-LDP FEC can be included in an Echo 1077 Request using the following FEC subtype: 1079 Sub-Type # Length Value Field 1080 ---------- ------ ------------- 1081 5 6 CR-LDP LSP ID 1083 The value consists of the LSPID of the LSP being pinged. An LSPID is 1084 a four octet IPv4 address (a local address on the ingress LSR, for 1085 example, the Router ID) plus a two octet identifier that is unique 1086 per LSP on a given ingress LSR. 1088 0 1 2 3 1089 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 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Ingress LSR Router ID | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Must Be Zero | LSP ID | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 5.2. Downstream Mapping for CR-LDP 1098 If a label in a Downstream Mapping was learned via CR-LDP, the 1099 Protocol field in the Mapping TLV can use the following entry: 1101 Protocol # Signaling Protocol 1102 ---------- ------------------ 1103 5 CR-LDP 1105 Authors' Addresses 1107 Kireeti Kompella 1108 Nischal Sheth 1109 Juniper Networks 1110 1194 N.Mathilda Ave 1111 Sunnyvale, CA 94089 1112 e-mail: kireeti@juniper.net 1113 e-mail: nsheth@juniper.net 1115 Ping Pan 1116 Ciena 1117 10480 Ridgeview Court 1118 Cupertino, CA 95014 1119 e-mail: ppan@ciena.com 1120 phone: +1 408.366.4700 1122 Dave Cooper 1123 Global Crossing 1124 960 Hamlin Court 1125 Sunnyvale, CA 94089 1126 email: dcooper@gblx.net 1127 phone: +1 916.415.0437 1129 George Swallow 1130 Cisco Systems, Inc. 1131 250 Apollo Drive 1132 Chelmsford, MA 01824 1133 e-mail: swallow@cisco.com 1134 phone: +1 978.497.8143 1136 Sanjay Wadhwa 1137 Juniper Networks 1138 10 Technology Park Drive 1139 Westford, MA 01886-3146 1140 email: swadhwa@unispherenetworks.com 1141 phone: +1 978.589.0697 1143 Ronald P. Bonica 1144 WorldCom 1145 22001 Loudoun County Pkwy 1146 Ashburn, Virginia, 20147 1147 email: ronald.p.bonica@wcom.com 1148 phone: +1 703.886.1681 1150 Intellectual Property Rights Notices 1152 The IETF takes no position regarding the validity or scope of any 1153 intellectual property or other rights that might be claimed to 1154 pertain to the implementation or use of the technology described in 1155 this document or the extent to which any license under such rights 1156 might or might not be available; neither does it represent that it 1157 has made any effort to identify any such rights. Information on the 1158 IETF's procedures with respect to rights in standards-track and 1159 standards-related documentation can be found in BCP-11. Copies of 1160 claims of rights made available for publication and any assurances of 1161 licenses to be made available, or the result of an attempt made to 1162 obtain a general license or permission for the use of such 1163 proprietary rights by implementors or users of this specification can 1164 be obtained from the IETF Secretariat. 1166 The IETF invites any interested party to bring to its attention any 1167 copyrights, patents or patent applications, or other proprietary 1168 rights which may cover technology that may be required to practice 1169 this standard. Please address the information to the IETF Executive 1170 Director. 1172 Full Copyright Statement 1174 Copyright (C) The Internet Society (2003). All Rights Reserved. 1176 This document and translations of it may be copied and furnished to 1177 others, and derivative works that comment on or otherwise explain it 1178 or assist in its implmentation may be prepared, copied, published and 1179 distributed, in whole or in part, without restriction of any kind, 1180 provided that the above copyright notice and this paragraph are 1181 included on all such copies and derivative works. However, this 1182 document itself may not be modified in any way, such as by removing 1183 the copyright notice or references to the Internet Society or other 1184 Internet organizations, except as needed for the purpose of 1185 developing Internet standards in which case the procedures for 1186 copyrights defined in the Internet Standards process must be 1187 followed, or as required to translate it into languages other than 1188 English. 1190 The limited permissions granted above are perpetual and will not be 1191 revoked by the Internet Society or its successors or assigns. 1193 This document and the information contained herein is provided on an 1194 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1195 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1196 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1197 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1198 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.