idnits 2.17.1 draft-swallow-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 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 631. ** 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 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 548 has weird spacing: '...ge Type tba ...' == Line 551 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 (March 2007) is 6251 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 393, but not defined ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-lsr-self-test-06 == Outdated reference: A later version (-18) exists of draft-ietf-mpls-p2mp-lsp-ping-02 Summary: 4 errors (**), 0 flaws (~~), 7 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: September 2007 6 Vanson Lim 7 Cisco Systems, Inc. 9 March 2007 11 Proxy LSP Ping 13 draft-swallow-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 Previous Hop Object ....................................... 13 65 6 Security Considerations ................................... 13 66 7 IANA Considerations ....................................... 13 67 7.1 Message and Object Type Assignments ....................... 13 68 7.2 Return Code Assignments ................................... 14 69 8 Acknowledgments ........................................... 14 70 9 References ................................................ 14 71 9.1 Normative References ...................................... 14 72 9.2 Informative References .................................... 14 73 10 Authors' Addresses ........................................ 15 74 1. Introduction 76 It is anticipated that very large Point-to-Multipoint (P2MP) Label 77 Switched Paths (LSPs) will exist. Further it is anticipated that 78 many of the applications for P2MP tunnels will require OAM that is 79 both rigorous and scalable. 81 Suppose one wishes to trace a P2MP LSP to localize a fault which is 82 affecting one egress or a set of egresses. Suppose one follows the 83 normal procedure for tracing - namely repeatedly pinging from the 84 root, incrementing the TTL by one after each three or so pings. Such 85 a procedure has the potential for producing a large amount of pro- 86 cessing at the P2MP-LSP midpoints and egresses. It also could pro- 87 duce an unwieldy number of replies back to the root. 89 One alternative would be to begin sending pings from points at or 90 near the affected egress(es) and working backwards toward the root. 91 The TTL could be held constant as say two, limiting the the number of 92 responses to the number of next-next-hops of the point where the ping 93 was initiated. 95 The above procedure does require that the root know the previous-hop 96 node to the one which was pinged on the prior iteration. This infor- 97 mation is readily available in [P2MP-TE]. This document provides a 98 means for obtaining this information for [mLDP] as well as defining a 99 means for remotely causing an MPLS echo request message to be sent 100 down a Label Switched Path (LSP) or part of an LSP. 102 While the motivaton for this document came from multicast scaling 103 concerns, its applicability may be wider. However other uses of this 104 facility are beyond the scope of this document. Further the discus- 105 sion is cauched in terms of multipoint LSPs. 107 1.1. Conventions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [KeyWords]. 113 The term "Must Be Zero" (MBZ) is used in object descriptions for 114 reserved fields. These fields MUST be set to zero when sent and 115 ignored on receipt. 117 Based on context the terms leaf and egress are used interchangeably. 118 Egress is used where consistency with [RFC4379] was deemed appropri- 119 ate. Receiver is used in the context of receiving protocol messages. 121 [Note (to be removed after assignments occur): = to be assigned 122 by IANA] 124 2. Proxy Ping Overview 126 Two new LSP Ping messages are defined for remote pinging, the MPLS 127 proxy ping request and the MPLS proxy ping reply. 129 A remote ping operation on a P2MP LSP involves at least three LSRs; 130 in some scenarios none of these are the ingress (root) or an egress 131 (leaf) of the LSP. 133 We refer to these nodes with the following terms: 135 Initiator - the node which initiates the ping operation by sending 136 an MPLS proxy ping request message 138 Proxy LSR - the node which is the destination of the MPLS proxy 139 request message and potential initiator of the MPLS 140 echo request 142 Receiver(s) - the receivers of the MPLS echo request messages 144 The initiator formats an MPLS proxy ping request message and sends it 145 to the proxy LSR, a node it believes to be on the path of the LSP. 146 This message specifies the MPLS echo request to be sent inband of the 147 LSP. It may also request the proxy LSR to acknowledge the receipt of 148 the proxy ping request message and/or respond with the address of the 149 previous hop, i.e. the LSR upstream of it on this LSP. 151 The proxy LSR validates that it has a label mapping for the specified 152 FEC and that it is authorized to send the specified MPLS echo request 153 on behalf of the initiator. Depending on the Reply Mode carried in 154 the header of the proxy ping request message and the above results an 155 MPLS remote echo reply message might be sent back to the initiator. 156 This message may also communicate the address of the previous hop. 158 If the proxy LSR has a label mapping for the FEC and and all autho- 159 rization check have passed, the proxy LSR formats an MPLS echo 160 request. If the source address of the IP packet is not the initia- 161 tor, it includes a ReplyTo object containing the initiator's address. 162 It then sends it inband of the LSP. 164 The receivers process the MPLS echo request as normal, sending their 165 MPLS echo replies back to the initiator. 167 3. Remote Echo / Reply Pprocedures 169 3.1. Procedures for the initiator 171 The initiator creates an MPLS proxy ping request message. 173 The message MUST contain a Target FEC Stack that describes the FEC 174 being tested. 176 [Note for the current version of the ID, the FEC stack is limited to 177 a single FEC as we have not yet fully considered the operational and 178 security impacts of permitting more FECs] 180 The message MUST contain a Proxy Echo Parameters object. The address 181 type is set to either IPv4 or IPv6. The Destination IP Address is 182 set to the value to be used in the MPLS echo request packet. If the 183 Address Type is IPv4, an address from the range 127/8. If the 184 Address Type is IPv6, an address from the range 185 0:0:0:0:0:FFFF:127/104. By default the source address will be set to 186 an address of the proxy LSR. 188 The Reply mode and Global Flags of the Proxy Echo Parameters object 189 are set to the values to be used in the MPLS echo request message 190 header. The Source UDP Port is set to the value to be used in the 191 MPLS echo request packet. The TTL is set to the value to be used in 192 the outgoing MPLS label stack. See section 5.2.2.2 for further 193 details. 195 Flags MAY be set to request the previous hop address and/or a down- 196 stream mapping object from the proxy LSR. 198 A list of Next Hop IP Addresses MAY be included to limit the next 199 hops towards which the MPLS echo request message will be sent. 201 Any of following objects MAY be included; these objects will be 202 copied into the MPLS echo request messages: 204 Pad 205 Vendor Enterprise Number 206 Reply TOS Byte 207 P2MP Egress Identifier [McstPing] 208 Echo Jitter TLV [McstPing] 209 Vendor Private TLVs 211 Downstream Mapping objects MAY be included. These objects will be 212 matched to the next hop address for inclusion in those particular 213 MPLS echo request messages. 215 The message is then encapsulated in a UDP packet. The source UDP 216 port is chosen by the sender; the destination UDP port is set to 217 3503. The IP header is set as follows: the source IP address is a 218 routable address of the sender; the destination IP address is a 219 routable address of the midpoint. The packet is then sent with the 220 IP TTL is set to 255. 222 3.2. Procedures for the proxy LSR 224 A proxy LSR that receives an MPLS proxy ping request message, parses 225 the packet to ensure that it is a well-formed packet. It checks that 226 the TLVs that are not marked "Ignore" are understood. If not, it 227 sets the Return Code set to "Malformed echo request received" or "TLV 228 not understood" (as appropriate), and the Subcode set to zero. If 229 the Reply Mode of the message header is not 0, an MPLS proxy ping 230 reply message SHOULD be sent as described below. In the latter case, 231 the misunderstood TLVs (only) are included in an Errored TLVs object. 233 The header fields Sender's Handle and Sequence Number are not exam- 234 ined, but are saved to be included in the MPLS proxy ping reply and 235 MPLS echo request messages. 237 The proxy LSR validates that it has a label mapping for the specified 238 FEC, it then determines if it is an egress, transit or bud node and 239 sets the Return Code as appropriate. 241 The proxy LSR then determines if it is authorized to send the speci- 242 fied MPLS echo request on behalf of the initiator. An LSR MUST be 243 capable of filtering addresses to validate initiators. Other filters 244 on FECs or MPLS echo request contents MAY be applied. If a filter 245 has been invoked (i.e. configured) and an address does not pass the 246 filter, then an MPLS echo request message MUST NOT be sent, and the 247 event SHOULD be logged. An MPLS proxy ping reply message may be sent 248 with a Return Code of , "Remote Ping not authorized". 250 If the "Request for Previous Hop" flag is set, a PHOP Address Object 251 is formatted for inclusion in the MPLS proxy ping reply. If the pre- 252 vious HOP is unknown or ambiguous the Address Type is set to "No 253 Address Supplied". 255 If there is a list of Next Hop addresses in the Proxy Echo Parameters 256 object, each address is examined to determine if it is a next hop for 257 this FEC. If any are not, those addresses are deleted from the list. 258 The updated Proxy Echo Parameters object is included in the MPLS 259 proxy ping reply. 261 If the "Request for Downstream Mapping" flag is set the LSR formats a 262 Downstream Mapping object for each interface that the MPLS echo 263 request will be sent out. 265 If the Reply Mode of the message header is not 0 or 5, an MPLS remote 266 echo reply message SHOULD be sent as described below. 268 3.2.1. Sending an MPLS proxy ping reply 270 The Reply mode, Sender's Handle and Sequence Number fields are copied 271 from the proxy ping request message. Various objects are included as 272 specified above. The message is encapsulated in a UDP packet. The 273 source IP address is a routable address of the proxy LSR; the source 274 port is the well-known UDP port for LSP ping. The destination IP 275 address and UDP port are copied from the source IP address and UDP 276 port of the echo request. The IP TTL is set to 255. 278 3.2.2. Sending the MPLS echo requests 280 A base MPLS echo request is formed as decribed in the next section. 281 The section below that describes how the base MPLS echo request is 282 sent on each interface. 284 3.2.2.1. Forming the base MPLS echo request 286 A Next_Hop_List is created as follows. If Next Hop addresses were 287 included in the received Proxy Parameters object, the Next_Hop_List 288 is copied from the Proxy Echo Parameters object as adjusted above. 289 Otherwise, the list is set to all the next hops to which the FEC 290 would be forwarded. 292 The proxy LSR then formats an MPLS echo request message. The Global 293 Flags and Reply Mode are copied from the Proxy Echo Parameters 294 object. The Return Code and Return Subcode are set to zero. 296 The Sender's Handle and Sequence Number are copied from the remote 297 echo request message. 299 The TimeStamp Sent is set to the time-of-day (in seconds and 300 microseconds) that the echo request is sent. The TimeStamp Received 301 is set to zero. 303 A ReplyTo object (see [SelfTest]) containing the initiator's address 304 is included. 306 The following objects are copied from the MPLS proxy ping request 307 message. Note that of these, only the Target FEC Stack is REQUIRED 308 to appear in the MPLS proxy ping request message. 310 Target FEC Stack 311 Pad 312 Vendor Enterprise Number 313 Reply TOS Byte 314 P2MP Egress Identifier [McstPing] 315 Echo Jitter TLV [McstPing] 316 Vendor Private TLVs 318 The message is then encapsulated in a UDP packet. The source UDP 319 port is copied from the Proxy Echo Parameters object. destination 320 ports are copied from the proxy ping request message. 322 The source IP address is set to a routable address of the proxy LSR. 323 Per usual the TTL of the IP packet is set to 1. 325 3.2.2.2. Per interface sending procedures 327 The proxy LSR now iterates through the Next_Hop_List modifying the 328 base MPLS echo request to form the MPLS echo request packet which is 329 then sent on that particular interface. 331 For each next hop address, the outgoing label stack is determained. 332 The TTL for the label corresponding to the FEC in the FEC stack is 333 set such that the TTL on the wire will be one less than the TTL spec- 334 ified in the proxy ping request message. If any additional labels 335 are pushed onto the stack, their TTLs are set to 255. 337 If the MPLS proxy ping request message contained Downstream Mapping 338 objects, they are examined. If the Downstream IP Address matches the 339 next hop address that Downstream Mapping object is included in the 340 MPLS echo request. 342 The packet is then transmitted on this interface. 344 4. Proxy Ping Request / Reply Messages 346 Two new LSP Ping messages are defined for remote pinging, the MPLS 347 proxy ping request message and the MPLS proxy ping reply. 349 4.1. Proxy Ping Request / Reply Message formats 351 Except where noted, the definitions of all fields in the messages are 352 identical to those found in [LSP-PING]. The messages have the fol- 353 lowing format: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Version Number | MUST Be Zero | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Message Type | Reply mode | Return Code | Return Subcode| 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Sender's Handle | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Sequence Number | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | TLVs ... | 367 . . 368 . . 369 . . 370 | | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Version Number 375 The Version Number is currently 1. (Note: the Version Number is 376 to be incremented whenever a change is made that affects the 377 ability of an implementation to correctly parse or process an 378 MPLS echo request/reply. These changes include any syntactic or 379 semantic changes made to any of the fixed fields, or to any TLV 380 or sub-TLV assignment or format that is defined at a certain 381 version number. The Version Number may not need to be changed 382 if an optional TLV or sub-TLV is added.) 384 Message Type 386 Type Message 387 ---- ------- 388 5 MPLS proxy ping request 389 6 MPLS proxy ping reply 391 Reply mode 393 The reply modes are the same as [LSP-PING] with the addtion of 394 value 5. For completeness, the full list of reply modes 395 follows: 397 Value Meaning 398 ----- ------- 399 1 Do not reply 400 2 Reply via an IPv4/IPv6 UDP packet 401 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 402 4 Reply via application level control channel 403 5 Reply via an IPv4/IPv6 UDP packet only if the proxy 404 request is not fulfilled 406 4.2. Proxy Ping Request Message contents 408 The MPLS proxy ping request message MAY contain the following 409 objects: 411 Type Object 412 ---- ----------- 413 1 Target FEC Stack 414 2 Downstream Mapping 415 3 Pad 416 5 Vendor Enterprise Number 417 10 Reply TOS Byte 418 tba Proxy Echo Parameters 419 tba PHOP Address 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 PHOP 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 PHOP 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. Previous Hop Object 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Address Type | MUST be Zero | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | | 519 : Previous Hop IP Address : 520 | | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Address Type 525 A type code as specified in the table below: 527 Type Type of Address 529 0 No Address Supplied 530 1 IPv4 531 3 IPv6 533 6. Security Considerations 535 [To be written] 537 7. IANA Considerations 539 [Not complete] 541 7.1. Message and Object Type Assignments 543 This document makes the following codepoint assigments (pending IANA 544 action): 546 Registry Codepoint Purpose 548 LSP Ping Message Type tba MPLS proxy ping request message 549 tba MPLS proxy ping reply 551 LSP Ping Object Type tba Proxy Echo Parameters 552 tba PHOP Address 554 7.2. Return Code Assignments 556 Value Meaning 558 tba Remote Ping not authorized 559 tba Failed Next Hops 561 8. Acknowledgments 563 9. References 565 9.1. Normative References 567 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 568 Label Switched (MPLS) Data Plane Failures", RFC 4379, 569 February 2006. 571 [SelfTest] Swallow, G. et al., "LSR Self Test", 572 draft-ietf-mpls-lsr-self-test-06.txt, October 2005. 574 [KeyWords] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, March 1997. 577 [McstPing] Farrel, A. et al, "Detecting Data Plane Failures in 578 Point-to-Multipoint MPLS Traffic Engineering - 579 Extensions to LSP Ping", 580 draft-ietf-mpls-p2mp-lsp-ping-02.txt, September 2006. 582 9.2. Informative References 584 [P2MP-TE] Aggarwal, R., et al., "Extensions to RSVP-TE for 585 Point-to-Multipoint TE LSPs", 586 draft-ietf-mpls-rsvp-te-p2mp-07.txt, January 2007. 588 [mLDP] Minei, I., et. al., "Label Distribution Protocol 589 Extensions for Point-to-Multipoint and 590 Multipoint-to-Multipoint Label Switched Paths" 591 draft-ietf-mpls-ldp-p2mp-02.txt, October 2006. 593 10. Authors' Addresses 595 George Swallow 596 Cisco Systems, Inc. 597 1414 Massachusetts Ave 598 Boxborough, MA 01719 600 Email: swallow@cisco.com 602 Vanson Lim 603 Cisco Systems, Inc. 604 1414 Massachusetts Ave 605 Boxborough, MA 01719 607 Email: vlim@cisco.com 609 Intellectual Property 611 The IETF takes no position regarding the validity or scope of any 612 Intellectual Property Rights or other rights that might be claimed to 613 pertain to the implementation or use of the technology described in 614 this document or the extent to which any license under such rights 615 might or might not be available; nor does it represent that it has 616 made any independent effort to identify any such rights. Information 617 on the procedures with respect to rights in RFC documents can be 618 found in BCP 78 and BCP 79. 620 Copies of IPR disclosures made to the IETF Secretariat and any assur- 621 ances of licenses to be made available, or the result of an attempt 622 made to obtain a general license or permission for the use of such 623 proprietary rights by implementers or users of this specification can 624 be obtained from the IETF on-line IPR repository at 625 http://www.ietf.org/ipr. 627 The IETF invites any interested party to bring to its attention any 628 copyrights, patents or patent applications, or other proprietary 629 rights that may cover technology that may be required to implement 630 this standard. Please address the information to the IETF at ietf- 631 ipr@ietf.org. 633 Full Copyright Notice 635 Copyright (C) The IETF Trust (2007). This document is subject to the 636 rights, licenses and restrictions contained in BCP 78, and except as 637 set forth therein, the authors retain all their rights. 639 This document and the information contained herein are provided on an 640 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 641 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 642 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 643 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 644 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 645 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.