idnits 2.17.1 draft-ietf-mpls-lsp-ping-enhanced-dsmap-11.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4379, but the abstract doesn't seem to directly say this. It does mention RFC4379 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4379, updated by this document, for RFC5378 checks: 2002-03-27) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 10, 2011) is 4584 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) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Bahadur 3 Internet-Draft K. Kompella 4 Updates: 4379 (if approved) Juniper Networks, Inc. 5 Intended status: Standards Track G. Swallow 6 Expires: March 13, 2012 Cisco Systems 7 September 10, 2011 9 Mechanism for performing LSP-Ping over MPLS tunnels 10 draft-ietf-mpls-lsp-ping-enhanced-dsmap-11 12 Abstract 14 This document describes methods for performing LSP-Ping (specified in 15 RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched 16 MPLS label-switched-paths (LSPs). The techniques outlined in RFC 17 4379 are insufficient to perform traceroute Forwarding Equivalency 18 Class (FEC) validation and path discovery for an LSP that goes over 19 other MPLS tunnels or for a stitched LSP. This document describes 20 enhancements to the downstream-mapping TLV (defined in RFC 4379). 21 These enhancements along with other procedures outlined in this 22 document can be used to trace such LSPs. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 13, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Conventions used in this document . . . . . . . . . . . . 4 72 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.2. New Return Codes . . . . . . . . . . . . . . . . . . . . . 6 76 3.2.1. Return code per downstream . . . . . . . . . . . . . . 6 77 3.2.2. Return code for stitched LSPs . . . . . . . . . . . . 6 78 3.3. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 7 79 3.3.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . 9 80 3.3.1.1. Multipath data sub-TLV . . . . . . . . . . . . . . 9 81 3.4. Deprecation of Downstream Mapping TLV . . . . . . . . . . 13 82 4. Performing MPLS traceroute on tunnels . . . . . . . . . . . . 13 83 4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 13 84 4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 13 85 4.1.2. Transition between tunnels . . . . . . . . . . . . . . 14 86 4.1.3. Modification to FEC Validation procedure on Transit . 16 87 4.2. Modification to FEC Validation procedure on Egress . . . . 16 88 4.3. Ingress node procedure . . . . . . . . . . . . . . . . . . 16 89 4.3.1. Processing Downstream Detailed Mapping TLV . . . . . . 17 90 4.3.1.1. Stack Change sub-TLV not present . . . . . . . . . 17 91 4.3.1.2. Stack Change sub-TLV(s) present . . . . . . . . . 17 92 4.3.2. Modifications to handling to Return Code 3 reply. . . 19 93 4.3.3. Handling of new return codes . . . . . . . . . . . . . 19 94 4.4. Handling deprecated Downstream Mapping TLV . . . . . . . . 19 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 97 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 100 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 This documents describes methods for performing LSP-Ping (specified 106 in [RFC4379]) traceroute over MPLS tunnels. The techniques in 107 [RFC4379] outline a traceroute mechanism that includes Forwarding 108 Equivalency Class (FEC) validation and Equal Cost Multi-Path (ECMP) 109 path discovery. Those mechanisms are insufficient and do not provide 110 details when the FEC being traced traverses one or more MPLS tunnels 111 and when label-switched-path (LSP) stitching [RFC5150] is in use. 112 This document defines enhancements to the downstream-mapping TLV 113 [RFC4379] to make it more extensible and to enable retrieval of 114 detailed information. Using the enhanced TLV format along with the 115 existing definitions of [RFC4379], this document describes procedures 116 by which a traceroute request can correctly traverse MPLS tunnels 117 with proper FEC and label validations. 119 1.1. Conventions used in this document 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 2. Motivation 127 A LSP-Ping traceroute may cross multiple MPLS tunnels en-route the 128 destination. Let us consider a simple case. 130 A B C D E 131 o -------- o -------- o --------- o --------- o 132 \_____/ | \______/ \______/ | \______/ 133 LDP | RSVP RSVP | LDP 134 | | 135 \____________________/ 136 LDP 138 Figure 1: LDP over RSVP tunnel 140 When a traceroute is initiated from router A, router B returns 141 downstream mapping information for node C in the MPLS echo reply. 142 The next MPLS echo request reaches router C with a LDP FEC. Node C 143 is a pure RSVP node and does not run LDP. Node C will receive the 144 MPLS echo request with 2 labels but only 1 FEC in the Target FEC 145 stack. Consequently, node C will be unable to perform FEC complete 146 validation. It will let the trace continue by just providing next- 147 hop information based on incoming label, and by looking up the 148 forwarding state associated with that label. However, ignoring FEC 149 validation defeats the purpose of control plane validatations. The 150 MPLS echo request should contain sufficient information to allow node 151 C to perform FEC validations to catch any misrouted echo-requests. 153 The above problem can be extended for a generic case of hierarchical 154 tunnels or stitched tunnels (e.g. B-C can be a separate RSVP tunnel 155 and C-D can be a separate RSVP tunnel). The problem of FEC 156 validation for tunnels can be solved if the transit routers (router B 157 in the above example) provide some information to the ingress 158 regarding the start of a new tunnel. 160 Stitched LSPs involve 2 or more LSP segments stitched together. The 161 LSP segments can be signaled using the same or different signaling 162 protocols. In order to perform an end-to-end trace of a stitched 163 LSP, the ingress needs to know FEC information regarding each of the 164 stitched LSP segments. For example, consider the figure below. 166 A B C D E F 167 o -------- o -------- o --------- o -------- o ------- o 168 \_____/ \______/ \______/ \______/ \_______/ 169 LDP LDP BGP RSVP RSVP 171 Figure 2: Stitched LSP 173 Consider ingress (A) tracing end-to-end stitched LSP A--F. When an 174 MPLS echo request reaches router C, there is a FEC stack change 175 happening at router C. With current LSP-Ping [RFC4379] mechanisms, 176 there is no way to convey this information to A. Consequently, when 177 the next echo request reaches router D, router D will know nothing 178 about the LDP FEC that A is trying to trace. 180 Thus, the procedures defined in [RFC4379] do not make it possible for 181 the ingress node to: 183 1. Know that tunneling has occured 184 2. Trace the path of the tunnel 185 3. Trace the path of stitched LSPs 187 3. Packet format 188 3.1. Introduction 190 In many cases there has been a need to associate additional data in 191 the MPLS echo reply. In most cases, the additional data needs to be 192 associated on a per downstream neighbor basis. Currently, the MPLS 193 echo reply contains one downstream map TLV (DSMAP) per downstream 194 neighbor. However the DSMAP format is not extensible and hence it is 195 not possible to associate more information with a downstream 196 neighbor. This draft defines a new extensible format for the DSMAP 197 and provides mechanisms for solving the tunneled LSP-Ping problem 198 using the new format. In summary, the draft makes the following TLV 199 changes: 201 o Addition of new Downstream Detailed Mapping TLV (DDMAP). 202 o Deprecation of existing Downstream Mapping TLV (DSMAP). 203 o Addition of Downstream FEC Stack Change Sub-TLV to DDMAP. 205 3.2. New Return Codes 207 3.2.1. Return code per downstream 209 A new Return Code is being defined "See DDM TLV for Return Code and 210 Return SubCode" (Section 6.3) to indicate that the Return Code is per 211 Downstream Detailed Mapping TLV (Section 3.3). This Return Code MUST 212 be used only in the message header and MUST be set only in the MPLS 213 echo reply message. If the Return Code is set in the MPLS echo 214 request message, then it MUST be ignored. When this Return Code is 215 set, each Downstream Detailed Mapping TLV MUST have an appropriate 216 Return Code and Return SubCode. This Return Code MUST be used when 217 there are multiple downstreams for a given node (such as P2MP or 218 ECMP), and the node needs to return a Return Code/Return SubCode for 219 each downstream. This Return Code MAY be used even when there is 220 only 1 downstream for a given node. 222 3.2.2. Return code for stitched LSPs 224 When a traceroute is being performed on stitched LSPs (Section 4.1.2) 225 the stitching point SHOULD indicate the stitching action to the node 226 performing the trace. This is done by setting the Return Code to 227 "Label switched with FEC change" (Section 6.3). If a node is 228 performing FEC hiding, then it MAY choose to set the Return Code to a 229 value (specified in [RFC4379]) other than "Label switched with FEC 230 change". The Return Code of "Label switched with FEC change" MUST 231 NOT be used if no FEC Stack sub-TLV (Section 3.3.1.3) is present in 232 the Downstream Detailed Mapping TLV(s). This new Return Code MAY be 233 used for hierarchical LSPs (for indicating start or end of an outer 234 LSP). 236 3.3. Downstream Detailed Mapping TLV 238 Type # Value Field 239 ------ ------------ 241 TBD Downstream detailed mapping 243 The Downstream Detailed Mapping object is a TLV that MAY be included 244 in an MPLS echo request message. Only one Downstream Detailed 245 Mapping object may appear in an echo request. The presence of a 246 Downstream Detailed Mapping object is a request that Downstream 247 Detailed Mapping objects be included in the MPLS echo reply. If the 248 replying router is the destination (Label Edge Router) of the FEC, 249 then a Downstream Detailed Mapping TLV SHOULD NOT be included in the 250 MPLS echo reply. Otherwise the replying router SHOULD include a 251 Downstream Detailed Mapping object for each interface over which this 252 FEC could be forwarded. 254 0 1 2 3 255 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 2 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | MTU | Address Type | DS Flags | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Downstream Address (4 or 16 octets) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Downstream Interface Address (4 or 16 octets) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Return Code | Return SubCode| Sub-tlv length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 . . 266 . List of Sub TLVs . 267 . . 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 3: Downstream Detailed Mapping TLV 272 The Downstream Detailed Mapping TLV format is derived from the 273 Downstream Mapping TLV format. The key change is that variable 274 length and optional fields have been converted into sub-TLVs. The 275 fields have the same use and meaning as in [RFC4379]. A summary of 276 the fields taken from Downstream Mapping TLV is as below: 278 Maximum Transmission Unit (MTU) 279 The MTU is the size in octets of the largest MPLS frame (including 280 label stack) that fits on the interface to the Downstream LSR. 282 Address Type 284 The Address Type indicates if the interface is numbered or 285 unnumbered. It also determines the length of the Downstream IP 286 Address and Downstream Interface fields. 288 DS Flags 290 The DS Flags field is a bit vector of various flags. 292 Downstream Address and Downstream Interface Address 294 IPv4 addresses and interface indices are encoded in 4 octets; IPv6 295 addresses are encoded in 16 octets. For details regarding setting 296 the address value, refer to [RFC4379]. 298 The newly added sub-TLVs and their fields are as described below. 300 Return code 301 The Return Code is set to zero by the sender. The receiver can 302 set it to one of the values specified in the "Multi-Protocol Label 303 Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry, 304 "Return Codes" sub-registry. 306 If the receiver sets a non-zero value of the Return Code field in 307 the Downstream Detailed Mapping TLV, then the receiver MUST also 308 set the Return Code field in the echo reply header to "See DDM TLV 309 for Return Code and Return SubCode" (Section 6.3). An exception 310 to this is if the receiver is a bud node [RFC4461] and is replying 311 as both an egress and a transit node with a Return Code of 3 312 ("Replying router is an egress for the FEC") in the echo reply 313 header. 315 If the Return Code of the echo reply message is not set to either 316 "See DDM TLV for Return Code and Return SubCode" (Section 6.3) or 317 "Replying router is an egress for the FEC", then the Return Code 318 specified in the Downstream Detailed Mapping TLV MUST be ignored. 320 Return SubCode 322 The Return SubCode is set to zero by the sender. The receiver can 323 set it to one of the values specified in the "Multi-Protocol Label 324 Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry, 325 "Return Codes" sub-registry. This field is filled in with the 326 stack-depth for those codes that specify that. For all other 327 codes, the Return SubCode MUST be set to zero. 329 If the Return Code of the echo reply message is not set to either 330 "See DDM TLV for Return Code and Return SubCode" (Section 6.3) or 331 "Replying router is an egress for the FEC", then the Return 332 SubCode specified in the Downstream Detailed Mapping TLV MUST be 333 ignored. 335 Sub-tlv length 336 Total length in bytes of the sub-TLVs associated with this TLV. 338 3.3.1. Sub-TLVs 340 This section defines the Sub-TLVs that MAY be included as part of the 341 Downstream Detailed Mapping TLV. 343 Sub-Type Value Field 344 --------- ------------ 345 TBD Multipath data 346 TBD Label stack 347 TBD FEC Stack change 349 3.3.1.1. Multipath data sub-TLV 351 0 1 2 3 352 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 2 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 |Multipath Type | Multipath Length |Reserved (MBZ) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | | 357 | (Multipath Information) | 358 | | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Figure 4: Multipath Sub-TLV 363 The multipath data sub-TLV includes multipath information. The sub- 364 TLV fields and their usage is as defined in [RFC4379]. A brief 365 summary of the fields is as below: 367 Multipath Type 368 The type of the encoding for the Multipath Information. 370 Multipath Length 372 The length in octets of the Multipath Information. 374 Multipath Information 376 Encoded multipath data, according to the Multipath Type. 378 3.3.1.2. Label stack sub-TLV 380 0 1 2 3 381 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 2 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Downstream Label | Protocol | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 . . 386 . . 387 . . 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Downstream Label | Protocol | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 5: Label Stack Sub-TLV 394 The Label stack sub-TLV contains the set of labels in the label stack 395 as it would have appeared if this router were forwarding the packet 396 through this interface. Any Implicit Null labels are explicitly 397 included. The number of label/protocol pairs present in the sub-TLV 398 is determined based on the sub-TLV data length. The label format and 399 protocol type are as defined in [RFC4379]. When the Downstream 400 Detailed Mapping TLV is sent in the echo reply, this sub-TLV MUST be 401 included. 403 Downstream Label 405 A Downstream Label is 24 bits, in the same format as an MPLS label 406 minus the TTL field, i.e., the MSBit of the label is bit 0, the 407 LSBit is bit 19, the EXP bits are bits 20-22, and bit 23 is the S 408 bit. The replying router SHOULD fill in the EXP and S bits; the 409 LSR receiving the echo reply MAY choose to ignore these bits. 411 Protocol 412 This specifies the label distribution protocol for the downstream 413 label. 415 3.3.1.3. FEC Stack change sub-TLV 417 A router MUST include the FEC Stack change sub-TLV when the 418 downstream node in the echo reply has a different FEC Stack than the 419 FEC stack received in the echo request. One or more FEC Stack change 420 sub-TLVs MAY be present in the Downstream Detailed Mapping TLV. The 421 format is as below. 423 0 1 2 3 424 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 2 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 |Operation Type | Address type | FEC-tlv length| Reserved | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Remote Peer Address (0, 4 or 16 octets) | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 . . 431 . FEC TLV . 432 . . 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 Figure 6: FEC Stack Change Sub-TLV 437 Operation Type 439 The operation type specifies the action associated with the FEC 440 stack change. The following operation types are defined. 442 Type # Operation 443 ------ --------- 444 1 Push 445 2 Pop 447 Address Type 449 The Address Type indicates the remote peer's address type. The 450 Address Type is set to one of the following values. The peer 451 address length is determined based on the address type. The 452 address type MAY be different from the address type included in 453 the Downstream Detailed Mapping TLV. This can happen when the LSP 454 goes over a tunnel of a different address family. The address 455 type MAY be set to Unspecified if the peer-address is either 456 unavailable or the transit router does not wish it provide it for 457 security or administrative reasons. 459 Type # Address Type Address length 460 ------ ------------ -------------- 462 0 Unspecified 0 463 1 IPv4 4 464 2 IPv6 16 466 FEC tlv Length 467 Length in bytes of the FEC TLV. 469 Reserved 470 This field is reserved for future use and MUST be set to zero. 472 Remote peer address 474 The remote peer address specifies the remote peer which is the 475 next-hop for the FEC being currently traced. E.g. in the LDP over 476 RSVP case Figure 1, router B would respond back with the address 477 of router D as the remote peer address for the LDP FEC being 478 traced. This allows the ingress node to provide information 479 regarding FEC peers. If the operation type is PUSH, the remote 480 peer address is the address of the peer from which the FEC being 481 pushed was learnt. If the operation type is POP, the remote peer 482 address MAY be set to Unspecified. 483 For upstream assigned labels [RFC5331], an operation type of POP 484 will have a remote peer address (the upstream node that assigned 485 the label) and this SHOULD be included in the FEC Stack change 486 sub-TLV. The remote peer address MAY be set to Unspecified, if 487 the address needs to be hidden. 489 FEC TLV 490 The FEC TLV is present only when FEC-tlv length field is non-zero. 491 The FEC TLV specifies the FEC associated with the FEC stack change 492 operation. This TLV MAY be included when the operation type is 493 POP. It MUST be included when the operation type is PUSH. The 494 FEC TLV contains exactly 1 FEC from the list of FECs specified in 495 [RFC4379]. A NIL FEC MAY be associated with a PUSH operation if 496 the responding router wishes to hide the details of the FEC being 497 pushed. 499 FEC Stack change sub-TLV operation rules: 501 a. A FEC Stack change sub-TLV containing a PUSH operation MUST NOT 502 be followed by a FEC Stack change sub-TLV containing a POP 503 operation. 504 b. One or more POP operations MAY be followed by one or more PUSH 505 operations. 506 c. One FEC Stack change sub-TLV MUST be included per FEC stack 507 change. For example, if 2 labels are going to be pushed, then 1 508 FEC Stack change sub-TLV MUST be included for each FEC. 509 d. A FEC splice operation (an operation where 1 FEC ends and another 510 FEC starts, see Figure 7) MUST be performed by including a POP 511 type FEC Stack change sub-TLV followed by a PUSH type FEC Stack 512 change sub-TLV. 513 e. A Downstream detailed mapping TLV containing only 1 FEC Stack 514 Change sub-TLV with Pop operation is equivalent to IS_EGRESS 515 (Return code 3, [RFC4379]) for the outermost FEC in the FEC 516 stack. The ingress router performing the MPLS traceroute MUST 517 treat such a case as an IS_EGRESS for the outermost FEC. 519 3.4. Deprecation of Downstream Mapping TLV 521 This document deprecates the Downstream Mapping TLV. LSP-ping 522 procedures should now use the Downstream Detailed Mapping TLV. 523 Detailed procedures regarding interoperability between the deprecated 524 TLV and the new TLV are specified in Section 4.4. 526 4. Performing MPLS traceroute on tunnels 528 This section describes the procedures to be followed by an LSP 529 ingress node and LSP transit nodes when performing MPLS traceroute 530 over MPLS tunnels. 532 4.1. Transit node procedure 534 4.1.1. Addition of a new tunnel 536 A transit node (Figure 1) knows when the FEC being traced is going to 537 enter a tunnel at that node. Thus, it knows about the new outer FEC. 538 All transit nodes that are the origination point of a new tunnel 539 SHOULD add the a FEC Stack change sub-TLV (Section 3.3.1.3) to the 540 Downstream Detailed Mapping TLV (Figure 3) in the echo reply. The 541 transit node SHOULD add 1 FEC Stack change sub-TLV of operation type 542 PUSH, per new tunnel being originated at the transit node. 544 A transit node that sends a Downstream FEC Stack change sub-TLV in 545 the echo reply SHOULD fill the address of the remote peer; which is 546 the peer of the current LSP being traced. If the transit node does 547 not know the address of the remote peer, it MUST set the address type 548 to Unspecified. 550 The Label stack sub-TLV MUST contain 1 additional label per FEC being 551 PUSHed. The label MUST be encoded as per Figure 5. The label value 552 MUST be the value used to switch the data traffic. If the tunnel is 553 transparent pipe to the node, i.e. the data-plane trace will not 554 expire in the middle of the new tunnel, then a FEC Stack change sub- 555 TLV SHOULD NOT be added and the Label stack sub-TLV SHOULD NOT 556 contain a label corresponding to the hidden tunnel. 558 If the transit node wishes to hide the nature of the tunnel from the 559 ingress of the echo request, then it MAY not want to send details 560 about the new tunnel FEC to the ingress. In such a case, the transit 561 node SHOULD use the NIL FEC. The echo reply would then contain a FEC 562 Stack change sub-TLV with operation type PUSH and a NIL FEC. The 563 value of the label in the NIL FEC MUST be set to zero. The remote 564 peer address type MUST be set to Unspecified. The transit node 565 SHOULD add 1 FEC Stack change sub-TLV of operation type PUSH, per new 566 tunnel being originated at the transit node. The Label stack sub-TLV 567 MUST contain 1 additional label per FEC being PUSHed. The label 568 value MUST be the value used to switch the data traffic. 570 4.1.2. Transition between tunnels 572 A B C D E F 573 o -------- o -------- o --------- o -------- o ------- o 574 \_____/ \______/ \______/ \______/ \_______/ 575 LDP LDP BGP RSVP RSVP 577 Figure 7: Stitched LSPs 579 In the above figure, we have 3 seperate LSP segments stitched at C 580 and D. Node C SHOULD include 2 FEC Stack change sub-TLVs. One with a 581 POP operation for the LDP FEC and one with the PUSH operation for the 582 BGP FEC. Similarly, node D SHOULD include 2 FEC Stack change sub- 583 TLVs, one with a POP operation for the BGP FEC and one with a PUSH 584 operation for the RSVP FEC. Nodes C and D SHOULD set the Return Code 585 to "Label switched with FEC change" (Section 6.3) to indicate change 586 in FEC being traced. 588 If node C wishes to perform FEC hiding, it SHOULD respond back with 2 589 FEC Stack change sub-TLVs. One POP followed by 1 PUSH. The POP 590 operation MAY either exclude the FEC TLV (by setting FEC TLV length 591 to 0) or set the FEC TLV to contain the LDP FEC. The PUSH operation 592 SHOULD have the FEC TLV containing the NIL FEC. The Return Code 593 SHOULD be set to "Label switched with FEC change". 595 If node C performs FEC hiding and node D also performs FEC hiding, 596 then node D MAY choose to not send any FEC Stack change sub-TLVs in 597 the echo reply since the number of labels has not changed (for the 598 downstream of node D) and the FEC type also has not changed (NIL 599 FEC). In such a case, node D MUST NOT set the Return Code to "Label 600 switched with FEC change". If node D performs FEC hiding, then node 601 F will respond as IS_EGRESS for the NIL FEC. The ingress (node A) 602 will know that IS_EGRESS corresponds to the end-to-end LSP. 604 A B C D E F 605 o -------- o -------- o --------- o --------- o --------- o 606 \_____/ |\____________________/ |\_______/ 607 LDP |\ RSVP-A | LDP 608 | \_______________________________/| 609 | RSVP-B | 610 \________________________________/ 611 LDP 613 Figure 8: Hierarchical LSPs 615 In the above figure, we have an end-to-end LDP LSP between nodes A 616 and F. The LDP LSP goes over RSVP LSP RSVP-B. LSP RSVP-B itself goes 617 over another RSVP LSP RSVP-A. When node A initiates a traceroute for 618 the end-to-end LDP LSP, then following sequence of FEC Stack change 619 sub-TLVs will be performed 621 Node B: 623 Respond with 2 FEC Stack change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A. 625 Node D: 627 Respond with a Return Code of 3 when RSVP-A is top of FEC stack. 628 When the echo request contains RSVP-B as top of stack, respond with 629 Downstream information for node E and an appropriate Return Code. 631 If node B is performing tunnel hiding, then: 633 Node B: 635 Respond with 2 FEC Stack change sub-TLVs: PUSH NIL-FEC, PUSH NIL-FEC. 637 Node D: 639 If D can co-relate that the NIL-FEC corresponds to RSVP-A, which 640 terminates at D, then it SHOULD Respond with Return Code of 3. D can 641 also respond with FEC Stack change sub-TLV: POP (since D knows that 642 number of labels towards next-hop is decreasing). Both responses 643 would be valid. 645 A B C D E F G 646 o -------- o -------- o ------ o ------ o ----- o ----- o 647 LDP LDP BGP \ RSVP RSVP / LDP 648 \_____________/ 649 LDP 651 Figure 9: Stitched hierarchical LSPs 653 In the above case, node D will send 3 FEC Stack change sub-TLVs. One 654 POP (for the BGP FEC) followed by 2 PUSHes (one for LDP and one for 655 RSVP). Nodes C and D SHOULD set the Return Code to "Label switched 656 with FEC change" (Section 6.3) to indicate change in FEC being 657 traced. 659 4.1.3. Modification to FEC Validation procedure on Transit 661 Section 4.4 of [RFC4379] specifies Target FEC stack validation 662 procedures. This document enhances the FEC validation procedures as 663 follows. If the outermost FEC of the target FEC stack is the NIL 664 FEC, then the node MUST skip the target FEC validation completely. 665 This is to support FEC hiding, in which the outer hidden FEC can be 666 the NIL FEC. 668 4.2. Modification to FEC Validation procedure on Egress 670 Section 4.4 of [RFC4379] specifies Target FEC stack validation 671 procedures. This document enhances the FEC validation procedures as 672 follows. If the outermost FEC of the target FEC stack is the NIL 673 FEC, then the node MUST skip the target FEC validation completely. 674 This is to support FEC hiding, in which the outer hidden FEC can be 675 the NIL FEC. 677 4.3. Ingress node procedure 679 It is the responsibility of an ingress node to understand tunnel 680 within tunnel semantics and LSP stitching semantics when performing a 681 MPLS traceroute. This section describes the ingress node procedure 682 based on the kind of reply an ingress node receives from a transit 683 node. 685 4.3.1. Processing Downstream Detailed Mapping TLV 687 Downstream Detailed Mapping TLV should be processed in the same way 688 as the Downstream Mapping TLV, defined in Section 4.4 of [RFC4379]. 689 This section describes the procedures for processing the new elements 690 introduced in this document. 692 4.3.1.1. Stack Change sub-TLV not present 694 This would be the default behavior as described in [RFC4379]. The 695 ingress node MUST perform MPLS echo reply processing as per the 696 procedures in [RFC4379]. 698 4.3.1.2. Stack Change sub-TLV(s) present 700 If one or more FEC Stack change sub-TLVs (Section 3.3.1.3) are 701 received in the MPLS echo reply, the ingress node SHOULD process them 702 and perform some validation. 704 The FEC stack changes are associated with a downstream neighbor and 705 along a particular path of the LSP. Consequently, the ingress will 706 need to maintain a FEC-stack per path being traced (in case of 707 multipath). All changes to the FEC stack resulting from the 708 processing of FEC Stack change sub-TLV(s) should be applied only for 709 the path along a given downstream neighbor. The following algorithm 710 should be followed for processing FEC Stack change sub-TLVs. 712 push_seen = FALSE 713 fec_stack_depth = current-depth-of-fec-stack-being-traced 714 saved_fec_stack = current_fec_stack 716 while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv)) 718 if (sub-tlv == NULL) break 720 if (sub-tlv.type == FEC-Stack-Change) { 722 if (sub-tlv.operation == POP) { 723 if (push_seen) { 724 Drop the echo reply 725 current_fec_stack = saved_fec_stack 726 return 727 } 729 if (fec_stack_depth == 0) { 730 Drop the echo reply 731 current_fec_stack = saved_fec_stack 732 return 733 } 735 Pop FEC from FEC stack being traced 736 fec_stack_depth--; 737 } 739 if (sub-tlv.operation == PUSH) { 740 push_seen = 1 741 Push FEC on FEC stack being traced 742 fec_stack_depth++; 743 } 744 } 745 } 747 if (fec_stack_depth == 0) { 748 Drop the echo reply 749 current_fec_stack = saved_fec_stack 750 return 751 } 753 Figure 10: FEC Stack Change Sub-TLV Processing Guideline 755 The next MPLS echo request along the same path should use the 756 modified FEC stack obtained after processing the FEC Stack change 757 sub-TLVs. A non-NIL FEC guarantees that the next echo request along 758 the same path will have the Downstream Detailed Mapping TLV validated 759 for IP address, Interface address and label stack mismatches. 761 If the top of the FEC stack is a NIL FEC and the MPLS echo reply does 762 not contain any FEC Stack change sub-TLV, then it does not 763 necessarily mean that the LSP has not started traversing a different 764 tunnel. It could be that the LSP associated with the NIL FEC 765 terminated at a transit node and at the same time a new LSP started 766 at the same transit node. The NIL FEC would now be associated with 767 the new LSP (and the ingress has no way of knowing this). Thus, it 768 is not possible to build an accurate hierarchical LSP topology if a 769 traceroute contains NIL FECs. 771 4.3.2. Modifications to handling to Return Code 3 reply. 773 The procedures above allow the addition of new FECs to the original 774 FEC being traced. Consequently, a reply from a downstream node with 775 Return Code of 3 (IS_EGRESS) may not necessarily be for the FEC being 776 traced. It could be for one of the new FECs that was added. On 777 receipt of an IS_EGRESS reply, the LSP ingress should check if the 778 depth of Target FEC sent to the node that just responded, was the 779 same as the depth of the FEC that was being traced. If it was not, 780 then it should pop an entry from the Target FEC stack and resend the 781 request with the same TTL (as previously sent). The process of 782 popping a FEC is to be repeated until either the LSP ingress receives 783 a non-IS_EGRESS reply or until all the additional FECs added to the 784 FEC stack have already been popped. Using IS_EGRESS reply, an 785 ingress can build a map of the hierarchical LSP structure traversed 786 by a given FEC. 788 4.3.3. Handling of new return codes 790 When the MPLS echo reply Return Code is "Label switched with FEC 791 change" (Section 3.2.2), the ingress node SHOULD manipulate the FEC 792 stack as per the FEC Stack change sub-TLVs contained in the 793 downstream detailed mapping TLV. A transit node can use this Return 794 Code for stitched LSPs and for hierarchical LSPs. In case of Equal 795 Cost Multi-Path (ECMP) or Point to Multi-Point (P2MP), there could be 796 multiple paths and downstream detailed mapping TLVs with different 797 return codes (Section 3.2.1). The ingress node should build the 798 topology based on the Return Code per ECMP path/P2MP branch. 800 4.4. Handling deprecated Downstream Mapping TLV 802 The Downstream Mapping TLV has been deprecated. Applications should 803 now use the Downstream Detailed Mapping TLV. The following 804 procedures SHOULD be used for backward compatibility with routers 805 that do not support the Downstream Detailed Mapping TLV. 807 o The Downstream Mapping TLV and the Downstream Detailed Mapping TLV 808 MUST never be sent together in the same MPLS echo request or in 809 the same MPLS echo reply. 810 o If the echo request contains a Downstream Detailed Mapping TLV and 811 the corresponding echo reply contains a Return Code of 2 (one or 812 more of the TLVs was not understood), then the sender of the echo 813 request MAY resend the echo request with the Downstream Mapping 814 TLV (instead of the Downstream Detailed Mapping TLV). In cases 815 where a detailed reply is needed, the sender can choose to ignore 816 the router that does not support the Downstream Detailed Mapping 817 TLV. 818 o If the echo request contains a Downstream Mapping TLV, then a 819 Downstream Detailed Mapping TLV MUST NOT be sent in the echo 820 reply. This is to handle the case that the sender of the echo 821 request does not support the new TLV. The echo reply MAY contain 822 Downstream Mapping TLV(s). 823 o If echo request forwarding is in use; such that the echo request 824 is processed at an intermediate label switched router (LSR) and 825 then forwarded on; then the intermediate router is responsible for 826 making sure that the TLVs being used among the ingress, 827 intermediate and destination are consistent. The intermediate 828 router MUST NOT forward an echo request or an echo reply 829 containing a Downstream Detailed Mapping TLV if it itself does not 830 support that TLV. 832 5. Security Considerations 834 1. If a network operator wants to prevent tracing inside a tunnel, 835 one can use the pipe mode [RFC3443], i.e. hide the outer MPLS 836 tunnel by not propagating the MPLS TTL into the outer tunnel (at 837 the start of the outer tunnel). By doing this, MPLS traceroute 838 packets will not expire in the outer tunnel and the outer tunnel 839 will not get traced. 840 2. If one doesn't wish to expose the details of the new outer LSP, 841 then the NIL FEC can be used to hide those details. Using the 842 NIL FEC ensures that the trace progresses without false negatives 843 and all transit nodes (of the new outer tunnel) perform some 844 minimal validations on the received MPLS echo requests. 846 Other security considerations, as discussed in [RFC4379] are also 847 applicable to this document. 849 6. IANA Considerations 851 The suggested values in all sub-sections below have been allocated 852 according to the early allocation process. 854 6.1. New TLV 856 IANA is requested to assign TLV type value to the following TLV from 857 the "Multiprotocol Label Switching Architecture (MPLS) Label Switched 858 Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- 859 registry. 861 Downstream Detailed Mapping TLV (See Section 3.3). Suggested value: 862 20. 864 6.2. New Sub-TLV types and associated registry 866 IANA is requested to create a new registry for the Sub-Type field of 867 Downstream Detailed Mapping TLV. The valid range for this is 868 0-65535. Assignments in the range 0-16383 and 32768-49161 are made 869 via Standards Action as defined in [RFC3692]; assignments in the 870 range 16384-31743 and 49162-64511 are made via Specification Required 871 ([RFC4379]); values in the range 31744-32767 and 64512-65535 are for 872 Vendor Private Use, and MUST NOT be allocated. If a sub-TLV has a 873 Type that falls in the range for Vendor Private Use, the Length MUST 874 be at least 4, and the first four octets MUST be that vendor's SMI 875 Enterprise Code, in network octet order. The rest of the Value field 876 is private to the vendor. 878 It is requested that IANA assign sub-TLV types from this new registry 879 to the following sub-TLVs (See Section 3.3.1). 881 Multipath data sub-TLV: Suggested value: 1 883 Label stack sub-TLV: Suggested value: 2 885 FEC Stack change sub-TLV: Suggested value: 3 887 6.3. New Return Codes 889 IANA is requested to assign new Return Code values from the "Multi- 890 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 891 Parameters" registry, "Return Codes" sub-registry as follows using a 892 Standards Action value. 894 Value Meaning 895 ----- ------- 896 TBD See DDM TLV for Return Code and Return SubCode 897 TBD Label switched with FEC change 899 Suggested values: 14 and 15 respectively 901 7. Acknowledgements 903 The authors would like to thank Yakov Rekhter and Adrian Farrel for 904 their suggestions on the draft. 906 8. References 908 8.1. Normative References 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, March 1997. 913 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 914 Considered Useful", BCP 82, RFC 3692, January 2004. 916 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 917 Label Switched (MPLS) Data Plane Failures", RFC 4379, 918 February 2006. 920 8.2. Informative References 922 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 923 in Multi-Protocol Label Switching (MPLS) Networks", 924 RFC 3443, January 2003. 926 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 927 Multipoint Traffic-Engineered MPLS Label Switched Paths 928 (LSPs)", RFC 4461, April 2006. 930 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 931 "Label Switched Path Stitching with Generalized 932 Multiprotocol Label Switching Traffic Engineering (GMPLS 933 TE)", RFC 5150, February 2008. 935 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 936 Label Assignment and Context-Specific Label Space", 937 RFC 5331, August 2008. 939 Authors' Addresses 941 Nitin Bahadur 942 Juniper Networks, Inc. 943 1194 N. Mathilda Avenue 944 Sunnyvale, CA 94089 945 US 947 Phone: +1 408 745 2000 948 Email: nitinb@juniper.net 949 URI: www.juniper.net 951 Kireeti Kompella 952 Juniper Networks, Inc. 953 1194 N. Mathilda Avenue 954 Sunnyvale, CA 94089 955 US 957 Phone: +1 408 745 2000 958 Email: kireeti@juniper.net 959 URI: www.juniper.net 961 George Swallow 962 Cisco Systems 963 1414 Massachusetts Ave 964 Boxborough, MA 01719 965 US 967 Email: swallow@cisco.com 968 URI: www.cisco.com