idnits 2.17.1 draft-ceccarelli-actn-framework-02.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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character 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 date (May 30, 2014) is 3617 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4655' is mentioned on line 104, but not defined == Missing Reference: 'RFC5440' is mentioned on line 105, but not defined == Missing Reference: 'ONF' is mentioned on line 755, but not defined == Unused Reference: 'NFV-AF' is defined on line 1058, but no explicit reference was found in the text Summary: 3 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 Daniele Ceccarelli 2 Internet Draft Ericsson 4 Intended status: Informational Luyuan Fang 5 Expires: November 2014 Microsoft 7 Young Lee 8 Huawei 10 Diego Lopez 11 Telefonica 13 May 30, 2014 15 Framework for Abstraction and Control of Transport Networks 17 draft-ceccarelli-actn-framework-02.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 November 30, 2014. 42 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 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.........................................6 66 3.1. Customers.................................................6 67 3.2. Service Providers.........................................7 68 3.3. Network Providers.........................................9 69 4. Multi domain management........................................9 70 5. Computation Model of ACTN.....................................10 71 5.1. Request Processing.......................................11 72 5.2. Types of Network Resources...............................11 73 5.3. Accuracy of Network Resource Representation..............11 74 5.4. Resource Sharing and Efficiency..........................12 75 5.5. Guarantee of Client Isolation............................12 76 5.6. Computing Time...........................................12 77 5.7. Admission Control........................................12 78 5.8. Path Constraints.........................................12 79 6. Control and Interface Model for ACTN..........................13 80 6.1. A High-level ACTN Control Architecture...................13 81 6.2. Customer Controller......................................15 82 6.3. Virtual Network Controller...............................16 83 6.4. Physical Network Controller..............................17 84 6.5. Abstracted Topology......................................18 85 6.6. Workflows of ACTN Control Modules........................21 86 6.7. Programmability of the ACTN Interfaces...................23 88 7. Design Principles of ACTN.....................................23 89 7.1. Network Security.........................................23 90 7.2. Privacy and Isolation....................................24 91 7.3. Scalability..............................................24 92 7.4. Manageability and Orchestration..........................24 93 7.5. Programmability..........................................24 94 7.6. Network Stability........................................25 95 8. References....................................................25 96 8.1. Informative References...................................25 97 9. Contributors..................................................25 98 Authors' Addresses...............................................26 99 Intellectual Property Statement..................................26 100 Disclaimer of Validity...........................................27 102 1. Terminology 104 This document uses the terminology defined in [RFC4655], and 105 [RFC5440]. 107 CVI Customer-VNC Interface 109 PCA Path Computation Agent 111 PNC Physical Network Controller 113 VL Virtual Link 115 VN Virtual Network 117 VNM Virtual Network Mapping 119 VNC Virtual Network Controller 121 VNE Virtual Network Element 123 VNS Virtual Network Service 125 VPI VNC-PNC Interface 127 2. Introduction 129 Transport networks have a variety of mechanisms to facilitate 130 separation of data plane and control plane including distributed 131 signaling for path setup and protection, centralized path 132 computation for planning and traffic engineering, and a range of 133 management and provisioning protocols to configure and activate 134 network resources. These mechanisms represent key technologies for 135 enabling flexible and dynamic networking. 137 Transport networks in this draft refer to a set of different type of 138 connection-oriented networks, primarily Connection-Oriented Circuit 139 Switched (CO-CS) networks and Connection-Oriented Packet Switched 140 (CO-PS) networks. This implies that at least the following transport 141 networks are in scope of the discussion of this draft: L1 optical 142 networks (e.g., OTN and WDM), MPLS-TP, MPLS-TE, as well as other 143 emerging connection-oriented networks such as Segment Routing (SR). 144 One of the characteristics of these network types is the ability of 145 dynamic provisioning and traffic engineering such that resource 146 guarantee can be provided to their clients. 148 One of the main drivers for Software Defined Networking (SDN) is a 149 physical separation of the network control plane from the data 150 plane. This separation of the control plane from the data plane has 151 been already achieved with the development of MPLS/GMPLS [GMPLS] and 152 PCE [PCE] for TE-based transport networks. In fact, in transport 153 networks such separation of data and control plane was dictated at 154 the onset due to the very different natures of the data plane 155 (circuit switched TDM or WDM) and a packet switched control plane. 156 The physical separation of the control plane and the data plane is a 157 major step towards allowing operators to gain the full control for 158 optimized network design and operation. Moreover, another advantage 159 of SDN is its logically centralized control regime that allows a 160 global view of the underlying network under its control. Centralized 161 control in SDN helps improve network resources utilization from a 162 distributed network control. For TE-based transport network control, 163 PCE is essentially equivalent to a logically centralized control for 164 path computation function. 166 As transport networks evolve, the need to provide network 167 abstraction has emerged as a key requirement for operators; this 168 implies in effect the virtualization of network resources so that 169 the network is "sliced" for different uses, applications, services, 170 and customers each being given a different partial view of the total 171 topology and each considering that it is operating with or on a 172 single, stand-alone and consistent network. Moreover, particular 173 attention needs to be paid to the multi-domain case, where ACTN can 174 facilitate virtual network operation via the creation of a single 175 virtualized network. This supports operators in viewing and 176 controlling different domains (at any dimension: applied technology, 177 administrative zones, or vendor-specific technology islands) as a 178 single virtualized network. 180 Network virtualization, in general, refers to allowing the customers 181 to utilize a certain amount of network resources as if they own them 182 and thus control their allocated resources in a way most optimal 183 with higher layer or application processes. This empowerment of 184 customer control facilitates introduction of new services and 185 applications as the customers are permitted to create, modify, and 186 delete their virtual network services. The level of virtual control 187 given to the customers can vary from a tunnel connecting two end- 188 points to virtual network elements that consist of a set of virtual 189 nodes and virtual links in a mesh network topology. More flexible, 190 dynamic customer control capabilities are added to the traditional 191 VPN along with a customer specific virtual network view. Customers 192 control a view of virtual network resources, specifically allocated 193 to each one of them. This view is called an abstracted network 194 topology. Such a view may be specific to the set of consumed 195 services as well as to a particular customer. As the customer 196 controller is envisioned to support a plethora of distinct 197 applications, there would be another level of virtualization from 198 the customer to individual applications. 200 The virtualization framework described in this draft is named 201 Abstraction and Control of Transport Network (ACTN) and facilitates: 203 - Abstraction of the underlying network resources to higher-layer 204 applications and users (customers); 206 - Slicing infrastructure to connect multiple customers to meet 207 specific application and users requirements; 209 - Creation of a virtualized environment allowing operators to 210 view and control multi-subnet multi-technology networks into a 211 single virtualized network; 213 - A computation scheme, via an information model, to serve 214 various customers that request network connectivity and 215 properties associated with it; 217 - A virtual network controller that adapts customer requests to 218 the virtual resources (allocated to them) to the supporting 219 physical network control and performs the necessary mapping, 220 translation, isolation and security/policy enforcement, etc.; 222 - The coordination of the underlying transport topology, 223 presenting it as an abstracted topology to the customers via 224 open and programmable interfaces. 226 The organization of this draft is as follows. Section 3 provides a 227 discussion for a Business Model, Section 4 a Computation Model, 228 Section 5 a Control and Interface model and Section 6 Design 229 Principles. 231 3. Business Model of ACTN 233 The traditional Virtual Private Network (VPN) and Overlay Network 234 (ON) models are built on the premise that one single network 235 provider provides all virtual private or overlay networks to its 236 customers. This model is simple to operate but has some 237 disadvantages in accommodating the increasing need for flexible and 238 dynamic network virtualization capabilities. 240 The ACTN model is built upon entities that reflect the current 241 landscape of network virtualization environments. There are three 242 key entities in the ACTN model [REF probl stat]: 244 - Customers 245 - Service Providers 246 - Network Providers 248 3.1. Customers 250 Within the ACTN framework, different types of customers may be taken 251 into account depending on the type of their resource needs, on their 252 number and type of access. As example, it is possible to group them 253 into two main categories: 255 Basic Customer: Basic customers include fixed residential users, 256 mobile users and small enterprises. Usually the number of basic 257 customers is high; they require small amounts of resources and are 258 characterized by steady requests (relatively time invariant). A 259 typical request for a basic customer is for a bundle of voice 260 service and internet access. 262 Advanced Customer: Advanced customers typically include enterprises, 263 governments and utilities. Such customers can ask for both point to 264 point and multipoint connectivity with high resource demand 265 significantly varying in time and from customer to customer. This is 266 one of reasons why a bundled services offer is not enough but it is 267 desirable to provide each of them with customized virtual network 268 services. As customers are geographically spread over multiple 269 network provider domains, the necessary control and data interfaces 270 to support such customer needs is no longer a single interface 271 between the customer and one single network provider. With this 272 premise, customers have to interface multiple providers to get their 273 end-to-end network connectivity service and the associated topology 274 information. Customers may have to support multiple virtual network 275 services with differing service objectives and QoS requirements. For 276 flexible and dynamic applications, customers may want to control 277 their allocated virtual network resources in a dynamic fashion. To 278 allow that, customers should be given an abstracted view of topology 279 on which they can perform the necessary control decisions and take 280 the corresponding actions. 282 Customers of a given service provider can in turn offer a service to 283 other customers in a recursive way. An example of recursiveness with 284 2 service providers is shown below. 286 - Customer (of service B) 287 - Customer (of service A) & Service Provider (of service B) 288 - Service Provider (of service A) 289 - Network Provider 291 +---------------------------------------------------------------+ --- 292 | | ^ 293 | Customer (of service B)| . 294 | +-------------------------------------------------------+ | B 295 | | | | --- . 296 | |Customer(of service A) & Service Provider(of service B)| | ^ . 297 | | +------------------------------------------------+ | | . . 298 | | | | | | . . 299 | | | Service Provider (of service A)| | | A . 300 | | |+ --------------------------------------+ | | | . . 301 | | || | | | | . . 302 | | || Network provider| | | | v v 303 | | |+---------------------------------------+ | | | ------- 304 | | +------------------------------------------------+ | | 305 | +-------------------------------------------------------+ | 306 +---------------------------------------------------------------+ 308 3.2. Service Providers 310 Service providers are the providers of virtual network services to 311 their customers. Service providers may or may not own physical 312 network resources. When a service provider is the same as the 313 network provider, this is similar to traditional VPN models. This 314 model works well when the customer maintains a single interface with 315 a single provider. When customer location spans across multiple 316 independent network provider domains, then it becomes hard to 317 facilitate the creation of end-to-end virtual network services with 318 this model. 320 A more interesting case arises when network providers only provide 321 infrastructure while service providers directly interface their 322 customers. In this case, service providers themselves are customers 323 of the network infrastructure providers. One service provider may 324 need to keep multiple independent network providers as its end-users 325 span geographically across multiple network provider domains. 327 Customer X -----------------------------------X 329 Service Provider A X -----------------------------------X 331 Network Provider B X-----------------X 333 Network Provider A X------------------X 335 The ACTN network model is predicated upon this three tier model and 336 is summarized in figure below: 338 +----------------------+ 339 | customer | 340 +----------------------+ 341 | 342 | /\ Service/Customer specific 343 | || Abstract Topology 344 | || 345 +----------------------+ 346 | VNC | E2E abstract 347 | Service Provider | topology creation 348 +----------------------+ 349 / | \ 350 / | \ Network Topology 351 / | \ (raw or abstract) 352 / | \ 353 +------------------+ +------------------+ +------------------+ 354 |Network Provider 1| |Network Provider 2| |Network Provider 3| 355 +------------------+ +------------------+ +------------------+ 356 Figure 1: Three tier model. 358 There can be multiple types of service providers. 360 . Data Center providers: can be viewed as a service provider type 361 as they own and operate data center resources to various WAN 362 clients, they can lease physical network resources from network 363 providers. 364 . Internet Service Providers (ISP): can be a service provider of 365 internet services to their customers while leasing physical 366 network resources from network providers. 367 . Mobile Virtual Network Operators (MVNO): provide mobile 368 services to their end-users without owning the physical network 369 infrastructure. 371 3.3. Network Providers 373 Network Providers are the infrastructure providers that own the 374 physical network resources and provide network resources to their 375 customers. The layered model proposed by this draft separates the 376 concerns of network providers and customers, with service providers 377 acting as aggregators of customer requests. 379 4. Multi domain management 381 Network operators build and operate multi-domain networks and these 382 domains may be technology, administrative or vendor specific (vendor 383 islands). Interoperability for dealing with different domains is a 384 perpetual problem for operators. Due to these issues, new service 385 introduction, often requiring connections that traverse multiple 386 domains, need significant planning, and several manual operations to 387 interface different vendor equipment and technology. 389 The creation of a virtualized environment allowing operators to view 390 and control multi-subnet multi-technology networks into a single 391 virtualized network highly facilitates network operators and will 392 accelerate rapid service deployment of new services, including more 393 dynamic and elastic services, and improve overall network operations 394 and scaling of existing services. 396 Figure 2 depict a common scenario in which two different domains can 397 be managed by a single VNC, which is in charge of acting as 398 orchestrator between them and presenting them as a single entity to 399 its clients. 401 +-------------------------+ 402 | VNC | 403 | | 404 +-------------------------+ 405 * 406 +------------+---------+--+ * +-----------+---------+--+ 407 | +---------+ | * | +---------+ | 408 | | PNC ************************* PNC | | 409 | +---------+---------+ | * | +---------+---------+ | 410 | | | | * | | | | 411 | | | | * | | | | 412 | | | | * | | | | 413 | | Packet | | * | | Packet | | 414 | +-------------------+ | * | +-------------------+ | 415 | | * | | 416 | | * | | 417 | | * | | 418 | | * | | 419 | | * | | 420 | +---------+ | * | +---------+ | 421 | | PNC ************************* PNC | | 422 | +---------+---------+ | | +---------+---------+ | 423 | | | | | | | | 424 | | | | | | | | 425 | | | | | | | | 426 | | Optical | | | | Optical | | 427 | +-------------------+ | | +-------------------+ | 428 +---+-------------------+-+ +--+-------------------+-+ 430 Domain 1 Domain 2 432 Figure 2: Multi domain management 434 In this figure the case of packet and optical domains controlled by 435 different PNCs is shown but any combination can be considered, like 436 e.g. a single PNC controlling the packet+optical domain 1 and 437 different PNCs for domains 2. 439 5. Computation Model of ACTN 441 This section discusses ACTN framework from a computational point of 442 view. As multiple customers run their virtualized network on a 443 shared infrastructure, making efficient use of the underlying 444 resources requires effective computational models and algorithms. 445 This general problem space is known as Virtual Network Mapping or 446 Embedding (VNM or VNE). [Editors's note(Put some reference)]. 448 As VNM/VNE issues impose some additional compute models and 449 algorithms for virtual network path computation, this section 450 discusses key issues and constraints for virtual network path 451 computation. 453 5.1. Request Processing 455 This is concerned about whether a set of customer requests for VN 456 creation can be dealt with in real-time or off line, and in the 457 latter case, simultaneously or not. This depends on the nature of 458 applications the customer support. There are applications and use 459 cases, like e.g. management of catastrophic events or real time SLA 460 negotiation, that require a real-time VN creation. If the customer 461 does not require real-time instantiation of VN creation, the 462 computation engine can process a set of VN creation requests 463 simultaneously to improve network efficiency. 465 5.2. Types of Network Resources 467 When a customer makes a VN creation request to the substrate 468 network, what kind of network resources is consumed is of concern of 469 both the customer and service/network providers. The customer needs 470 to put constraints (e.g. TE parameters, resiliency) for the 471 provisioning of the VN, while the service and network providers need 472 to choose which resources meet such constraints and possibly have 473 fewest impact on the capability of serving other customers. For 474 transport network virtualization, the network resource consumed is 475 primarily network bandwidth that the required paths would occupy on 476 the physical link(s). However, there may be other resource types 477 such as CPU and memory that need to be considered for certain 478 applications. These resource types shall be part of the VN request 479 made by the customer. 481 5.3. Accuracy of Network Resource Representation 483 As the underlying transport network in itself may consist of a 484 layered structure, it is a challenge how to represent these 485 underlying physical network resources and topology into a form that 486 can be reliably used by the computation engine that assigns customer 487 requests into the physical network resource and topology. 489 5.4. Resource Sharing and Efficiency 491 Related to the accuracy of network resource representation is 492 resource efficiency. As a set of independent customer VN is created 493 and mapped onto physical network resources, the overall network 494 resource utilization is the primary concern of the network provider. 496 In order to provide an efficient utilization of the resources of the 497 provider network, it should be possible to share given physical 498 resources among a number of different VNs. Whether a virtual 499 resource is sharable among a set of VNs (and hence of customers) is 500 something the service provider needs to agree with each customer. 501 Preemption and priority management are tools that could help provide 502 an efficient sharing of physical resources among different VNs. 504 5.5. Guarantee of Client Isolation 506 While network resource sharing across a set of customers for 507 efficient utilization is an important aspect of network 508 virtualization, customer isolation has to be guaranteed. Admissions 509 of new customer requests or any changes of other existing customer 510 VNs must not affect any particular customer in terms of resource 511 guarantee, security constraints, and other performance constraints. 513 5.6. Computing Time 515 Depending on the nature of applications, how quickly a VN is 516 instantiated from the time of request is an important factor. For 517 dynamic applications that require instantaneous VN creation or VN 518 changes from the existing one, the computation model/algorithm 519 should support this constraint. 521 5.7. Admission Control 523 To coordinate the request process of multiple customers, an 524 admission control will help maximize an overall efficiency. 526 5.8. Path Constraints 528 There may be some factors of path constraints that can affect the 529 overall efficiency. Path Split can lower VN request blocking if the 530 underlying network can support such capability. A packet-based TE 531 network can support path split while circuit-based transport may 532 have limitations. 534 Path migration is a technique that allows changes of nodes or link 535 assignments of the established paths in an effort to accommodate new 536 requests that would not be accepted without such path migration(s). 537 This can improve overall efficiency, yet additional care needs to be 538 applied to avoid any adverse impacts associated with changing the 539 existing paths. 541 Re-optimization is a global process to re-shuffle all existing path 542 assignments to minimize network resource fragmentation. Again, an 543 extra care needs to be applied for re-optimization. 545 6. Control and Interface Model for ACTN 547 This section provides a high-level control and interface model of 548 ACTN. 550 6.1. A High-level ACTN Control Architecture 552 To allow virtualization, the network has to provide open, 553 programmable interfaces, in which customer applications can create, 554 replace and modify virtual network resources in an interactive, 555 flexible and dynamic fashion while having no impact on other 556 customers. Direct customer control of transport network elements 557 over existing interfaces (control or management plane) is not 558 perceived as a viable proposition for transport network providers 559 due to security and policy concerns among other reasons. In 560 addition, as discussed in the previous section, the network control 561 plane for transport networks has been separated from data plane and 562 as such it is not viable for the customer to directly interface with 563 transport network elements. 565 While the current network control plane is well suited for control 566 of physical network resources via dynamic provisioning, path 567 computation, etc., a virtual network controller needs to be built on 568 top of physical network controller to support network 569 virtualization. On a high-level, virtual network control refers to a 570 mediation layer that performs several functions: 572 - Computation of customer resource requests into virtual network 573 paths based on the global network-wide abstracted topology; 575 - Mapping and translation of customer virtual network slices into 576 physical network resources; 578 - Creation of an abstracted view of network slices allocated to each 579 customer, according to customer-specific objective functions, and 580 to the customer traffic profile. 582 In order to facilitate the above-mentioned virtual control 583 functions, the virtual network controller (aka., "virtualizer") 584 needs to maintain two interfaces: 586 - One interface with the physical network controller functions which 587 is termed as the VNC-PNC Interface (VPI). 589 - Another interface with the customer controller for the virtual 590 network, which is termed as Client-VNC Interface (CVI). 592 Figure 2 depicts a high-level control and interface architecture for 593 ACTN. 595 ------------------------------------------ 596 | Application Layer | 597 ------------------------------------------ 598 /|\ /|\ /|\ 599 | | \|/ Northbound API 600 | | --------------- 601 | \|/ | Customer | 602 | --------------- Controller | 603 \|/ | Customer |------------ 604 -------------- Controller | /|\ 605 | Customer |----------- | 606 | Controller | /|\ | 607 -------------- | | 608 /|\ | | Customer-VNC 609 | | | Interface (CVI) 610 \|/ \|/ \|/ 611 ----------------------------------- 612 | Virtual Network Controller (VNC) | 613 ----------------------------------- 614 /|\ 615 | VNC-PNC Interface (VPI) 616 \|/ 617 ----------------------------------- 618 | Physical Network Controller (PNC) | 619 ----------------------------------- 620 /|\ 621 | Control Interface to NEs 622 \|/ 624 Physical Network Infrastructure 626 Figure 3: Control and Interface Architecture for ACTN. 628 Figure 2 shows that there are multiple customer controllers, which 629 are independent to one another, and that each customer supports 630 various business applications over its NB API. There are layered 631 client-server relationships in this architecture. As various 632 applications are clients to the customer controller, it also becomes 633 itself a client to the virtual network controller. Likewise, the 634 virtual network controller is also a client to the physical network 635 controller. This layered relationship is important in the protocol 636 definition work on the NB API, the CVI and VPI interfaces as this 637 allows third-party software developers to program client controllers 638 and virtual network controllers independently. 640 There are several ways in which the Physical Network Controller 641 manages the network elements, e.g. via management protocols, 642 PCEP+GMPLS, or any other type of protocol. In other words the ACTN 643 architecture both applies to physical networks controlled by control 644 plane protocols (e.g. PCEP+GMPLS) or management plane protocols 645 (e.g. SNMP). 647 6.2. Customer Controller 649 A Virtual Network Service is instantiated by the customer controller 650 via the CVI. As the customer controller directly interfaces the 651 application stratum, it understands multiple application 652 requirements and their service needs. It is assumed that the 653 customer controller and the VNC have a common knowledge on the end- 654 point interfaces based on their business negotiation prior to 655 service instantiation. End-point interfaces refer to customer- 656 network physical interfaces that connect customer premise equipment 657 to network provider equipment. Figure 5 shows an example physical 658 network topology that supports multiple customers. In this example, 659 customer A has three end-points A.1, A.2 and A.3. The interfaces 660 between customers and transport networks are assumed to be 40G OTU 661 links. For simplicity's sake, all network interfaces are assumed to 662 be 40G OTU links and all network ports support ODU switching and 663 grooming on the level of ODU1 and ODU2. Customer controller for A 664 provides its traffic demand matrix that describes bandwidth 665 requirements and other optional QoS parameters (e.g., latency, 666 diversity requirement, etc.) for each pair of end-point connections. 668 6.3. Virtual Network Controller 670 The virtual network controller sits between the consumer controller 671 (the one issuing connectivity requests) and the physical network 672 controller (the one managing the resources). The Virtual Network 673 controller can be collocated with the physical network controller, 674 especially in those cases where the service provider and the network 675 provider are the same entity. 677 The virtual network controller is composed by the following 678 functional components: 680 +------------------------------------------------------------------+ 681 | | 682 | Virtual +-------------+ +------------------------+ | 683 | Network | VNS Proxy | | Abstract Topology DB | | 684 | Controller +-------------+ +------------------------+ | 685 | | 686 | +-------------------+ +-------------------+ +---------------+ | 687 | | Resource Manager | | vConnection Agent | |VNC OAM handler| | 688 | +-------------------+ +-------------------+ +---------------+ | 689 +------------------------------------------------------------------+ 691 . VNS proxy: The VNS proxy is the functional module in charge of 692 performing policy management and AAA (Authentication, 693 authorization, and accounting) functions. It is the one that 694 receives that VN instantiation and resource allocation requests 695 from the Customer controllers. 696 . Abstract Topology DB: This is the database where the abstract 697 topology, generated by the VNC or received from the PNC, is 698 stored. A different VN instance is kept for every different 699 customer. 700 . Resource Manager: The resource manager is in charge of 701 receiving VNS instantiation requests from the customer 702 controller and, as a consequence, triggering a concurrent path 703 computation request to the PCE in the PNC based on the traffic 704 matrix. The Resource manager is also in charge of generating 705 the abstract topology for the customer. 706 . vConnection Agent: This module is in charge of mapping VN setup 707 commands into network provisioning requests to the PNC. 708 . VNC OAM handler: The VNC OAM handler is the module that is in 709 charge of understanding how the network is operating, detecting 710 faults and reacting to problems related to the abstract 711 topology. 713 6.4. Physical Network Controller 715 The physical network controller is the one in charge of configuring 716 the network elements, monitoring the physical topology of the 717 network and passing it, either raw or abstracted, to the VNC. 719 It is composed by the following functional components: 721 +------------------------------------------------------------------+ 722 | | 723 | Physical +-----------+ +-----+ +------------------------+ | 724 | Network | VNC Proxy | | PCE | | Abstract Topology Gen. | | 725 | Controller +-----------+ +-----+ +------------------------+ | 726 | | 727 | +---------------+ +--------------------+ +--------------------+ | 728 | |PNC OAM Handler| |Provisioning Manager| |Physical Topology DB| | 729 | +---------------+ +--------------------+ +--------------------+ | 730 +------------------------------------------------------------------+ 732 . VNC proxy: The VNC proxy is the functional module in charge of 733 performing policy management and AAA (Authentication, 734 authorization, and accounting) functions on requests coming 735 from the VNC. 736 . PCE: This is the stateful PCE performing the path computation 737 over the physical topology and that provides the vConnection 738 agent with the network topology. 739 . Abstract topology generator: the network topology can be passed 740 to the VNC as raw or abstract. In case the topology is passed 741 as abstract topology, this module is in charge of generating it 742 from the physical topology DB. The module is optional. 743 . ONC OAM handler: it verifies that connections exists, 744 implements monitoring functions to see if failures occurs. It 745 is the proxy to an OSS/NMS system but does not duplicate any of 746 OSS/NMS functionalities. 747 . Physical topology database: The physical topology database is 748 mainly composed by two databases: the Traffic Engineering 749 Database (TED) and the LSP Database (LSP-DB). 750 . Provisioning manager: The Provisioning Manager is responsible 751 for making or channeling requests for the establishment of 752 LSPs. This may be instructions to the control plane running in 753 the networks, or may involve the programming of individual 754 network devices. In the latter case, the Provisioning Manager 755 may act as an OpenFlow Controller [ONF]. 757 6.5. Abstracted Topology 759 There are two levels of abstracted topology that needs to be 760 maintained and supported for ACTN. Customer-specific Abstracted 761 Topology refers to the abstracted view of network resources 762 allocated (shared or dedicated) to the customer. The granularity of 763 this abstraction varies depending on the nature of customer 764 applications. Figure 3 illustrates this. 766 Figure 3 shows how three independent customers A, B and C provide 767 its respective traffic demand matrix to the VNC. The physical 768 network topology shown in Figure 2 is the provider's network 769 topology generated by the PNC topology creation engine such as the 770 link state database (LSDB) and Traffic Engineering DB (TEDB) based 771 on control plane discovery function. This topology is internal to 772 PNC and not available to customers. What is available to them is an 773 abstracted network topology (a virtual network topology) based on 774 the negotiated level of abstraction. This is a part of VNS 775 instantiation between a client control and VNC. 777 +------+ +------+ +------+ 778 A.1 ------o o-----------o o----------o o------- A.2 779 B.1 ------o 1 | | 2 | | 3 | 780 C.1 ------o o-----------o o----------o o------- B.2 781 +-o--o-+ +-o--o-+ +-o--o-+ 782 | | | | | | 783 | | | | | | 784 | | | | | | 785 | | +-o--o-+ +-o--o-+ 786 | `-------------o o----------o o------- B.3 787 | | 4 | | 5 | 788 `----------------o o----------o o------- C.3 789 +-o--o-+ +------+ 790 | | 791 | | 792 C.2 A.3 794 Traffic Matrix Traffic Matrix Traffic Matrix 795 for Customer A for Customer B for Customer C 797 A.1 A.2 A.3 B.1 B.2 B.3 C.1 C.2 C.3 798 ------------------- ------------------ ----------------- 799 A.1 - 20G 20G B.1 - 40G 40G C.1 - 20G 20G 800 A.2 20G - 10G B.2 40G - 20G C.2 20G - 10G 801 A.3 20G 10G - B.3 40G 20G - C.3 20G 10G - 803 Figure 4: Physical network topology shared with multiple customers 805 Figure 5 depicts illustrative examples of different level of 806 topology abstractions that can be provided by the VNC topology 807 abstraction engine based on the physical topology base maintained by 808 the PNC. The level of topology abstraction is expressed in terms of 809 the number of virtual network elements (VNEs) and virtual links 810 (VLs). For example, the abstracted topology for customer A shows 811 there are 5 VNEs and 10 VLs. This is by far the most detailed 812 topology abstraction with a minimal link hiding compared to other 813 abstracted topologies in Figure 4. 815 (a) Abstracted Topology for Customer A (5 VNEs and 10 VLs) 817 +------+ +------+ +------+ 818 A.1 ------o o-----------o o----------o o------- A.2 819 | 1 | | 2 | | 3 | 820 | | | | | | 821 +-o----+ +-o----+ +-o----+ 822 | | | 823 | | | 824 | | | 825 | +-o----+ +-o--o-+ 826 | | | | | 827 | | 4 | | 5 | 828 `----------------o o----------o | 829 +----o-+ +------+ 830 | 831 | 832 A.3 834 (b) Abstracted Topology for Customer B (3 VNEs and 6 VLs) 836 +------+ +------+ 837 B.1 ------o o-----------------------------o o------ B.2 838 | 1 | | 3 | 839 | | | | 840 +-o----+ +-o----+ 841 \ | 842 \ | 843 \ | 844 `------------------- | 845 ` +-o----+ 846 \ | o------ B.3 847 \ | 5 | 848 `-------o | 849 +------+ 851 (c) Abstracted Topology for Customer C (1 VNE and 3 VLs) 852 +-------------------------------------------+ 853 | | 854 | | 855 C.1 ------o | 856 | | 857 | | 858 | | 859 | o--------C.3 860 | | 861 +--------------------o----------------------+ 862 | 863 | 864 | 865 | 866 C.2 868 Figure 5: Topology Abstraction Examples for Customers 870 As different customers have different control/application needs, 871 abstracted topologies for customers B and C, respectively show a 872 much higher degree of abstraction. The level of abstraction is 873 determined by the policy (e.g., the granularity level) placed for 874 the customer and/or the path computation results by the PCE operated 875 by the PNC. The more granular the abstraction topology is, the more 876 control is given to the customer controller. If the customer 877 controller has applications that require more granular control of 878 virtual network resources, then the abstracted topology shown for 879 customer A may be the right abstraction level for such controller. 880 For instance, if the customer is a third-party virtual service 881 broker/provider, then it would desire much more sophisticated 882 control of virtual network resources to support different 883 application needs. On the other hand, if the customer were only to 884 support simple tunnel services to its applications, then the 885 abstracted topology shown for customer C (one VNE and three VLs) 886 would suffice. 888 6.6. Workflows of ACTN Control Modules 890 Figure 5 shows workflows across the customer controller, VNC and PNC 891 for the VNS instantiation, topology exchange, and VNS setup. 893 The customer controller "owns" a VNS and initiates it by providing 894 the instantiation identifier with a traffic demand matrix that 895 includes path selection constraints for that instance. This VNS 896 instantiation request from the Customer Controller triggers a path 897 computation request by the Resource Manager in the VNC after VNC's 898 proxy's interlay of this request to the Resource Manager. PCA sends 899 a concurrent path computation request that is converted according to 900 the traffic demand matrix as part of the VNS instantiation request 901 from the Customer Controller. Upon receipt of this path computation 902 request, the PCE in the PNC block computes paths and updates network 903 topology DB and informs the Resource Manager of the VNC of the paths 904 and topology updates. 906 ------------------------------------------------------------------ 907 | Customer ----------------------------------------------- | 908 | Controller | VNS Control | | 909 | ----------------------------------------------- | 910 ------------------------------------------------------------------ 911 1.VNS | /|\ 4. Abstracted | /|\ 912 Instantiation | | Topology | | 913 (instance id, | | | | 914 Traffic Matr.) | | | | 8. VNS 915 | | 5. VNS | | Set-up 916 \|/ | Set-up \|/ | Confirm 917 ------------------------------------------------------------------ 918 | Virtual ----------------------------------------------- | 919 | Network | VNS Proxy | | 920 | Controller ----------------------------------------------- | 921 | ----------------------- ----------------------- | 922 | |Path Computation Agent | | vConnection Agent | | 923 | ----------------------- ----------------------- | 924 ------------------------------------------------------------------ 925 2. Path | /|\ 3. PC Reply | /|\ 926 Computation | | with updated | | 927 Request | | topology | | 928 | | 6. Network | |8.Network 929 | | Provisioning | |Provisioning 930 \|/ | Request \|/ |Confirm 931 ------------------------------------------------------------------ 932 | Physical ------------- -------------------------- | 933 | Network | PCE | | Network Provisioning || 934 | Controller ------------- -------------------------- | 935 ------------------------------------------------------------------ 937 Figure 6. Workflows across Customer Controller, VNC and PNC 939 It is assumed that the PCE in PNC is a stateful PCE [PCE-S]. PCA 940 abstracts the physical network topology into an abstracted topology 941 for the customer based on the agreed-upon granularity level. The 942 abstracted topology is then passed to the VNS control of the 943 Customer Controller. This controller computes and assigns virtual 944 network resources for its applications based on the abstracted 945 topology and creates VNS setup command to the VNC. The VNC 946 vConnection module turns this VN setup command into network 947 provisioning requests over the network elements. 949 6.7. Programmability of the ACTN Interfaces 951 From Figures 2 and 5, we have identified several interfaces that are 952 of interest of the ACTN model. More precisely, ACTN concerns the 953 following interfaces: 955 - Customer-VNC Interface (CVI): an interface between a customer 956 controller and a virtual network controller. 958 - VNC-PNC Interface (VPI): an interface between a virtual network 959 controller and a physical network controller. 961 The NBI interfaces and direct control interfaces to NEs are outside 962 of the scope of ACTN. 964 The CVI interface should allow programmability, first of all, to the 965 customer so they can create, modify and delete virtual network 966 service instances. This interface should also support open standard 967 information and data models that can transport abstracted topology. 969 The VPI interface should allow programmability to service 970 provider(s) (through VNCs) in such ways that control functions such 971 as path computation, provisioning, and restoration can be 972 facilitated. Seamless mapping and translation between physical 973 resources and virtual resources should also be facilitated via this 974 interface. 976 7. Design Principles of ACTN 978 7.1. Network Security 980 Network security concerns are always one of the primary principles 981 of any network design. ACTN is no exception. Due to the nature of 982 heterogeneous VNs that are to be created, maintained and deleted 983 flexibly and dynamically and the anticipated interaction with 984 physical network control components, secure programming models and 985 interfaces have to be available beyond secured tunnels, encryption 986 and other network security tools. 988 7.2. Privacy and Isolation 990 As physical network resources are shared with and controlled by 991 multiple independent customers, isolation and privacy for each 992 customer has to be guaranteed. 994 Policy should be applied per client. 996 7.3. Scalability 998 As multiple VNs need to be supported seamlessly, there are 999 potentially several scaling issues associated with ACTN. The VN 1000 Controller system should be scalable in supporting multiple parallel 1001 computation requests from multiple customers. New VN request should 1002 not affect the control and maintenance of the existing VNs. Any VN 1003 request should also be satisfied within a time-bound of the customer 1004 application request. 1006 Interfaces should also be scalable as a large amount of data needs 1007 to be transported across customers to virtual network controllers 1008 and across virtual network controllers and physical network 1009 controllers. 1011 7.4. Manageability and Orchestration 1013 As there are multiple entities participating in network 1014 virtualization, seamless manageability has to be provided across 1015 every layer of network virtualization. Orchestration is an important 1016 aspect of manageability as the ACTN design should allow 1017 orchestration capability. 1019 ACTN orchestration should encompass network provider multi-domains, 1020 relationships between service provider(s) and network provider(s), 1021 and relationships between customers and service/network providers. 1023 Ease of deploying end-to-end virtual network services across 1024 heterogeneous network environments is a challenge. 1026 7.5. Programmability 1028 As discussed earlier in Section 5.5, the ACTN interfaces should 1029 support open standard interfaces to allow flexible and dynamic 1030 virtual service creation environments. 1032 7.6. Network Stability 1034 As multiple VNs are envisioned to share the same physical network 1035 resources, combining many resources into one should not cause any 1036 network instability. Provider network oscillation can affect readily 1037 both on virtual networks and the end-users. 1039 Part of network instability can be caused when virtual network 1040 mapping is done on an inaccurate or unreliable resource data. Data 1041 base synchronization is one of the key issues that need to be 1042 ensured in ACTN design. 1044 8. References 1046 8.1. Informative References 1048 [PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1049 Computation Element (PCE)-Based Architecture", IETF RFC 1050 4655, August 2006. 1052 [PCE-S] Crabbe, E, et. al., "PCEP extension for stateful 1053 PCE",draft-ietf-pce-stateful-pce, work in progress. 1055 [GMPLS] Manning, E., et al., "Generalized Multi-Protocol Label 1056 Switching (GMPLS) Architecture", RFC 3945, October 2004. 1058 [NFV-AF] "Network Functions Virtualization (NFV); Architectural 1059 Framework", ETSI GS NFV 002 v1.1.1, October 2013. 1061 9. Contributors 1062 Authors' Addresses 1064 Daniele Ceccarelli 1065 Ericsson 1066 Via Melen, 77 1067 Genova, Italy 1068 Email: daniele.ceccarelli@ericsson.com 1070 Luyuan Fang 1071 Email: luyuanf@gmail.com 1073 Young Lee 1074 Huawei Technologies 1075 5340 Legacy Drive 1076 Plano, TX 75023, USA 1077 Phone: (469)277-5838 1078 Email: leeyoung@huawei.com 1080 Diego Lopez 1081 Telefonica I+D 1082 Don Ramon de la Cruz, 82 1083 28006 Madrid, Spain 1084 Email: diego@tid.es 1086 Intellectual Property Statement 1088 The IETF Trust takes no position regarding the validity or scope of 1089 any Intellectual Property Rights or other rights that might be 1090 claimed to pertain to the implementation or use of the technology 1091 described in any IETF Document or the extent to which any license 1092 under such rights might or might not be available; nor does it 1093 represent that it has made any independent effort to identify any 1094 such rights. 1096 Copies of Intellectual Property disclosures made to the IETF 1097 Secretariat and any assurances of licenses to be made available, or 1098 the result of an attempt made to obtain a general license or 1099 permission for the use of such proprietary rights by implementers or 1100 users of this specification can be obtained from the IETF on-line 1101 IPR repository at http://www.ietf.org/ipr 1103 The IETF invites any interested party to bring to its attention any 1104 copyrights, patents or patent applications, or other proprietary 1105 rights that may cover technology that may be required to implement 1106 any standard or specification contained in an IETF Document. Please 1107 address the information to the IETF at ietf-ipr@ietf.org. 1109 Disclaimer of Validity 1111 All IETF Documents and the information contained therein are 1112 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 1113 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 1114 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1115 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1116 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1117 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1118 FOR A PARTICULAR PURPOSE. 1120 Acknowledgment 1122 Funding for the RFC Editor function is currently provided by the 1123 Internet Society.