idnits 2.17.1 draft-ietf-mpls-ldp-multi-topology-12.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 (April 23, 2014) is 3649 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 K. Raza 5 Expires: October 31, 2014 C. Zhou 6 Cisco Systems 7 L. Fang 8 Microsoft 9 L. Li 10 China Mobile 11 D. King 12 Old Dog Consulting 13 April 23, 2014 15 LDP Extensions for Multi Topology 16 draft-ietf-mpls-ldp-multi-topology-12.txt 18 Abstract 20 Multi-Topology (MT) routing is supported in IP networks with the use 21 of MT aware IGPs. In order to provide MT routing within 22 Multiprotocol Label Switching (MPLS) Label Distribution Protocol 23 (LDP) networks new extensions are required. 25 This document describes the LDP protocol extensions required to 26 support MT routing in an MPLS environment. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 31, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Signaling Extensions . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) . . . . 5 66 3.2. New Address Families: MT IP . . . . . . . . . . . . . . . 5 67 3.3. LDP FEC Elements with MT IP AF . . . . . . . . . . . . . . 6 68 3.4. IGP MT-ID Mapping and Translation . . . . . . . . . . . . 7 69 3.5. LDP MT Capability Advertisement . . . . . . . . . . . . . 7 70 3.5.1. Protocol Extension . . . . . . . . . . . . . . . . . . 7 71 3.5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . 8 72 3.6. Label Spaces . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.7. Reserved MT ID Values . . . . . . . . . . . . . . . . . . 10 74 4. MT Applicability on FEC-based features . . . . . . . . . . . . 10 75 4.1. Typed Wildcard FEC Element . . . . . . . . . . . . . . . . 10 76 4.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.3. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.3.1. New FEC Sub-Types . . . . . . . . . . . . . . . . . . 11 79 4.3.2. MT LDP IPv4 FEC Sub-TLV . . . . . . . . . . . . . . . 12 80 4.3.3. MT LDP IPv6 FEC Sub-TLV . . . . . . . . . . . . . . . 12 81 4.3.4. Operation Considerations . . . . . . . . . . . . . . . 13 82 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 13 83 5.1. MT Error Notification for Invalid Topology ID . . . . . . 13 84 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 13 85 7. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 14 86 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 10. Manageability Considerations . . . . . . . . . . . . . . . . . 16 89 10.1. Control of Function and Policy . . . . . . . . . . . . . . 16 90 10.2. Information and Data Models . . . . . . . . . . . . . . . 16 91 10.3. Liveness Detection and Monitoring . . . . . . . . . . . . 16 92 10.4. Verify Correct Operations . . . . . . . . . . . . . . . . 16 93 10.5. Requirements On Other Protocols . . . . . . . . . . . . . 16 94 10.6. Impact On Network Operations . . . . . . . . . . . . . . . 17 95 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 99 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 102 1. Introduction 104 Multi-Topology (MT) routing is supported in IP networks with the use 105 of MT aware IGPs. It would be advantageous for Communications 106 Service Providers (CSP) to support Multiple Topologies (MT) within 107 MPLS environments (MPLS-MT). The benefits of MPLS-MT 108 technology provide features for various network scenarios, including: 110 o A CSP may want to assign varying Quality of Service (QoS) profiles 111 to different traffic classes. based on a specific topology in an 112 MT routing network; 114 o Separate routing and MPLS domains may be used to isolate multicast 115 and IPv6 islands within the backbone network; 117 o Specific IP address space could be routed across an MT based on 118 security or operational isolation requirements; 120 o Low latency links could be assigned to an MT for delay sensitive 121 traffic; 123 o Management traffic may be divided from customer traffic using 124 different MTs utilizing separate links, thus ensuring that 125 management traffic is separated from customer traffic. 127 This document describes the Label Distribution Protocol (LDP) 128 procedures and protocol extensions required to support MT routing in 129 an MPLS environment. 131 This document also updates RFC4379 by defining two new Forwarding 132 Equivalence Class (FEC) types for Label Switched Path (LSP) ping. 134 2. Terminology 136 This document uses MPLS terminology defined in [RFC5036]. Additional 137 terms are defined below: 139 o MT-ID: A 16 bit value used to represent the Multi-Topology ID. 141 o Default MT Topology: A topology that is built using the MT-ID 142 default value of 0. 144 o MT Topology: A topology that is built using the corresponding 145 MT-ID. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 3. Signaling Extensions 153 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) 155 LDP assigns and binds a label to a FEC, where a FEC is a list of one 156 or more FEC elements. To setup LSPs for unicast IP routing paths, 157 LDP assigns local labels for IP prefixes, and advertises these 158 labels to its peers so that an LSP is setup along the routing 159 path. To setup MT LSPs for IP prefixes under a given topology 160 scope, the LDP "prefix-related" FEC element must be extended to 161 include topology information. This implies that MT-ID becomes an 162 attribute of Prefix-related FEC element, and all FEC-Label binding 163 operations are performed under the context of given topology 164 (MT-ID). 166 The following subsection 3.2 (New Address Families (AF): MT IP) 167 defines the extension required to bind "prefix-related" FEC to a 168 topology. 170 3.2. New Address Families: MT IP 172 The LDP base specification [RFC5036] (Section 2.1) defines the 173 "Prefix" FEC Element. The "Prefix" encoding is defined for a given 174 "Address Family" (AF), and has length (in bits) specified by the 175 "PreLen" field. 177 To extend IP address families for MT, two new Address Families named 178 "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes 179 within a topology scope. 181 The format of data associated with these new Address Families is 182 described below: 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | IPv4 Address | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Reserved | MT-ID | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 1: MT IP Address Family Format 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | IPv6 Address | 198 | | 199 | | 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Reserved | MT-ID | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2: MT IPv6 Address Family Format 207 Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and 208 "MT IPv6" AF respectively, and the field "MT-ID" corresponds to 16- 209 bit Topology ID for given address. 211 The definition and usage for the remaining fields in the FEC Elements 212 are as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to 213 default topology and MUST be ignored on receipt so as to not cause 214 any conflict/confusion with existing non-MT procedures. 216 The defined FEC Elements with "MT IP" Address Family can be used in 217 any LDP message and procedures that currently specify and allow the 218 use of FEC Elements with IP/IPv6 Address Family. 220 3.3. LDP FEC Elements with MT IP AF 222 The following section specifies the format extensions of the existing 223 LDP FEC Elements to support MT. The "Address Family" of these FEC 224 elements will be set to "MT IP" or "MT IPv6". 226 The MT Prefix FEC element encoding is as follows: 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 | Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Prefix | 234 ~ ~ 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Reserved | MT-ID | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Figure 3: MT Prefix FEC Element Format 241 The MT Typed Wildcard FEC element encoding is as follows: 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 |Typed Wcard (5)| FEC Type | Len = 6 | AF = MT IP ..| 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |... or MT IPv6 | MT ID | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Figure 4: MT Typed Wildcard FEC Element 253 The above format can be used for any LDP FEC Element that allows use 254 of IP/IPv6 address family. In the scope of this document, the 255 allowed "FEC Type" in a MT Typed Wildcard FEC Element is "Prefix" FEC 256 element. 258 3.4. IGP MT-ID Mapping and Translation 260 The non-reserved non-special IGP MT-ID values can be used and carried 261 in LDP without the need for translation. However, there is a need 262 for translating reserved or special IGP MT-ID values to corresponding 263 LDP MT-IDs. The assigned, unassigned and special LDP MT-ID values 264 are requested In Section 9. (IANA Considerations). 266 How future LDP MT-ID values are allocated are out of of scope of this 267 document. Instead a new Internet-Draft will be created to document 268 the allocation policy and process for requesting new MT-ID values. 270 3.5. LDP MT Capability Advertisement 272 3.5.1. Protocol Extension 274 We specify a new LDP capability, named "Multi-Topology (MT)", which 275 is defined in accordance with LDP Capability definition guidelines 276 [RFC5561]. The LDP "MT" capability can be advertised by an LDP 277 speaker to its peers either during the LDP session initialization or 278 after the LDP session is setup to announce LSR capability to support 279 MT for the given IP address family. An LDP speaker MUST NOT send 280 messages containing MT FEC elements unless the peer has said it can 281 handle it. 283 The MT capability is specified using "Multi-Topology Capability" TLV. 284 The "Multi-Topology Capability" TLV format is in accordance with LDP 285 capability guidelines as defined in [RFC5561]. To be able to specify 286 IP address family, the capability specific data (i.e. "Capability 287 Data" field of Capability TLV) is populated using "Typed Wildcard FEC 288 Element" as defined in [RFC5918]. 290 The format of "Multi-Topology Capability" TLV is as follows: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |U|F| Multi-Topology Cap.(IANA) | Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 |S| Reserved | | 298 +-+-+-+-+-+-+-+-+ | 299 ~ Typed Wildcard FEC element(s) ~ 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 5: Multi-Topology Capability TLV Format 305 Where: 307 o U-bit: MUST be 1 so that the TLV will be silently ignored by a 308 recipient if it is unkown according to the rules of [RFC5036]. 310 o F-bit: MUST be 0 as per Section 3 (Specifying Capabilities in LDP 311 Messages) of LDP Capabilities [RFC5561]. 313 o Multi-Topology Capability: Capability TLV type (IANA assigned) 315 o S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be 316 set to 0 or 1 in dynamic "Capability" message to advertise or 317 withdraw the capability respectively. 319 o Typed Wildcard FEC element(s): One or more elements specified as 320 the "Capability data". 322 o Length: length of Value field, starting from S bit, in octets. 324 o The encoding of Typed Wildcard FEC element, as defined in 325 [RFC5918], is defined in the section 3.3 (Typed Wildcard FEC 326 Element) of this document. The MT-ID field of MT Typed Wildcard 327 FEC Element MUST be set to "Wildcard Topology" when it is 328 specified in MT Capability TLV. 330 3.5.2. Procedures 332 To announce its MT capability for an IP address family, LDP FEC type, 333 and Multi Topology, an LDP speaker sends an "MT Capability" including 334 the exact Typed Wildcard FEC element with corresponding 335 "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT 336 IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., 337 set to "Prefix"), and corresponding "MT-ID". To announce its MT 338 capability for both IPv4 and IPv6 address family, or for multiple FEC 339 types, or for multiple Multi Topologies, an LDP speaker sends "MT 340 Capability" with one or more MT Typed FEC elements in it. 342 o The capability for supporting multi-topology in LDP can be 343 advertised during LDP session initialization stage by including 344 the LDP MT capability TLV in LDP Initialization message. After an 345 LDP session is established, the MT capability can also be 346 advertised or withdrawn using Capability message (only if "Dynamic 347 Announcement" capability [RFC5561] has already been successfully 348 negotiated). 350 o If an LSR has not advertised MT capability, its peer MUST NOT send 351 any LDP messages with FEC elements that include MT identifier to 352 this LSR. 354 o If an LSR is changed from non-MT capable to MT capable, it sets 355 the S bit in MT capability TLV and advertises via the Capability 356 message (if it supports Dynamic Announcement Capability). The 357 existing LSP is treated as LSP for default MT (ID 0). 359 o If an LSR is changed from LDP-MT capable to non-MT capable, it 360 initiates withdraw of all label mapping for existing LSPs of all 361 non-default MTs. It also cleans up all the LSPs of all non- 362 default MTs locally. Then it clears the S bit in MT capability 363 TLV and advertises via the Capability message (if it supports 364 Dynamic Announcement Capability). When an LSR knows the peer node 365 is changed from LDP-MT capable to non-MT capable, it cleanup all 366 the LSPs of all non-default MTs locally and initiate withdraw of 367 all label mapping for existing LSPs of all non-default MTs. Both 368 sides of the nodes send label release to its peer once they 369 receive the label release messages even both sides have already 370 cleaned up all the LSPs locally. 372 o If an LSR does not support "Dynamic Announcement Capability", it 373 MUST reset session with its peer whenever LSR changes its local 374 capability with regards to supporting LDP MT. 376 o If an LSR is changed from IGP-MT capable to non-MT capable, it may 377 wait until the routes update to withdraw FEC and release the label 378 mapping for existing LSPs of specific MT. 380 3.6. Label Spaces 382 The use of multiple topologies for LDP does not require different 383 label spaces for each topology. An LSR can use the same label space 384 for all MT FECs as for the default topology. 386 Similarly, signaling for different topologies can and should be done 387 within a single LDP session. 389 3.7. Reserved MT ID Values 391 Certain MT topologies are assigned to serve predetermined purposes. 393 In Section 9. (IANA Considerations), this document defines a new 394 IANA registry "LDP Multi-Topology ID Name Space" under IANA "LDP 395 Parameter" namespace to keep an LDP MT-ID reserved value. 397 If an LSR receives a FEC element with an "MT-ID" value that is 398 "Reserved" for future use (and not IANA allocated yet), the LSR MUST 399 abort the processing of the FEC element, and SHOULD send a 400 notification message with status code "Invalid Topology ID" to the 401 sender. 403 4. MT Applicability on FEC-based features 405 4.1. Typed Wildcard FEC Element 407 [RFC5918] extends base LDP and defines Typed Wildcard FEC Element 408 framework. Typed Wildcard FEC element can be used in any LDP message 409 to specify a wildcard operation/action for given type of FEC. 411 The MT extensions defined in document do not require any extension to 412 procedures for Typed Wildcard FEC element, and these procedures apply 413 as-is to MT wildcarding. The MT extensions, though, allow use of "MT 414 IP" or "MT IPv6" in the Address Family field of the Typed Wildcard 415 FEC element in order to use wildcard operations in the context of a 416 given topology. The use of MT-scoped address family also allows us 417 to specify MT-ID in these operations. 419 The defined format in Section 3.3 (Typed Wildcard FEC Element) allows 420 an LSR to perform wildcard FEC operations under the scope of a 421 topology. If an LSR wishes to perform wildcard operation that 422 applies to all topologies, it can use a "Wildcard Topology" MT-ID. 423 For example, upon local de-configuration of a topology "x", an LSR 424 may send a typed wildcard label withdraw message with MT-ID "x" to 425 withdraw all its labels from the peer that advertised under the scope 426 of topology "x". Additionally, upon a global configuration change, 427 an LSR may send a typed wildcard label withdraw message with the 428 MT-ID set to "Wildcard Topology" to withdraw all its labels under all 429 topologies from the peer. 431 4.2. End-of-LIB 433 [RFC5919] specifies extensions and procedures for an LDP speaker to 434 signal its convergence for a given FEC type towards a peer. The 435 procedures defined in [RFC5919] applies as-is to an MT FEC element. 436 This allows an LDP speaker to signal its IP convergence using Typed 437 Wildcard FEC element, and its MT IP convergence per topology using a 438 MT Typed Wildcard FEC element. 440 4.3. LSP Ping 442 [RFC4379] defines procedures to detect data-plane failures in MPLS 443 LSPs via LSP ping. That specification defines a "Target FEC Stack" 444 TLV that describes the FEC stack being tested. This TLV is sent in 445 an MPLS echo request message towards LSPs egress LSR, and is 446 forwarded along the same data path as other packets belonging to the 447 FEC. 449 "Target FEC Stack" TLV contains one or more sub-TLVs pertaining to 450 different FEC types. Section 3.2 of [RFC4379] defines Sub-Types and 451 format for the FEC. To support LSP ping for MT LDP LSPs, this 452 document defines following extensions to [RFC4379]. 454 4.3.1. New FEC Sub-Types 456 We define two new FEC types for LSP ping: 458 o MT LDP IPv4 FEC 460 o MT LDP IPv6 FEC 462 We also define following new sub-types for sub-TLVs to specify these 463 FECs in the "Target FEC Stack" TLV of [RFC4379]: 465 Sub-Type Length Value Field 466 -------- ------ ----------------- 467 TBA1 8 MT LDP IPv4 prefix 468 TBA2 20 MT LDP IPv6 prefix 470 Figure 6: new sub-types for sub-TLVs 472 The rules and procedures of using these sub-TLVs in an MPLS echo 473 request message are same as defined for LDP IPv4/IPv6 FEC sub-TLV 474 types in [RFC4379]. 476 4.3.2. MT LDP IPv4 FEC Sub-TLV 478 The format of "MT LDP IPv4 FEC" sub-TLV to be used in a "Target FEC 479 Stack" [RFC4379] is: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type = TBA5(MT LDP IPv4 FEC) | Length = 8 | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | IPv4 prefix | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Prefix Length | MBZ | MT-ID | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Figure 7: MT LDP IPv4 FEC sub-TLV 493 The format of this sub-TLV is similar to LDP IPv4 FEC sub-TLV as 494 defined in [RFC4379]. In addition to "IPv4 prefix" and "Prefix 495 Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology 496 ID). The Length for this sub-TLV is 5. 498 4.3.3. MT LDP IPv6 FEC Sub-TLV 500 The format of "MT LDP IPv6 FEC" sub-TLV to be used in a "Target FEC 501 Stack" [RFC4379] is: 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type = TBA6(MT LDP IPv6 FEC) | Length = 20 | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | | 509 | IPv6 prefix | 510 | | 511 | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Prefix Length | MBZ | MT-ID | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 8: MT LDP IPv6 FEC sub-TLV 518 The format of this sub-TLV is similar to LDP IPv6 FEC sub-TLV as 519 defined in [RFC4379]. In addition to "IPv6 prefix" and "Prefix 520 Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology 521 ID). The Length for this sub-TLV is 17. 523 4.3.4. Operation Considerations 525 To detect data plane failures using LSP Ping for a specific topology, 526 the router will initiate an LSP Ping request with the target FEC 527 stack TLV containing LDP MT IP Prefix Sub-TLV in the Echo Request 528 packet. The Echo Request packet is sent with the label bound to the 529 IP Prefix in the topology. Once the echo request packet reaches the 530 target router, it will process the packet and perform checks for the 531 LDP MT IP Prefix sub-TLV present in the Target FEC Stack as described 532 in [RFC4379] and respond according to [RFC4379] processing rules. 533 For the case that the LSP ping with return path is not specified, the 534 reply packet must go through the default topology instead of the 535 topology where the Echo Request goes through. 537 It should be noted that existing MIB module for an MPLS LSR [RFC3813] 538 and MPLS LDP managed objects[RFC3815] do not provide the necessary 539 information to support the extensions in this document. For 540 example, the absence of the MT-ID as an index into the MIB modules 541 means that there is no way to disambiguate different topology 542 instances. 544 5. Error Handling 546 The extensions defined in this document utilize the existing LDP 547 error handling defined in [RFC5036]. If an LSR receives an error 548 notification from a peer for a session, it terminates the LDP session 549 by closing the TCP transport connection for the session and 550 discarding all multi-topology label mappings learned via the session. 552 5.1. MT Error Notification for Invalid Topology ID 554 An LSR should respond with an "Invalid Topology ID" status code in 555 LDP Notification message when it receives an LDP message with a FEC 556 element specifying an MT-ID which is not locally known or not 557 supported. The LSR MUST also discard the entire message before 558 sending the Notification. 560 6. Backwards Compatibility 562 The MPLS-MT solution is backwards compatible with existing LDP 563 enhancements defined in [RFC5036], including message authenticity, 564 integrity of message, and topology loop detection. 566 The legacy node which does not support MT should not receive any MT 567 related LDP messages. In case the bad things happen, according to 568 [RFC5036], processing of such messages should be aborted. 570 7. MPLS Forwarding in MT 572 Although forwarding is out of the scope of this draft, we include 573 some forwarding consideration for informational purpose here. 575 The specified signaling mechanisms allow all the topologies to share 576 the platform-specific label space, This feature allows the existing 577 data plane techniques to be used. Also, there is no way for the data 578 plane to associate a received packet with any one topology, meaning 579 that topology-specific label spaces cannot be used. 581 8. Security Consideration 583 The use of MT over existing MPLS solutions does not offer any 584 specific security benefit. 586 General LDP Communication security threats and how these may be 587 mitigated are described in [RFC5036], these threats include: 589 o Spoofing 591 o Privacy 593 o Denial of Service 595 For further discussion regarding possible LDP communication threats 596 and mitigation techniques see [RFC5920]. 598 9. IANA Considerations 600 The document introduces following new protocol elements that require 601 IANA consideration and assignments: 603 o New LDP Capability TLV: "Multi-Topology Capability" TLV (requested 604 code point: TBA1 from LDP registry "TLV Type Name Space". We 605 suggest to have a value in the range 0x050C-0x05FF). 607 o New Status Code: "Invalid Topology ID" (requested code point: TBA2 608 from LDP registry "Status Code Name Space"). 610 Registry: 611 Range/Value Description 612 -------------- ------------------------------ 613 TBA2 Invalid Topology ID 614 This new Status Code should be added to 615 the range 0x00000000-0x1FFFFFFF (IETF Consensus). 617 Figure 9: New Code Points for LDP Multi Topology Extensions 619 o New address families under IANA registry "Address Family Numbers": 621 - MT IP: Multi-Topology IP version 4 (requested codepoint: 26) 622 - MT IPv6: Multi-Topology IP version 6 (requested codepoint: 27) 624 Figure 10: Address Family Numbers 626 o New registry "MPLS Multi-Topology Identifiers". 628 This registry should be a sub-registry of "Multiprotocol Label 629 Switching Architecture (MPLS)" 631 The allocation policies for this registry are: 633 Range/Value Purpose Reference 634 ----------- ------------------------------------- ---------- 635 0 Default/standard topology [This.I-D] 636 1 IPv4 in-band management [This.I-D] 637 2 IPv6 routing topology [This.I-D] 638 3 IPv4 multicast topology [This.I-D] 639 4 IPv6 multicast topology [This.I-D] 640 5 IPv6 in-band management [This.I-D] 641 6-3995 Unassigned for future IGP topologies [This.I-D] 642 Assigned by Standards Action [This.I-D] 643 3996-4095 Experimental [This.I-D] 644 4096-65534 Unassigned for MPLS topologies [This.I-D] 645 Assigned by Standards Action 646 65535 Wildcard Topology [This.I-D] 648 Figure 11: MPLS Multi-Topology Identifier registry 650 o New Sub-TLV Types for LSP ping: Following new sub-type values 651 under TLV type 1 (Target FEC Stack) from "Multi-Protocol Label 652 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 653 registry, and "TLVs and sub-TLVs" sub-registry. 655 Sub-Type Value Field 656 -------- ----------- 657 TBA3 MT LDP IPv4 prefix 658 TBA4 MT LDP IPv6 prefix 659 Figure 12: New Sub-TLV Types for LSP ping 661 IANA should allocate the next available numbers for these TBAs. 663 As highlighted at the end of Section 3.4 (IGP MT-ID Mapping and 664 Translation), a new Internet-Draft will be created to document the 665 policy and process for allocating new MT-ID values. 667 10. Manageability Considerations 669 10.1. Control of Function and Policy 671 There are capabilities that should be configurable to enable good 672 manageability. One such example is to allow enable or disable LDP 673 Multi-Topology capability. It is assumed that the mapping of the LDP 674 MT ID and IGP MT ID is manually configured on every router by 675 default. If an automatic mapping between IGP MT IDs and LDP MT IDs 676 is needed, there must be explicit configuration to do so. 678 10.2. Information and Data Models 680 Any extensions that may be required for existing MIBs are beyond the 681 scope of this document. 683 10.3. Liveness Detection and Monitoring 685 Mechanisms defined in this document do not imply any new liveness 686 detection and monitoring requirements. 688 10.4. Verify Correct Operations 690 In order to debug an LDP MT enabled network it may be necessary to 691 associate between the LDP label advertisement and the IGP routing 692 advertisement, in this case the user MUST understand the mapping 693 mechanism to convert the IGP MT ID to the LDP MT ID. The method and 694 type of mapping mechanism is out of the scope of this document. 696 10.5. Requirements On Other Protocols 698 If the LDP MT ID has an implicit dependency on IGP MT ID, then the 699 corresponding IGP MT features will need to be supported. 701 10.6. Impact On Network Operations 703 Mechanisms defined in this document do not have any impact on network 704 operations. 706 11. Contributors 707 Ning So 708 Tata Communications 709 2613 Fairbourne Cir. 710 Plano, TX 75082 711 USA 713 Email: ning.so@tatacommunications.com 715 Raveendra Torvi 716 Juniper Networks 717 10, Technoogy Park Drive 718 Westford, MA 01886-3140 719 US 721 Email: rtorvi@juniper.net 723 Huaimo Chen 724 Huawei Technology 725 125 Nagog Technology Park 726 Acton, MA 01719 727 US 729 Emily Chen 730 2717 Seville Blvd, Apt 1205, 731 Clearwater, FL 33764 732 US 734 Email: emily.chen220@gmail.com 736 Chen Li 737 China Mobile 738 53A, Xibianmennei Ave. 739 Xunwu District, Beijing 01719 740 China 742 Email: lichenyj@chinamobile.com 744 Lu Huang 745 China Mobile 746 53A, Xibianmennei Ave. 747 Xunwu District, Beijing 01719 748 China 750 12. Acknowledgement 752 The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin, 753 Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun Chai, 754 Pranjal Dutta, George Swallow, Curtis Villamizar, Adrian Farrel, Alia 755 Atlas and Loa Anderson for their valuable comments on this draft. 757 13. References 759 13.1. Normative References 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, March 1997. 764 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 765 Label Switched (MPLS) Data Plane Failures", RFC 4379, 766 February 2006. 768 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 769 Specification", RFC 5036, October 2007. 771 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 772 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 774 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 775 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 776 (FEC)", RFC 5918, August 2010. 778 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 779 "Signaling LDP Label Advertisement Completion", RFC 5919, 780 August 2010. 782 13.2. Informative References 784 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 785 Networks", RFC 5920, July 2010. 787 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 788 "Multiprotocol Label Switching (MPLS) Label Switching 789 Router (LSR) Management Information Base (MIB)", RFC 3813, 790 June 2004. 792 [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions 793 of Managed Objects for the Multiprotocol Label Switching 794 (MPLS), Label Distribution Protocol (LDP)", RFC 3815, 795 June 2004. 797 Authors' Addresses 799 Quintin Zhao 800 Huawei Technology 801 125 Nagog Technology Park 802 Acton, MA 01719 803 US 805 Email: quintin.zhao@huawei.com 807 Kamran Raza 808 Cisco Systems 809 2000 Innovation Drive 810 Kanata, ON K2K-3E8, MA 811 Canada 813 Email: E-mail: skraza@cisco.com 815 Chao Zhou 816 Cisco Systems 817 300 Beaver Brook Road 818 Boxborough, MA 01719 819 US 821 Email: czhou@cisco.com 823 Luyuan Fang 824 Microsoft 826 Email: lufang@microsoft.com 828 Lianyuan Li 829 China Mobile 830 53A, Xibianmennei Ave. 831 Xunwu District, Beijing 01719 832 China 834 Email: lilianyuan@chinamobile.com 836 Daniel King 837 Old Dog Consulting 839 Email: daniel@olddog.co.uk