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