idnits 2.17.1 draft-ceccarelli-actn-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 : ---------------------------------------------------------------------------- ** 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 date (January 3, 2014) is 3737 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4655' is mentioned on line 100, but not defined == Missing Reference: 'RFC5440' is mentioned on line 101, but not defined == Unused Reference: 'NFV-AF' is defined on line 794, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Daniele Ceccarelli 2 Internet Draft Ericsson 4 Intended status: Informational Luyuan Fang 5 Expires: July 2014 Microsoft 7 Young Lee 8 Huawei 10 Diego Lopez 11 Telefonica 13 January 3, 2014 15 Framework for Abstraction and Control of Transport Networks 17 draft-ceccarelli-actn-framework-00.txt 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with 22 the provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on June 3, 2014. 42 Copyright Notice 43 Copyright (c) 2013 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 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the Simplified BSD License. 56 Abstract 58 This draft provides a framework for abstraction and control of 59 transport networks. 61 Table of Contents 63 1. Terminology....................................................3 64 2. Introduction...................................................3 65 3. Business Model of ACTN.........................................5 66 3.1. Consumers.................................................6 67 3.2. Service Providers.........................................6 68 3.3. Network Providers.........................................7 69 4. Computation Model of ACTN......................................7 70 4.1. Request Processing........................................7 71 4.2. Types of Network Resources................................8 72 4.3. Accuracy of Network Resource Representation...............8 73 4.4. Resource Efficiency.......................................8 74 4.5. Guarantee of Client Isolation.............................8 75 4.6. Computing Time............................................8 76 4.7. Admission Control.........................................8 77 4.8. Path Constraints..........................................9 78 5. Control and Interface Model for ACTN...........................9 79 5.1. A High-level ACTN Control Architecture....................9 80 5.2. Consumer Controller......................................11 81 5.3. Abstracted Topology......................................12 82 5.4. Workflows of ACTN Control Modules........................15 83 5.5. Programmability of the ACTN Interfaces...................17 84 6. Design Principles of ACTN.....................................17 85 6.1. Network Security.........................................17 86 6.2. Privacy and Isolation....................................17 87 6.3. Scalability..............................................18 88 6.4. Manageability and Orchestration..........................18 89 6.5. Programmability..........................................18 90 6.6. Network Stability........................................18 91 7. References....................................................19 92 7.1. Informative References...................................19 93 8. Contributors..................................................19 94 Authors' Addresses...............................................20 95 Intellectual Property Statement..................................20 96 Disclaimer of Validity...........................................21 98 1. Terminology 100 This document uses the terminology defined in [RFC4655], and 101 [RFC5440]. 103 CVI Consumer-VNC Interface 105 PNC Physical Network Controller 107 VL Virtual Link 109 VNM Virtual Network Mapping 111 VNC Virtual Network Controller 113 VNE Virtual Network Element 115 VNS Virtual Network Service 117 VPI VNC-PNC Interface 119 2. Introduction 121 Transport networks have a variety of mechanisms to facilitate 122 separation of data plane and control plane including distributed 123 signaling for path setup and protection, centralized path 124 computation for planning and traffic engineering, and a range of 125 management and provisioning protocols to configure and activate 126 network resources. These mechanisms represent key technologies for 127 enabling flexible and dynamic networking. 129 Transport networks in this draft refer to a set of different type of 130 connection-oriented networks, primarily Connection-Oriented Circuit 131 Switched (CO-CS) networks and Connection-Oriented Packet Switched 132 (CO-PS) networks. This implies that at least the following transport 133 networks are in scope of the discussion of this draft: L1 optical 134 networks (e.g., OTN and WSON), MPLS-TP, MPLS-TE, as well as other 135 emerging connection-oriented networks such as Segment Routing (SR). 136 One of the characteristics of these network types is the ability of 137 dynamic provisioning and traffic engineering such that resource 138 guarantee can be provided to their clients. 140 One of the main drivers for Software Defined Networking (SDN) is a 141 physical separation of the network control plane from the data 142 plane. This separation of the network control plane from the data 143 plane has been already achieved for with the development of 144 MPLS/GMPLS [GMPLS] and PCE [PCE] for TE-based transport networks. In 145 fact, in transport networks such separation of data and control 146 plane was dictated at the onset due to the very different natures of 147 the data plane (circuit switched TDM or wavelength) and a packet 148 switched control plane. The physical separation of the control plane 149 and the data plane is a major step toward allowing operators to gain 150 the full control for optimized network design and operation. 151 Moreover, another advantage of SDN is its logically centralized 152 control regime that allows a global view of the underlying network 153 under its control. Centralized control in SDN helps improve network 154 resource utilization from a distributed network control. For TE- 155 based transport network control, PCE is essentially equivalent to a 156 logically centralized control for path computation function. 158 As transport networks evolve, the need to provide network 159 abstraction has emerged as a key requirement for operators; this 160 implies in effect the virtualization of network resources so that 161 the network is "sliced" for different uses, applications, services, 162 and consumers each being given a different partial view of the total 163 topology and each considering that it is operating with or on a 164 single, stand-alone and consistent network. 166 Network virtualization, in general, refers to allowing the consumers 167 to utilize a certain amount of network resources as if they own them 168 and thus control their allocated resources in a way most optimal 169 with higher layer or application processes. This empowerment of 170 consumer control facilitates introduction of new services and 171 applications as the consumers are given to create, modify, and 172 delete their virtual network services. The level of virtual control 173 given to the consumers can vary from a tunnel connecting two end- 174 points to virtual network elements that consist of a set of virtual 175 nodes and virtual links in a mesh network topology. More flexible, 176 dynamic consumer control capabilities are added to the traditional 177 VPN along with a consumer specific virtual network view. Consumers 178 control a view of virtual network resources, specifically allocated 179 to each one of them. This view is called an abstracted network 180 topology. Such a view may be specific to the set of consumed 181 services as well as to the particular consumer. As the consumer 182 controller is envisioned to support a plethora of distinct 183 applications, there would be another level of virtualization from 184 the consumer to individual applications. 186 The virtualization framework described in this draft is named 187 Abstraction and Control of Transport Network (ACTN) and facilitates: 189 - Abstraction of the underlying network resources to higher-layer 190 applications and users (consumers); 192 - Sharing of network resources, to meet specific application and 193 users requirements; 195 - A computation scheme, via an information model, to serve 196 various consumers that request network connectivity and 197 properties associated with it; 199 - A virtual network controller that adapts consumer requests to 200 the virtual resources allocated to them to the supporting 201 physical network control and performs the necessary mapping, 202 translation, isolation and security/policy enforcement, etc.; 204 - The coordination of the underlying transport topology, 205 presenting it as an abstracted topology to consumervia open and 206 programmable interfaces. 208 The organization of this draft is as follows. Section 3 provides a 209 discussion for a Business Model, Section 4 a Computation Model, 210 Section 5 a Control and Interface model and Section 6 Design 211 Principles. 213 3. Business Model of ACTN 215 The traditional Virtual Private Network (VPN) and Overlay Network 216 (ON) models are built on the premise that one single network 217 provider provides all virtual private or overlay networks to its 218 consumers. This model is simple to operate but has some 219 disadvantages in accommodating the increasing need for flexible and 220 dynamic network virtualization capabilities. 222 The ACTN model is built upon entities that reflect the current 223 landscape of network virtualization environments. There are three 224 key entities in the ACTN model: 226 - Consumers 227 - Network Providers 228 - Service Providers 230 3.1. Consumers 232 Consumers are the users of virtual network services. As consumers 233 are geographically spread over multiple network provider domains, 234 the necessary control and data interfaces to support such consumer 235 needs is no longer a single interface between the consumer and one 236 single network provider. With this premise, consumers have to 237 interface multiple providers to get their end-to-end network 238 connectivity servjce and the associated topology information. 239 Consumers may have to support multiple virtual network services with 240 differing service objectives and QoS requirements. For flexible and 241 dynamic applications, consumers may want to control their allocated 242 virtual network resources in a dynamic fashion. To allow that, 243 consumers should be given an abstracted view of topology on which 244 they can perform the necessary control decisions and take the 245 corresponding actions. 247 3.2. Service Providers 249 Service providers are the providers of virtual network services to 250 their consumers. Service providers may or may not own physical 251 network resources. When a service provider is the same as the 252 network provider, this is similar to traditional VPN models. This 253 model works well when the consumer maintains a single interface with 254 a single provider. When consumer location spans across multiple 255 independent network provider domains, then it becomes hard to 256 facilitate the creation of end-to-end virtual network services with 257 this model. 259 A more interesting case arises when network providers only provide 260 infrastructure while service providers directly interface their 261 consumers. In this case, service providers themselves are consumers 262 of the network infrastructure providers. One service provider may 263 need to keep multiple independent network providers as its end-users 264 span geographically across multiple network provider domains. The 265 ACTN network model is predicated upon this three tier model. 267 There can be multiple types of service providers. Data Center 268 providers can be viewed as a service provider type as they own and 269 operate data center resources to various WAN clients, they can lease 270 physical network resources from network providers. Internet Service 271 Providers (ISP) can be a service provider of internet services to 272 their customers while leasing physical network resources from 273 network providers. There may be other types of service providers 274 such as mobile virtual network operators (MVNO) that provide mobile 275 services to their end-users without owning the physical network 276 infrastructure. 278 3.3. Network Providers 280 Network Providers are the infrastructure providers that own the 281 physical network resources and provide network resources to their 282 consumers. The layered model proposed by this draft separates the 283 concerns of network providers and consumers, with service providers 284 acting as aggregators of consumer requests. 286 4. Computation Model of ACTN 288 This section discusses ACTN from a computational point of view. As 289 multiple consumers run their virtualized network on a shared 290 infrastructure, making efficient use of the underlying resources 291 requires effective computational models and algorithms. This general 292 problem space is known as Virtual Network Mapping or Embedding (VNM 293 or VNE). (Put some reference). 295 As VNM/VNE issues impose some additional compute models and 296 algorithms for virtual network path computation, this section 297 discusses key issues and constraints for virtual network path 298 computation. 300 4.1. Request Processing 302 This is concerned about whether a set of consumer requests for VN 303 creation can be dealt with simultaneously or not. This depends on 304 the nature of applications the consumer support. If the consumer 305 does not require real-time instantiation of VN creation, the 306 computation engine can process a set of VN creation requests 307 simultaneously to improve network efficiency. 309 4.2. Types of Network Resources 311 When a consumer makes a VN creation request to the substrate 312 network, what kind of network resources is consumed is of concern of 313 both the consumer and network providers. For transport network 314 virtualization, the network resource consumed is primarily network 315 bandwidth that the required paths would occupy on the physical 316 link(s). However, there may be other resource types such as CPU and 317 memory that need to be considered for certain applications. These 318 resource types shall be part of the VN request made by the consumer. 320 4.3. Accuracy of Network Resource Representation 322 As the underlying transport network in itself may consist of a 323 layered structure, it is a challenge how to represent these 324 underlying physical network resources and topology into a form that 325 can be reliably used by the computation engine that assigns consumer 326 requests into the physical network resource and topology. 328 4.4. Resource Efficiency 330 Related to the accuracy of network resource representation is 331 resource efficiency. As a set of independent consumer VN is created 332 and mapped onto physical network resources, the overall network 333 resource utilization is the primary concern of the network provider. 335 4.5. Guarantee of Client Isolation 337 While network resource sharing across a set of consumers for 338 efficient utilization is an important aspect of network 339 virtualization, consumer isolation has to be guaranteed. Admissions 340 of new consumer requests or any changes of other existing consumer 341 VNs must not affect any particular consumer in terms of resource 342 guarantee, security constraints, and other performance constraints. 344 4.6. Computing Time 346 Depending on the nature of applications, how quickly a VN is 347 instantiated from the time of request is an important factor. For 348 dynamic applications that require instantaneous VN creation, the 349 computation model/algorithm should support this constraint. 351 4.7. Admission Control 353 To coordinate the request process of multiple consumers, an 354 admission control will help maximize an overall efficiency. 356 4.8. Path Constraints 358 There may be some factors of path constraints that can affect the 359 overall efficiency. Path Split can lower VN request blocking if the 360 underlying network can support such capability. A packet-based TE 361 network can support path split while circuit-based transport may 362 have limitations. 364 Path migration is a technique that allows changes of nodes or link 365 assignments of the established paths in an effort to accommodate new 366 requests that would not be accepted without such path migration(s). 367 This can improve overall efficiency, yet additional care needs to be 368 applied to avoid any adverse impacts associated with changing the 369 existing paths. 371 Re-optimization is a global process to re-shuffle all existing path 372 assignments to minimize network resource fragmentation. Again, an 373 extra care needs to be applied for re-optimization. 375 5. Control and Interface Model for ACTN 377 This section provides a high-level control and interface model of 378 ACTN. 380 5.1. A High-level ACTN Control Architecture 382 To allow virtualization, the network has to provide open, 383 programmable interfaces in which consumer applications can create, 384 replace and modify virtual network resources in an interactive, 385 flexible and dynamic fashion while having no impact on other network 386 consumers. Direct consumer control of transport network elements 387 over existing interfaces (control or management plane) is not 388 perceived as a viable proposition for transport network providers 389 due to security and policy concerns among other reasons. In 390 addition, as discussed in the previous section, the network control 391 plane for transport networks has been separated from data plane and 392 as such it is not viable for the consumer to directly interface with 393 transport network elements. 395 While the current network control plane is well suited for control 396 of physical network resources via dynamic provisioning, path 397 computation, etc., a virtual network controller needs to be built on 398 top of physical network controller to support network 399 virtualization. On a high-level, virtual network control refers to a 400 mediation layer that performs several functions: 402 - Computation of consumer resource requests into virtual network 403 paths based on the global network-wide abstracted topology; 405 - Mapping and translation of consumer virtual network slices into 406 physical network resources; 408 - Creation of an abstracted view of network slices allocated to each 409 consumer, according to consumer-specific objective functions, and 410 to the consumer traffic profile. 412 In order to facilitate the above-mentioned virtual control 413 functions, the virtual network controller (aka., "virtualizer") 414 needs to maintain two interfaces: 416 - One interface with the physical network controller functions 417 assumed by MPLS/GMPLS and PCE, which is termed as the VNC-PNC 418 Interface (VPI); 420 - Another interface with the consumer controller for the virtual 421 network, which is termed as Client-VNC Interface (CVI). 423 Figure 1 depicts a high-level control and interface architecture for 424 ACTN. 426 ------------------------------------------ 427 | Application Layer | 428 ------------------------------------------ 429 /|\ /|\ /|\ 430 | | \|/ Northbound API 431 | | --------------- 432 | \|/ | Consumer | 433 | --------------- Controller | 434 \|/ | Consumer |------------ 435 -------------- Controller | /|\ 436 | Consumer |----------- | 437 | Controller | /|\ | 438 -------------- | | 439 /|\ | | Consumer-VNC 440 | | | Interface (CVI) 441 \|/ \|/ \|/ 442 ----------------------------------- 443 | Virtual Network Controller (VNC) | 444 ----------------------------------- 445 /|\ 446 | VNC-PNC Interface (VPI) 447 \|/ 448 ----------------------------------- 449 | Physical Network Controller (PNC) | 450 ----------------------------------- 451 /|\ 452 | Control Interface to NEs 453 \|/ 455 Physical Network Infrastructure 457 Figure 1: Control and Interface Architecture for ACTN. 459 Figure 1 shows that there are multiple consumer controllers, which 460 are independent to one another, and that each consumer supports 461 various business applications over its NB API. There are layered 462 client-server relationships in this architecture. As various 463 applications are clients to the consumer controller, it also becomes 464 itself a client to the virtual network controller. Likewise, the 465 virtual network controller is also a client to the physical network 466 controller. This layered relationship is important in the protocol 467 definition work on the NB API, the CVI and VPI interfaces as this 468 allows third-party software developers to program client controllers 469 and virtual network controllers independently. 471 5.2. Consumer Controller 473 A Virtual Network Service is instantiated by the consumer controller 474 via the CVI. As the consumer controller directly interfaces the 475 application stratum, it understands multiple application 476 requirements and their service needs. It is assumed that the 477 consumer controller and the VNC have a common knowledge on the end- 478 point interfaces based on their business negotiation prior to 479 service instantiation. End-point interfaces refer to consumer- 480 network physical interfaces that connect consumer premise equipment 481 to network provider equipment. Figure 2 shows an example physical 482 network topology that supports multiple consumers. In this example, 483 consumer A has three end-points A.1, A.2 and A.3. The interfaces 484 between consumers and transport networks are assumed to be 40G OTU 485 links. For simplicity's sake, all network interfaces are assumed to 486 be 40G OTU links and all network ports support ODU switching and 487 grooming on the level of ODU1 and ODU2. Consumer controller for A 488 provides its traffic demand matrix that describes bandwidth 489 requirements and other optional QoS parameters (e.g., latency, 490 diversity requirement, etc.) for each pair of end-point connections. 492 5.3. Abstracted Topology 494 There are two levels of abstracted topology that needs to be 495 maintained and supported for ACTN. Consumer-specific Abstracted 496 Topology refers to the abstracted view of network resources 497 allocated to the consumer. The granularity of this abstraction 498 varies depending on the nature of consumer applications. Figure 2 499 illustrates this. 501 Figure 2 shows how three independent consumers A, B and C provide 502 its respective traffic demand matrices to the VNC. The physical 503 network topology shown in Figure 2 is the provider's network 504 topology generated by the PNC topology creation engine such as the 505 link state database (LSDB) and Traffic Engineering DB (TEDB) based 506 on control plane discovery function. This topology is internal to 507 PNC and not available to consumers. What is available to them is an 508 abstracted network topology (a virtual network topology) based on 509 the negotiated level of abstraction. This is a part of VNS 510 instantiation between a client control and VNC. 512 +------+ +------+ +------+ 513 A.1 ------o o-----------o o----------o o------- A.2 514 B.1 ------o 1 | | 2 | | 3 | 515 C.1 ------o o-----------o o----------o o------- B.2 516 +-o--o-+ +-o--o-+ +-o--o-+ 517 | | | | | | 518 | | | | | | 519 | | | | | | 520 | | +-o--o-+ +-o--o-+ 521 | `-------------o o----------o o------- B.3 522 | | 4 | | 5 | 523 `----------------o o----------o o------- C.3 524 +-o--o-+ +------+ 525 | | 526 | | 527 C.2 A.3 529 Traffic Matrix Traffic Matrix Traffic Matrix 530 for Consumer A for Consumer B for Consumer C 532 A.1 A.2 A.3 B.1 B.2 B.3 C.1 C.2 C.3 533 ------------------- ------------------ ----------------- 534 A.1 - 20G 20G B.1 - 40G 40G C.1 - 20G 20G 535 A.2 20G - 10G B.2 40G - 20G C.2 20G - 10G 536 A.3 20G 10G - B.3 40G 20G - C.3 20G 10G - 538 Figure 2: Physical network topology shared with multiple consumers 539 Figure 3 depicts illustrative examples of different level of 540 topology abstractions that can be provided by the VNC topology 541 abstraction engine based on the physical topology base maintained by 542 the PNC. The level of topology abstraction is expressed in terms of 543 the number of virtual network elements (VNEs) and virtual links 544 (VLs). For example, the abstracted topology for consumer A shows 545 there are 5 VNEs and 10 VLs. This is by far the most detailed 546 topology abstraction with a minimal link hiding compared to other 547 abstracted topologies in Figure 3. 549 (a) Abstracted Topology for Consumer A (5 VNEs and 10 VLs) 551 +------+ +------+ +------+ 552 A.1 ------o o-----------o o----------o o------- A.2 553 | 1 | | 2 | | 3 | 554 | | | | | | 555 +-o----+ +-o----+ +-o----+ 556 | | | 557 | | | 558 | | | 559 | +-o----+ +-o--o-+ 560 | | | | | 561 | | 4 | | 5 | 562 `----------------o o----------o | 563 +----o-+ +------+ 564 | 565 | 566 A.3 568 (b) Abstracted Topology for Consumer B (3 VNEs and 6 VLs) 570 +------+ +------+ 571 B.1 ------o o-----------------------------o o------ B.2 572 | 1 | | 3 | 573 | | | | 574 +-o----+ +-o----+ 575 \ | 576 \ | 577 \ | 578 `------------------- | 579 ` +-o----+ 580 \ | o------ B.3 581 \ | 5 | 582 `-------o | 583 +------+ 585 (c) Abstracted Topology for Consumer C (1 VNE and 3 VLs) 587 +-------------------------------------------+ 588 | | 589 | | 590 C.1 ------o | 591 | | 592 | | 593 | | 594 | o--------C.3 595 | | 596 +--------------------o----------------------+ 597 | 598 | 599 | 600 | 601 C.2 603 Figure 3: Topology Abstraction Examples for Consumers 605 As different consumers have different control/application needs, 606 abstracted topologies for consumers B and C, respectively show a 607 much higher degree of abstraction. The level of abstraction is 608 determined by the policy (e.g., the granularity level) placed for 609 the consumer and/or the path computation results by the PCE operated 610 by the PNC. The more granular the abstraction topology is, the more 611 control is given to the consumer controller. If the consumer 612 controller has applications that require more granular control of 613 virtual network resources, then the abstracted topology shown for 614 consumer A may be the right abstraction level for such controller. 615 For instance, if the consumer is a third-party virtual service 616 broker/provider, then it would desire much more sophisticated 617 control of virtual network resources to support different 618 application needs. On the other hand, if the consumer were only to 619 support simple tunnel services to its applications, then the 620 abstracted topology shown for consumer C (one VNE and three VLs) 621 would suffice. 623 5.4. Workflows of ACTN Control Modules 625 Figure 4 shows workflows across the consumer controller, VNC and PNC 626 for the VNS instantiation, topology exchange, and VNS setup. 628 The consumer controller "owns" a VNS and initiates it by providing 629 the instantiation identifier with a traffic demand matrix that 630 includes path selection constraints for that instance. This VNS 631 instantiation request from the Consumer Controller triggers a path 632 computation request by the virtual PCE (vPCE) agent in the VNC after 633 VNC's proxy's interlay of this request to the vPCE. vPCE sends a 634 concurrent path computation request that is converted according to 635 the traffic demand matrix as part of the VNS instantiation request 636 from the Consumer Controller. Upon receipt of this path computation 637 request, the PCE in the PNC block computes paths and updates network 638 topology DB and informs the vPCE agent of the VNC of the paths and 639 topology updates. 641 ------------------------------------------------------------------ 642 | Consumer ----------------------------------------------- | 643 | Controller | VNS Control | | 644 | ----------------------------------------------- | 645 ------------------------------------------------------------------ 646 1.VNS | /|\ 4. Abstracted | /|\ 647 Instantiation | | Topology | | 648 (instance id, | | | | 649 Traffic Matr.) | | | | 8. VNS 650 | | 5. VNS | | Set-up 651 \|/ | Set-up \|/ | Confirm 652 ------------------------------------------------------------------ 653 | Virtual ----------------------------------------------- | 654 | Network | VNS Proxy | | 655 | Controller ----------------------------------------------- | 656 | ----------------------- ----------------------- | 657 | | vPCE Agent | | vConnection Agent | | 658 | ----------------------- ----------------------- | 659 ------------------------------------------------------------------ 660 2. Path | /|\ 3. PC Reply | /|\ 661 Computation | | with updated | | 662 Request | | topology | | 663 | | 6. Network | |8.Network 664 | | Provisioning | |Provisioning 665 \|/ | Request \|/ |Confirm 666 ------------------------------------------------------------------ 667 | Physical ------------- -------------------------- | 668 | Network | PCE | | Network Provisioning || 669 | Controller ------------- -------------------------- | 670 ------------------------------------------------------------------ 672 Figure 4. Workflows across Consumer Controller, VNC and PNC 674 It is assumed that the PCE in PNC is a stateful PCE [PCE-S]. vPCE 675 agent abstracts the network topology into an abstracted topology for 676 the consumer based on the agreed-upon granularity level. The 677 abstracted topology is then passed to the VNS control of the 678 Consumer Controller. This controller computes and assigns virtual 679 network resources for its applications based on the abstracted 680 topology and creates VNS setup command to the VNC. The VNC 681 vConnection module turns this VN setup command into network 682 provisioning requests over the network elements using control plane 683 messages such as GMPLS, etc. 685 5.5. Programmability of the ACTN Interfaces 687 From Figures 1 and 4, we have identified several interfaces that are 688 of interest of the ACTN model. More precisely, ACTN concerns the 689 following interfaces: 691 - Consumer-VNC Interface (CVI): an interface between a consumer 692 controller and a virtual network controller. 694 - VNC-PNC Interface (VPI): an interface between a virtual network 695 controller and a physical network controller. 697 The NBI interfaces and direct control interfaces to NEs are outside 698 of the scope of ACTN. 700 The CVI interface should allow programmability, first of all, to the 701 consumer so they can create, modify and delete virtual service 702 instances. This interface should also support open standard 703 information and data models that can transport abstracted topology. 705 The VPI interface should allow programmability to service 706 provider(s) (through VNCs) in such ways that control functions such 707 as path computation, provisioning, and restoration can be 708 facilitated. Seamless mapping and translation between physical 709 resources and virtual resources should also be facilitated via this 710 interface. 712 6. Design Principles of ACTN 714 6.1. Network Security 716 Network security concerns are always one of the primary principles 717 of any network design. ACTN is no exception. Due to the nature of 718 heterogeneous VNs that are to be created, maintained and deleted 719 flexibly and dynamically and the anticipated interaction with 720 physical network control components, secure programming models and 721 interfaces have to be available beyond secured tunnels, encryption 722 and other network security tools. 724 6.2. Privacy and Isolation 726 As physical network resources are shared with and controlled by 727 multiple independent consumers, isolation and privacy for each 728 consumer has to be guaranteed. 730 Policy should be applied per client. 732 6.3. Scalability 734 As multiple VNs need to be supported seamlessly, there are 735 potentially several scaling issues associated with ACTN. The VN 736 Controller system should be scalable in supporting multiple parallel 737 computation requests from multiple consumers. New VN request should 738 not affect the control and maintenance of the existing VNs. Any VN 739 request should also be satisfied within a time-bound of the consumer 740 application request. 742 Interfaces should also be scalable as a large amount of data needs 743 to be transported across consumers to virtual network controllers 744 and across virtual network controllers and physical network 745 controllers. 747 6.4. Manageability and Orchestration 749 As there are multiple entities participating in network 750 virtualization, seamless manageability has to be provided across 751 every layer of network virtualization. Orchestration is an important 752 aspect of manageability as the ACTN design should allow 753 orchestration capability. 755 ACTN orchestration should encompass network provider multi-domains, 756 relationships between service provider(s) and network provider(s), 757 and relationships between consumers and service/network providers. 759 Ease of deploying end-to-end virtual network services across 760 heterogeneous network environments is a challenge. 762 6.5. Programmability 764 As discussed earlier in Section 5.5, the ACTN interfaces should 765 support open standard interfaces to allow flexible and dynamic 766 virtual service creation environments. 768 6.6. Network Stability 770 As multiple VNs are envisioned to share the same physical network 771 resources, combining many resources into one should not cause any 772 network instability. Provider network oscillation can affect readily 773 both on virtual networks and the end-users. 775 Part of network instability can be caused when virtual network 776 mapping is done on an inaccurate or unreliable resource data. Data 777 base synchronization is one of the key issues that need to be 778 ensured in ACTN design. 780 7. References 782 7.1. Informative References 784 [PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 785 Computation Element (PCE)-Based Architecture", IETF RFC 786 4655, August 2006. 788 [PCE-S] Crabbe, E, et. al., "PCEP extension for stateful 789 PCE",draft-ietf-pce-stateful-pce, work in progress. 791 [GMPLS] Manning, E., et al., "Generalized Multi-Protocol Label 792 Switching (GMPLS) Architecture", RFC 3945, October 2004. 794 [NFV-AF] "Network Functions Virtualization (NFV); Architectural 795 Framework", ETSI GS NFV 002 v1.1.1, October 2013. 797 8. Contributors 798 Authors' Addresses 800 Daniel Ceccarelli 801 Email: daniele.ceccarelli@ericsson.com 803 Luyuan Fang 804 Email: luyuanf@gmail.com 806 Young Lee 807 Huawei Technologies 808 5340 Legacy Drive 809 Plano, TX 75023, USA 810 Phone: (469)277-5838 811 Email: leeyoung@huawei.com 813 Diego Lopez 814 Telefonica I+D 815 Don Ramon de la Cruz, 82 816 28006 Madrid, Spain 817 Email: diego@tid.es 819 Intellectual Property Statement 821 The IETF Trust takes no position regarding the validity or scope of 822 any Intellectual Property Rights or other rights that might be 823 claimed to pertain to the implementation or use of the technology 824 described in any IETF Document or the extent to which any license 825 under such rights might or might not be available; nor does it 826 represent that it has made any independent effort to identify any 827 such rights. 829 Copies of Intellectual Property disclosures made to the IETF 830 Secretariat and any assurances of licenses to be made available, or 831 the result of an attempt made to obtain a general license or 832 permission for the use of such proprietary rights by implementers or 833 users of this specification can be obtained from the IETF on-line 834 IPR repository at http://www.ietf.org/ipr 836 The IETF invites any interested party to bring to its attention any 837 copyrights, patents or patent applications, or other proprietary 838 rights that may cover technology that may be required to implement 839 any standard or specification contained in an IETF Document. Please 840 address the information to the IETF at ietf-ipr@ietf.org. 842 Disclaimer of Validity 844 All IETF Documents and the information contained therein are 845 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 846 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 847 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 848 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 849 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 850 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 851 FOR A PARTICULAR PURPOSE. 853 Acknowledgment 855 Funding for the RFC Editor function is currently provided by the 856 Internet Society.