idnits 2.17.1 draft-ietf-mpls-ldp-multi-topology-01.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 5 instances of too long lines in the document, the longest one being 9 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 (October 31, 2011) is 4554 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 242, but not defined == Missing Reference: 'RFC5036' is mentioned on line 450, but not defined == Missing Reference: 'RFC5918' is mentioned on line 692, but not defined == Missing Reference: 'RFC5919' is mentioned on line 709, but not defined == Unused Reference: 'RFC3692' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 753, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Q. Zhao 3 Internet-Draft Huawei Technology 4 Intended status: Standards Track L. Fang 5 Expires: May 3, 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 October 31, 2011 15 LDP Extensions for Multi Topology Routing 16 draft-ietf-mpls-ldp-multi-topology-01.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 3, 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. Associating a FEC or group of FECs with MT-ID . . . . . . 8 77 3.2.1. MT-ID TLV . . . . . . . . . . . . . . . . . . . . . . 8 78 3.2.2. FEC TLV with MT-ID Extension . . . . . . . . . . . . . 9 79 3.3. LDP MT Capability Advertisement . . . . . . . . . . . . . 9 80 3.3.1. Session Initialization . . . . . . . . . . . . . . . . 10 81 3.3.2. Post Session Setup . . . . . . . . . . . . . . . . . . 11 82 3.4. LDP Sessions . . . . . . . . . . . . . . . . . . . . . . . 12 83 3.5. Reserved MT ID Values . . . . . . . . . . . . . . . . . . 12 84 3.6. LDP Messages with FEC TLV and MT-ID TLV . . . . . . . . . 12 85 3.6.1. Label Mapping Message . . . . . . . . . . . . . . . . 13 86 3.6.2. Label Request Message . . . . . . . . . . . . . . . . 14 87 3.6.3. Label Abort Request Message . . . . . . . . . . . . . 14 88 3.6.4. Label Withdraw Message . . . . . . . . . . . . . . . . 15 89 3.6.5. Label Release Message . . . . . . . . . . . . . . . . 16 90 3.7. Session Initialization Message with MT Capability . . . . 16 91 3.8. MT Applicability on FEC-based features . . . . . . . . . . 17 92 3.8.1. Typed Wildcard Prefix FEC Element . . . . . . . . . . 17 93 3.8.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . 17 94 3.9. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . 18 95 3.10. Security Consideration . . . . . . . . . . . . . . . . . . 18 96 3.11. IANA Considerations . . . . . . . . . . . . . . . . . . . 18 97 3.12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 18 98 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 4.1. Normative References . . . . . . . . . . . . . . . . . . . 18 100 4.2. Informative References . . . . . . . . . . . . . . . . . . 19 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 103 1. Terminology 105 Terminology used in this document 107 MT-ID: A 12 bit value to represent Multi-Topology ID. 109 Default Topology: A topology that is built using the MT-ID value 110 0. 112 MT topology: A topology that is built using the corresponding 113 MT-ID. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 2. Introduction 123 There are increasing requirements to support multi-topology in MPLS 124 network. For example, service providers may want to assign different 125 level of service(s) to different topologies so that the service 126 separation can be achieved. It is also possible to have an in-band 127 management network on top of the original MPLS topology, or maintain 128 separate routing and MPLS domains for isolated multicast or IPv6 129 islands within the backbone, or force a subset of an address space to 130 follow a different MPLS topology for the purpose of security, QoS or 131 simplified management and/or operations. 133 OSPF and IS-IS use MT-ID (Multi-Topology Identification) to identify 134 different topologies. For each topology identified by a MT-ID, IGP 135 computes a separate SPF tree independently to find the best paths to 136 the IP prefixes associated with this topology. 138 For FECs that are associated with a specific topology, this solution 139 utilises the same MT-ID of this topology in LDP. Thus LSP for a 140 certain FEC may be created and maintained along the IGP path in this 141 topology. 143 Maintaining multiple MTs for MPLS network in a backwards-compatible 144 manner requires several extensions to the label signaling encoding 145 and processing procedures. When label is associated with a FEC, the 146 FEC includes both IP address and topology it belongs to. 148 There are a few possible ways to apply the MT-ID of a topology in 149 LDP. One way is to have a new TLV for MT-ID and insert the TLV into 150 messages describing a FEC that needs Multi-Topology information. 151 Another approach is to expand the FEC TLV to contain MT-ID if the FEC 152 needs Multi-Topology information. 154 MT based MPLS in general can be used for a variety of purposes such 155 as service separation by assigning each service or a group of 156 services to a topology, where the managment, QoS and security of the 157 service or the group of the services can be simplified and 158 guaranteed, in-band management network "on top" of the original MPLS 159 topology, maintain separate routing and MPLS forwrding domains for 160 isolated multicast or IPv6 islands within the backbone, or force a 161 subset of an address space to follow a different MPLS topology for 162 the purpose of security, QoS or simplified management and/or 163 operations. 165 One of the use of the MT based MPLS is where one class of data 166 requires low latency links, for example Voice over Internet Protocol 167 (VoIP) data. As a result such data may be sent preferably via 168 physical landlines rather than, for example, high latency links such 169 as satellite links. As a result an additional tolology is defined as 170 all low latency links on the network and VoIP data packets are 171 assinged to the additional topology. Another example is security- 172 critical traffic which may be assigned to an additional topology for 173 non-radiative links. Further possible examples are file transfer 174 prtocol (FTP) or SMTP (simple mail transfer protocol) traffic which 175 can be assigned to additional topology comprising high latency links, 176 Internet Protocol version 4 (IPv4) versus Internet Protocol version 6 177 (IPv6) traffic which may be assigned to different topology or data to 178 be distingushed by the quality of service (QoS) assinged to it. 180 This document describes the protocol extensions required to extend 181 the existing MPLS LDP signalling protocol for creating and 182 maintaining LSPs in an MT environment. 184 3. Requirements 186 MPLS-MT may be used for a variety of purposes such as service 187 separation by assigning each service or a group of services to a 188 topology, where the management, QoS and security of the service or 189 the group of the services can be simplified and guaranteed, in-band 190 management network "on top" of the original MPLS topology, maintain 191 separate routing and MPLS forwarding domains for isolated multicast 192 or IPv6 islands within the backbone, or force a subset of an address 193 space to follow a different MPLS topology for the purpose of 194 security, QoS or simplified management and/or operations. 196 The following specific requirements and objectives have been defined 197 in order to provide the functionality described above, and facilitate 198 service provider configuration and operation. 200 o Deployment of MPLS-MT within existing MPLS networks should be 201 possible, with MPLS-MT non-capable nodes existing with MPLS-MT 202 capable nodes. 204 o Minimise configuration and operation complexity of MPLS-MT across 205 the network. 207 o The MPLS-MT solution SHOULD NOT require data-plane modification. 209 o The MPLS-MT solution MUST support multiple topologies. Allowing a 210 an MPLS LSP to be established across a specific, or set of, 211 multiple topologies. 213 o Control and filtering of LSPs using explicitly including or 214 excluding multiple topologies MUST be supported. 216 o The MPLS-MT solution MUST be capable of supporting QoS mechanisms. 218 [Editors Note - We expect these base MPLS-MT protocol requirements to 219 be evolved over the next few versions of this document. Note that 220 all Editors notes will be deleted before publication of the document] 222 3.1. Application Scenarios 224 3.1.1. Simplified Data-plane 226 IGP-MT requires additional data-plane resources maintain multiple 227 forwarding for each configured MT. On the other hand, MPLS-MT does 228 not change the data-plane system architecture, if an IGP-MT is mapped 229 to an MPLS-MT. In case MPLS-MT, incoming label value itself can 230 determine an MT, and hence it requires a single NHLFE space. MPLS-MT 231 requires only MT-RIBs in the control-plane, no need to have MT-FIBs. 232 Forwarding IP packets over a particular MT requires either 233 configuration or some external means at every node, to maps an 234 attribute of incoming IP packet header to IGP-MT, which is additional 235 overhead for network management. Whereas, MPLS-MT mapping is 236 required only at the ingress-PE of an MPLS-MT LSP, because of each 237 node identifies MPLS-MT LSP switching based on incoming label, hence 238 no additional configuration is required at every node. 240 3.1.2. Using MT for p2p Protection 242 We know that [IP-FRR-MT] can be used for configuring alternate path 243 via backup-mt, such that if primary link fails, then backup-MT can be 244 used for forwarding. However, such techniques require special 245 marking of IP packets that needs to be forwarded using backup-MT. 246 MPLS-LDP-MT procedures simplify the forwarding of the MPLS packets 247 over backup-MT, as MPLS-LDP-MT procedure distribute separate labels 248 for each MT. How backup paths are computed depends on the 249 implementation, and the algorithm. The MPLS-LDP-MT in conjunction 250 with IGP-MT could be used to separate the primary traffic and backup 251 traffic. For example, service providers can create a backup MT that 252 consists of links that are meant only for backup traffic. Service 253 providers can then establish bypass LSPs, standby LSPs, using backup 254 MT, thus keeping undeterministic backup traffic away from the primary 255 traffic. 257 3.1.3. Using MT for mLDP Protection 259 Fro the P2mP or MP2MP LSPs setup by using mLDP protocol, there is a 260 need to setup a backup LSP to have an end to end protection for the 261 priamry LSP in the appplicaitons such IPTV, where the end to end 262 protection is a must. Since the mLDP lSp is setup following the IGP 263 routes, the second LSP setup by following the IGP routes can not be 264 guranteed to have the link and node diversity from the primary LSP. 265 By using MPLS-LDP-MT, two topology can be configured with complete 266 link and node diversity, where the primary and secondary LSP can be 267 set up independantly within each topology. The two LSPs setup by 268 this mechanism can protect each other end-to-end. 270 3.1.4. Service Separation 272 MPLS-MT procedures allow establishing two distinct LSPs for the same 273 FEC, by advertising separate label mapping for each configured 274 topology. Service providers can implement CoS using MPLS-MT 275 procedures without requiring to create separate FEC address for each 276 class. MPLS-MT can also be used separate multicast and unicast 277 traffic. 279 3.1.5. An Alternative inter-AS VPN Solution 281 When the lsp is crossing multiple domains for the inter-as VPN 282 scenarios, the LSP setup process can be done by configuring a set of 283 routers which are in different domains into a new single domain with 284 a new topology ID using the LDP multiple topology. All the routers 285 belong this new topology will be used to carry the traffic across 286 multiple domains and since they are in a single domain with the new 287 topology ID, so the LDP lsp set up can be done without propagating 288 VPN routes across AS boundaries. 290 3.2. Associating a FEC or group of FECs with MT-ID 292 This section describes multiple approaches to associate a FEC or a group 293 of FECs to a MT-ID in LDP. One way is to have a new TLV for MT-ID 294 and insert the MT-ID TLV into messages describing a FEC that needs 295 Multi-Topology information. Another approach is to extend FEC TLV to 296 contain the MT-ID if the FEC needs Multi-Topology information. There are 297 also other choices such as defining new address family or associate the 298 MPLS MT-ID with each FEC element in the FEC TLV. In this version, we discuss 299 the first two choices, and in the future versions, we will add the discussions 300 for other choices into the draft. 302 3.2.1. MT-ID TLV 304 The new TLV for MT-ID is defined as below: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 |U|F| TLV Code Point(TBD) | Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | reserved | MT-ID | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 where: 315 U and F bits: 316 As specified in [RFC5036]. 318 TLV Code Point: 319 The TLV type which identifies a specific capability. 321 MT-ID is a 12-bit field containing the ID of the topology 322 corresponding to the MT-ID used in IGP and LDP. Lack of MT-ID TLV 323 in messages MUST be interpreted as FECs are used in default 324 MT-ID (0) only. 326 A MT-ID TLV can be inserted into the following LDP messages as 327 an optional parameter. 329 Label Mapping "Label Mapping Message" 330 Label Request "Label Request Message" 331 Label Abort Request "Label Abort Request Message" 332 Label Withdraw "Label Withdraw Message" 333 Label Release "Label Release Message" 335 The message with inserted MT-ID TLV associates a FEC in same message 336 to the topology identified by MT-ID. 338 Figure 1: MT-ID TLV Format 340 3.2.2. FEC TLV with MT-ID Extension 342 The new TLV for MT-ID is defined as below: 344 The extended FEC TLV has the format below. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 |U|F| FEC (TBD) | Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | reserved | MT-ID | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | FEC Element 1 | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | | 356 ~ ~ 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | FEC Element n | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 This new FEC TLV may contain a number of FEC elements and a MT-ID. 363 It associates these FEC elements with the topology identified by 364 the MT-ID. Each FEC TLV can contain only one MT-ID. 366 Figure 2: Extended FEC with MT-ID 368 3.3. LDP MT Capability Advertisement 370 The LDP MT capability can be advertised either during the LDP session 371 initializatin or after the LDP session is setup. 373 The capability for supporting multi-topology in LDP can be advertised 374 during LDP session initialization stage by including the LDP MT 375 capability TLV in LDP Initialization message. After LDP session is 376 established, the MT capability can also be advertised or changed 377 using Capability message. 379 If an LSR has not advertised MT capability, its peer must not send 380 messages that include MT identifier to this LSR. 382 If an LSR receives a Label Mapping message with MT parameter from 383 downstream LSR-D and its upstream LSR-U has not advertised MT 384 capability, an LSP for the MT will not be established. 386 If an LSR is changed from non-MT capable to MT capable, it sets the S 387 bit in MT capability TLV and advertises via the Capability message. 388 The existing LSP is treated as LSP for default MT (ID 0). 390 If an LSR is changed from MT capable to non-MT capable, it may 391 initiate withdraw of all label mapping for existing LSPs of all non- 392 default MTs. Alternatively, it may wait until the routing update to 393 withdraw FEC and release the label mapping for existing LSPs of 394 specific MT. 396 There will be case where IGP is MT capable but MPLS is not and the 397 handling procedure for this case is TBD. 399 3.3.1. Session Initialization 401 In an LDP session initialization, the MT capability may be advertised 402 through an extended session initialization message. This extended 403 message has the same format as the original session initialization 404 message but contains the LDP MT capability TLV as an optional 405 parameter. 407 The format of the TLV for LDP MT is specified in the [RFC5036] as 408 below: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |U|F| TLV Code Point(TBD) | Length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |S| Reserved | | 416 +-+-+-+-+-+-+-+-+ Capability Data | 417 | +-+-+-+-+-+-+-+-+ 418 | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 where: 422 U and F bits: 423 As specified in [RFC5036]. 425 TLV Code Point: 426 The TLV type which identifies a specific capability. The "IANA 427 Considerations" section of [RFC5036] specifies the assignment of 428 code points for LDP TLVs. 430 S-bit: 431 The State Bit indicates whether the sender is advertising or 432 withdrawing the capability corresponding to the TLV Code Point. 433 The State bit is used as follows: 435 1 - The TLV is advertising the capability specified by the 436 TLV Code Point. 437 0 - The TLV is withdrawing the capability specified by the 438 TLV Code Point. 440 Capability Data: 442 Information, if any, about the capability in addition to the TLV 443 Code Point required to fully specify the capability. 445 Figure 3: LDP MT CAP TLV 447 3.3.2. Post Session Setup 449 During the normal operating stage of LDP sessions, the capability 450 message defined in the [RFC5036] will be used with an LDP MT 451 capability TLV. 453 The format of the Capability message is as follows: 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 |0| Capability (IANA) | Length | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Message ID | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | TLV_1 (LDP-MT Capability TLV) | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | . . . | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | TLV_N | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Figure 4: LDP CAP Format 471 where TLV_1 (LDP-MT Capability TLV) specifies that the LDP MT 472 capability is enabled or disabled by setting the S bit of the TLV to 473 1 or 0. 475 3.4. LDP Sessions 477 Depending on the number of label spaces supported, if a single global 478 label space is supported, there will be one session supported for 479 each pair of peer, even there are multiple topologies supported 480 between these two peers. If there are different label spaces 481 supported for different topologies, which means that label spaces 482 overlap with each other for different MTs, then it is suggested to 483 establish multiple sessions for multiple topologies between these two 484 peers. In this case, multiple LSR-IDs need to be allocated 485 beforehand so that each multiple topology can have its own label 486 space ID. 488 [Editors Note - This section requires further discussion] 490 3.5. Reserved MT ID Values 492 Certain MT topologies are assigned to serve pre-determined purposes: 494 [Editors Note - This section requires further discussion] 496 3.6. LDP Messages with FEC TLV and MT-ID TLV 497 3.6.1. Label Mapping Message 499 An LSR sends a Label Mapping message to an LDP peer to advertise FEC- 500 label bindings. In the Optional Parameters' field, the MT-ID TLV 501 will be inserted. 503 The encoding for the Label Mapping message is: 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 |0| Label Mapping (0x0400) | Message Length | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Message ID | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | FEC TLV | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Label TLV | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | MT-ID TLV | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Other Optional Parameters | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Optional Parameters 522 This variable length field contains 0 or more parameters, each 523 encoded as a TLV. The optional parameters are: 525 Optional Parameter Length Value 527 Label Request 4 See below 528 Message ID TLV 529 Hop Count TLV 1 See below 530 Path Vector TLV variable See below 531 MT TLV variable See below 533 MT TLV 534 see the definition section for this new TLV. 536 Figure 5: Label Mapping Message 538 3.6.2. Label Request Message 540 An LSR sends the Label Request message to an LDP peer to request a 541 binding (mapping) for a FEC. The MT TLV will be inserted into the 542 Optional parameters' field. 544 The encoding for the Label Request message is: 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 |0| Label Request (0x0401) | Message Length | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Message ID | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | FEC TLV | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | MT-ID TLV | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Optional Parameters | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 Figure 6: Label Request Message 562 In the DU mode, when a label mapping is received by a LSR which has a 563 downstream with MT capability advertised and an upstream without the 564 MT capability advertised, it will not send label mapping to its 565 upstream. 567 in the DoD mode, the label request is sent down to the downstream LSR 568 until it finds the downstream LSR which doesn't support the MT, then 569 the current LSPR will send a notification to its upstream LSR. In 570 this case, no LSP is setup. 572 We propose to add a new notification event to signal the upstream 573 that the downstream is not capable. 575 3.6.3. Label Abort Request Message 577 The Label Abort Request message may be used to abort an outstanding 578 Label Request message. The MT TLV may be inserted into the optional 579 parameters' field. 581 The encoding for the Label Abort Request message is: 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 |0| Label Abort Req (0x0404) | Message Length | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Message ID | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | FEC TLV | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Label Request Message ID TLV | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | MT-ID TLV (optional) | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Optional Parameters | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 Figure 7: Label Abort Request Message 601 3.6.4. Label Withdraw Message 603 An LSR sends a Label Withdraw Message to an LDP peer to signal the 604 peer that the peer may not continue to use specific FEC-label 605 mappings the LSR had previously advertised. This breaks the mapping 606 between the FECs and the labels. The MT TLV will be added into the 607 optional paramters field. 609 The encoding for the Label Withdraw Message is: 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 |0| Label Withdraw (0x0402) | Message Length | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Message ID | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | FEC TLV | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Label TLV (optional) | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | MT-ID TLV | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Optional Parameters | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Figure 8: Label Withdraw Message 629 3.6.5. Label Release Message 631 An LSR sends a Label Release message to an LDP peer to signal the 632 peer that the LSR no longer needs specific FEC-label mappings 633 previously requested of and/or advertised by the peer. The MT TLV 634 will be added into the optional paramers field. 636 The encoding for the Label Release Message is: 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 |0| Label Release (0x0403) | Message Length | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Message ID | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | FEC TLV | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Label TLV (optional) | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | MT-ID TLV | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Optional Parameters | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Figure 9: Label Release Message 656 3.7. Session Initialization Message with MT Capability 658 The session initializtion message is extended to contain the LDP MT 659 capability as an optional parameter. The extended session 660 initialization message has the format below. 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 |0| Initialization (0x0200) | Message Length | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Message ID | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Common Session Parameters TLV | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | LDP MT Capability TLV | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Optional Parameters | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 Figure 10: Session Initialization Message with MT Capability 678 3.8. MT Applicability on FEC-based features 680 3.8.1. Typed Wildcard Prefix FEC Element 682 RFC-5918 extends base LDP and defines Typed Wildcard FEC Element 683 framework [RFC5918]. Typed Wildcard FEC element can be used in any 684 LDP message to specify a wildcard operation/action for given type of 685 FEC. 687 The impact of the MT extensions proposed in document on the 688 procedures for Typed Wildcard Prefix FEC element depends on the MPLS 689 MT-ID representation mechanism we chose at the end. 691 For example, if the MPLS-MT ID TLV option is the final choice, then 692 the procedures defined in [RFC5918] apply as-is to Prefix FEC element 693 or the Prefix FEC element along with the MPLS MT-ID TLV. For 694 instance, upon local un-configuration of topology "x", an LSR may 695 send wildcard label withdraw with MT-ID TLV "x" to withdraw all its 696 labels from peer that were advertised under the scope of topology 697 "x". 699 3.8.2. End-of-LIB 701 [RFC5919] specifies extensions and procedures for an LDP speaker to 702 signal its convergence for given FEC type towards a peer. 704 The impact of the MT extensions proposed in document on the 705 procedures for End-of-LIB depends on the MPLS MT-ID representation 706 mechanism we chose at the end. 708 For example, if the MPLS-MT ID TLV option is the final choice, the 709 procedures defined in [RFC5919] apply as-is to Prefix FEC element or 710 the Prefix FEC element along with the MPLS MT-ID TLV. This means 711 that an LDP speaker MAY signal its IP convergence using Typed 712 Wildcard Prefix FEC element, and its MT IP convergence per topology 713 using the Typed Wildcard Prefix FEC element along with the MPLS MT-ID 714 TLV. 716 3.9. MPLS Forwarding in MT 718 Although forwarding is out of the scope of this draft, we include 719 some forwarding consideration for informational purpose here. 721 The specified signaling mechanisms allow all the topologies to share 722 the platform-specific label space; this is the feature that allows 723 the existing data plane techniques to be used; and the specified 724 signaling mechanisms do not provide any way for the data plane to 725 associate a given packet with a context-specific label space. 727 3.10. Security Consideration 729 MPLS security applies to the work presented. No specific security 730 issues with the proposed solutions are known. The authentication 731 procedure for RSVP signalling is the same regardless of MT 732 information inside the RSVP messages. 734 3.11. IANA Considerations 736 [Editors Note - This section requires further discussion] 738 3.12. Acknowledgement 740 The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin, 741 Daniel King and Eric Rosen for their valuable comments on this draft. 743 4. References 745 4.1. Normative References 747 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 748 Requirement Levels", BCP 14, RFC 2119, March 1997. 750 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 751 Considered Useful", BCP 82, RFC 3692, January 2004. 753 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 754 Topology (MT) Routing in Intermediate System to 755 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 757 4.2. Informative References 759 Authors' Addresses 761 Quintin Zhao 762 Huawei Technology 763 125 Nagog Technology Park 764 Acton, MA 01719 765 US 767 Email: quintin.zhao@huawei.com 769 Huaimo Chen 770 Huawei Technology 771 125 Nagog Technology Park 772 Acton, MA 01719 773 US 775 Email: huaimochen@huawei.com 777 Emily Chen 778 Huawei Technology 779 No. 5 Street, Shangdi Information, Haidian 780 Beijing 781 China 783 Email: chenying220@huawei.com 785 Lianyuan Li 786 China Mobile 787 53A, Xibianmennei Ave. 788 Xunwu District, Beijing 01719 789 China 791 Email: lilianyuan@chinamobile.com 792 Chen Li 793 China Mobile 794 53A, Xibianmennei Ave. 795 Xunwu District, Beijing 01719 796 China 798 Email: lichenyj@chinamobile.com 800 Lu Huang 801 China Mobile 802 53A, Xibianmennei Ave. 803 Xunwu District, Beijing 01719 804 China 806 Email: huanglu@chinamobile.com 808 Luyuang Fang 809 Cisco Systems 810 300 Beaver Brook Road 811 Boxborough, MA 01719 812 US 814 Email: lufang@cisco.com 816 Chao Zhou 817 Cisco Systems 818 300 Beaver Brook Road 819 Boxborough, MA 01719 820 US 822 Email: czhou@cisco.com 824 Kamran Raza 825 Cisco Systems 826 2000 Innovation Drive 827 Kanata, ON K2K-3E8, MA 828 Canada 830 Email: E-mail: skraza@cisco.com 831 Ning So 832 Verizon Business 833 2400 North Glenville Drive 834 Richardson, TX 75082 835 USA 837 Email: Ning.So@verizonbusiness.com 839 Raveendra Torvi 840 Juniper Networks 841 10, Technoogy Park Drive 842 Westford, MA 01886-3140 843 US 845 Email: rtorvi@juniper.net