idnits 2.17.1 draft-ietf-mpls-lsp-ping-02.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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 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 1075 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 (March 2003) is 7712 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RSVP' is defined on line 906, but no explicit reference was found in the text == Unused Reference: 'RSVP-TE' is defined on line 913, 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 (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella (Juniper) 3 Internet Draft P. Pan (Ciena) 4 draft-ietf-mpls-lsp-ping-02.txt N. Sheth (Juniper) 5 Category: Standards Track D. Cooper (Global Crossing) 6 Expires: September 2003 G. Swallow (Cisco) 7 S. Wadhwa (Juniper) 8 R. Bonica (WorldCom) 9 March 2003 11 Detecting MPLS Data Plane Liveness 13 *** DRAFT *** 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document describes a simple and efficient mechanism that can be 43 used to detect data plane failures in Multi-Protocol Label Switching 44 (MPLS) Label Switched Paths (LSPs). There are two parts to this 45 document: information carried in an MPLS "echo request" and "echo 46 reply" for the purposes of fault detection and isolation; and 47 mechanisms for reliably sending the echo reply. 49 Sub-IP ID Summary 51 (This section to be removed before publication.) 53 (See Abstract above.) 55 RELATED DOCUMENTS 57 May be found in the "references" section. 59 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 61 Fits in the MPLS box. 63 WHY IS IT TARGETED AT THIS WG 65 MPLS WG is currently looking at MPLS-specific error detection and 66 recovery mechanisms. The mechanisms proposed here are for packet- 67 based MPLS LSPs, which is why the MPLS WG is targeted. 69 JUSTIFICATION 71 The WG should consider this document, as it allows network operators 72 to detect MPLS LSP data plane failures in the network. This type of 73 failures have occurred, and are a source of concern to operators 74 implementing MPLS networks. 76 1. Introduction 78 This document describes a simple and efficient mechanism that can be 79 used to detect data plane failures in MPLS LSPs. There are two parts 80 to this document: information carried in an MPLS "echo request" and 81 "echo reply"; and mechanisms for transporting the echo reply. The 82 first part aims at providing enough information to check correct 83 operation of the data plane, as well as a mechanism to verify the 84 data plane against the control plane, and thereby localize faults. 85 The second part suggests two methods of reliable reply channels for 86 the echo request message, for more robust fault isolation. 88 An important consideration in this design is that MPLS echo requests 89 follow the same data path that normal MPLS packets would traverse. 90 MPLS echo requests are meant primarily to validate the data plane, 91 and secondarily to verify the data plane against the control plane. 92 Mechanisms to check the control plane are valuable, but are not 93 covered in this document. 95 To avoid potential Denial of Service attacks, it is recommended to 96 regulate the MPLS ping traffic going to the control plane. A rate 97 limiter should be applied to the well-known UDP port defined below. 99 1.1. Conventions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 105 1.2. Structure of this document 107 The body of this memo contains four main parts: motivation, MPLS echo 108 request/reply packet format, MPLS ping operation, and a reliable 109 return path. It is suggested that first-time readers skip the actual 110 packet formats and read the Theory of Operation first; the document 111 is structured the way it is to avoid forward references. 113 The last section (reliable return path for RSVP LSPs) may be removed 114 in a future revision. 116 1.3. Changes since last revision 118 (This section to be removed before publication.) 120 - Clarified definition of downstream router/interface. 121 - Added text for multipath (mostly just taken from Curtis) 122 - Mandated the use of Router Alert for sending echo requests 123 - If reply mode says IPv4 with router alert, and the reply is 124 labeled, the top label MUST be the router alert label 125 - Expanded the Theory of Operation, and added a section on ECMP 126 - Expanded checks on receipt of echo requests, per email on list 128 1.4. Issues remaining 130 (This section to be removed before publication.) 132 - Monitoring mode 133 - Finalize ECMP format and semantics 134 - Keep or remove replies via control plane? 135 - Normalize error codes 137 2. Motivation 139 When an LSP fails to deliver user traffic, the failure cannot always 140 be detected by the MPLS control plane. There is a need to provide a 141 tool that would enable users to detect such traffic "black holes" or 142 misrouting within a reasonable period of time; and a mechanism to 143 isolate faults. 145 In this document, we describe a mechanism that accomplishes these 146 goals. This mechanism is modeled after the ping/traceroute paradigm: 147 ping (ICMP echo request [ICMP]) is used for connectivity checks, and 148 traceroute is used for hop-by-hop fault localization as well as path 149 tracing. This document specifies a "ping mode" and a "traceroute" 150 mode for testing MPLS LSPs. 152 The basic idea is to test that packets that belong to a particular 153 Forwarding Equivalence Class (FEC) actually end their MPLS path on an 154 LSR that is an egress for that FEC. This document proposes that this 155 test be carried out by sending a packet (called an "MPLS echo 156 request") along the same data path as other packets belonging to this 157 FEC. An MPLS echo request also carries information about the FEC 158 whose MPLS path is being verified. This echo request is forwarded 159 just like any other packet belonging to that FEC. In "ping" mode 160 (basic connectivity check), the packet should reach the end of the 161 path, at which point it is sent to the control plane of the egress 162 LSR, which then verifies that it is indeed an egress for the FEC. In 163 "traceroute" mode (fault isolation), the packet is sent to the 164 control plane of each transit LSR, which performs various checks that 165 it is indeed a transit LSR for this path; this LSR also returns 166 further information that helps check the control plane against the 167 data plane, i.e., that forwarding matches what the routing protocols 168 determined as the path. 170 One way these tools can be used is to periodically ping a FEC to 171 ensure connectivity. If the ping fails, one can then initiate a 172 traceroute to determine where the fault lies. One can also 173 periodically traceroute FECs to verify that forwarding matches the 174 control plane; however, this places a greater burden on transit LSRs 175 and thus should be used with caution. 177 3. Packet Format 179 An MPLS echo request is a (possibly labelled) UDP packet; the 180 contents of the UDP packet have the following format: 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Version Number | Must Be Zero | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Message Type | Reply mode | Return Code | Return Subcode| 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Sender's Handle | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Sequence Number | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | TimeStamp Sent (seconds) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | TimeStamp Sent (microseconds) | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | TimeStamp Received (seconds) | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | TimeStamp Received (microseconds) | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | TLVs ... | 202 . . 203 . . 204 . . 205 | | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 The Version Number is currently 1. (Note: the Version Number is to 209 be incremented whenever a change is made that affects the ability of 210 an implementation to correctly parse or process an MPLS echo 211 request/reply. These changes include any syntactic or semantic 212 changes made to any of the fixed fields, or to any TLV or sub-TLV 213 assignment or format that is defined at a certain version number. 214 The Version Number may not need to be changed if an optional TLV or 215 sub-TLV is added.) 217 The Message Type is one of the following: 219 Value Meaning 220 ----- ------- 221 1 MPLS Echo Request 222 2 MPLS Echo Reply 224 The Reply Mode can take one of the following values: 226 Value Meaning 227 ----- ------- 228 1 Do not reply 229 2 Reply via an IPv4 UDP packet 230 3 Reply via an IPv4 UDP packet with Router Alert 231 4 Reply via the control plane 233 An MPLS echo request with "Do not reply" may be used for one-way 234 connectivity tests; the receiving router may log gaps in the sequence 235 numbers and/or maintain delay/jitter statistics. An MPLS echo 236 request would normally have "Reply via an IPv4 UDP packet"; if the 237 normal IPv4 return path is deemed unreliable, one may use "Reply via 238 an IPv4 UDP packet with Router Alert" (note that this requires that 239 all intermediate routers understand and know how to forward MPLS echo 240 replies) or "Reply via the control plane" (this is currently only 241 defined for control plane that uses RSVP). 243 The Return Code is set to zero by the sender. The receiver can set 244 it to one of the following values: 246 Value Meaning 247 ----- ------- 248 0 The error code is contained in the Error Code TLV 249 1 Malformed echo request received 250 2 One or more of the TLVs was not understood 251 3 Replying router is an egress for the FEC 252 4 Replying router has no mapping for the FEC 253 5 Replying router is not one of the "Downstream Routers" 254 6 Replying router is one of the "Downstream Routers", 255 and its mapping for this FEC on the received interface 256 is the given label 257 7 Replying router is one of the "Downstream Routers", 258 but its mapping for this FEC is not the given label 260 The Return Subcode is unused at present and SHOULD be set to zero. 262 The Sender's Handle is filled in by the sender, and returned 263 unchanged by the receiver in the echo reply (if any). There are no 264 semantics associated with this handle, although a sender may find 265 this useful for matching up requests with replies. 267 The Sequence Number is assigned by the sender of the MPLS echo 268 request, and can be (for example) used to detect missed replies. 270 The TimeStamp Sent is the time-of-day (in seconds and microseconds, 271 wrt the sender's clock) when the MPLS echo request is sent. The 272 TimeStamp Received in an echo reply is the time-of-day (wrt the 273 receiver's clock) that the corresponding echo request was received. 275 TLVs (Type-Length-Value tuples) have the following format: 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type | Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Value | 283 . . 284 . . 285 . . 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Types are defined below; Length is the length of the Value field in 290 octets. The Value field depends on the Type; it is zero padded to 291 align to a four-octet boundary. 293 Type # Value Field 294 ------ ----------- 295 1 Target FEC Stack 296 2 Downstream Mapping 297 3 Pad 298 4 Error Code 300 3.1. Target FEC Stack 302 A Target FEC Stack is a list of sub-TLVs. The number of elements is 303 determined by the looking at the sub-TLV length fields. 305 Sub-Type # Length Value Field 306 ---------- ------ ----------- 307 1 5 LDP IPv4 prefix 308 2 17 LDP IPv6 prefix 309 3 20 RSVP IPv4 Session Query 310 4 56 RSVP IPv6 Session Query 311 5 Reserved; see Appendix 312 6 13 VPN IPv4 prefix 313 7 25 VPN IPv6 prefix 314 8 14 L2 VPN endpoint 315 9 10 L2 circuit ID 317 Other FEC Types will be defined as needed. 319 Note that this TLV defines a stack of FECs, the first FEC element 320 corresponding to the top of the label stack, etc. 322 An MPLS echo request MUST have a Target FEC Stack that describes the 323 FEC stack being tested. For example, if an LSR X has an LDP mapping 324 for 192.168.1.1 (say label 1001), then to verify that label 1001 does 325 indeed reach an egress LSR that announced this prefix via LDP, X can 326 send an MPLS echo request with a FEC Stack TLV with one FEC in it, 327 namely of type LDP IPv4 prefix, with prefix 192.168.1.1/32, and send 328 the echo request with a label of 1001. 330 If LSR X wanted to verify that a label stack of <1001, 23456> is the 331 right label stack to use to reach an IP VPN prefix of 10/8 in VPN foo 332 on an egress LSR with loopback address 192.168.1.1 (learned via LDP), 333 X has two choices. X can send an MPLS echo request with a FEC Stack 334 TLV with a single FEC of type VPN IPv4 prefix with a prefix of 10/8 335 with the Route Distinguisher for VPN foo. Alternatively, X can send 336 a FEC Stack TLV with two FECs, the first of type LDP IPv4 with a 337 prefix of 192.168.1.1/32 and the second of type of IP VPN with a 338 prefix 10/8 in VPN foo. In either case, the MPLS echo request would 339 have a label stack of <1001, 23456>. (Note: in this example, 1001 is 340 the "outer" label and 23456 is the "inner" label.) 342 3.1.1. LDP IPv4 Prefix 344 The value consists of four octets of an IPv4 prefix followed by one 345 octet of prefix length in bits. The IPv4 prefix is in network byte 346 order. See [LDP] for an example of a Mapping for an IPv4 FEC. 348 3.1.2. LDP IPv6 Prefix 350 The value consists of sixteen octets of an IPv6 prefix followed by 351 one octet of prefix length in bits. The IPv6 prefix is in network 352 byte order. See [LDP] for an example of a Mapping for an IPv6 FEC. 354 3.1.3. RSVP IPv4 Session 356 The value has the format below. The value fields are taken from 357 [RFC3209, sections 4.6.1.1 and 4.6.2.1]. 359 0 1 2 3 360 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | IPv4 tunnel end point address | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Must Be Zero | Tunnel ID | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Extended Tunnel ID | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | IPv4 tunnel sender address | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Must Be Zero | LSP ID | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 3.1.4. RSVP IPv6 Session 375 The value has the format below. The value fields are taken from 376 [RFC3209, sections 4.6.1.2 and 4.6.2.2]. 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | IPv6 tunnel end point address | 382 | | 383 | | 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Must Be Zero | Tunnel ID | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Extended Tunnel ID | 389 | | 390 | | 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | IPv6 tunnel sender address | 394 | | 395 | | 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Must Be Zero | LSP ID | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 3.1.5. VPN IPv4 Prefix 403 The value field consists of a Route Distinguisher, an IPv4 prefix and 404 a prefix length, as follows: 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Route Distinguisher | 410 | (8 octets) | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | IPv4 prefix | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Prefix Length | Must Be Zero | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 3.1.6. VPN IPv6 Prefix 419 The value field consists of a Route Distinguisher, an IPv6 prefix and 420 a prefix length, as follows: 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Route Distinguisher | 426 | (8 octets) | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | IPv6 prefix | 429 | | 430 | | 431 | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Prefix Length | Must Be Zero | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 3.1.7. L2 VPN Endpoint 438 The value field consists of a Route Distinguisher (8 octets), the 439 sender (of the ping)'s CE ID (2 octets), the receiver's CE ID (2 440 octets), and an encapsulation type (2 octets), formatted as follows: 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Route Distinguisher | 446 | (8 octets) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Sender's CE ID | Receiver's CE ID | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Encapsulation Type | Must Be Zero | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 3.1.8. L2 Circuit ID 455 The value field consists of a remote PE address (the address of the 456 targetted LDP session), a VC ID and an encapsulation type, as 457 follows: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Remote PE Address | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | VC ID | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Encapsulation Type | Must Be Zero | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 3.2. Downstream Mapping 471 The Downstream Mapping is an optional TLV in an echo request. The 472 Length is 12 + 4*N octets, where N is the number of Downstream 473 Labels. The Value of a Downstream Mapping has the following format: 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Downstream IPv4 Router ID | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | MTU | Address Type | DS Index | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Downstream Interface Address | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Hash Key Type | Depth Limit | Multipath Length | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | IP Address or Next Label | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 . . 489 . (more IP Addresses or Next Labels) . 490 . . 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Downstream Label | Protocol | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 . . 495 . . 496 . . 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Downstream Label | Protocol | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 The MTU is the largest MPLS frame (including label stack) that fits 502 on the interface to the Downstream LSR. The Downstream Interface 503 Address Type is one of: 505 Type # Address Type 506 ------ ------------ 507 1 IPv4 508 2 Unnumbered 510 'Protocol' is taken from the following table: 512 Protocol # Signaling Protocol 513 ---------- ------------------ 514 0 Unknown 515 1 Static 516 2 BGP 517 3 LDP 518 4 RSVP-TE 519 5 Reserved; see Appendix 521 The notion of "downstream router" and "downstream interface" should 522 be explained. Consider an LSR X. If a packet that was originated 523 with TTL n>1 arrived with outermost label L at LSR X, X must be able 524 to compute which LSRs could receive the packet if it was originated 525 with TTL=n+1, over which interface the request would arrive and what 526 label stack those LSRs would see. (It is outside the scope of this 527 document to specify how this computation is done.) The set of these 528 LSRs/interfaces are the downstream routers/interfaces (and their 529 corresponding labels) for X with respect to L. Each pair of 530 downstream router and interface requires a separate Downstream 531 Mapping to be added to the reply, and is given a unique DS Index. 532 (Note that there are multiple Downstream Label fields in each TLV as 533 the incoming label L may be swapped with a label stack.) 535 The case where X is the LSR originating the echo request is a special 536 case. X needs to figure out what LSRs would receive the MPLS echo 537 request for a given FEC Stack that X originates with TTL=1. 539 The set of downstream routers at X may be alternative paths (see the 540 discussion below on ECMP) or simultaneous paths (e.g., for MPLS 541 multicast). In the former case, the Multipath sub-field is used as a 542 hint to the sender as to how it may influence the choice of these 543 alternatives. The Multipath Length is the total length of the 544 Multipath field (i.e., 4 + 4*M, where M is the number of IP 545 Address/Next Label fields). The Hash Key Type is taken from the 546 following table: 548 Hash Key Type IP Address or Next Label 549 -------------------- ------------------------ 550 0 no multipath (nothing; M = 0) 551 1 label M labels 552 2 IP address M IP addresses 553 3 label range M/2 low/high label pairs 554 4 IP address range M/2 low/high address pairs 555 5 no more labels (nothing; M = 0) 556 6 All IP addresses (nothing; M = 0) 557 7 no match (nothing; M = 0) 559 The Depth Limit is applicable only to a label stack, and is the 560 maximum number of labels considered in the hash; this SHOULD be set 561 to zero if unspecified or unlimited. 563 IP Address or Next Label is an IP address from the range 127/8 or an 564 next label which will exercise this particular path. 566 The semantics of the Hash Key Type and IP Address/Next Label are as 567 follows: 569 type 1 - a list of single labels is provided, any one of which 570 will 571 cause the hash to match this MP path. 572 type 2 - a list of single IP addresses is provided, any one of 573 which will cause the hash to match this MP path. 574 type 3 - a list of label ranges is provided, any one of which will 575 cause the hash to match this MP path. 576 type 4 - a list of IP address ranges is provided, any one of which 577 will cause the hash to match this MP path. 578 type 5 - if no more labels are provided on the stack, this MP path 579 will apply (can only appear once). 580 type 6 - Any IP addresses matches. Undertlying labels may go 581 elsewhere, but all IP takes only one MP path (can only 582 appear once). 583 type 7 - no matches are possible given the set of "Multipath 584 Exercise TLV" provided by prior hops. 586 If prior hops provide a "Downstream Multipath Mapping TLV" the labels 587 and IP addresses should be picked from the set provided in prior 588 "Multipath Exercise TLV" or "Hash Key Type" of 7 used. 590 3.3. Pad TLV 592 The value part of the Pad TLV contains a variable number (>= 1) of 593 octets. The first octet takes values from the following table; all 594 the other octets (if any) are ignored. The receiver SHOULD verify 595 that the TLV is received in its entirety, but otherwise ignores the 596 contents of this TLV, apart from the first octet. 598 Value Meaning 599 ----- ------- 600 1 Drop Pad TLV from reply 601 2 Copy Pad TLV to reply 602 3-255 Reserved for future use 604 3.4. Error Code 606 The Error Code TLV is currently not defined; its purpose is to 607 provide a mechanism for a more elaborate error reporting structure, 608 should the reason arise. 610 4. Theory of Operation 612 An MPLS echo request is used to test a particular LSP. The LSP to be 613 tested is identified by the "FEC Stack"; for example, if the LSP was 614 set up via LDP, and is to an egress IP address of 10.1.1.1, the FEC 615 stack contains a single element, namely, an LDP IPv4 prefix sub-TLV 616 with value 10.1.1.1/32. If the LSP being tested is an RSVP LSP, the 617 FEC stack consists of a single element that captures the RSVP Session 618 and Sender Template which uniquely identifies the LSP. 620 FEC stacks can be more complex. For example, one may wish to test a 621 VPN IPv4 prefix of 10.1/8 that is tunneled over an LDP LSP with 622 egress 10.10.1.1. The FEC stack would then contain two sub-TLVs, the 623 first being a VPN IPv4 prefix, and the second being an LDP IPv4 624 prefix. If the underlying (LDP) tunnel were not known, or was 625 considered irrelevant, the FEC stack could be a single element with 626 just the VPN IPv4 sub-TLV. 628 When an MPLS echo request is received, the receiver is expected to do 629 a number of tests that verify that the control plane and data plane 630 are both healthy (for the FEC stack being pinged), and that the two 631 planes are in sync. 633 4.1. Dealing with Equal-Cost Multi-Path (ECMP) 635 LSPs need not be simple point-to-point tunnels. Frequently, a single 636 LSP may originate at several ingresses, and terminate at several 637 egresses; this is very common with LDP LSPs. LSPs for a given FEC 638 may also have multiple "next hops" at transit LSRs. At an ingress, 639 there may also be several different LSPs to choose from to get to the 640 desired endpoint. Finally, LSPs may have backup paths, detour paths 641 and other alternative paths to take should the primary LSP go down. 643 To deal with the last two first: it is assumed that the LSR sourcing 644 MPLS echo requests can force the echo request into any desired LSP, 645 so choosing among multiple LSPs at the ingress is not an issue. The 646 problem of probing the various flavors of backup paths that will 647 typically not be used for forwarding data unless the primary LSP is 648 down will not be addressed here. 650 Since the actual LSP and path that a given packet may take may not be 651 known a priori, it is useful if MPLS echo requests can exercise all 652 possible paths. This, while desirable, may not be practical, because 653 the algorithms that a given LSR uses to distribute packets over 654 alternative paths may be proprietary. 656 To achieve some degree of coverage of alternate paths, there is a 657 certain lattitude in choosing the destination IP address and source 658 UDP port for an MPLS echo request. This is clearly not sufficient; 659 in the case of traceroute, more lattitude is offered by means of the 660 "Multipath Exercise" sub-TLV of the Downstream Mapping TLV. This is 661 used as follows. An ingress LSR periodically sends an MPLS 662 traceroute message to determine whether there are multipaths for a 663 given LSP. If so, each hop will provide some information how each of 664 its downstreams can be exercised. The ingress can then send MPLS 665 echo requests that exercise these paths. If several transit LSRs 666 have ECMP, the ingress may attempt to compose these to exercise all 667 possible paths. However, full coverage may not be possible. 669 4.2. Sending an MPLS Echo Request 671 An MPLS echo request is a (possibly) labelled UDP packet. The IP 672 header is set as follows: the source IP address is a routable address 673 of the sender; the destination IP address is a (randomly chosen) 674 address from 127/8; the IP TTL is set to 1. The source UDP port is 675 chosen by the sender; the destination UDP port is set to 3503 676 (assigned by IANA for MPLS echo requests). The Router Alert option 677 is set in the IP header. If the echo request is labelled, the MPLS 678 TTL on all the labels except the outermost should be set to 1. 680 In "ping" mode (end-to-end connectivity check), the TTL in the 681 outermost label is set to 255. In "traceroute" mode (fault isolation 682 mode), the TTL is set successively to 1, 2, .... 684 The sender chooses a Sender's Handle, and a Sequence Number. When 685 sending subsequent MPLS echo requests, the sender SHOULD increment 686 the sequence number by 1. However, a sender MAY choose to send a 687 group of echo requests with the same sequence number to improve the 688 chance of arrival of at least one packet with that sequence number. 690 The TimeStamp Sent is set to the time-of-day (in seconds and 691 microseconds) that the echo request is sent. The TimeStamp Received 692 is set to zero. 694 An MPLS echo request MUST have a FEC Stack TLV. Also, the Reply Mode 695 must be set to the desired reply mode; the Return Code and Subcode 696 are set to zero. 698 In the "traceroute" mode, the echo request SHOULD contain one or more 699 Downstream Mapping TLVs. For TTL=1, all the downstream routers (and 700 corresponding labels) for the sender with respect to the FEC Stack 701 being pinged SHOULD be sent in the echo request. For n>1, the 702 Downstream Mapping TLVs from the echo reply for TTL=(n-1) are copied 703 to the echo request with TTL=n; the sender MAY choose to reduce the 704 size of a "Downstream Multipath Mapping TLV" when copying into the 705 next echo request as long as the Hash Key Type matching the label or 706 IP address used to exercise the current MP is still present. 708 4.3. Receiving an MPLS Echo Request 710 An LSR X that receives an MPLS echo request first parses the packet 711 to ensure that it is a well-formed packet, and that the TLVs are 712 understood. If not, X SHOULD send an MPLS echo reply with the Return 713 Code set to "Malformed echo request received" or "TLV not understood" 714 (as appropriate), and the Subcode set to the appropriate value. 716 If the echo request is good, X then checks whether it is a valid 717 transit or egress LSR for the FEC in the echo request. If not, X MAY 718 log this fact. If it is, X notes that interface I over which the 719 echo was received, and the label L with which it came. X checks 720 whether it actually advertised L over interface I for the FEC in the 721 echo request. 723 If the echo request contains a Downstream Mapping TLV, X MUST further 724 check whether its Router ID matches one of the Downstream IPv4 Router 725 IDs; and if so, whether the given Downstream Label is in fact the 726 label that X sent as its mapping for the FEC over the downstream 727 interface. The result of the checks in the previous and this 728 paragraph are captured in the Return Code/Subcode. 730 If the echo request has a Reply Mode that wants a reply, X uses the 731 procedure in the next subsection to send the echo reply. 733 4.4. Sending an MPLS Echo Reply 735 An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response 736 to an MPLS echo request. The source IP address is a routable address 737 of the replier; the source port is the well-known UDP port for MPLS 738 ping. The destination IP address and UDP port are copied from the 739 source IP address and UDP port of the echo request. The IP TTL is 740 set to 255. If the Reply Mode in the echo request is "Reply via an 741 IPv4 UDP packet with Router Alert", then the IP header MUST contain 742 the Router Alert IP option. If the reply is sent over an LSP, the 743 topmost label MUST in this case be the Router Alert label (1) (see 744 [LABEL-STACK]). 746 The format of the echo reply is the same as the echo request. The 747 Sender's Handle, the Sequence Number and TimeStamp Sent are copied 748 from the echo request; the TimeStamp Received is set to the time-of- 749 day that the echo request is received (note that this information is 750 most useful if the time-of-day clocks on the requestor and the 751 replier are synchronized). The FEC Stack TLV from the echo request 752 MAY be copied to the reply. 754 The replier MUST fill in the Return Code and Subcode, as determined 755 in the previous subsection. 757 If the echo request contains a Pad TLV, the replier MUST interpret 758 the first octet for instructions regarding how to reply. 760 If the echo request contains a Downstream Mapping TLV, the replier 761 SHOULD compute its downstream routers and corresponding labels for 762 the incoming label, and add Downstream Mapping TLVs for each one to 763 the echo reply it sends back. 765 4.5. Receiving an MPLS Echo Reply 767 An LSR X should only receive an MPLS Echo Reply in response to an 768 MPLS Echo Request that it sent. Thus, on receipt of an MPLS Echo 769 Reply, X should parse the packet to assure that it is well-formed, 770 then attempt to match up the Echo Reply with an Echo Request that it 771 had previously sent, using the destination UDP port and the Sender's 772 Handle. If no match is found, then X jettisons the Echo Reply; 773 otherwise, it checks the Sequence Number to see if it matches. Gaps 774 in the Sequence Number MAY be logged and SHOULD be counted. Once an 775 Echo Reply is received for a given Sequence Number (for a given UDP 776 port and Handle), the Sequence Number for subsequent Echo Requests 777 for that UDP port and Handle SHOULD be incremented. 779 If the Echo Reply contains Downstream Mappings, and X wishes to 780 traceroute further, it SHOULD copy the Downstream Mappings into its 781 next Echo Request (with TTL incremented by one). 783 4.6. Non-compliant Routers 785 If the egress for the FEC Stack being pinged does not support MPLS 786 ping, then no reply will be sent, resulting in possible "false 787 negatives". If in "traceroute" mode, a transit LSR does not support 788 MPLS ping, then no reply will be forthcoming from that LSR for some 789 TTL, say n. The LSR originating the echo request SHOULD try sending 790 the echo request with TTL=n+1, n+2, ..., n+k in the hope that some 791 transit LSR further downstream may support MPLS echo requests and 792 reply. In such a case, the echo request for TTL>n MUST NOT have 793 Downstream Mapping TLVs, until a reply is received with a Downstream 794 Mapping. 796 5. Reliable Reply Path 798 One of the issues that are faced with MPLS ping is to distinguish 799 between a failure in the forward path (the MPLS path being 'pinged') 800 and a failure in the return path. Note that this problem exists with 801 vanilla IP ping as well. In the case of MPLS ping, it is assumed 802 that the IP control and data planes are reliable. However, it could 803 be that the forwarding in the return path is via an MPLS LSP. 805 In this specification, we give two solutions for this problem. One 806 is to set the Router Alert option in the MPLS echo reply. When a 807 router sees this option, it MUST forward the packet as an IP packet. 808 Note that this may not work if some transit LSR does not support MPLS 809 ping. 811 Another option is to send the echo reply via the control plane. At 812 present, this is defined only for RSVP-TE LSPs, and described below. 814 These options are controlled by the ingress LSR, using the Reply Mode 815 in the MPLS echo request packet. 817 5.1. RSVP-TE Extension 819 To test an LSP's liveliness, an ingress LSR sends MPLS echo requests 820 over the LSP being tested. When an egress LSR receives the message, 821 it needs to acknowledge the ingress LSR by sending an LSP_ECHO object 822 in a RSVP Resv message. The object has the following format: 824 Class = LSP_ECHO (use form 11bbbbbb for compatibility) 826 C-Type = 1 828 0 1 2 3 829 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Sequence Number | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | TimeStamp (seconds) | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | TimeStamp (microseconds) | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | UDP Source Port | Return Code | Return Subcode| 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 The Sequence Number is copied from the Sequence Number of the echo 841 request. The TimeStamp is set to the time the echo request is 842 received. The UDP Source Port is copied from the UDP source port of 843 the MPLS echo request. The FEC is implied by the Session and the 844 Sender Template Objects. 846 5.2. Operation 848 For the sake of brevity in the context of this document by "the 849 control plane" we mean "the RSVP-TE component of the control plane". 851 Consider an LSP between an ingress LSR and an egress LSR spanning 852 multiple LSR hops. 854 5.3. Procedures at the ingress LSR 856 One must ensure before setting the Reply Mode to "reply via the 857 control plane" that the egress LSR supports this feature. 859 The ingress LSR, say X, builds an MPLS echo request as in section 860 "Sending an MPLS Echo Request". The FEC Type must be an RVSP Session 861 Query. X also sets the Reply Mode to "reply via the control plane". 863 If X does not receive an Resv message from the egress LSR that 864 contains an LSP_ECHO object within some period of time, it declares 865 the LSP as "down". At this point, the ingress LSR may apply the 866 necessary procedures to fix the LSP. These may include generating a 867 message to network management, tearing-down and re-building the LSP, 868 and/or rerouting user traffic to a backup LSP. 870 To test an LSP that carries non-IP traffic, before injecting ICMP and 871 MPLS ping messages into the LSP, the IPv4 Explicit NULL label should 872 be prepended to such messages. The ingress and egress LSR's must 873 follow the procedures defined in [LABEL-STACK]. 875 5.4. Procedures at the egress LSR 877 When the egress LSR receives an MPLS ping message, it follows the 878 procedures given above. If the Reply Mode is set to "Reply via the 879 control plane", the LSR can, based on the RSVP SESSION and 880 SENDER_TEMPLATE objects carried in the MPLS ping message, find the 881 corresponding LSP in its RSVP-TE database. The LSR then checks to 882 see if the Resv message for this LSP contains an LSP_ECHO object with 883 the same source UDP port value. If not, the LSR adds or updates the 884 LSP_ECHO object and refreshes the Resv message. 886 5.5. Procedures for the intermediate LSR's 888 At intermediate LSRs, normal RSVP processing procedures will cause 889 the LSP_ECHO object to be forwarded as RSVP messages are refreshed. 891 At the LSR's that support MPLS ping the Resv messages that carry the 892 LSP_ECHO object MUST be delivered upstream immediately. 894 Note that an intermediate LSR using RSVP refresh reduction [RSVP- 895 REFRESH], the new or changed LSP_ECHO object will cause the LSR to 896 classify the RSVP message as a trigger message. 898 6. Normative References 900 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 901 Requirement Levels", BCP 14, RFC 2119, March 1997. 903 [LABEL-STACK] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 904 3032, January 2001. 906 [RSVP] Braden, R. (Editor), et al, "Resource ReSerVation protocol 907 (RSVP) -- Version 1 Functional Specification," RFC 2205, 908 September 1997. 910 [RSVP-REFRESH] Berger, L., et al, "RSVP Refresh Overhead Reduction 911 Extensions", RFC 2961, April 2001. 913 [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP 914 tunnels", RFC 3209, December 2001. 916 7. Informative References 918 [ICMP] Postel, J., "Internet Control Message Protocol", RFC 792. 920 [LDP] Andersson, L., et al, "LDP Specification", RFC 3036, January 921 2001. 923 8. Security Considerations 925 There are at least two approaches to attacking LSRs using the 926 mechanisms defined here. One is a Denial of Service attack, by 927 sending MPLS echo requests/replies to LSRs and thereby increasing 928 their workload. The other is obfuscating the state of the MPLS data 929 plane liveness by spoofing, hijacking, replaying or otherwise 930 tampering with MPLS echo requests and replies. 932 Authentication will help reduce the number of seemingly valid MPLS 933 echo requests, and thus cut down the Denial of Service attacks; 934 beyond that, each LSR must protect itself. 936 Authentication sufficiently addresses spoofing, replay and most 937 tampering attacks; one hopes to use some mechanism devised or 938 suggested by the RPSec WG. It is not clear how to prevent hijacking 939 (non-delivery) of echo requests or replies; however, if these 940 messages are indeed hijacked, MPLS ping will report that the data 941 plane isn't working as it should. 943 It doesn't seem vital (at this point) to secure the data carried in 944 MPLS echo requests and replies, although knowledge of the state of 945 the MPLS data plane may be considered confidential by some. 947 9. IANA Considerations 949 (To be filled in a later revision) 951 10. Acknowledgments 953 This document is the outcome of many discussions among many people, 954 that include Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa 955 Gan, Brook Bailey, Eric Rosen and Ina Minei. 957 The Multipath Exercise sub-field of the Downstream Mapping TLV was 958 adapted from text suggested by Curtis Villamizar. 960 11. Appendix 962 This appendix specifies non-normative aspects of detecting MPLS data 963 plane liveness. 965 11.1. CR-LDP FEC 967 This section describes how a CR-LDP FEC can be included in an Echo 968 Request using the following FEC subtype: 970 Sub-Type # Length Value Field 971 ---------- ------ ----------- 972 5 6 CR-LDP LSP ID 974 The value consists of the LSPID of the LSP being pinged. An LSPID is 975 a four octet IPv4 address (a local address on the ingress LSR, for 976 example, the Router ID) plus a two octet identifier that is unique 977 per LSP on a given ingress LSR. 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Ingress LSR Router ID | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Must Be Zero | LSP ID | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 11.2. Downstream Mapping for CR-LDP 989 If a label in a Downstream Mapping was learned via CR-LDP, the 990 Protocol field in the Mapping TLV can use the following entry: 992 Protocol # Signaling Protocol 993 ---------- ------------------ 994 5 CR-LDP 996 12. Authors' Addresses 998 Kireeti Kompella 999 Nischal Sheth 1000 Juniper Networks 1001 1194 N.Mathilda Ave 1002 Sunnyvale, CA 94089 1003 e-mail: kireeti@juniper.net 1004 e-mail: nsheth@juniper.net 1006 Ping Pan 1007 Ciena 1008 10480 Ridgeview Court 1009 Cupertino, CA 95014 1010 e-mail: ppan@ciena.com 1011 phone: +1 408.366.4700 1013 Dave Cooper 1014 Global Crossing 1015 960 Hamlin Court 1016 Sunnyvale, CA 94089 1017 email: dcooper@gblx.net 1018 phone: +1 916.415.0437 1020 George Swallow 1021 Cisco Systems, Inc. 1022 250 Apollo Drive 1023 Chelmsford, MA 01824 1024 e-mail: swallow@cisco.com 1025 phone: +1 978.497.8143 1027 Sanjay Wadhwa 1028 Juniper Networks 1029 10 Technology Park Drive 1030 Westford, MA 01886-3146 1031 email: swadhwa@unispherenetworks.com 1032 phone: +1 978.589.0697 1034 Ronald P. Bonica 1035 WorldCom 1036 22001 Loudoun County Pkwy 1037 Ashburn, Virginia, 20147 1038 email: ronald.p.bonica@wcom.com 1039 phone: +1 703.886.1681 1041 13. Intellectual Property Rights Notices 1043 The IETF takes no position regarding the validity or scope of any 1044 intellectual property or other rights that might be claimed to 1045 pertain to the implementation or use of the technology described in 1046 this document or the extent to which any license under such rights 1047 might or might not be available; neither does it represent that it 1048 has made any effort to identify any such rights. Information on the 1049 IETF's procedures with respect to rights in standards-track and 1050 standards-related documentation can be found in BCP-11. Copies of 1051 claims of rights made available for publication and any assurances of 1052 licenses to be made available, or the result of an attempt made to 1053 obtain a general license or permission for the use of such 1054 proprietary rights by implementors or users of this specification can 1055 be obtained from the IETF Secretariat. 1057 The IETF invites any interested party to bring to its attention any 1058 copyrights, patents or patent applications, or other proprietary 1059 rights which may cover technology that may be required to practice 1060 this standard. Please address the information to the IETF Executive 1061 Director. 1063 Full Copyright Statement 1065 Copyright (C) The Internet Society (2003). All Rights Reserved. 1067 This document and translations of it may be copied and furnished to 1068 others, and derivative works that comment on or otherwise explain it 1069 or assist in its implmentation may be prepared, copied, published and 1070 distributed, in whole or in part, without restriction of any kind, 1071 provided that the above copyright notice and this paragraph are 1072 included on all such copies and derivative works. However, this 1073 document itself may not be modified in any way, such as by removing 1074 the copyright notice or references to the Internet Society or other 1075 Internet organizations, except as needed for the purpose of 1076 developing Internet standards in which case the procedures for 1077 copyrights defined in the Internet Standards process must be 1078 followed, or as required to translate it into languages other than 1079 English. 1081 The limited permissions granted above are perpetual and will not be 1082 revoked by the Internet Society or its successors or assigns. 1084 This document and the information contained herein is provided on an 1085 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1086 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1087 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1088 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1089 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.