idnits 2.17.1 draft-ietf-mpls-lsr-self-test-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RSVP-TE], [LSP-Ping], [LDP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 280 has weird spacing: '...Request messa...' == Line 292 has weird spacing: '... Reply messa...' == Line 569 has weird spacing: '...by this when ...' == Line 734 has weird spacing: '...for the purpo...' -- 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 (February 2004) is 7375 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 84, but not defined == Missing Reference: 'LSP-PING' is mentioned on line 251, but not defined == Unused Reference: 'RFC3036' is defined on line 662, 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 (~~), 8 warnings (==), 4 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: August 2004 5 Kireeti Kompella 6 Juniper Networks, Inc. 8 Dan Tappan 9 Cisco Systems, Inc. 11 February 2004 13 Label Switching Router Self-Test 15 draft-ietf-mpls-lsr-self-test-02.txt 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document defines a means of self test for a Label-Switching 43 Router (LSR) to verify that its dataplane is functioning for 44 certain key Multi-Protocol Label Switching (MPLS) applications 45 including unicast forwarding based on LDP [LDP] and traffic 46 engineering tunnels based on [RSVP-TE]. A new Loopback FEC type 47 is defined to allow an upstream neighbor to assist in the testing 48 at very low cost. MPLS Echo Request and MPLS Echo Reply messages 49 [LSP-Ping] are extended to do the actual 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 ................................... 5 59 3.1 Data Plane Verification Request / Reply Messages ....... 7 60 3.2 Downstream Verification Object ......................... 8 61 3.2.1 IPv4 Downstream Verification Object .................... 8 62 3.2.2 IPv6 Downstream Verification Object .................... 11 63 3.3 Reply-To Object ........................................ 13 64 3.3.1 IPv4 Reply-To Object ................................... 14 65 3.3.2 IPv6 Reply-To Object ................................... 14 66 3.4 Sending procedures ..................................... 15 67 3.5 Receiving procedures ................................... 16 68 3.6 Upstream Neighbor Verification ......................... 16 69 4 Security Considerations ................................ 17 70 5 IANA Considerations .................................... 17 71 6 Acknowledgments ........................................ 17 72 7 References ............................................. 18 73 7.1 Normative References ................................... 18 74 7.2 Informative References ................................. 18 75 8 Authors' Addresses ..................................... 18 76 9 Intellectual Property Notice ........................... 19 77 10 Full Copyright Statement ............................... 19 79 1. Introduction 81 This document defines a means of self test for a Label-Switching 82 Router (LSR) to verify that its dataplane is functioning for certain 83 key Multi-Protocol Label Switching (MPLS) applications including 84 unicast forwarding based on LDP [LDP] and traffic engineering tunnels 85 based on [RSVP-TE]. MPLS Echo Request and MPLS Echo Reply messages 86 [LSP-Ping] messages are extended to do the actual probing. The pings 87 are sent to an upstream neighbor, looped back through the LSR under 88 test and intercepted, by means of TTL expiration by a downstream 89 neighbor. Extensions to LSP-Ping [LSP-Ping] are defined to allow the 90 down stream neighbor to report the test results. 92 In order to minimize the load on upstream LSRs a new loopback FEC is 93 defined. Receipt of a packet labeled with a loopback label will cause 94 the advertising LSR to pop the label off the label stack and send the 95 packet out the advertised interface. 97 Note that use of a loopback allows an LSR to test label entries for 98 which the LSR is not currently some neighbor's next hop. In this way 99 label entries can be verified prior to the occurrence of a routing 100 change. 102 Some routing protocls, most notably OSPF have no means of exchanging 103 the "Link Local Identifiers" used to identify unnumbered links and 104 components of bundled links. These test procedures can be used to 105 associate the neighbor's interfaces with the probing LSRs interfaces. 106 This is achieved by simply having the TTL of the MPLS Ping expire one 107 hop sooner, i.e. at the testing LSR itself. 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 2. Loopback FEC 117 The Loopback FEC type is defined to enable an upstream neighbor to 118 assist in LSR self-testing at very low cost. This FEC causes the 119 loopback to occur in the dataplane without control plane involvement 120 beyond the initial LDP exchange and dataplane setup. 122 An LSR uses the Loopback FEC to selectively advertise loopback labels 123 to its neighbor LSRs. Each loopback label is bound to a particular 124 interface. For multi-access links, a unique label for each neighbor 125 is required, since the link-level address is derived from the label 126 lookup. When an MPLS packet with its top label set to a loopback 127 label is received from an interface over which that label was 128 advertised, the loopback label is popped and the packet is sent on 129 the interface to which the loopback label was bound. 131 TTL treatment for loopback labels follows the Uniform model. I.e. 132 the TTL carried in the loopback label is decremented and copied to 133 the exposed label or IP header as the case may be. 135 2.1. Loopback FEC Element 137 FEC element type 130 is used. The FEC element is encoded as 138 follows: (note: 130 is provisionally assigned, the actual value will 139 be assigned by IANA.) 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | 130 | Res | Interface Type| Id Length | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Interface Identifier | 147 | " | 148 | " | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Reserved (Res) 153 Must be set to zero on transmission and ignored on receipt. 155 Interface Type 157 # Type Interface Identifier 158 --- ---- -------------------- 159 0 Unnumbered A 32 bit Link Identifier as 160 defined in [RFC3477] 161 1 IPv4 Numbered IPv4 Address 162 2 IPv6 Numbered IPv6 Address 164 Identifier Length 166 Length of the interface identifier in octets. 167 The length is 4 bytes for Unnumbered and IPv4, 16 bytes for IPv6. 169 Address 171 An identifier encoded according to the Identifier Type field. 173 2.2. LDP Procedures 175 It is RECOMMENDED that loopback labels only be distributed in 176 response to a Label Request message, irrespective of the label 177 advertisement mode of the LDP session. However it is recognized that 178 in certain cases such as OSPF with unnumbered links, the upstream LSR 179 may not have sufficiently detailed information of the neighbor's link 180 identifier to form the request. In these cases, the downstream LSR 181 will need to be configured to make unsolicited advertisements. 183 3. Data Plane Self Test 185 A self test operation involves three LSRs, the LSR doing the test, an 186 upstream neighbor and a downstream neighbor. We refer to these as 187 LSRs T, U, and D respectively. In order to minimize the processing 188 load on LSRD, two new LSP Ping messages are defined, called the MPLS 189 Data Plane Verification Request and the MPLS Data Plane Verification 190 Reply. These messages are used to allow LSRT to obtain the label 191 stack, address and interface information of LSRD. 193 If FEC verification is required, the MPLS Echo Request and Reply 194 messages are used. 196 The packet flow is shown below. Although the figure shows LSRD 197 adjacent to LSRT it may in some cases be an arbitrary number of hops 198 away. 200 +------+ +------+ +------+ 201 | ,-|-------| | 203 | | | <-|-------| | 627 | | | | 628 +------+ +------+ 629 LSRU LSRT 631 Figure 2: Upstream Neighbor Verification 633 No TLVs need to be included in the MPLS Data Plane Verification 634 Request. By noting the Sender's Handle and Sequence Number, as well 635 as the loopback label, LSRT is able to detect that a) the packet was 636 looped, and b) determine (or verify) the interface on which the 637 packet was received. 639 4. Security Considerations 641 Were loopback labels widely known, they might be subject to abuse. 642 It is therefore RECOMMENDED that loopback labels only be shared 643 between trusted neighbors. Further, if the loopback labels are drawn 644 from the Global Label Space, or any other label space shared across 645 multiple LDP sessions, it is RECOMMENDED that all loopback labels be 646 filtered from a session except those labels pertaining to interfaces 647 directly connected to the neighbor participating in that session. 649 5. IANA Considerations 651 TBD 653 6. Acknowledgments 655 The authors would like to thank Vanson Lim, Tom Nadeau, and Bob 656 Thomas for their comments and suggestions. 658 7. References 660 7.1. Normative References 662 [RFC3036] Andersson, L. et al., "LDP Specification", January 2001. 664 [LSP-Ping] Bonica, R. et al., "Detecting MPLS Data Plane Liveness", 665 work-in-progress. 667 [RFC3477] Kompella, K. & Y. Rekhter, "Signalling Unnumbered Links 668 in Resource ReSerVation Protocol - Traffic Engineering 669 (RSVP-TE)", January 2003. 671 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, March 1997. 674 7.2. Informative References 676 [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP 677 tunnels", RFC 3209, December 2001. 679 8. Authors' Addresses 681 Kireeti Kompella 682 Juniper Networks, Inc. 683 1194 N. Mathilda Ave. 684 Sunnyvale, CA 94089 685 Email: kireeti@juniper.net 687 George Swallow 688 Cisco Systems, Inc. 689 1414 Massachusetts Ave 690 Boxborough, MA 01719 692 Email: swallow@cisco.com 694 Dan Tappan 695 Cisco Systems, Inc. 696 1414 Massachusetts Ave 697 Boxborough, MA 01719 699 Email: tappan@cisco.com 701 9. Intellectual Property Notice 703 The IETF takes no position regarding the validity or scope of any 704 intellectual property or other rights that might be claimed to 705 pertain to the implementation or use of the technology described in 706 this document or the extent to which any license under such rights 707 might or might not be available; neither does it represent that it 708 has made any effort to identify any such rights. Information on the 709 IETF's procedures with respect to rights in standards-track and 710 standards-related documentation can be found in BCP-11 [RFC2028]. 711 Copies of claims of rights made available for publication and any 712 assurances of licenses to be made available, or the result of an 713 attempt made to obtain a general license or permission for the use of 714 such proprietary rights by implementors or users of this 715 specification can be obtained from the IETF Secretariat. The IETF 716 invites any interested party to bring to its attention any 717 copyrights, patents or patent applications, or other proprietary 718 rights that may cover technology that may be required to practice 719 this standard. Please address the information to the IETF Executive 720 Director. 722 10. Full Copyright Statement 724 Copyright (C) The Internet Society (2004). All Rights Reserved. 726 This document and translations of it may be copied and furnished to 727 others, and derivative works that comment on or otherwise explain it 728 or assist in its implementation may be prepared, copied, published 729 and distributed, in whole or in part, without restriction of any 730 kind, provided that the above copyright notice and this paragraph are 731 included on all such copies and derivative works. However, this 732 document itself may not be modified in any way, such as by removing 733 the copyright notice or references to the Internet Society or other 734 Internet organizations, except as needed for the purpose of 735 developing Internet standards in which case the procedures for 736 copyrights defined in the Internet Standards process must be 737 followed, or as required to translate it into languages other than 738 English. 740 The limited permissions granted above are perpetual and will not be 741 revoked by the Internet Society or its successors or assigns. 743 This document and the information contained herein is provided on an 744 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 745 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 746 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 747 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 748 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.