idnits 2.17.1 draft-lee-network-control-function-virtualization-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (October 21, 2013) is 3833 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4655' is mentioned on line 89, but not defined == Missing Reference: 'RFC5440' is mentioned on line 90, but not defined == Missing Reference: 'RFC2119' is mentioned on line 111, but not defined Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Young Lee 2 Internet Draft Huawei Technologies 4 Intended status: Informational Greg Bernstein 5 Expires: April 2014 Grotto Networking 7 Ning So 8 Tata Communications 10 Luyuan Fang 11 Cisco 13 Daniele Ceccarelli 14 Ericsson 16 Diego Lopez 17 Telefonica 19 Oscar Gonzalez de Dios 20 Telefonica 22 October 21, 2013 24 Network Control Function Virtualization for Transport SDN 26 draft-lee-network-control-function-virtualization-01.txt 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with 31 the provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six 39 months and may be updated, replaced, or obsoleted by other documents 40 at any time. It is inappropriate to use Internet-Drafts as 41 reference material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on April 21, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with 60 respect to this document. Code Components extracted from this 61 document must include Simplified BSD License text as described in 62 Section 4.e of the Trust Legal Provisions and are provided without 63 warranty as described in the Simplified BSD License. 65 Abstract 67 This presentation explores the concept of network control function 68 virtualization for transport SDN to help evolve transport networks 69 to provide programmable virtual network services with infrastructure 70 changes to the traditional control plane architecture. 72 Table of Contents 74 1. Terminology....................................................3 75 2. Requirements Language..........................................3 76 3. Introduction...................................................3 77 4. Transport SDN Control Architecture.............................4 78 5. Transport SDN Virtual Network Service..........................6 79 6. Summary and Conclusion........................................11 80 7. References....................................................11 81 7.1. Informative References...................................11 82 8. Contributors..................................................12 83 Authors' Addresses...............................................12 84 Intellectual Property Statement..................................12 85 Disclaimer of Validity...........................................13 87 1. Terminology 89 This document uses the terminology defined in [RFC4655], and 90 [RFC5440]. 92 CVI Client-VNC Interface 94 PNC Physical Network Control 96 VL virtual Link 98 VNC Virtual Network Control 100 VNE Virtual Network Element 102 VNS Virtual Network Service 104 VPI VNC-PNC Interface 106 2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Introduction 114 One of the main drivers for SDN is a physical separation of the 115 network control plane from the forwarding plane. This separation of 116 the network control plane from the forwarding plane has been already 117 achieved with the development of GMPLS/ASON and PCE for transport 118 networks. In fact, in transport networks such separation of data and 119 control plane was dictated at the onset due to the very different 120 natures of the data plane (circuit switched TDM or wavelength) and a 121 packet switched control plane. The physical separation of the 122 control plane and the forwarding plane is a major step toward 123 allowing operators to gain the full control for optimized network 124 design and operation. Another attraction of SDN technology is its 125 logically centralized control regime which allows a global view of 126 the underlying networks under its control. The centralized control 127 of SDN helps improve network resource utilization from a distributed 128 network control. Transport networks have long used this centralized 129 model via network management systems and currently supplement it 130 with topology and resource status information gathered dynamically 131 via GMPLS routing. For transport network control, PCE technology is 132 essentially equivalent to a logically centralized control for path 133 computation function. By combining the strength of GMPLS/ASON 134 [GMPLS] and PCE [PCE], and open standard interfaces, transport 135 network control plane technology is readily in a position to fully 136 embrace the SDN concepts. 138 However, the current transport network control plane technology is 139 not suitable for virtualization and client programmability, which 140 are the two of the main drivers for SDN in recent years. 141 Virtualization refers to allowing the clients to utilize a certain 142 amount of network resources as if they own them and thus control 143 their allocated resources in a way most optimal with higher layer or 144 application processes. This empowerment of client control 145 facilitates introduction of new services and applications as the 146 clients are given to create, modify, and delete their virtual 147 network services. The level of virtual control given to the clients 148 can vary from a tunnel connecting two end-points to virtual network 149 elements that consist of a set of virtual nodes and virtual links in 150 a mesh network topology. As part of the VNS, a client control 151 concept is added to the traditional VPN along with a client specific 152 virtual network view. Client control is operated on the view of 153 virtual network resources allocated to the client. This view is 154 called abstracted network topology. Such a view may be specific to 155 the set of client services as well as the particular client. As the 156 client control is envisioned to support a plethora of applications, 157 there is another level of virtualization from the client to 158 individual applications. 160 4. Transport SDN Control Architecture 162 To allow virtualization, the network has to provide open, 163 programmable interfaces in which clients/applications can create, 164 replace, modify virtual network services in an interactive manner 165 while having no impact on other network clients. Traditional 166 transport network infrastructure is not suitable for providing 167 programmable interfaces to clients. Direct client control of 168 transport network elements over existing programmable interfaces 169 (control or management plane) is not perceived as a viable 170 proposition for transport network providers due to security and 171 policy concerns among other reasons. 173 Hence, the need for network control function virtualization where 174 there is a "virtualizer" that interfaces directly with client 175 control and translates/allocates resources (from physical to virtual 176 and vice versa) and creates abstracted network topology for each 177 client and interacts with physical network connection control 178 functions (e.g., GMPLS/ASON for provisioning, PCE for path 179 computation). The Network control function virtualizer maintains two 180 interfaces: one interface with physical network control functions 181 assumed by GMPLS/ASON and PCE, which is termed as VNC-PNC Interface 182 (VPI); another interface with client control of virtual network, 183 which is termed as Client-VNC Interface (CVI). Figure 1 depicts the 184 overall architecture for transport SDN control in which the virtual 185 network control entity provides network control function 186 virtualization. 188 ------------------------------------------ 189 | Application Layer | 190 ------------------------------------------ 191 /|\ /|\ /|\ 192 | | \|/ North Bound API 193 | | --------------- 194 | \|/ | Client | 195 | -------------- Control | 196 \|/ | Client |-------- 197 -------------- Control | /|\ 198 | Client |------- | 199 | Control | /|\ | 200 -------------- | | 201 /|\ | | Client-VNC Interface 202 | | | (CVI) 203 \|/ \|/ \|/ 204 ---------------------------------- 205 | Virtual Network Control (VNC) | 206 ---------------------------------- 207 /|\ 208 | VNC-PNC Interface (VPI) 209 \|/ 210 ---------------------------------- 211 | Physical Network Control (PNC) | 212 ---------------------------------- 213 /|\ 214 | Control Interface to NEs 215 \|/ 217 Physical Network Infrastructure 219 Figure 1: Transport SDN control architecture 221 Figure 1 shows that there are multiple client controls which are 222 independent to each other and that each client supports various 223 business applications over its NB API. There are layered client- 224 server relationships in this architecture. As various applications 225 are clients to client control, client control itself is also a 226 client to virtual network control; likewise, virtual network control 227 is also a client to physical network control. This layered 228 relationship is important in protocol definition work on NB API, CVI 229 and VPI interfaces as this allows third-party software developers to 230 program client control and virtual network control functions in such 231 a way to create, modify and delete virtual network services. 233 This architecture in Figure 1 is conceptually in alignment with the 234 Network Functions Virtualization (NFV) architecture [NFV-AF]. 236 5. Transport SDN Virtual Network Service 238 Virtual Network Service is instantiated by the client control via 239 the CVI. As client control directly interfaces the application 240 stratum, it understands multiple application requirements and their 241 service needs. It is assumed that client control and VNC have the 242 common knowledge on the end-point interfaces based on their business 243 negotiation prior to service instantiation. End-point interfaces 244 refer to client-network physical interfaces that connect client 245 premise equipment to network provider equipment. Figure 2 shows an 246 example physical network topology that supports multiple clients. In 247 this example, client A has three end-points A.1, A.2 and A.3. The 248 interfaces between clients and transport networks are assumed to be 249 40G OTU links. For simplicity's sake, all network interfaces are 250 assumed to be 40G OTU links and all network ports support ODU 251 switching and grooming on the level of ODU1 and ODU2. Client control 252 for A provides its traffic demand matrix that describes bandwidth 253 requirements and other optional QoS parameters (e.g., latency, 254 diversity requirement, etc.) for each pair of end-point connections. 256 Figure 2 shows that three independent clients A, B and C provide its 257 respective traffic demand matrices to the VNC. The physical network 258 topology shown in Figure 2 is the provider's network topology 259 created by the PNC's topology creation engine such as the link state 260 database (LSDB) and Traffic Engineering DB (TEDB) based on control 261 plane discovery function. This topology is internal to PNC and not 262 available to the client. What is available to the client is 263 abstracted network topology (aka, virtual network topology) based on 264 the negotiated level of abstraction. This is a part of VNS 265 instantiation between a client control and VNC. 267 +------+ +------+ +------+ 268 A.1 ------o o-----------o o----------o o------- A.2 269 B.1 ------o 1 | | 2 | | 3 | 270 C.1 ------o o-----------o o----------o o------- B.2 271 +-o--o-+ +-o--o-+ +-o--o-+ 272 | | | | | | 273 | | | | | | 274 | | | | | | 275 | | +-o--o-+ +-o--o-+ 276 | `-------------o o----------o o------- B.3 277 | | 4 | | 5 | 278 `----------------o o----------o o------- C.3 279 +-o--o-+ +------+ 280 | | 281 | | 282 | | 283 C.2 A.3 285 Traffic Matrix Traffic Matrix Traffic Matrix 286 for Client A for Client B for Client C 288 A.1 A.2 A.3 B.1 B.2 B.3 C.1 C.2 C.3 289 ------------------- ------------------ ----------------- 290 A.1 - 20G 20G B.1 - 40G 40G C.1 - 20G 20G 291 A.2 20G - 10G B.2 40G - 20G C.2 20G - 10G 292 A.3 20G 10G - B.3 40G 20G - C.3 20G 10G - 294 Figure 2: Physical network topology shared with multiple clients 296 Figure 3 depicts illustrative examples of different level of 297 topology abstractions that can be provided by the VNC topology 298 abstraction engine based on physical topology base maintained by the 299 PNC. The level of topology abstraction is expressed in terms of the 300 number of virtual network elements (VNEs) and virtual links (VLs). 301 For example, the abstracted topology for client A shows there are 5 302 VNEs and 10 VLs. This is by far the most detail topology abstraction 303 with a minimal link hiding compared to other abstracted topologies 304 in Figure 3. 306 Abstracted Topology for Client A (5 VNEs and 10 VLs) 308 +------+ +------+ +------+ 309 A.1 ------o o-----------o o----------o o------- A.2 310 | 1 | | 2 | | 3 | 311 | | | | | | 312 +-o----+ +-o----+ +-o----+ 313 | | | 314 | | | 315 | | | 316 | +-o----+ +-o--o-+ 317 | | | | | 318 | | 4 | | 5 | 319 `----------------o o----------o | 320 +----o-+ +------+ 321 | 322 | 323 | 324 A.3 326 Abstracted Topology for Client B (3 VNEs and 6 VLs) 328 +------+ +------+ 329 B.1 ------o o-----------------------------o o------ B.2 330 | 1 | | 3 | 331 | | | | 332 +-o----+ +-o----+ 333 \ | 334 \ | 335 \ | 336 `------------------- | 337 ` +-o----+ 338 \ | o------ B.3 339 \ | 5 | 340 `-------o | 341 +------+ 343 Abstracted Topology for Client C (1 VNE and 3 VLs) 345 +-------------------------------------------+ 346 | | 347 | | 348 C.1 ------o | 349 | | 350 | | 351 | | 352 | o--------C.3 353 | | 354 +--------------------o----------------------+ 355 | 356 | 357 | 358 | 359 C.2 361 Figure 3: Topology Abstraction Examples for Clients 363 As different client has different control/application needs, 364 abstracted topologies for client B and C, respectively show much 365 less degree of abstraction. The level of topology abstraction is 366 determined by the policy (e.g., the granularity level) placed for 367 the client and/or the path computation results by the PNC's PCE. The 368 more granular the abstraction topology is, the more control is given 369 to the client control. If the client controller has applications 370 that require more granular control of virtual network resources, 371 then abstracted topology for client A may be the right abstraction 372 level for such client controller. For instance, if the client is a 373 third-party virtual service broker/provider, then it would desire 374 much more sophisticated control of virtual network resources to 375 support differing application needs. On the other hand, if the 376 client were only to support simple tunnel services to its 377 application, then abstracted topology for client C that consists of 378 one VNE and three VLs would suffice. 380 Figure 4 shows workflows across client control, VNC and PNC for the 381 VNS instantiation, topology exchange, and VNS setup. Client control 382 "owns" a VNS and initiates by providing the instantiation identifier 383 with the traffic demand matrix with path selection constraints for 384 that instance. This VNS instantiation request from Client Control 385 triggers a path computation request by the virtual PCE (vPCE) agent 386 in the VNC after VNC's proxy's interlay of this request to the vPCE. 387 vPCE requests a concurrent path computation request that is 388 converted based on the traffic demand matrix as part of the VNS 389 instantiation request from Client Control. Upon receipt of this path 390 computation request, the PCE in the PNC block computes paths and 391 updates network topology DB and informs the vPCE agent of the VNC of 392 the paths and topology updates. 394 ------------------------------------------------------------------ 395 | Client ----------------------------------------------- | 396 | Control | VNS Control | | 397 | ----------------------------------------------- | 398 ------------------------------------------------------------------ 399 1.VNS | /|\ 4. Abstracted | /|\ 400 Instantiation | | Topology | | 401 (instance id, | | | | 402 Traffic Matr.) | | | | 8. VNS 403 | | 5. VNS | | Set-up 404 \|/ | Set-up \|/ | Confirm 405 ------------------------------------------------------------------ 406 | Virtual ----------------------------------------------- | 407 | Network | VNS Proxy | | 408 | Control ----------------------------------------------- | 409 | ----------------------- ----------------------- | 410 | | vPCE Agent | | vConnection Agent | | 411 | ----------------------- ----------------------- | 412 ------------------------------------------------------------------ 413 2. Path | /|\ 3. PC Reply | /|\ 414 Computation | | with updated | | 415 Request | | topology | | 416 | | 6. Network | |8.Network 417 | | Provisioning | |Provisioning 418 \|/ | Request \|/ |Confirm 419 ------------------------------------------------------------------ 420 | Physical ------------- -------------------------- | 421 | Network | PCE | | Network Provisioning || 422 | Control ------------- -------------------------- | 423 ------------------------------------------------------------------ 425 Figure 4. Workflows across Client control, VNC and PNC 427 It is assumed that the PCE in PNC is a stateful PCE [PCE-S]. vPCE 428 agent abstracts the network topology into an abstracted topology for 429 the client based on the agree-upon granularity level. The abstracted 430 topology is then passed to the VNS control of the Client Control 431 block. The Client Control's VNS control computes and assigns virtual 432 network resources for its applications based on the abstracted 433 topology and creates VNS setup command to the VNC. The VNC's 434 vConnection module turns this VN setup command into network 435 provisioning requests over the network elements using control plane 436 messages such as GMPLS, etc. 438 6. Summary and Conclusion 440 This presentation explores the concept of network control function 441 virtualization for transport SDN to help evolve transport networks 442 to provide programmable virtual network services with infrastructure 443 changes to the traditional control plane architecture. The VNC and 444 its interfaces with the Client Control and the PNC provide control 445 plane function virtualization over programmable interfaces such as 446 virtual network path computation and optimization, topology 447 abstraction hiding details of physical topology while supporting 448 service-specific objectives the clients demand, maintaining virtual 449 network service instances and the states, policy enforcement for 450 virtual network services. With this evolutionary architecture, 451 virtual network services can be readily introduced while re-using 452 physical network control plane functions. 454 7. References 456 7.1. Informative References 458 [PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 459 Computation Element (PCE)-Based Architecture", IETF RFC 460 4655, August 2006. 462 [PCE-S] Crabbe, E, et. al., "PCEP extension for stateful 463 PCE",draft-ietf-pce-stateful-pce, work in progress. 465 [GMPLS] Manning, E., et al., "Generalized Multi-Protocol Label 466 Switching (GMPLS) Architecture", RFC 3945, October 2004. 468 [NFV-AF] "Network Functions Virtualization (NFV); Architectural 469 Framework", ETSI GS NFV 002 v1.1.1, October 2013. 471 8. Contributors 473 Authors' Addresses 475 Young Lee 476 Huawei Technologies 477 5340 Legacy Drive 478 Plano, TX 75023, USA 479 Phone: (469)277-5838 480 Email: leeyoung@huawei.com 482 Greg Bernstein 483 Grotto Networking 484 Fremont, CA, USA 485 Phone: (510) 573-2237 486 Email: gregb@grotto-networking.com 488 Ning So 489 Email: Ning.So@tatacommunications.com 491 Luyuan Fang 492 Email: luyuanf@gmail.com 494 Daniel Ceccarelli 495 Email: daniele.ceccarelli@ericsson.com 497 Diego Lopez 498 Email: diego@tid.es 500 Oscar Gonzalez de Dios 501 Email: ogondio@tid.es 503 Intellectual Property Statement 505 The IETF Trust takes no position regarding the validity or scope of 506 any Intellectual Property Rights or other rights that might be 507 claimed to pertain to the implementation or use of the technology 508 described in any IETF Document or the extent to which any license 509 under such rights might or might not be available; nor does it 510 represent that it has made any independent effort to identify any 511 such rights. 513 Copies of Intellectual Property disclosures made to the IETF 514 Secretariat and any assurances of licenses to be made available, or 515 the result of an attempt made to obtain a general license or 516 permission for the use of such proprietary rights by implementers or 517 users of this specification can be obtained from the IETF on-line 518 IPR repository at http://www.ietf.org/ipr 520 The IETF invites any interested party to bring to its attention any 521 copyrights, patents or patent applications, or other proprietary 522 rights that may cover technology that may be required to implement 523 any standard or specification contained in an IETF Document. Please 524 address the information to the IETF at ietf-ipr@ietf.org. 526 Disclaimer of Validity 528 All IETF Documents and the information contained therein are 529 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 530 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 531 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 532 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 533 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 534 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 535 FOR A PARTICULAR PURPOSE. 537 Acknowledgment 539 Funding for the RFC Editor function is currently provided by the 540 Internet Society.