idnits 2.17.1 draft-ietf-mpls-ldp-multi-topology-03.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 : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 10 characters in excess of 72. 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 (March 11, 2012) is 4429 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) -- Looks like a reference, but probably isn't: '5036' on line 242 == Missing Reference: 'RFC5561' is mentioned on line 377, but not defined == Missing Reference: 'IP-FRR-MT' is mentioned on line 640, but not defined == Unused Reference: 'RFC3692' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC6388' is defined on line 608, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Q. Zhao 3 Internet-Draft Huawei Technology 4 Intended status: Standards Track L. Fang 5 Expires: September 12, 2012 C. Zhou 6 Cisco Systems 7 L. Li 8 China Mobile 9 N. So 10 Verizon Business 11 K. Kamran 12 Cisco Systems 13 March 11, 2012 15 LDP Extensions for Multi Topology Routing 16 draft-ietf-mpls-ldp-multi-topology-03.txt 18 Abstract 20 Multi-Topology (MT) routing is supported in IP networks with the use 21 of MT aware IGP protocols. 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 September 12, 2012. 45 Copyright Notice 47 Copyright (c) 2012 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 4. Signaling Extensions . . . . . . . . . . . . . . . . . . . . . 5 78 4.1. Topology-Scoped FEC . . . . . . . . . . . . . . . . . . . 5 79 4.2. New Address Families: MT IP . . . . . . . . . . . . . . . 5 80 4.3. LDP FEC Elements with MT IP AF . . . . . . . . . . . . . . 7 81 4.4. IGP MT-ID Mapping and Translation . . . . . . . . . . . . 8 82 4.5. LDP MT Capability Advertisement . . . . . . . . . . . . . 8 83 4.6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.7. LDP Sessions . . . . . . . . . . . . . . . . . . . . . . . 10 85 4.8. Reserved MT ID Values . . . . . . . . . . . . . . . . . . 11 86 5. MT Applicability on FEC-based features . . . . . . . . . . . . 11 87 5.1. Typed Wildcard FEC Element . . . . . . . . . . . . . . . . 11 88 5.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . . 12 89 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 12 90 6.1. MT Error Notifications . . . . . . . . . . . . . . . . . . 12 91 6.2. MT Advisory Notifications . . . . . . . . . . . . . . . . 12 92 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12 93 8. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 13 94 9. Security Consideration . . . . . . . . . . . . . . . . . . . . 13 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 96 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 98 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 99 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 100 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 15 101 A.1. Application Scenarios . . . . . . . . . . . . . . . . . . 15 102 A.1.1. Simplified Data-plane . . . . . . . . . . . . . . . . 15 103 A.1.2. Using MT for P2P Protection . . . . . . . . . . . . . 15 104 A.1.3. Using MT for mLDP Protection . . . . . . . . . . . . . 16 105 A.1.4. Service Separation . . . . . . . . . . . . . . . . . . 16 106 A.1.5. An Alternative inter-AS VPN Solution . . . . . . . . . 16 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 109 1. Terminology 111 This document uses MPLS terminology defined in [RFC5036]. Additional 112 terms are defined below: 114 o MT-ID: A 16 bit value used to represent the Multi-Topology ID. 116 o Default MT Topology: A topology that is built using the MT-ID 117 default value of 0. 119 o MT Topology: A topology that is built using the corresponding 120 MT-ID. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Introduction 128 It would be advantageous for Communications Service Providers (CSP) 129 to support Multiple Topologies (MT) within MPLS environments 130 (MPLS-MT). Beneficial MPLS-MT deployment scenarios include: 132 o A CSP may want to assign varying QoS profiles to traffic, based on 133 a specific MT. 135 o Separate routing and MPLS domains may be used to isolated 136 multicast and IPv6 islands within the backbone network. 138 o Specific IP address space could be routed across an MT based on 139 security or operational isolation requirements. 141 o Low latency links could be assigned to an MT for delay sensitive 142 traffic. 144 o Management traffic could be separated from customer traffic using 145 multiple MTs, where the management traffic MT does not use links 146 that carries customer traffic. 148 3. Requirements 150 The following specific requirements and objectives have been defined 151 in order to provide the functionality described in Section 2 152 (Introduction), and facilitate CSP configuration and operation: 154 o Minimise configuration and operation complexity of MPLS-MT across 155 the network. 157 o The MPLS-MT solution SHOULD NOT require data-plane modification. 159 o The MPLS-MT solution MUST support multiple topologies. Allowing a 160 an MPLS LSP to be established across a specific, or set of, 161 multiple topologies. 163 o Control and filtering of LSPs using explicitly including or 164 excluding multiple topologies MUST be supported. 166 o The MPLS-MT solution MUST be capable of supporting QoS mechanisms. 168 o The MPLS-MT solution MUST be backwards compatibility with existing 169 LDP message authenticity and integrity techniques, and loop 170 detection. 172 o Deployment of MPLS-MT within existing MPLS networks should be 173 possible, with nodes not capable of MPLS-MT being unaffected. 175 4. Signaling Extensions 177 4.1. Topology-Scoped FEC 179 LDP assigns and binds a label to a FEC, where a FEC is a list of one 180 of more FEC elements. To setup LSPs for unicast IP routing paths, 181 LDP assigns local labels for IP prefixes, and advertises these labels 182 to its peers so that an LSP is setup along the routing path. To 183 setup MT LSPs for IP prefixes under a given topology scope, the LDP 184 "prefix-related" FEC element must be extended to include topology 185 info. This infers that MT-ID becomes an attribute of Prefix-related 186 FEC element, and all FEC-Label binding operations are performed under 187 the context of given topology (MT-ID). 189 The following Subsection (4.2 New Address Families: MT IP) defines 190 the extension required to bind "prefix-related" FEC to a topology. 192 4.2. New Address Families: MT IP 194 The LDP base specification [RFC5036] (Section 4.1) defines the 195 "Prefix" FEC Element as follows: 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Prefix (2) | Address Family | PreLen | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Prefix | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 1: Prefix FEC Element Format [RFC5036] 207 Where "Prefix" encoding is as defined for given "Address Family", and 208 whose length (in bits) is specified by the "PreLen" field. 210 To extend IP address families for MT, two new Address Families named 211 "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes 212 within a topology scope. 214 The format of data associated with these new Address Family is: 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | IP Address | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Reserved | MT-ID | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 2: MT IP Address Family Format 226 Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and 227 "MT IPv6" AF respectively, and the field "MT-ID" corresponds to 16- 228 bit Topology ID for given address. 230 Where 16-bit "MT-ID" field defines the Topology ID, and the 231 definition and usage of the rest fields in the FEC Elements are same 232 as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to 233 default topology and MUST be ignored on receipt so as to not cause 234 any conflict/confusion with existing non-MT procedures. 236 The proposed FEC Elements with "MT IP" Address Family can be used in 237 any LDP message and procedures that currently specify and allow the 238 use of FEC Elements with IP/IPv6 Address Family. 240 [Editors Note - RFC[5036] doesn't specify the handling of unknown 241 Address Family. After we have introduced the two new address family 242 here, RFC[5036] need to be updated to add the handling procedure for 243 the unknown address families. 245 4.3. LDP FEC Elements with MT IP AF 247 When introducing the new Address Family, it will make the extension 248 to all the prefix-related FEC Elements by nature. This section 249 specifies the format extensions of the existing LDP FEC Elements. 250 The "Address Family" of these FEC elements will be set to "MT IP" or 251 "MT IPv6". 253 The MT Prefix FEC element will be encoded as follows: 255 0 1 2 3 256 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Prefix | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Reserved | MT-ID | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 3: MT Prefix FEC Element Format 267 Similarly, the MT mLDP FEC elements will be encoded as follows, where 268 the mLDP FEC Type can be P2MP(6), MP2MP-up(7), and MP2MP-down(8): 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | mLDP FEC Type | Address Family (MT IP/MT IPv6)| Address Length| 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 ~ Root Node Address ~ 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Reserved | MT-ID | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Opaque Length | Opaque Value ... | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 281 ~ ~ 282 | | 283 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 4: MT mLDP FEC Element Format 289 And the MT Typed Wildcard FEC element encoding is as follows: 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |Typed Wcard (5)| FEC Type | Len = 6 | AF = MT IP ..| 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |... or MT IPv6 | MT ID | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 5: MT Typed Wildcard FEC Element 301 4.4. IGP MT-ID Mapping and Translation 303 The non-reserved non-special IGP MT-ID values can be used/carried in 304 LDP as-is and need no translation. However, there is a need for 305 translating reserved/special IGP MT-ID values to corresponding LDP 306 MT-IDs. The corresponding special/reserved LDP MT-ID values are 307 defined in later section 10. 309 4.5. LDP MT Capability Advertisement 311 We specify a new LDP capability, named "Multi-Topology (MT)", which 312 is defined in accordance with LDP Capability definition guidelines 313 [RFC5561]. The LDP "MT" capability can be advertised by an LDP 314 speaker to its peers either during the LDP session initialization or 315 after the LDP session is setup to announce LSR capability to support 316 MTR for the given IP address family. 318 The "MT" capability is specified using "Multi-Topology Capability" 319 TLV. The "Multi-Topology Capability" TLV format is in accordance 320 with LDP capability guidelines as defined in [RFC5561]. To be able 321 to specify IP address family, the capability specific data (i.e. 322 "Capability Data" field of Capability TLV) is populated using "Typed 323 Wildcard FEC Element" as defined in [RFC5918]. 325 The format of "Multi-Topology Capability" TLV is as follows: 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 |U|F| Multi-Topology Cap.(IANA) | Length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 |S| Reserved | | 333 +-+-+-+-+-+-+-+-+ | 334 ~ Typed Wildcard FEC element(s) ~ 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 6: Multi-Topology Capability TLV Format 340 Where: 342 o U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of 343 LDP Capabilities [RFC5561]. 345 o Multi-Topology Capability: Capability TLV type (IANA assigned) 347 o S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be 348 set to 0 or 1 in dynamic "Capability" message to advertise or 349 withdraw the capability respectively. 351 o Typed Wildcard FEC element(s): One or more elements specified as 352 the "Capability data". 354 o Length: The length (in octets) of TLV. 356 The encoding of Typed Wcard FEC element, as defined in [RFC5561], is 357 defined in the section 4.3 of this document. 359 4.6. Procedures 361 To announce its MT capability for given IP address family, given LDP 362 FEC type, and given Multi Topology, an LDP speaker MAY send "MT 363 Capability" including the exact Typed Wildcard FEC element with 364 corresponding "Address Family" field (i.e. set to "MT IP" for IPv4 365 and set to "MT IPv6" for IPv6 address family), corresponding "FEC 366 Type" field (i.e. set to "P2P", "P2MP", "MP2MP"), and corresponding 367 "MT-ID". To announce its MT capability for both IPv4 and IPv6 368 address family, or for multiple FEC types, or for multiple Multi 369 Topologies, an LDP speaker MAY send "MT Capability" with one or more 370 MT Typed FEC elements in it. 372 o The capability for supporting multi-topology in LDP can be 373 advertised during LDP session initialization stage by including 374 the LDP MT capability TLV in LDP Initialization message. After 375 LDP session is established, the MT capability can also be 376 advertised or withdrawn using Capability message (only if "Dynamic 377 Announcement" capability [RFC5561] has already been successfully 378 negotiated). 380 o If an LSR has not advertised MT capability, its peer must not send 381 messages that include MT identifier to this LSR. 383 o If an LSR receives a Label Mapping message with MT parameter from 384 downstream LSR-D and its upstream LSR-U has not advertised MT 385 capability, an LSP for the MT will not be established. 387 o We propose to add a new notification event to signal the upstream 388 that the downstream is not capable. 390 o If an LSR is changed from non-MT capable to MT capable, it sets 391 the S bit in MT capability TLV and advertises via the Capability 392 message. The existing LSP is treated as LSP for default MT (ID 393 0). 395 o If an LSR is changed from LDP-MT capable to non-MT capable, it may 396 initiate withdraw of all label mapping for existing LSPs of all 397 non-default MTs. Then it clears the S bit in MT capability TLV 398 and advertises via the Capability message. 400 o If an LSR is changed from IGP-MT capable to non-MT capable, it may 401 wait until the routes update to withdraw FEC and release the label 402 mapping for existing LSPs of specific MT. 404 o There will be case where IGP is MT capable but MPLS is not and the 405 handling procedure for this case is TBD. 407 4.7. LDP Sessions 409 Depending on the number of label spaces supported, if a single global 410 label space is supported, there will be one session supported for 411 each pair of peer, even there are multiple topologies supported 412 between these two peers. If there are different label spaces 413 supported for different topologies, which means that label spaces 414 overlap with each other for different MTs, then it is suggested to 415 establish multiple sessions for multiple topologies between these two 416 peers. In this case, multiple LSR-IDs need to be allocated 417 beforehand so that each multiple topology can have its own label 418 space ID. 420 [Editors Note - This section requires further discussion] 422 4.8. Reserved MT ID Values 424 Certain MT topologies are assigned to serve pre-determined purposes: 426 Default-MT: Default topology. This corresponds to OSPF default IPv4 427 and IPv6, as well as ISIS default IPv4. A value of 0 is proposed. 429 ISIS IPv6 MT: ISIS default MT-ID for IPv6. 431 Wildcard-MT: This corresponds to All-Topologies. A value of 65535 432 (0xffff) is proposed. 434 We propose a new IANA registry "LDP Multi-Topology ID Name Space" 435 under IANA "LDP Parameter" namespace to keep LDP MT-ID reserved 436 value. 438 If an LSR receives a FEC element with an "MT-ID" value that is 439 "Reserved" for future use (and not IANA allocated yet), the LSR must 440 abort the processing of the FEC element, and SHOULD send a 441 notification message with status code "Invalid MT-ID" to the sender. 443 [Editors Note - This section requires further discussion]. 445 5. MT Applicability on FEC-based features 447 5.1. Typed Wildcard FEC Element 449 [RFC5918] extends base LDP and defines Typed Wildcard FEC Element 450 framework. Typed Wildcard FEC element can be used in any LDP message 451 to specify a wildcard operation/action for given type of FEC. 453 The MT extensions proposed in document do not require any extension 454 in procedures for Typed Wildcard FEC element, and these procedures 455 apply as-is to MT wildcarding. The MT extensions, though, allow use 456 of "MT IP" or "MT IPv6" in the Address Family field of the Typed 457 Wildcard FEC element in order to use wildcard operations in the 458 context of a given topology. The use of MT-scoped address family 459 also allows us to specify MT-ID in these operations. 461 The proposed format in section 4.3 allows an LSR to perform wildcard 462 FEC operations under the scope of a topology. If an LSR wishes to 463 perform wildcard operation that applies to all topologies, it can use 464 "Wildcard Topology" MT-ID as defined in section 4.8. For instance, 465 upon local un-configuration of topology "x", an LSR may send wildcard 466 label withdraw with MT-ID "x" to withdraw all its labels from peer 467 that were advertised under the scope of topology "x". On the other 468 hand, upon some global configuration change, an LSR may send wildcard 469 label withdraw with MT-ID set to "Wildcard Topology" to withdraw all 470 its labels under all topologies from the peer. 472 5.2. End-of-LIB 474 [RFC5919] specifies extensions and procedures for an LDP speaker to 475 signal its convergence for given FEC type towards a peer. The 476 procedures defined in [RFC5919] apply as-is to MT FEC element. This 477 means that an LDP speaker MAY signal its IP convergence using Typed 478 Wildcard FEC element, and its MT IP convergence per topology using MT 479 Typed Wildcard FEC element (as defined in earlier section). 481 6. Error Handling 483 The extensions defined in this document utilise the existing LDP 484 error handling defined in [RFC5036]. Errors and events are signaled 485 to MPLS-MT peers using LDP notification messages. There are two 486 kinds of MPLS-MT notification messages: 488 1. Error Notifications. 490 These are used to signal fatal errors. If an LSR receives an error 491 notification from a peer for an MPLS-MT session, it terminates the 492 LDP session by closing the TCP transport connection for the session 493 and discarding all MT-ID label mappings learned via the session. 495 2. Advisory Notifications. 497 These are used to pass an LSR information about the MT-ID LDP session 498 and the status of some previous message received from the peer. 500 6.1. MT Error Notifications 502 Multi-Topology Capability not supported. 504 Invalid Topology ID 506 6.2. MT Advisory Notifications 508 Unknown Address Family ("MT IP" and "MT IPv6") 510 7. Backwards Compatibility 512 The MPLS-MT solution is backwards compatible with existing LDP 513 enhancements defined in [RFC5036], including message authenticity, 514 integrity of message, and topology loop detection. 516 8. MPLS Forwarding in MT 518 Although forwarding is out of the scope of this draft, we include 519 some forwarding consideration for informational purpose here. 521 The specified signaling mechanisms allow all the topologies to share 522 the platform-specific label space; this is the feature that allows 523 the existing data plane techniques to be used; and the specified 524 signaling mechanisms do not provide any way for the data plane to 525 associate a given packet with a context-specific label space. 527 9. Security Consideration 529 No specific security issues with the proposed solutions are known. 530 The proposed extension in this document does not introduce any new 531 security considerations beyond that already apply to the base LDP 532 specification [RFC5036] and [RFC5920]. 534 10. IANA Considerations 536 The document introduces following new protocol elements that require 537 IANA consideration and assignments: 539 o New LDP Capability TLV: "Multi-Topology Capability" TLV (requested 540 code point: 0x510 from LDP registry "TLV Type Name Space"). 542 o New Status Code: "Multi-Topology Capability not supported" 543 (requested code point: 0x50 from LDP registry "Status Code Name 544 Space"). 546 o New Status Code: "Invalid Topology ID" (requested code point: 0x51 547 from LDP registry "Status Code Name Space"). 549 o New Status Code: "Unknown Address Family" (requested code point: 550 0x52 from LDP registry "Status Code Name Space"). 552 Registry: 553 Range/Value E Description 554 -------------- --- ------------------------------ 555 0x00000050 1 Multi-Topology Capability not supported 556 0x00000051 1 Invalid Topology ID 557 0x00000052 0 Unknown Address Family 559 Figure 7: New Status Codes for LDP Multi Topology Extensions 561 o New address families under IANA registry "Address Family Numbers": 563 - MT IP: Multi-Topology IP version 4 (requested codepoint: 26) 564 - MT IPv6: Multi-Topology IP version 6 (requested codepoint: 27) 566 Figure 8: Address Family Numbers 568 o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP 569 Parameter" namespace. The registry is defined as: 571 Range/Value Name 572 ----------- ------------------------ 573 0 Default Topology (ISIS and OSPF) 574 1-4095 Unassigned 575 4096 ISIS IPv6 routing topology (i.e. ISIS MT ID #2) 576 4097-65534 Reserved (for future allocation) 577 65535 Wildcard Topology (ISIS or OSPF) 579 Figure 9: LDP Multi-Topology (MT) ID Name Space 581 11. Acknowledgement 583 The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin, 584 Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun Chai for 585 their valuable comments on this draft. 587 12. References 589 12.1. Normative References 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997. 594 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 595 Considered Useful", BCP 82, RFC 3692, January 2004. 597 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 598 Specification", RFC 5036, October 2007. 600 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 601 "Signaling LDP Label Advertisement Completion", RFC 5919, 602 August 2010. 604 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 605 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 606 (FEC)", RFC 5918, August 2010. 608 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 609 "Label Distribution Protocol Extensions for Point-to- 610 Multipoint and Multipoint-to-Multipoint Label Switched 611 Paths", RFC 6388, November 2011. 613 12.2. Informative References 615 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 616 Networks", RFC 5920, July 2010. 618 Appendix A. Appendix 620 A.1. Application Scenarios 622 A.1.1. Simplified Data-plane 624 IGP-MT requires additional data-plane resources maintain multiple 625 forwarding for each configured MT. On the other hand, MPLS-MT does 626 not change the data-plane system architecture, if an IGP-MT is mapped 627 to an MPLS-MT. In case MPLS-MT, incoming label value itself can 628 determine an MT, and hence it requires a single NHLFE space. MPLS-MT 629 requires only MT-RIBs in the control-plane, no need to have MT-FIBs. 630 Forwarding IP packets over a particular MT requires either 631 configuration or some external means at every node, to maps an 632 attribute of incoming IP packet header to IGP-MT, which is additional 633 overhead for network management. Whereas, MPLS-MT mapping is 634 required only at the ingress-PE of an MPLS-MT LSP, because of each 635 node identifies MPLS-MT LSP switching based on incoming label, hence 636 no additional configuration is required at every node. 638 A.1.2. Using MT for P2P Protection 640 We know that [IP-FRR-MT] can be used for configuring alternate path 641 via backup-mt, such that if primary link fails, then backup-MT can be 642 used for forwarding. However, such techniques require special 643 marking of IP packets that needs to be forwarded using backup-MT. 644 MPLS-LDP-MT procedures simplify the forwarding of the MPLS packets 645 over backup-MT, as MPLS-LDP-MT procedure distribute separate labels 646 for each MT. How backup paths are computed depends on the 647 implementation, and the algorithm. The MPLS-LDP-MT in conjunction 648 with IGP-MT could be used to separate the primary traffic and backup 649 traffic. For example, service providers can create a backup MT that 650 consists of links that are meant only for backup traffic. Service 651 providers can then establish bypass LSPs, standby LSPs, using backup 652 MT, thus keeping undeterministic backup traffic away from the primary 653 traffic. 655 A.1.3. Using MT for mLDP Protection 657 For the P2MP or MP2MP LSPs setup by using mLDP protocol, there is a 658 need to setup a backup LSP to have an end to end protection for the 659 primary LSP in the applications such as IPTV, where the end to end 660 protection is a must. Since the mLDP LSP is setup following the IGP 661 routes, the second LSP setup by following the IGP routes can not be 662 guaranteed to have the link and node diversity from the primary LSP. 663 By using MPLS-LDP-MT, two topology can be configured with complete 664 link and node diversity, where the primary and secondary LSP can be 665 set up independently within each topology. The two LSPs setup by 666 this mechanism can protect each other end-to-end. 668 A.1.4. Service Separation 670 MPLS-MT procedures allow establishing two distinct LSPs for the same 671 FEC, by advertising separate label mapping for each configured 672 topology. Service providers can implement QoS using MPLS-MT 673 procedures without requiring to create separate FEC address for each 674 class. MPLS-MT can also be used separate multicast and unicast 675 traffic. 677 A.1.5. An Alternative inter-AS VPN Solution 679 When the LSP is crossing multiple domains for the inter-as VPN 680 scenarios, the LSP setup process can be done by configuring a set of 681 routers which are in different domains into a new single domain with 682 a new topology ID using the LDP multiple topology. All the routers 683 belong this new topology will be used to carry the traffic across 684 multiple domains and since they are in a single domain with the new 685 topology ID, so the LDP LSP set up can be done without propagating 686 VPN routes across AS boundaries. 688 Authors' Addresses 690 Quintin Zhao 691 Huawei Technology 692 125 Nagog Technology Park 693 Acton, MA 01719 694 US 696 Email: quintin.zhao@huawei.com 697 Luyuan Fang 698 Cisco Systems 699 300 Beaver Brook Road 700 Boxborough, MA 01719 701 US 703 Email: lufang@cisco.com 705 Chao Zhou 706 Cisco Systems 707 300 Beaver Brook Road 708 Boxborough, MA 01719 709 US 711 Email: czhou@cisco.com 713 Lianyuan Li 714 China Mobile 715 53A, Xibianmennei Ave. 716 Xunwu District, Beijing 01719 717 China 719 Email: lilianyuan@chinamobile.com 721 Ning So 722 Verizon Business 723 2400 North Glenville Drive 724 Richardson, TX 75082 725 USA 727 Email: Ning.So@verizonbusiness.com 729 Kamran Raza 730 Cisco Systems 731 2000 Innovation Drive 732 Kanata, ON K2K-3E8, MA 733 Canada 735 Email: E-mail: skraza@cisco.com 736 Raveendra Torvi 737 Juniper Networks 738 10, Technoogy Park Drive 739 Westford, MA 01886-3140 740 US 742 Email: rtorvi@juniper.net 744 Huaimo Chen 745 Huawei Technology 746 125 Nagog Technology Park 747 Acton, MA 01719 748 US 750 Email: huaimochen@huawei.com 752 Emily Chen 753 Huawei Technology 754 2330 Central Expressway 755 Santa Clara, CA 95050 756 US 758 Email: emily.chenying@huawei.com 760 Chen Li 761 China Mobile 762 53A, Xibianmennei Ave. 763 Xunwu District, Beijing 01719 764 China 766 Email: lichenyj@chinamobile.com 768 Lu Huang 769 China Mobile 770 53A, Xibianmennei Ave. 771 Xunwu District, Beijing 01719 772 China 774 Email: huanglu@chinamobile.com 776 Daniel King 777 Old Dog Consulting 779 Email: E-mail: daniel@olddog.co.uk