idnits 2.17.1 draft-ankur-mpls-upstream-mapping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 11, 2013) is 3849 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6424' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC6426' is defined on line 325, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 6424 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Working Group A. Saxena 3 Internet-Draft M. Jethanandani 4 Intended status: Standards Track Ciena Corporation 5 Expires: April 14, 2014 October 11, 2013 7 Upstream mapping in Echo Request 8 draft-ankur-mpls-upstream-mapping-00.txt 10 Abstract 12 This document describes an enhancement to the Echo Request and Echo 13 Response message to carry upstream mapping information for co-routed 14 bidirectional MPLS-TP tunnels. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 14, 2014. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 52 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 3 56 3.2. Upstream TLV . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Theory of Operations . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Usefulness of Upstream TLV in a Bidirectional LSP sharing 59 the same path . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 6.1. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.2. New Returns Codes . . . . . . . . . . . . . . . . . . . . 7 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 Detecting MPLS Data Plane Failures [RFC4379] defines mechanisms for 73 collecting downstream mapping information using Downstream Mapping 74 (DSMAP) TLV. However, it does not describe a method by which similar 75 information can be captured for the upstream mapping. An operator 76 would generally be interested in the path taken by a packet in both 77 the downstream and the upstream direction. Currently the only way 78 the operator would be able to get that information would be by 79 running the same command from the other end point. This document 80 describes a method by which both Downstream Mapping (DSMAP) and 81 Upstream Mapping (UPMAP) information can be collected by the same 82 device. 84 1.1. Conventions Used in This Document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119] [RFC2119]. 90 1.2. Abbreviations 92 +--------------+---------------------+ 93 | Abbreviation | Meaning | 94 +--------------+---------------------+ 95 | DSMAP | Downstream Mapping | 96 | | | 97 | LSP | Label Switched Path | 98 | | | 99 | UPMAP | Upstream Mapping | 100 +--------------+---------------------+ 102 2. Motivation 104 Detecting MPLS Data Plane Failures [RFC4379], describes the method by 105 which an operator can find a fault in a bidirectional LSP. The 106 operator starts by issuing a traceroute command from a node in the 107 network to a node that is beyond the failed node. The operator then 108 has to issue the same command from the node that was targeted in the 109 first command. In many cases, the operator does not have access to 110 the other node in the network. The operator is however interested in 111 both the upstream and downstream LSP. This draft suggests a method 112 by which the operator can issue a single traceroute command from one 113 of the nodes in the network and mpls echo request and response packet 114 will carry information to validate both the DSMAP and UPMAP 115 information. The UPMAP can only be used in case of a bidirectional 116 LSP, where the Forward LSP and the Reverse LSP share their path. 117 When used in a non-bidirectional LSP, the UPMAP information will be 118 filled with zeros and SHOULD be ignored on reception. A router that 119 does not support the UPMAP TLV will silently ignore the TLV. 121 3. Packet format 123 The packet format is similar to the packet format described in 124 Section 3 of RCF4379. [RFC4379] 126 This draft proposes to add two new return codes as outlined in 127 section and a new TLV as specified in section . 129 3.1. Return Codes 131 +-------+------------------------------------------+ 132 | Value | Meaning | 133 +-------+------------------------------------------+ 134 | TBD | Upstream Mapping Mismatch | 135 | | | 136 | TBD | Downstream and Upstream Mapping Mismatch | 137 +-------+------------------------------------------+ 139 3.2. Upstream TLV 140 The upstream mapping TLV is an object that MUST be included for all 141 reply modes in the MPLS Echo packet when the operator has requested a 142 traceroute on a bidirectional LSP, where the Forward LSP and Reverse 143 LSP share the same path. The presence of an upstream TLV by the 144 requester means that the replying router SHOULD validate the upstream 145 TLV and if correct, fill the upstream TLV with upstream FEC of the 146 replying router. If incorrect, it should fill the return code with 147 one of the values specified in section to indicate "Upstream Mapping 148 Mismatch" and leave the upstream TLV as is. If the node is an LER 149 router and the upstream TLV is included in the MPLS echo request 150 packet, it SHOULD fill the upstream TLV with the appropriate 151 information and MUST include it in the MPLS echo reply. 153 As defined in RFC 4379, the length of this TLV is K + M + 4*N octets, 154 where M is the Multipath Length, and N is the number of Downstream 155 Labels. Values for K are found in the description of Address Type 156 below. The Value field of a Upstream TLV has the following format: 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 | MTU | Address Type | DS Flags | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Upstream IP Address (4 or 16 octets) | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Upstream Interface Address (4 or 16 octets) | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Multipath Type| Depth Limit | Multipath Length | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 . . 170 . (Multipath Information) . 171 . . 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Upstream Label | Protocol | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 . . 176 . . 177 . . 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Upstream Label | Protocol | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Upstream IP Address and Upstream Interface Address 184 IPv4 addresses and interface indices are encoded in 4 octets; IPv6 185 addresses are encoded in 16 octets. If the interface to the upstream 186 node is numbered, then the Address Type MUST be set to IPv4 or IPv6, 187 the Upstream IP Address MUST be set to either the Upstream node's 188 Router ID or the interface address of the Upstream node, and the 189 Upstream Interface Address MUST be set to the upstream node's 190 interface address. If the interface to the upstream node is 191 unnumbered, the Address Type MUST be IPv4 Unnumbered or IPv6 192 Unnumbered, the Upstream IP Address MUST be the upstream node's 193 Router ID, and the Upstream Interface Address MUST be set to the 194 index assigned by the node to the interface. 196 If a node does not know the IP address of its neighbor, then it MUST 197 set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. 198 For IPv4, it must set the Upstream IP Address to 127.0.0.1; for IPv6 199 the address is set to 0::1. In both cases, the interface index MUST 200 be set to 0. 202 Upstream Label(s) 204 The set of labels in the label stack should appear as if this router 205 were forwarding the packet through this interface. Any Implicit Null 206 labels are explicitly included. Labels are treated as numbers, i.e., 207 they are right justified in the field. 209 A Upstream Label is 24 bits, in the same format as an MPLS label 210 minus the TTL field, i.e., the MSBit of the label is bit 0, the LSBit 211 is bit 19, the EXP bits are bits 20-22, and bit 23 is the S bit. The 212 replying router SHOULD fill in the EXP and S bits; the LSR receiving 213 the echo reply MAY choose to ignore these bits. 215 For explanation of rest of the fields in the Upstream TLV please 216 refer section 3.3 of Detecting MPLS Data Plane Failures [RFC4379]. 218 4. Theory of Operations 220 4.1. Usefulness of Upstream TLV in a Bidirectional LSP sharing the same 221 path 223 The Upstream TLV MUST only be used in case of a bidirectional LSP 224 where Forward and Reverse Paths are same, for example, MPLS-TP Co- 225 routed tunnels or Multisegment Pseudo wire. In which case, the 226 transit nodes will know all the information required to fill both the 227 Downstream Mapping TLV and Upstream TLV. 229 Consider the following example: 231 +------+L0 L0+------+L1 L1+------+ 232 | |------------>| |----------->| | 233 | LER1 | | LSR1 | | LER2 | 234 | |<------------| |<-----------| | 235 +------+L3 L3+------+L2 L2+------+ 237 In the above fig, LER1 is the ingress node with forward out going 238 label L0 and reverse in coming label of L3. LSR1 is the transit 239 router with forward incoming and outgoing labels as L0 and L1 240 respectively and reverse incoming and outgoing labels of L2 and L3 241 respectively. LER2 is the egress router with forward incoming label 242 of L1 and reverse outgoing label of L2. 244 The ingress node SHOULD fill its Downstream TLV for label L0 and 245 Upstream TLV for label L3. When this MPLS Echo request packet 246 (containing the Upstream TLV and the DownStream TLV) reaches the 247 transit node, then the node validates both Upstream TLV for label L3 248 and Downstream TLV for Label L0. If the Downstream TLV for label L0 249 specified in the packet does not match the information the transit 250 node has, then the transit node sends a return code specifying 251 Downstream TLV mismatch. Similarly, if the Upstream TLV specified in 252 the packet does not match the Upstream information the transit node 253 has, then the transit node SHOULD send a return code of Upstream TLV 254 mismatch. If both, the Upstream TLV and Downstream TLV does not 255 match then the transit node should send a return code of Upstream and 256 Downstream TLV mismatch. And if both the TLVs match then the transit 257 node populates it's Downstream Mapping for label L1 and the Upstream 258 Mapping for label L2 and sends the reply back to the ingress node. 259 The ingress node uses this new Downstream TLV and Upstream TLV in 260 it's next Echo Request packet. The egress node on receiving the Echo 261 Request packet validates Upstream TLV and Downstream TLV. If both 262 the TLVs match then the egress node SHOULD send a return code of 263 Replying router is egress, else it SHOULD send the return code 264 depending on which TLV did not match. 266 In case a bidirectional LSP does not share the Forward and Reverse 267 path, for example, MPLS-TP Associated LSPs, traceroute SHOULD NOT add 268 Upstream TLV as part of the MPLS Echo Request. If the Forward and 269 Reverse LSPs are not on the same node then the transit node of the 270 Forward LSP won't have any information to fill the Upstream TLV. 272 5. Security Considerations 274 Security considerations, as discussed in Detecting MPLS Data Plane 275 Failures [RFC4379], are applicable to this document. 277 6. IANA Considerations 279 6.1. New TLV 281 IANA would have to assign a new TLV value to the following TLV from 282 the "Multiprotocol Label Switching Architecture (MPLS) Label Switched 283 Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub- 284 registry. 286 Upstream Detailed Mapping TLV (see Section ). 288 6.2. New Returns Codes 290 IANA needs to assign a new Return Code values from the "Multi- 291 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 292 Parameters" registry, "Return Codes" sub-registry, as follows using a 293 Standards Action value. 295 +-------+------------------------------------------+ 296 | Value | Meaning | 297 +-------+------------------------------------------+ 298 | TBD | Upstream mapping mismatch | 299 | | | 300 | TBD | Downstream and Upstream mapping mismatch | 301 +-------+------------------------------------------+ 303 7. Acknowledgements 305 We would like to thank Ashesh Mishra and Vijay D'Souza for their 306 feedback on this draft. 308 8. References 310 8.1. Normative References 312 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 313 Label Switched (MPLS) Data Plane Failures", RFC 4379, 314 February 2006. 316 8.2. Informative References 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, March 1997. 321 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 322 Performing Label Switched Path Ping (LSP Ping) over MPLS 323 Tunnels", RFC 6424, November 2011. 325 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 326 On-Demand Connectivity Verification and Route Tracing", 327 RFC 6426, November 2011. 329 Authors' Addresses 331 Ankur Saxena 332 Ciena Corporation 333 3939 N. First Street 334 San Jose, CA 95134 335 USA 337 Phone: +1 (408) 904-2109 338 Email: ankurpsaxena@gmail.com 340 Mahesh Jethanandani 341 Ciena Corporation 342 3939 N. First Street 343 San Jose, CA 95134 344 USA 346 Phone: +1 (408) 904-2160 347 Email: mjethanandani@gmail.com