idnits 2.17.1 draft-ietf-mpls-ldp-multi-topology-09.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 -- The document date (October 14, 2013) is 3840 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 (==), 1 comment (--). 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 Expires: April 18, 2014 C. Zhou 6 Cisco Systems 7 L. Li 8 China Mobile 9 K. Raza 10 Cisco Systems 11 October 14, 2013 13 LDP Extensions for Multi Topology Routing 14 draft-ietf-mpls-ldp-multi-topology-09.txt 16 Abstract 18 Multi-Topology (MT) routing is supported in IP networks with the use 19 of MT aware IGPs. In order to provide MT routing within 20 Multiprotocol Label Switching (MPLS) Label Distribution Protocol 21 (LDP) networks new extensions are required. 23 This document describes the LDP protocol extensions required to 24 support MT routing in an MPLS environment. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 20, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Signaling Extensions . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) . . . . 5 64 3.2. New Address Families: MT IP . . . . . . . . . . . . . . . 5 65 3.3. LDP FEC Elements with MT IP AF . . . . . . . . . . . . . . 6 66 3.4. IGP MT-ID Mapping and Translation . . . . . . . . . . . . 7 67 3.5. LDP MT Capability Advertisement . . . . . . . . . . . . . 7 68 3.5.1. Protocol Extension . . . . . . . . . . . . . . . . . . 7 69 3.5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . 9 70 3.6. LDP Sessions . . . . . . . . . . . . . . . . . . . . . . . 10 71 3.7. 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 . . . . . . . . . . . . . . . . . . . 13 83 7. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 14 84 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 10. Manageability Considerations . . . . . . . . . . . . . . . . . 16 87 10.1. Control of Function and Policy . . . . . . . . . . . . . . 16 88 10.2. Information and Data Models . . . . . . . . . . . . . . . 16 89 10.3. Liveness Detection and Monitoring . . . . . . . . . . . . 16 90 10.4. Verify Correct Operations . . . . . . . . . . . . . . . . 16 91 10.5. Requirements On Other Protocols . . . . . . . . . . . . . 16 92 10.6. Impact On Network Operations . . . . . . . . . . . . . . . 16 93 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 95 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 97 13.2. Informative References . . . . . . . . . . . . . . . . . . 19 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 Multi-Topology (MT) routing is supported in IP networks with the use 103 of MT aware IGPs. It would be advantageous for communications 104 Service Providers (CSP) to support Multiple Topologies (MT) within 105 MPLS environments (MPLS-MT). The benefits of MPLS-MT enabled 106 networks include: 108 o A CSP may want to assign varying Quality of Service (QoS) profiles 109 to traffic, based on a specific MT. 111 o Separate routing and MPLS domains may be used to isolated 112 multicast and IPv6 islands within the backbone network. 114 o Specific IP address space could be routed across an MT based on 115 security or operational isolation requirements. 117 o Low latency links could be assigned to an MT for delay sensitive 118 traffic. 120 o Management traffic could be separated from customer traffic using 121 multiple MTs, where the management traffic MT does not use links 122 that carries customer traffic. 124 This document describes the Label Distribution Protocol (LDP) 125 procedures and protocol extensions required to support MT routing in 126 an MPLS environment. 128 This document also updates RFC4379 by defining two new FEC types for 129 Label Switched Path (LSP) ping. 131 2. Terminology 133 This document uses MPLS terminology defined in [RFC5036]. Additional 134 terms are defined below: 136 o MT-ID: A 16 bit value used to represent the Multi-Topology ID. 138 o Default MT Topology: A topology that is built using the MT-ID 139 default value of 0. 141 o MT Topology: A topology that is built using the corresponding 142 MT-ID. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 3. Signaling Extensions 150 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) 152 LDP assigns and binds a label to a Forwarding Equivalence Class 153 (FEC), where a FEC is a list of one of more FEC elements. To setup 154 LSPs for unicast IP routing paths, LDP assigns local labels for IP 155 prefixes, and advertises these labels to its peers so that an LSP is 156 setup along the routing path. To setup MT LSPs for IP prefixes under 157 a given topology scope, the LDP "prefix-related" FEC element must be 158 extended to include topology information. This implies that MT-ID 159 becomes an attribute of Prefix-related FEC element, and all FEC-Label 160 binding operations are performed under the context of given topology 161 (MT-ID). 163 The following Subsection 3.2(New Address Families (AF): MT IP) 164 defines the extension required to bind "prefix-related" FEC to a 165 topology. 167 3.2. New Address Families: MT IP 169 The LDP base specification [RFC5036] (Section 4.1) defines the 170 "Prefix" FEC Element. The "Prefix" encoding is defined for a given 171 "Address Family" (AF), and has length (in bits) specified by the 172 "PreLen" field. 174 To extend IP address families for MT, two new Address Families named 175 "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes 176 within a topology scope. 178 The format of data associated with these new Address Families are 179 described below: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | IP Address | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Reserved | MT-ID | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Figure 1: MT IP Address Family Format 191 Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and 192 "MT IPv6" AF respectively, and the field "MT-ID" corresponds to 16- 193 bit Topology ID for given address. 195 Where 16-bit "MT-ID" field defines the Topology ID, and the 196 definition and usage of the rest fields in the FEC Elements are same 197 as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to 198 default topology and MUST be ignored on receipt so as to not cause 199 any conflict/confusion with existing non-MT procedures. 201 The defined FEC Elements with "MT IP" Address Family can be used in 202 any LDP message and procedures that currently specify and allow the 203 use of FEC Elements with IP/IPv6 Address Family. 205 3.3. LDP FEC Elements with MT IP AF 207 The following section specifies the format extensions of the existing 208 LDP FEC Elements. The "Address Family" of these FEC elements will be 209 set to "MT IP" or "MT IPv6". 211 The MT Prefix FEC element encoding is as follows: 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Prefix | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Reserved | MT-ID | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 2: MT Prefix FEC Element Format 225 Similarly, the MT mLDP FEC elements encoding is as follows, where the 226 mLDP FEC Type can be P2MP(6), MP2MP-up(7), and MP2MP-down(8): 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | mLDP FEC Type | Address Family (MT IP/MT IPv6)| Address Length| 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 ~ Root Node Address ~ 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Reserved | MT-ID | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Opaque Length | Opaque Value ... | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 239 ~ ~ 240 | | 241 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 3: MT mLDP FEC Element Format 247 The MT Typed Wildcard FEC element encoding is as follows: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 |Typed Wcard (5)| FEC Type | Len = 6 | AF = MT IP ..| 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |... or MT IPv6 | MT ID | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 4: MT Typed Wildcard FEC Element 259 3.4. IGP MT-ID Mapping and Translation 261 The non-reserved non-special IGP MT-ID values can be used and carried 262 in LDP without the need for translation. However, there is a need 263 for translating reserved or special IGP MT-ID values to corresponding 264 LDP MT-IDs. The corresponding special and reserved LDP MT-ID values 265 are requested In Section 9. (IANA Considerations). 267 3.5. LDP MT Capability Advertisement 269 3.5.1. Protocol Extension 271 We specify a new LDP capability, named "Multi-Topology (MT)", which 272 is defined in accordance with LDP Capability definition guidelines 273 [RFC5561]. The LDP "MT" capability can be advertised by an LDP 274 speaker to its peers either during the LDP session initialization or 275 after the LDP session is setup to announce LSR capability to support 276 MT for the given IP address family. An LDP speaker MUST NOT send an 277 MT AF unless the peer has said it can handle it. 279 The MT capability is specified using "Multi-Topology Capability" TLV. 280 The "Multi-Topology Capability" TLV format is in accordance with LDP 281 capability guidelines as defined in [RFC5561]. To be able to specify 282 IP address family, the capability specific data (i.e. "Capability 283 Data" field of Capability TLV) is populated using "Typed Wildcard FEC 284 Element" as defined in [RFC5918]. 286 The format of "Multi-Topology Capability" TLV is as follows: 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |U|F| Multi-Topology Cap.(IANA) | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 |S| Reserved | | 294 +-+-+-+-+-+-+-+-+ | 295 ~ Typed Wildcard FEC element(s) ~ 296 | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 5: Multi-Topology Capability TLV Format 301 Where: 303 o U- and F-bits: MUST be 1 and 0, respectively, as per Section 3. 304 (Signaling Extensions) of LDP Capabilities [RFC5561]. 306 o Multi-Topology Capability: Capability TLV type (IANA assigned) 308 o S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be 309 set to 0 or 1 in dynamic "Capability" message to advertise or 310 withdraw the capability respectively. 312 o Typed Wildcard FEC element(s): One or more elements specified as 313 the "Capability data". 315 o Length: length of Value field, starting from S bit, in octets. 317 o The encoding of Typed Wildcard FEC element, as defined in 318 [RFC5918], is defined in the section 3.3 (Typed Wildcard FEC 319 Element) of this document. 321 In the case that the LDP initialization message can not hold all the 322 MTs to be advertised, dynamic "Capability" message to advertise the 323 capability" must be supported. 325 3.5.2. Procedures 327 To announce its MT capability for an IP address family, LDP FEC type, 328 and Multi Topology, an LDP speaker an LDP speaker sends an "MT 329 Capability" including the exact Typed Wildcard FEC element with 330 corresponding "AddressFamily" field (i.e., set to "MT IP" for IPv4 331 and set to "MT IPv6" for IPv6 address family), corresponding "FEC 332 Type" field (i.e., set to "P2P", "P2MP", "MP2MP"), and corresponding 333 "MT-ID". To announce its MT capability for both IPv4 and IPv6 334 address family, or for multiple FEC types, or for multiple Multi 335 Topologies, an LDP speaker an LDP speaker sends "MT Capability" with 336 one or more MT Typed FEC elements in it. 338 o The capability for supporting multi-topology in LDP can be 339 advertised during LDP session initialization stage by including 340 the LDP MT capability TLV in LDP Initialization message. After an 341 LDP session is established, the MT capability can also be 342 advertised or withdrawn using Capability message (only if "Dynamic 343 Announcement" capability [RFC5561] has already been successfully 344 negotiated). 346 o If an LSR has not advertised MT capability, its peer MUST NOT send 347 label mapping messages that include MT identifier to this LSR. 349 o If an LSR receives a Label Mapping message with an MT parameter 350 from downstream LSR-D and its upstream LSR-U has not advertised MT 351 capability, an LSP for the MT will not be established. 353 o If an LSR is changed from non-MT capable to MT capable, it sets 354 the S bit in MT capability TLV and advertises via the Capability 355 message. The existing LSP is treated as LSP for default MT (ID 356 0). 358 o If an LSR is changed from LDP-MT capable to non-MT capable, it 359 initiates withdraw of all label mapping for existing LSPs of all 360 non-default MTs. It also cleanup all the LSPs of all non-default 361 MTs locally. Then it clears the S bit in MT capability TLV and 362 advertises via the Capability message. When an LSR knows the peer 363 node is changed from LDP-MT capable to non-MT capable, it cleanup 364 all the LSPs of all non-default MTs locally and initiate withdraw 365 of all label mapping for existing LSPs of all non-default MTs. 366 Both sides of the nodes send label release to its peer once they 367 receive the label release messages even both sides have already 368 cleaned up all the LSPs locally. 370 o If an LSR is changed from IGP-MT capable to non-MT capable, it may 371 wait until the routes update to withdraw FEC and release the label 372 mapping for existing LSPs of specific MT. 374 3.6. LDP Sessions 376 Since using different label spaces for different topologies would 377 imply significant changes to the data plane, a single global label 378 space is supported in this solution. There will be one session 379 supported for each pair of peer, even there are multiple topologies 380 supported between these two peers. 382 3.7. Reserved MT ID Values 384 Certain MT topologies are assigned to serve predetermined purposes. 386 In Section 9. (IANA Considerations), this document defines a new 387 IANA registry "LDP Multi-Topology ID Name Space" under IANA "LDP 388 Parameter" namespace to keep an LDP MT-ID reserved value. 390 If an LSR receives a FEC element with an "MT-ID" value that is 391 "Reserved" for future use (and not IANA allocated yet), the LSR must 392 abort the processing of the FEC element, and SHOULD send a 393 notification message with status code "Invalid MT-ID" to the sender. 395 4. MT Applicability on FEC-based features 397 4.1. Typed Wildcard FEC Element 399 [RFC5918] extends base LDP and defines Typed Wildcard FEC Element 400 framework. Typed Wildcard FEC element can be used in any LDP message 401 to specify a wildcard operation/action for given type of FEC. 403 The MT extensions defined in document do not require any extension to 404 procedures for Typed Wildcard FEC element, and these procedures apply 405 as-is to MT wildcarding. The MT extensions, though, allow use of "MT 406 IP" or "MT IPv6" in the Address Family field of the Typed Wildcard 407 FEC element in order to use wildcard operations in the context of a 408 given topology. The use of MT-scoped address family also allows us 409 to specify MT-ID in these operations. 411 The defined format in Section 3.3 (Typed Wildcard FEC Element) allows 412 an LSR to perform wildcard FEC operations under the scope of a 413 topology. If an LSR wishes to perform wildcard operation that 414 applies to all topologies, it can use a "Wildcard Topology" MT-ID. 415 For example, upon local configuration of topology "x", an LSR may 416 send a wildcard label withdraw request with MT-ID "x" to withdraw all 417 its labels from the peer that advertised under the scope of topology 418 "x". Additionally, upon a global configuration change, an LSR may 419 send a wildcard label withdraw with the MT-ID set to "Wildcard 420 Topology" to withdraw all its labels under all topologies from the 421 peer. 423 4.2. End-of-LIB 425 [RFC5919] specifies extensions and procedures for an LDP speaker to 426 signal its convergence for a given FEC type towards a peer. The 427 procedures defined in [RFC5919] applies as-is to an MT FEC element. 428 This allows an LDP speaker to signal its IP convergence using Typed 429 Wildcard FEC element, and its MT IP convergence per topology using a 430 MT Typed Wildcard FEC element. 432 4.3. LSP Ping 434 [RFC4379] defines procedures to detect data-plane failures in MPLS 435 LSPs via LSP ping. That specification defines a "Target FEC Stack" 436 TLV that describes the FEC stack being tested. This TLV is sent in 437 an MPLS echo request message towards LSPs egress LSR, and is 438 forwarded along the same data path as other packets belonging to the 439 FEC. 441 "Target FEC Stack" TLV contains one or more sub-TLVs pertaining to 442 different FEC types. Section 3.2 of [RFC4379] defines Sub-Types and 443 format for the FEC. To support LSP ping for MT LDP LSPs, this 444 document defines following extensions to [RFC4379]. 446 4.3.1. New FEC Sub-Types 448 We define two new FEC types for LSP ping: 450 o MT LDP IPv4 FEC 452 o MT LDP IPv6 FEC 454 We also define following new sub-types for sub-TLVs to specify these 455 FECs in the "Target FEC Stack" TLV of [RFC4379]: 457 Sub-Type Length Value Field 458 -------- ------ ----------------- 459 TBA5 8 MT LDP IPv4 prefix 460 TBA6 20 MT LDP IPv6 prefix 462 Figure 6: new sub-types for sub-TLVs 464 The rules and procedures of using these sub-TLVs in an MPLS echo 465 request message are same as defined for LDP IPv4/IPv6 FEC sub-TLV 466 types in [RFC4379]. 468 4.3.2. MT LDP IPv4 FEC Sub-TLV 470 The format of "MT LDP IPv4 FEC" sub-TLV to be used in a "Target FEC 471 Stack" [RFC4379] is: 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Type = TBA5(MT LDP IPv4 FEC) | Length = 8 | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | IPv4 prefix | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Prefix Length | MBZ | MT-ID | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Figure 7: MT LDP IPv4 FEC sub-TLV 485 The format of this sub-TLV is similar to LDP IPv4 FEC sub-TLV as 486 defined in [RFC4379]. In addition to "IPv4 prefix" and "Prefix 487 Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology 488 ID). The Length for this sub-TLV is 5. 490 4.3.3. MT LDP IPv6 FEC Sub-TLV 492 The format of "MT LDP IPv6 FEC" sub-TLV to be used in a "Target FEC 493 Stack" [RFC4379] is: 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Type = TBA6(MT LDP IPv6 FEC) | Length = 20 | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | | 501 | IPv6 prefix | 502 | | 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Prefix Length | MBZ | MT-ID | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 8: MT LDP IPv6 FEC sub-TLV 510 The format of this sub-TLV is similar to LDP IPv6 FEC sub-TLV as 511 defined in [RFC4379]. In addition to "IPv6 prefix" and "Prefix 512 Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology 513 ID). The Length for this sub-TLV is 17. 515 4.3.4. Operation Considerations 517 To detect data plane failures using LSP Ping for a specific topology, 518 the router will initiate an LSP Ping request with the target FEC 519 stack TLV containing LDP MT IP Prefix Sub-TLV in the Echo Request 520 packet. The Echo Request packet is sent with the label bound to the 521 IP Prefix in the topology. Once the echo request packet reaches the 522 target router, it will process the packet and perform checks for the 523 LDP MT IP Prefix sub-TLV present in the Target FEC Stack as described 524 in [RFC4379] and respond according to [RFC4379] processing rules. 525 For the case that the LSP ping with return path not specified , the 526 reply packet must go through the default topology instead of the 527 topology where the Echo Request goes through. 529 5. Error Handling 531 The extensions defined in this document utilize the existing LDP 532 error handling defined in [RFC5036]. If an LSR receives an error 533 notification from a peer for a session, it terminates the LDP session 534 by closing the TCP transport connection for the session and 535 discarding all MT-ID label mappings learned via the session. 537 5.1. MT Error Notification for Invalid Topology ID 539 If an LSR has advertised an MT Capability TLV using the 540 Initialization message or Capability message, which includes Typed 541 Wildcard FEC elements with specific MT-IDs, and it receives an MT 542 message with a MT-ID which is not included in the supported list, it 543 should response this "Invalid Topology ID" status code. 545 6. Backwards Compatibility 547 The MPLS-MT solution is backwards compatible with existing LDP 548 enhancements defined in [RFC5036], including message authenticity, 549 integrity of message, and topology loop detection. 551 The legacy node which does not support MT should not receive any MT 552 related LDP messages. In case the bad things does happen, according 553 to [RFC5036], processing of such message should be aborted. 555 7. MPLS Forwarding in MT 557 Although forwarding is out of the scope of this draft, we include 558 some forwarding consideration for informational purpose here. 560 The specified signaling mechanisms allow all the topologies to share 561 the platform-specific label space; this is the feature that allows 562 the existing data plane techniques to be used; and there is no way 563 for the data plane to associate a received packet with any one 564 topology, meaning that topology-specific label spaces cannot be used. 566 8. Security Consideration 568 No specific security issues with the defined solutions are known. 569 The defined extensions in this document do not introduce any new 570 security considerations beyond that already apply to the base LDP 571 specification [RFC5036] and [RFC5920]. 573 9. IANA Considerations 575 The document introduces following new protocol elements that require 576 IANA consideration and assignments: 578 o New LDP Capability TLV: "Multi-Topology Capability" TLV (requested 579 code point: TBA1 from LDP registry "TLV Type Name Space"). 581 o New Status Code: "Multi-Topology Capability not supported" 582 (requested code point: TBA2 from LDP registry "Status Code Name 583 Space"). This status code is only used by node that supports MT 584 when decided to withdraw this capability. 586 o New Status Code: "Invalid Topology ID" (requested code point: TBA3 587 from LDP registry "Status Code Name Space"). 589 Registry: 590 Range/Value Description 591 -------------- ------------------------------ 592 TBA1 Multi-Topology Capability 593 TBA2 Multi-Topology Capability not supported 594 TBA3 Invalid Topology ID 596 Figure 9: New Code Points for LDP Multi Topology Extensions 598 o New address families under IANA registry "Address Family Numbers": 600 - MT IP: Multi-Topology IP version 4 (requested codepoint: 26) 601 - MT IPv6: Multi-Topology IP version 6 (requested codepoint: 27) 603 Figure 10: Address Family Numbers 605 o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP 606 Parameter" namespace. The allocation policies for this registry 607 are: 609 Range/Value Purpose Reference 610 ----------- ------------------------------------- --------- 611 0 Default/standard topology 612 1 IPv4 in-band management 613 2 IPv6 routing topology 614 3 IPv4 multicast topology 615 4 IPv6 multicast topology 616 5 IPv6 in-band management 617 6-3995 Reserved for future IGP topologies 618 3996-4095 Reserved for IGP experimental topologies 620 4096-4127 Reserved for LDP topologies 621 4128-65534 Reserved for LDP experimental topologies 623 65535 Wildcard Topology 625 Figure 11: 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 TBA4 MT LDP IPv4 prefix 635 TBA5 MT LDP IPv6 prefix 637 Figure 12: New Sub-TLV Types for LSP ping 639 IANA should allocate the next available numbers for these TBAs. 641 10. Manageability Considerations 643 10.1. Control of Function and Policy 645 There are capabilities that should be configurable to enable good 646 manageability. One such example is to allow enable or disable LDP 647 Multi-Topology capability. It is assumed that the mapping of the LDP 648 MT ID and IGP MT ID is manually configured on every router by 649 default. If an automatic mapping between IGP MT IDs and LDP MT IDs 650 is needed, there must be explicit configuration to do so. 652 10.2. Information and Data Models 654 draft-li-mpls-ldp-mt-mib.txt describes the PCEP MIB, there is no new 655 MIB Objects for this document. 657 10.3. Liveness Detection and Monitoring 659 Mechanisms defined in this document do not imply any new liveness 660 detection and monitoring requirements. 662 10.4. Verify Correct Operations 664 If an operator is trying to debug LDP MT enabled network and wants to 665 make the association between the LDP label advertisement and the IGP 666 routing advertisement, then the user must understand the mapping 667 mechanism to convert the IGP MT ID to the LDP MT ID. This type of 668 mapping mechanisms is out of the scope of this document. 670 10.5. Requirements On Other Protocols 672 If the LDP MT ID has an implicit dependency on IGP MT ID, then the 673 corresponding IGP MT feature/s need to be supported. 675 10.6. Impact On Network Operations 677 Mechanisms defined in this document do not have any impact on network 678 operations. 680 11. Contributors 682 Ning So 683 Tata Communications 684 2613 Fairbourne Cir. 685 Plano, TX 75082 686 USA 688 Email: ning.so@tatacommunications.com 690 Raveendra Torvi 691 Juniper Networks 692 10, Technoogy Park Drive 693 Westford, MA 01886-3140 694 US 696 Email: rtorvi@juniper.net 698 Huaimo Chen 699 Huawei Technology 700 125 Nagog Technology Park 701 Acton, MA 01719 702 US 704 Email: huaimochen@huawei.com 706 Emily Chen 707 2717 Seville Blvd, Apt 1205, 708 Clearwater, FL 33764 709 US 711 Email: emily.chen220@gmail.com 713 Chen Li 714 China Mobile 715 53A, Xibianmennei Ave. 716 Xunwu District, Beijing 01719 717 China 719 Email: lichenyj@chinamobile.com 721 Lu Huang 722 China Mobile 723 53A, Xibianmennei Ave. 724 Xunwu District, Beijing 01719 725 China 727 Email: huanglu@chinamobile.com 729 Daniel King 730 Old Dog Consulting 731 Email: E-mail: daniel@olddog.co.uk 733 Zhenbin Li 734 Huawei Technology 735 2330 Central Expressway 736 Santa Clara, CA 95050 737 US 739 Email: zhenbin.li@huawei.com 741 12. Acknowledgement 743 The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin, 744 Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun 745 Chai,pranjal Dutta, George Swallow, Curtis Villamizar, Adrian Farrel, 746 Alia Atlas and Loa Anderson for their valuable comments on this 747 draft. 749 13. References 751 13.1. Normative References 753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 754 Requirement Levels", BCP 14, RFC 2119, March 1997. 756 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 757 Label Switched (MPLS) Data Plane Failures", RFC 4379, 758 February 2006. 760 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 761 Specification", RFC 5036, October 2007. 763 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 764 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 766 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 767 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 768 (FEC)", RFC 5918, August 2010. 770 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 771 "Signaling LDP Label Advertisement Completion", RFC 5919, 772 August 2010. 774 13.2. Informative References 776 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 777 Networks", RFC 5920, July 2010. 779 Authors' Addresses 781 Quintin Zhao 782 Huawei Technology 783 125 Nagog Technology Park 784 Acton, MA 01719 785 US 787 Email: quintin.zhao@huawei.com 789 Luyuan Fang 790 Cisco Systems 791 300 Beaver Brook Road 792 Boxborough, MA 01719 793 US 795 Email: lufang@cisco.com 797 Chao Zhou 798 Cisco Systems 799 300 Beaver Brook Road 800 Boxborough, MA 01719 801 US 803 Email: czhou@cisco.com 805 Lianyuan Li 806 China Mobile 807 53A, Xibianmennei Ave. 808 Xunwu District, Beijing 01719 809 China 811 Email: lilianyuan@chinamobile.com 812 Kamran Raza 813 Cisco Systems 814 2000 Innovation Drive 815 Kanata, ON K2K-3E8, MA 816 Canada 818 Email: E-mail: skraza@cisco.com