idnits 2.17.1 draft-ietf-mpls-ldp-multi-topology-07.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 : ---------------------------------------------------------------------------- No issues found here. 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 (May 6, 2013) is 4007 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Q. Zhao 3 Internet-Draft Huawei Technology 4 Intended status: Standards Track L. Fang 5 Updates: 4379 C. Zhou 6 Expires: November 6, 2013 Cisco Systems 7 L. Li 8 China Mobile 9 K. Raza 10 Cisco Systems 11 May 6, 2013 13 LDP Extensions for Multi Topology Routing 14 draft-ietf-mpls-ldp-multi-topology-07.txt 16 Abstract 18 Multi-Topology (MT) routing is supported in IP networks with the use 19 of MT aware IGP protocols. In order to provide MT routing within 20 Multiprotocol Label Switching (MPLS) Label Distribution Protocol 21 (LDP) networks new extensions are required. This document updates 22 RFC4379. 24 This document describes the LDP protocol extensions required to 25 support MT routing in an MPLS environment. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 2, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Signaling Extensions . . . . . . . . . . . . . . . . . . . . . 5 76 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) . . . . 5 77 3.2. New Address Families: MT IP . . . . . . . . . . . . . . . 5 78 3.3. LDP FEC Elements with MT IP AF . . . . . . . . . . . . . . 6 79 3.4. IGP MT-ID Mapping and Translation . . . . . . . . . . . . 7 80 3.5. LDP MT Capability Advertisement . . . . . . . . . . . . . 8 81 3.6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 9 82 3.7. LDP Sessions . . . . . . . . . . . . . . . . . . . . . . . 10 83 3.8. Reserved MT ID Values . . . . . . . . . . . . . . . . . . 10 84 4. MT Applicability on FEC-based features . . . . . . . . . . . . 10 85 4.1. Typed Wildcard FEC Element . . . . . . . . . . . . . . . . 10 86 4.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . . 11 87 4.3. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 4.3.1. New FEC Sub-Types . . . . . . . . . . . . . . . . . . 11 89 4.3.2. MT LDP IPv4 FEC Sub-TLV . . . . . . . . . . . . . . . 12 90 4.3.3. MT LDP IPv6 FEC Sub-TLV . . . . . . . . . . . . . . . 12 91 4.3.4. Operation Considerations . . . . . . . . . . . . . . . 13 92 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 13 93 5.1. MT Error Notification for Invalid Topology ID . . . . . . 13 94 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14 95 7. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 14 96 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 98 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 100 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 102 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 103 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 18 104 A.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 105 A.2. Application Scenarios . . . . . . . . . . . . . . . . . . 18 106 A.2.1. Simplified Data-plane . . . . . . . . . . . . . . . . 18 107 A.2.2. Using MT for P2P Protection . . . . . . . . . . . . . 19 108 A.2.3. Using MT for mLDP Protection . . . . . . . . . . . . . 19 109 A.2.4. Service Separation . . . . . . . . . . . . . . . . . . 19 110 A.2.5. An Alternative Inter-AS VPN Solution . . . . . . . . . 20 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 113 1. Terminology 115 This document uses MPLS terminology defined in [RFC5036]. Additional 116 terms are defined below: 118 o MT-ID: A 16 bit value used to represent the Multi-Topology ID. 120 o Default MT Topology: A topology that is built using the MT-ID 121 default value of 0. 123 o MT Topology: A topology that is built using the corresponding 124 MT-ID. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 2. Introduction 132 Multi-Topology (MT) routing is supported in IP networks with the use 133 of MT aware IGP protocols. It would be advantageous for 134 communications Service Providers (CSP) to support Multiple Topologies 135 (MT) within MPLS environments (MPLS-MT). The benefits of MPLS-MT 136 enabled networks include: 138 o A CSP may want to assign varying QoS profiles to traffic, based on 139 a specific MT. 141 o Separate routing and MPLS domains may be used to isolated 142 multicast and IPv6 islands within the backbone network. 144 o Specific IP address space could be routed across an MT based on 145 security or operational isolation requirements. 147 o Low latency links could be assigned to an MT for delay sensitive 148 traffic. 150 o Management traffic could be separated from customer traffic using 151 multiple MTs, where the management traffic MT does not use links 152 that carries customer traffic. 154 This document describes the Label Distribution Protocol (LDP) 155 procedures and protocol extensions required to support MT routing in 156 an MPLS environment. 158 This document also updates RFC4379 by defining two new FEC types for 159 LSP ping. 161 3. Signaling Extensions 163 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) 165 LDP assigns and binds a label to a Forwarding Equivalence Class 166 (FEC), where a FEC is a list of one of more FEC elements. To setup 167 LSPs for unicast IP routing paths, LDP assigns local labels for IP 168 prefixes, and advertises these labels to its peers so that an LSP is 169 setup along the routing path. To setup MT LSPs for IP prefixes under 170 a given topology scope, the LDP "prefix-related" FEC element must be 171 extended to include topology information. This infers that MT-ID 172 becomes an attribute of Prefix-related FEC element, and all FEC-Label 173 binding operations are performed under the context of given topology 174 (MT-ID). 176 The following Subsection 3.2(New Address Families (AF): MT IP) 177 defines the extension required to bind "prefix-related" FEC to a 178 topology. 180 3.2. New Address Families: MT IP 182 The LDP base specification [RFC5036] (Section 4.1) defines the 183 "Prefix" FEC Element as follows: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Prefix (2) | Address Family | PreLen | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Prefix | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 1: Prefix FEC Element Format [RFC5036] 195 Where "Prefix" encoding is as defined for given "Address Family" 196 (AF), and whose length (in bits) is specified by the "PreLen" field. 198 To extend IP address families for MT, two new Address Families named 199 "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes 200 within a topology scope. 202 The format of data associated with these new Address Families are 203 described below: 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | IP Address | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Reserved | MT-ID | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 2: MT IP Address Family Format 215 Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and 216 "MT IPv6" AF respectively, and the field "MT-ID" corresponds to 16- 217 bit Topology ID for given address. 219 Where 16-bit "MT-ID" field defines the Topology ID, and the 220 definition and usage of the rest fields in the FEC Elements are same 221 as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to 222 default topology and MUST be ignored on receipt so as to not cause 223 any conflict/confusion with existing non-MT procedures. 225 The proposed FEC Elements with "MT IP" Address Family can be used in 226 any LDP message and procedures that currently specify and allow the 227 use of FEC Elements with IP/IPv6 Address Family. 229 [RFC5036] does not specify the handling of "Unknown" Address 230 Families. Therefore, [RFC5036] will need to be updated to include 231 the handling procedure for unknown address families. 233 3.3. LDP FEC Elements with MT IP AF 235 The following section specifies the format extensions of the existing 236 LDP FEC Elements. The "Address Family" of these FEC elements will be 237 set to "MT IP" or "MT IPv6". 239 The MT Prefix FEC element encoding is as follows: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Prefix | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Reserved | MT-ID | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 3: MT Prefix FEC Element Format 252 Similarly, the MT mLDP FEC elements encoding is as follows, where the 253 mLDP FEC Type can be P2MP(6), MP2MP-up(7), and MP2MP-down(8): 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | mLDP FEC Type | Address Family (MT IP/MT IPv6)| Address Length| 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 ~ Root Node Address ~ 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Reserved | MT-ID | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Opaque Length | Opaque Value ... | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 266 ~ ~ 267 | | 268 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 4: MT mLDP FEC Element Format 274 The MT Typed Wildcard FEC element encoding is as follows: 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |Typed Wcard (5)| FEC Type | Len = 6 | AF = MT IP ..| 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |... or MT IPv6 | MT ID | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 5: MT Typed Wildcard FEC Element 286 3.4. IGP MT-ID Mapping and Translation 288 The non-reserved non-special IGP MT-ID values can be used and carried 289 in LDP without the need for translation. However, there is a need 290 for translating reserved or special IGP MT-ID values to corresponding 291 LDP MT-IDs. The corresponding special and reserved LDP MT-ID 292 values are requested In Section 9. (IANA Considerations). 294 3.5. LDP MT Capability Advertisement 296 We specify a new LDP capability, named "Multi-Topology (MT)", which 297 is defined in accordance with LDP Capability definition guidelines 298 [RFC5561]. The LDP "MT" capability can be advertised by an LDP 299 speaker to its peers either during the LDP session initialization or 300 after the LDP session is setup to announce LSR capability to support 301 MT for the given IP address family. 303 The MT capability is specified using "Multi-Topology Capability" 304 TLV. The "Multi-Topology Capability" TLV format is in accordance 305 with LDP capability guidelines as defined in [RFC5561]. To be able 306 to specify IP address family, the capability specific data (i.e. 307 "Capability Data" field of Capability TLV) is populated using "Typed 308 Wildcard FEC Element" as defined in [RFC5918]. 310 The format of "Multi-Topology Capability" TLV is as follows: 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |U|F| Multi-Topology Cap.(IANA) | Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 |S| Reserved | | 318 +-+-+-+-+-+-+-+-+ | 319 ~ Typed Wildcard FEC element(s) ~ 320 | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 6: Multi-Topology Capability TLV Format 325 Where: 327 o U- and F-bits: MUST be 1 and 0, respectively, as per Section 3. 328 (Signaling Extensions) of LDP Capabilities [RFC5561]. 330 o Multi-Topology Capability: Capability TLV type (IANA assigned) 332 o S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be 333 set to 0 or 1 in dynamic "Capability" message to advertise or 334 withdraw the capability respectively. 336 o Typed Wildcard FEC element(s): One or more elements specified as 337 the "Capability data". 339 o Length: The length (in octets) of TLV. 341 o The encoding of Typed Wildcard FEC element, as defined in 342 [RFC5918], is defined in the section 3.3 (Typed Wildcard FEC 343 Element) of this document. 345 3.6. Procedures 347 To announce its MT capability for an IP address family, LDP FEC type, 348 and Multi Topology, an LDP speaker MAY send an "MT Capability" 349 including the exact Typed Wildcard FEC element with corresponding 350 "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT 351 IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., 352 set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To 353 announce its MT capability for both IPv4 and IPv6 address family, or 354 for multiple FEC types, or for multiple Multi Topologies, an LDP 355 speaker MAY send "MT Capability" with one or more MT Typed FEC 356 elements in it. 358 o The capability for supporting multi-topology in LDP can be 359 advertised during LDP session initialization stage by including 360 the LDP MT capability TLV in LDP Initialization message. After an 361 LDP session is established, the MT capability can also be 362 advertised or withdrawn using Capability message (only if "Dynamic 363 Announcement" capability [RFC5561] has already been successfully 364 negotiated). 366 o If an LSR has not advertised MT capability, its peer must not send 367 messages that include MT identifier to this LSR. 369 o If an LSR receives a Label Mapping message with an MT parameter 370 from downstream LSR-D and its upstream LSR-U has not advertised MT 371 capability, an LSP for the MT will not be established. 373 o This document proposes to add a new notification event to signal 374 the upstream that the downstream is not capable. 376 o If an LSR is changed from non-MT capable to MT capable, it sets 377 the S bit in MT capability TLV and advertises via the Capability 378 message. The existing LSP is treated as LSP for default MT (ID 379 0). 381 o If an LSR is changed from LDP-MT capable to non-MT capable, it may 382 initiate withdraw of all label mapping for existing LSPs of all 383 non-default MTs. Then it clears the S bit in MT capability TLV 384 and advertises via the Capability message. 386 o If an LSR is changed from IGP-MT capable to non-MT capable, it may 387 wait until the routes update to withdraw FEC and release the label 388 mapping for existing LSPs of specific MT. 390 3.7. LDP Sessions 392 Since using different label spaces for different topologies would 393 imply significant changes to the data plane, a single global label 394 space is supported in this solution. There will be one session 395 supported for each pair of peer, even there are multiple topologies 396 supported between these two peers. 398 3.8. Reserved MT ID Values 400 Certain MT topologies are assigned to serve predetermined purposes: 402 Default-MT: Default topology. This corresponds to OSPF default IPv4 403 and IPv6, as well as ISIS default IPv4. A value of 0 is proposed. 405 ISIS IPv6 MT: ISIS default MT-ID for IPv6. 407 Wildcard-MT: This corresponds to All-Topologies. A value of 65535 408 (0xffff) is proposed. 410 In Section 9. (IANA Considerations) this document proposes a new 411 IANA registry "LDP Multi-Topology ID Name Space" under IANA "LDP 412 Parameter" namespace to keep an LDP MT-ID reserved value. 414 If an LSR receives a FEC element with an "MT-ID" value that is 415 "Reserved" for future use (and not IANA allocated yet), the LSR must 416 abort the processing of the FEC element, and SHOULD send a 417 notification message with status code "Invalid MT-ID" to the sender. 419 4. MT Applicability on FEC-based features 421 4.1. Typed Wildcard FEC Element 423 [RFC5918] extends base LDP and defines Typed Wildcard FEC Element 424 framework. Typed Wildcard FEC element can be used in any LDP message 425 to specify a wildcard operation/action for given type of FEC. 427 The MT extensions proposed in document do not require any extension 428 to procedures for Typed Wildcard FEC element, and these procedures 429 apply as-is to MT wildcarding. The MT extensions, though, allow use 430 of "MT IP" or "MT IPv6" in the Address Family field of the Typed 431 Wildcard FEC element in order to use wildcard operations in the 432 context of a given topology. The use of MT-scoped address family 433 also allows us to specify MT-ID in these operations. 435 The proposed format in Section 3.3 (Typed Wildcard FEC Element) 436 allows an LSR to perform wildcard FEC operations under the scope of a 437 topology. If an LSR wishes to perform wildcard operation that 438 applies to all topologies, it can use a "Wildcard Topology" MT-ID. 439 For example, upon local configuration of topology "x", an LSR may 440 send a wildcard label withdraw request with MT-ID "x" to withdraw all 441 its labels from the peer that advertized under the scope of topology 442 "x". Additionally, upon a global configuration change, an LSR may 443 send a wildcard label withdraw with the MT-ID set to "Wildcard 444 Topology" to withdraw all its labels under all topologies from the 445 peer. 447 4.2. End-of-LIB 449 [RFC5919] specifies extensions and procedures for an LDP speaker to 450 signal its convergence for a given FEC type towards a peer. The 451 procedures defined in [RFC5919] applies as-is to an MT FEC element. 452 This MAY allow an LDP speaker to signal its IP convergence using 453 Typed Wildcard FEC element, and its MT IP convergence per topology 454 using a MT Typed Wildcard FEC element. 456 4.3. LSP Ping 458 [RFC4379] defines procedures to detect data-plane failures in MPLS 459 LSPs via LSP ping. The specification defines a "Target FEC Stack" 460 TLV that describes the FEC stack being tested. This TLV is sent in 461 an MPLS echo request message towards LSPs egress LSR, and is 462 forwarded along the same data path as other packets belonging to the 463 FEC. 465 "Target FEC Stack" TLV contains one or more sub-TLVs pertaining to 466 different FEC types. Section 3.2 of [RFC4379] defines Sub-Types and 467 format for the FEC. To support LSP ping for MT LDP LSPs, this 468 document proposes following extensions to [RFC4379]. 470 4.3.1. New FEC Sub-Types 472 We define two new FEC types for LSP ping: 474 o MT LDP IPv4 FEC 476 o MT LDP IPv6 FEC 478 We also define following new sub-types for sub-TLVs to specify these 479 FECs in the "Target FEC Stack" TLV of [RFC4379]: 481 Sub-Type Length Value Field 482 -------- ------ ----------------- 483 TBA5 5 MT LDP IPv4 prefix 484 TBA6 17 MT LDP IPv6 prefix 486 Figure 7: new sub-types for sub-TLVs 488 The rules and procedures of using these sub-TLVs in an MPLS echo 489 request message are same as defined for LDP IPv4/IPv6 FEC sub-TLV 490 types in [RFC4379]. 492 4.3.2. MT LDP IPv4 FEC Sub-TLV 494 The format of "MT LDP IPv4 FEC" sub-TLV to be used in a "Target FEC 495 Stack" [RFC4379] is: 497 0 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Type = TBA5(MT LDP IPv4 FEC) | Length = 8 | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | IPv4 prefix | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Prefix Length | MBZ | MT-ID | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Figure 8: MT LDP IPv4 FEC sub-TLV 509 The format of this sub-TLV is similar to LDP IPv4 FEC sub-TLV as 510 defined in [RFC4379]. In addition to "IPv4 prefix" and "Prefix 511 Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology 512 ID). The Length for this sub-TLV is 5. 514 4.3.3. MT LDP IPv6 FEC Sub-TLV 516 The format of "MT LDP IPv6 FEC" sub-TLV to be used in a "Target FEC 517 Stack" [RFC4379] is: 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Type = TBA6(MT LDP IPv6 FEC) | Length = 20 | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | | 525 | IPv6 prefix | 526 | | 527 | | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Prefix Length | MBZ | MT-ID | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Figure 9: MT LDP IPv6 FEC sub-TLV 534 The format of this sub-TLV is similar to LDP IPv6 FEC sub-TLV as 535 defined in [RFC4379]. In addition to "IPv6 prefix" and "Prefix 536 Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology 537 ID). The Length for this sub-TLV is 17. 539 4.3.4. Operation Considerations 541 When detect data plane failures using LSP Ping for a specific topoly, 542 the router will intiate an LSP Ping request with the targer FEC stack 543 TLV containing LDP MT IP Prefix Sub-TLV in the Echo Request packet. 544 The Echo Request packet is sent with the label binded to the IP 545 Prefix in the topolgy. Once the echo request packet reaches the 546 target router, it will process the packet and perform checs for the 547 LDP MT IP Prefix sub-TLV present in the Target FEC Stack as described 548 in [RFC4379] and respond according to [RFC4379] processing rules. 549 For the case that the LSP ping with return path not specified , the 550 reply packet may go through the default topology instead of the 551 topology where the Echo Request goes through. 553 5. Error Handling 555 The extensions defined in this document utilise the existing LDP 556 error handling defined in [RFC5036]. If an LSR receives an error 557 notification from a peer for an MPLS-MT session, it terminates the 558 LDP session by closing the TCP transport connection for the session 559 and discarding all MT-ID label mappings learned via the session. 561 5.1. MT Error Notification for Invalid Topology ID 563 If an LSR has advertized an MT Capability TLV using the 564 Initialization message or Capability message, which includes Typed 565 Wildcard FEC elements with specific MT-IDs, and it receives an MT 566 message with a MT-ID which is not included in the supported list, it 567 should response this "Invalid Topology ID" status code. 569 6. Backwards Compatibility 571 The MPLS-MT solution is backwards compatible with existing LDP 572 enhancements defined in [RFC5036], including message authenticity, 573 integrity of message, and topology loop detection. 575 7. MPLS Forwarding in MT 577 Although forwarding is out of the scope of this draft, we include 578 some forwarding consideration for informational purpose here. 580 The specified signaling mechanisms allow all the topologies to share 581 the platform-specific label space; this is the feature that allows 582 the existing data plane techniques to be used; and the specified 583 signaling mechanisms do not provide any way for the data plane to 584 associate a given packet with a context-specific label space. 586 8. Security Consideration 588 No specific security issues with the proposed solutions are known. 589 The proposed extensions in this document do not introduce any new 590 security considerations beyond that already apply to the base LDP 591 specification [RFC5036] and [RFC5920]. 593 9. IANA Considerations 595 The document introduces following new protocol elements that require 596 IANA consideration and assignments: 598 o New LDP Capability TLV: "Multi-Topology Capability" TLV (requested 599 code point: TBA1 from LDP registry "TLV Type Name Space"). 601 o New Status Code: "Multi-Topology Capability not supported" 602 (requested code point: TBA2 from LDP registry "Status Code Name 603 Space"). 605 o New Status Code: "Invalid Topology ID" (requested code point: TBA3 606 from LDP registry "Status Code Name Space"). 608 o New Status Code: "Unknown Address Family" (requested code point: 609 TBA4 from LDP registry "Status Code Name Space"). 611 Registry: 612 Range/Value E Description 613 -------------- --- ------------------------------ 614 0x00000051 1 Invalid Topology ID 616 Figure 10: New Status Codes for LDP Multi Topology Extensions 618 o New address families under IANA registry "Address Family Numbers": 620 - MT IP: Multi-Topology IP version 4 (requested codepoint: 26) 621 - MT IPv6: Multi-Topology IP version 6 (requested codepoint: 27) 623 Figure 11: Address Family Numbers 625 o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP 626 Parameter" namespace. The registry is defined as: 628 Range/Value Name 629 ----------- ------------------------ 630 0 Default Topology (ISIS and OSPF) 631 1-4095 Unassigned 632 4096 ISIS IPv6 routing topology 633 (i.e. ISIS MT ID #2) 634 4097-65534 Reserved (for future allocation) 635 65535 Wildcard Topology (ISIS or OSPF) 637 Figure 12: LDP Multi-Topology (MT) ID Name Space 639 o New Sub-TLV Types for LSP ping: Following new sub-type values 640 under TLV type 1 (Target FEC Stack) from "Multi-Protocol Label 641 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 642 registry, and "TLVs and sub-TLVs" sub-registry. 644 Sub-Type Value Field 645 -------- ----------- 646 TBA5 MT LDP IPv4 prefix 647 TBA6 MT LDP IPv6 prefix 649 Figure 13: New Sub-TLV Types for LSP ping 651 10. Contributors 653 Ning So 654 Tata Communications 655 2613 Fairbourne Cir. 656 Plano, TX 75082 657 USA 659 Email: ning.so@tatacommunications.com 661 Raveendra Torvi 662 Juniper Networks 663 10, Technoogy Park Drive 664 Westford, MA 01886-3140 665 US 667 Email: rtorvi@juniper.net 669 Huaimo Chen 670 Huawei Technology 671 125 Nagog Technology Park 672 Acton, MA 01719 673 US 675 Email: huaimochen@huawei.com 677 Emily Chen 678 2717 Seville Blvd, Apt 1205, 679 Clearwater, FL 33764 680 US 682 Email: emily.chen220@gmail.com 684 Chen Li 685 China Mobile 686 53A, Xibianmennei Ave. 687 Xunwu District, Beijing 01719 688 China 690 Email: lichenyj@chinamobile.com 692 Lu Huang 693 China Mobile 694 53A, Xibianmennei Ave. 695 Xunwu District, Beijing 01719 696 China 698 Email: huanglu@chinamobile.com 699 Daniel King 700 Old Dog Consulting 702 Email: E-mail: daniel@olddog.co.uk 704 Zhenbin Li 705 Huawei Technology 706 2330 Central Expressway 707 Santa Clara, CA 95050 708 US 710 Email: zhenbin.li@huawei.com 712 11. Acknowledgement 714 The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin, 715 Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun Chai and 716 pranjal Dutta, George Swallow and Curtis Villamizar for their 717 valuable comments on this draft. 719 12. References 721 12.1. Normative References 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, March 1997. 726 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 727 Label Switched (MPLS) Data Plane Failures", RFC 4379, 728 February 2006. 730 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 731 Specification", RFC 5036, October 2007. 733 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 734 Le Roux, "LDP Capabilities", RFC 5561, July 2009 736 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 737 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 738 (FEC)", RFC 5918, August 2010. 740 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 741 "Signaling LDP Label Advertisement Completion", RFC 5919, 742 August 2010. 744 12.2. Informative References 746 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 747 Networks", RFC 5920, July 2010. 749 Authors' Addresses 751 Quintin Zhao 752 Huawei Technology 753 125 Nagog Technology Park 754 Acton, MA 01719 755 US 757 Email: quintin.zhao@huawei.com 759 Luyuan Fang 760 Cisco Systems 761 300 Beaver Brook Road 762 Boxborough, MA 01719 763 US 765 Email: lufang@cisco.com 767 Chao Zhou 768 Cisco Systems 769 300 Beaver Brook Road 770 Boxborough, MA 01719 771 US 773 Email: czhou@cisco.com 775 Lianyuan Li 776 China Mobile 777 53A, Xibianmennei Ave. 778 Xunwu District, Beijing 01719 779 China 781 Email: lilianyuan@chinamobile.com 783 Kamran Raza 784 Cisco Systems 785 2000 Innovation Drive 786 Kanata, ON K2K-3E8, MA 787 Canada 789 Email: E-mail: skraza@cisco.com