idnits 2.17.1 draft-ietf-mpls-lsr-self-test-07.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, updated by RFC 4748 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 557. ** 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 14 longer pages, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (May 2007) is 6163 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) ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 4379 (ref. 'LSP-PING') (Obsoleted by RFC 8029) Summary: 4 errors (**), 0 flaws (~~), 2 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: November 2007 6 Kireeti Kompella 7 Juniper Networks, Inc. 9 Dan Tappan 11 May 2007 13 Label Switching Router Self-Test 15 draft-ietf-mpls-lsr-self-test-07.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 to 43 verify that its data plane is functioning for certain key Multi- 44 Protocol Label Switching applications, including unicast 45 forwarding and traffic engineering tunnels. A new Loopback FEC 46 type is defined to allow an upstream neighbor to assist in the 47 testing at very low cost. MPLS Verification Request and MPLS 48 Verification Reply messages are defined to do the actual probing. 50 Contents 52 1 Introduction .............................................. 3 53 1.1 Conventions ............................................... 4 54 2 Loopback FEC .............................................. 4 55 2.1 Loopback FEC Element ...................................... 4 56 2.2 LDP Procedures ............................................ 6 57 3 Data Plane Self Test ...................................... 6 58 3.1 Data Plane Verification Request / Reply Messages .......... 7 59 3.2 UDP Port .................................................. 9 60 3.3 Reply-To Address Object ................................... 9 61 3.3.1 IPv4 Reply-To Address Object .............................. 9 62 3.3.2 IPv6 Reply-To Address Object .............................. 9 63 3.4 Sending procedures ........................................ 10 64 3.5 Receiving procedures ...................................... 11 65 3.6 Upstream Neighbor Verification ............................ 12 66 4 Security Considerations ................................... 12 67 5 IANA Considerations ....................................... 13 68 6 Acknowledgments ........................................... 13 69 7 References ................................................ 13 70 7.1 Normative References ...................................... 13 71 7.2 Informative References .................................... 14 72 8 Authors' Addresses ........................................ 14 74 1. Introduction 76 This document defines extentions to RFC 4379 [LSP-PING] (which is 77 generally known as Label-Switched-Path (LSP) Ping) to provide a means 78 for a Label-Switching Router (LSR) to verify that its data plane is 79 functioning for certain key Multi-Protocol Label Switching (MPLS) 80 applications, including unicast forwarding based on the Label Distri- 81 bution Protocol (LDP) [LDP] and traffic engineering tunnels based on 82 [RSVP-TE]. MPLS Verification Request and MPLS Verification Reply 83 messages are defined to do the actual probing. The pings are sent to 84 an upstream neighbor, looped back through the LSR under test and 85 intercepted, by means of time-to-live (TTL) expiration by a down- 86 stream neighbor. 88 In order to minimize the load on upstream LSRs a loopback FEC Type is 89 defined. Labels advertised with this FEC Type are referred to as 90 loopback labels. Receipt of a packet labeled with a loopback label 91 will cause the advertising LSR to pop the label off the label stack 92 and send the packet out the advertised interface. 94 Use of a loopback mechnism allows an LSR to test label entries which 95 are not currently in use. For example many LSRs advertise label map- 96 pings for all IPv4 routes to all of their neighbors. For some por- 97 tion of these their neighbor LSR is not currently upstream and the 98 label entry is not used. But if the neighbors best path to a desti- 99 nation changes, that route and the associated label entry will be 100 used. An LSR can loop traffic through a "non-upstream" LSR because 101 that LSR is acting only on the loopback label and not on the underly- 102 ing label associated with the actual forwarding equivalence class 103 (FEC) being tested. In this way label entries can be verified prior 104 to the occurrence of a routing change. 106 Some routing protocols, most notably Open Shortest-Path-First (OSPF) 107 [OSPF] have no means of exchanging the "Link Local Identifiers" used 108 to identify unnumbered links and components of bundled links. These 109 test procedures can be used to associate the neighbor's interfaces 110 with the probing LSRs interfaces. This is achieved by simply having 111 the TTL of the LSP Ping expire one hop sooner, i.e. at the testing 112 LSR itself. 114 1.1. Conventions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 120 2. Loopback FEC 122 The Loopback FEC type is defined to enable an upstream neighbor to 123 assist in LSR self-testing at very low cost. This FEC causes the 124 loopback to occur in the data plane without control plane involvement 125 beyond the initial LDP exchange and data-plane setup. The FEC also 126 carries information to indicate the desired encapsulation should it 127 be the only label in a received label stack. Values are defined for 128 IPv4 and IPv6. 130 An LSR uses a Loopback FEC to selectively advertise loopback labels 131 to its neighbor LSRs. Each loopback label is bound to a particular 132 interface. For multi-access links, a unique label for each neighbor 133 is required, since the link-level address is derived from the label 134 lookup. When an MPLS packet with its top label set to a loopback 135 label is received from an interface over which that label was adver- 136 tised, the loopback label is popped and the packet is sent on the 137 interface to which the loopback label was bound. If the label-stack 138 only contains the one loopback label, the encapsulation of the packet 139 is determined by the FEC Type. 141 TTL treatment for loopback labels follows the Uniform model. I.e. 142 the TTL carried in the loopback label is decremented and copied to 143 the exposed label or IP header as the case may be. 145 2.1. Loopback FEC Element 147 FEC element type 130 is used. The FEC element is encoded as fol- 148 lows: (note: 130 is provisionally assigned, the actual value will be 149 assigned by IANA.) 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | 130 | Res | If & Prot Type| Id Length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Interface Identifier | 156 | " | 157 | " | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Reserved (Res) 162 MUST be set to zero on transmission and ignored on receipt. 164 Interface & Protocol Type 166 # Type Interface Identifier 167 --- ---- -------------------- 168 1 IPv4 Numbered IPv4 Address 169 2 IPv4 Unnumbered A 32 bit Link Identifier as 170 defined in [RFC3477] 171 3 IPv6 Numbered IPv6 Address 172 4 IPv6 Unnumbered A 32 bit Link Identifier as 173 defined in [RFC3477] 175 Note that these type values also indicate the encapsulation 176 (IPv4 or IPv6) for payloads that have a label stack containing 177 only a loopback label. 179 Identifier Length 181 Length of the interface identifier in octets. The length is 4 182 bytes for the unnumbered types and IPv4, 16 bytes for IPv6. 184 Address 186 An identifier encoded according to the Identifier Type field. 188 2.2. LDP Procedures 190 It is RECOMMENDED that loopback labels only be distributed in 191 response to a Label Request message, irrespective of the label adver- 192 tisement mode of the LDP session. However it is recognized that in 193 certain cases such as OSPF with unnumbered links, the upstream LSR 194 may not have sufficiently detailed information of the neighbor's link 195 identifier to form the request. In these cases, the downstream LSR 196 MAY be configured to make unsolicited advertisements. 198 3. Data Plane Self Test 200 A self test operation involves three LSRs, the LSR doing the test, an 201 upstream neighbor and a downstream LSR. Upstream here is with 202 respect to the flow of the test (which in some cases could be differ- 203 ent than the normal sense of upstream in IP routing). We refer to 204 these as LSRs T, U, and D respectively. In order to minimize the 205 processing load on LSR-D, two new LSP Ping messages are defined, 206 called the MPLS Data Plane Verification Request and the MPLS Data 207 Plane Verification Reply. These messages are used to allow LSR-T to 208 obtain the label stack, address and interface information of LSR-D. 210 The packet flow is shown below. Although the figure shows LSR-D adja- 211 cent to LSR-T it may in some cases be an arbitrary number of hops 212 away. 214 +-------+ +-------+ +-------+ 215 | ,-|-------| | 217 | | | | | | 218 | | | <-|-------|, is provided. Port SHOULD be 313 used by default. The source UDP port, as in [LSP-PING] is chosen by 314 the sender. 316 3.3. Reply-To Address Object 318 In order to perform detailed diagnostics of a particular failing flow 319 in the face of ECMP, it is useful to be able to use the exact source 320 and destination addresses of that flow. The Reply-To Object is an 321 optional TLV in a MPLS Data Plane Verification Request message. The 322 Object has two formats, type 11 for IPv4 and type 12 for IPv6 (to be 323 assigned by IANA). 325 3.3.1. IPv4 Reply-To Address Object 327 The length of an IPv4 Reply-to Address object is 4 octets; the value 328 field has the following format: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Reply-to IPv4 Address | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Reply-to IPv4 Address 338 The address to which the MPLS Data Plane Verification Reply 339 message is to be sent. 341 3.3.2. IPv6 Reply-To Address Object 343 The length of an IPv6 Reply-to Address object is 16 octets; the value 344 field has the following format: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Reply-to IPv6 Address | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Reply-to IPv6 Address (Cont.) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Reply-to IPv6 Address (Cont.) | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Reply-to IPv6 Address (Cont.) | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Reply-to IPv6 Address 360 The address to which the MPLS Data Plane Verification Reply 361 message is to be sent. 363 3.4. Sending procedures 365 In order to perform a test on an incoming labeled or unlabeled 366 packet, an LSR first determines the expected outgoing label stack, 367 next hop router and next hop interface. 369 The LSR creates an MPLS Data Plane Verification Request message. 371 In normal use, the source address is set to an address belonging to 372 the LSR and the destination set to an address in the range of 127/8. 373 The incoming label stack (if any) is prepended to the packet. The 374 TTL of these labels and the packet header SHOULD be set to appropri- 375 ate values - 2 for those labels and/or header which will be processed 376 by this node when the packet is looped back; 1 for those labels 377 and/or header which will be carried through. Finally the loopback 378 label bound to the incoming interface is prepended to the packet. In 379 the case of an otherwise unlabeled packet the label's FEC MUST indi- 380 cate the appropriate IP version. The TTL is set such that it will 381 have the value of 3 on the wire. 383 The packet is sent to the upstream neighbor on an interface for which 384 the loopback label is valid. 386 In diagnostic situations, the source and destination addresses MAY be 387 set to any value. In this case, a Reply-to IPv4 or IPv6 Address 388 object MUST be included. The IP TTL MUST be set to 1. The TTL of 389 labels other than the loopback label MUST be set to appropriate val- 390 ues - 2 for those labels which will be process by this LSR when the 391 packet is looped back; 1 for those labels which will be carried 392 through. 394 In some MPLS deployments TTL hiding is used to make a providers net- 395 work appear as a single hop. That is the TTL in the imposed label 396 does not reflect the TTL of the received packet. It is RECOMMENDED 397 that testing of label imposition SHOULD NOT be performed in such cir- 398 cumstances as the Verification Request will in most case travel mul- 399 tiple hops. 401 3.5. Receiving procedures 403 An LSR X that receives an MPLS Verification Request message formats a 404 MPLS Verification Reply message. The Sender's Handle and Sequence 405 Number are copied from the Request message. 407 X then parses the packet to ensure that it is a well-formed packet, 408 and that the TLVs that are not marked "Ignore" are understood. If 409 not, X SHOULD set the Return Code set to "Malformed echo request 410 received" or "TLV not understood" (as appropriate), and the Subcode 411 set to zero. In the latter case, the misunderstood TLVs (only) are 412 included in the reply. 414 If the Verification Request is good, X MUST note the interface and 415 label stack of the received Verification Request and format this 416 information as a Downstream Verification object. This object is 417 included in the MPLS Verification Reply message. The Return Code and 418 Subcode MUST be set to zero, indicating "No return code". 420 The source address of the Reply message MUST be an address of the 421 replying LSR. If the request included a Reply-to IPv4 or IPv6 422 Address object, the MPLS Data Plane Verification Reply message MUST 423 be sent to that address. Otherwise the Reply message is sent to the 424 source address of the Verification Request message. 426 An LSR MUST be capable of filtering addresses that are to be replied 427 to. If a filter has been invoked (i.e. configured) and an address 428 does not pass the filter, then a reply MUST NOT be sent, and the 429 event SHOULD be logged. 431 3.6. Upstream Neighbor Verification 433 To verify that an upstream neighbor is properly echoing packets an 434 LSR may send an MPLS Data Plane Verification Request packet with the 435 TTL set so that the packet will expire upon reaching reaching itself. 436 This procedure not only tests that the neighbor is correctly process- 437 ing the loopback label, it also allows the node to verify the neigh- 438 bor's interface mapping. 440 +-------+ +-------+ 441 | | | | 442 | ,-|-------| | 444 | | | | 445 +-------+ +-------+ 446 LSR-U LSR-T 448 DPVRq: MPLS Data Plane Verification Request 450 Figure 2: Upstream Neighbor Verification 452 No TLVs need to be included in the MPLS Data Plane Verification 453 Request. By noting the Sender's Handle and Sequence Number, as well 454 as the loopback label, LSR-T is able to detect that a) the packet was 455 looped, and b) determine (or verify) the interface on which the 456 packet was received. 458 4. Security Considerations 460 Were loopback labels widely known, they might be subject to abuse. 461 It is therefore RECOMMENDED that loopback labels only be shared 462 between trusted neighbors. Further, if the loopback labels are drawn 463 from a per-platform label space, or any other label space shared 464 across multiple LDP sessions, it is RECOMMENDED that all loopback 465 labels be filtered from a session except those labels pertaining to 466 interfaces directly connected to the neighbor participating in that 467 session. 469 5. IANA Considerations 471 This document makes the following codepoint assigments (pending IANA 472 action): 474 Registry Codepoint Purpose 476 UDP Port tbd MPLS Verification Request 478 LSP Ping Message Type 3 MPLS Data Plane Verification 479 Request 480 LSP Ping Message Type 4 MPLS Data Plane Verification 481 Reply 482 LSP Ping Object Type 11 IPv4 Reply-to Address 484 LSP Ping Object Type 12 IPv6 Reply-to Address 486 6. Acknowledgments 488 The authors would like to thank Vanson Lim, Tom Nadeau, and Bob 489 Thomas for their comments and suggestions. 491 7. References 493 7.1. Normative References 495 [LDP] Andersson, L. et al., "LDP Specification", RFC 3036, 496 January 2001. 498 [LSP-PING] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 499 Label Switched (MPLS) Data Plane Failures", RFC 4379, 500 February 2006. 502 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 503 in Resource ReSerVation Protocol - Traffic Engineering 504 (RSVP-TE)", January 2003. 506 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 7.2. Informative References 511 [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP 512 tunnels", RFC 3209, December 2001. 513 [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 515 8. Authors' Addresses 517 Kireeti Kompella 518 Juniper Networks, Inc. 519 1194 N. Mathilda Ave. 520 Sunnyvale, CA 94089 521 Email: kireeti@juniper.net 523 George Swallow 524 Cisco Systems, Inc. 525 1414 Massachusetts Ave 526 Boxborough, MA 01719 528 Email: swallow@cisco.com 530 Dan Tappan 531 Boxborough, MA 01719 533 Email: dtappan@alum.mit.edu 535 Intellectual Property 537 The IETF takes no position regarding the validity or scope of any 538 Intellectual Property Rights or other rights that might be claimed to 539 pertain to the implementation or use of the technology described in 540 this document or the extent to which any license under such rights 541 might or might not be available; nor does it represent that it has 542 made any independent effort to identify any such rights. Information 543 on the procedures with respect to rights in RFC documents can be 544 found in BCP 78 and BCP 79. 546 Copies of IPR disclosures made to the IETF Secretariat and any assur- 547 ances of licenses to be made available, or the result of an attempt 548 made to obtain a general license or permission for the use of such 549 proprietary rights by implementers or users of this specification can 550 be obtained from the IETF on-line IPR repository at 551 http://www.ietf.org/ipr. 553 The IETF invites any interested party to bring to its attention any 554 copyrights, patents or patent applications, or other proprietary 555 rights that may cover technology that may be required to implement 556 this standard. Please address the information to the IETF at ietf- 557 ipr@ietf.org. 559 Full Copyright Notice 561 Copyright (C) The IETF Trust (2007). This document is subject to the 562 rights, licenses and restrictions contained in BCP 78, and except as 563 set forth therein, the authors retain all their rights. 565 This document and the information contained herein are provided on an 566 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 567 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 568 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 569 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 570 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 571 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.