idnits 2.17.1 draft-li-mpls-global-label-framework-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 are 4 instances of too long lines in the document, the longest one being 8 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 11, 2013) is 3941 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.li-mpls-global-label-usecases' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC4456' is defined on line 449, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-03 == Outdated reference: A later version (-03) exists of draft-li-mpls-global-label-usecases-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Z. Li 2 Internet-Draft Q. Zhao 3 Intended status: Informational Huawei Technologies 4 Expires: January 12, 2014 T. Yang 5 China Mobile 6 July 11, 2013 8 A Framework of MPLS Global Label 9 draft-li-mpls-global-label-framework-00 11 Abstract 13 The document defines the framework of MPLS global label including: 14 representation of MPLS global label, process of control plane for 15 MPLS global label, and process of data plane for MPLS global label. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 12, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Representation of MPLS Global Label . . . . . . . . . . . . . 3 60 3.1. Option A -- Traditional MPLS Label . . . . . . . . . . . 3 61 3.2. Option B -- Expansions of MPLS Label . . . . . . . . . . 4 62 4. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1.1. Shared MPLS Global Label Range Calculation . . . . . 4 65 4.1.2. MPLS Global Label Allocation . . . . . . . . . . . . 5 66 4.1.3. MPLS Global Label Withdraw . . . . . . . . . . . . . 5 67 4.1.4. Error Process . . . . . . . . . . . . . . . . . . . . 6 68 4.1.5. Redundancy . . . . . . . . . . . . . . . . . . . . . 6 69 4.2. BGP-Based Control Plane . . . . . . . . . . . . . . . . . 6 70 4.3. IGP-Based Control Plane . . . . . . . . . . . . . . . . . 7 71 4.4. PCE-Based Control Plane . . . . . . . . . . . . . . . . . 8 72 5. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 [I-D.li-mpls-global-label-usecases]proposes possible usecases of MPLS 81 global label. MPLS global label can be used for identification of 82 the location, the service and the network in different application 83 scenarios. The new solutions based on MPLS global label can gain 84 advantage over the existing solutions to facilitate service 85 provisions. 87 This document defines the framework for MPLS global label. The 88 framework includes the representation of MPLS global label, the 89 process of control plane and data plane for MPLS global label. 91 2. Terminology 93 BDR: Backup Designated Router 95 DR: Designated Router 97 FEC: Forward Equivalence Class 99 MVPN: Multicast VPN 101 NBMA: Non-broadcast multi-access 103 PCE: Path Computation Element 105 PCC: Path Computation Client 107 RR: Route Reflector 109 3. Representation of MPLS Global Label 111 3.1. Option A -- Traditional MPLS Label 113 Current MPLS label uses 20 bits to represent the label range from 0 114 to 2^20 - 1. Since the existing MPLS label forwarding mechanism has 115 been widely deployed, it is difficult to adopt following possible 116 ways to represent MPLS global label: 118 1. Specific label in the existing label range to represent MPLS 119 global label. Since a specific MPLS global label should be 120 understood by all nodes for the same meaning, it is hard for all 121 nodes to allocate a specific label value for the same usage. For 122 example, a specific label value may be allocated for MPLS global 123 label while the same label value may be allocated for MPLS LDP for 124 MPLS local label. Thus, the inconsistency for the specific label 125 value will happen. 127 2. Reserve a segment of existing MPLS label range for MPLS global 128 label and the MPLS global label is allocated concentratedly. This is 129 also hard to implement owing to following reasons: 131 1) The label capability of network nodes are different. It is hard 132 to get a shared label segment of all nodes for the usage of MPLS 133 global label. 135 2) Even if the label capability of all network nodes can be collected 136 and the shared label segment can be calculated, once new nodes are 137 introduced into the network, the shared label segment reserved for 138 MPLS global label maybe has to calculate again according to the new 139 label capability introduced. The worst case is that the new shared 140 label segment can not be available and it will do harm to the 141 existing deployed services based on MPLS global label. 143 3.2. Option B -- Expansions of MPLS Label 145 It is a reasonable way to define a new label range or segment for 146 MPLS global label which is independent from the existing MPLS label 147 range. [I-D.li-mpls-mega-label] defines the label stacking mechanism 148 to expand the MPLS label range. The mechanism can be used to define 149 a new label range for MPLS global label. 151 The MPLS global label can be represented as the following figure. 152 The global label value is achieved by adding the actual base label 153 value indicated by the base label and the remainder label value. 155 0 32 64 156 +-------------------+----+-+---------+-------------------+----+-+---------+ 157 | Base Label | TC |S| TTL | Remainder Label | TC |S| TTL | 158 +-------------------+----+-+---------+-------------------+----+-+---------+ 160 Figure 1 Representation of MPLS Global Label 162 [I-D.li-mpls-mega-label] specifies that the base label can be any 163 value range from 0 to 2^20 -1 (excluding the special labels which 164 have been reserved). But for MPLS global label, it is better to 165 define a new special label which is in the range from 0 to 15. Thus 166 all nodes can understand it for the same meaning. Otherwise, if a 167 label value in the range from 16 to 2^20 -1 is used for the base 168 label of the global label, it is necessary to get all network nodes 169 to reserve the specific label value. It has the same issues as those 170 described in Section 3.1 such as difficulty in reservation, 171 recalculation when new nodes are introduced, etc. 173 4. Control Plane 175 4.1. Overview 177 MPLS global label should be allocated concentratedly to guarantee all 178 nodes can understand the same meaning for a specific global label. 179 It should adopt a server/client model in the control plane for MPLS 180 global label allocation. The procedures for the global label are 181 described as follows. 183 4.1.1. Shared MPLS Global Label Range Calculation 184 1. Clients nodes should report MPLS global label capability to the 185 centralized controller. Since the label range for MPLS global label 186 is newly defined, it is MANDATORY for each client node to support a 187 least range of labels for the usage of MPLS global label. This is to 188 guarantee that a shared global label segment can be derived for all 189 nodes. 191 2. The centralized controller collects MPLS global label capability 192 and MPLS global label range of all nodes. Then it can calculate the 193 shared MPLS global label range for all nodes. 195 3. The centralized controller should notify the shared global label 196 range to all client nodes. 198 4.1.2. MPLS Global Label Allocation 200 1. The client node should send the global label request for specific 201 usage to the centralized controller. FEC(Forward Equivalence Class) 202 should be incorporated in the MPLS global label request message. 204 2. When the centralized controllers receives the MPLS global label 205 request, it should allocate the label from the shared MPLS global 206 label segment of all nodes. 208 3. The centralized controller sends the MPLS global label mapping 209 message to all client nodes. Thus the MPLS global label for specific 210 usage can be understood by all client nodes. 212 4. The client node receives the MPLS global label mapping message 213 and installs the corresponding MPLS forwarding entry for the global 214 label. 216 4.1.2.1. Process of Duplicate MPLS Global Label Request 218 Since MPLS global label is used for specific usage globally, it is 219 possible that multiple MPLS global label requests for the same usage 220 are sent by different client nodes to the centralized controller. 221 The controller needs to count the MPLS global label requests for the 222 same usage. It can send multiple global label mapping messages to 223 respond these requests. It can also send only one copy of the global 224 label mapping message to all nodes in order to reduce the unnecessary 225 protocol operation. If the controller sends multiple copies of the 226 global label mapping message to respond each label request, client 227 nodes need to ignore the subsequent messages. 229 4.1.3. MPLS Global Label Withdraw 231 TBD. 233 4.1.4. Error Process 235 TBD. 237 4.1.5. Redundancy 239 Since MPLS global label is allocated concentratedly, it is important 240 to guarantee the high availability of the centralized controller. 241 Redundant backup needs to be introduced for the high availability. 242 The backup centralized controller needs to learn global label 243 requests sent by client nodes and corresponding label mapping sent by 244 the primary centralized controller. The backup centralized 245 controller will not send any global label mapping to client nodes 246 until failure happens for the primary centralized controller. 248 The primary role and the backup role of the centralized controllers 249 can be specified administratively. They can also be elected 250 dynamically based on auto-discovery of these controllers. 252 The failure detection mechanism also needs to be introduced between 253 the primary controller and the backup controller. It can be the 254 keepalive-like mechanism, the fast detection mechanism like BFD, or 255 mixing use of both mechanisms. 257 4.2. BGP-Based Control Plane 259 +---------------+ 260 | IP/MPLS | 261 | Network | 262 +----+ +----+ | | +----+ +----+ 263 | CE1|-----| | | | | |-----| CE2| 264 +----+\ | PE1|\| +---- + |/| PE3| +----+ 265 \ +----+ \____| | / +----+ 266 \ | RR+ |___/| 267 \ +----+ /----| | | 268 \| |/| +-----+ | 269 | PE2| | | 270 +----+ | | 271 +---------------+ 273 Figure 2: BGP-based Control Plane 275 Many types of services such as VPLS[RFC4761], Multicast VPN[RFC6514] 276 and E-VPN[I-D.ietf-l2vpn-evpn] are based on MP-BGP. If new solutions 277 based on MPLS global label are introduced for such services, the 278 architecture shown in the figure 2 can be applied. 280 In the BGP-based control plane, Route Reflector (RR) of BGP 281 [RFC4456]can act as the role of the centralized controller. We call 282 this type of RR as RR+. For VPLS, Multicast VPN and E-VPN services, 283 auto-discovery mechanisms based on MP-BGP are introduced. So the RR+ 284 can learn the necessary membership information through these A-D 285 routes. RR+ can also learn the MPLS label capability information 286 through necessary MP-BGP extensions. When MPLS global label is 287 necessary, the BGP client on the PE node can send label request to 288 RR+ and the label mapping for the allocated MPLS global label will be 289 advertised to all PEs. Thus all PEs can learn the binding between 290 the service and the MPLS global and the forwarding entry for the MPLS 291 global label can be installed accordingly. 293 4.3. IGP-Based Control Plane 295 +------------------------------+ +------------------------------+ 296 | IGP AREA 1 | | IGP AREA 2 | 297 | +--------+ | | +--------+ | 298 | | | | | | | | 299 | | DR+ |--------------------------| DR+ | | 300 | | | | | | | | 301 | | | | | | | | 302 | +--------+ | | +--------+ | 303 | / \ | | / \ | 304 | / \ | | / \ | 305 | / \ | | / \ | 306 | +--------+ +--------+ | | +--------+ +--------+ | 307 | | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | | 308 | | | ...... | | | | | | ...... | | | 309 | | IGP | | IGP | | | | IGP | | IGP | | 310 | | CLIENT | | CLIENT | | | | CLIENT | | CLIENT | | 311 | +--------+ +--------+ | | +--------+ +--------+ | 312 | | | | 313 +------------------------------+ +------------------------------+ 315 Figure 3: IGP-based Control Plane 317 If the internal nodes of the network support MPLS global label, IGP- 318 based control plane can be introduced. IGP has ever introduced the 319 DR(Designated Router) and BDR(Backup Designated Router) concepts for 320 broadcast and NBMA network([RFC2328]). The Designated Router is 321 elected in the broadcast or NBMA network to act as a centralized 322 control point to advertise adjacencies among DR and DR others. In 323 the IGP-base control plane for MPLS global label, we can adopt the DR 324 concept which can act as the centralized controller for the MPLS 325 global label. We called this type of DR ad DR+. The DR+ can collect 326 the MPLS global label capability of all client nodes. If MPLS global 327 label is necessary for specific usage, the MPLS global label will be 328 allocated by the DR+ and the corresponding label mapping can be 329 advertised to all network nodes through IGP extensions. Thus all 330 network nodes in the IGP area can learn the label binding between the 331 specific usage and the MPLS global label and the forwarding entry for 332 the MPLS global label can be installed accordingly. 334 MPLS global label binding information should be always advertised in 335 a specific IGP area. There may be multiple IGP areas and nodes in 336 other IGP areas may be necessary to learn the MPLS global label 337 information. There are two possible solutions: 339 1. The global label information can be advertised by IGP to span 340 multiple areas. It is like leaking the information from the native 341 area to other areas. 343 2. There can exist direct connections between IGP DR+. The MPLS 344 global label information can be advertised from the native IGP DR+ to 345 the other IGP DR+ using possible protocol extensions other than 346 IGP(e.g. PCEP extensions or BGP extensions). The other IGP DR+ can 347 learn the MPLS global label information and advertise it in its own 348 area through IGP extensions. 350 4.4. PCE-Based Control Plane 352 +------------------------------+ +------------------------------+ 353 | PCE DOMAIN 1 | | PCE DOMAIN 2 | 354 | +--------+ | | +--------+ | 355 | | | | | | | | 356 | | PCE |--------------------------| PCE | | 357 | | Server | | | | Server | | 358 | | | | | | | | 359 | +--------+ | | +--------+ | 360 | / \ | | / \ | 361 | / \ | | / \ | 362 | / \ | | / \ | 363 | +--------+ +--------+ | | +--------+ +--------+ | 364 | | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | | 365 | | | ...... | | | | | | ...... | | | 366 | | PCC | | PCC | | | | PCC | | PCC | | 367 | | | | | | | | | | | | 368 | +--------+ +--------+ | | +--------+ +--------+ | 369 | | | | 370 +------------------------------+ +------------------------------+ 372 Figure 4: PCE-based Control Plane 374 PCE[RFC4655] is another choice to implement the control plane for 375 MPLS global label. The PCE servers can act as the role of the 376 centralized controller and the PCC can act the role of the client for 377 process of MPLS global label. PCE servers can collect the MPLS 378 global label capability of all nodes through PCEP extensions. If 379 MPLS global label is necessary for specific usage, the label request 380 can be sent from PCC to PCE server. MPLS global label will be 381 allocated by the PCE server and the corresponding label mapping will 382 be advertised to all network nodes through PCEP extensions. Thus all 383 network nodes in the domain can learn the label binding between the 384 specific usage and the MPLS global label and the forwarding entry for 385 the MPLS global label can be installed accordingly. 387 If MPLS global label information needs to be advertised in different 388 domain, it can be advertised from the native PCE server to other PCE 389 servers through PECP extensions. Then other PCE servers can 390 advertise the MPLS global information to PCC through PCEP in its own 391 domain. 393 5. Data Plane 395 According to Section 3, MPLS global label can be represented by label 396 stacking. When encapsulate MPLS global label, the remainder label 397 for the MPLS global label should be encapsulated firstly. Then the 398 base label for the MPLS global label should be encapsulated in a row. 399 The TTL, COS and S values should be the same in the base label 400 encapsulation and the remainder label encapsulation. 402 When receive the packet with MPLS global label encapsulation, the 403 base label should be decapsulated firstly. The actual base label 404 value indicated by the base label will be derived. Then the 405 remainder label should be decapsulated. The actual MPLS global label 406 value can be acquired by adding the actual base label value and the 407 remainder label value. The TTL, COS and S value in the base label 408 encapsulation and the remainder label encapsulation for the MPLS 409 global label should be the same. If there exists inconsistency, the 410 TTL, COS and S value in the remainder label encapsulation should be 411 adopted for MPLS forwarding. 413 Since MPLS global label can be used for different usages, the process 414 of the data plane may be related with the specific usage of the MPLS 415 global label. These processes are out of scope of this document and 416 should be defined combining with the specific usage. 418 6. IANA Considerations 420 This document makes no request of IANA. 422 7. Security Considerations 424 TBD. 426 8. Normative References 428 [I-D.ietf-l2vpn-evpn] 429 Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F., 430 Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", 431 draft-ietf-l2vpn-evpn-03 (work in progress), February 432 2013. 434 [I-D.li-mpls-global-label-usecases] 435 Li, Z., Zhao, Q., and T. Yang, "Usecases of MPLS Global 436 Label", draft-li-mpls-global-label-usecases-00 (work in 437 progress), July 2013. 439 [I-D.li-mpls-mega-label] 440 Li, Z. and L. Zheng, "Mega Label - Expansion of MPLS Label 441 Range", draft-li-mpls-mega-label-00 (work in progress), 442 July 2013. 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, March 1997. 447 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 449 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 450 Reflection: An Alternative to Full Mesh Internal BGP 451 (IBGP)", RFC 4456, April 2006. 453 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 454 Element (PCE)-Based Architecture", RFC 4655, August 2006. 456 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 457 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 458 4761, January 2007. 460 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 461 Encodings and Procedures for Multicast in MPLS/BGP IP 462 VPNs", RFC 6514, February 2012. 464 Authors' Addresses 465 Zhenbin Li 466 Huawei Technologies 467 Huawei Bld., No.156 Beiqing Rd. 468 Beijing 100095 469 China 471 Email: lizhenbin@huawei.com 473 Quintin Zhao 474 Huawei Technologies 475 125 Nagog Technology Park 476 Acton, MA 01719 477 US 479 Email: quintin.zhao@huawei.com 481 Tianle Yang 482 China Mobile 483 32, Xuanwumenxi Ave. 484 Beijing 01719 485 China 487 Email: yangtianle@chinamobile.com