idnits 2.17.1 draft-ietf-mpls-ldp-multi-topology-06.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 2 instances of too long lines in the document, the longest one being 7 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 (December 4, 2012) is 4154 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 228 == Missing Reference: 'RFC5561' is mentioned on line 361, but not defined == Missing Reference: 'RFC-4379' is mentioned on line 536, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Unused Reference: 'RFC3692' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'RFC6388' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'IANA-LSPV' is defined on line 755, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 8 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: June 7, 2013 Cisco Systems 7 L. Li 8 China Mobile 9 K. Raza 10 Cisco Systems 11 December 4, 2012 13 LDP Extensions for Multi Topology Routing 14 draft-ietf-mpls-ldp-multi-topology-06.txt 16 Abstract 18 Multi-Topology (MT) routing is supported in IP networks with the use 19 of MT aware IGP protocols. In order to provide MT routing within 20 Multiprotocol Label Switching (MPLS) Label Distribution Protocol 21 (LDP) networks new extensions are required. This document updates 22 RFC4379. 24 This document describes the LDP protocol extensions required to 25 support MT routing in an MPLS environment. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 6, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Signaling Extensions . . . . . . . . . . . . . . . . . . . . . 5 76 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) . . . . 5 77 3.2. New Address Families: MT IP . . . . . . . . . . . . . . . 5 78 3.3. LDP FEC Elements with MT IP AF . . . . . . . . . . . . . . 6 79 3.4. IGP MT-ID Mapping and Translation . . . . . . . . . . . . 7 80 3.5. LDP MT Capability Advertisement . . . . . . . . . . . . . 8 81 3.6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 9 82 3.7. LDP Sessions . . . . . . . . . . . . . . . . . . . . . . . 10 83 3.8. Reserved MT ID Values . . . . . . . . . . . . . . . . . . 10 84 4. MT Applicability on FEC-based features . . . . . . . . . . . . 10 85 4.1. Typed Wildcard FEC Element . . . . . . . . . . . . . . . . 10 86 4.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . . 11 87 4.3. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 4.3.1. New FEC Sub-Types . . . . . . . . . . . . . . . . . . 11 89 4.3.2. MT LDP IPv4 FEC Sub-TLV . . . . . . . . . . . . . . . 12 90 4.3.3. MT LDP IPv6 FEC Sub-TLV . . . . . . . . . . . . . . . 12 91 4.3.4. Operation Considerations . . . . . . . . . . . . . . . 13 92 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 13 93 5.1. MT Error Notification for Invalid Topology ID . . . . . . 13 94 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14 95 7. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 14 96 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 98 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 100 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 102 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 103 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 18 104 A.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 105 A.2. Application Scenarios . . . . . . . . . . . . . . . . . . 18 106 A.2.1. Simplified Data-plane . . . . . . . . . . . . . . . . 18 107 A.2.2. Using MT for P2P Protection . . . . . . . . . . . . . 19 108 A.2.3. Using MT for mLDP Protection . . . . . . . . . . . . . 19 109 A.2.4. Service Separation . . . . . . . . . . . . . . . . . . 19 110 A.2.5. An Alternative inter-AS VPN Solution . . . . . . . . . 20 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 113 1. Terminology 115 This document uses MPLS terminology defined in [RFC5036]. Additional 116 terms are defined below: 118 o MT-ID: A 16 bit value used to represent the Multi-Topology ID. 120 o Default MT Topology: A topology that is built using the MT-ID 121 default value of 0. 123 o MT Topology: A topology that is built using the corresponding 124 MT-ID. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 2. Introduction 132 Multi-Topology (MT) routing is supported in IP networks with the use 133 of MT aware IGP protocols. It would be advantageous for 134 communications Service Providers (CSP) to support Multiple Topologies 135 (MT) within MPLS environments (MPLS-MT). Beneficial MPLS-MT 136 deployment applications include: 138 o A CSP may want to assign varying QoS profiles to traffic, based on 139 a specific MT. 141 o Separate routing and MPLS domains may be used to isolated 142 multicast and IPv6 islands within the backbone network. 144 o Specific IP address space could be routed across an MT based on 145 security or operational isolation requirements. 147 o Low latency links could be assigned to an MT for delay sensitive 148 traffic. 150 o Management traffic could be separated from customer traffic using 151 multiple MTs, where the management traffic MT does not use links 152 that carries customer traffic. 154 This document describes the LDP procedures and protocol extensions 155 required to support MT routing in an MPLS environment. 157 This document also updates RFC4379 by defining two new FEC types for 158 LSP ping. 160 3. Signaling Extensions 162 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) 164 LDP assigns and binds a label to a Forwarding Equivalence Class 165 (FEC), where a FEC is a list of one of more FEC elements. To setup 166 LSPs for unicast IP routing paths, LDP assigns local labels for IP 167 prefixes, and advertises these labels to its peers so that an LSP is 168 setup along the routing path. To setup MT LSPs for IP prefixes under 169 a given topology scope, the LDP "prefix-related" FEC element must be 170 extended to include topology information. This infers that MT-ID 171 becomes an attribute of Prefix-related FEC element, and all FEC-Label 172 binding operations are performed under the context of given topology 173 (MT-ID). 175 The following Subsection 3.2(New Address Families: MT IP) defines the 176 extension required to bind "prefix-related" FEC to a topology. 178 3.2. New Address Families: MT IP 180 The LDP base specification [RFC5036] (Section 4.1) defines the 181 "Prefix" FEC Element as follows: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Prefix (2) | Address Family | PreLen | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Prefix | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: Prefix FEC Element Format [RFC5036] 193 Where "Prefix" encoding is as defined for given "Address Family", and 194 whose length (in bits) is specified by the "PreLen" field. 196 To extend IP address families for MT, two new Address Families named 197 "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes 198 within a topology scope. 200 The format of data associated with these new Address Family is: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | IP Address | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Reserved | MT-ID | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 2: MT IP Address Family Format 212 Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and 213 "MT IPv6" AF respectively, and the field "MT-ID" corresponds to 16- 214 bit Topology ID for given address. 216 Where 16-bit "MT-ID" field defines the Topology ID, and the 217 definition and usage of the rest fields in the FEC Elements are same 218 as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to 219 default topology and MUST be ignored on receipt so as to not cause 220 any conflict/confusion with existing non-MT procedures. 222 The proposed FEC Elements with "MT IP" Address Family can be used in 223 any LDP message and procedures that currently specify and allow the 224 use of FEC Elements with IP/IPv6 Address Family. 226 [Editors Note - RFC[5036] doesn't specify the handling of unknown 227 Address Family. After we have introduced the two new address family 228 here, RFC[5036] need to be updated to add the handling procedure for 229 the unknown address families. 231 3.3. LDP FEC Elements with MT IP AF 233 The following section specifies the format extensions of the existing 234 LDP FEC Elements. The "Address Family" of these FEC elements will be 235 set to "MT IP" or "MT IPv6". 237 The MT Prefix FEC element encoding is as follows: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Prefix | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Reserved | MT-ID | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 3: MT Prefix FEC Element Format 250 Similarly, the MT mLDP FEC elements encoding is as follows, where the 251 mLDP FEC Type can be P2MP(6), MP2MP-up(7), and MP2MP-down(8): 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | mLDP FEC Type | Address Family (MT IP/MT IPv6)| Address Length| 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 ~ Root Node Address ~ 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Reserved | MT-ID | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Opaque Length | Opaque Value ... | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 264 ~ ~ 265 | | 266 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 4: MT mLDP FEC Element Format 272 The MT Typed Wildcard FEC element encoding is as follows: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 |Typed Wcard (5)| FEC Type | Len = 6 | AF = MT IP ..| 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |... or MT IPv6 | MT ID | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 5: MT Typed Wildcard FEC Element 284 3.4. IGP MT-ID Mapping and Translation 286 The non-reserved non-special IGP MT-ID values can be used/carried in 287 LDP as-is and need no translation. However, there is a need for 288 translating reserved/special IGP MT-ID values to corresponding LDP 289 MT-IDs. The corresponding special/reserved LDP MT-ID values are 290 defined in later section 10. 292 3.5. LDP MT Capability Advertisement 294 We specify a new LDP capability, named "Multi-Topology (MT)", which 295 is defined in accordance with LDP Capability definition guidelines 296 [RFC5561]. The LDP "MT" capability can be advertised by an LDP 297 speaker to its peers either during the LDP session initialization or 298 after the LDP session is setup to announce LSR capability to support 299 MTR for the given IP address family. 301 The "MT" capability is specified using "Multi-Topology Capability" 302 TLV. The "Multi-Topology Capability" TLV format is in accordance 303 with LDP capability guidelines as defined in [RFC5561]. To be able 304 to specify IP address family, the capability specific data (i.e. 305 "Capability Data" field of Capability TLV) is populated using "Typed 306 Wildcard FEC Element" as defined in [RFC5918]. 308 The format of "Multi-Topology Capability" TLV is as follows: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 |U|F| Multi-Topology Cap.(IANA) | Length | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |S| Reserved | | 316 +-+-+-+-+-+-+-+-+ | 317 ~ Typed Wildcard FEC element(s) ~ 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 6: Multi-Topology Capability TLV Format 323 o Where: 325 o U- and F-bits: MUST be 1 and 0, respectively, as per Section 3. 326 (Signaling Extensions) of LDP Capabilities [RFC5561]. 328 o Multi-Topology Capability: Capability TLV type (IANA assigned) 330 o S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be 331 set to 0 or 1 in dynamic "Capability" message to advertise or 332 withdraw the capability respectively. 334 o Typed Wildcard FEC element(s): One or more elements specified as 335 the "Capability data". 337 o Length: The length (in octets) of TLV. 339 o The encoding of Typed Wildcard FEC element, as defined in 340 [RFC5561], is defined in the section 4.1 (Typed Wildcard FEC 341 Element) of this document. 343 3.6. Procedures 345 To announce its MT capability for an IP address family, LDP FEC type, 346 and Multi Topology, an LDP speaker MAY send an "MT Capability" 347 including the exact Typed Wildcard FEC element with corresponding 348 "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT 349 IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., 350 set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To 351 announce its MT capability for both IPv4 and IPv6 address family, or 352 for multiple FEC types, or for multiple Multi Topologies, an LDP 353 speaker MAY send "MT Capability" with one or more MT Typed FEC 354 elements in it. 356 o The capability for supporting multi-topology in LDP can be 357 advertised during LDP session initialization stage by including 358 the LDP MT capability TLV in LDP Initialization message. After an 359 LDP session is established, the MT capability can also be 360 advertised or withdrawn using Capability message (only if "Dynamic 361 Announcement" capability [RFC5561] has already been successfully 362 negotiated). 364 o If an LSR has not advertised MT capability, its peer must not send 365 messages that include MT identifier to this LSR. 367 o If an LSR receives a Label Mapping message with an MT parameter 368 from downstream LSR-D and its upstream LSR-U has not advertised MT 369 capability, an LSP for the MT will not be established. 371 o This document proposes to add a new notification event to signal 372 the upstream that the downstream is not capable. 374 o If an LSR is changed from non-MT capable to MT capable, it sets 375 the S bit in MT capability TLV and advertises via the Capability 376 message. The existing LSP is treated as LSP for default MT (ID 377 0). 379 o If an LSR is changed from LDP-MT capable to non-MT capable, it may 380 initiate withdraw of all label mapping for existing LSPs of all 381 non-default MTs. Then it clears the S bit in MT capability TLV 382 and advertises via the Capability message. 384 o If an LSR is changed from IGP-MT capable to non-MT capable, it may 385 wait until the routes update to withdraw FEC and release the label 386 mapping for existing LSPs of specific MT. 388 3.7. LDP Sessions 390 If a single global label space is supported, there will be an LDP 391 session supported for each pair of peers, regardless of the number of 392 MTs supported between peers. If there are different label spaces 393 supported for different topologies, which means that label spaces 394 overlap with each other for different MTs, then it is recommended to 395 establish multiple sessions for multiple topologies between these two 396 peers. In this case, multiple LSR-IDs will need to be allocated so 397 that each multiple topology can have its own label space ID. 399 3.8. Reserved MT ID Values 401 Certain MT topologies are assigned to serve predetermined purposes: 403 Default-MT: Default topology. This corresponds to OSPF default IPv4 404 and IPv6, as well as ISIS default IPv4. A value of 0 is proposed. 406 ISIS IPv6 MT: ISIS default MT-ID for IPv6. 408 Wildcard-MT: This corresponds to All-Topologies. A value of 65535 409 (0xffff) is proposed. 411 In Section 9. (IANA Considerations) this document proposes a new 412 IANA registry "LDP Multi-Topology ID Name Space" under IANA "LDP 413 Parameter" namespace to keep an LDP MT-ID reserved value. 415 If an LSR receives a FEC element with an "MT-ID" value that is 416 "Reserved" for future use (and not IANA allocated yet), the LSR must 417 abort the processing of the FEC element, and SHOULD send a 418 notification message with status code "Invalid MT-ID" to the sender. 420 4. MT Applicability on FEC-based features 422 4.1. Typed Wildcard FEC Element 424 [RFC5918] extends base LDP and defines Typed Wildcard FEC Element 425 framework. Typed Wildcard FEC element can be used in any LDP message 426 to specify a wildcard operation/action for given type of FEC. 428 The MT extensions proposed in document do not require any extension 429 in procedures for Typed Wildcard FEC element, and these procedures 430 apply as-is to MT wildcarding. The MT extensions, though, allow use 431 of "MT IP" or "MT IPv6" in the Address Family field of the Typed 432 Wildcard FEC element in order to use wildcard operations in the 433 context of a given topology. The use of MT-scoped address family 434 also allows us to specify MT-ID in these operations. 436 The proposed format in Section 4.1 (Typed Wildcard FEC Element) 437 allows an LSR to perform wildcard FEC operations under the scope of a 438 topology. If an LSR wishes to perform wildcard operation that 439 applies to all topologies, it can use a "Wildcard Topology" MT-ID. 440 For example, upon local configuration of topology "x", an LSR may 441 send a wildcard label withdraw request with MT-ID "x" to withdraw all 442 its labels from the peer that advertized under the scope of topology 443 "x". Additionally, upon a global configuration change, an LSR may 444 send a wildcard label withdraw with the MT-ID set to "Wildcard 445 Topology" to withdraw all its labels under all topologies from the 446 peer. 448 4.2. End-of-LIB 450 [RFC5919] specifies extensions and procedures for an LDP speaker to 451 signal its convergence for a given FEC type towards a peer. The 452 procedures defined in [RFC5919] applies as-is to an MT FEC element. 453 This MAY allow an LDP speaker to signal its IP convergence using 454 Typed Wildcard FEC element, and its MT IP convergence per topology 455 using a MT Typed Wildcard FEC element. 457 4.3. LSP Ping 459 [RFC4379] defines procedures to detect data-plane failures in MPLS 460 LSPs via LSP ping. The specification defines a "Target FEC Stack" 461 TLV that describes the FEC stack being tested. This TLV is sent in 462 an MPLS echo request message towards LSPs egress LSR, and is 463 forwarded along the same data path as other packets belonging to the 464 FEC. 466 "Target FEC Stack" TLV contains one or more sub-TLVs pertaining to 467 different FEC types. Section 3.2 of [RFC-4379] defines Sub-Types and 468 format for the FEC. To support LSP ping for MT LDP LSPs, this 469 document proposes following extensions to [RFC-4379]. 471 4.3.1. New FEC Sub-Types 473 We define two new FEC types for LSP ping: 475 o MT LDP IPv4 FEC 477 o MT LDP IPv6 FEC 479 We also define following new sub-types for sub-TLVs to specify these 480 FECs in the "Target FEC Stack" TLV of [RFC-4379]: 482 Sub-Type Length Value Field 483 -------- ------ ----------------- 484 TBA5 5 MT LDP IPv4 prefix 485 TBA6 17 MT LDP IPv6 prefix 487 Figure 7: new sub-types for sub-TLVs 489 The rules and procedures of using these sub-TLVs in an MPLS echo 490 request message are same as defined for LDP IPv4/IPv6 FEC sub-TLV 491 types in [RFC-4379]. 493 4.3.2. MT LDP IPv4 FEC Sub-TLV 495 The format of "MT LDP IPv4 FEC" sub-TLV to be used in a "Target FEC 496 Stack" [RFC4379] is: 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type = TBA5(MT LDP IPv4 FEC) | Length = 8 | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | IPv4 prefix | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Prefix Length | MBZ | MT-ID | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 8: MT LDP IPv4 FEC sub-TLV 510 The format of this sub-TLV is similar to LDP IPv4 FEC sub-TLV as 511 defined in [RFC-4379]. In addition to "IPv4 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 5. 515 4.3.3. MT LDP IPv6 FEC Sub-TLV 517 The format of "MT LDP IPv6 FEC" sub-TLV to be used in a "Target FEC 518 Stack" [RFC4379] is: 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Type = TBA6(MT LDP IPv6 FEC) | Length = 20 | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | | 526 | IPv6 prefix | 527 | | 528 | | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Prefix Length | MBZ | MT-ID | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 9: MT LDP IPv6 FEC sub-TLV 535 The format of this sub-TLV is similar to LDP IPv6 FEC sub-TLV as 536 defined in [RFC-4379]. In addition to "IPv6 prefix" and "Prefix 537 Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology 538 ID). The Length for this sub-TLV is 17. 540 4.3.4. Operation Considerations 542 When detect data-plane failures using LSP Ping for a specific topoly, 543 the router will intiate an LSP Ping request with the targer FEC stack 544 TLV containing LDP MT IP Prefix Sub-TLV in the Echo Request packet. 545 The Echo Request packet is sent with the label binded to the IP 546 Prefix in the topolgy. Once the echo request packet reaches the 547 target router, it will process the packet and perform checs for the 548 LDP MT IP Prefix sub-TLV present in the Target FEC Stack as described 549 in [RFC4379] and respond according to [RFC4379] processing rules. 550 For the case that the LSP ping with return path not specified , the 551 reply packet may go through the default topology instead of the 552 topology where the Echol Request goes through. 554 5. Error Handling 556 The extensions defined in this document utilise the existing LDP 557 error handling defined in [RFC5036]. If an LSR receives an error 558 notification from a peer for an MPLS-MT session, it terminates the 559 LDP session by closing the TCP transport connection for the session 560 and discarding all MT-ID label mappings learned via the session. 562 5.1. MT Error Notification for Invalid Topology ID 564 If an LSR has advertized an MT Capability TLV using the 565 Initialization message or Capability message, which includes Typed 566 Wildcard FEC elements with specific MT-IDs, and it receives an MT 567 message with a MT-ID which is not included in the supported list, it 568 should response this "Invalid Topology ID" status code. 570 6. Backwards Compatibility 572 The MPLS-MT solution is backwards compatible with existing LDP 573 enhancements defined in [RFC5036], including message authenticity, 574 integrity of message, and topology loop detection. 576 7. MPLS Forwarding in MT 578 Although forwarding is out of the scope of this draft, we include 579 some forwarding consideration for informational purpose here. 581 The specified signaling mechanisms allow all the topologies to share 582 the platform-specific label space; this is the feature that allows 583 the existing data plane techniques to be used; and the specified 584 signaling mechanisms do not provide any way for the data plane to 585 associate a given packet with a context-specific label space. 587 8. Security Consideration 589 No specific security issues with the proposed solutions are known. 590 The proposed extensions in this document do not introduce any new 591 security considerations beyond that already apply to the base LDP 592 specification [RFC5036] and [RFC5920]. 594 9. IANA Considerations 596 The document introduces following new protocol elements that require 597 IANA consideration and assignments: 599 o New LDP Capability TLV: "Multi-Topology Capability" TLV (requested 600 code point: TBA1 from LDP registry "TLV Type Name Space"). 602 o New Status Code: "Multi-Topology Capability not supported" 603 (requested code point: TBA2 from LDP registry "Status Code Name 604 Space"). 606 o New Status Code: "Invalid Topology ID" (requested code point: TBA3 607 from LDP registry "Status Code Name Space"). 609 o New Status Code: "Unknown Address Family" (requested code point: 610 TBA4 from LDP registry "Status Code Name Space"). 612 Registry: 613 Range/Value E Description 614 -------------- --- ------------------------------ 615 0x00000051 1 Invalid Topology ID 617 Figure 10: New Status Codes for LDP Multi Topology Extensions 619 o New address families under IANA registry "Address Family Numbers": 621 - MT IP: Multi-Topology IP version 4 (requested codepoint: 26) 622 - MT IPv6: Multi-Topology IP version 6 (requested codepoint: 27) 624 Figure 11: Address Family Numbers 626 o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP 627 Parameter" namespace. The registry is defined as: 629 Range/Value Name 630 ----------- ------------------------ 631 0 Default Topology (ISIS and OSPF) 632 1-4095 Unassigned 633 4096 ISIS IPv6 routing topology 634 (i.e. ISIS MT ID #2) 635 4097-65534 Reserved (for future allocation) 636 65535 Wildcard Topology (ISIS or OSPF) 638 Figure 12: LDP Multi-Topology (MT) ID Name Space 640 o New Sub-TLV Types for LSP ping: Following new sub-type values 641 under TLV type 1 (Target FEC Stack) from "Multi-Protocol Label 642 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 643 registry, and "TLVs and sub-TLVs" sub-registry. 645 Sub-Type Value Field 646 -------- ----------- 647 TBA5 MT LDP IPv4 prefix 648 TBA6 MT LDP IPv6 prefix 650 Figure 13: New Sub-TLV Types for LSP ping 652 10. Contributors 654 Ning So 655 Tata Communications 656 2613 Fairbourne Cir. 657 Plano, TX 75082 658 USA 660 Email: ning.so@tatacommunications.com 662 Raveendra Torvi 663 Juniper Networks 664 10, Technoogy Park Drive 665 Westford, MA 01886-3140 666 US 668 Email: rtorvi@juniper.net 670 Huaimo Chen 671 Huawei Technology 672 125 Nagog Technology Park 673 Acton, MA 01719 674 US 676 Email: huaimochen@huawei.com 678 Emily Chen 679 2717 Seville Blvd, Apt 1205, 680 Clearwater, FL 33764 681 US 683 Email: emily.chen220@gmail.com 685 Chen Li 686 China Mobile 687 53A, Xibianmennei Ave. 688 Xunwu District, Beijing 01719 689 China 691 Email: lichenyj@chinamobile.com 693 Lu Huang 694 China Mobile 695 53A, Xibianmennei Ave. 696 Xunwu District, Beijing 01719 697 China 699 Email: huanglu@chinamobile.com 700 Daniel King 701 Old Dog Consulting 703 Email: E-mail: daniel@olddog.co.uk 705 Zhenbin Li 706 Huawei Technology 707 2330 Central Expressway 708 Santa Clara, CA 95050 709 US 711 Email: zhenbin.li@huawei.com 713 11. Acknowledgement 715 The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin, 716 Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun Chai and 717 pranjal Dutta, George Swallow and Curtis Villamizar for their 718 valuable comments on this draft. 720 12. References 722 12.1. Normative References 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", BCP 14, RFC 2119, March 1997. 727 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 728 Considered Useful", BCP 82, RFC 3692, January 2004. 730 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 731 Specification", RFC 5036, October 2007. 733 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 734 "Signaling LDP Label Advertisement Completion", RFC 5919, 735 August 2010. 737 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 738 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 739 (FEC)", RFC 5918, August 2010. 741 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 742 "Label Distribution Protocol Extensions for Point-to- 743 Multipoint and Multipoint-to-Multipoint Label Switched 744 Paths", RFC 6388, November 2011. 746 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 747 Label Switched (MPLS) Data Plane Failures", RFC 4379, 748 February 2006. 750 12.2. Informative References 752 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 753 Networks", RFC 5920, July 2010. 755 [IANA-LSPV] 756 Multi-Protocol Label Switching (MPLS) Label Switched Paths 757 (LSPs) Ping Parameters, "http://www.iana.org/assignments/ 758 mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml". 760 Authors' Addresses 762 Quintin Zhao 763 Huawei Technology 764 125 Nagog Technology Park 765 Acton, MA 01719 766 US 768 Email: quintin.zhao@huawei.com 770 Luyuan Fang 771 Cisco Systems 772 300 Beaver Brook Road 773 Boxborough, MA 01719 774 US 776 Email: lufang@cisco.com 778 Chao Zhou 779 Cisco Systems 780 300 Beaver Brook Road 781 Boxborough, MA 01719 782 US 784 Email: czhou@cisco.com 785 Lianyuan Li 786 China Mobile 787 53A, Xibianmennei Ave. 788 Xunwu District, Beijing 01719 789 China 791 Email: lilianyuan@chinamobile.com 793 Kamran Raza 794 Cisco Systems 795 2000 Innovation Drive 796 Kanata, ON K2K-3E8, MA 797 Canada 799 Email: E-mail: skraza@cisco.com