idnits 2.17.1 draft-ietf-mpls-lsr-self-test-00.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 : ---------------------------------------------------------------------------- ** 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 191 has weird spacing: '...r Type field...' == Line 192 has weird spacing: '... The lengt...' -- 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 7499 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 105, but not defined == Unused Reference: 'RFC3036' is defined on line 420, 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: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 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: April 2004 6 Kireeti Kompella 7 Juniper Networks, Inc. 9 Dan Tappan 10 Cisco Systems, Inc. 12 October 2003 14 Label Switching Router Self-Test 16 draft-ietf-mpls-lsr-self-test-00.txt 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 This document defines a means of self test for a Label-Switching 44 Router (LSR) to verify that its dataplane is functioning for 45 certain key Multi-Protocol Label Switching (MPLS) applications 46 including unicast forwarding based on LDP [LDP] and traffic 47 engineering tunnels based on [RSVP-TE]. A new Loopback FEC type 48 is defined to allow an upstream neighbor to assist in the testing 49 at very low cost. MPLS Echo Request and MPLS Echo Reply messages 50 [LSP-Ping] messages are extended to do the actually probing. 52 Contents 54 1 Introduction ........................................... 4 55 1.1 Conventions ............................................ 4 56 2 Loopback FEC ........................................... 5 57 2.1 Loopback FEC Element ................................... 5 58 2.2 LDP Procedures ......................................... 6 59 3 Data Plane Self Test ................................... 6 60 3.1 Next Hop Verification Object ........................... 7 61 3.2 Additional Error Codes ................................. 9 62 3.3 Sending procedures ..................................... 9 63 3.4 Receiving procedures ................................... 10 64 3.5 Upstream Neighbor Verification ......................... 11 65 4 Security Considerations ................................ 11 66 5 IANA Considerations .................................... 12 67 6 Acknowledgments ........................................ 12 68 7 References ............................................. 12 69 7.1 Normative References ................................... 12 70 7.2 Informative References ................................. 12 71 8 Authors' Addresses ..................................... 13 73 0. Sub-IP ID Summary 75 (This section to be removed before publication.) 77 (See Abstract above.) 79 RELATED DOCUMENTS 81 May be found in the "references" section. 83 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 85 Fits in the MPLS box. 87 WHY IS IT TARGETED AT THIS WG 89 MPLS WG is currently looking at MPLS-specific error detection and 90 recovery mechanisms. The mechanisms proposed here are for packet- 91 based MPLS LSPs, which is why the MPLS WG is targeted. 93 JUSTIFICATION 95 The WG should consider this document, as it allows network 96 operators to detect MPLS LSP data plane failures in the network. 97 This type of failures have occurred, and are a source of concern 98 to operators implementing MPLS networks. 100 1. Introduction 102 This document defines a means of self test for a Label-Switching 103 Router (LSR) to verify that its dataplane is functioning for certain 104 key Multi-Protocol Label Switching (MPLS) applications including 105 unicast forwarding based on LDP [LDP] and traffic engineering tunnels 106 based on [RSVP-TE]. MPLS Echo Request and MPLS Echo Reply messages 107 [LSP-Ping] messages are extended to do the actually probing. The 108 pings are sent to an upstream neighbor, looped back through the LSR 109 under test and intercepted, by means of TTL expiration by a 110 downstream neighbor. Extensions to LSP-Ping are defined to allow the 111 down stream neighbor to verify the test results. 113 In order to minimize the load on upstream LSRs a new loopback FEC is 114 defined. Receipt of a packet labeled with a loopback label will cause 115 the advertising LSR to pop the label off the label stack and send the 116 packet out the advertised interface. 118 Note that use of a loopback allows an LSR to label entries for which 119 the LSR is not currently its potential upstream neighbor's next hop. 120 In this way label entries can be verified prior to the occurrence of 121 a routing change. 123 Some routing protocls, most notably OSPF have no means of exchanging 124 "Link Local Identifiers" used to identify unnumbered links and 125 components of bundled links. These same test procedures can be used 126 to associate the neighbor's interfaces with the probing LSRs 127 interfaces. This is achieved by simply having the TTL of the MPLS 128 Ping expire one hop sooner, i.e. at the testing LSR itself. 130 1.1. Conventions 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 136 2. Loopback FEC 138 The Loopback FEC type is defined to enable an upstream neighbor to 139 assist in the LSR self-testing at very low cost. This FEC allows the 140 loopback to occur in the dataplane without control plane involvement 141 beyond the initial LDP exchange and dataplane setup. 143 An LSR uses the Loopback FEC to selectively advertise loopback labels 144 to its neighbor LSRs. Each loopback label is bound to a particular 145 interface. For multiaccess links, one label per neighbor is required 146 since the link-level address is derived from the label lookup. When 147 an MPLS packet with its top label set to a loopback label is received 148 from an interface over which that label was advertised, the loopback 149 label is popped and the packet is sent on the interface to which the 150 loopback label was bound. 152 TTL treatment for loopback labels follows the Uniform model. I.e. 153 the TTL carried in the loopback label is decremented and copied to 154 the exposed label or IP header as the case may be. 156 2.1. Loopback FEC Element 158 FEC element type 130 is used. The FEC element is encoded as 159 follows: (note: 130 is provisionally assigned, the actual value will 160 be assigned by IANA.) 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | 130 | Res | Interface Type| Id Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Interface Identifier | 168 | " | 169 | " | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Reserved 174 Must be set to zero on transmission and ignored on receipt. 176 Interface Type 178 # Type Interface Identifier 179 --- ---- -------------------- 180 0 Unnumbered A 32 bit Link Identifier as 181 defined in [RFC3477] 182 1 IPv4 Numbered IPv4 Address 183 2 IPv6 Numbered IPv6 Address 185 Identifier Length 187 Length of the interface identifier in octets. 189 Address 191 An identifier encoded according to the Identifier Type field. 192 The length is 4 bytes for Unnumbered and IPv4, 16 bytes for 193 IPv6. 195 2.2. LDP Procedures 197 It is RECOMMENDED that loopback labels only be distributed in 198 response to a Label Request message, irrespective of the label 199 advertisement mode of the LDP session. However it is recognized that 200 in certain cases such as OSPF with unnumbered links, the upstream LSR 201 may not have sufficiently detailed information of the neighbors link 202 identifier to form the request. In these cases, the downstream LSR 203 will need to be configured to make unsolicited advertisements. 205 3. Data Plane Self Test 207 A self test operation involves three LSRs, the LSR doing the test, an 208 upstream neighbor and a downstream neighbor. We refer to these as 209 LSRs T, U, and D respectively. The packet flow is shown below. 210 Although the figure shows LSRD adjacent to LSRT it may in some cases 211 be an arbitrary number of hops away. 213 +------+ +------+ +------+ 214 | ,-|-------|- | 216 | | | <-|-------|- | | | 383 | | | | | | 384 +------+ +------+ +------+ 385 LSRU LSRT LSRD 387 Figure 2: Upstream Neighbor Verification 389 No TLVs need to be included in the MPLS Echo Request. By noting the 390 Sender's Handle and Sequence Number, as well as the loopback label, 391 LSRT is able to detect that a) the packet was looped, and b) 392 determine (or verify) the interface on which the packet was received. 393 A Next Hop Verification TLV may be included to assist in 394 verification. This may be particularly useful in a system where 395 control is distributed over multiple processor. 397 4. Security Considerations 399 Were loopback labels widely known, they might be subject to abuse. 400 It is therefore RECOMMENDED that loopback labels only be shared 401 between trusted neighbors. Further, if the loopback labels are drawn 402 from the Global Label Space, or any other label space shared across 403 multiple LDP sessions, it is RECOMMENDED that all loopback label be 404 filtered from a session except those labels pertaining to interfaces 405 directly connected to the neighbor participating in that session. 407 5. IANA Considerations 409 TBD 411 6. Acknowledgments 413 The authors would like to thank Vanson Lim, Tom Nadeau, and Bob 414 Thomas for their comments and suggestions. 416 7. References 418 7.1. Normative References 420 [RFC3036] Andersson, L. et al., "LDP Specification", January 2001. 422 [LSP-Ping] Bonica, R. et al., "Detecting MPLS Data Plane Liveness", 423 work-in-progress. 425 [RFC3477] Kompella, K. & Y. Rekhter, "Signalling Unnumbered Links 426 in Resource ReSerVation Protocol - Traffic Engineering 427 (RSVP-TE)", January 2003. 429 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, March 1997. 432 7.2. Informative References 434 [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP 435 tunnels", RFC 3209, December 2001. 437 8. Authors' Addresses 439 Kireeti Kompella 440 Juniper Networks, Inc. 441 1194 N. Mathilda Ave. 442 Sunnyvale, CA 94089 443 Email: kireeti@juniper.net 445 George Swallow 446 Cisco Systems, Inc. 447 1414 Massachusetts Ave 448 Boxborough, MA 01719 450 Email: swallow@cisco.com 452 Dan Tappan 453 Cisco Systems, Inc. 454 1414 Massachusetts Ave 455 Boxborough, MA 01719 457 Email: tappan@cisco.com