idnits 2.17.1 draft-ietf-mpls-lsr-self-test-01.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 6 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 272 has weird spacing: '...Request messa...' == Line 284 has weird spacing: '...Request messa...' -- 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 2003) is 7497 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 82, but not defined == Missing Reference: 'LSP-PING' is mentioned on line 243, but not defined == Unused Reference: 'RFC3036' is defined on line 632, 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 (==), 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: April 2004 5 Kireeti Kompella 6 Juniper Networks, Inc. 8 Dan Tappan 9 Cisco Systems, Inc. 11 October 2003 13 Label Switching Router Self-Test 15 draft-ietf-mpls-lsr-self-test-01.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 (2003). 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 actually 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 ....... 6 60 3.2 Next Hop Verification Object ........................... 8 61 3.2.1 IPv4 Next Hop Verification Object ...................... 8 62 3.2.2 IPv6 Next Hop Verification Object ...................... 11 63 3.3 Reply-To Object ........................................ 13 64 3.3.1 IPv4 Reply-To Object ................................... 13 65 3.3.2 IPv6 Reply-To Object ................................... 14 66 3.3.3 Sending procedures ..................................... 15 67 3.4 Receiving procedures ................................... 15 68 3.5 Upstream Neighbor Verification ......................... 15 69 4 Security Considerations ................................ 16 70 5 IANA Considerations .................................... 16 71 6 Acknowledgments ........................................ 16 72 7 References ............................................. 17 73 7.1 Normative References ................................... 17 74 7.2 Informative References ................................. 17 75 8 Authors' Addresses ..................................... 17 77 1. Introduction 79 This document defines a means of self test for a Label-Switching 80 Router (LSR) to verify that its dataplane is functioning for certain 81 key Multi-Protocol Label Switching (MPLS) applications including 82 unicast forwarding based on LDP [LDP] and traffic engineering tunnels 83 based on [RSVP-TE]. MPLS Echo Request and MPLS Echo Reply messages 84 [LSP-Ping] messages are extended to do the actually probing. The 85 pings are sent to an upstream neighbor, looped back through the LSR 86 under test and intercepted, by means of TTL expiration by a 87 downstream neighbor. Extensions to LSP-Ping are defined to allow the 88 down stream neighbor to report the test results. 90 In order to minimize the load on upstream LSRs a new loopback FEC is 91 defined. Receipt of a packet labeled with a loopback label will cause 92 the advertising LSR to pop the label off the label stack and send the 93 packet out the advertised interface. 95 Note that use of a loopback allows an LSR to test label entries for 96 which the LSR is not currently some neighbor's next hop. In this way 97 label entries can be verified prior to the occurrence of a routing 98 change. 100 Some routing protocls, most notably OSPF have no means of exchanging 101 the "Link Local Identifiers" used to identify unnumbered links and 102 components of bundled links. These test procedures can be used to 103 associate the neighbor's interfaces with the probing LSRs interfaces. 104 This is achieved by simply having the TTL of the MPLS Ping expire one 105 hop sooner, i.e. at the testing LSR itself. 107 1.1. Conventions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 113 2. Loopback FEC 115 The Loopback FEC type is defined to enable an upstream neighbor to 116 assist in LSR self-testing at very low cost. This FEC causes the 117 loopback to occur in the dataplane without control plane involvement 118 beyond the initial LDP exchange and dataplane setup. 120 An LSR uses the Loopback FEC to selectively advertise loopback labels 121 to its neighbor LSRs. Each loopback label is bound to a particular 122 interface. For multi-access links, a unique label for each neighbor 123 is required, since the link-level address is derived from the label 124 lookup. When an MPLS packet with its top label set to a loopback 125 label is received from an interface over which that label was 126 advertised, the loopback label is popped and the packet is sent on 127 the interface to which the loopback label was bound. 129 TTL treatment for loopback labels follows the Uniform model. I.e. 130 the TTL carried in the loopback label is decremented and copied to 131 the exposed label or IP header as the case may be. 133 2.1. Loopback FEC Element 135 FEC element type 130 is used. The FEC element is encoded as 136 follows: (note: 130 is provisionally assigned, the actual value will 137 be assigned by IANA.) 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | 130 | Res | Interface Type| Id Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Interface Identifier | 145 | " | 146 | " | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Reserved (Res) 151 Must be set to zero on transmission and ignored on receipt. 153 Interface Type 155 # Type Interface Identifier 156 --- ---- -------------------- 157 0 Unnumbered A 32 bit Link Identifier as 158 defined in [RFC3477] 159 1 IPv4 Numbered IPv4 Address 160 2 IPv6 Numbered IPv6 Address 162 Identifier Length 164 Length of the interface identifier in octets. 165 The length is 4 bytes for Unnumbered and IPv4, 16 bytes for IPv6. 167 Address 169 An identifier encoded according to the Identifier Type field. 171 2.2. LDP Procedures 173 It is RECOMMENDED that loopback labels only be distributed in 174 response to a Label Request message, irrespective of the label 175 advertisement mode of the LDP session. However it is recognized that 176 in certain cases such as OSPF with unnumbered links, the upstream LSR 177 may not have sufficiently detailed information of the neighbors link 178 identifier to form the request. In these cases, the downstream LSR 179 will need to be configured to make unsolicited advertisements. 181 3. Data Plane Self Test 183 A self test operation involves three LSRs, the LSR doing the test, an 184 upstream neighbor and a downstream neighbor. We refer to these as 185 LSRs T, U, and D respectively. In order to minimize the processing 186 load on LSRD, two new LSP Ping messages are defined, called the MPLS 187 Data Plane Verification Request and the MPLS Data Plane Verification 188 Reply. These messages are used to allow LSRT to obtain the label 189 stack and address and interface information of LSRD. 191 If FEC verification is required, the MPLS Echo Request and Reply 192 messages are used. 194 The packet flow is shown below. Although the figure shows LSRD 195 adjacent to LSRT it may in some cases be an arbitrary number of hops 196 away. 198 +------+ +------+ +------+ 199 | ,-|-------| | 201 | | | <-|-------| | 597 | | | | 598 +------+ +------+ 599 LSRU LSRT 601 Figure 2: Upstream Neighbor Verification 603 No TLVs need to be included in the MPLS Data Plane Verification 604 Request. By noting the Sender's Handle and Sequence Number, as well 605 as the loopback label, LSRT is able to detect that a) the packet was 606 looped, and b) determine (or verify) the interface on which the 607 packet was received. 609 4. Security Considerations 611 Were loopback labels widely known, they might be subject to abuse. 612 It is therefore RECOMMENDED that loopback labels only be shared 613 between trusted neighbors. Further, if the loopback labels are drawn 614 from the Global Label Space, or any other label space shared across 615 multiple LDP sessions, it is RECOMMENDED that all loopback label be 616 filtered from a session except those labels pertaining to interfaces 617 directly connected to the neighbor participating in that session. 619 5. IANA Considerations 621 TBD 623 6. Acknowledgments 625 The authors would like to thank Vanson Lim, Tom Nadeau, and Bob 626 Thomas for their comments and suggestions. 628 7. References 630 7.1. Normative References 632 [RFC3036] Andersson, L. et al., "LDP Specification", January 2001. 634 [LSP-Ping] Bonica, R. et al., "Detecting MPLS Data Plane Liveness", 635 work-in-progress. 637 [RFC3477] Kompella, K. & Y. Rekhter, "Signalling Unnumbered Links 638 in Resource ReSerVation Protocol - Traffic Engineering 639 (RSVP-TE)", January 2003. 641 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 7.2. Informative References 646 [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP 647 tunnels", RFC 3209, December 2001. 649 8. Authors' Addresses 651 Kireeti Kompella 652 Juniper Networks, Inc. 653 1194 N. Mathilda Ave. 654 Sunnyvale, CA 94089 655 Email: kireeti@juniper.net 657 George Swallow 658 Cisco Systems, Inc. 659 1414 Massachusetts Ave 660 Boxborough, MA 01719 662 Email: swallow@cisco.com 664 Dan Tappan 665 Cisco Systems, Inc. 666 1414 Massachusetts Ave 667 Boxborough, MA 01719 669 Email: tappan@cisco.com