idnits 2.17.1 draft-nadeau-rfc4379-bis-link-bundle-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 772. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 781. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 794. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2006) is 6403 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) == Missing Reference: 'RFC4201' is mentioned on line 137, but not defined == Unused Reference: 'SELF-TST' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'MCSTPING' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'MPLS-BFD' is defined on line 723, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) -- Possible downref: Non-RFC (?) normative reference: ref. 'SELF-TST' -- Possible downref: Non-RFC (?) normative reference: ref. 'MCSTPING' Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tom Nadeau 2 Internet Draft George Swallow 3 Category: Standards Track David Ward 4 Expiration Date: May 2007 Danny Prairie 5 Cisco Systems, Inc. 7 October 2006 9 Extensions to RFC4379 in Support of Link Bundles 11 draft-nadeau-rfc4379-bis-link-bundle-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 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 Abstract 38 This document specifies extensions to MPLS LSP Ping's 39 tracing function as specified in IETF RFC4379 to support 40 link bundle constructs. In particular, we extend the 41 Echo Request packet format to include a new Link Bundle TLV 42 that can contain both the virtual link bundle interface 43 ID, as well as a description of the ECMP algorithm used by 44 said interface. The existing downstream mapping processing 45 algorithm for midpoints is modified to specify that when link 46 bundles are encountered, that the component links should be 47 revealed as would non-component links in the existing 48 algorithm. 50 Extensions to RFC4379 for link bundles October 15, 2006 52 Contents 54 1 Introduction .............................................. 3 55 1.1 Conventions ............................................... 3 56 1.2 Terminology ............................................... 3 57 2 Overview .................................................. 3 58 3 Connectivity Verification Bootstrapping ................... 4 59 3.1 Connectivity Verification Session Object .................. 4 60 6 Security Considerations ................................... 11 61 7 IANA Considerations ....................................... 11 62 8 Acknowledgments ........................................... 11 63 9 References ................................................ 11 64 9.1 Normative References ...................................... 11 65 9.2 Informative References .................................... 12 66 10 Authors' Addresses ........................................ 12 68 1. Introduction 70 Link bundling is a technology that allows a device 71 to group or "bundle" together multiple, dislike or like 72 interfaces into a single link bundle interface. The 73 constituent interfaces that are bundled together 74 are referred to as component interfaces or links. The 75 set of component links or interfaces all connect one 76 router/switch to another. When associated under the 77 umbrella of a single, virtual link bundle interface, 78 they are still viewed in this way, but only as a single 79 pipe to the adjacent neighbor, consisting of the combined 80 bandwidth and other attributes of the component links. For 81 example, a single set of transmit and receive counters reflect 82 the aggregate behavior of the individual component links, and 83 provide a single point of management for the operator. 85 The algorithm used to share traffic across component links is 86 often identical to the one used for spreading the load across 87 adjacent IGP equal cost links, which is referred to as Equal Cost 88 Multi-Path (ECMP). The most common algorithms are: 90 1) per-packet, which uses some form of round-robin 91 scheduling to push each packet over a different 92 component link or 94 2) per-destination, which sends all packets destined to 95 a particular IP destination over the same component 96 link. There are of course, pros and cons to using either 97 algorithm, but the most common used is per-destination. 99 Extensions to RFC4379 for link bundles October 15, 2006 101 The motivation behind link bundling is to improve routing 102 scalability by reducing the amount of information that has to be 103 processed and advertised by the routing protocols such as OSPF or 104 IS-IS. This reduction is accomplished by performing 105 information aggregation/abstraction as described above. 106 However, as well as the benefits to information aggregation, 107 some negative side-effects result. Specifically, in cases where 108 trouble-shooting or diagnosing failures related to malfunctioning 109 link bundles, this information hiding compounds the time 110 it takes a network manager to uncover the failure. For instance, 111 if the failure has to do with one of the component links failing, 112 depending on the hashing algorithm used to move traffic onto those 113 component links, errors may appear random, or may be difficult 114 to stimulate. 116 This document specifies extensions to MPLS LSP Ping's 117 tracing functions [RFC4379] to support link bundle constructs. 118 To this end, we extend the Echo Request packet format to 119 include a new options Link Bundle TLV (i.e.: U bit set to 1) 120 will contain both the virtual link bundle interface ID, as 121 well as a description of the ECMP algorithm used by link 122 bundling interfaces on an MPLS Label Switching Router (LSR). The 123 existing downstream mapping processing algorithm for midpoints 124 is modified to specify that when link bundles are encountered, 125 that the component links should be revealed as would non-component 126 links in the existing algorithm. 128 1.1. Conventions 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 134 1.2. Terminology 136 Definitions of key terms for MPLS OAM are found in [RFC4379] and 137 [RFC4201]. The reader is assumed to be familiar with those 138 definitions which are not repeated here. 140 The following additional terms are useful to understand this 141 document. 143 1.3 Acronyms 145 The following list of acronyms is a repeat of common acronyms defined 146 in many other documents, and is provided here for convenience. 148 Extensions to RFC4379 for link bundles October 15, 2006 150 CE: Customer Edge 151 PE: Provider Edge 152 ECMP: Equal Cost Multipath 153 LDP: Label Distribution Protocol 154 LSP: Label Switch Path 155 LSR: Label Switch Router 156 OAM: Operations and Management 157 OA&M: Operations, Administration and Maintenance. 158 RSVP: Resource reSerVation Protocol 159 SP: Service Provider 161 2. Overview 163 In section 3, we extend the Echo Request packet format to 164 include a new (optional) Link Bundle TLV that will contain 165 both the virtual link bundle interface ID, as well as a 166 description of the ECMP algorithm used by said interface. 167 The the existing downstream mapping processing algorithm for 168 midpoints is modified to specify that when link bundles 169 are encountered, that the component links should be 170 revealed as would non-component links in the existing 171 algorithm. The error processing algorithm will also be 172 modified to indicate that a component of a virtual 173 link bundle interface has failed. The presence of the 174 Link Bundle TLV will indicate that a link bundle 175 virtual interface is associated with those component links, 176 and that special processing and consideration at the 177 head-end LSR of the LSP should be taken when processing this 178 information. The head-end LSR's processing algorithm is 179 modified to understand the new aforementioned Link Bundle TLV, 180 as well as to modify its processing algorithm for how it 181 investigiates the LSP's tree when tracing either the entire tree 182 using ECMP tree trace, or tracing a single path 183 (also known as a path selector) of the LSP. This is 184 all detailed below. 186 4. Downstream Mapping Processing For Link Bundles 188 Use the algorithm as stated in RFC4379 with the following 189 modifications: 191 [At the receiver of an Echo Request containing a Downstream Map TLV] 193 1) When encoding the downstream map tlv, and encountering 194 a link bundle virtual interface, recurse through 195 to each one of its component link interfaces and 196 include those (their IP address and IfNumber) in 197 Extensions to RFC4379 for link bundles October 15, 2006 199 the Downstream Map TLV. For each one included, also 200 set the DS Flag to indicate that it is a component link 201 interface. The multipath type specified is used to fully 202 resolve the outgoing path to a particular component link 203 of the bundle. In other words, multipath type A is not 204 used to perform resolution to a bundle, and then multipath 205 type B used to further resolve to a component link. 206 That is, run the ECMP algorithm twice, once using the 207 virtual link bundle interface as the next-hop, 208 and then again through that interface to the component link 209 bundle interfaces. In most cases, the ECMP algorithm 210 used for the link bundles will be identical to the one 211 used to get from the link bundle interface to the 212 component interfaces, and thus can simply be run twice 213 by the control plane. 215 2) Include one copy of the Downstream Map Link Bundle TLV 216 for each link bundle virtual interface. For each 217 TLV, fill in the component links herein to "point" 218 back at the link bundle component links specified 219 in #1. 221 [At the receiver of an Echo Reply containing a Downstream 222 Map TLV] 224 1) Ensure that for each Downstream Map TLV containing 225 an interface with the DS Flag of "L" set, verify that 226 a Downstream Map Link Bundle TLV exists that contains 227 this interface, or return an error. Older versions of 228 code will ignore this flag. 230 2) For each component interface present in the Downstream 231 Mapping TLV, process as normal. This facilitates 232 backwards compatibility with older code. 234 3) For each Downstream Map Link Bundle TLV, iterate 235 through the component interfaces specified therein, 236 and ensure they match the ones specified in the 237 Downstream Map TLV discussed in 1. 239 3.3. Downstream Mapping When Supporting Link Bundles 241 The description of interfaces in Section 3.3 "Downstream Mapping" 242 of [RFC4379] must be changed to reflect each set of link bundle 243 component interfaces belonging to a link bundle as follows. The 244 entire section has been copied here and modified in place 245 for completeness. 247 Extensions to RFC4379 for link bundles October 15, 2006 249 The Downstream Mapping object is a TLV that MAY be included in an 250 echo request message. Only one Downstream Mapping object may appear 251 in an echo request. The presence of a Downstream Mapping object is a 252 request that Downstream Mapping objects be included in the echo 253 reply. If the replying router is the destination of the FEC, then a 254 Downstream Mapping TLV SHOULD NOT be included in the echo reply. 255 Otherwise the replying router SHOULD include a Downstream Mapping 256 object for each interface over which this FEC could be forwarded. 257 For a more precise definition of the notion of "downstream", see 258 section 3.3.2, "Downstream Router and Interface". 260 The Length is K + M + 4*N octets, where M is the Multipath Length, 261 and N is the number of Downstream Labels. Values for K are found in 262 the description of Address Type below. The Value field of a 263 Downstream Mapping has the following format: 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | MTU | Address Type | DS Flags | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Downstream IP Address (4 or 16 octets) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Downstream Interface Address (4 or 16 octets) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Multipath Type| Depth Limit | Multipath Length | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 . . 277 . (Multipath Information) . 278 . . 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Downstream Label | Protocol | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 . . 283 . . 284 . . 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Downstream Label | Protocol | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Maximum Transmission Unit (MTU) 291 The MTU is the size in octets of the largest MPLS frame (including 292 label stack) that fits on the interface to the Downstream LSR. 294 Address Type 296 The Address Type indicates if the interface is numbered or 297 unnumbered. It also determines the length of the Downstream IP 298 Extensions to RFC4379 for link bundles October 15, 2006 300 Address and Downstream Interface fields. The resulting total for 301 the initial part of the TLV is listed in the table below as "K 302 Octets". 304 In the case where the interface is a virtual link bundle 305 interface, the LSR MUST include its component interfaces 306 addresses here and MUST NOT include the virtual link bundle. 307 It must also indicate that it is a component link by 308 setting the L bit in the DS Flags. Under this condition, the LSR 309 MUST then include a corresponding Link Bundle TLV (see below) to 310 indicate which component interfaces are associated with which 311 component links returned in the DS Map TLV. 313 Type # Address Type K Octets 314 ------ ------------ -------- 315 1 IPv4 Numbered 16 316 2 IPv4 Unnumbered 16 317 3 IPv6 Numbered 40 318 4 IPv6 Unnumbered 28 320 DS Flags 322 The DS Flags field is a bit vector with the following format: 324 0 1 2 3 4 5 6 7 325 +-+-+-+-+-+-+-+-+ 326 |Rsvd(MBZ)|L|I|N| 327 +-+-+-+-+-+-+-+-+ 329 Three flags are defined currently, I, N and L. The remaining flags 330 MUST be set to zero when sending and ignored on receipt. 332 Flag Name and Meaning 333 ---- ---------------- 335 I Interface and Label Stack Object Request 337 When this flag is set, it indicates that the replying 338 router SHOULD include an Interface and Label Stack 339 Object in the echo reply message. 341 N Treat as a Non-IP Packet 343 Echo request messages will be used to diagnose non-IP 344 flows. However, these messages are carried in IP 345 packets. For a router that alters its ECMP algorithm 346 based on the FEC or deep packet examination, this flag 348 Extensions to RFC4379 for link bundles October 15, 2006 350 requests that the router treat this as it would if the 351 determination of an IP payload had failed. 353 L Link Bundle Component Interface 355 When this flag is set, it indicates that the interface 356 indicated in the Downstream Interface Address field 357 is a member of a link bundle (i.e.: a component link 358 bundle interface). 360 Downstream IP Address and Downstream Interface Address 362 IPv4 addresses and interface indices are encoded in 4 octets; IPv6 363 addresses are encoded in 16 octets. 365 If the interface to the downstream LSR is numbered, then the 366 Address Type MUST be set to IPv4 or IPv6, the Downstream IP 367 Address MUST be set to either the downstream LSR's Router ID or 368 the interface address of the downstream LSR, and the Downstream 369 Interface Address MUST be set to the downstream LSR's interface 370 address. 372 If the interface to the downstream LSR is unnumbered, the Address 373 Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP 374 Address MUST be the downstream LSR's Router ID, and the Downstream 375 Interface Address MUST be set to the index assigned by the 376 upstream LSR to the interface. 378 If an LSR does not know the IP address of its neighbor, then it 379 MUST set the Address Type to either IPv4 Unnumbered or IPv6 380 Unnumbered. For IPv4, it must set the Downstream IP Address to 381 127.0.0.1; for IPv6 the address is set to 0::1. In both cases, 382 the interface index MUST be set to 0. If an LSR receives an Echo 383 Request packet with either of these addresses in the Downstream IP 384 Address field, this indicates that it MUST bypass interface 385 verification but continue with label validation. 387 If the originator of an Echo Request packet wishes to obtain 388 Downstream Mapping information but does not know the expected 389 label stack, then it SHOULD set the Address Type to either IPv4 390 Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set the 391 Downstream IP Address to 224.0.0.2; for IPv6 the address MUST be 392 set to FF02::2. In both cases, the interface index MUST be set to 393 0. If an LSR receives an Echo Request packet with the all-routers 394 multicast address, then this indicates that it MUST bypass both 395 interface and label stack validation, but return Downstream 396 Mapping TLVs using the information provided. 398 Multipath Type 399 Extensions to RFC4379 for link bundles October 15, 2006 401 The following Multipath Types are defined: 403 Key Type Multipath Information 404 --- ---------------- --------------------- 405 0 no multipath Empty (Multipath Length = 0) 406 2 IP address IP addresses 407 4 IP address range low/high address pairs 408 8 Bit-masked IP IP address prefix and bit mask 409 address set 410 9 Bit-masked label set Label prefix and bit mask 412 Type 0 indicates that all packets will be forwarded out this one 413 interface. 415 Types 2, 4, 8, and 9 specify that the supplied Multipath 416 Information will serve to exercise this path. 418 Depth Limit 420 The Depth Limit is applicable only to a label stack and is the 421 maximum number of labels considered in the hash; this SHOULD be 422 set to zero if unspecified or unlimited. 424 Multipath Length 426 The length in octets of the Multipath Information. 428 Multipath Information 430 Address or label values encoded according to the Multipath Type. 431 In the case where the L bit is set in the DS Flags, the multipath 432 information MUST also be set to reflect the multipath address or 433 label value encoding that link bundle interface will use 434 to load share traffic onto this component interface. The 435 parameters used to get traffic from the inbound interface to the 436 link bundle virtual interface will be described in the Multipath 437 Information for Link Bundles section below. 439 See the next section below for encoding details. 441 Downstream Label(s) 443 The set of labels in the label stack as it would have appeared if 444 this router were forwarding the packet through this interface. 445 Any Implicit Null labels are explicitly included. Labels are 446 treated as numbers, i.e., they are right justified in the field. 448 Extensions to RFC4379 for link bundles October 15, 2006 450 A Downstream Label is 24 bits, in the same format as an MPLS label 451 minus the TTL field, i.e., the MSBit of the label is bit 0, the 452 LSBit is bit 19, the EXP bits are bits 20-22, and bit 23 is the S 453 bit. The replying router SHOULD fill in the EXP and S bits; the 454 LSR receiving the echo reply MAY choose to ignore these bits. 456 Protocol 458 The Protocol is taken from the following table: 460 Protocol # Signaling Protocol 461 ---------- ------------------ 462 0 Unknown 463 1 Static 464 2 BGP 465 3 LDP 466 4 RSVP-TE 467 5 Link Bundle Component Interface 469 In the case where a link bundle's component interface is 470 specified (as indicated by DS Flag L), the value of 5 471 (Link Bundle Component Interface MUST be used as the 472 protocol identifier. 474 10. Downstream Mapping Link Bundle TLV 476 The Downstream Mapping Link Bundle object is a TLV that 477 SHOULD NOT be included in an echo request message. 478 This TLV is used to specify the link bundle virtual interface, 479 as well as which link bundle virtual interface corresponds to 480 which link bundle component interfaces that were specified in 481 the Downstream Mapping TLV. If the replying router is the 482 destination of the FEC, then a Downstream Mapping Link Bundle 483 TLV SHOULD NOT be included in the Echo Reply. Otherwise the replying 484 router MUST include a Downstream Mapping Link Bundle object for 485 each link bundle virtual interface over which this FEC could be 486 forwarded. Furthermore, this TLV will be present once for 487 every Downstream Mapping TLV present that contains a DS Flag set 488 to L. For a more precise definition of the notion of "downstream", 489 see section 3.3.2, "Downstream Router and Interface". 491 The Length is K + M + 4*N octets, where M is the Multipath Length, 492 and N is the number of Downstream Labels. Values for K are found in 493 the description of Address Type below. The Value field of a 494 Downstream Mapping has the following format: 496 0 1 2 3 497 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 498 Extensions to RFC4379 for link bundles October 15, 2006 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | MTU | Address Type | DS Flags | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Downstream IP Address (4 or 16 octets) | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Downstream Interface Address (4 or 16 octets) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Multipath Type| Reserved | Multipath Length | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 . . 510 . (Multipath Information) . 511 . . 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Component Interface Address | Protocol | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Component Interface's Downstream Map TLV index | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 . . 519 . . 520 . . 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Component Interface Address | Protocol | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Component Interface's Downstream Map TLV index | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Maximum Transmission Unit (MTU) 529 The MTU is the size in octets of the largest MPLS frame (including 530 label stack) that fits on the virtual interface to the Downstream 531 LSR. 533 Address Type 535 The Address Type indicates if the virtual interface is numbered or 536 unnumbered. It also determines the length of the Downstream IP 537 Address and Downstream Interface fields. The resulting total for 538 the initial part of the TLV is listed in the table below as "K 539 Octets". The Address Type is set to one of the following values: 541 Type # Address Type K Octets 542 ------ ------------ -------- 543 1 IPv4 Numbered 16 544 2 IPv4 Unnumbered 16 545 3 IPv6 Numbered 40 546 4 IPv6 Unnumbered 28 548 DS Link Bundle Flags 549 Extensions to RFC4379 for link bundles October 15, 2006 551 The DS Flags field is a bit vector with the following format: 553 0 1 2 3 4 5 6 7 554 +-+-+-+-+-+-+-+-+ 555 | Rsvd(MBZ) | 556 +-+-+-+-+-+-+-+-+ 558 All flags are reserved for future use and MUST be set to zero when 559 sending and ignored on receipt. 561 Downstream IP Address and Downstream Component Interface Address 563 IPv4 addresses and interface indices are encoded in 4 octets; IPv6 564 addresses are encoded in 16 octets. 566 If the link bundle component interface to the downstream LSR is 567 numbered, then the Address Type MUST be set to IPv4 or IPv6, the 568 Downstream IP Address MUST be set to either the downstream LSR's 569 Router ID or the interface address of the downstream LSR, and 570 the Downstream Interface Address MUST be set to the downstream 571 LSR's interface address. The interface index is set to the value 572 assigned by the LSR. 574 If the link bundle interface to the downstream LSR is unnumbered, 575 the Address Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the 576 Downstream IP Address MUST be the downstream LSR's Router ID, 577 and the Downstream Interface Address MUST be set to the interface 578 index assigned by the upstream LSR to the interface. 580 If an LSR does not know the IP address of its neighbor, then it 581 MUST set the Address Type to either IPv4 Unnumbered or IPv6 582 Unnumbered. For IPv4, it must set the Downstream IP Address to 583 127.0.0.1; for IPv6 the address is set to 0::1. In both cases, 584 the interface index MUST be set to 0. If an LSR receives an Echo 585 Request packet with either of these addresses in the Downstream IP 586 Address field, this indicates that it MUST bypass interface 587 verification but continue with label validation. 589 If the originator of an Echo Request packet wishes to obtain 590 Downstream Mapping Link Bundle information but does not know the 591 expected label stack, then it SHOULD set the Address Type to 592 either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it MUST 593 set the Downstream IP Address to 224.0.0.2; for IPv6 the address 594 MUST be set to FF02::2. In both cases, the interface index MUST 595 be set to 0. If an LSR receives an Echo Request packet with the 596 all-routers multicast address, then this indicates that it MUST 597 bypass both interface and label stack validation, but return 598 Downstream Mapping TLVs using the information provided. 600 Extensions to RFC4379 for link bundles October 15, 2006 602 Multipath Type 604 This field specifies an additional multipath type 605 if it differs from the one specified for the 606 link bundle component interfaces specified in the 607 Downstream Map TLV. Definition is the same as those 608 from RFC4379. 610 Depth Limit 612 The Depth Limit is applicable only to a label stack and is the 613 maximum number of labels considered in the hash; this SHOULD be 614 set to zero if unspecified or unlimited. 616 Multipath Length 618 The length in octets of the Multipath Information. 620 Multipath Information 622 Address or label values encoded according to the Multipath Type. 623 See the next section below for encoding details. 625 Downstream Label(s) 627 The set of labels in the label stack as it would have appeared if 628 this router were forwarding the packet through this interface. 629 Any Implicit Null labels are explicitly included. Labels are 630 treated as numbers, i.e., they are right justified in the field. 632 A Downstream Label is 24 bits, in the same format as an MPLS label 633 minus the TTL field, i.e., the MSBit of the label is bit 0, the 634 LSBit is bit 19, the EXP bits are bits 20-22, and bit 23 is the S 635 bit. The replying router SHOULD fill in the EXP and S bits; the 636 LSR receiving the echo reply MAY choose to ignore these bits. 638 Protocol 640 The Protocol is taken from the following table: 642 Protocol # Signaling Protocol 643 ---------- ------------------ 644 0 Unknown 645 1 Static 646 2 BGP 647 3 LDP 648 4 RSVP-TE 650 Extensions to RFC4379 for link bundles October 15, 2006 652 3.3.2. Downstream Router and Interface 654 Section 3 of RFC3479 contains a description of TLV types. The 655 Downstream Mapping Link Bundle TLV will be assigned a Type value of 656 11 as follows. 658 A description of the Types and Values of the top-level TLVs for LSP 659 ping are given below: 661 Type # Value Field 662 ------ ----------- 663 1 Target FEC Stack 664 2 Downstream Mapping 665 3 Pad 666 4 Not Assigned 667 5 Vendor Enterprise Number 668 6 Not Assigned 669 7 Interface and Label Stack 670 8 Not Assigned 671 9 Errored TLVs 672 10 Reply TOS Byte 673 11 Downstream Mapping Link Bundle 675 6. Security Considerations 677 TBD 679 7. IANA Considerations 681 This document makes the following code point assignments (pending 682 IANA action): 684 Registry Code point Purpose 686 UDP Port tba MPLS Verification Request 688 LSP Ping Message Type 5 MPLS Connectivity Verification 689 Probe 691 LSP Ping Object Type 13 Connectivity Verification 692 Parameters 694 LSP Ping FEC Stack tba Multicast LDP FEC 695 Sub-object Type 696 Extensions to RFC4379 for link bundles October 15, 2006 698 8. Acknowledgments 700 The authors would like to thank Vanson Lim for his comments and 701 suggestions. 703 9. References 705 9.1. Normative References 707 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 708 Label Switched (MPLS) Data Plane Failures", RFC 4379, 709 February 2006. 711 [SELF-TST] Swallow, G. et al., "Label Switching Router Self-Test", 712 , June 2006. 714 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, March 1997. 717 [MCSTPING] "Detecting Data Plane Failures in Point-to-Multipoint 718 MPLS Traffic Engineering - Extensions to LSP Ping", 719 , April 2006. 721 9.2. Informative References 723 [MPLS-BFD] Aggarwal, R., et al., " 725 10. Authors' Addresses 727 George Swallow 728 Cisco Systems, Inc. 729 1414 Massachusetts Ave 730 Boxborough, MA 01719 USA 731 Email: swallow@cisco.com 733 Tom Nadeau 734 Cisco Systems, Inc. 735 1414 Massachusetts Ave 736 Boxborough, MA 01719 USA 737 Extensions to RFC4379 for link bundles October 15, 2006 739 Email: tnadeau@cisco.com 741 Dave Ward 742 Cisco Systems 743 170 W. Tasman Dr. 744 San Jose, CA 95134 USA 745 Phone: +1-408-526-4000 747 Email: dward@cisco.com 749 Danny Prairie 750 Cisco Systems 751 2000 Innovation Drive 752 Kanata, Ontario K2K 3E8 CANADA 753 Phone: +1.613.274.3544 754 Email: dprairie@cisco.com 756 Copyright Notice 758 Copyright (C) The Internet Society (2006). This document is subject 759 to the rights, licenses and restrictions contained in BCP 78, and 760 except as set forth therein, the authors retain all their rights. 762 Extensions to RFC4379 for link bundles October 15, 2006 764 Disclaimer of Validity 766 This document and the information contained herein are provided on an 767 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 768 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 769 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 770 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 771 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 772 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 774 The IETF takes no position regarding the validity or scope of any 775 Intellectual Property Rights or other rights that might be claimed to 776 pertain to the implementation or use of the technology described in 777 this document or the extent to which any license under such rights 778 might or might not be available; nor does it represent that it has 779 made any independent effort to identify any such rights. Information 780 on the procedures with respect to rights in RFC documents can be 781 found in BCP 78 and BCP 79. 783 Copies of IPR disclosures made to the IETF Secretariat and any 784 assurances of licenses to be made available, or the result of an 785 attempt made to obtain a general license or permission for the use of 786 such proprietary rights by implementers or users of this 787 specification can be obtained from the IETF on-line IPR repository at 788 http://www.ietf.org/ipr. 790 The IETF invites any interested party to bring to its attention any 791 copyrights, patents or patent applications, or other proprietary 792 rights that may cover technology that may be required to implement 793 this standard. Please address the information to the IETF at 794 ietf-ipr@ietf.org.