idnits 2.17.1 draft-ietf-mpls-lsr-self-test-06.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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 569. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 13 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 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6767 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'LDP' is mentioned on line 80, but not defined == Missing Reference: 'LSP-PING' is mentioned on line 309, but not defined == Unused Reference: 'RFC3036' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'LSP-Ping' is defined on line 492, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) -- Possible downref: Non-RFC (?) normative reference: ref. 'LSP-Ping' Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group George Swallow 2 Internet Draft Cisco Systems, Inc. 3 Category: Standards Track 4 Expiration Date: April 2006 5 Kireeti Kompella 6 Juniper Networks, Inc. 8 Dan Tappan 9 Cisco Systems, Inc. 11 October 2005 13 Label Switching Router Self-Test 15 draft-ietf-mpls-lsr-self-test-06.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 This document defines a means for a Label-Switching Router (LSR) 43 to verify that its data plane is functioning for certain key 44 Multi-Protocol Label Switching (MPLS) applications, including 45 unicast forwarding and traffic engineering tunnels. A new 46 Loopback FEC type is defined to allow an upstream neighbor to 47 assist in the testing at very low cost. MPLS Verification Request 48 and MPLS Verification Reply messages are defined to do the actual 49 probing. 51 Contents 53 1 Introduction .............................................. 3 54 1.1 Conventions ............................................... 3 55 2 Loopback FEC .............................................. 4 56 2.1 Loopback FEC Element ...................................... 4 57 2.2 LDP Procedures ............................................ 5 58 3 Data Plane Self Test ...................................... 6 59 3.1 Data Plane Verification Request / Reply Messages .......... 7 60 3.2 UDP Port .................................................. 8 61 3.3 Reply-To Address Object ................................... 8 62 3.3.1 IPv4 Reply-To Address Object .............................. 8 63 3.3.2 IPv6 Reply-To Address Object .............................. 9 64 3.4 Sending procedures ........................................ 9 65 3.5 Receiving procedures ...................................... 10 66 3.6 Upstream Neighbor Verification ............................ 11 67 4 Security Considerations ................................... 12 68 5 IANA Considerations ....................................... 12 69 6 Acknowledgments ........................................... 12 70 7 References ................................................ 12 71 7.1 Normative References ...................................... 12 72 7.2 Informative References .................................... 13 73 8 Authors' Addresses ........................................ 13 75 1. Introduction 77 This document defines a means for a Label-Switching Router (LSR) to 78 verify that its data plane is functioning for certain key Multi-Pro- 79 tocol Label Switching (MPLS) applications, including unicast forward- 80 ing based on LDP [LDP] and traffic engineering tunnels based on 81 [RSVP-TE]. MPLS Verification Request and MPLS Verification Reply 82 messages are defined to do the actual probing. The pings are sent to 83 an upstream neighbor, looped back through the LSR under test and 84 intercepted, by means of TTL expiration by a downstream neighbor. 86 In order to minimize the load on upstream LSRs a loopback FEC Type is 87 defined. Labels advertised with this FEC Type are referred to as 88 loopback labels. Receipt of a packet labeled with a loopback label 89 will cause the advertising LSR to pop the label off the label stack 90 and send the packet out the advertised interface. 92 Use of a loopback mechnism allows an LSR to test label entries which 93 are not currently in use. For example many LSRs advertise label map- 94 pings for all IPv4 routes to all of their neighbors. For some por- 95 tion of these their neighbor LSR is not currently upstream and the 96 label entry is not used. But if the neighbors best path to a desti- 97 nation changes, that route and the associated label entry will be 98 used. An LSR can loop traffic through a "non-upstream" LSR because 99 that LSR is acting only on the loopback label and not on the underly- 100 ing label associated with the actual FEC being tested. In this way 101 label entries can be verified prior to the occurrence of a routing 102 change. 104 Some routing protocols, most notably OSPF have no means of exchanging 105 the "Link Local Identifiers" used to identify unnumbered links and 106 components of bundled links. These test procedures can be used to 107 associate the neighbor's interfaces with the probing LSRs interfaces. 108 This is achieved by simply having the TTL of the MPLS Ping expire one 109 hop sooner, i.e. at the testing LSR itself. 111 1.1. Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 117 2. Loopback FEC 119 The Loopback FEC type is defined to enable an upstream neighbor to 120 assist in LSR self-testing at very low cost. This FEC causes the 121 loopback to occur in the data plane without control plane involvement 122 beyond the initial LDP exchange and data-plane setup. The FEC also 123 carries information to indicate the desired encapsulation should it 124 be the only label in a received label stack. Values are defined for 125 IPv4 and IPv6. 127 An LSR uses a Loopback FEC to selectively advertise loopback labels 128 to its neighbor LSRs. Each loopback label is bound to a particular 129 interface. For multi-access links, a unique label for each neighbor 130 is required, since the link-level address is derived from the label 131 lookup. When an MPLS packet with its top label set to a loopback 132 label is received from an interface over which that label was adver- 133 tised, the loopback label is popped and the packet is sent on the 134 interface to which the loopback label was bound. If the label-stack 135 only contains the one loopback label, the encapsulation of the packet 136 is determined by the FEC Type. 138 TTL treatment for loopback labels follows the Uniform model. I.e. 139 the TTL carried in the loopback label is decremented and copied to 140 the exposed label or IP header as the case may be. 142 2.1. Loopback FEC Element 144 FEC element type 130 is used. The FEC element is encoded as fol- 145 lows: (note: 130 is provisionally assigned, the actual value will be 146 assigned by IANA.) 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | 130 | Res | If & Prot Type| Id Length | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Interface Identifier | 154 | " | 155 | " | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Reserved (Res) 159 MUST be set to zero on transmission and ignored on receipt. 161 Interface & Protocol Type 163 # Type Interface Identifier 164 --- ---- -------------------- 165 1 IPv4 Numbered IPv4 Address 166 2 IPv4 Unnumbered A 32 bit Link Identifier as 167 defined in [RFC3477] 168 3 IPv6 Numbered IPv6 Address 169 4 IPv6 Unnumbered A 32 bit Link Identifier as 170 defined in [RFC3477] 172 Note that these type values also indicate the encapsulation (IPv4 or 173 IPv6) for payloads that have a label stack containing only a loopback 174 label. 176 Identifier Length 178 Length of the interface identifier in octets. The length is 4 179 bytes for the unnumbered types and IPv4, 16 bytes for IPv6. 181 Address 183 An identifier encoded according to the Identifier Type field. 185 2.2. LDP Procedures 187 It is RECOMMENDED that loopback labels only be distributed in 188 response to a Label Request message, irrespective of the label adver- 189 tisement mode of the LDP session. However it is recognized that in 190 certain cases such as OSPF with unnumbered links, the upstream LSR 191 may not have sufficiently detailed information of the neighbor's link 192 identifier to form the request. In these cases, the downstream LSR 193 MAY be configured to make unsolicited advertisements. 195 3. Data Plane Self Test 197 A self test operation involves three LSRs, the LSR doing the test, an 198 upstream neighbor and a downstream LSR. Upstream here is with 199 respect to the flow of the test (which in some cases could be differ- 200 ent than the normal sense of upstream in IP routing). We refer to 201 these as LSRs T, U, and D respectively. In order to minimize the 202 processing load on LSR-D, two new LSP Ping messages are defined, 203 called the MPLS Data Plane Verification Request and the MPLS Data 204 Plane Verification Reply. These messages are used to allow LSR-T to 205 obtain the label stack, address and interface information of LSR-D. 207 The packet flow is shown below. Although the figure shows LSR-D adja- 208 cent to LSR-T it may in some cases be an arbitrary number of hops 209 away. 211 +-------+ +-------+ +-------+ 212 | ,-|-------| | 214 | | | | | | 215 | | | <-|-------|, is provided. Port SHOULD be 309 used by default. The source UDP port, as in [LSP-PING] is chosen by 310 the sender. 312 3.3. Reply-To Address Object 314 In order to perform detailed diagnostics of a particular failing flow 315 in the face of ECMP, it is useful to be able to use the exact source 316 and destination addresses of that flow. The Reply-To Object is an 317 optional TLV in a MPLS Data Plane Verification Request message. The 318 Object has two formats, type 11 for IPv4 and type 12 for IPv6 (to be 319 assigned by IANA). 321 3.3.1. IPv4 Reply-To Address Object 323 The length of an IPv4 Reply-to Address object is 4 octets; the value 324 field has the following format: 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Reply-to IPv4 Address | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Reply-to IPv4 Address 334 The address to which the MPLS Data Plane Verification Reply 335 message is to be sent. 337 3.3.2. IPv6 Reply-To Address Object 339 The length of an IPv6 Reply-to Address object is 16 octets; the value 340 field has the following format: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Reply-to IPv6 Address | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Reply-to IPv6 Address (Cont.) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Reply-to IPv6 Address (Cont.) | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Reply-to IPv6 Address (Cont.) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Reply-to IPv6 Address 356 The address to which the MPLS Data Plane Verification Reply 357 message is to be sent. 359 3.4. Sending procedures 361 In order to perform a test on an incoming labeled or unlabeled 362 packet, an LSR first determines the expected outgoing label stack, 363 next hop router and next hop interface. 365 The LSR creates an MPLS Data Plane Verification Request message. 367 In normal use, the source address is set to an address belonging to 368 the LSR and the destination set to an address in the range of 127/8. 370 The incoming label stack (if any) is prepended to the packet. The 371 TTL of these labels and the packet header SHOULD be set to appropri- 372 ate values - 2 for those labels and/or header which will be processed 373 by this node when the packet is looped back; 1 for those labels 374 and/or header which will be carried through. Finally the loopback 375 label bound to the incoming interface is prepended to the packet. In 376 the case of an otherwise unlabeled packet the label's FEC MUST indi- 377 cate the appropriate IP version. The TTL is set such that it will 378 have the value of 3 on the wire. 380 The packet is sent to the upstream neighbor on an interface for which 381 the loopback label is valid. 383 In diagnostic situations, the source and destination addresses MAY be 384 set to any value. In this case, a Reply-to IPv4 or IPv6 Address 385 object MUST be included. The IP TTL MUST be set to 1. The TTL of 386 labels other than the loopback label MUST be set to appropriate val- 387 ues - 2 for those labels which will be process by this LSR when the 388 packet is looped back; 1 for those labels which will be carried 389 through. 391 In some MPLS deployments TTL hiding is used to make a providers net- 392 work appear as a single hop. That is the TTL in the imposed label 393 does not reflect the TTL of the received packet. It is RECOMMENDED 394 that testing of label imposition SHOULD NOT be performed in such cir- 395 cumstances as the Verification Request will in most case travel mul- 396 tiple hops. 398 3.5. Receiving procedures 400 An LSR X that receives an MPLS Verification Request message formats a 401 MPLS Verification Reply message. The Sender's Handle and Sequence 402 Number are copied from the Request message. 404 X then parses the packet to ensure that it is a well-formed packet, 405 and that the TLVs that are not marked "Ignore" are understood. If 406 not, X SHOULD set the Return Code set to "Malformed echo request 407 received" or "TLV not understood" (as appropriate), and the Subcode 408 set to zero. In the latter case, the misunderstood TLVs (only) are 409 included in the reply. 411 If the Verification Request is good, X MUST note the interface and 412 label stack of the received Verification Request and format this 413 information as a Downstream Verification object. This object is 414 included in the MPLS Verification Reply message. The Return Code and 415 Subcode MUST be set to zero, indicating "No return code". 417 The source address of the Reply message MUST be an address of the 418 replying LSR. If the request included a Reply-to IPv4 or IPv6 419 Address object, the MPLS Data Plane Verification Reply message MUST 420 be sent to that address. Otherwise the Reply message is sent to the 421 source address of the Verification Request message. 423 An LSR MUST be capable of filtering addresses that are to be replied 424 to. If a filter has been invoked (i.e. configured) and an address 425 does not pass the filter, then a reply MUST NOT be sent, and the 426 event SHOULD be logged. 428 3.6. Upstream Neighbor Verification 430 To verify that an upstream neighbor is properly echoing packets an 431 LSR may send an MPLS Data Plane Verification Request packet with the 432 TTL set so that the packet will expire upon reaching reaching itself. 433 This procedure not only tests that the neighbor is correctly process- 434 ing the loopback label, it also allows the node to verify the neigh- 435 bor's interface mapping. 437 +-------+ +-------+ 438 | | | | 439 | ,-|-------| | 441 | | | | 442 +-------+ +-------+ 443 LSR-U LSR-T 445 DPVRq: MPLS Data Plane Verification Request 447 Figure 2: Upstream Neighbor Verification 449 No TLVs need to be included in the MPLS Data Plane Verification 450 Request. By noting the Sender's Handle and Sequence Number, as well 451 as the loopback label, LSR-T is able to detect that a) the packet was 452 looped, and b) determine (or verify) the interface on which the 453 packet was received. 455 4. Security Considerations 457 Were loopback labels widely known, they might be subject to abuse. 458 It is therefore RECOMMENDED that loopback labels only be shared 459 between trusted neighbors. Further, if the loopback labels are drawn 460 from the Global Label Space, or any other label space shared across 461 multiple LDP sessions, it is RECOMMENDED that all loopback labels be 462 filtered from a session except those labels pertaining to interfaces 463 directly connected to the neighbor participating in that session. 465 5. IANA Considerations 467 This document makes the following codepoint assigments (pending IANA 468 action): 470 Registry Codepoint Purpose 472 UDP Port tbd MPLS Verification Request 474 LSP Ping Message Type 3 MPLS Data Plane Verification 475 Request 476 LSP Ping Message Type 4 MPLS Data Plane Verification 477 Reply 478 LSP Ping Object Type 11 IPv4 Reply-to Address 479 LSP Ping Object Type 12 IPv6 Reply-to Address 481 6. Acknowledgments 483 The authors would like to thank Vanson Lim, Tom Nadeau, and Bob 484 Thomas for their comments and suggestions. 486 7. References 488 7.1. Normative References 490 [RFC3036] Andersson, L. et al., "LDP Specification", January 2001. 492 [LSP-Ping] Bonica, R. et al., "Detecting MPLS Data Plane Liveness", 493 work-in-progress. 495 [RFC3477] Kompella, K. & Y. Rekhter, "Signalling Unnumbered Links 496 in Resource ReSerVation Protocol - Traffic Engineering 497 (RSVP-TE)", January 2003. 499 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, March 1997. 502 7.2. Informative References 504 [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP 505 tunnels", RFC 3209, December 2001. 507 8. Authors' Addresses 509 Kireeti Kompella 510 Juniper Networks, Inc. 511 1194 N. Mathilda Ave. 512 Sunnyvale, CA 94089 513 Email: kireeti@juniper.net 515 George Swallow 516 Cisco Systems, Inc. 517 1414 Massachusetts Ave 518 Boxborough, MA 01719 520 Email: swallow@cisco.com 522 Dan Tappan 523 Cisco Systems, Inc. 524 1414 Massachusetts Ave 525 Boxborough, MA 01719 527 Email: tappan@cisco.com 529 Copyright Notice 531 Copyright (C) The Internet Society (2005). This document is subject 532 to the rights, licenses and restrictions contained in BCP 78, and 533 except as set forth therein, the authors retain all their rights. 535 Expiration Date 537 April 2006 539 Disclaimer of Validity 541 This document and the information contained herein are provided on an 542 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 543 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 544 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 545 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 546 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 547 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 549 The IETF takes no position regarding the validity or scope of any 550 Intellectual Property Rights or other rights that might be claimed to 551 pertain to the implementation or use of the technology described in 552 this document or the extent to which any license under such rights 553 might or might not be available; nor does it represent that it has 554 made any independent effort to identify any such rights. Information 555 on the procedures with respect to rights in RFC documents can be 556 found in BCP 78 and BCP 79. 558 Copies of IPR disclosures made to the IETF Secretariat and any 559 assurances of licenses to be made available, or the result of an 560 attempt made to obtain a general license or permission for the use of 561 such proprietary rights by implementers or users of this 562 specification can be obtained from the IETF on-line IPR repository at 563 http://www.ietf.org/ipr. 565 The IETF invites any interested party to bring to its attention any 566 copyrights, patents or patent applications, or other proprietary 567 rights that may cover technology that may be required to implement 568 this standard. Please address the information to the IETF at 569 ietf-ipr@ietf.org.