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