idnits 2.17.1 draft-ceccarelli-teas-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 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 10 instances of too long lines in the document, the longest one being 84 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 136 has weird spacing: '... As network...' == Line 268 has weird spacing: '...r, used to ma...' -- The document date (March 9, 2016) is 2970 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ONF-ARCH' is mentioned on line 667, but not defined == Unused Reference: 'PCE-S' is defined on line 1046, but no explicit reference was found in the text == Unused Reference: 'NFV-AF' is defined on line 1052, but no explicit reference was found in the text == Unused Reference: 'ONF' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'ACTN-Info' is defined on line 1072, but no explicit reference was found in the text == Unused Reference: 'Cheng' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'Dhody' is defined on line 1080, but no explicit reference was found in the text == Unused Reference: 'Fang' is defined on line 1084, but no explicit reference was found in the text == Unused Reference: 'Klee' is defined on line 1088, but no explicit reference was found in the text == Unused Reference: 'Kumaki' is defined on line 1093, but no explicit reference was found in the text == Unused Reference: 'Lopez' is defined on line 1097, but no explicit reference was found in the text == Unused Reference: 'Shin' is defined on line 1101, but no explicit reference was found in the text == Unused Reference: 'Xu' is defined on line 1106, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Daniele Ceccarelli (Ed) 2 Internet Draft Ericsson 3 Intended status: Informational Young Lee (Ed) 4 Expires: November 2016 Huawei 6 March 9, 2016 8 Framework for Abstraction and Control of Traffic Engineered Networks 10 draft-ceccarelli-teas-actn-framework-01 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 9, 2015. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 Traffic Engineered networks have a variety of mechanisms to 53 facilitate the 54 separation of the data plane and control plane. They also have a 55 range of management and provisioning protocols to configure and 56 activate network resources. These mechanisms represent key 57 technologies for enabling flexible and dynamic networking. 59 Abstraction of network resources is a technique that can be applied 60 to a single network domain or across multiple domains to create a 61 single virtualized network that is under the control of a network 62 operator or the customer of the operator that actually owns 63 the network resources. 65 This draft provides a framework for Abstraction and Control of 66 Traffic Engineered Networks (ACTN). 68 Table of Contents 70 1. Introduction ................................................ 3 71 1.1. Terminology ............................................ 5 72 2. Business Model of ACTN ....................................... 7 73 2.1. Customers .............................................. 7 74 2.2. Service Providers ....................................... 9 75 2.3. Network Providers ...................................... 11 76 3. ACTN architecture .......................................... 11 77 3.1. Customer Network Controller ............................ 14 78 3.2. Multi Domain Service Coordinator ....................... 15 79 3.3. Physical Network Controller ............................ 16 80 3.4. ACTN interfaces........................................ 17 81 4. VN creation process ........................................ 19 82 5. Access Points and Virtual Network Access Points ............. 20 83 5.1. Dual homing scenario ................................... 22 84 6. End point selection & mobility ............................. 23 85 6.1. End point selection & mobility ......................... 23 86 6.2. Preplanned end point migration ......................... 24 87 6.3. On the fly end point migration ......................... 25 89 7. Security ................................................... 25 90 8. References ................................................. 25 91 8.1. Informative References ................................. 25 92 9. Contributors ............................................... 28 93 Authors' Addresses ............................................ 28 95 1. Introduction 97 Traffic Engineered networks have a variety of mechanisms to 98 facilitate separation of data plane and control plane including 99 distributed signaling for path setup and protection, centralized 100 path computation for planning and traffic engineering, and a range 101 of management and provisioning protocols to configure and activate 102 network resources. These mechanisms represent key technologies for 103 enabling flexible and dynamic networking. 105 The term Traffic Engineered Network in this draft refers to any 106 connection- 107 oriented network that has the ability of dynamic provisioning, 108 abstracting and orchestrating network resource to 109 the network's clients. Some examples of networks that are in scope 110 of this definition are optical networks, MPLS Transport Profile 111 (MPLS-TP), MPLS Traffic Engineering (MPLS-TE), and other emerging 112 technologies with connection-oriented behavior. 114 One of the main drivers for Software Defined Networking (SDN) is a 115 decoupling of the network control plane from the data plane. This 116 separation of the control plane from the data plane has been already 117 achieved with the development of MPLS/GMPLS [GMPLS] and PCE [PCE] 118 for TE-based transport networks. One of the advantages of SDN is its 119 logically centralized control regime that allows a global view of 120 the underlying network under its control. Centralized control in SDN 121 helps improve network resources utilization compared with 122 distributed network control. For TE-based transport network control, 123 PCE is essentially equivalent to a logically centralized control for 124 path computation function. 126 Two key aspects that need to be solved by SDN are: 128 . Network and service abstraction: Detach the network and service 129 control from underlying technology and help customer express 130 the network as desired by business needs. 132 . Coordination of resources across multiple domains and multiple 133 layers to provide end-to-end services regardless of whether the 134 domains use SDN or not. 136 As networks evolve, the need to provide resource and service 137 abstraction has emerged as a key requirement for operators; this 138 implies in effect the virtualization of network resources so that 139 the network is "sliced" for different tenants shown as a dedicated 140 portion of the network resources 142 Particular attention needs to be paid to the multi-domain case, 143 where Abstraction and Control of Traffic Engineered Networks 144 (ACTN) can facilitate virtual network operation via the creation 145 of a single virtualized network or a seamless service. This 146 supports operators in viewing and controlling different domains 147 (at any dimension: applied technology, administrative zones, or 148 vendor-specific technology islands) as a single virtualized 149 network. 151 Network virtualization refers to allowing the customers of network 152 operators (see Section 2.1) to utilize a certain amount of network 153 resources as if they own them and thus control their allocated 154 resources with higher layer or application processes that enables 155 the resources to be used in the most optimal way. More flexible, 156 dynamic customer control capabilities are added to the traditional 157 VPN along with a customer specific virtual network view. Customers 158 control a view of virtual network resources, specifically allocated 159 to each one of them. This view is called an abstracted network 160 topology. Such a view may be specific to a specific service, the set 161 of consumed resources or to a particular customer. Customer 162 controller of the virtual network is envisioned to support a 163 plethora of distinct applications. This means that there may be a 164 further level of virtualization that provides a view of resources in 165 the customer's virtual network for use by an individual application. 167 The framework described in this draft is named Abstraction and 168 Control of Traffic Engineered Network (ACTN) and facilitates: 170 - Abstraction of the underlying network resources to higher-layer 171 applications and users (customers); abstraction for a specific 172 application or customer is referred to as virtualization in the 173 Optical Networking Foundation (ONF) SDN architecture. [ONF- 174 ARCH] 176 - Slicing infrastructure to connect multiple customers to meet 177 specific customer's service requirements; 179 - Creation of a virtualized environment allowing operators to 180 view and control multi-subnet multi-technology networks into a 181 single virtualized network; 183 - Possibility of providing a customer with abstracted network or 184 abstracted services (totally hiding the network). 186 - A virtualization/mapping network function that adapts customer 187 requests to the virtual resources (allocated to them) to the 188 supporting physical network control and performs the necessary 189 mapping, translation, isolation and security/policy 190 enforcement, etc.; This function is often referred to as 191 orchestration. 193 - The multi-domain coordination of the underlying transport 194 domains, presenting it as an abstracted topology to the 195 customers via open and programmable interfaces. This allows for 196 the recursion of controllers in a customer-provider 197 relationship. 199 A further discussion of the term "abstraction" can be found in 200 [TE-INFO]. 202 1.1. Terminology 204 The following terms are used in this document. Some of them are 205 newly defined, some others reference existing definition: 207 - Node: A node is a topological entity describing the "opaque" 208 forwarding aspect of the topological component which represents 209 the opportunity to enable forwarding between points at the edge 210 of the node. It provides the context for instructing the 211 formation, adjustment and removal of the forwarding. A node, in 212 a VN network, can be represented by single physical entity or 213 by a group of nodes moving from physical to virtual network. 215 - Link: A link is a topological entity describing the effective 216 adjacency between two or more forwarding entities, such as two 217 or more nodes. In its basic form (i.e., point-to-point Link) it 218 associates an edge point of a node with an equivalent edge 219 point on another node. Links in virtual network is in fact 220 connectivity, realized by bandwidth engineering between any two 221 nodes meeting certain criteria, for example, redundancy, 222 protection, latency, not tied to any particular physical 223 characteristics like timeslots, wavelength, packet. The link 224 can be dynamic, realized by a service in underlay, or static. 226 - Virtual Network: A Virtual Network (VN) is a client view of the 227 transport network. It is composed by a set of physical 228 resources sliced in the provider network and presented to the 229 customer as a set of abstract resources i.e. virtual nodes and 230 virtual links. Depending on the agreement between client and 231 provider a VN can be just represented by how the end points can 232 be connected with given SLA attributes(e.g., re satisfying the 233 customer's objectives), or a pre-configured set of physical 234 resources or can be created as outcome of a dynamic request 235 from customer. 236 o In the first case can be seen as an (or set of) e2e 237 connection(s) that can be formed by recursive aggregation 238 of lower level connections at provider level. Such end to 239 end connections include: customer end points, access links 240 (physical or virtual), intra domain tunnels and inter- 241 domain link (physical or virtual). 242 o When VN is pre-configured is provided after a static 243 negotiation between customer and provider while in the 244 third case VN can be dynamically created, deleted, or 245 modified in response to requests from the customer.This 246 implies dynamic changes of network resources reserved for 247 the customer. 248 o In the second and third case , once that customer has 249 obtained his VN, can act upon the virtual network 250 resources to perform connection management (set- 251 up/release/modify connections). 252 - Abstract Topology: Every lower controller in the provider 253 network, when is representing its network topology to an higher 254 layer, it may want to hide details of the actual network 255 topology. In such case, an abstract topology may be used for 256 this purpose. Abstract topology enhances scalability for the 257 MDSC to operate multi-domain networks 259 - Access link: A link between a customer node and a provider 260 node. 262 - Inter domain link: A link between domains managed by different 263 PNCs 265 - Access Point (AP): An access point is defined on an access 266 link. It is used to keep confidentiality between the customer 267 and the provider. It is an identifier shared between the 268 customer and the provider, used to map the end points of the 269 border node in the provider NW. The AP can be used by the 270 customer when requesting connectivity service to the provider. 271 A number of parameters, e.g. available bandwidth, need to be 272 associated to the AP to qualify it. 274 - VN Access Point (VNAP): A VNAP is defined within an AP as part 275 of a given VN and is used to identify the portion of the AP, 276 and hence of the access link) dedicated to a given VN. 278 2. Business Model of ACTN 280 The Virtual Private Network (VPN) [RFC4026] and Overlay Network (ON) 281 models [RFC4208] are built on the premise that one single network 282 provider provides all virtual private or overlay networks to its 283 customers. These models are simple to operate but have some 284 disadvantages in accommodating the increasing need for flexible and 285 dynamic network virtualization capabilities. 287 The ACTN model is built upon entities that reflect the current 288 landscape of network virtualization environments. There are three 289 key entities in the ACTN model [ACTN-PS]: 291 - Customers 292 - Service Providers 293 - Network Providers 295 2.1. Customers 297 Within the ACTN framework, different types of customers may be taken 298 into account depending on the type of their resource needs, on their 299 number and type of access. As example, it is possible to group them 300 into two main categories: 302 Basic Customer: Basic customers include fixed residential users, 303 mobile users and small enterprises. Usually the number of basic 304 customers is high; they require small amounts of resources and are 305 characterized by steady requests (relatively time invariant). A 306 typical request for a basic customer is for a bundle of voice 307 services and internet access. Moreover basic customers do not modify 308 their services themselves; if a service change is needed, it is 309 performed by the provider as proxy and they generally have very few 310 dedicated resources (subscriber drop), with everything else shared 311 on the basis of some SLA, which is usually best-efforts. 313 Advanced Customer: Advanced customers typically include enterprises, 314 governments and utilities. Such customers can ask for both point to 315 point and multipoint connectivity with high resource demand 316 significantly varying in time and from customer to customer. This is 317 one of the reasons why a bundled service offering is not enough and 318 it is desirable to provide each of them with a customized virtual 319 network service. 321 Advanced customers may own dedicated virtual resources, or share 322 resources. They may also have the ability to modify their service 323 parameters within the scope of their virtualized environments. 325 As customers are geographically spread over multiple network 326 provider domains, they have to interface multiple providers and may 327 have to support multiple virtual network services with different 328 underlying objectives set by the network providers. To enable these 329 customers to support flexible and dynamic applications they need to 330 control their allocated virtual network resources in a dynamic 331 fashion, and that means that they need an abstracted view of the 332 topology that spans all of the network providers. 334 ACTN's primary focus is Advanced Customers. 336 Customers of a given service provider can in turn offer a service to 337 other customers in a recursive way. An example of recursiveness with 338 2 service providers is shown below. 340 - Customer (of service B) 341 - Customer (of service A) & Service Provider (of service B) 342 - Service Provider (of service A) 343 - Network Provider 345 +------------------------------------------------------------+ --- 346 | | ^ 347 | Customer (of service B)| . 348 | +--------------------------------------------------------+ | B 349 | | | |--- . 350 | |Customer (of service A) & Service Provider(of service B)| | ^ . 351 | | +---------------------------------------------------+ | | . . 352 | | | | | | . . 353 | | | Service Provider (of service A)| | | A . 354 | | |+------------------------------------------+ | | | . . 355 | | || | | | | . . 356 | | || Network provider| | | | v v 357 | | |+------------------------------------------+ | | |------ 358 | | +---------------------------------------------------+ | | 359 | +--------------------------------------------------------+ | 360 +------------------------------------------------------------+ 362 Figure 1: Network Recursiveness. 364 2.2. Service Providers 366 Service providers are the providers of virtual network services to 367 their customers. Service providers may or may not own physical 368 network resources. When a service provider is the same as the 369 network provider, this is similar to traditional VPN models. This 370 model works well when the customer maintains a single interface with 371 a single provider. When customer location spans across multiple 372 independent network provider domains, then it becomes hard to 373 facilitate the creation of end-to-end virtual network services with 374 this model. 376 A more interesting case arises when network providers only provide 377 infrastructure while service providers directly interface their 378 customers. In this case, service providers themselves are customers 379 of the network infrastructure providers. One service provider may 380 need to keep multiple independent network providers as its end-users 381 span geographically across multiple network provider domains as 382 shown in Figure 2 where Service Provider A uses resources from 383 Network Provider A and Network Provider B to offer a virtualized 384 network to its customer. 386 Customer X -----------------------------------X 387 Service Provider A X -----------------------------------X 389 Network Provider B X-----------------X 391 Network Provider A X------------------X 393 Figure 2: A service Provider as Customer of Two Network Providers. 395 The ACTN network model is predicated upon this three tier model and 396 is summarized in Figure 3: 398 +----------------------+ 399 | customer | 400 +----------------------+ 401 | 402 | /\ Service/Customer specific 403 | || Abstract Topology 404 | || 405 +----------------------+ E2E abstract 406 | Service Provider | topology creation 407 +----------------------+ 408 / | \ 409 / | \ Network Topology 410 / | \ (raw or abstract) 411 / | \ 412 +------------------+ +------------------+ +------------------+ 413 |Network Provider 1| |Network Provider 2| |Network Provider 3| 414 +------------------+ +------------------+ +------------------+ 416 Figure 3: Three tier model. 418 There can be multiple types of service providers. 420 . Data Center providers: can be viewed as a service provider type 421 as they own and operate data center resources to various WAN 422 clients, they can lease physical network resources from network 423 providers. 424 . Internet Service Providers (ISP): can be a service provider of 425 internet services to their customers while leasing physical 426 network resources from network providers. 427 . Mobile Virtual Network Operators (MVNO): provide mobile 428 services to their end-users without owning the physical network 429 infrastructure. 431 The network provider space is the one where recursiveness occurs. A 432 customer-provider relationship between multiple service providers 433 can be established leading to a hierarchical architecture of 434 controllers within service provider network. 436 2.3. Network Providers 438 Network Providers are the infrastructure providers that own the 439 physical network resources and provide network resources to their 440 customers. The layered model proposed by this draft separates the 441 concerns of network providers and customers, with service providers 442 acting as aggregators of customer requests. 444 3. ACTN architecture 446 This section provides a high-level control and interface model of 447 ACTN. 449 The ACTN architecture, while being aligned with the ONF SDN 450 architecture [ONF-ARCH], is presenting a 3-tiers reference model. It 451 allows for hierarchy and recursiveness not only of SDN controllers 452 but also of traditionally controlled domains. It defines three types 453 of controllers depending on the functionalities they implement. The 454 main functionalities that are identified are: 456 . Multi domain coordination function: With the definition of 457 domain being "everything that is under the control of the same 458 controller",it is needed to have a control entity that oversees 459 the specific aspects of the different domains and to build a 460 single abstracted end-to-end network topology in order to 461 coordinate end-to-end path computation and path/service 462 provisioning. 464 . Virtualization/Abstraction function: To provide an abstracted 465 view of the underlying network resources towards customer, 466 being it the client or a higher level controller entity. It 467 includes computation of customer resource requests into virtual 468 network paths based on the global network-wide abstracted 469 topology and the creation of an abstracted view of network 470 slices allocated to each customer, according to customer- 471 specific virtual network objective functions, and to the 472 customer traffic profile. 474 . Customer mapping function: In charge of mapping customer VN 475 setup commands into network provisioning requests to the 476 Physical Network Controller (PNC) according to business OSS/NMS 477 provisioned static or dynamic policy. Moreover it provides 478 mapping and translation of customer virtual network slices into 479 physical network resources 481 . Virtual service coordination: Virtual service coordination 482 function in ACTN incorporates customer service-related 483 knowledge into the virtual network operations in order to 484 seamlessly operate virtual networks while meeting customer's 485 service requirements. 487 The virtual services that are coordinated under ACTN can be split 488 into two categories: 490 . Service-aware Connectivity Services: This category includes all 491 the network service operations used to provide connectivity 492 between customer end-points while meeting policies and service 493 related constraints. The data model for this category would 494 include topology entities such as virtual nodes, virtual links, 495 adaptation and termination points and service-related entities 496 such as policies and service related constraints. (See Section 497 4.2.2) 499 . Network Function Virtualization Services: These kinds of 500 services are usually setup between customers' premises and 501 service provider premises and are provided mostly by cloud 502 providers or content delivery providers. The context may 503 include, but not limited to a security function like firewall, 504 a traffic optimizer, the provisioning of storage or computation 505 capacity where the customer does not care whether the service 506 is implemented in a given data center or another. These 507 services may be hosted virtually by the provider or physically 508 part of the network. This allows the service provider to hide 509 his own resources (both network and data centers) and divert 510 customer requests where most suitable. This is also known as 511 "end points mobility" case and introduces new concepts of 512 traffic and service provisioning and resiliency. (e.g. Virtual 513 Machine mobility)." (See Section 4.2.3) 515 About the Customer service-related knowledge it includes: 517 - VN Service Requirements: The end customer would have 518 specific service requirements for the VN including the 519 customer endpoints access profile as well as the E2E 520 customer service objectives. The ACTN framework 521 architectural "entities" would monitor the E2E service 522 during the lifetime of VN by focusing on both the 523 connectivity provided by the network as well as the customer 524 service objectives. These E2E service requirements go beyond 525 the VN service requirements and include customer 526 infrastructure as well. 528 - Application Service Policy: Apart for network connectivity, 529 the customer may also require some policies for application 530 specific features or services. The ACTN framework would take 531 these application service policies and requirements into 532 consideration while coordinating the virtual network 533 operations, which require end customer connectivity for 534 these advanced services. 536 While the "types" of controller defined are shown in Figure 4 below 537 and are the following: 539 . CNC - Customer Network Controller 540 . MDSC - Multi Domain Service Coordinator 541 . PNC - Physical Network Controller 543 VPN customer NW Mobile Customer ISP NW service Customer 544 | | | 545 +-------+ +-------+ +-------+ 546 | CNC-A | | CNC-B | | CNC-C | 547 +-------+ +-------+ +-------+ 548 \___________ | _____________/ 549 ---------- | ------------ 550 \ | / 551 +-----------------------+ 552 | MDSC | 553 +-----------------------+ 554 __________/ | \_________ 555 ---------- | ------------____ 556 / | \ 557 +-------+ +-------+ +-------+ 558 | PNC | | PNC | | PNC | 559 +-------+ +-------+ +-------+ 560 | GMPLS / | / \ 561 | trigger / | / \ 562 -------- __---- +-----+ __ +-----+ \ 563 ( ) ( )_ | PNC |__ | PCE | \ 564 - - ( Phys ) +-----+ +-----+ ----- 565 ( GMPLS ) (Netw) | / ( ) 566 ( Physical ) ---- | / ( Phys. ) 567 ( Network ) ----- ----- ( Net ) 568 - - ( ) ( ) ----- 569 ( ) ( Phys. ) ( Phys ) 570 -------- ( Net ) ( Net ) 571 ----- ----- 573 Figure 4: ACTN Control Hierarchy 575 3.1. Customer Network Controller 577 A Virtual Network Service is instantiated by the Customer Network 578 Controller via the CMI (CNC-MDSC Interface). As the Customer Network 579 Controller directly interfaces the application stratum, it 580 understands multiple application requirements and their service 581 needs. It is assumed that the Customer Network Controller and the 582 MDSC have a common knowledge on the end-point interfaces based on 583 their business negotiation prior to service instantiation. End-point 584 interfaces refer to customer-network physical interfaces that 585 connect customer premise equipment to network provider equipment. 587 In addition to abstract networks, ACTN allows to provide the CNC 588 with services. Example of services include connectivity between one 589 of the customer's end points with a given set of resources in a data 590 center from the service provider. 592 3.2. Multi Domain Service Coordinator 594 The MDSC (Multi Domain Service Coordinator) sits between the CNC 595 (the one issuing connectivity requests) and the PNCs (Physical 596 Network Controllersr - the ones managing the physical network 597 resources). The MDSC can be collocated with the PNC, especially in 598 those cases where the service provider and the network provider are 599 the same entity. 601 The internal system architecture and building blocks of the MDSC are 602 out of the scope of ACTN. Some examples can be found in the 603 Application Based Network Operations (ABNO) architecture [ABNO] and 604 the ONF SDN architecture [ONF-ARCH]. 606 The MDSC is the only building block of the architecture that is able 607 to implement all the four ACTN main functionalities, i.e. multi 608 domain coordination function, virtualization/abstraction function, 609 customer mapping function and virtual service coordination. The key 610 point of the MDSC and the whole ACTN framework is detaching the 611 network and service control from underlying technology and help 612 customer express the network as desired by business needs. The MDSC 613 envelopes the instantiation of right technology and network control 614 to meet business criteria. In essence it controls and manages the 615 primitives to achieve functionalities as desired by CNC 616 A hierarchy of MDSCs can be foreseen for scalability and 617 administrative choices. In order to allow for a hierarchy of MDSC, 618 the interface between the parent MDSC and a child MDSC must be the 619 same as the interface between the MDSC and the PNC. This does not 620 introduce any complexity as it is transparent from the perspective 621 of the CNCs and the PNCs and it makes use of the same interface 622 model and its primitives as the CMI and MPI. 624 +-------+ +-------+ +-------+ 625 | CNC-A | | CNC-B | | CNC-C | 626 +-------+ +-------+ +-------+ 627 \___________ | ___________/ 628 ---------- | ---------- 629 \ | / 630 +-----------------------+ 631 | MDSC | 632 +-----------------------+ 633 __________/ | \_________ 634 ---------- | -----------____ 635 / | \ 636 +----------+ +----------+ +--------+ 637 | MDSC | | MDSC | | MDSC | 638 +----------+ +----------+ +--------+ 639 | / | / \ 640 | / | / \ 641 +-----+ +-----+ +-----+ +-----+ +-----+ 642 | PNC | | PNC | | PNC | | PNC | | PNC | 643 +-----+ +-----+ +-----+ +-----+ +-----+ 645 Figure 5: Controller recursiveness 647 A key requirement for allowing recursion of MDSCs is that a single 648 interface needs to be defined both for the north and the south 649 bounds. 650 In order to allow for multi-domain coordination a 1:N relationship 651 must be allowed between MDSCs and between MDSCs and PNCs (i.e. 1 652 parent MDSC and N child MDSC or 1 MDSC and N PNCs). In addition to 653 that it could be possible to have also a M:1 relationship between 654 MDSC and PNC to allow for network resource partitioning/sharing 655 among different customers not necessarily connected to the same MDSC 656 (e.g. different service providers). 658 3.3. Physical Network Controller 660 The Physical Network Controller is the one in charge of configuring 661 the network elements, monitoring the physical topology of the 662 network and passing it, either raw or abstracted, to the MDSC. 664 The internal architecture of the PNC, his building blocks and the 665 way it controls its domain, are out of the scope of ACTN. Some 666 examples can be found in the Application Based Network Operations 667 (ABNO) architecture [ABNO] and the ONF SDN architecture [ONF-ARCH] 668 The PNC, in addition to being in charge of controlling the physical 669 network, is able to implement two of the four ACTN main 670 functionalities: multi domain coordination function and 671 virtualization/abstraction function 672 A hierarchy of PNCs can be foreseen for scalability and 673 administrative choices. 675 3.4. ACTN interfaces 677 To allow virtualization and multi domain coordination, the network 678 has to provide open, programmable interfaces, in which customer 679 applications can create, replace and modify virtual network 680 resources and services in an interactive, flexible and dynamic 681 fashion while having no impact on other customers. Direct customer 682 control of transport network elements and virtualized services is 683 not perceived as a viable proposition for transport network 684 providers due to security and policy concerns among other reasons. 685 In addition, as discussed in the previous section, the network 686 control plane for transport networks has been separated from data 687 plane and as such it is not viable for the customer to directly 688 interface with transport network elements. 690 While the current network control plane is well suited for control 691 of physical network resources via dynamic provisioning, path 692 computation, etc., a multi service domain controller needs to be 693 built on top of physical network controller to support network 694 virtualization. 696 Figure 5 depicts a high-level control and interface architecture for 697 ACTN. A number of key ACTN interfaces exist for deployment and 698 operation of ACTN-based networks. These are highlighted in Figure 5 699 (ACTN Interfaces) below: 701 .-------------- 702 ------------- | 703 | Application |-- 704 ------------- 705 ^ 706 | I/F A -------- 707 v ( ) 708 -------------- - - 709 | Customer | ( Customer ) 710 | Network |--------->( Network ) 711 | Controller | ( ) 712 -------------- - - 713 ^ ( ) 714 | I/F B -------- 715 v ^ ^ 716 -------------- : : 717 | MultiDomain | : . 718 | Service | : . 719 | Coordinator| -------- . I/F E 720 -------------- ( ) . 721 ^ - - . 722 | I/F C ( Physical ) . 723 v ( Network ) . 724 --------------- ( ) -------- 725 | |<----> - - ( ) 726 -------------- | ( ) - - 727 | Physical |-- -------- ( Physical ) 728 | Network |<---------------------->( Network ) 729 | Controller | I/F D ( ) 730 -------------- - - 731 ( ) 732 -------- 734 Figure 6: ACTN Interfaces 736 The interfaces and functions are described below: 738 . Interface A: A north-bound interface (NBI) that will 739 communicate the service request or application demand. A 740 request will include specific service properties, including: 741 services, topology, bandwidth and constraint information. 743 . Interface B: The CNC-MDSC Interface (CMI) is an interface 744 between a Customer Network Controller and a Multi Service 745 Domain Controller. It requests the creation of the network 746 resources, topology or services for the applications. The 747 Virtual Network Controller may also report potential network 748 topology availability if queried for current capability from 749 the Customer Network Controller. 751 . Interface C: The MDSC-PNC Interface (MPI) is an interface 752 between a Multi Domain Service Coordinator and a Physical 753 Network Controller. It communicates the creation request, if 754 required, of new connectivity of bandwidth changes in the 755 physical network, via the PNC. In multi-domain environments, 756 the MDSC needs to establish multiple MPIs, one for each PNC, as 757 there are multiple PNCs responsible for its domain control. 759 . Interface D: The provisioning interface for creating forwarding 760 state in the physical network, requested via the Physical 761 Network Controller. 763 . Interface E: A mapping of physical resources to overlay 764 resources. 766 The interfaces within the ACTN scope are B and C. 768 4. VN creation process 770 The provider can present to the customer different level of network 771 abstraction, spanning from one extreme (say "white") where nothing 772 is shown, just the APs, to the other extreme (say "black") where a 773 slice of the network is shown to the customer. There are shades of 774 gray in between where a number of abstract links and nodes can be 775 shown. 777 The VN creation is composed by two phases: Negotiation and 778 Implementation. 780 Negotiation: In the case of grey/black topology abstraction, there 781 is an a priori phase in which the customer agrees with the provider 782 on the type of topology to be shown, e.q. 10 virtual links and 5 783 virtual nodes with a given interconnectivity. This is something that 784 is assumed to be preconfigured by the operator off-line, what is 785 online is the capability of modifying/deleting something (e.g. a 786 virtual link). In the case of "white" abstraction this negotiation 787 phase does not happen, in the sense that the provider only shows the 788 AP to the customer and nothing else. 790 Implementation: In the case of white topology abstraction, the 791 customers can ask for connectivity with given constraints/SLA 792 between his own access points and LSPs/tunnels are created by the 793 provider to satisfy the request. What the customer sees is only that 794 his CE are connected with a given SLA. In the case of grey/black the 795 customer creates his own LSPs as he wants accordingly with the 796 topology that was presented to him. 798 5. Access Points and Virtual Network Access Points 800 In order not to share unwanted topological information between the 801 customer domain and provider domain, a new entity is defined and 802 associated to an access link, the Access Point (AP). See the 803 definition of AP in Section 1.1. 805 A customer node will use APs as the end points for the request of 806 VNs. 808 A number of parameters need to be associated to the APs. Such 809 parameters need to include at least: the maximum reservable 810 bandwidth on the link, the available bandwidth and the link 811 characteristics (e.g. switching capability, type of mapping). 813 Editor note: it is not appropriate to define link characteristics 814 like bandwidth against a point (AP). A solution needs to be found. 816 ------- ------- 817 ( ) ( ) 818 - - __ - - 819 +---+ X ( ) ( ) Z +---+ 820 |CE1|---+----( Domain X )----( Domain Y )---+---|CE2| 821 +---+ | ( ) ( ) | +---+ 822 AP1 - - - - AP2 823 ( ) ( ) 824 ------- ------- 826 Figure 7: APs definition customer view 828 Let's take as example a scenario in which CE1 is connected to domain 829 X via a 10Gb link and CE2 to domain Y via a 40Gb link. Before the 830 creation of any VN between AP1 and AP2 the customer view can be 831 summarized as follows: 833 +-----+----------+-------------+----------+ 834 |AP id| MaxResBw | AvailableBw | CE,port | 835 +-----+----------+-------------+----------+ 836 | AP1 | 10Gb | 10Gb |CE1,portX | 837 +-----+----------+-------------+----------+ 838 | AP2 | 40Gb | 40Gb |CE2,portZ | 839 +-----+----------+-------------+----------+ 841 Table 1: AP - customer view 843 On the other side what the provider sees is: 845 ------- ------- 846 ( ) ( ) 847 - - __ - - 848 W (+---+ ) ( +---+) Y 849 -+---( |PE1| Dom.X )----( Dom.Y |PE2| )---+- 850 | (+---+ ) ( +---+) | 851 AP1 - - - - AP2 852 ( ) ( ) 853 ------- ------- 855 Figure 8: APs definition provider view 857 Which in the example above ends up in a summarization as follows: 859 +-----+----------+-------------+----------+ 860 |AP id| MaxResBw | AvailableBw | PE,port | 861 +-----+----------+-------------+----------+ 862 | AP1 | 10Gb | 10Gb |PE1,portW | 863 +-----+----------+-------------+----------+ 864 | AP2 | 40Gb | 40Gb |PE2,portY | 865 +-----+----------+-------------+----------+ 867 Table 2: AP - provider view 869 The second entity that needs to be defined is a structure within the 870 AP that is linked to a VN and that is used to allow for different VN 871 to be provided starting from the same AP. It also allows reserving 872 the bandwidth for the VN on the access link. Such entity is called 873 Virtual Network Access Point. For each virtual network is defined on 874 an AP, a different VNAP is created. 876 In the simple scenario depicted above we suppose to create two 877 virtual networks. The first one has with VN identifier 9 between AP1 878 and AP2 with and bandwidth of 1Gbps, while the second one with VN id 879 5, again between AP1 and AP2 and bandwidth 2Gbps. 881 The customer view would evolve as follows: 883 +---------+----------+-------------+----------+ 884 |AP/VNAPid| MaxResBw | AvailableBw | PE,port | 885 +---------+----------+-------------+----------+ 886 |AP1 | 10Gbps | 7Gbps |PE1,portW | 887 | -VNAP1.9| 1Gbps | N.A. | | 888 | -VNAP1.5| 2Gbps | N.A | | 889 +---------+----------+-------------+----------+ 890 |AP2 | 40Gb | 37Gb |PE2,portY | 891 | -VNAP2.9| 1Gbps | N.A. | | 892 | -VNAP2.5| 2Gbps | N.A | | 893 +---------+----------+-------------+----------+ 895 Table 3: AP and VNAP - provider view after VN creation 897 5.1. Dual homing scenario 899 Often there is a dual homing relationship between a CE and a pair of 900 PE. This case needs to be supported also by the definition of VN, AP 901 and VNAP. Suppose to have CE1 connected to two different PE in the 902 operator domain via AP1 and AP2 and the customer needing 5Gbps of 903 bandwidth between CE1 and CE2. 905 AP1 ------- ------- 906 -------( ) ( ) 907 W / - - __ - - 908 +---+ / ( ) ( ) Z +---+ 909 |CE1| ( Domain X )----( Domain Y )---+---|CE2| 910 +---+ \ ( ) ( ) | +---+ 911 Y \ - - - - AP3 912 -------( ) ( ) 913 AP2 ------- ------- 915 Figure 9: Dual homing scenario 917 In this case the customer will request for a VN between AP1, AP2 and 918 AP3 specifying a dual homing relationship between AP1 and AP2. As a 919 consequence no traffic will be flowing between AP1 and AP2. The dual 920 homing relationship would then be mapped against the VNAPs (since 921 other independent VNs might have AP1 and AP2 as end points). 923 The customer view would be as follows: 925 +---------+----------+-------------+----------+-----------+ 926 |AP/VNAPid| MaxResBw | AvailableBw | CE,port |Dual Homing| 927 +---------+----------+-------------+----------+-----------+ 928 |AP1 | 10Gbps | 5Gbps |CE1,portW | | 929 | -VNAP1.9| 5Gbps | N.A. | | VNAP2.9 | 930 +---------+----------+-------------+----------+-----------+ 931 |AP2 | 40Gbps | 35Gbps |CE1,portY | | 932 | -VNAP2.9| 5Gbps | N.A. | | VNAP1.9 | 933 +---------+----------+-------------+----------+-----------+ 934 |AP3 | 40Gbps | 35Gbps |CE2,portZ | | 935 | -VNAP3.9| 5Gbps | N.A. | | NONE | 936 +---------+----------+-------------+----------+-----------+ 3 938 Table 4: Dual homing - customer view after VN creation 940 6. End point selection & mobility 942 Virtual networks could be used as the infrastructure to connect a 943 number of sites of a customer among them or to provide connectivity 944 between customer sites and virtualized network functions (VNF) like 945 for example virtualized firewall, vBNG, storage, computational 946 functions. 948 6.1. End point selection & mobility 950 A VNF could be deployed in any place in the network (e.g. data 951 centers A, B or C in figure below) but the customer doesn't know 952 which is the best site where to install the VNF from a network 953 utilization point of view and which one is able to provide the 954 requested SLA (e.g. it is possible to compute the path minimizing 955 the delay between AP1 and AP2, but the customer doesn't know a 956 priori if the path with minimum delay is towards A, B or C). 958 ------- ------- 959 ( ) ( ) 960 - - __ - - 961 +---+ ( ) ( ) +----+ 962 |CE1|---+----( Domain X )----( Domain Y )---+---|DC-A| 963 +---+ | ( ) ( ) | +----+ 964 AP1 - - - - AP2 965 ( ) ( ) 966 ---+--- ---+--- 967 AP3 | AP4 | 968 +----+ +----+ 969 | |DC-B| |DC-C| 970 | +----+ +----+ 972 Figure 10: End point selection 974 In this case the customer should be allowed to ask for a VN between 975 AP1 and a set of end points hidden to the customer and for which the 976 provider knows the mapping against the related APs. The list of end 977 points is provided by the customer. Also the capability of using a 978 wildcard should be supported when the provider is the owner of both 979 the network and the VNF service offering. In other words a request 980 without indicating the end points should be supported and the 981 provider should decide which the best one to be used is. 983 When the end point is identified the connectivity can be 984 instantiated and a notification can be sent to the customer for the 985 instantiation of the VNF. 987 6.2. Preplanned end point migration 989 A premium SLA for VNF service provisioning consists on the offering 990 of a protected VNF instantiated on two or more sites and with a hot 991 stand-by protection mechanism. In this case the VN should be 992 provided so to switch from one end point to another upon a trigger 993 from the customer or a failure detection mechanism in the network. 994 An example is provided in figure below where the request from the 995 customer is for connectivity with given constraint and resiliency 996 between CE1 and a VNF with primary installation in DC-A and a 997 protection in DC-C. 999 ------- ------- 1000 ( ) ( ) 1001 - - __ - - 1002 +---+ ( ) ( ) +----+ 1003 |CE1|---+----( Domain X )----( Domain Y )---+---|DC-A| 1004 +---+ | ( ) ( ) | +----+ 1005 AP1 - - - - AP2 | 1006 ( ) ( ) | 1007 ---+--- ---+--- | 1008 AP3 | AP4 | HOT STANDBY 1010 +----+ | 1011 | |DC-C| <------------ 1012 | +----+ 1013 Figure 11: Preplanned endpoint migration 1015 6.3. On the fly end point migration 1017 The one the fly end point migration concept is very similar to the 1018 end point selection one. The idea is to give the provider not only 1019 the list of sites where the VNF can be installed, but also the 1020 freedom to dynamically suggest for the switch of the VNF depending 1021 on failures or traffic pattern changes. After an handshake with the 1022 customer controller/applications, the bandwidth in network would be 1023 moved accordingly with the moving of the VNFs. 1025 7. Security 1027 TBD 1029 8. References 1031 8.1. Informative References 1033 [PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1034 Computation Element (PCE)-Based Architecture", IETF RFC 1035 4655, August 2006. 1037 [RFC4026] L. Andersson, T. Madsen, "Provider Provisioned Virtual 1038 Private Network (VPN) Terminology", RFC 4026, March 2005. 1040 [RFC4208] G. Swallow, J. Drake, H.Ishimatsu, Y. Rekhter, 1041 "Generalized Multiprotocol Label Switching (GMPLS) User- 1042 Network Interface (UNI): Resource ReserVation Protocol- 1043 Traffic Engineering (RSVP-TE) Support for the Overlay 1044 Model", RFC 4208, October 2005. 1046 [PCE-S] Crabbe, E, et. al., "PCEP extension for stateful 1047 PCE",draft-ietf-pce-stateful-pce, work in progress. 1049 [GMPLS] Manning, E., et al., "Generalized Multi-Protocol Label 1050 Switching (GMPLS) Architecture", RFC 3945, October 2004. 1052 [NFV-AF] "Network Functions Virtualization (NFV); Architectural 1053 Framework", ETSI GS NFV 002 v1.1.1, October 2013. 1055 [ACTN-PS] Y. Lee, D. King, M. Boucadair, R. Jing, L. Contreras 1056 Murillo, "Problem Statement for Abstraction and Control of 1057 Transport Networks", draft-leeking-actn-problem-statement, 1058 work in progress. 1060 [ONF] Open Networking Foundation, "OpenFlow Switch Specification 1061 Version 1.4.0 (Wire Protocol 0x05)", October 2013. 1063 [TE-INFO] A. Farrel, Editor, "Problem Statement and Architecture for 1064 Information Exchange Between Interconnected Traffic 1065 Engineered Networks", draft-ietf-teas-interconnected-te- 1066 info-exchange, work in progress. 1068 [ABNO] King, D., and Farrel, A., "A PCE-based Architecture for 1069 Application-based Network Operations", draft-farrkingel- 1070 pce-abno-architecture, work in progress. 1072 [ACTN-Info] Y. Lee, S. Belotti, D. Dhody, "Information Model for 1073 Abstraction and Control of Transport Networks", draft- 1074 leebelotti-teas-actn-info, work in progress. 1076 [Cheng] W. Cheng, et. al., "ACTN Use-cases for Packet Transport 1077 Networks in Mobile Backhaul Networks", draft-cheng-actn- 1078 ptn-requirements, work in progress. 1080 [Dhody] D. Dhody, et. al., "Packet Optical Integration (POI) Use 1081 Cases for Abstraction and Control of Transport Networks 1082 (ACTN)", draft-dhody-actn-poi-use-case, work in progress. 1084 [Fang] L. Fang, "ACTN Use Case for Multi-domain Data Center 1085 Interconnect", draft-fang-actn-multidomain-dci, work in 1086 progress. 1088 [Klee] K. Lee, H. Lee, R. Vilata, V. Lopez, "ACTN Use-case for On- 1089 demand E2E Connectivity Services in Multiple Vendor Domain 1090 Transport Networks", draft-klee-actn-connectivity-multi- 1091 vendor-domains, work in progress. 1093 [Kumaki] K. Kumaki, T. Miyasaka, "ACTN : Use case for Multi Tenant 1094 VNO ", draft-kumaki-actn-multitenant-vno, work in 1095 progress. 1097 [Lopez] D. Lopez (Ed), "ACTN Use-case for Virtual Network Operation 1098 for Multiple Domains in a Single Operator Network", draft- 1099 lopez-actn-vno-multidomains, work in progress. 1101 [Shin] J. Shin, R. Hwang, J. Lee, "ACTN Use-case for Mobile Virtual 1102 Network Operation for Multiple Domains in a Single 1103 Operator Network", draft-shin-actn-mvno-multi-domain, work 1104 in progress. 1106 [Xu] Y. Xu, et. al., "Use Cases and Requirements of Dynamic Service 1107 Control based on Performance Monitoring in ACTN 1108 Architecture", draft-xu-actn-perf-dynamic-service-control, 1109 work in progress. 1111 9. Contributors 1113 Authors' Addresses 1115 Daniele Ceccarelli (Editor) 1116 Ericsson 1117 Torshamnsgatan,48 1118 Stockholm, Sweden 1119 Email: daniele.ceccarelli@ericsson.com 1121 Young Lee (Editor) 1122 Huawei Technologies 1123 5340 Legacy Drive 1124 Plano, TX 75023, USA 1125 Phone: (469)277-5838 1126 Email: leeyoung@huawei.com 1128 Luyuan Fang 1129 Email: luyuanf@gmail.com 1131 Diego Lopez 1132 Telefonica I+D 1133 Don Ramon de la Cruz, 82 1134 28006 Madrid, Spain 1135 Email: diego@tid.es 1137 Sergio Belotti 1138 Alcatel Lucent 1139 Via Trento, 30 1140 Vimercate, Italy 1141 Email: sergio.belotti@alcatel-lucent.com 1143 Daniel King 1144 Lancaster University 1145 Email: d.king@lancaster.ac.uk 1147 Dhruv Dhoddy 1148 Huawei Technologies 1149 dhruv.ietf@gmail.com