idnits 2.17.1 draft-ietf-mpls-remote-lsp-ping-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 660. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 646. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 566 has weird spacing: '...ge Type tba ...' == Line 569 has weird spacing: '...ct Type tba...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2007) is 5978 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: 'LSP-PING' is mentioned on line 394, but not defined ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-18) exists of draft-ietf-mpls-p2mp-lsp-ping-02 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group George Swallow 3 Internet Draft Cisco Systems, Inc. 4 Category: Standards Track 5 Expiration Date: May 2008 6 Vanson Lim 7 Cisco Systems, Inc. 9 November 2007 11 Proxy LSP Ping 13 draft-ietf-mpls-remote-lsp-ping-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 This document defines a means of remotely initiating Multiprocal 41 Label Switched Protocol Pings on Label Switched Paths. A proxy 42 ping request is sent to any Label Switching Routers along a Label 43 Switched Path. The primary motivations for this facility are 44 first to limit the number of messages and related processing when 45 using LSP Ping in large Point-to-Multipoint LSPs, and second to 46 enable leaf to root tracing. 48 Contents 50 1 Introduction .............................................. 3 51 1.1 Conventions ............................................... 3 52 2 Proxy Ping Overview ....................................... 4 53 3 Remote Echo / Reply Pprocedures ........................... 5 54 3.1 Procedures for the initiator .............................. 5 55 3.2 Procedures for the proxy LSR .............................. 6 56 3.2.1 Sending an MPLS proxy ping reply .......................... 7 57 3.2.2 Sending the MPLS echo requests ............................ 7 58 4 Proxy Ping Request / Reply Messages ....................... 8 59 4.1 Proxy Ping Request / Reply Message formats ................ 9 60 4.2 Proxy Ping Request Message contents ....................... 10 61 4.3 Proxy Ping Reply Message Contents ......................... 10 62 5 Object formats ............................................ 11 63 5.1 Proxy Echo Parameters Object .............................. 11 64 5.2 Reply-to Address Object ................................... 12 65 5.3 Previous Hop Address Object ............................... 13 66 6 Security Considerations ................................... 13 67 7 IANA Considerations ....................................... 13 68 7.1 Message and Object Type Assignments ....................... 14 69 7.2 Return Code Assignments ................................... 14 70 8 Acknowledgments ........................................... 14 71 9 References ................................................ 14 72 9.1 Normative References ...................................... 14 73 9.2 Informative References .................................... 15 74 10 Authors' Addresses ........................................ 15 75 1. Introduction 77 It is anticipated that very large Point-to-Multipoint (P2MP) Label 78 Switched Paths (LSPs) will exist. Further it is anticipated that 79 many of the applications for P2MP tunnels will require OAM that is 80 both rigorous and scalable. 82 Suppose one wishes to trace a P2MP LSP to localize a fault which is 83 affecting one egress or a set of egresses. Suppose one follows the 84 normal procedure for tracing - namely repeatedly pinging from the 85 root, incrementing the TTL by one after each three or so pings. Such 86 a procedure has the potential for producing a large amount of pro- 87 cessing at the P2MP-LSP midpoints and egresses. It also could pro- 88 duce an unwieldy number of replies back to the root. 90 One alternative would be to begin sending pings from points at or 91 near the affected egress(es) and working backwards toward the root. 92 The TTL could be held constant as say two, limiting the the number of 93 responses to the number of next-next-hops of the point where the ping 94 was initiated. 96 The above procedure does require that the root know the previous-hop 97 node to the one which was pinged on the prior iteration. This infor- 98 mation is readily available in [P2MP-TE]. This document provides a 99 means for obtaining this information for [mLDP] as well as defining a 100 means for remotely causing an MPLS echo request message to be sent 101 down a Label Switched Path (LSP) or part of an LSP. 103 While the motivaton for this document came from multicast scaling 104 concerns, its applicability may be wider. However other uses of this 105 facility are beyond the scope of this document. Further the discus- 106 sion is cauched in terms of multipoint LSPs. 108 1.1. Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [KeyWords]. 114 The term "Must Be Zero" (MBZ) is used in object descriptions for 115 reserved fields. These fields MUST be set to zero when sent and 116 ignored on receipt. 118 Based on context the terms leaf and egress are used interchangeably. 119 Egress is used where consistency with [RFC4379] was deemed appropri- 120 ate. Receiver is used in the context of receiving protocol messages. 122 [Note (to be removed after assignments occur): = to be assigned 123 by IANA] 125 2. Proxy Ping Overview 127 Two new LSP Ping messages are defined for remote pinging, the MPLS 128 proxy ping request and the MPLS proxy ping reply. 130 A remote ping operation on a P2MP LSP involves at least three LSRs; 131 in some scenarios none of these are the ingress (root) or an egress 132 (leaf) of the LSP. 134 We refer to these nodes with the following terms: 136 Initiator - the node which initiates the ping operation by sending 137 an MPLS proxy ping request message 139 Proxy LSR - the node which is the destination of the MPLS proxy 140 request message and potential initiator of the MPLS 141 echo request 143 Receiver(s) - the receivers of the MPLS echo request messages 145 The initiator formats an MPLS proxy ping request message and sends it 146 to the proxy LSR, a node it believes to be on the path of the LSP. 147 This message specifies the MPLS echo request to be sent inband of the 148 LSP. It may also request the proxy LSR to acknowledge the receipt of 149 the proxy ping request message and/or respond with the address of the 150 previous hop, i.e. the LSR upstream of it on this LSP. 152 The proxy LSR validates that it has a label mapping for the specified 153 FEC and that it is authorized to send the specified MPLS echo request 154 on behalf of the initiator. Depending on the Reply Mode carried in 155 the header of the proxy ping request message and the above results an 156 MPLS remote echo reply message might be sent back to the initiator. 157 This message may also communicate the address of the previous hop. 159 If the proxy LSR has a label mapping for the FEC and and all autho- 160 rization check have passed, the proxy LSR formats an MPLS echo 161 request. If the source address of the IP packet is not the initia- 162 tor, it includes a Reply-to Address object containing the initiator's 163 address. It then sends it inband of the LSP. 165 The receivers process the MPLS echo request as normal, sending their 166 MPLS echo replies back to the initiator. 168 3. Remote Echo / Reply Pprocedures 170 3.1. Procedures for the initiator 172 The initiator creates an MPLS proxy ping request message. 174 The message MUST contain a Target FEC Stack that describes the FEC 175 being tested. 177 [Note for the current version of the ID, the FEC stack is limited to 178 a single FEC as we have not yet fully considered the operational and 179 security impacts of permitting more FECs] 181 The message MUST contain a Proxy Echo Parameters object. The address 182 type is set to either IPv4 or IPv6. The Destination IP Address is 183 set to the value to be used in the MPLS echo request packet. If the 184 Address Type is IPv4, an address from the range 127/8. If the 185 Address Type is IPv6, an address from the range 186 0:0:0:0:0:FFFF:127/104. By default the source address will be set to 187 an address of the proxy LSR. 189 The Reply mode and Global Flags of the Proxy Echo Parameters object 190 are set to the values to be used in the MPLS echo request message 191 header. The Source UDP Port is set to the value to be used in the 192 MPLS echo request packet. The TTL is set to the value to be used in 193 the outgoing MPLS label stack. See section 5.2.2.2 for further 194 details. 196 Flags MAY be set to request the previous hop address and/or a down- 197 stream mapping object from the proxy LSR. 199 A list of Next Hop IP Addresses MAY be included to limit the next 200 hops towards which the MPLS echo request message will be sent. 202 Any of following objects MAY be included; these objects will be 203 copied into the MPLS echo request messages: 205 Pad 206 Vendor Enterprise Number 207 Reply TOS Byte 208 P2MP Egress Identifier [McstPing] 209 Echo Jitter TLV [McstPing] 210 Vendor Private TLVs 212 Downstream Mapping objects MAY be included. These objects will be 213 matched to the next hop address for inclusion in those particular 214 MPLS echo request messages. 216 The message is then encapsulated in a UDP packet. The source UDP 217 port is chosen by the sender; the destination UDP port is set to 218 3503. The IP header is set as follows: the source IP address is a 219 routable address of the sender; the destination IP address is a 220 routable address of the midpoint. The packet is then sent with the 221 IP TTL is set to 255. 223 3.2. Procedures for the proxy LSR 225 A proxy LSR that receives an MPLS proxy ping request message, parses 226 the packet to ensure that it is a well-formed packet. It checks that 227 the TLVs that are not marked "Ignore" are understood. If not, it 228 sets the Return Code set to "Malformed echo request received" or "TLV 229 not understood" (as appropriate), and the Subcode set to zero. If 230 the Reply Mode of the message header is not 0, an MPLS proxy ping 231 reply message SHOULD be sent as described below. In the latter case, 232 the misunderstood TLVs (only) are included in an Errored TLVs object. 234 The header fields Sender's Handle and Sequence Number are not exam- 235 ined, but are saved to be included in the MPLS proxy ping reply and 236 MPLS echo request messages. 238 The proxy LSR validates that it has a label mapping for the specified 239 FEC, it then determines if it is an egress, transit or bud node and 240 sets the Return Code as appropriate. 242 The proxy LSR then determines if it is authorized to send the speci- 243 fied MPLS echo request on behalf of the initiator. An LSR MUST be 244 capable of filtering addresses to validate initiators. Other filters 245 on FECs or MPLS echo request contents MAY be applied. If a filter 246 has been invoked (i.e. configured) and an address does not pass the 247 filter, then an MPLS echo request message MUST NOT be sent, and the 248 event SHOULD be logged. An MPLS proxy ping reply message may be sent 249 with a Return Code of , "Remote Ping not authorized". 251 If the "Request for Previous Hop" flag is set, a Previous Hop Address 252 Object is formatted for inclusion in the MPLS proxy ping reply. If 253 the previous HOP is unknown or ambiguous the Address Type is set to 254 "No Address Supplied". 256 If there is a list of Next Hop addresses in the Proxy Echo Parameters 257 object, each address is examined to determine if it is a next hop for 258 this FEC. If any are not, those addresses are deleted from the list. 259 The updated Proxy Echo Parameters object is included in the MPLS 260 proxy ping reply. 262 If the "Request for Downstream Mapping" flag is set the LSR formats a 263 Downstream Mapping object for each interface that the MPLS echo 264 request will be sent out. 266 If the Reply Mode of the message header is not 0 or 5, an MPLS remote 267 echo reply message SHOULD be sent as described below. 269 3.2.1. Sending an MPLS proxy ping reply 271 The Reply mode, Sender's Handle and Sequence Number fields are copied 272 from the proxy ping request message. Various objects are included as 273 specified above. The message is encapsulated in a UDP packet. The 274 source IP address is a routable address of the proxy LSR; the source 275 port is the well-known UDP port for LSP ping. The destination IP 276 address and UDP port are copied from the source IP address and UDP 277 port of the echo request. The IP TTL is set to 255. 279 3.2.2. Sending the MPLS echo requests 281 A base MPLS echo request is formed as decribed in the next section. 282 The section below that describes how the base MPLS echo request is 283 sent on each interface. 285 3.2.2.1. Forming the base MPLS echo request 287 A Next_Hop_List is created as follows. If Next Hop addresses were 288 included in the received Proxy Parameters object, the Next_Hop_List 289 is copied from the Proxy Echo Parameters object as adjusted above. 290 Otherwise, the list is set to all the next hops to which the FEC 291 would be forwarded. 293 The proxy LSR then formats an MPLS echo request message. The Global 294 Flags and Reply Mode are copied from the Proxy Echo Parameters 295 object. The Return Code and Return Subcode are set to zero. 297 The Sender's Handle and Sequence Number are copied from the remote 298 echo request message. 300 The TimeStamp Sent is set to the time-of-day (in seconds and 301 microseconds) that the echo request is sent. The TimeStamp Received 302 is set to zero. 304 A Reply-to Address object containing the initiator's address is 305 included. 307 The following objects are copied from the MPLS proxy ping request 308 message. Note that of these, only the Target FEC Stack is REQUIRED 309 to appear in the MPLS proxy ping request message. 311 Target FEC Stack 312 Pad 313 Vendor Enterprise Number 314 Reply TOS Byte 315 P2MP Egress Identifier [McstPing] 316 Echo Jitter TLV [McstPing] 317 Vendor Private TLVs 319 The message is then encapsulated in a UDP packet. The source UDP 320 port is copied from the Proxy Echo Parameters object. destination 321 ports are copied from the proxy ping request message. 323 The source IP address is set to a routable address of the proxy LSR. 324 Per usual the TTL of the IP packet is set to 1. 326 3.2.2.2. Per interface sending procedures 328 The proxy LSR now iterates through the Next_Hop_List modifying the 329 base MPLS echo request to form the MPLS echo request packet which is 330 then sent on that particular interface. 332 For each next hop address, the outgoing label stack is determained. 333 The TTL for the label corresponding to the FEC in the FEC stack is 334 set such that the TTL on the wire will be one less than the TTL spec- 335 ified in the proxy ping request message. If any additional labels 336 are pushed onto the stack, their TTLs are set to 255. 338 If the MPLS proxy ping request message contained Downstream Mapping 339 objects, they are examined. If the Downstream IP Address matches the 340 next hop address that Downstream Mapping object is included in the 341 MPLS echo request. 343 The packet is then transmitted on this interface. 345 4. Proxy Ping Request / Reply Messages 347 Two new LSP Ping messages are defined for remote pinging, the MPLS 348 proxy ping request message and the MPLS proxy ping reply. 350 4.1. Proxy Ping Request / Reply Message formats 352 Except where noted, the definitions of all fields in the messages are 353 identical to those found in [LSP-PING]. The messages have the fol- 354 lowing format: 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Version Number | MUST Be Zero | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Message Type | Reply mode | Return Code | Return Subcode| 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Sender's Handle | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Sequence Number | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | TLVs ... | 368 . . 369 . . 370 . . 371 | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Version Number 376 The Version Number is currently 1. (Note: the Version Number is 377 to be incremented whenever a change is made that affects the 378 ability of an implementation to correctly parse or process an 379 MPLS echo request/reply. These changes include any syntactic or 380 semantic changes made to any of the fixed fields, or to any TLV 381 or sub-TLV assignment or format that is defined at a certain 382 version number. The Version Number may not need to be changed 383 if an optional TLV or sub-TLV is added.) 385 Message Type 387 Type Message 388 ---- ------- 389 5 MPLS proxy ping request 390 6 MPLS proxy ping reply 392 Reply mode 394 The reply modes are the same as [LSP-PING] with the addtion of 395 value 5. For completeness, the full list of reply modes 396 follows: 398 Value Meaning 399 ----- ------- 400 1 Do not reply 401 2 Reply via an IPv4/IPv6 UDP packet 402 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 403 4 Reply via application level control channel 404 5 Reply via an IPv4/IPv6 UDP packet only if the proxy 405 request is not fulfilled 407 4.2. Proxy Ping Request Message contents 409 The MPLS proxy ping request message MAY contain the following 410 objects: 412 Type Object 413 ---- ----------- 414 1 Target FEC Stack 415 2 Downstream Mapping 416 3 Pad 417 5 Vendor Enterprise Number 418 10 Reply TOS Byte 419 tba Proxy Echo Parameters 420 tba P2MP Egress Identifier [McstPing] 421 tba Echo Jitter TLV [McstPing] 422 Vendor Private TLVs 424 4.3. Proxy Ping Reply Message Contents 426 The MPLS proxy ping reply message MAY contain the following objects: 428 Type Object 429 ---- ----------- 430 1 Target FEC Stack 431 2 Downstream Mapping 432 5 Vendor Enterprise Number 433 9 Errored TLVs 434 tba Proxy Echo Parameters 435 tba Previous Hop Address 436 Vendor Private objects 438 5. Object formats 440 5.1. Proxy Echo Parameters Object 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 | Address Type | Flags | Reply mode | TTL | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Source UDP Port | Global Flags | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 : Destination IP Address : 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | 454 : : 455 : Next Hop IP Addresses : 456 : : 457 | | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Address Type 462 The type of address found in the in the Destination IP Address 463 and Next Hop IP Addresses fields. The type codes appear in the 464 table below: 466 Address Family Type 468 IPv4 Numbered 1 469 IPv6 Numbered 3 471 Flags 473 Request for Previous Hop 0x01 475 When set this requests that the proxy LSR supply the previous hop 476 address in the MPLS proxy ping reply message 478 Request for Downstream Mapping 0x02 480 When set this requests that the proxy LSR supply a 481 Downstream Mapping object in the MPLS proxy ping reply 482 message 484 Reply mode 486 The reply mode to be sent in the MPLS Echo Request message; the 487 values are as specified in [RFC4379] 489 TTL 491 The TTL to be used in the label corresponding to the FEC in the 492 MPLS Echo Request packet 494 Source UDP Port 496 The source UDP port to be sent in the MPLS Echo Request packet 498 Global Flags 500 The Global Flags to be sent in the MPLS Echo Request messge 502 Destination IP Address 504 If the Address Type is IPv4, an address from the range 127/8; 505 If the Address Type is IPv6, an address from the range 506 0:0:0:0:0:FFFF:127/104 508 Next Hop IP Addresses 510 A list of next hop address that the echo request message is to 511 be sent towards 513 5.2. Reply-to Address Object 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Address Type | MUST be Zero | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | | 519 : Reply-to Address : 520 | | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Address Type 524 A type code as specified in the table below: 526 Type Type of Address 528 1 IPv4 529 3 IPv6 531 5.3. Previous Hop Address Object 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Address Type | MUST be Zero | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | | 537 : Previous Hop Address : 538 | | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Address Type 543 A type code as specified in the table below: 545 Type Type of Address 547 0 No Address Supplied 548 1 IPv4 549 3 IPv6 551 6. Security Considerations 553 [To be written] 555 7. IANA Considerations 557 [Not complete] 559 7.1. Message and Object Type Assignments 561 This document makes the following codepoint assigments (pending IANA 562 action): 564 Registry Codepoint Purpose 566 LSP Ping Message Type tba MPLS proxy ping request message 567 tba MPLS proxy ping reply 569 LSP Ping Object Type tba Proxy Echo Parameters 570 tba Reply-to Address 571 tba Previous Hop Address 573 7.2. Return Code Assignments 575 Value Meaning 577 tba Remote Ping not authorized 579 8. Acknowledgments 581 9. References 583 9.1. Normative References 585 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 586 Label Switched (MPLS) Data Plane Failures", RFC 4379, 587 February 2006. 589 [KeyWords] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, March 1997. 592 [McstPing] Farrel, A. et al, "Detecting Data Plane Failures in 593 Point-to-Multipoint MPLS Traffic Engineering - 594 Extensions to LSP Ping", 595 draft-ietf-mpls-p2mp-lsp-ping-02.txt, September 2006. 597 9.2. Informative References 599 [P2MP-TE] Aggarwal, R., et al., "Extensions to RSVP-TE for 600 Point-to-Multipoint TE LSPs", 601 draft-ietf-mpls-rsvp-te-p2mp-07.txt, January 2007. 603 [mLDP] Minei, I., et. al., "Label Distribution Protocol 604 Extensions for Point-to-Multipoint and 605 Multipoint-to-Multipoint Label Switched Paths" 606 draft-ietf-mpls-ldp-p2mp-02.txt, October 2006. 608 10. Authors' Addresses 610 George Swallow 611 Cisco Systems, Inc. 612 1414 Massachusetts Ave 613 Boxborough, MA 01719 615 Email: swallow@cisco.com 617 Vanson Lim 618 Cisco Systems, Inc. 619 1414 Massachusetts Ave 620 Boxborough, MA 01719 622 Email: vlim@cisco.com 624 Intellectual Property 626 The IETF takes no position regarding the validity or scope of any 627 Intellectual Property Rights or other rights that might be claimed to 628 pertain to the implementation or use of the technology described in 629 this document or the extent to which any license under such rights 630 might or might not be available; nor does it represent that it has 631 made any independent effort to identify any such rights. Information 632 on the procedures with respect to rights in RFC documents can be 633 found in BCP 78 and BCP 79. 635 Copies of IPR disclosures made to the IETF Secretariat and any assur- 636 ances of licenses to be made available, or the result of an attempt 637 made to obtain a general license or permission for the use of such 638 proprietary rights by implementers or users of this specification can 639 be obtained from the IETF on-line IPR repository at 640 http://www.ietf.org/ipr. 642 The IETF invites any interested party to bring to its attention any 643 copyrights, patents or patent applications, or other proprietary 644 rights that may cover technology that may be required to implement 645 this standard. Please address the information to the IETF at ietf- 646 ipr@ietf.org. 648 Full Copyright Notice 650 Copyright (C) The IETF Trust (2007). This document is subject to the 651 rights, licenses and restrictions contained in BCP 78, and except as 652 set forth therein, the authors retain all their rights. 654 This document and the information contained herein are provided on an 655 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 656 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 657 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 658 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 659 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 660 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.