idnits 2.17.1 draft-li-mpls-global-label-framework-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 4 instances 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 14, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-05 == Outdated reference: A later version (-03) exists of draft-li-mpls-global-label-usecases-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft Q. Zhao 4 Intended status: Informational Huawei Technologies 5 Expires: August 18, 2014 T. Yang 6 China Mobile 7 February 14, 2014 9 A Framework of MPLS Global Label 10 draft-li-mpls-global-label-framework-01 12 Abstract 14 The document defines the framework of MPLS global label including: 15 representation of MPLS global label, process of control plane for 16 MPLS global label, and process of data plane for MPLS global label. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 18, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Representation of MPLS Global Label . . . . . . . . . . . . . 3 61 3.1. Option A -- Traditional MPLS Label . . . . . . . . . . . 3 62 3.2. Option B -- Expansions of MPLS Label . . . . . . . . . . 3 63 4. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1.1. Shared MPLS Global Label Range Calculation . . . . . 4 66 4.1.2. MPLS Global Label Allocation . . . . . . . . . . . . 4 67 4.1.3. MPLS Global Label Withdraw . . . . . . . . . . . . . 5 68 4.1.4. Error Process . . . . . . . . . . . . . . . . . . . . 5 69 4.1.5. Redundancy . . . . . . . . . . . . . . . . . . . . . 5 70 4.2. BGP-Based Control Plane . . . . . . . . . . . . . . . . . 6 71 4.3. IGP-Based Control Plane . . . . . . . . . . . . . . . . . 6 72 4.4. PCE-Based Control Plane . . . . . . . . . . . . . . . . . 8 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 7.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 [I-D.li-mpls-global-label-usecases] proposes possible usecases of 83 MPLS global label. MPLS global label can be used for identification 84 of the location, the service and the network in different application 85 scenarios. The new solutions based on MPLS global label can gain 86 advantage over the existing solutions to facilitate service 87 provisions. 89 This document defines the framework for MPLS global label. The 90 framework includes the representation of MPLS global label, the 91 process of control plane and data plane for MPLS global label. 93 2. Terminology 95 BDR: Backup Designated Router 97 DR: Designated Router 99 FEC: Forward Equivalence Class 101 MVPN: Multicast VPN 103 NBMA: Non-broadcast multi-access 105 PCE: Path Computation Element 107 PCC: Path Computation Client 109 RR: Route Reflector 111 3. Representation of MPLS Global Label 113 3.1. Option A -- Traditional MPLS Label 115 Current MPLS label uses 20 bits to represent the label range from 0 116 to 2^20 - 1. Since the existing MPLS label is always allocated 117 locally, in order to guarantee a specific label is allocated 118 globally, the available label values of the network nodes should be 119 reported to a central control point. The central control point can 120 calculate the COMMON label space which is available for all network 121 nodes. Then the network nodes must reserve the common label space 122 for the global label. When the global label is requested to allocate 123 for specific service, the central control point can allocate the 124 label from the common label space. 126 3.2. Option B -- Expansions of MPLS Label 128 [I-D.mpls-big-label-ucase-req] proposes the usecases and requirements 129 for MPLS big label. It could also be a reasonable way to define a 130 new label range or segment for MPLS global label which is independent 131 from the existing MPLS label range. The label stack mechanism can be 132 introduced to expand the MPLS label range. For example, the MPLS 133 global label can be represented as the following figure. The global 134 label value is achieved by adding the actual base label value 135 indicated by the base label and the remainder label value. 137 0 32 64 138 +-------------------+----+-+---------+-------------------+----+-+---------+ 139 | Base Label | TC |S| TTL | Remainder Label | TC |S| TTL | 140 +-------------------+----+-+---------+-------------------+----+-+---------+ 142 Figure 1 Representation of MPLS Global Label 144 If the new label range is used for the global label, it can reduce 145 the possible confliction with the existing label range. 147 4. Control Plane 149 4.1. Overview 151 MPLS global label should be allocated concentratedly to guarantee all 152 nodes can understand the same meaning for a specific global label. 153 It should adopt a server/client model in the control plane for MPLS 154 global label allocation. The procedures for the global label are 155 described as follows. 157 4.1.1. Shared MPLS Global Label Range Calculation 159 1. Clients nodes should report MPLS global label capability to the 160 central controller. 162 2. The central controller collects MPLS global label capability and 163 MPLS global label range of all nodes. Then it can calculate the 164 shared MPLS global label range for all nodes. 166 3. The centralized controller should notify the shared global label 167 range to all client nodes. Client nodes reserve the shared global 168 label range. 170 4.1.2. MPLS Global Label Allocation 172 1. The client node should send the global label request for specific 173 usage to the central controller. FEC(Forward Equivalence Class) 174 should be incorporated in the MPLS global label request message. 176 2. When the central controllers receives the MPLS global label 177 request, it should allocate the label from the shared MPLS global 178 label segment of all nodes. 180 3. The central controller sends the MPLS global label mapping 181 message to all client nodes. Thus the MPLS global label for specific 182 usage can be understood by all client nodes. 184 4. The client node receives the MPLS global label mapping message 185 and installs the corresponding MPLS forwarding entry for the global 186 label. 188 4.1.2.1. Process of Duplicate MPLS Global Label Request 190 Since MPLS global label is used for specific usage globally, it is 191 possible that multiple MPLS global label requests for the same usage 192 are sent by different client nodes to the central controller. The 193 controller needs to count the MPLS global label requests for the same 194 usage. It can send multiple global label mapping messages to respond 195 these requests. It can also send only one copy of the global label 196 mapping message to all nodes in order to reduce the unnecessary 197 protocol operation. If the controller sends multiple copies of the 198 global label mapping message to respond each label request, client 199 nodes need to ignore the subsequent messages. 201 4.1.3. MPLS Global Label Withdraw 203 TBD. 205 4.1.4. Error Process 207 TBD. 209 4.1.5. Redundancy 211 Since MPLS global label is allocated concentratedly, it is important 212 to guarantee the high availability of the central controller. 213 Redundant backup needs to be introduced for the high availability. 214 The backup central controller needs to learn global label requests 215 sent by client nodes and corresponding label mapping sent by the 216 primary central controller. The backup central controller will not 217 send any global label mapping to client nodes until failure happens 218 for the primary central controller. 220 The primary role and the backup role of the central controllers can 221 be specified administratively. They can also be elected dynamically 222 based on auto-discovery of these controllers. 224 The failure detection mechanism also needs to be introduced between 225 the primary controller and the backup controller. It can be the 226 keepalive-like mechanism, the fast detection mechanism like BFD, or 227 mixing use of both mechanisms. 229 4.2. BGP-Based Control Plane 231 +---------------------+ 232 | IP/MPLS | 233 | Network | 234 +----+ +----+ | | +----+ +----+ 235 | CE1|-----| | | | | |-----| CE2| 236 +----+\ | PE1|\| +----------+ |/| PE3| +----+ 237 \ +----+ \_____| BGP | / +----+ 238 \ |Controller|___/| 239 \ +----+ /-----| (RR+) | | 240 \| |/| +----------+ | 241 | PE2| | | 242 +----+ | | 243 +---------------------+ 245 Figure 2: BGP-based Control Plane 247 Many types of services such as VPLS[RFC4761], Multicast VPN[RFC6514] 248 and E-VPN[I-D.ietf-l2vpn-evpn] are based on MP-BGP. If new solutions 249 based on MPLS global label are introduced for such services, the 250 architecture shown in the figure 2 can be applied. 252 In the BGP-based control plane, Route Reflector (RR) of BGP [RFC4456] 253 can act as the role of the central controller. We call this type of 254 RR as RR+. For VPLS, Multicast VPN and E-VPN services, auto-discovery 255 mechanisms based on MP-BGP are introduced. So the RR+ can learn the 256 necessary membership information through these A-D routes. RR+ can 257 also learn the MPLS label capability information through necessary 258 MP-BGP extensions. When MPLS global label is necessary, the BGP 259 client on the PE node can send label request to RR+ and the label 260 mapping for the allocated MPLS global label will be advertised to all 261 PEs. Thus all PEs can learn the binding between the service and the 262 MPLS global and the forwarding entry for the MPLS global label can be 263 installed accordingly. 265 4.3. IGP-Based Control Plane 266 +------------------------------+ +------------------------------+ 267 | IGP Domain 1 | | IGP Domain 2 | 268 | +----------+ | | +----------+ | 269 | | IGP | | | | IGP | | 270 | |Controller|------------------------|Controller| | 271 | | (DR+) | | | | (DR+) | | 272 | | | | | | | | 273 | +----------+ | | +----------+ | 274 | / \ | | / \ | 275 | / \ | | / \ | 276 | / \ | | / \ | 277 | +--------+ +--------+ | | +--------+ +--------+ | 278 | | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | | 279 | | | ...... | | | | | | ...... | | | 280 | | IGP | | IGP | | | | IGP | | IGP | | 281 | | CLIENT | | CLIENT | | | | CLIENT | | CLIENT | | 282 | +--------+ +--------+ | | +--------+ +--------+ | 283 | | | | 284 +------------------------------+ +------------------------------+ 286 Figure 3: IGP-based Control Plane 288 If the internal nodes of the network support MPLS global label, IGP- 289 based control plane can be introduced. IGP has ever introduced the 290 DR(Designated Router) and BDR(Backup Designated Router) concepts for 291 broadcast and NBMA network([RFC2328]). The Designated Router is 292 elected in the broadcast or NBMA network to act as a centralized 293 control point to advertise adjacencies among DR and DR others. In 294 the IGP-base control plane for MPLS global label, we can adopt the DR 295 concept which can act as the central controller for the MPLS global 296 label. We called this type of DR ad DR+. The DR+ can collect the 297 MPLS global label capability of all client nodes. If MPLS global 298 label is necessary for specific usage, the MPLS global label will be 299 allocated by the DR+ and the corresponding label mapping can be 300 advertised to all network nodes through IGP extensions. Thus all 301 network nodes in the IGP area can learn the label binding between the 302 specific usage and the MPLS global label and the forwarding entry for 303 the MPLS global label can be installed accordingly. 305 MPLS global label binding information should be always advertised in 306 a specific IGP domains. There may be multiple IGP domains and nodes 307 in other IGP domains may be necessary to learn the MPLS global label 308 information. There are two possible solutions: 310 1. The global label information can be advertised by IGP to span 311 multiple domains. It is like leaking the information from the native 312 area to other areas. 314 2. There can exist direct connections between IGP DR+. The MPLS 315 global label information can be advertised from the native IGP DR+ to 316 the other IGP DR+ using possible protocol extensions other than 317 IGP(e.g. PCEP extensions or BGP extensions). The other IGP DR+ can 318 learn the MPLS global label information and advertise it in its own 319 area through IGP extensions. 321 4.4. PCE-Based Control Plane 323 +------------------------------+ +------------------------------+ 324 | PCE DOMAIN 1 | | PCE DOMAIN 2 | 325 | +--------+ | | +--------+ | 326 | | | | | | | | 327 | | PCE |--------------------------| PCE | | 328 | | Server | | | | Server | | 329 | | | | | | | | 330 | +--------+ | | +--------+ | 331 | / \ | | / \ | 332 | / \ | | / \ | 333 | / \ | | / \ | 334 | +--------+ +--------+ | | +--------+ +--------+ | 335 | | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | | 336 | | | ...... | | | | | | ...... | | | 337 | | PCC | | PCC | | | | PCC | | PCC | | 338 | | | | | | | | | | | | 339 | +--------+ +--------+ | | +--------+ +--------+ | 340 | | | | 341 +------------------------------+ +------------------------------+ 343 Figure 4: PCE-based Control Plane 345 PCE[RFC4655] is another choice to implement the control plane for 346 MPLS global label. The PCE servers can act as the role of the 347 centralized controller and the PCC can act the role of the client for 348 process of MPLS global label. PCE servers can collect the MPLS 349 global label capability of all nodes through PCEP extensions. If 350 MPLS global label is necessary for specific usage, the label request 351 can be sent from PCC to PCE server. MPLS global label will be 352 allocated by the PCE server and the corresponding label mapping will 353 be advertised to all network nodes through PCEP extensions. Thus all 354 network nodes in the domain can learn the label binding between the 355 specific usage and the MPLS global label and the forwarding entry for 356 the MPLS global label can be installed accordingly. 358 If MPLS global label information needs to be advertised in different 359 domain, it can be advertised from the native PCE server to other PCE 360 servers through PECP extensions. Then other PCE servers can 361 advertise the MPLS global information to PCC through PCEP in its own 362 domain. 364 5. IANA Considerations 366 This document makes no request of IANA. 368 6. Security Considerations 370 TBD. 372 7. References 374 7.1. Normative References 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 7.2. Informative References 381 [I-D.ietf-l2vpn-evpn] 382 Sajassi, A., Aggarwal, R., Henderickx, W., Isaac, A., and 383 J. Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf- 384 l2vpn-evpn-05 (work in progress), February 2014. 386 [I-D.li-mpls-global-label-usecases] 387 Li, Z., Zhao, Q., and T. Yang, "Usecases of MPLS Global 388 Label", draft-li-mpls-global-label-usecases-01 (work in 389 progress), February 2014. 391 [I-D.mpls-big-label-ucase-req] 392 Li, R. and K. Zhao, "MPLS Big Label Usecases and 393 Requirements", draft-mpls-big-label-ucase-req-00 (work in 394 progress), October 2013. 396 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 398 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 399 Reflection: An Alternative to Full Mesh Internal BGP 400 (IBGP)", RFC 4456, April 2006. 402 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 403 Element (PCE)-Based Architecture", RFC 4655, August 2006. 405 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 406 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 407 4761, January 2007. 409 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 410 Encodings and Procedures for Multicast in MPLS/BGP IP 411 VPNs", RFC 6514, February 2012. 413 Authors' Addresses 415 Zhenbin Li 416 Huawei Technologies 417 Huawei Bld., No.156 Beiqing Rd. 418 Beijing 100095 419 China 421 Email: lizhenbin@huawei.com 423 Quintin Zhao 424 Huawei Technologies 425 125 Nagog Technology Park 426 Acton, MA 01719 427 US 429 Email: quintin.zhao@huawei.com 431 Tianle Yang 432 China Mobile 433 32, Xuanwumenxi Ave. 434 Beijing 01719 435 China 437 Email: yangtianle@chinamobile.com