idnits 2.17.1 draft-ietf-mpls-remote-lsp-ping-02.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 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 730. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 736. 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 19 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 481 has weird spacing: '...pear in the t...' == Line 658 has weird spacing: '...ge Type tba ...' == Line 661 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 (July 14, 2008) is 5758 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 405, 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-06 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 7 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: January 2009 6 Vanson Lim 7 Cisco Systems, Inc. 9 July 14, 2008 11 Proxy LSP Ping 13 draft-ietf-mpls-remote-lsp-ping-02.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 Proxy MPLS Echo Request / 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 ....................... 9 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 ......................... 11 62 5 Object formats ............................................ 11 63 5.1 Proxy Echo Parameters Object .............................. 11 64 5.1.1 Next Hop sub-Object ....................................... 13 65 5.2 Reply-to Address Object ................................... 14 66 5.3 Previous Hop Address Object ............................... 15 67 6 Security Considerations ................................... 16 68 7 IANA Considerations ....................................... 16 69 7.1 Message and Object Type Assignments ....................... 16 70 7.2 Return Code Assignments ................................... 17 71 8 References ................................................ 17 72 8.1 Normative References ...................................... 17 73 8.2 Informative References .................................... 17 74 9 Authors' Addresses ........................................ 18 76 1. Introduction 78 It is anticipated that very large Point-to-Multipoint (P2MP) Label 79 Switched Paths (LSPs) will exist. Further it is anticipated that 80 many of the applications for P2MP tunnels will require OAM that is 81 both rigorous and scalable. 83 Suppose one wishes to trace a P2MP LSP to localize a fault which is 84 affecting one egress or a set of egresses. Suppose one follows the 85 normal procedure for tracing - namely repeatedly pinging from the 86 root, incrementing the TTL by one after each three or so pings. Such 87 a procedure has the potential for producing a large amount of pro- 88 cessing at the P2MP-LSP midpoints and egresses. It also could pro- 89 duce an unwieldy number of replies back to the root. 91 One alternative would be to begin sending pings from points at or 92 near the affected egress(es) and working backwards toward the root. 93 The TTL could be held constant as say two, limiting the the number of 94 responses to the number of next-next-hops of the point where the ping 95 was initiated. 97 The above procedure does require that the root know the previous-hop 98 node to the one which was pinged on the prior iteration. This infor- 99 mation is readily available in [P2MP-TE]. This document provides a 100 means for obtaining this information for [mLDP] as well as defining a 101 means for remotely causing an MPLS echo request message to be sent 102 down a Label Switched Path (LSP) or part of an LSP. 104 While the motivaton for this document came from multicast scaling 105 concerns, its applicability may be wider. However other uses of this 106 facility are beyond the scope of this document. Further the discus- 107 sion is cauched in terms of multipoint LSPs. 109 1.1. Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [KeyWords]. 115 The term "Must Be Zero" (MBZ) is used in object descriptions for 116 reserved fields. These fields MUST be set to zero when sent and 117 ignored on receipt. 119 Based on context the terms leaf and egress are used interchangeably. 120 Egress is used where consistency with [RFC4379] was deemed appropri- 121 ate. Receiver is used in the context of receiving protocol messages. 123 [Note (to be removed after assignments occur): = to be assigned 124 by IANA] 126 2. Proxy Ping Overview 128 Two new LSP Ping messages are defined for remote pinging, the MPLS 129 proxy ping request and the MPLS proxy ping reply. 131 A remote ping operation on a P2MP LSP involves at least three LSRs; 132 in some scenarios none of these are the ingress (root) or an egress 133 (leaf) of the LSP. 135 We refer to these nodes with the following terms: 137 Initiator - the node which initiates the ping operation by sending 138 an MPLS proxy ping request message 140 Proxy LSR - the node which is the destination of the MPLS proxy 141 request message and potential initiator of the MPLS 142 echo request 144 Receiver(s) - the receivers of the MPLS echo request messages 146 The initiator formats an MPLS proxy ping request message and sends it 147 to the proxy LSR, a node it believes to be on the path of the LSP. 148 This message specifies the MPLS echo request to be sent inband of the 149 LSP. It may also request the proxy LSR to acknowledge the receipt of 150 the proxy ping request message and/or respond with the address of the 151 previous hop, i.e. the LSR upstream of it on this LSP. 153 The proxy LSR validates that it has a label mapping for the specified 154 FEC and that it is authorized to send the specified MPLS echo request 155 on behalf of the initiator. Depending on the Reply Mode carried in 156 the header of the proxy ping request message and the above results an 157 MPLS remote echo reply message might be sent back to the initiator. 158 This message may also communicate the address of the previous hop. 160 If the proxy LSR has a label mapping for the FEC and and all autho- 161 rization check have passed, the proxy LSR formats an MPLS echo 162 request. If the source address of the IP packet is not the initia- 163 tor, it includes a Reply-to Address object containing the initiator's 164 address. It then sends it inband of the LSP. 166 The receivers process the MPLS echo request as normal, sending their 167 MPLS echo replies back to the initiator. 169 3. Proxy MPLS Echo Request / Reply Pprocedures 171 3.1. Procedures for the initiator 173 The initiator creates an MPLS proxy ping request message. 175 The message MUST contain a Target FEC Stack that describes the FEC 176 being tested. 178 [Note for the current version of the ID, the FEC stack is limited to 179 a single FEC as we have not yet fully considered the operational and 180 security impacts of permitting more FECs] 182 The message MUST contain a Proxy Echo Parameters object. The address 183 type is set to either IPv4 or IPv6. The Destination IP Address is 184 set to the value to be used in the MPLS echo request packet. If the 185 Address Type is IPv4, an address from the range 127/8. If the 186 Address Type is IPv6, an address from the range 187 0:0:0:0:0:FFFF:127/104. By default the source address will be set to 188 an address of the proxy LSR. 190 The Reply mode and Global Flags of the Proxy Echo Parameters object 191 are set to the values to be used in the MPLS echo request message 192 header. The Source UDP Port is set to the value to be used in the 193 MPLS echo request packet. The TTL is set to the value to be used in 194 the outgoing MPLS label stack. See section 5.2.2.2 for further 195 details. 197 Flags MAY be set to request the previous hop address and/or a down- 198 stream mapping object from the proxy LSR. 200 A list of Next Hop IP Addresses MAY be included to limit the next 201 hops towards which the MPLS echo request message will be sent. 203 Any of following objects MAY be included; these objects will be 204 copied into the MPLS echo request messages: 206 Pad 207 Vendor Enterprise Number 208 Reply TOS Byte 209 P2MP Egress Identifier [McstPing] 210 Echo Jitter TLV [McstPing] 211 Vendor Private TLVs 213 Downstream Mapping objects MAY be included. These objects will be 214 matched to the next hop address for inclusion in those particular 215 MPLS echo request messages. 217 The message is then encapsulated in a UDP packet. The source UDP 218 port is chosen by the sender; the destination UDP port is set to 219 3503. The IP header is set as follows: the source IP address is a 220 routable address of the sender; the destination IP address is a 221 routable address of the midpoint. The packet is then sent with the 222 IP TTL is set to 255. 224 3.2. Procedures for the proxy LSR 226 A proxy LSR that receives an MPLS proxy ping request message, parses 227 the packet to ensure that it is a well-formed packet. It checks that 228 the TLVs that are not marked "Ignore" are understood. If not, it 229 sets the Return Code set to "Malformed echo request received" or "TLV 230 not understood" (as appropriate), and the Subcode set to zero. If 231 the Reply Mode of the message header is not 1, an MPLS proxy ping 232 reply message SHOULD be sent as described below. In the latter case, 233 the misunderstood TLVs (only) are included in an Errored TLVs object. 235 The header fields Sender's Handle and Sequence Number are not exam- 236 ined, but are saved to be included in the MPLS proxy ping reply and 237 MPLS echo request messages. 239 The proxy LSR validates that it has a label mapping for the specified 240 FEC, it then determines if it is an egress, transit or bud node and 241 sets the Return Code as appropriate. 243 The proxy LSR then determines if it is authorized to send the speci- 244 fied MPLS echo request on behalf of the initiator. An LSR MUST be 245 capable of filtering addresses to validate initiators. Other filters 246 on FECs or MPLS echo request contents MAY be applied. If a filter 247 has been invoked (i.e. configured) and an address does not pass the 248 filter, then an MPLS echo request message MUST NOT be sent, and the 249 event SHOULD be logged. An MPLS proxy ping reply message may be sent 250 with a Return Code of , "Remote Ping not authorized". 252 If the "Request for Previous Hop" flag is set, a Previous Hop Address 253 Object is formatted for inclusion in the MPLS proxy ping reply. If 254 the previous HOP is unknown or ambiguous the Address Type is set to 255 "No Address Supplied". 257 If there is a list of Next Hop addresses in the Proxy Echo Parameters 258 object, each address is examined to determine if it is a next hop for 259 this FEC. If any are not, those addresses are deleted from the list. 260 The updated Proxy Echo Parameters object is included in the MPLS 261 proxy ping reply. 263 If the "Request for Downstream Mapping" flag is set the LSR formats a 264 Downstream Mapping object for each interface that the MPLS echo 265 request will be sent out. 267 If the Reply Mode of the message header is not 1 or 5, an MPLS remote 268 echo reply message SHOULD be sent as described below. 270 3.2.1. Sending an MPLS proxy ping reply 272 The Reply mode, Sender's Handle and Sequence Number fields are copied 273 from the proxy ping request message. Various objects are included as 274 specified above. The message is encapsulated in a UDP packet. The 275 source IP address is a routable address of the proxy LSR; the source 276 port is the well-known UDP port for LSP ping. The destination IP 277 address and UDP port are copied from the source IP address and UDP 278 port of the echo request. The IP TTL is set to 255. 280 3.2.2. Sending the MPLS echo requests 282 A base MPLS echo request is formed as decribed in the next section. 283 The section below that describes how the base MPLS echo request is 284 sent on each interface. 286 3.2.2.1. Forming the base MPLS echo request 288 A Next_Hop_List is created as follows. If Next Hop addresses were 289 included in the received Proxy Parameters object, the Next_Hop_List 290 is copied from the Proxy Echo Parameters object as adjusted above. 291 Otherwise, the list is set to all the next hops to which the FEC 292 would be forwarded. 294 The proxy LSR then formats an MPLS echo request message. The Global 295 Flags and Reply Mode are copied from the Proxy Echo Parameters 296 object. The Return Code and Return Subcode are set to zero. 298 The Sender's Handle and Sequence Number are copied from the remote 299 echo request message. 301 The TimeStamp Sent is set to the time-of-day (in seconds and 302 microseconds) that the echo request is sent. The TimeStamp Received 303 is set to zero. 305 A Reply-to Address object containing the initiator's address is 306 included. 308 The following objects are copied from the MPLS proxy ping request 309 message. Note that of these, only the Target FEC Stack is REQUIRED 310 to appear in the MPLS proxy ping request message. 312 Target FEC Stack 313 Pad 314 Vendor Enterprise Number 315 Reply TOS Byte 316 P2MP Egress Identifier [McstPing] 317 Echo Jitter TLV [McstPing] 318 Vendor Private TLVs 320 The message is then encapsulated in a UDP packet. The source UDP 321 port is copied from the Proxy Echo Parameters object. destination 322 ports are copied from the proxy ping request message. 324 The source IP address is set to a routable address of the proxy LSR. 325 Per usual the TTL of the IP packet is set to 1. 327 If the Explicit DSCP flag is set, the Requested DSCP byte is exam- 328 ined. If the setting is permitted then the DSCP byte of the IP 329 header of the MPLS Echo Request message is set to that value. Other- 330 wise the DSCP byte is set to a default value. In this case the MPLS 331 Proxy Echo Parameters with the Explicit DSCP flag cleared MUST be 332 included in any MPLS proxy ping reply message. The return code MUST 333 be set to , "Proxy ping parameters modified". The DSCP field of 334 the MPLS Proxy Echo Parameters SHOULD be set to the actual value 335 used. 337 3.2.2.2. Per interface sending procedures 339 The proxy LSR now iterates through the Next_Hop_List modifying the 340 base MPLS echo request to form the MPLS echo request packet which is 341 then sent on that particular interface. 343 For each next hop address, the outgoing label stack is determained. 344 The TTL for the label corresponding to the topmost FEC in the FEC 345 stack is set such that the TTL on the wire will be one less than the 346 TTL specified in the Proxy Echo Parameters. If any additional labels 347 are pushed onto the stack, their TTLs are set to 255. 349 If the MPLS proxy ping request message contained Downstream Mapping 350 objects, they are examined. If the Downstream IP Address matches the 351 next hop address that Downstream Mapping object is included in the 352 MPLS echo request. 354 The packet is then transmitted on this interface. 356 4. Proxy Ping Request / Reply Messages 358 Two new LSP Ping messages are defined for remote pinging, the MPLS 359 proxy ping request message and the MPLS proxy ping reply. 361 4.1. Proxy Ping Request / Reply Message formats 363 Except where noted, the definitions of all fields in the messages are 364 identical to those found in [LSP-PING]. The messages have the fol- 365 lowing format: 367 0 1 2 3 368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Version Number | MUST Be Zero | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Message Type | Reply mode | Return Code | Return Subcode| 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Sender's Handle | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Sequence Number | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | TLVs ... | 379 . . 380 . . 381 . . 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Version Number 387 The Version Number is currently 1. (Note: the Version Number is 388 to be incremented whenever a change is made that affects the 389 ability of an implementation to correctly parse or process an 390 MPLS echo request/reply. These changes include any syntactic or 391 semantic changes made to any of the fixed fields, or to any TLV 392 or sub-TLV assignment or format that is defined at a certain 393 version number. The Version Number may not need to be changed 394 if an optional TLV or sub-TLV is added.) 396 Message Type 398 Type Message 399 ---- ------- 400 5 MPLS proxy ping request 401 6 MPLS proxy ping reply 403 Reply mode 405 The reply modes are the same as [LSP-PING] with the addtion of 406 value 5. For completeness, the full list of reply modes 407 follows: 409 Value Meaning 410 ----- ------- 411 1 Do not reply 412 2 Reply via an IPv4/IPv6 UDP packet 413 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 414 4 Reply via application level control channel 415 5 Reply via an IPv4/IPv6 UDP packet only if the proxy 416 request is not fulfilled or modified 418 4.2. Proxy Ping Request Message contents 420 The MPLS proxy ping request message MAY contain the following 421 objects: 423 Type Object 424 ---- ----------- 425 1 Target FEC Stack 426 2 Downstream Mapping 427 3 Pad 428 5 Vendor Enterprise Number 429 10 Reply TOS Byte 430 tba Proxy Echo Parameters 431 tba P2MP Egress Identifier [McstPing] 432 tba Echo Jitter TLV [McstPing] 433 Vendor Private TLVs 435 4.3. Proxy Ping Reply Message Contents 437 The MPLS proxy ping reply message MAY contain the following objects: 439 Type Object 440 ---- ----------- 441 1 Target FEC Stack 442 2 Downstream Mapping 443 5 Vendor Enterprise Number 444 9 Errored TLVs 445 tba Proxy Echo Parameters 446 tba Previous Hop Address 447 Vendor Private objects 449 5. Object formats 451 5.1. Proxy Echo Parameters Object 453 The Proxy Echo Parameters object is a TLV that MUST be included in an 454 MPLS Proxy Echo Request message. The length of the TLV is 12 + K + 455 S, where K is the length of the Destination IP Address field and S is 456 the total length of the sub-objects. 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Address Type | Flags | Reply mode | TTL | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Rqst'd DSCP | Must be Zero | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Source UDP Port | Global Flags | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | | 468 : Destination IP Address : 469 | | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | | 472 : : 473 : Sub-Objects : 474 : : 475 | | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Address Type 479 The type and length of the address found in the in the 480 Destination IP Address and Next Hop IP Addresses fields. 481 The type codes appear in the table below: 483 Address Family Type Length 485 IPv4 1 4 486 IPv6 3 16 488 Flags 490 Request for Previous Hop 0x01 492 When set this requests that the proxy LSR supply the 493 previous hop address in the MPLS proxy ping reply message 495 Request for Downstream Mapping 0x02 497 When set this requests that the proxy LSR supply a 498 Downstream Mapping object in the MPLS proxy ping reply 499 message 501 Explicit DSCP Request 0x04 503 When set this requests that the proxy LSR supply a use 504 the supplied DSCP byte in the echo request message 506 Reply mode 508 The reply mode to be sent in the MPLS Echo Request message; the 509 values are as specified in [RFC4379] 511 TTL 513 The TTL to be used in the label stack entry corresponding to 514 the topmost FEC in the in the MPLS Echo Request packet 516 Requested DSCP 518 This field is valid only if the Explicit DSCP flag is set. If 519 not set, the field MUST be zero on transmission and ignored on 520 receipt. When the flag is set this field contains the DSCP 521 value to be used in the MPLS echo request packet IP header. 523 Source UDP Port 525 The source UDP port to be sent in the MPLS Echo Request packet 527 Global Flags 529 The Global Flags to be sent in the MPLS Echo Request messge 531 Destination IP Address 533 If the Address Type is IPv4, an address from the range 127/8; 534 If the Address Type is IPv6, an address from the range 535 0:0:0:0:0:FFFF:127/104 537 Sub-Objects 539 A TLV encoded list of sub-objects. Currently one is defined. 541 Sub-Type Length Value Field 542 -------- ------ ----------- 543 1 8+ Next Hop 545 5.1.1. Next Hop sub-Object 547 This sub-object is used to describe a particular next hop towards 548 which the Echo Request packet should be sent. If the topmost FEC in 549 the FEC-stack is a multipoint LSP, this sub-object may appear multi- 550 ple times. 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Addr Type | MUST be Zero | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Next Hop IP Address (4 or 16 octets) | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Next Hop Interface (0, 4 or 16 octets) | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 Address Type 562 Type Type of Next Hop Addr Length IF Length 564 1 IPv4 Numbered 4 4 565 2 IPv4 Unnumbered 4 4 566 3 IPv6 Numbered 16 16 567 4 IPv6 Unnumbered 16 4 568 5 IPv4 Protocol Adj 4 0 569 6 IPv6 Protocol Adj 16 0 571 Note: Types 1-4 correspond to the types in the DS Mapping 572 object. They are expected to populated with information 573 obtained through a previously returned DS Mapping object. 574 Types 5 and 6 are intended to be populated from the local 575 address information obtained from a previously returned 576 Previous Hop Address Object. 578 Next Hop IP Address 580 A next hop address that the echo request message is to 581 be sent towards 583 Next Hop Interface 585 Identifier of the interface through which the echo request 586 message is to be sent 588 5.2. Reply-to Address Object 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Address Type | MUST be Zero | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | | 593 : Reply-to Address : 594 | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Address Type 599 A type code as specified in the table below: 601 Type Type of Address 603 1 IPv4 604 3 IPv6 606 5.3. Previous Hop Address Object 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 |PHOP Addr Type |Local Addr Type| MUST be Zero | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | | 612 : Previous Hop Address : 613 | | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | | 616 : Local Address : 617 | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 PHOP Addr Type; Local Addr Type 621 These two fields determine the type and length of the 622 respective addresses. The codes are specified in the table 623 below: 625 Type Type of Address Length 627 0 No Address Supplied 0 628 1 IPv4 4 629 3 IPv6 16 631 Previous Hop Address 633 The address of the immediate upstream neighbor for the topmost 634 FEC in the FEC stack. If protocol adjacency exists by which 635 the label for this FEC was exchanged, this address MUST be the 636 address used in that protocol exchange. 638 Local Address 640 The local address used in the protocol adjacency exists by 641 which the label for this FEC was exchanged. 643 6. Security Considerations 645 [To be written] 647 7. IANA Considerations 649 [Not complete] 651 7.1. Message and Object Type Assignments 653 This document makes the following codepoint assigments (pending IANA 654 action): 656 Registry Codepoint Purpose 658 LSP Ping Message Type tba MPLS proxy ping request message 659 tba MPLS proxy ping reply 661 LSP Ping Object Type tba Proxy Echo Parameters 662 tba Reply-to Address 663 tba Previous Hop Address 665 7.2. Return Code Assignments 667 Value Meaning 669 tba Proxy ping request not authorized 670 tba Proxy ping parameters modified 672 8. References 674 8.1. Normative References 676 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 677 Label Switched (MPLS) Data Plane Failures", RFC 4379, 678 February 2006. 680 [KeyWords] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, March 1997. 683 [McstPing] Farrel, A. et al, "Detecting Data Plane Failures in 684 Point-to-Multipoint MPLS Traffic Engineering - 685 Extensions to LSP Ping", 686 draft-ietf-mpls-p2mp-lsp-ping-06.txt, June 2008. 688 8.2. Informative References 690 [P2MP-TE] Aggarwal, R., et al., "Extensions to RSVP-TE for 691 Point-to-Multipoint TE LSPs", RFC 4875, May 2007. 693 [mLDP] Minei, I., et. al., "Label Distribution Protocol 694 Extensions for Point-to-Multipoint and 695 Multipoint-to-Multipoint Label Switched Paths" 696 draft-ietf-mpls-ldp-p2mp-05.txt, May 2008. 698 9. Authors' Addresses 700 George Swallow 701 Cisco Systems, Inc. 702 1414 Massachusetts Ave 703 Boxborough, MA 01719 705 Email: swallow@cisco.com 707 Vanson Lim 708 Cisco Systems, Inc. 709 1414 Massachusetts Ave 710 Boxborough, MA 01719 712 Email: vlim@cisco.com 714 Intellectual Property 716 The IETF takes no position regarding the validity or scope of any 717 Intellectual Property Rights or other rights that might be claimed to 718 pertain to the implementation or use of the technology described in 719 this document or the extent to which any license under such rights 720 might or might not be available; nor does it represent that it has 721 made any independent effort to identify any such rights. Information 722 on the procedures with respect to rights in RFC documents can be 723 found in BCP 78 and BCP 79. 725 Copies of IPR disclosures made to the IETF Secretariat and any 726 assurances of licenses to be made available, or the result of an 727 attempt made to obtain a general license or permission for the use of 728 such proprietary rights by implementers or users of this 729 specification can be obtained from the IETF on-line IPR repository at 730 http://www.ietf.org/ipr. 732 The IETF invites any interested party to bring to its attention any 733 copyrights, patents or patent applications, or other proprietary 734 rights that may cover technology that may be required to implement 735 this standard. Please address the information to the IETF at ietf- 736 ipr@ietf.org. 738 Full Copyright Notice 740 Copyright (C) The IETF Trust (2008). This document is subject 741 to the rights, licenses and restrictions contained in BCP 78, and 742 except as set forth therein, the authors retain all their rights. 744 This document and the information contained herein are provided on an 745 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 746 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 747 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 748 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 749 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 750 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.