idnits 2.17.1 draft-ietf-mpls-ldp-multi-topology-11.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2014) is 3696 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 (~~), 2 warnings (==), 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: August, 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 February 14, 2014 15 LDP Extensions for Multi Topology 16 draft-ietf-mpls-ldp-multi-topology-11.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 August, 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 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .3 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .4 76 3. Signaling Extensions . . . . . . . . . . . . . . . . . . . . .4 77 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) . . . .4 78 3.2. New Address Families: MT IP . . . . . . . . . . . . . . .4 79 3.3. LDP FEC Elements with MT IP AF . . . . . . . . . . . . . .5 80 3.4. IGP MT-ID Mapping and Translation . . . . . . . . . . . .6 81 3.5. LDP MT Capability Advertisement . . . . . . . . . . . . .6 82 3.5.1. Protocol Extension . . . . . . . . . . . . . . . . . .6 83 3.5.2. Procedures . . . . . . . . . . . . . . . . . . . . . .7 84 3.6. LDP Sessions . . . . . . . . . . . . . . . . . . . . . . .8 85 3.7. Reserved MT ID Values . . . . . . . . . . . . . . . . . .8 86 4. MT Applicability on FEC-based features . . . . . . . . . . . .9 87 4.1. Typed Wildcard FEC Element . . . . . . . . . . . . . . . .9 88 4.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . .9 89 4.3. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . .9 90 4.3.1. New FEC Sub-Types . . . . . . . . . . . . . . . . . .10 91 4.3.2. MT LDP IPv4 FEC Sub-TLV . . . . . . . . . . . . . . .10 92 4.3.3. MT LDP IPv6 FEC Sub-TLV . . . . . . . . . . . . . . .11 93 4.3.4. Operation Considerations . . . . . . . . . . . . . . .11 94 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . .11 95 5.1. MT Error Notification for Invalid Topology ID . . . . . .12 96 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . .12 97 7. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . .12 98 8. Security Consideration . . . . . . . . . . . . . . . . . . . .12 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . .13 100 10. Manageability Considerations . . . . . . . . . . . . . . . . .14 101 10.1. Control of Function and Policy . . . . . . . . . . . . . .14 102 10.2. Information and Data Models . . . . . . . . . . . . . . .14 103 10.3. Liveness Detection and Monitoring . . . . . . . . . . . .14 104 10.4. Verify Correct Operations . . . . . . . . . . . . . . . .14 105 10.5. Requirements On Other Protocols . . . . . . . . . . . . .15 106 10.6. Impact On Network Operations . . . . . . . . . . . . . . .15 107 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . .15 108 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .16 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . .16 110 13.1. Normative References . . . . . . . . . . . . . . . . . . .16 111 13.2. Informative References . . . . . . . . . . . . . . . . . .17 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .17 114 1. Introduction 116 Multi-Topology (MT) routing is supported in IP networks with the use 117 of MT aware IGPs. It would be advantageous for communications 118 Service Providers (CSP) to support Multiple Topologies (MT) within 119 MPLS environments (MPLS-MT). The benefits of MPLS-MT enabled 120 networks include: 122 o A CSP may want to assign varying Quality of Service (QoS) profiles 123 to traffic, based on a specific MT. 125 o Separate routing and MPLS domains may be used to isolate multicast 126 and IPv6 islands within the backbone network. 128 o Specific IP address space could be routed across an MT based on 129 security or operational isolation requirements. 131 o Low latency links could be assigned to an MT for delay sensitive 132 traffic. 134 o Management traffic could be separated from customer traffic using 135 multiple MTs, where the management traffic MT does not use links 136 that carry customer traffic. 138 This document describes the Label Distribution Protocol (LDP) 139 procedures and protocol extensions required to support MT routing in 140 an MPLS environment. 142 This document also updates RFC4379 by defining two new FEC types for 143 Label Switched Path (LSP) ping. 145 2. Terminology 147 This document uses MPLS terminology defined in [RFC5036]. Additional 148 terms are defined below: 150 o MT-ID: A 16 bit value used to represent the Multi-Topology ID. 152 o Default MT Topology: A topology that is built using the MT-ID 153 default value of 0. 155 o MT Topology: A topology that is built using the corresponding 156 MT-ID. 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 3. Signaling Extensions 164 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) 166 LDP assigns and binds a label to a Forwarding Equivalence Class 167 (FEC), where a FEC is a list of one or more FEC elements. To setup 168 LSPs for unicast IP routing paths, LDP assigns local labels for IP 169 prefixes, and advertises these labels to its peers so that an LSP is 170 setup along the routing path. To setup MT LSPs for IP prefixes under 171 a given topology scope, the LDP "prefix-related" FEC element must be 172 extended to include topology information. This implies that MT-ID 173 becomes an attribute of Prefix-related FEC element, and all FEC-Label 174 binding operations are performed under the context of given topology 175 (MT-ID). 177 The following Subsection 3.2(New Address Families (AF): MT IP) 178 defines the extension required to bind "prefix-related" FEC to a 179 topology. 181 3.2. New Address Families: MT IP 183 The LDP base specification [RFC5036] (Section 4.1) defines the 184 "Prefix" FEC Element. The "Prefix" encoding is defined for a given 185 "Address Family" (AF), and has length (in bits) specified by the 186 "PreLen" field. 188 To extend IP address families for MT, two new Address Families named 189 "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes 190 within a topology scope. 192 The format of data associated with these new Address Families is 193 described below: 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | IP Address | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Reserved | MT-ID | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 1: MT IP Address Family Format 205 Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and 206 "MT IPv6" AF respectively, and the field "MT-ID" corresponds to 16- 207 bit Topology ID for given address. 209 The definition and usage of the rest fields in the FEC Elements are 210 same as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to 211 default topology and MUST be ignored on receipt so as to not cause 212 any conflict/confusion with existing non-MT procedures. 214 The defined FEC Elements with "MT IP" Address Family can be used in 215 any LDP message and procedures that currently specify and allow the 216 use of FEC Elements with IP/IPv6 Address Family. 218 3.3. LDP FEC Elements with MT IP AF 220 The following section specifies the format extensions of the existing 221 LDP FEC Elements to support MT. The "Address Family" of these FEC 222 elements will be set to "MT IP" or "MT IPv6". 224 The MT Prefix FEC element encoding is as follows: 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Prefix | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Reserved | MT-ID | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 2: MT Prefix FEC Element Format 238 The MT Typed Wildcard FEC element encoding is as follows: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |Typed Wcard (5)| FEC Type | Len = 6 | AF = MT IP ..| 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 |... or MT IPv6 | MT ID | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 3: MT Typed Wildcard FEC Element 250 The above format can be used for any LDP FEC Element that allows use 251 of IP/IPv6 address family. In the scope of this document, the 252 allowed "FEC Type" in a MT Typed Wildcard FEC Element is "Prefix" FEC 253 element. 255 3.4. IGP MT-ID Mapping and Translation 257 The non-reserved non-special IGP MT-ID values can be used and carried 258 in LDP without the need for translation. However, there is a need 259 for translating reserved or special IGP MT-ID values to corresponding 260 LDP MT-IDs. The assigned, unassigned and special LDP MT-ID values 261 are requested In Section 9. (IANA Considerations). 263 How future LDP MT-ID values are allocated are out of of scope of this 264 document. Instead a new Internet-Draft will be created to document 265 the allocation policy and process for requesting new MT-ID values. 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 277 messages containing MT FEC elements unless the peer has said it can 278 handle it. 280 The MT capability is specified using "Multi-Topology Capability" TLV. 281 The "Multi-Topology Capability" TLV format is in accordance with LDP 282 capability guidelines as defined in [RFC5561]. To be able to specify 283 IP address family, the capability specific data (i.e. "Capability 284 Data" field of Capability TLV) is populated using "Typed Wildcard FEC 285 Element" as defined in [RFC5918]. 287 The format of "Multi-Topology Capability" TLV is as follows: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |U|F| Multi-Topology Cap.(IANA) | Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |S| Reserved | | 295 +-+-+-+-+-+-+-+-+ | 296 ~ Typed Wildcard FEC element(s) ~ 297 | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 4: Multi-Topology Capability TLV Format 302 Where: 304 o U- and F-bits: MUST be 1 and 0, respectively, as per Section 3. 305 (Signaling Extensions) of LDP Capabilities [RFC5561]. 307 o Multi-Topology Capability: Capability TLV type (IANA assigned) 309 o S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be 310 set to 0 or 1 in dynamic "Capability" message to advertise or 311 withdraw the capability respectively. 313 o Typed Wildcard FEC element(s): One or more elements specified as 314 the "Capability data". 316 o Length: length of Value field, starting from S bit, in octets. 318 o The encoding of Typed Wildcard FEC element, as defined in 319 [RFC5918], is defined in the section 3.3 (Typed Wildcard FEC 320 Element) of this document. The MT-ID field of MT Typed Wildcard 321 FEC Element MUST be set to "Wildcard Topology" when it is 322 specified in MT Capability TLV. 324 3.5.2. Procedures 326 To announce its MT capability for an IP address family, LDP FEC type, 327 and Multi Topology, an LDP speaker sends an "MT Capability" including 328 the exact Typed Wildcard FEC element with corresponding 329 "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT 330 IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., 331 set to "Prefix"), and corresponding "MT-ID". To announce its MT 332 capability for both IPv4 and IPv6 address family, or for multiple FEC 333 types, or for multiple Multi Topologies, an LDP speaker sends "MT 334 Capability" with one or more MT Typed FEC elements in it. 336 o The capability for supporting multi-topology in LDP can be 337 advertised during LDP session initialization stage by including 338 the LDP MT capability TLV in LDP Initialization message. After an 339 LDP session is established, the MT capability can also be 340 advertised or withdrawn using Capability message (only if "Dynamic 341 Announcement" capability [RFC5561] has already been successfully 342 negotiated). 344 o If an LSR has not advertised MT capability, its peer MUST NOT send 345 any LDP messages with FEC elements that include MT identifier to 346 this LSR. 348 o If an LSR is changed from non-MT capable to MT capable, it sets 349 the S bit in MT capability TLV and advertises via the Capability 350 message (if it supports Dynamic Announcement Capability). The 351 existing LSP is treated as LSP for default MT (ID 0). 353 o o If an LSR is changed from LDP-MT capable to non-MT capable, it 354 initiates withdraw of all label mapping for existing LSPs of all 355 non-default MTs. It also cleans up all the LSPs of all non- 356 default MTs locally. Then it clears the S bit in MT capability 357 TLV and advertises via the Capability message (if it supports 358 Dynamic Announcement Capability). When an LSR knows the peer node 359 is changed from LDP-MT capable to non-MT capable, it cleanup all 360 the LSPs of all non-default MTs locally and initiate withdraw of 361 all label mapping for existing LSPs of all non-default MTs. Both 362 sides of the nodes send label release to its peer once they 363 receive the label release messages even both sides have already 364 cleaned up all the LSPs locally. 366 o If an LSR does not support "Dynamic Announcement Capability", it 367 MUST reset session with its peer whenever LSR changes its local 368 capability with regards to supporting LDP MT. 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 between a pair of peers, even if there are multiple 380 topologies 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 Topology ID" to the 394 sender. 396 4. MT Applicability on FEC-based features 398 4.1. Typed Wildcard FEC Element 400 [RFC5918] extends base LDP and defines Typed Wildcard FEC Element 401 framework. Typed Wildcard FEC element can be used in any LDP message 402 to specify a wildcard operation/action for given type of FEC. 404 The MT extensions defined in document do not require any extension to 405 procedures for Typed Wildcard FEC element, and these procedures apply 406 as-is to MT wildcarding. The MT extensions, though, allow use of "MT 407 IP" or "MT IPv6" in the Address Family field of the Typed Wildcard 408 FEC element in order to use wildcard operations in the context of a 409 given topology. The use of MT-scoped address family also allows us 410 to specify MT-ID in these operations. 412 The defined format in Section 3.3 (Typed Wildcard FEC Element) allows 413 an LSR to perform wildcard FEC operations under the scope of a 414 topology. If an LSR wishes to perform wildcard operation that 415 applies to all topologies, it can use a "Wildcard Topology" MT-ID. 416 For example, upon local de-configuration of a topology "x", an LSR 417 may send a typed wildcard label withdraw message with MT-ID "x" to 418 withdraw all its labels from the peer that advertised under the scope 419 of topology "x". Additionally, upon a global configuration change, 420 an LSR may send a typed wildcard label withdraw message with the 421 MT-ID set to "Wildcard Topology" to withdraw all its labels under all 422 topologies from the peer. 424 4.2. End-of-LIB 426 [RFC5919] specifies extensions and procedures for an LDP speaker to 427 signal its convergence for a given FEC type towards a peer. The 428 procedures defined in [RFC5919] applies as-is to an MT FEC element. 429 This allows an LDP speaker to signal its IP convergence using Typed 430 Wildcard FEC element, and its MT IP convergence per topology using a 431 MT Typed Wildcard FEC element. 433 4.3. LSP Ping 435 [RFC4379] defines procedures to detect data-plane failures in MPLS 436 LSPs via LSP ping. That specification defines a "Target FEC Stack" 437 TLV that describes the FEC stack being tested. This TLV is sent in 438 an MPLS echo request message towards LSPs egress LSR, and is 439 forwarded along the same data path as other packets belonging to the 440 FEC. 442 "Target FEC Stack" TLV contains one or more sub-TLVs pertaining to 443 different FEC types. Section 3.2 of [RFC4379] defines Sub-Types and 444 format for the FEC. To support LSP ping for MT LDP LSPs, this 445 document defines following extensions to [RFC4379]. 447 4.3.1. New FEC Sub-Types 449 We define two new FEC types for LSP ping: 451 o MT LDP IPv4 FEC 453 o MT LDP IPv6 FEC 455 We also define following new sub-types for sub-TLVs to specify these 456 FECs in the "Target FEC Stack" TLV of [RFC4379]: 458 Sub-Type Length Value Field 459 -------- ------ ----------------- 460 TBA5 8 MT LDP IPv4 prefix 461 TBA6 20 MT LDP IPv6 prefix 463 Figure 5: new sub-types for sub-TLVs 465 The rules and procedures of using these sub-TLVs in an MPLS echo 466 request message are same as defined for LDP IPv4/IPv6 FEC sub-TLV 467 types in [RFC4379]. 469 4.3.2. MT LDP IPv4 FEC Sub-TLV 471 The format of "MT LDP IPv4 FEC" sub-TLV to be used in a "Target FEC 472 Stack" [RFC4379] is: 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Type = TBA5(MT LDP IPv4 FEC) | Length = 8 | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | IPv4 prefix | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Prefix Length | MBZ | MT-ID | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Figure 6: 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 7: 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 is 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 530 The extensions defined in this document utilize the existing LDP 531 error handling defined in [RFC5036]. If an LSR receives an error 532 notification from a peer for a session, it terminates the LDP session 533 by closing the TCP transport connection for the session and 534 discarding all multi-topology label mappings learned via the session. 536 5.1. MT Error Notification for Invalid Topology ID 538 An LSR should respond with an "Invalid Topology ID" status code in 539 LDP Notification message when it receives an LDP message with a FEC 540 element specifying an MT-ID which is not locally known or not 541 supported. The LSR MUST also discard the entire message before 542 sending the Notification. 544 6. Backwards Compatibility 546 The MPLS-MT solution is backwards compatible with existing LDP 547 enhancements defined in [RFC5036], including message authenticity, 548 integrity of message, and topology loop detection. 550 The legacy node which does not support MT should not receive any MT 551 related LDP messages. In case the bad things happen, according to 552 [RFC5036], processing of such messages should be aborted. 554 7. MPLS Forwarding in MT 556 Although forwarding is out of the scope of this draft, we include 557 some forwarding consideration for informational purpose here. 559 The specified signaling mechanisms allow all the topologies to share 560 the platform-specific label space, This feature allows the existing 561 data plane techniques to be used. Also, there is no way for the data 562 plane to associate a received packet with any one topology, meaning 563 that topology-specific label spaces cannot be used. 565 8. Security Consideration 567 The use of MT over existing MPLS solutions does not offer any 568 specific security benefit. 570 General LDP Communication security threats and how these may be 571 mitigated are described in [RFC5036], these threats include: 573 o Spoofing 574 o Privacy 576 o Denial of Service 578 For further discussion regarding possible LDP communication threats 579 and mitigation techniques see [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: "Invalid Topology ID" (requested code point: TBA2 590 from LDP registry "Status Code Name Space"). 592 Registry: 593 Range/Value Description 594 -------------- ------------------------------ 595 TBA1 Invalid Topology ID 597 Figure 8: New Code Points for LDP Multi Topology Extensions 599 o New address families under IANA registry "Address Family Numbers": 601 - MT IP: Multi-Topology IP version 4 (requested codepoint:26) 602 - MT IPv6: Multi-Topology IP version 6 (requested codepoint:27) 604 Figure 9: Address Family Numbers 606 o New registry "MPLS Multi-Topology Identifiers". The allocation 607 policies for this registry are: 609 Range/Value Purpose Reference 610 ----------- ------------------------------------- ---------- 611 0 Default/standard topology [This.I-D] 612 1 IPv4 in-band management [This.I-D] 613 2 IPv6 routing topology [This.I-D] 614 3 IPv4 multicast topology [This.I-D] 615 4 IPv6 multicast topology [This.I-D] 616 5 IPv6 in-band management [This.I-D] 617 6-3995 Unassigned for future IGP topologies [This.I-D] 618 Assigned by Standards Action [This.I-D] 619 3996-4095 Experimental [This.I-D] 620 4096-65534 Unassigned for MPLS topologies [This.I-D] 621 Assigned by Standards Action 622 65535 Wildcard Topology [This.I-D] 623 Figure 10: MPLS Multi-Topology Identifier registry 625 o New Sub-TLV Types for LSP ping: Following new sub-type values 626 under TLV type 1 (Target FEC Stack) from "Multi-Protocol Label 627 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 628 registry, and "TLVs and sub-TLVs" sub-registry. 630 Sub-Type Value Field 631 -------- ----------- 632 TBA3 MT LDP IPv4 prefix 633 TBA4 MT LDP IPv6 prefix 635 Figure 11: New Sub-TLV Types for LSP ping 637 IANA should allocate the next available numbers for these TBAs. 639 As highlighted at the end of Section 3.4 (IGP MT-ID Mapping and 640 Translation), a new Internet-Draft will be created to document the 641 policy and process for allocating new MT-ID values. 643 10. Manageability Considerations 645 10.1. Control of Function and Policy 647 There are capabilities that should be configurable to enable good 648 manageability. One such example is to allow enable or disable LDP 649 Multi-Topology capability. It is assumed that the mapping of the LDP 650 MT ID and IGP MT ID is manually configured on every router by 651 default. If an automatic mapping between IGP MT IDs and LDP MT IDs 652 is needed, there must be explicit configuration to do so. 654 10.2. Information and Data Models 656 Any extensions that may be required for existing MIBs are beyond the 657 scope of this document. 659 10.3. Liveness Detection and Monitoring 661 Mechanisms defined in this document do not imply any new liveness 662 detection and monitoring requirements. 664 10.4. Verify Correct Operations 665 If an operator is trying to debug LDP MT enabled network and wants to 666 make the association between the LDP label advertisement and the IGP 667 routing advertisement, then the user MUST understand the mapping 668 mechanism to convert the IGP MT ID to the LDP MT ID. This type of 669 mapping mechanisms is out of the scope of this document. 671 10.5. Requirements On Other Protocols 673 If the LDP MT ID has an implicit dependency on IGP MT ID, then the 674 corresponding IGP MT feattures will need to be supported. 676 10.6. Impact On Network Operations 678 Mechanisms defined in this document do not have any impact on network 679 operations. 681 11. Contributors 683 Ning So 684 Tata Communications 685 2613 Fairbourne Cir. 686 Plano, TX 75082 687 USA 689 Email: ning.so@tatacommunications.com 691 Raveendra Torvi 692 Juniper Networks 693 10, Technoogy Park Drive 694 Westford, MA 01886-3140 695 US 697 Email: rtorvi@juniper.net 699 Huaimo Chen 700 Huawei Technology 701 125 Nagog Technology Park 702 Acton, MA 01719 703 US 705 Email: huaimochen@huawei.com 707 Emily Chen 708 2717 Seville Blvd, Apt 1205, 709 Clearwater, FL 33764 710 US 712 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 Zhenbin Li 730 Huawei Technology 731 2330 Central Expressway 732 Santa Clara, CA 95050 733 US 735 Email: zhenbin.li@huawei.com 737 12. Acknowledgement 739 The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin, 740 Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun Chai, 741 Pranjal Dutta, George Swallow, Curtis Villamizar, Adrian Farrel, Alia 742 Atlas, Loa Anderson, Joel Halpern and Kathleen Moriarty for their 743 valuable comments on this draft. 745 13. References 747 13.1. Normative References 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, March 1997. 752 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 753 Label Switched (MPLS) Data Plane Failures", RFC 4379, 754 February 2006. 756 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 757 Specification", RFC 5036, October 2007. 759 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 760 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 762 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 763 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 764 (FEC)", RFC 5918, August 2010. 766 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 767 "Signaling LDP Label Advertisement Completion", RFC 5919, 768 August 2010. 770 13.2. Informative References 772 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 773 Networks", RFC 5920, July 2010. 775 Authors' Addresses 777 Quintin Zhao 778 Huawei Technology 779 125 Nagog Technology Park 780 Acton, MA 01719 781 US 783 Email: quintin.zhao@huawei.com 785 Kamran Raza 786 Cisco Systems 787 2000 Innovation Drive 788 Kanata, ON K2K-3E8, MA 789 Canada 791 Email: E-mail: skraza@cisco.com 793 Chao Zhou 794 Cisco Systems 795 300 Beaver Brook Road 796 Boxborough, MA 01719 797 US 799 Email: czhou@cisco.com 801 Luyuan Fang 802 Microsoft 804 Email: lufang@microsoft.com 805 Lianyuan Li 806 China Mobile 807 53A, Xibianmennei Ave. 808 Xunwu District, Beijing 01719 809 China 811 Email: lilianyuan@chinamobile.com 813 Daniel King 814 Old Dog Consulting 816 Email: lufang@microsoft.com