idnits 2.17.1 draft-ietf-mpls-ldp-multi-topology-02.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 8 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 date (November 21, 2011) is 4540 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) == Missing Reference: 'IP-FRR-MT' is mentioned on line 223, but not defined -- Looks like a reference, but probably isn't: '5036' on line 357 == Missing Reference: 'RFC5561' is mentioned on line 450, but not defined == Unused Reference: 'RFC3692' is defined on line 634, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 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: May 24, 2012 C. Zhou 6 Cisco Systems 7 L. Li 8 China Mobile 9 N. So 10 Verizon Business 11 R. Torvi 12 Juniper Networks 13 November 21, 2011 15 LDP Extensions for Multi Topology Routing 16 draft-ietf-mpls-ldp-multi-topology-02.txt 18 Abstract 20 Multi-Topology (MT) routing is supported in IP through extension of 21 IGP protocols, such as OSPF and IS-IS. It would be advantageous to 22 extend Multiprotocol Label Switching (MPLS), using Label Distribution 23 Protocol (LDP), to support multiple topologies. These LDP 24 extensions, known as Multiple Topology Label Distribution Protocol 25 (MT LDP), would allow the configuration of multiple topologies within 26 an MPLS LDP enabled network. 28 This document describes the protocol extensions required to extend 29 the existing MPLS LDP signalling protocol for creating and 30 maintaining LSPs in an MT environment. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 24, 2012. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Application Scenarios . . . . . . . . . . . . . . . . . . 6 71 3.1.1. Simplified Data-plane . . . . . . . . . . . . . . . . 6 72 3.1.2. Using MT for p2p Protection . . . . . . . . . . . . . 6 73 3.1.3. Using MT for mLDP Protection . . . . . . . . . . . . . 7 74 3.1.4. Service Separation . . . . . . . . . . . . . . . . . . 7 75 3.1.5. An Alternative inter-AS VPN Solution . . . . . . . . . 7 76 3.2. Signaling Extensions . . . . . . . . . . . . . . . . . . . 7 77 3.2.1. Topology-Scoped Prefix FEC . . . . . . . . . . . . . . 7 78 3.2.2. LDP MT Capability Advertisement . . . . . . . . . . . 9 79 3.2.3. Procedures . . . . . . . . . . . . . . . . . . . . . . 11 80 3.2.4. LDP Sessions . . . . . . . . . . . . . . . . . . . . . 12 81 3.2.5. Reserved MT ID Values . . . . . . . . . . . . . . . . 12 82 3.3. MT Applicability on FEC-based features . . . . . . . . . . 13 83 3.3.1. Typed Wildcard Prefix FEC Element . . . . . . . . . . 13 84 3.3.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . 13 85 3.4. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . 14 86 3.5. Security Consideration . . . . . . . . . . . . . . . . . . 14 87 3.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 14 88 3.7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 15 89 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 4.1. Normative References . . . . . . . . . . . . . . . . . . . 15 91 4.2. Informative References . . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Terminology 96 Terminology used in this document 98 MT-ID: A 12 bit value to represent Multi-Topology ID. 100 Default Topology: A topology that is built using the MT-ID value 101 0. 103 MT topology: A topology that is built using the corresponding 104 MT-ID. 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Introduction 114 There are increasing requirements to support multi-topology in MPLS 115 network. For example, service providers may want to assign different 116 level of service(s) to different topologies so that the service 117 separation can be achieved. It is also possible to have an in-band 118 management network on top of the original MPLS topology, or maintain 119 separate routing and MPLS domains for isolated multicast or IPv6 120 islands within the backbone, or force a subset of an address space to 121 follow a different MPLS topology for the purpose of security, QoS, or 122 simplified management and/or operations. 124 OSPF and IS-IS use MT-ID (Multi-Topology Identifier) to identify 125 different topologies. For each topology identified by an MT-ID, IGP 126 computes a separate SPF tree independently to find the best paths to 127 the IP prefixes associated with this topology. 129 For IP Prefix FECs that are associated with a specific topology, this 130 solution utilizes the use of MT-ID of the topology in LDP. Thus the 131 LSP for the given Prefix FEC may be created and maintained along the 132 IGP path in this topology if it is needed. 134 Maintaining multiple MTs for MPLS network in a backwards-compatible 135 manner requires several extensions to the label signaling encoding 136 and processing procedures. When a label is associated with an IP 137 Prefix FEC, the corresponding FEC element includes both the 138 destination prefix (IP address) and the topology it belongs to. 140 MT based MPLS in general can be used for a variety of purposes such 141 as service separation by assigning each service or a group of 142 services to a topology, where the management, QoS, and security of 143 the service or the group of the services can be simplified and 144 guaranteed, in-band management network "on top" of the original MPLS 145 topology, maintain separate routing and MPLS forwarding domains for 146 isolated multicast or IPv6 islands within the backbone, or force a 147 subset of an address space to follow a different MPLS topology for 148 the purpose of security, QoS or simplified management and/or 149 operations. 151 One of the use of the MT based MPLS is where one class of data 152 requires low latency links, for example Voice over IP (VoIP) data. 153 As a result such data may be sent preferably via physical landlines 154 rather than, for example, high latency links such as satellite links. 155 As a result an additional topology is defined as all low latency 156 links on the network and VoIP data packets are assigned to the 157 additional topology. Further possible examples are File Transfer 158 Protocol (FTP) or Simple Mail Transfer Protocol (SMTP) traffic which 159 can be assigned to additional topology comprising high latency links, 160 and Internet Protocol version 4 (IPv4) versus Internet Protocol 161 version 6 (IPv6) traffic which may be assigned to different topology 162 or data to be distinguished by the Quality of Service (QoS) assigned 163 to it. 165 3. Requirements 167 MPLS-MT may be used for a variety of purposes such as service 168 separation by assigning each service or a group of services to a 169 topology, where the management, QoS and security of the service or 170 the group of the services can be simplified and guaranteed, in-band 171 management network "on top" of the original MPLS topology, maintain 172 separate routing and MPLS forwarding domains for isolated multicast 173 or IPv6 islands within the backbone, or force a subset of an address 174 space to follow a different MPLS topology for the purpose of 175 security, QoS or simplified management and/or operations. 177 The following specific requirements and objectives have been defined 178 in order to provide the functionality described above, and facilitate 179 service provider configuration and operation. 181 o Deployment of MPLS-MT within existing MPLS networks should be 182 possible, with MPLS-MT non-capable nodes existing with MPLS-MT 183 capable nodes. 185 o Minimise configuration and operation complexity of MPLS-MT across 186 the network. 188 o The MPLS-MT solution SHOULD NOT require data-plane modification. 190 o The MPLS-MT solution MUST support multiple topologies. Allowing a 191 an MPLS LSP to be established across a specific, or set of, 192 multiple topologies. 194 o Control and filtering of LSPs using explicitly including or 195 excluding multiple topologies MUST be supported. 197 o The MPLS-MT solution MUST be capable of supporting QoS mechanisms. 199 [Editors Note - We expect these base MPLS-MT protocol requirements to 200 be evolved over the next few versions of this document. Note that 201 all Editors notes will be deleted before publication of the document] 203 3.1. Application Scenarios 205 3.1.1. Simplified Data-plane 207 IGP-MT requires additional data-plane resources maintain multiple 208 forwarding for each configured MT. On the other hand, MPLS-MT does 209 not change the data-plane system architecture, if an IGP-MT is mapped 210 to an MPLS-MT. In case MPLS-MT, incoming label value itself can 211 determine an MT, and hence it requires a single NHLFE space. MPLS-MT 212 requires only MT-RIBs in the control-plane, no need to have MT-FIBs. 213 Forwarding IP packets over a particular MT requires either 214 configuration or some external means at every node, to maps an 215 attribute of incoming IP packet header to IGP-MT, which is additional 216 overhead for network management. Whereas, MPLS-MT mapping is 217 required only at the ingress-PE of an MPLS-MT LSP, because of each 218 node identifies MPLS-MT LSP switching based on incoming label, hence 219 no additional configuration is required at every node. 221 3.1.2. Using MT for p2p Protection 223 We know that [IP-FRR-MT] can be used for configuring alternate path 224 via backup-mt, such that if primary link fails, then backup-MT can be 225 used for forwarding. However, such techniques require special 226 marking of IP packets that needs to be forwarded using backup-MT. 227 MPLS-LDP-MT procedures simplify the forwarding of the MPLS packets 228 over backup-MT, as MPLS-LDP-MT procedure distribute separate labels 229 for each MT. How backup paths are computed depends on the 230 implementation, and the algorithm. The MPLS-LDP-MT in conjunction 231 with IGP-MT could be used to separate the primary traffic and backup 232 traffic. For example, service providers can create a backup MT that 233 consists of links that are meant only for backup traffic. Service 234 providers can then establish bypass LSPs, standby LSPs, using backup 235 MT, thus keeping undeterministic backup traffic away from the primary 236 traffic. 238 3.1.3. Using MT for mLDP Protection 240 Fro the P2mP or MP2MP LSPs setup by using mLDP protocol, there is a 241 need to setup a backup LSP to have an end to end protection for the 242 priamry LSP in the appplicaitons such IPTV, where the end to end 243 protection is a must. Since the mLDP lSp is setup following the IGP 244 routes, the second LSP setup by following the IGP routes can not be 245 guranteed to have the link and node diversity from the primary LSP. 246 By using MPLS-LDP-MT, two topology can be configured with complete 247 link and node diversity, where the primary and secondary LSP can be 248 set up independantly within each topology. The two LSPs setup by 249 this mechanism can protect each other end-to-end. 251 3.1.4. Service Separation 253 MPLS-MT procedures allow establishing two distinct LSPs for the same 254 FEC, by advertising separate label mapping for each configured 255 topology. Service providers can implement CoS using MPLS-MT 256 procedures without requiring to create separate FEC address for each 257 class. MPLS-MT can also be used separate multicast and unicast 258 traffic. 260 3.1.5. An Alternative inter-AS VPN Solution 262 When the lsp is crossing multiple domains for the inter-as VPN 263 scenarios, the LSP setup process can be done by configuring a set of 264 routers which are in different domains into a new single domain with 265 a new topology ID using the LDP multiple topology. All the routers 266 belong this new topology will be used to carry the traffic across 267 multiple domains and since they are in a single domain with the new 268 topology ID, so the LDP lsp set up can be done without propagating 269 VPN routes across AS boundaries. 271 3.2. Signaling Extensions 273 3.2.1. Topology-Scoped Prefix FEC 275 LDP assigns and binds a label to a FEC, where a FEC is a list of one 276 of more FEC elements. To setup LSPs for unicast IP routing paths, 277 LDP assigns local labels for IP prefixes, and advertises these labels 278 to its peers so that an LSP is setup along the routing path. To 279 setup Multi-Topology LSPs for IP prefixes under a given topology 280 scope, it is a natural requirement to extend LDP "Prefix" FEC element 281 to include topology info. This infers that MT-ID becomes an 282 attribute of Prefix FEC element, and all FEC-Label binding operations 283 are performed under the context of given topology (MT-ID). Following 284 subsection proposes the extension to bind "Prefix FEC" to a topology. 286 3.2.1.1. New Address Families: MT IP 288 LDP base specification [RFC5036] (section 3.4.1) defines the "Prefix" 289 FEC Element 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 | Prefix (2) | Address Family | PreLen | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Prefix | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 1: Prefix FEC Element Format [RFC5036] 301 Where "Prefix" encoding is as defined for given "Address Family", and 302 whose length (in bits) is specified by the "PreLen" field. 304 To extend IP address families for MT, we propose two new Address 305 Families named "MT IP" and "MT IPv6" that can be used to specify IP 306 prefixes within a topology scope. The format of data associated with 307 these new Address Family is: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | (IP) Prefix | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Reserved | MT-ID | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 2: MT IP Address Family Format 319 Where "(IP) Prefix" is an IPv4 and IPv6 address/prefix for "MT IP" 320 and "MT IPv6" AF respectively, and the field "MT-ID" corresponds to 321 16-bit Topology ID for given prefix. 323 For MT LDP, the "Prefix" FEC element's "Address Family" will be set 324 to "MT IP" or "MT IPv6", and the FEC element will be encoded as 325 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 | Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Prefix | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Reserved | MT-ID | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 3: MT Prefix FEC Element Format 339 Where 16-bit "MT-ID" field defines the Topology ID, and the 340 definition and usage of "Prefix" and "PreLen" field is same as 341 defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to default 342 topology and MUST be ignored on receipt so as to not cause any 343 conflict/confusion with existing non-MT procedures. 345 The proposed "Prefix FEC Element" with "MT IP" Address Family can be 346 used in any LDP message and procedures that currently specify and 347 allow the use of "Prefix FEC" element with IP/IPv6 Address Family. 349 This document does not limit the use of these new AF only to LDP 350 "Prefix FEC element", and these can be used in other FECs and 351 signaling as required. For example, mLDP MP FECs, as specified in 352 [mLDP], can be extended to use these new address families to make MP 353 FECs to become MT aware. 355 [Editors Note - RFC[5036] doesn't specify the handling of unknown 356 Address Family. After we have introduced the two new address family 357 here, RFC[5036] need to be updated to add the handling procedure for 358 the unknow address families. 360 3.2.1.2. IGP MT-ID Mapping and Translation 362 The non-reserved non-special IGP MT-ID values can be used/carried in 363 LDP as-is and need no translation. However, there is a need for 364 translating reserved/special IGP MT-ID values to corresponding LDP 365 MT-IDs. The corresponding special/reserved LDP MT-ID values are 366 defined in later section 9. 368 3.2.2. LDP MT Capability Advertisement 370 We specify a new LDP capability, named "Multi-Topology (MT)", which 371 is defined in accordance with LDP Capability definition guidelines 372 [RFC5561]. The LDP "MT" capability can be advertised by an LDP 373 speaker to its peers either during the LDP session initialization or 374 after the LDP session is setup to announce LSR capability to support 375 MTR for given IP address family. 377 The "MT" capability is specified using "Multi-Topology Capability" 378 TLV. The "Multi-Topology Capability" TLV format is in accordance 379 with LDP capability guidelines as defined in [RFC5561]. To be able 380 to specify IP address family, the capability specific data (i.e. 381 "Capability Data" field of Capability TLV) is populated using "Typed 382 Wildcard Prefix FEC Element" as defined in [RFC5918]. 384 The format of "Multi-Topology Capability" TLV is as follows: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 |U|F| Multi-Topology Cap.(IANA) | Length | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 |S| Reserved | | 392 +-+-+-+-+-+-+-+-+ | 393 ~ Typed Wcard Prefix FEC element(s) ~ 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 4: Multi-Topology Capability TLV Format 399 Where: 401 U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of LDP 402 Capabilities [RFC5561]. 404 Multi-Topology Capability: Capability TLV type (IANA assigned) 406 S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be set 407 to 0 or 1 in dynamic "Capability" message to advertise or withdraw 408 the capability respectively. 410 Typed Wcard Prefix FEC element(s): One or two elements specified as 411 the "Capability data". 413 Length: The length (in octets) of TLV. The value of this field MUST 414 be 6 with one FEC element specification, and 11 for two FEC element 415 specifications. 417 The encoding of Typed Wcard Prefix FEC element, as defined in 418 [RFC5561], is as follows: 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |Typed Wcard (5)|Type=Prefix (2)| Len = 2 | Address... | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | ...Family | 426 +-+-+-+-+-+-+-+-+ 428 Figure 5: Typed Wildcard Prefix FEC Element [RFC5561] 430 Where: 432 Address Family: MUST be set to "MT IP" or "MT IPv6" 434 3.2.3. Procedures 436 To announce its MT capability for given IP address family, an LDP 437 speaker MAY send "MT Capability" with exactly one Typed Wildcard 438 Prefix FEC element with corresponding "Address Family" field (i.e. 439 set to "MT IP" for IPv4 and set to "MT IPv6" for IPv6 address 440 family). To announce its MT capability for both IPv4 and IPv6 441 address family, an LDP speaker MAY send "MT Capability" with two 442 Typed Prefix FEC elements in it, where Address Family is set to "MT 443 IP" in one element and set to "MT IPv6" in other element. 445 o The capability for supporting multi-topology in LDP can be 446 advertised during LDP session initialization stage by including 447 the LDP MT capability TLV in LDP Initialization message. After 448 LDP session is established, the MT capability can also be 449 advertised or withdrawn using Capability message (only if "Dynamic 450 Announcement" capability [RFC5561] has already been successfully 451 negotiated). 453 o If an LSR has not advertised MT capability, its peer must not send 454 messages that include MT identifier to this LSR. 456 o If an LSR receives a Label Mapping message with MT parameter from 457 downstream LSR-D and its upstream LSR-U has not advertised MT 458 capability, an LSP for the MT will not be established. 460 o We propose to add a new notification event to signal the upstream 461 that the downstream is not capable. 463 o If an LSR is changed from non-MT capable to MT capable, it sets 464 the S bit in MT capability TLV and advertises via the Capability 465 message. The existing LSP is treated as LSP for default MT (ID 466 0). 468 o If an LSR is changed from MT capable to non-MT capable, it may 469 initiate withdraw of all label mapping for existing LSPs of all 470 non-default MTs. Alternatively, it may wait until the routing 471 update to withdraw FEC and release the label mapping for existing 472 LSPs of specific MT. 474 o There will be case where IGP is MT capable but MPLS is not and the 475 handling procedure for this case is TBD. 477 3.2.4. LDP Sessions 479 Depending on the number of label spaces supported, if a single global 480 label space is supported, there will be one session supported for 481 each pair of peer, even there are multiple topologies supported 482 between these two peers. If there are different label spaces 483 supported for different topologies, which means that label spaces 484 overlap with each other for different MTs, then it is suggested to 485 establish multiple sessions for multiple topologies between these two 486 peers. In this case, multiple LSR-IDs need to be allocated 487 beforehand so that each multiple topology can have its own label 488 space ID. 490 [Editors Note - This section requires further discussion] 492 3.2.5. Reserved MT ID Values 494 Certain MT topologies are assigned to serve pre-determined purposes: 496 Default-MT: Default topology. This corresponds to OSPF default IPv4 497 and IPv6, as well as ISIS default IPv4. A value of 0 is proposed. 499 ISIS IPv6 MT: ISIS default MT-ID for IPv6. 501 Wildcard-MT: This corresponds to All-Topologies. A value of 65535 502 (0xffff) is proposed. 504 We propose a new IANA registry "LDP Multi-Topology ID Name Space" 505 under IANA "LDP Parameter" namespace to keep LDP MT-ID reserved 506 value. 508 If an LSR receives a FEC element with an "MT-ID" value that is 509 "Reserved" for future use (and not IANA allocated yet), the LSR must 510 abort the processing of the FEC element, and SHOULD send a 511 notification message with status code "Invalid MT-ID" to the sender. 513 [Editors Note - This section requires further discussion]. 515 3.3. MT Applicability on FEC-based features 517 3.3.1. Typed Wildcard Prefix FEC Element 519 RFC-5918 extends base LDP and defines Typed Wildcard FEC Element 520 framework [RFC5918]. Typed Wildcard FEC element can be used in any 521 LDP message to specify a wildcard operation/action for given type of 522 FEC. 524 The MT extensions proposed in document do not require any extension 525 in procedures for Typed Wildcard Prefix FEC element, and these 526 procedures apply as-is to MT Prefix wildcarding. The MT extensions, 527 though, allow use of "MT IP" or "MT IPv6" in the Address Family field 528 of the Typed Wildcard Prefix FEC element in order to use wildcard 529 operations in the context of a given topology. The use of MT-scoped 530 address family also allows us to specify MT-ID in these operations. 532 This document extends Typed Wildcard Prefix FEC element encoding for 533 MT is as follows: 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 |Typed Wcard (5)|Type=Prefix (2)| Len = 4 | AF = MT IP ..| 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 |... or MT IPv6 | MT-ID | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Figure 6: Typed Wildcard Prefix FEC Element for MT 545 The proposed format allows an LSR to perform wildcard FEC operations 546 under the scope of a topology. If an LSR wishes to perform wildcard 547 operation that applies to all topologies, it can use "Wildcard 548 Topology" MT-ID as defined in section 5.4. For instance, upon local 549 un-configuration of topology "x", an LSR may send wildcard label 550 withdraw with MT-ID "x" to withdraw all its labels from peer that 551 were advertised under the scope of topology "x". On the other hand, 552 upon some global configuration change, an LSR may send wildcard label 553 withdraw with MT-ID set to "Wildcard Topology" to withdraw all its 554 labels under all topologies from the peer. 556 3.3.2. End-of-LIB 558 [RFC5919] specifies extensions and procedures for an LDP speaker to 559 signal its convergence for given FEC type towards a peer. The 560 procedures defined in [RFC5919] apply as-is to MT Prefix FEC element. 561 This means that an LDP speaker MAY signal its IP convergence using 562 Typed Wildcard Prefix FEC element, and its MT IP convergence per 563 topology using MT Typed Wildcard Prefix FEC element (as defined in 564 earlier section). 566 3.4. MPLS Forwarding in MT 568 Although forwarding is out of the scope of this draft, we include 569 some forwarding consideration for informational purpose here. 571 The specified signaling mechanisms allow all the topologies to share 572 the platform-specific label space; this is the feature that allows 573 the existing data plane techniques to be used; and the specified 574 signaling mechanisms do not provide any way for the data plane to 575 associate a given packet with a context-specific label space. 577 3.5. Security Consideration 579 No specific security issues with the proposed solutions are known. 580 The proposed extension in this document does not introduce any new 581 security considerations beyond that already apply to the base LDP 582 specification [RFC5036] and [RFC5920]. 584 3.6. IANA Considerations 586 The document introduces following new protocol elements that require 587 IANA consideration and assignments: 589 o New LDP Capability TLV: "Multi-Topology Capability" TLV (requested 590 code point: 0x510 from LDP registry "TLV Type Name Space"). 592 o New Status Code: "Invalid Topology ID" (requested code point: 0x50 593 from LDP registry "Status Code Name Space") as follows: 595 Registry: 596 Range/Value E Description 597 -------------- --- ------------------------------ 598 0x00000050 0 Invalid MT-ID 600 Figure 7: Invalid Topology ID 602 o New address families under IANA registry "Address Family Numbers": 604 - MT IP: Multi-Topology IP version 4 (requested codepoint: 26) 605 - MT IPv6: Multi-Topology IP version 6 (requested codepoint: 27) 607 Figure 8: Address Family Numbers 609 o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP 610 Parameter" namespace. The registry is defined as: 612 Range/Value Name 613 ----------- ------------------------ 614 0 Default Topology (ISIS and OSPF) 615 1-4095 Unassigned 616 4096 ISIS IPv6 routing topology (i.e. ISIS MT ID #2) 617 4097-65534 Reserved (for future allocation) 618 65535 Wildcard Topology (ISIS or OSPF) 620 Figure 9: LDP Multi-Topology (MT) ID Name Space 622 3.7. Acknowledgement 624 The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin, 625 Daniel King and Eric Rosen for their valuable comments on this draft. 627 4. References 629 4.1. Normative References 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, March 1997. 634 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 635 Considered Useful", BCP 82, RFC 3692, January 2004. 637 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 638 Specification", RFC 5036, October 2007. 640 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, 641 "Signaling LDP Label Advertisement Completion", RFC 5919, 642 August 2010. 644 [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution 645 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class 646 (FEC)", RFC 5918, August 2010. 648 4.2. Informative References 650 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 651 Networks", RFC 5920, July 2010. 653 Authors' Addresses 655 Quintin Zhao 656 Huawei Technology 657 125 Nagog Technology Park 658 Acton, MA 01719 659 US 661 Email: quintin.zhao@huawei.com 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 Huawei Technology 673 No. 5 Street, Shangdi Information, Haidian 674 Beijing 675 China 677 Email: chenying220@huawei.com 679 Lianyuan Li 680 China Mobile 681 53A, Xibianmennei Ave. 682 Xunwu District, Beijing 01719 683 China 685 Email: lilianyuan@chinamobile.com 687 Chen Li 688 China Mobile 689 53A, Xibianmennei Ave. 690 Xunwu District, Beijing 01719 691 China 693 Email: lichenyj@chinamobile.com 694 Lu Huang 695 China Mobile 696 53A, Xibianmennei Ave. 697 Xunwu District, Beijing 01719 698 China 700 Email: huanglu@chinamobile.com 702 Luyuang Fang 703 Cisco Systems 704 300 Beaver Brook Road 705 Boxborough, MA 01719 706 US 708 Email: lufang@cisco.com 710 Chao Zhou 711 Cisco Systems 712 300 Beaver Brook Road 713 Boxborough, MA 01719 714 US 716 Email: czhou@cisco.com 718 Kamran Raza 719 Cisco Systems 720 2000 Innovation Drive 721 Kanata, ON K2K-3E8, MA 722 Canada 724 Email: E-mail: skraza@cisco.com 726 Ning So 727 Verizon Business 728 2400 North Glenville Drive 729 Richardson, TX 75082 730 USA 732 Email: Ning.So@verizonbusiness.com 733 Raveendra Torvi 734 Juniper Networks 735 10, Technoogy Park Drive 736 Westford, MA 01886-3140 737 US 739 Email: rtorvi@juniper.net