idnits 2.17.1 draft-ietf-mpls-ldp-multi-topology-08.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 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 (May 13, 2013) is 4001 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 13, 2013 Cisco Systems 7 L. Li 8 China Mobile 9 K. Raza 10 Cisco Systems 11 May 13, 2013 13 LDP Extensions for Multi Topology Routing 14 draft-ietf-mpls-ldp-multi-topology-08.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 13, 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 Table of Contents 61 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Signaling Extensions . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) . . . . 5 65 3.2. New Address Families: MT IP . . . . . . . . . . . . . . . 5 66 3.3. LDP FEC Elements with MT IP AF . . . . . . . . . . . . . . 6 67 3.4. IGP MT-ID Mapping and Translation . . . . . . . . . . . . 7 68 3.5. LDP MT Capability Advertisement . . . . . . . . . . . . . 8 69 3.6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.7. LDP Sessions . . . . . . . . . . . . . . . . . . . . . . . 10 71 3.8. Reserved MT ID Values . . . . . . . . . . . . . . . . . . 10 72 4. MT Applicability on FEC-based features . . . . . . . . . . . . 10 73 4.1. Typed Wildcard FEC Element . . . . . . . . . . . . . . . . 10 74 4.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.3. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.3.1. New FEC Sub-Types . . . . . . . . . . . . . . . . . . 11 77 4.3.2. MT LDP IPv4 FEC Sub-TLV . . . . . . . . . . . . . . . 12 78 4.3.3. MT LDP IPv6 FEC Sub-TLV . . . . . . . . . . . . . . . 12 79 4.3.4. Operation Considerations . . . . . . . . . . . . . . . 13 80 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 13 81 5.1. MT Error Notification for Invalid Topology ID . . . . . . 13 82 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14 83 7. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 14 84 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 91 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 18 92 A.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 93 A.2. Application Scenarios . . . . . . . . . . . . . . . . . . 18 94 A.2.1. Simplified Data-plane . . . . . . . . . . . . . . . . 18 95 A.2.2. Using MT for P2P Protection . . . . . . . . . . . . . 19 96 A.2.3. Using MT for mLDP Protection . . . . . . . . . . . . . 19 97 A.2.4. Service Separation . . . . . . . . . . . . . . . . . . 19 98 A.2.5. An Alternative Inter-AS VPN Solution . . . . . . . . . 20 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 101 1. Terminology 103 This document uses MPLS terminology defined in [RFC5036]. Additional 104 terms are defined below: 106 o MT-ID: A 16 bit value used to represent the Multi-Topology ID. 108 o Default MT Topology: A topology that is built using the MT-ID 109 default value of 0. 111 o MT Topology: A topology that is built using the corresponding 112 MT-ID. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2. Introduction 120 Multi-Topology (MT) routing is supported in IP networks with the use 121 of MT aware IGP protocols. It would be advantageous for 122 communications Service Providers (CSP) to support Multiple Topologies 123 (MT) within MPLS environments (MPLS-MT). The benefits of MPLS-MT 124 enabled networks include: 126 o A CSP may want to assign varying QoS profiles to traffic, based on 127 a specific MT. 129 o Separate routing and MPLS domains may be used to isolated 130 multicast and IPv6 islands within the backbone network. 132 o Specific IP address space could be routed across an MT based on 133 security or operational isolation requirements. 135 o Low latency links could be assigned to an MT for delay sensitive 136 traffic. 138 o Management traffic could be separated from customer traffic using 139 multiple MTs, where the management traffic MT does not use links 140 that carries customer traffic. 142 This document describes the Label Distribution Protocol (LDP) 143 procedures and protocol extensions required to support MT routing in 144 an MPLS environment. 146 This document also updates RFC4379 by defining two new FEC types for 147 LSP ping. 149 3. Signaling Extensions 151 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) 153 LDP assigns and binds a label to a Forwarding Equivalence Class 154 (FEC), where a FEC is a list of one of more FEC elements. To setup 155 LSPs for unicast IP routing paths, LDP assigns local labels for IP 156 prefixes, and advertises these labels to its peers so that an LSP is 157 setup along the routing path. To setup MT LSPs for IP prefixes under 158 a given topology scope, the LDP "prefix-related" FEC element must be 159 extended to include topology information. This infers that MT-ID 160 becomes an attribute of Prefix-related FEC element, and all FEC-Label 161 binding operations are performed under the context of given topology 162 (MT-ID). 164 The following Subsection 3.2(New Address Families (AF): MT IP) 165 defines the extension required to bind "prefix-related" FEC to a 166 topology. 168 3.2. New Address Families: MT IP 170 The LDP base specification [RFC5036] (Section 4.1) defines the 171 "Prefix" FEC Element as follows: 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Prefix (2) | Address Family | PreLen | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Prefix | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Figure 1: Prefix FEC Element Format [RFC5036] 183 Where "Prefix" encoding is as defined for given "Address Family" 184 (AF), and whose length (in bits) is specified by the "PreLen" field. 186 To extend IP address families for MT, two new Address Families named 187 "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes 188 within a topology scope. 190 The format of data associated with these new Address Families are 191 described below: 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | IP Address | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Reserved | MT-ID | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 2: MT IP Address Family Format 203 Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and 204 "MT IPv6" AF respectively, and the field "MT-ID" corresponds to 16- 205 bit Topology ID for given address. 207 Where 16-bit "MT-ID" field defines the Topology ID, and the 208 definition and usage of the rest fields in the FEC Elements are same 209 as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to 210 default topology and MUST be ignored on receipt so as to not cause 211 any conflict/confusion with existing non-MT procedures. 213 The proposed FEC Elements with "MT IP" Address Family can be used in 214 any LDP message and procedures that currently specify and allow the 215 use of FEC Elements with IP/IPv6 Address Family. 217 [RFC5036] does not specify the handling of "Unknown" Address 218 Families. Therefore, [RFC5036] will need to be updated to include 219 the handling procedure for unknown address families. 221 3.3. LDP FEC Elements with MT IP AF 223 The following section specifies the format extensions of the existing 224 LDP FEC Elements. The "Address Family" of these FEC elements will be 225 set to "MT IP" or "MT IPv6". 227 The MT Prefix FEC element encoding is as follows: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Prefix | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Reserved | MT-ID | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 3: MT Prefix FEC Element Format 240 Similarly, the MT mLDP FEC elements encoding is as follows, where the 241 mLDP FEC Type can be P2MP(6), MP2MP-up(7), and MP2MP-down(8): 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | mLDP FEC Type | Address Family (MT IP/MT IPv6)| Address Length| 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 ~ Root Node Address ~ 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Reserved | MT-ID | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Opaque Length | Opaque Value ... | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 254 ~ ~ 255 | | 256 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 4: MT mLDP FEC Element Format 262 The MT Typed Wildcard FEC element encoding is as follows: 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |Typed Wcard (5)| FEC Type | Len = 6 | AF = MT IP ..| 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 |... or MT IPv6 | MT ID | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 5: MT Typed Wildcard FEC Element 274 3.4. IGP MT-ID Mapping and Translation 276 The non-reserved non-special IGP MT-ID values can be used and carried 277 in LDP without the need for translation. However, there is a need 278 for translating reserved or special IGP MT-ID values to corresponding 279 LDP MT-IDs. The corresponding special and reserved LDP MT-ID 280 values are requested In Section 9. (IANA Considerations). 282 3.5. LDP MT Capability Advertisement 284 We specify a new LDP capability, named "Multi-Topology (MT)", which 285 is defined in accordance with LDP Capability definition guidelines 286 [RFC5561]. The LDP "MT" capability can be advertised by an LDP 287 speaker to its peers either during the LDP session initialization or 288 after the LDP session is setup to announce LSR capability to support 289 MT for the given IP address family. 291 The MT capability is specified using "Multi-Topology Capability" 292 TLV. The "Multi-Topology Capability" TLV format is in accordance 293 with LDP capability guidelines as defined in [RFC5561]. To be able 294 to specify IP address family, the capability specific data (i.e. 295 "Capability Data" field of Capability TLV) is populated using "Typed 296 Wildcard FEC Element" as defined in [RFC5918]. 298 The format of "Multi-Topology Capability" TLV is as follows: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |U|F| Multi-Topology Cap.(IANA) | Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 |S| Reserved | | 306 +-+-+-+-+-+-+-+-+ | 307 ~ Typed Wildcard FEC element(s) ~ 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 6: Multi-Topology Capability TLV Format 313 Where: 315 o U- and F-bits: MUST be 1 and 0, respectively, as per Section 3. 316 (Signaling Extensions) of LDP Capabilities [RFC5561]. 318 o Multi-Topology Capability: Capability TLV type (IANA assigned) 320 o S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be 321 set to 0 or 1 in dynamic "Capability" message to advertise or 322 withdraw the capability respectively. 324 o Typed Wildcard FEC element(s): One or more elements specified as 325 the "Capability data". 327 o Length: The length (in octets) of TLV. 329 o The encoding of Typed Wildcard FEC element, as defined in 330 [RFC5918], is defined in the section 3.3 (Typed Wildcard FEC 331 Element) of this document. 333 3.6. Procedures 335 To announce its MT capability for an IP address family, LDP FEC type, 336 and Multi Topology, an LDP speaker MAY send an "MT Capability" 337 including the exact Typed Wildcard FEC element with corresponding 338 "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT 339 IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., 340 set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To 341 announce its MT capability for both IPv4 and IPv6 address family, or 342 for multiple FEC types, or for multiple Multi Topologies, an LDP 343 speaker MAY send "MT Capability" with one or more MT Typed FEC 344 elements in it. 346 o The capability for supporting multi-topology in LDP can be 347 advertised during LDP session initialization stage by including 348 the LDP MT capability TLV in LDP Initialization message. After an 349 LDP session is established, the MT capability can also be 350 advertised or withdrawn using Capability message (only if "Dynamic 351 Announcement" capability [RFC5561] has already been successfully 352 negotiated). 354 o If an LSR has not advertised MT capability, its peer must not send 355 messages that include MT identifier to this LSR. 357 o If an LSR receives a Label Mapping message with an MT parameter 358 from downstream LSR-D and its upstream LSR-U has not advertised MT 359 capability, an LSP for the MT will not be established. 361 o This document proposes to add a new notification event to signal 362 the upstream that the downstream is not capable. 364 o If an LSR is changed from non-MT capable to MT capable, it sets 365 the S bit in MT capability TLV and advertises via the Capability 366 message. The existing LSP is treated as LSP for default MT (ID 367 0). 369 o If an LSR is changed from LDP-MT capable to non-MT capable, it may 370 initiate withdraw of all label mapping for existing LSPs of all 371 non-default MTs. Then it clears the S bit in MT capability TLV 372 and advertises via the Capability message. 374 o If an LSR is changed from IGP-MT capable to non-MT capable, it may 375 wait until the routes update to withdraw FEC and release the label 376 mapping for existing LSPs of specific MT. 378 3.7. LDP Sessions 380 Since using different label spaces for different topologies would 381 imply significant changes to the data plane, a single global label 382 space is supported in this solution. There will be one session 383 supported for each pair of peer, even there are multiple topologies 384 supported between these two peers. 386 3.8. Reserved MT ID Values 388 Certain MT topologies are assigned to serve predetermined purposes: 390 Default-MT: Default topology. This corresponds to OSPF default IPv4 391 and IPv6, as well as ISIS default IPv4. A value of 0 is proposed. 393 ISIS IPv6 MT: ISIS default MT-ID for IPv6. 395 Wildcard-MT: This corresponds to All-Topologies. A value of 65535 396 (0xffff) is proposed. 398 In Section 9. (IANA Considerations) this document proposes a new 399 IANA registry "LDP Multi-Topology ID Name Space" under IANA "LDP 400 Parameter" namespace to keep an LDP MT-ID reserved value. 402 If an LSR receives a FEC element with an "MT-ID" value that is 403 "Reserved" for future use (and not IANA allocated yet), the LSR must 404 abort the processing of the FEC element, and SHOULD send a 405 notification message with status code "Invalid MT-ID" to the sender. 407 4. MT Applicability on FEC-based features 409 4.1. Typed Wildcard FEC Element 411 [RFC5918] extends base LDP and defines Typed Wildcard FEC Element 412 framework. Typed Wildcard FEC element can be used in any LDP message 413 to specify a wildcard operation/action for given type of FEC. 415 The MT extensions proposed in document do not require any extension 416 to procedures for Typed Wildcard FEC element, and these procedures 417 apply as-is to MT wildcarding. The MT extensions, though, allow use 418 of "MT IP" or "MT IPv6" in the Address Family field of the Typed 419 Wildcard FEC element in order to use wildcard operations in the 420 context of a given topology. The use of MT-scoped address family 421 also allows us to specify MT-ID in these operations. 423 The proposed format in Section 3.3 (Typed Wildcard FEC Element) 424 allows an LSR to perform wildcard FEC operations under the scope of a 425 topology. If an LSR wishes to perform wildcard operation that 426 applies to all topologies, it can use a "Wildcard Topology" MT-ID. 427 For example, upon local configuration of topology "x", an LSR may 428 send a wildcard label withdraw request with MT-ID "x" to withdraw all 429 its labels from the peer that advertized under the scope of topology 430 "x". Additionally, upon a global configuration change, an LSR may 431 send a wildcard label withdraw with the MT-ID set to "Wildcard 432 Topology" to withdraw all its labels under all topologies from the 433 peer. 435 4.2. End-of-LIB 437 [RFC5919] specifies extensions and procedures for an LDP speaker to 438 signal its convergence for a given FEC type towards a peer. The 439 procedures defined in [RFC5919] applies as-is to an MT FEC element. 440 This MAY allow an LDP speaker to signal its IP convergence using 441 Typed Wildcard FEC element, and its MT IP convergence per topology 442 using a MT Typed Wildcard FEC element. 444 4.3. LSP Ping 446 [RFC4379] defines procedures to detect data-plane failures in MPLS 447 LSPs via LSP ping. The specification defines a "Target FEC Stack" 448 TLV that describes the FEC stack being tested. This TLV is sent in 449 an MPLS echo request message towards LSPs egress LSR, and is 450 forwarded along the same data path as other packets belonging to the 451 FEC. 453 "Target FEC Stack" TLV contains one or more sub-TLVs pertaining to 454 different FEC types. Section 3.2 of [RFC4379] defines Sub-Types and 455 format for the FEC. To support LSP ping for MT LDP LSPs, this 456 document proposes following extensions to [RFC4379]. 458 4.3.1. New FEC Sub-Types 460 We define two new FEC types for LSP ping: 462 o MT LDP IPv4 FEC 464 o MT LDP IPv6 FEC 466 We also define following new sub-types for sub-TLVs to specify these 467 FECs in the "Target FEC Stack" TLV of [RFC4379]: 469 Sub-Type Length Value Field 470 -------- ------ ----------------- 471 TBA5 5 MT LDP IPv4 prefix 472 TBA6 17 MT LDP IPv6 prefix 474 Figure 7: new sub-types for sub-TLVs 476 The rules and procedures of using these sub-TLVs in an MPLS echo 477 request message are same as defined for LDP IPv4/IPv6 FEC sub-TLV 478 types in [RFC4379]. 480 4.3.2. MT LDP IPv4 FEC Sub-TLV 482 The format of "MT LDP IPv4 FEC" sub-TLV to be used in a "Target FEC 483 Stack" [RFC4379] is: 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Type = TBA5(MT LDP IPv4 FEC) | Length = 8 | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | IPv4 prefix | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Prefix Length | MBZ | MT-ID | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 Figure 8: MT LDP IPv4 FEC sub-TLV 497 The format of this sub-TLV is similar to LDP IPv4 FEC sub-TLV as 498 defined in [RFC4379]. In addition to "IPv4 prefix" and "Prefix 499 Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology 500 ID). The Length for this sub-TLV is 5. 502 4.3.3. MT LDP IPv6 FEC Sub-TLV 504 The format of "MT LDP IPv6 FEC" sub-TLV to be used in a "Target FEC 505 Stack" [RFC4379] is: 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Type = TBA6(MT LDP IPv6 FEC) | Length = 20 | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | | 513 | IPv6 prefix | 514 | | 515 | | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Prefix Length | MBZ | MT-ID | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 9: MT LDP IPv6 FEC sub-TLV 522 The format of this sub-TLV is similar to LDP IPv6 FEC sub-TLV as 523 defined in [RFC4379]. In addition to "IPv6 prefix" and "Prefix 524 Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology 525 ID). The Length for this sub-TLV is 17. 527 4.3.4. Operation Considerations 529 When detect data plane failures using LSP Ping for a specific topoly, 530 the router will intiate an LSP Ping request with the targer FEC stack 531 TLV containing LDP MT IP Prefix Sub-TLV in the Echo Request packet. 532 The Echo Request packet is sent with the label binded to the IP 533 Prefix in the topolgy. Once the echo request packet reaches the 534 target router, it will process the packet and perform checs for the 535 LDP MT IP Prefix sub-TLV present in the Target FEC Stack as described 536 in [RFC4379] and respond according to [RFC4379] processing rules. 537 For the case that the LSP ping with return path not specified , the 538 reply packet may go through the default topology instead of the 539 topology where the Echo Request goes through. 541 5. Error Handling 543 The extensions defined in this document utilise the existing LDP 544 error handling defined in [RFC5036]. If an LSR receives an error 545 notification from a peer for an MPLS-MT session, it terminates the 546 LDP session by closing the TCP transport connection for the session 547 and discarding all MT-ID label mappings learned via the session. 549 5.1. MT Error Notification for Invalid Topology ID 551 If an LSR has advertized an MT Capability TLV using the 552 Initialization message or Capability message, which includes Typed 553 Wildcard FEC elements with specific MT-IDs, and it receives an MT 554 message with a MT-ID which is not included in the supported list, it 555 should response this "Invalid Topology ID" status code. 557 6. Backwards Compatibility 559 The MPLS-MT solution is backwards compatible with existing LDP 560 enhancements defined in [RFC5036], including message authenticity, 561 integrity of message, and topology loop detection. 563 7. MPLS Forwarding in MT 565 Although forwarding is out of the scope of this draft, we include 566 some forwarding consideration for informational purpose here. 568 The specified signaling mechanisms allow all the topologies to share 569 the platform-specific label space; this is the feature that allows 570 the existing data plane techniques to be used; and the specified 571 signaling mechanisms do not provide any way for the data plane to 572 associate a given packet with a context-specific label space. 574 8. Security Consideration 576 No specific security issues with the proposed solutions are known. 577 The proposed extensions in this document do not introduce any new 578 security considerations beyond that already apply to the base LDP 579 specification [RFC5036] and [RFC5920]. 581 9. IANA Considerations 583 The document introduces following new protocol elements that require 584 IANA consideration and assignments: 586 o New LDP Capability TLV: "Multi-Topology Capability" TLV (requested 587 code point: TBA1 from LDP registry "TLV Type Name Space"). 589 o New Status Code: "Multi-Topology Capability not supported" 590 (requested code point: TBA2 from LDP registry "Status Code Name 591 Space"). 593 o New Status Code: "Invalid Topology ID" (requested code point: TBA3 594 from LDP registry "Status Code Name Space"). 596 o New Status Code: "Unknown Address Family" (requested code point: 597 TBA4 from LDP registry "Status Code Name Space"). 599 Registry: 600 Range/Value E Description 601 -------------- --- ------------------------------ 602 0x00000051 1 Invalid Topology ID 604 Figure 10: New Status Codes for LDP Multi Topology Extensions 606 o New address families under IANA registry "Address Family Numbers": 608 - MT IP: Multi-Topology IP version 4 (requested codepoint: 26) 609 - MT IPv6: Multi-Topology IP version 6 (requested codepoint: 27) 611 Figure 11: Address Family Numbers 613 o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP 614 Parameter" namespace. The registry is defined as: 616 Range/Value Name 617 ----------- ------------------------ 618 0 Default Topology (ISIS and OSPF) 619 1-4095 Unassigned 620 4096 ISIS IPv6 routing topology 621 (i.e. ISIS MT ID #2) 622 4097-65534 Reserved (for future allocation) 623 65535 Wildcard Topology (ISIS or OSPF) 625 Figure 12: LDP Multi-Topology (MT) ID Name Space 627 o New Sub-TLV Types for LSP ping: Following new sub-type values 628 under TLV type 1 (Target FEC Stack) from "Multi-Protocol Label 629 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 630 registry, and "TLVs and sub-TLVs" sub-registry. 632 Sub-Type Value Field 633 -------- ----------- 634 TBA5 MT LDP IPv4 prefix 635 TBA6 MT LDP IPv6 prefix 637 Figure 13: New Sub-TLV Types for LSP ping 639 10. Contributors 641 Ning So 642 Tata Communications 643 2613 Fairbourne Cir. 644 Plano, TX 75082 645 USA 647 Email: ning.so@tatacommunications.com 649 Raveendra Torvi 650 Juniper Networks 651 10, Technoogy Park Drive 652 Westford, MA 01886-3140 653 US 655 Email: rtorvi@juniper.net 657 Huaimo Chen 658 Huawei Technology 659 125 Nagog Technology Park 660 Acton, MA 01719 661 US 663 Email: huaimochen@huawei.com 665 Emily Chen 666 2717 Seville Blvd, Apt 1205, 667 Clearwater, FL 33764 668 US 670 Email: emily.chen220@gmail.com 672 Chen Li 673 China Mobile 674 53A, Xibianmennei Ave. 675 Xunwu District, Beijing 01719 676 China 678 Email: lichenyj@chinamobile.com 680 Lu Huang 681 China Mobile 682 53A, Xibianmennei Ave. 683 Xunwu District, Beijing 01719 684 China 686 Email: huanglu@chinamobile.com 687 Daniel King 688 Old Dog Consulting 690 Email: E-mail: daniel@olddog.co.uk 692 Zhenbin Li 693 Huawei Technology 694 2330 Central Expressway 695 Santa Clara, CA 95050 696 US 698 Email: zhenbin.li@huawei.com 700 11. Acknowledgement 702 The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin, 703 Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun Chai and 704 pranjal Dutta, George Swallow and Curtis Villamizar for their 705 valuable comments on this draft. 707 12. References 709 12.1. Normative References 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, March 1997. 714 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 715 Label Switched (MPLS) Data Plane Failures", RFC 4379, 716 February 2006. 718 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 719 Specification", RFC 5036, October 2007. 721 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 722 Le Roux, "LDP Capabilities", RFC 5561, July 2009 724 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 725 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 726 (FEC)", RFC 5918, August 2010. 728 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 729 "Signaling LDP Label Advertisement Completion", RFC 5919, 730 August 2010. 732 12.2. Informative References 734 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 735 Networks", RFC 5920, July 2010. 737 Authors' Addresses 739 Quintin Zhao 740 Huawei Technology 741 125 Nagog Technology Park 742 Acton, MA 01719 743 US 745 Email: quintin.zhao@huawei.com 747 Luyuan Fang 748 Cisco Systems 749 300 Beaver Brook Road 750 Boxborough, MA 01719 751 US 753 Email: lufang@cisco.com 755 Chao Zhou 756 Cisco Systems 757 300 Beaver Brook Road 758 Boxborough, MA 01719 759 US 761 Email: czhou@cisco.com 763 Lianyuan Li 764 China Mobile 765 53A, Xibianmennei Ave. 766 Xunwu District, Beijing 01719 767 China 769 Email: lilianyuan@chinamobile.com 771 Kamran Raza 772 Cisco Systems 773 2000 Innovation Drive 774 Kanata, ON K2K-3E8, MA 775 Canada 777 Email: E-mail: skraza@cisco.com