idnits 2.17.1 draft-ietf-mpls-ldp-multi-topology-05.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. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC4379, but the header doesn't have an 'Updates:' line to match this. 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 (October 22, 2012) is 4204 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 230 == Missing Reference: 'RFC5561' is mentioned on line 363, but not defined == Missing Reference: 'RFC-4379' is mentioned on line 538, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Missing Reference: 'IP-FRR-MT' is mentioned on line 801, but not defined == Unused Reference: 'RFC3692' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'RFC6388' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'IANA-LSPV' is defined on line 747, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Q. Zhao 3 Internet-Draft Huawei Technology 4 Intended status: Standards Track L. Fang 5 Updates: RFC4379 C. Zhou 6 Expires: April 25, 2013 Cisco Systems 7 L. Li 8 China Mobile 9 N. So 10 Tata Communications 11 K. Raza 12 Cisco Systems 13 October 22, 2012 15 LDP Extensions for Multi Topology Routing 16 draft-ietf-mpls-ldp-multi-topology-05.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. This document updates 24 RFC4379. 26 This document describes the LDP protocol extensions required to 27 support MT routing in an MPLS environment. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 6, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Signaling Extensions . . . . . . . . . . . . . . . . . . . . . 5 78 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) . . . . 5 79 3.2. New Address Families: MT IP . . . . . . . . . . . . . . . 5 80 3.3. LDP FEC Elements with MT IP AF . . . . . . . . . . . . . . 6 81 3.4. IGP MT-ID Mapping and Translation . . . . . . . . . . . . 7 82 3.5. LDP MT Capability Advertisement . . . . . . . . . . . . . 8 83 3.6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.7. LDP Sessions . . . . . . . . . . . . . . . . . . . . . . . 10 85 3.8. Reserved MT ID Values . . . . . . . . . . . . . . . . . . 10 86 4. MT Applicability on FEC-based features . . . . . . . . . . . . 10 87 4.1. Typed Wildcard FEC Element . . . . . . . . . . . . . . . . 10 88 4.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . . 11 89 4.3. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 4.3.1. New FEC Sub-Types . . . . . . . . . . . . . . . . . . 11 91 4.3.2. MT LDP IPv4 FEC Sub-TLV . . . . . . . . . . . . . . . 12 92 4.3.3. MT LDP IPv6 FEC Sub-TLV . . . . . . . . . . . . . . . 12 93 4.3.4. Operation Considerations . . . . . . . . . . . . . . . 13 94 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 13 95 5.1. MT Error Notification for Invalid Topology ID . . . . . . 13 96 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14 97 7. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 14 98 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 100 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 103 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 104 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 105 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 18 106 A.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 107 A.2. Application Scenarios . . . . . . . . . . . . . . . . . . 18 108 A.2.1. Simplified Data-plane . . . . . . . . . . . . . . . . 18 109 A.2.2. Using MT for P2P Protection . . . . . . . . . . . . . 19 110 A.2.3. Using MT for mLDP Protection . . . . . . . . . . . . . 19 111 A.2.4. Service Separation . . . . . . . . . . . . . . . . . . 19 112 A.2.5. An Alternative inter-AS VPN Solution . . . . . . . . . 20 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 115 1. Terminology 117 This document uses MPLS terminology defined in [RFC5036]. Additional 118 terms are defined below: 120 o MT-ID: A 16 bit value used to represent the Multi-Topology ID. 122 o Default MT Topology: A topology that is built using the MT-ID 123 default value of 0. 125 o MT Topology: A topology that is built using the corresponding 126 MT-ID. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 2. Introduction 134 Multi-Topology (MT) routing is supported in IP networks with the use 135 of MT aware IGP protocols. It would be advantageous for 136 communications Service Providers (CSP) to support Multiple Topologies 137 (MT) within MPLS environments (MPLS-MT). Beneficial MPLS-MT 138 deployment applications include: 140 o A CSP may want to assign varying QoS profiles to traffic, based on 141 a specific MT. 143 o Separate routing and MPLS domains may be used to isolated 144 multicast and IPv6 islands within the backbone network. 146 o Specific IP address space could be routed across an MT based on 147 security or operational isolation requirements. 149 o Low latency links could be assigned to an MT for delay sensitive 150 traffic. 152 o Management traffic could be separated from customer traffic using 153 multiple MTs, where the management traffic MT does not use links 154 that carries customer traffic. 156 This document describes the LDP procedures and protocol extensions 157 required to support MT routing in an MPLS environment. 159 This document also updates RFC4379 by defining two new FEC types for 160 LSP ping. 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 of 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 infers 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: MT IP) defines the 178 extension required to bind "prefix-related" FEC to a topology. 180 3.2. New Address Families: MT IP 182 The LDP base specification [RFC5036] (Section 4.1) defines the 183 "Prefix" FEC Element as follows: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Prefix (2) | Address Family | PreLen | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Prefix | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 1: Prefix FEC Element Format [RFC5036] 195 Where "Prefix" encoding is as defined for given "Address Family", and 196 whose length (in bits) is specified by the "PreLen" field. 198 To extend IP address families for MT, two new Address Families named 199 "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes 200 within a topology scope. 202 The format of data associated with these new Address Family is: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | IP Address | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Reserved | MT-ID | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 2: MT IP Address Family Format 214 Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and 215 "MT IPv6" AF respectively, and the field "MT-ID" corresponds to 16- 216 bit Topology ID for given address. 218 Where 16-bit "MT-ID" field defines the Topology ID, and the 219 definition and usage of the rest fields in the FEC Elements are same 220 as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to 221 default topology and MUST be ignored on receipt so as to not cause 222 any conflict/confusion with existing non-MT procedures. 224 The proposed FEC Elements with "MT IP" Address Family can be used in 225 any LDP message and procedures that currently specify and allow the 226 use of FEC Elements with IP/IPv6 Address Family. 228 [Editors Note - RFC[5036] doesn't specify the handling of unknown 229 Address Family. After we have introduced the two new address family 230 here, RFC[5036] need to be updated to add the handling procedure for 231 the unknown address families. 233 3.3. LDP FEC Elements with MT IP AF 235 The following section specifies the format extensions of the existing 236 LDP FEC Elements. The "Address Family" of these FEC elements will be 237 set to "MT IP" or "MT IPv6". 239 The MT Prefix FEC element encoding is as follows: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Prefix | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Reserved | MT-ID | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 3: MT Prefix FEC Element Format 252 Similarly, the MT mLDP FEC elements encoding is as follows, where the 253 mLDP FEC Type can be P2MP(6), MP2MP-up(7), and MP2MP-down(8): 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 | mLDP FEC Type | Address Family (MT IP/MT IPv6)| Address Length| 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 ~ Root Node Address ~ 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Reserved | MT-ID | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Opaque Length | Opaque Value ... | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 266 ~ ~ 267 | | 268 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 4: MT mLDP FEC Element Format 274 The MT Typed Wildcard FEC element encoding is as follows: 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |Typed Wcard (5)| FEC Type | Len = 6 | AF = MT IP ..| 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |... or MT IPv6 | MT ID | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 5: MT Typed Wildcard FEC Element 286 3.4. IGP MT-ID Mapping and Translation 288 The non-reserved non-special IGP MT-ID values can be used/carried in 289 LDP as-is and need no translation. However, there is a need for 290 translating reserved/special IGP MT-ID values to corresponding LDP 291 MT-IDs. The corresponding special/reserved LDP MT-ID values are 292 defined in later section 10. 294 3.5. LDP MT Capability Advertisement 296 We specify a new LDP capability, named "Multi-Topology (MT)", which 297 is defined in accordance with LDP Capability definition guidelines 298 [RFC5561]. The LDP "MT" capability can be advertised by an LDP 299 speaker to its peers either during the LDP session initialization or 300 after the LDP session is setup to announce LSR capability to support 301 MTR for the given IP address family. 303 The "MT" capability is specified using "Multi-Topology Capability" 304 TLV. The "Multi-Topology Capability" TLV format is in accordance 305 with LDP capability guidelines as defined in [RFC5561]. To be able 306 to specify IP address family, the capability specific data (i.e. 307 "Capability Data" field of Capability TLV) is populated using "Typed 308 Wildcard FEC Element" as defined in [RFC5918]. 310 The format of "Multi-Topology Capability" TLV is as follows: 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |U|F| Multi-Topology Cap.(IANA) | Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 |S| Reserved | | 318 +-+-+-+-+-+-+-+-+ | 319 ~ Typed Wildcard FEC element(s) ~ 320 | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 6: Multi-Topology Capability TLV Format 325 o Where: 327 o U- and F-bits: MUST be 1 and 0, respectively, as per Section 3. 328 (Signaling Extensions) of LDP Capabilities [RFC5561]. 330 o Multi-Topology Capability: Capability TLV type (IANA assigned) 332 o S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be 333 set to 0 or 1 in dynamic "Capability" message to advertise or 334 withdraw the capability respectively. 336 o Typed Wildcard FEC element(s): One or more elements specified as 337 the "Capability data". 339 o Length: The length (in octets) of TLV. 341 o The encoding of Typed Wildcard FEC element, as defined in 342 [RFC5561], is defined in the section 4.1 (Typed Wildcard FEC 343 Element) of this document. 345 3.6. Procedures 347 To announce its MT capability for an IP address family, LDP FEC type, 348 and Multi Topology, an LDP speaker MAY send an "MT Capability" 349 including the exact Typed Wildcard FEC element with corresponding 350 "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT 351 IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., 352 set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To 353 announce its MT capability for both IPv4 and IPv6 address family, or 354 for multiple FEC types, or for multiple Multi Topologies, an LDP 355 speaker MAY send "MT Capability" with one or more MT Typed FEC 356 elements in it. 358 o The capability for supporting multi-topology in LDP can be 359 advertised during LDP session initialization stage by including 360 the LDP MT capability TLV in LDP Initialization message. After an 361 LDP session is established, the MT capability can also be 362 advertised or withdrawn using Capability message (only if "Dynamic 363 Announcement" capability [RFC5561] has already been successfully 364 negotiated). 366 o If an LSR has not advertised MT capability, its peer must not send 367 messages that include MT identifier to this LSR. 369 o If an LSR receives a Label Mapping message with an MT parameter 370 from downstream LSR-D and its upstream LSR-U has not advertised MT 371 capability, an LSP for the MT will not be established. 373 o This document proposes to add a new notification event to signal 374 the upstream that the downstream is not capable. 376 o If an LSR is changed from non-MT capable to MT capable, it sets 377 the S bit in MT capability TLV and advertises via the Capability 378 message. The existing LSP is treated as LSP for default MT (ID 379 0). 381 o If an LSR is changed from LDP-MT capable to non-MT capable, it may 382 initiate withdraw of all label mapping for existing LSPs of all 383 non-default MTs. Then it clears the S bit in MT capability TLV 384 and advertises via the Capability message. 386 o If an LSR is changed from IGP-MT capable to non-MT capable, it may 387 wait until the routes update to withdraw FEC and release the label 388 mapping for existing LSPs of specific MT. 390 3.7. LDP Sessions 392 If a single global label space is supported, there will be an LDP 393 session supported for each pair of peers, regardless of the number of 394 MTs supported between peers. If there are different label spaces 395 supported for different topologies, which means that label spaces 396 overlap with each other for different MTs, then it is recommended to 397 establish multiple sessions for multiple topologies between these two 398 peers. In this case, multiple LSR-IDs will need to be allocated so 399 that each multiple topology can have its own label space ID. 401 3.8. Reserved MT ID Values 403 Certain MT topologies are assigned to serve predetermined purposes: 405 Default-MT: Default topology. This corresponds to OSPF default IPv4 406 and IPv6, as well as ISIS default IPv4. A value of 0 is proposed. 408 ISIS IPv6 MT: ISIS default MT-ID for IPv6. 410 Wildcard-MT: This corresponds to All-Topologies. A value of 65535 411 (0xffff) is proposed. 413 In Section 9. (IANA Considerations) this document proposes a new 414 IANA registry "LDP Multi-Topology ID Name Space" under IANA "LDP 415 Parameter" namespace to keep an LDP MT-ID reserved value. 417 If an LSR receives a FEC element with an "MT-ID" value that is 418 "Reserved" for future use (and not IANA allocated yet), the LSR must 419 abort the processing of the FEC element, and SHOULD send a 420 notification message with status code "Invalid MT-ID" to the sender. 422 4. MT Applicability on FEC-based features 424 4.1. Typed Wildcard FEC Element 426 [RFC5918] extends base LDP and defines Typed Wildcard FEC Element 427 framework. Typed Wildcard FEC element can be used in any LDP message 428 to specify a wildcard operation/action for given type of FEC. 430 The MT extensions proposed in document do not require any extension 431 in procedures for Typed Wildcard FEC element, and these procedures 432 apply as-is to MT wildcarding. The MT extensions, though, allow use 433 of "MT IP" or "MT IPv6" in the Address Family field of the Typed 434 Wildcard FEC element in order to use wildcard operations in the 435 context of a given topology. The use of MT-scoped address family 436 also allows us to specify MT-ID in these operations. 438 The proposed format in Section 4.1 (Typed Wildcard FEC Element) 439 allows an LSR to perform wildcard FEC operations under the scope of a 440 topology. If an LSR wishes to perform wildcard operation that 441 applies to all topologies, it can use a "Wildcard Topology" MT-ID. 442 For example, upon local configuration of topology "x", an LSR may 443 send a wildcard label withdraw request with MT-ID "x" to withdraw all 444 its labels from the peer that advertized under the scope of topology 445 "x". Additionally, upon a global configuration change, an LSR may 446 send a wildcard label withdraw with the MT-ID set to "Wildcard 447 Topology" to withdraw all its labels under all topologies from the 448 peer. 450 4.2. End-of-LIB 452 [RFC5919] specifies extensions and procedures for an LDP speaker to 453 signal its convergence for a given FEC type towards a peer. The 454 procedures defined in [RFC5919] applies as-is to an MT FEC element. 455 This MAY allow an LDP speaker to signal its IP convergence using 456 Typed Wildcard FEC element, and its MT IP convergence per topology 457 using a MT Typed Wildcard FEC element. 459 4.3. LSP Ping 461 [RFC4379] defines procedures to detect data-plane failures in MPLS 462 LSPs via LSP ping. The specification defines a "Target FEC Stack" 463 TLV that describes the FEC stack being tested. This TLV is sent in 464 an MPLS echo request message towards LSPs egress LSR, and is 465 forwarded along the same data path as other packets belonging to the 466 FEC. 468 "Target FEC Stack" TLV contains one or more sub-TLVs pertaining to 469 different FEC types. Section 3.2 of [RFC-4379] defines Sub-Types and 470 format for the FEC. To support LSP ping for MT LDP LSPs, this 471 document proposes following extensions to [RFC-4379]. 473 4.3.1. New FEC Sub-Types 475 We define two new FEC types for LSP ping: 477 o MT LDP IPv4 FEC 479 o MT LDP IPv6 FEC 481 We also define following new sub-types for sub-TLVs to specify these 482 FECs in the "Target FEC Stack" TLV of [RFC-4379]: 484 Sub-Type Length Value Field 485 -------- ------ ----------------- 486 24 5 MT LDP IPv4 prefix 487 25 17 MT LDP IPv6 prefix 489 Figure 7: new sub-types for sub-TLVs 491 The rules and procedures of using these sub-TLVs in an MPLS echo 492 request message are same as defined for LDP IPv4/IPv6 FEC sub-TLV 493 types in [RFC-4379]. 495 4.3.2. MT LDP IPv4 FEC Sub-TLV 497 The format of "MT LDP IPv4 FEC" sub-TLV to be used in a "Target FEC 498 Stack" [RFC4379] is: 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Type = 24 (MT LDP IPv4 FEC) | Length = 8 | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | IPv4 prefix | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Prefix Length | MBZ | MT-ID | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Figure 8: MT LDP IPv4 FEC sub-TLV 512 The format of this sub-TLV is similar to LDP IPv4 FEC sub-TLV as 513 defined in [RFC-4379]. In addition to "IPv4 prefix" and "Prefix 514 Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology 515 ID). The Length for this sub-TLV is 5. 517 4.3.3. MT LDP IPv6 FEC Sub-TLV 519 The format of "MT LDP IPv6 FEC" sub-TLV to be used in a "Target FEC 520 Stack" [RFC4379] is: 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type = 25 (MT LDP IPv6 FEC) | Length = 20 | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | | 528 | IPv6 prefix | 529 | | 530 | | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Prefix Length | MBZ | MT-ID | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Figure 9: MT LDP IPv6 FEC sub-TLV 537 The format of this sub-TLV is similar to LDP IPv6 FEC sub-TLV as 538 defined in [RFC-4379]. In addition to "IPv6 prefix" and "Prefix 539 Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology 540 ID). The Length for this sub-TLV is 17. 542 4.3.4. Operation Considerations 544 When detect data-plane failures using LSP Ping for a specific topoly, 545 the router will intiate an LSP Ping request with the targer FEC stack 546 TLV containing LDP MT IP Prefix Sub-TLV in the Echo Request packet. 547 The Echo Request packet is sent with the label binded to the IP 548 Prefix in the topolgy. Once the echo request packet reaches the 549 target router, it will process the packet and perform checs for the 550 LDP MT IP Prefix sub-TLV present in the Target FEC Stack as described 551 in [RFC4379] and respond according to [RFC4379] processing rules. 552 For the case that the LSP ping with return path not specified , the 553 reply packet may go through the default topology instead of the 554 topology where the Echol Request goes through. 556 5. Error Handling 558 The extensions defined in this document utilise the existing LDP 559 error handling defined in [RFC5036]. If an LSR receives an error 560 notification from a peer for an MPLS-MT session, it terminates the 561 LDP session by closing the TCP transport connection for the session 562 and discarding all MT-ID label mappings learned via the session. 564 5.1. MT Error Notification for Invalid Topology ID 566 If an LSR has advertized an MT Capability TLV using the 567 Initialization message or Capability message, which includes Typed 568 Wildcard FEC elements with specific MT-IDs, and it receives an MT 569 message with a MT-ID which is not included in the supported list, it 570 should response this "Invalid Topology ID" status code. 572 6. Backwards Compatibility 574 The MPLS-MT solution is backwards compatible with existing LDP 575 enhancements defined in [RFC5036], including message authenticity, 576 integrity of message, and topology loop detection. 578 7. MPLS Forwarding in MT 580 Although forwarding is out of the scope of this draft, we include 581 some forwarding consideration for informational purpose here. 583 The specified signaling mechanisms allow all the topologies to share 584 the platform-specific label space; this is the feature that allows 585 the existing data plane techniques to be used; and the specified 586 signaling mechanisms do not provide any way for the data plane to 587 associate a given packet with a context-specific label space. 589 8. Security Consideration 591 No specific security issues with the proposed solutions are known. 592 The proposed extensions in this document do not introduce any new 593 security considerations beyond that already apply to the base LDP 594 specification [RFC5036] and [RFC5920]. 596 9. IANA Considerations 598 The document introduces following new protocol elements that require 599 IANA consideration and assignments: 601 o New LDP Capability TLV: "Multi-Topology Capability" TLV (requested 602 code point: 0x510 from LDP registry "TLV Type Name Space"). 604 o New Status Code: "Multi-Topology Capability not supported" 605 (requested code point: 0x50 from LDP registry "Status Code Name 606 Space"). 608 o New Status Code: "Invalid Topology ID" (requested code point: 0x51 609 from LDP registry "Status Code Name Space"). 611 o New Status Code: "Unknown Address Family" (requested code point: 612 0x52 from LDP registry "Status Code Name Space"). 614 Registry: 615 Range/Value E Description 616 -------------- --- ------------------------------ 617 0x00000051 1 Invalid Topology ID 619 Figure 10: New Status Codes for LDP Multi Topology Extensions 621 o New address families under IANA registry "Address Family Numbers": 623 - MT IP: Multi-Topology IP version 4 (requested codepoint: 26) 624 - MT IPv6: Multi-Topology IP version 6 (requested codepoint: 27) 626 Figure 11: Address Family Numbers 628 o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP 629 Parameter" namespace. The registry is defined as: 631 Range/Value Name 632 ----------- ------------------------ 633 0 Default Topology (ISIS and OSPF) 634 1-4095 Unassigned 635 4096 ISIS IPv6 routing topology (i.e. ISIS MT ID #2) 636 4097-65534 Reserved (for future allocation) 637 65535 Wildcard Topology (ISIS or OSPF) 639 Figure 12: LDP Multi-Topology (MT) ID Name Space 641 o New Sub-TLV Types for LSP ping: Following new sub-type values 642 under TLV type 1 (Target FEC Stack) from "Multi-Protocol Label 643 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 644 registry, and "TLVs and sub-TLVs" sub-registry. 646 Sub-Type Value Field 647 -------- ----------- 648 24 MT LDP IPv4 prefix 649 25 MT LDP IPv6 prefix 651 Figure 13: New Sub-TLV Types for LSP ping 653 10. Contributors 655 Raveendra Torvi 656 Juniper Networks 657 10, Technoogy Park Drive 658 Westford, MA 01886-3140 659 US 661 Email: rtorvi@juniper.net 663 Huaimo Chen 664 Huawei Technology 665 125 Nagog Technology Park 666 Acton, MA 01719 667 US 669 Email: huaimochen@huawei.com 671 Emily Chen 672 2717 Seville Blvd, Apt 1205, 673 Clearwater, FL 33764 674 US 676 Email: emily.chen220@gmail.com 678 Chen Li 679 China Mobile 680 53A, Xibianmennei Ave. 681 Xunwu District, Beijing 01719 682 China 684 Email: lichenyj@chinamobile.com 686 Lu Huang 687 China Mobile 688 53A, Xibianmennei Ave. 689 Xunwu District, Beijing 01719 690 China 692 Email: huanglu@chinamobile.com 694 Daniel King 695 Old Dog Consulting 697 Email: E-mail: daniel@olddog.co.uk 698 Zhenbin Li 699 Huawei Technology 700 2330 Central Expressway 701 Santa Clara, CA 95050 702 US 704 Email: zhenbin.li@huawei.com 706 11. Acknowledgement 708 The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin, 709 Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun Chai and 710 pranjal Dutta for their valuable comments on this draft. 712 12. References 714 12.1. Normative References 716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, March 1997. 719 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 720 Considered Useful", BCP 82, RFC 3692, January 2004. 722 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 723 Specification", RFC 5036, October 2007. 725 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 726 "Signaling LDP Label Advertisement Completion", RFC 5919, 727 August 2010. 729 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 730 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 731 (FEC)", RFC 5918, August 2010. 733 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 734 "Label Distribution Protocol Extensions for Point-to- 735 Multipoint and Multipoint-to-Multipoint Label Switched 736 Paths", RFC 6388, November 2011. 738 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 739 Label Switched (MPLS) Data Plane Failures", RFC 4379, 740 February 2006. 742 12.2. Informative References 744 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 745 Networks", RFC 5920, July 2010. 747 [IANA-LSPV] 748 Multi-Protocol Label Switching (MPLS) Label Switched Paths 749 (LSPs) Ping Parameters, "http://www.iana.org/assignments/ 750 mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml". 752 Appendix A. Appendix 754 A.1. Requirements 756 The following specific requirements and objectives have been defined 757 in order to provide the functionality described in Section 2 758 (Introduction), and facilitate CSP configuration and operation: 760 o Minimise configuration and operation complexity of MPLS-MT across 761 the network. 763 o The MPLS-MT solution SHOULD NOT require data-plane modification. 765 o The MPLS-MT solution MUST support multiple topologies. Allowing a 766 an MPLS LSP to be established across a specific, or set of, 767 multiple topologies. 769 o Control and filtering of LSPs using explicitly including or 770 excluding multiple topologies MUST be supported. 772 o The MPLS-MT solution MUST be capable of supporting QoS mechanisms. 774 o The MPLS-MT solution MUST be backwards compatibility with existing 775 LDP message authenticity and integrity techniques, and loop 776 detection. 778 o Deployment of MPLS-MT within existing MPLS networks should be 779 possible, with nodes not capable of MPLS-MT being unaffected. 781 A.2. Application Scenarios 783 A.2.1. Simplified Data-plane 785 IGP-MT requires additional data-plane resources maintain multiple 786 forwarding for each configured MT. On the other hand, MPLS-MT does 787 not change the data-plane system architecture, if an IGP-MT is mapped 788 to an MPLS-MT. In case MPLS-MT, incoming label value itself can 789 determine an MT, and hence it requires a single NHLFE space. MPLS-MT 790 requires only MT-RIBs in the control-plane, no need to have MT-FIBs. 791 Forwarding IP packets over a particular MT requires either 792 configuration or some external means at every node, to maps an 793 attribute of incoming IP packet header to IGP-MT, which is additional 794 overhead for network management. Whereas, MPLS-MT mapping is 795 required only at the ingress-PE of an MPLS-MT LSP, because of each 796 node identifies MPLS-MT LSP switching based on incoming label, hence 797 no additional configuration is required at every node. 799 A.2.2. Using MT for P2P Protection 801 We know that [IP-FRR-MT] can be used for configuring alternate path 802 via backup-mt, such that if primary link fails, then backup-MT can be 803 used for forwarding. However, such techniques require special 804 marking of IP packets that needs to be forwarded using backup-MT. 805 MPLS-LDP-MT procedures simplify the forwarding of the MPLS packets 806 over backup-MT, as MPLS-LDP-MT procedure distribute separate labels 807 for each MT. How backup paths are computed depends on the 808 implementation, and the algorithm. The MPLS-LDP-MT in conjunction 809 with IGP-MT could be used to separate the primary traffic and backup 810 traffic. For example, service providers can create a backup MT that 811 consists of links that are meant only for backup traffic. Service 812 providers can then establish bypass LSPs, standby LSPs, using backup 813 MT, thus keeping undeterministic backup traffic away from the primary 814 traffic. 816 A.2.3. Using MT for mLDP Protection 818 For the P2MP or MP2MP LSPs setup by using mLDP protocol, there is a 819 need to setup a backup LSP to have an end to end protection for the 820 primary LSP in the applications such as IPTV, where the end to end 821 protection is a must. Since the mLDP LSP is setup following the IGP 822 routes, the second LSP setup by following the IGP routes can not be 823 guaranteed to have the link and node diversity from the primary LSP. 824 By using MPLS-LDP-MT, two topology can be configured with complete 825 link and node diversity, where the primary and secondary LSP can be 826 set up independently within each topology. The two LSPs setup by 827 this mechanism can protect each other end-to-end. 829 A.2.4. Service Separation 831 MPLS-MT procedures allow establishing two distinct LSPs for the same 832 FEC, by advertising separate label mapping for each configured 833 topology. Service providers can implement QoS using MPLS-MT 834 procedures without requiring to create separate FEC address for each 835 class. MPLS-MT can also be used separate multicast and unicast 836 traffic. 838 A.2.5. An Alternative inter-AS VPN Solution 840 When the LSP is crossing multiple domains for the inter-as VPN 841 scenarios, the LSP setup process can be done by configuring a set of 842 routers which are in different domains into a new single domain with 843 a new topology ID using the LDP multiple topology. All the routers 844 belong this new topology will be used to carry the traffic across 845 multiple domains and since they are in a single domain with the new 846 topology ID, so the LDP LSP set up can be done without propagating 847 VPN routes across AS boundaries. 849 Authors' Addresses 851 Quintin Zhao 852 Huawei Technology 853 125 Nagog Technology Park 854 Acton, MA 01719 855 US 857 Email: quintin.zhao@huawei.com 859 Luyuan Fang 860 Cisco Systems 861 300 Beaver Brook Road 862 Boxborough, MA 01719 863 US 865 Email: lufang@cisco.com 867 Chao Zhou 868 Cisco Systems 869 300 Beaver Brook Road 870 Boxborough, MA 01719 871 US 873 Email: czhou@cisco.com 874 Lianyuan Li 875 China Mobile 876 53A, Xibianmennei Ave. 877 Xunwu District, Beijing 01719 878 China 880 Email: lilianyuan@chinamobile.com 882 Ning So 883 Tata Communications 884 2613 Fairbourne Cir. 885 Plano, TX 75082 886 USA 888 Email: ning.so@tatacommunications.com 890 Kamran Raza 891 Cisco Systems 892 2000 Innovation Drive 893 Kanata, ON K2K-3E8, MA 894 Canada 896 Email: E-mail: skraza@cisco.com