idnits 2.17.1 draft-ietf-mpls-ldp-multi-topology-00.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 is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 7, 2011) is 4583 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 200, but not defined == Missing Reference: 'RFC3036' is mentioned on line 382, but not defined ** Obsolete undefined reference: RFC 3036 (Obsoleted by RFC 5036) == Missing Reference: 'LDPCAP' is mentioned on line 405, but not defined == Missing Reference: 'TBD' is mentioned on line 448, but not defined == Unused Reference: 'RFC2119' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 710, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'RFC4915' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 721, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 11 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: April 9, 2012 C. Zhou 6 Cisco Systems 7 L. Li 8 ChinaMobile 9 N. So 10 Verison Business 11 R. Torvi 12 Juniper Networks 13 October 7, 2011 15 LDP Extension for Multi Topology Support 16 draft-ietf-mpls-ldp-multi-topology-00.txt 18 Abstract 20 Multi-Topology (MT) routing is supported in IP through extension of 21 IGP protocols, such as OSPF and IS-IS. Each route computed by OSPF 22 or IS-IS is associated with a specific topology. Label Distribution 23 Protocol (LDP) is used to distribute labels for FECs advertised by 24 routing protocols. It is a natural requirement to extend LDP in 25 order to make LDP be aware of MT and thus take advantage of MT based 26 routing. 28 This document describes options to extend the existing MPLS 29 signalling protocol (LDP) for creating and maintaining Label 30 Switching Paths (LSPs) in a Multi-Topology enviroment. 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 April 9, 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 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Simplified Data-plane . . . . . . . . . . . . . . . . . . 5 70 3.2. Using MT for p2p Protection . . . . . . . . . . . . . . . 6 71 3.3. Using MT for mLDP Protection . . . . . . . . . . . . . . . 6 72 3.4. Service Separation . . . . . . . . . . . . . . . . . . . . 6 73 3.5. Simplified inter-AS VPN Solution . . . . . . . . . . . . . 6 74 4. Associating a FEC or group of FECs with MT-ID . . . . . . . . 7 75 4.1. MT-ID TLV . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.2. FEC TLV with MT-ID Extenstion . . . . . . . . . . . . . . 8 77 5. LDP MT Capability Advertisement . . . . . . . . . . . . . . . 9 78 5.1. Session Initialization . . . . . . . . . . . . . . . . . . 10 79 5.2. After Session Setup . . . . . . . . . . . . . . . . . . . 11 80 6. LDP Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 7. Reserved MT ID Values . . . . . . . . . . . . . . . . . . . . 12 82 8. LDP Messages with FEC TLV and MT-ID TLV . . . . . . . . . . . 12 83 8.1. Label Mapping Message . . . . . . . . . . . . . . . . . . 13 84 8.2. Label Request Message . . . . . . . . . . . . . . . . . . 14 85 8.3. Label Abort Request Message . . . . . . . . . . . . . . . 14 86 8.4. Label Withdraw Message . . . . . . . . . . . . . . . . . . 15 87 8.5. Label Release Message . . . . . . . . . . . . . . . . . . 16 88 9. Session Initialization Message with MT Capability . . . . . . 16 89 10. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 17 90 10.1. Use Label for (FEC, MT-ID) Tuple . . . . . . . . . . . . . 17 91 11. Security Consideration . . . . . . . . . . . . . . . . . . . . 18 92 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 93 13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 94 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 14.1. Normative References . . . . . . . . . . . . . . . . . . . 19 96 14.2. Informative References . . . . . . . . . . . . . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 99 1. Terminology 101 Terminology used in this document 103 MT-ID: A 12 bit value to represent Multi-Topology ID. 105 Default Topology: A topology that is built using the MT-ID value 106 0. 108 MT topology: A topology that is built using the corresponding 109 MT-ID. 111 2. Introduction 113 There are increasing requirements to support multi-topology in MPLS 114 network. For example, service providers may want to assign different 115 level of service(s) to different topologies so that the service 116 separation can be achieved. It is also possible to have an in-band 117 management network on top of the original MPLS topology, or maintain 118 separate routing and MPLS domains for isolated multicast or IPv6 119 islands within the backbone, or force a subset of an address space to 120 follow a different MPLS topology for the purpose of security, QoS or 121 simplified management and/or operations. 123 OSPF and IS-IS use MT-ID (Multi-Topology Identification) to identify 124 different topologies. For each topology identified by a MT-ID, IGP 125 computes a separate SPF tree independently to find the best paths to 126 the IP prefixes associated with this topology. 128 For FECs that are associated with a specific topology, we propose to 129 use the same MT-ID of this topology in LDP. Thus the Label Switching 130 Path (LSP) for a certian FEC may be created and maintained along the 131 IGP path in this topology. 133 Maintaining multiple MTs for MPLS network in a backwards-compatible 134 manner requires several extensions to the label signaling encoding 135 and processing procedures. When label is associated with a FEC, the 136 FEC includes both ip address and topology it belongs to. 138 There are two possible solutions to support MT awared MPLS network 139 from MPLS forwarding point of view. The first one is to map label to 140 both ip address and the corresponding topology. The alternative one 141 is to use label stacks. The upper label maps to the topology, the 142 lower label maps to the ip address. The first option does not 143 require change to data plane, and it could use multiple labels for 144 the same address on different topologies. The second option requires 145 two lookups on data forwarding plane, and it can use the same label 146 for the same address on different topologies. 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 3. Application Scenarios 182 3.1. Simplified Data-plane 184 IGP-MT requires additional data-plane resources maintain multiple 185 forwarding for each configured MT. On the other hand, MPLS-MT does 186 not change the data-plane system architecture, if an IGP-MT is mapped 187 to an MPLS-MT. In case MPLS-MT, incoming label value itself can 188 determine an MT, and hence it requires a single NHLFE space. MPLS-MT 189 requires only MT-RIBs in the control-plane, no need to have MT-FIBs. 190 Forwarding IP packets over a particular MT requires either 191 configuration or some external means at every node, to maps an 192 attribute of incoming IP packet header to IGP-MT, which is additional 193 overhead for network management. Whereas, MPLS-MT mapping is 194 required only at the ingress-PE of an MPLS-MT LSP, because of each 195 node identifies MPLS-MT LSP switching based on incoming label, hence 196 no additional configuration is required at every node. 198 3.2. Using MT for p2p Protection 200 We know that [IP-FRR-MT] can be used for configuring alternate path 201 via backup-mt, such that if primary link fails, then backup-MT can be 202 used for forwarding. However, such techniques require special 203 marking of IP packets that needs to be forwarded using backup-MT. 204 MPLS-LDP-MT procedures simplify the forwarding of the MPLS packets 205 over backup-MT, as MPLS-LDP-MT procedure distribute separate labels 206 for each MT. How backup paths are computed depends on the 207 implementation, and the algorithm. The MPLS-LDP-MT in conjunction 208 with IGP-MT could be used to separate the primary traffic and backup 209 traffic. For example, service providers can create a backup MT that 210 consists of links that are meant only for backup traffic. Service 211 providers can then establish bypass LSPs, standby LSPs, using backup 212 MT, thus keeping undeterministic backup traffic away from the primary 213 traffic. 215 3.3. Using MT for mLDP Protection 217 Fro the P2mP or MP2MP LSPs setup by using mLDP protocol, there is a 218 need to setup a backup LSP to have an end to end protection for the 219 priamry LSP in the appplicaitons such IPTV, where the end to end 220 protection is a must. Since the mLDP lSp is setup following the IGP 221 routes, the second LSP setup by following the IGP routes can not be 222 guranteed to have the link and node diversity from the primary LSP. 223 By using MPLS-LDP-MT, two topology can be configured with complete 224 link and node diversity, where the primary and secondary LSP can be 225 set up independantly within each topology. The two LSPs setup by 226 this mechanism can protect each other end-to-end. 228 3.4. Service Separation 230 MPLS-MT procedures allow establishing two distinct LSPs for the same 231 FEC, by advertising separate label mapping for each configured 232 topology. Service providers can implement CoS using MPLS-MT 233 procedures without requiring to create separate FEC address for each 234 class. MPLS-MT can also be used separate multicast and unicast 235 traffic. 237 3.5. Simplified inter-AS VPN Solution 239 When the lsp is crossing multiple domains for the inter-as VPN 240 scenarios, the LSP setup process can be simplified by configuring a 241 set of routers which are in different domains into a new single 242 domain with a new toplogy ID using the LDP multiple topology. All 243 the routers belong this new topology will be used to carry the 244 traffic acrossing multiple domains and since they are in a sinle 245 domain with the new topology ID, so the LDP lsp set up can be done 246 easily without the complex inter-as VPN solution's option A, option B 247 and option C. 249 4. Associating a FEC or group of FECs with MT-ID 251 This section describes two approaches to associate a FEC or a group 252 of FECs to a MT-ID in LDP. One way is to have a new TLV for MT-ID 253 and insert the MT-ID TLV into messages describing a FEC that needs 254 Multi-Topology information. Another approach is to extend FEC TLV to 255 contain the MT-ID if the FEC needs Multi-Topology information. 257 4.1. MT-ID TLV 259 The new TLV for MT-ID is defined as below: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 |U|F| TLV Code Point(TBD) | Length | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | reserved | MT-ID | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 where: 270 U and F bits: 271 As specified in [RFC3036]. 273 TLV Code Point: 274 The TLV type which identifies a specific capability. 276 MT-ID is a 12-bit field containing the ID of the topology 277 corresponding to the MT-ID used in IGP and LDP. Lack of MT-ID TLV 278 in messages MUST be interpreted as FECs are used in default 279 MT-ID (0) only. 281 A MT-ID TLV can be inserted into the following LDP messages as 282 an optional parameter. 284 Label Mapping "Label Mapping Message" 285 Label Request "Label Request Message" 286 Label Abort Request "Label Abort Request Message" 287 Label Withdraw "Label Withdraw Message" 288 Label Release "Label Release Message" 290 The message with inserted MT-ID TLV associates a FEC in same message 291 to the topology identified by MT-ID. 293 Figure 1: MT-ID TLV Format 295 4.2. FEC TLV with MT-ID Extenstion 297 The new TLV for MT-ID is defined as below: 299 The extended FEC TLV has the format below. 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 |U|F| FEC (TBD) | Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | reserved | MT-ID | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | FEC Element 1 | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | 311 ~ ~ 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | FEC Element n | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 This new FEC TLV may contain a number of FEC elements and a MT-ID. 318 It associates these FEC elements with the topology identified by 319 the MT-ID. Each FEC TLV can contain only one MT-ID. 321 Figure 2: Extended FEC with MT-ID 323 5. LDP MT Capability Advertisement 325 The LDP MT capability can be advertised either during the LDP session 326 initailizatin or after the LDP session is setup. 328 The capability for supporting multi-topology in LDP can be advertised 329 during LDP session initialization stage by including the LDP MT 330 capability TLV in LDP Initialization message. After LDP session is 331 established, the MT capability can also be advertised or changed 332 using Capability message. 334 If an LSR has not advertised MT capability, its peer must not send 335 messages that include MT identifier to this LSR. 337 If an LSR receives a Label Mapping message with MT parameter from 338 downstream LSR-D and its upstream LSR-U has not advertised MT 339 capability, an LSP for the MT will not be established. 341 If an LSR is changed from non MT capable to MT capable, it sets the S 342 bit in MT capability TLV and advertises via the Capability message. 343 The existing LSP is treated as LSP for default MT (ID 0). 345 If an LSR is changed from MT capable to non-MT capable, it may 346 initiate withdraw of all label mapping for existing LSPs of all non- 347 default MTs. Alternatively, it may wait until the routing update to 348 withdraw FEC and release the label mapping for existing LSPs of 349 specific MT. 351 There will be case where IGP is MT capable but MPLS is not and the 352 handling procedure for this case is TBD. 354 5.1. Session Initialization 356 In an LDP session initialization, the MT capability may be advertised 357 through an extended session initailization message. This extended 358 message has the same format as the original session initialization 359 message but contains the LDP MT capability TLV as an optional 360 parameter. 362 The format of the TLV for LDP MT is specified in the [LDPCAP] as 363 below: 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 |U|F| TLV Code Point(TBD) | Length | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |S| Reserved | | 371 +-+-+-+-+-+-+-+-+ Capability Data | 372 | +-+-+-+-+-+-+-+-+ 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 where: 377 U and F bits: 378 As specified in [RFC3036]. 380 TLV Code Point: 381 The TLV type which identifies a specific capability. The "IANA 382 Considerations" section of [RFC3036] specifies the assignment of 383 code points for LDP TLVs. 385 S-bit: 386 The State Bit indicates whether the sender is advertising or 387 withdrawing the capability corresponding to the TLV Code Point. 388 The State bit is used as follows: 390 1 - The TLV is advertising the capability specified by the 391 TLV Code Point. 392 0 - The TLV is withdrawing the capability specified by the 393 TLV Code Point. 395 Capability Data: 397 Information, if any, about the capability in addition to the TLV 398 Code Point required to fully specify the capability. 400 Figure 3: LDP MT CAP TLV 402 5.2. After Session Setup 404 During the normal operating stage of LDP sessions, the capability 405 message defined in the [LDPCAP] will be used with an LDP MT 406 capability TLV. 408 The format of the Capability message is as follows: 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 |0| Capability (IANA) | Length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Message ID | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | TLV_1 (LDP-MT Capability TLV) | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | . . . | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | TLV_N | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Figure 4: LDP CAP Format 426 where TLV_1 (LDP-MT Capability TLV) specifies that the LDP MT 427 capability is enabled or disbabled by setting the S bit of the TLV to 428 1 or 0. 430 6. LDP Sessions 432 Depending on the number of label spaces supported, if a single gloabl 433 label space is supported, there will be one session supported for 434 each pair of peers, even there are multiple topologoies supported 435 between these two peers. If there are different label spaces 436 supported for different topologies, which means that label spaces 437 overlap with each other for different MTs, then it is suggested to 438 establish multiple sessions for multipple topologies between these 439 two peers. In this case, multiple LSR-IDs need to be allocated 440 beforehand so that each multiple topology can have its own label 441 space ID. 443 This section is still TBD. 445 7. Reserved MT ID Values 447 Certain MT topologies are assigned to serve pre-determined purposes: 448 [TBD] 450 8. LDP Messages with FEC TLV and MT-ID TLV 451 8.1. Label Mapping Message 453 An LSR sends a Label Mapping message to an LDP peer to advertise FEC- 454 label bindings. In the Optional Parameters' field, the MT-ID TLV 455 will be inserted. 457 The encoding for the Label Mapping message is: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 |0| Label Mapping (0x0400) | Message Length | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Message ID | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | FEC TLV | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Label TLV | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | MT-ID TLV | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Other Optional Parameters | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Optional Parameters 476 This variable length field contains 0 or more parameters, each 477 encoded as a TLV. The optional parameters are: 479 Optional Parameter Length Value 481 Label Request 4 See below 482 Message ID TLV 483 Hop Count TLV 1 See below 484 Path Vector TLV variable See below 485 MT TLV variable See below 487 MT TLV 488 see the defination section for this new TLV. 490 Figure 5: Label Mapping Message 492 8.2. Label Request Message 494 An LSR sends the Label Request message to an LDP peer to request a 495 binding (mapping) for a FEC. The MT TLV will be inserted into the 496 Optional parameters' field. 498 The encoding for the Label Request message is: 500 0 1 2 3 501 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 |0| Label Request (0x0401) | Message Length | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Message ID | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | FEC TLV | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | MT-ID TLV | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Optional Parameters | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Figure 6: Label Request Message 516 In the DU mode, when a label mapping is received by a LSR which has a 517 downstream with MT capability advertised and an upstream without the 518 MT capability advertised, it will not send label mapping to its 519 upstream. 521 in the DoD mode, the label request is sent down to the downstream LSR 522 until it finds the downstrream LSR which doesn't support the MT, then 523 the current LSPR will send a notification to its upstream LSR. In 524 this case, no LSP is setup. 526 We propose to add a new notification event to signal the upstream 527 that the downstream is not capable. 529 8.3. Label Abort Request Message 531 The Label Abort Request message may be used to abort an outstanding 532 Label Request message. The MT TLV may be inserted into the optional 533 parameters' field. 535 The encoding for the Label Abort Request message is: 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 |0| Label Abort Req (0x0404) | Message Length | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Message ID | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | FEC TLV | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Label Request Message ID TLV | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | MT-ID TLV (optional) | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Optional Parameters | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Figure 7: Label Abort Request Message 555 8.4. Label Withdraw Message 557 An LSR sends a Label Withdraw Message to an LDP peer to signal the 558 peer that the peer may not continue to use specific FEC-label 559 mappings the LSR had previously advertised. This breaks the mapping 560 between the FECs and the labels. The MT TLV will be added into the 561 optional paramters' field. 563 The encoding for the Label Withdraw Message is: 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 |0| Label Withdraw (0x0402) | Message Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Message ID | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | FEC TLV | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Label TLV (optional) | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | MT-ID TLV | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Optional Parameters | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Figure 8: Label Withdraw Message 583 8.5. Label Release Message 585 An LSR sends a Label Release message to an LDP peer to signal the 586 peer that the LSR no longer needs specific FEC-label mappings 587 previously requested of and/or advertised by the peer. The MT TLV 588 will be added into the optional paramers' field. 590 The encoding for the Label Release Message is: 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 |0| Label Release (0x0403) | Message Length | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Message ID | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | FEC TLV | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Label TLV (optional) | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | MT-ID TLV | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Optional Parameters | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Figure 9: Label Release Message 610 9. Session Initialization Message with MT Capability 612 The session initializtion message is extended to contain the LDP MT 613 capability as an optional parameter. The extended session 614 initialization message has the format below. 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 |0| Initialization (0x0200) | Message Length | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Message ID | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Common Session Parameters TLV | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | LDP MT Capability TLV | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Optional Parameters | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Figure 10: Session Initialization Message with MT Capability 632 10. MPLS Forwarding in MT 634 Although forwading is out of the scope of this draft. For the 635 completness of discussion, we include some forwarding consideration 636 for informational purpose here. 638 In MT based MPLS network, forwarding will be based not only on label, 639 but also on MT-ID associsted with the label. There are multiple 640 options to do this. Below, we list the option prefered. 642 10.1. Use Label for (FEC, MT-ID) Tuple 644 We suggest is that MPLS forwarding for different topologies is 645 implied by labels. This approach does not need any change to the 646 exsiting MPLS hardware forwarding mechanism. It also resolves the 647 forwarding issue that exists in IGP multi-topology forwarding when 648 multiple topologies share an interface with overlay address space. 650 On a MT awared LSR, each label is associated with tuple: (FEC, 651 MT-ID). Therefore, same FEC with different MT-ID would be assigned 652 to different labels. 654 Using this mechanism, for tuple (FEC-F, MT-ID-N1) and (FEC-F, 655 MT-ID-N2), each LSR along the LSP path that is shared by topology MT- 656 ID-N1 and MT-ID-N2 will allocate different labels to them. Thus two 657 different Label Switching Paths will be created. One for (FEC-F, MT- 658 ID-N1) and the other for (FEC-F, MT-ID-N1). The traffic for them 659 will follow different Label Switching Paths (LSPs). 661 Note, in this mechanism, label space is not allowed to be overlapping 662 among different MTs. In the above example, each label belongs to a 663 specific topology or the default topology. MPLS forwarding will be 664 performed exactly same as non-MT MPLS forwarding: using label to find 665 output information. This option will not require any change of 666 hardware forwarding to commodate MPLS MT. We will have different 667 RIBs coresspoding to different MT IDs. But we will only need one 668 LFIB. 670 Below is an example for MPLS forwarding: 672 RIB(x) for MT-IDx: 673 FEC NEXT HOP 674 FECi(Destination A) R1 676 RIB(y) for MT-IDy: 677 FEC NEXT HOP 678 FECi(Destination A) R2 680 LFIB: 681 Ingress Label Egress Label NEXT HOP 682 Lm Lp R1 683 Ln Lq R2 (could be same as R1) 685 Figure 11: Forwarding Mechanism 687 11. Security Consideration 689 MPLS security applies to the work presented. No specific security 690 issues with the proposed solutions are known. The authentication 691 procedure for RSVP signalling is the same regardless of MT 692 information inside the RSVP messages. 694 12. IANA Considerations 696 TBD 698 13. Acknowledgement 700 The authors would like to thank Dan Tappan, Nabil Bitar, and Huang 701 Xin for their valuable comments on this draft. 703 14. References 705 14.1. Normative References 707 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 708 Requirement Levels", BCP 14, RFC 2119, March 1997. 710 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 711 Considered Useful", BCP 82, RFC 3692, January 2004. 713 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 714 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 715 October 1998. 717 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 718 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 719 RFC 4915, June 2007. 721 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 722 Topology (MT) Routing in Intermediate System to 723 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 725 14.2. Informative References 727 Authors' Addresses 729 Quintin Zhao 730 Huawei Technology 731 125 Nagog Technology Park 732 Acton, MA 01719 733 US 735 Email: qzhao@huawei.com 737 Huaimo Chen 738 Huawei Technology 739 125 Nagog Technology Park 740 Acton, MA 01719 741 US 743 Email: huaimochen@huawei.com 744 Emily Chen 745 Huawei Technology 746 No. 5 Street, Shangdi Information, Haidian 747 Beijing 748 China 750 Email: chenying220@huawei.com 752 Lianyuan Li 753 China Mobile 754 53A, Xibianmennei Ave. 755 Xunwu District, Beijing 01719 756 China 758 Email: lilianyuan@chinamobile.com 760 Chen Li 761 China Mobile 762 53A, Xibianmennei Ave. 763 Xunwu District, Beijing 01719 764 China 766 Email: lichenyj@chinamobile.com 768 Lu Huang 769 China Mobile 770 53A, Xibianmennei Ave. 771 Xunwu District, Beijing 01719 772 China 774 Email: huanglu@chinamobile.com 776 Luyuang Fang 777 Cisco Systems 778 300 Beaver Brook Road 779 Boxborough, MA 01719 780 US 782 Email: lufang@cisco.com 783 Chao Zhou 784 Cisco Systems 785 300 Beaver Brook Road 786 Boxborough, MA 01719 787 US 789 Email: czhou@cisco.com 791 Ning So 792 Verison Business 793 2400 North Glenville Drive 794 Richardson, TX 75082 795 USA 797 Email: Ning.So@verizonbusiness.com 799 Raveendra Torvi 800 Juniper Networks 801 10, Technoogy Park Drive 802 Westford, MA 01886-3140 803 US 805 Email: pratiravi@juniper.net