idnits 2.17.1 draft-ceccarelli-actn-framework-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 713 has weird spacing: '...ansport uti...' == Line 763 has weird spacing: '...tion of in ...' == Line 790 has weird spacing: '...ing and man...' == Line 791 has weird spacing: '...e usage pro...' == Line 794 has weird spacing: '...agement and...' == (1 more instance...) -- The document date (March 9, 2015) is 3308 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ONF-ARCH' is mentioned on line 570, but not defined == Unused Reference: 'PCE-S' is defined on line 838, but no explicit reference was found in the text == Unused Reference: 'NFV-AF' is defined on line 844, but no explicit reference was found in the text == Unused Reference: 'ONF' is defined on line 852, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Daniele Ceccarelli (Editor) 2 Internet Draft Ericsson 4 Intended status: Informational Young Lee (Editor) 5 Expires: September 2015 Huawei 7 March 9, 2015 9 Framework for Abstraction and Control of Transport Networks 11 draft-ceccarelli-actn-framework-07.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 9, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 This draft provides a framework for abstraction and control of 54 transport networks. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Business Model of ACTN.........................................5 60 2.1. Customers.................................................5 61 2.2. Service Providers.........................................7 62 2.3. Network Providers.........................................8 63 3. ACTN architecture..............................................8 64 3.1. Customer Network Controller..............................12 65 3.2. Multi Domain Service Coordinator.........................13 66 3.3. Physical Network Controller..............................14 67 3.4. ACTN interfaces..........................................15 68 3.5. Work in Scope of ACTN....................................17 69 4. References....................................................21 70 4.1. Informative References...................................21 71 5. Contributors..................................................24 72 Authors' Addresses...............................................24 74 1. Introduction 76 Transport networks have a variety of mechanisms to facilitate 77 separation of data plane and control plane including distributed 78 signaling for path setup and protection, centralized path 79 computation for planning and traffic engineering, and a range of 80 management and provisioning protocols to configure and activate 81 network resources. These mechanisms represent key technologies for 82 enabling flexible and dynamic networking. 84 Transport networks in this draft refer to a set of different type of 85 connection-oriented networks, primarily Connection-Oriented Circuit 86 Switched (CO-CS) networks and Connection-Oriented Packet Switched 87 (CO-PS) networks. This implies that at least the following transport 88 networks are in scope of the discussion of this draft: Layer 1(L1) 89 and Layer 0 (L0) optical networks (e.g., Optical Transport Network 90 (OTN), Optical Channel Data Unit (ODU), Optical Channel 91 (OCh)/Wavelength Switched Optical Network (WSON)), Multi-Protocol 92 Label Switching - Transport Profile (MPLS-TP), Multi-Protocol Label 93 Switching - Traffic Engineering (MPLS-TE), as well as other emerging 94 technologies with connection-oriented behavior. One of the 95 characteristics of these network types is the ability of dynamic 96 provisioning and traffic engineering such that resource guarantees 97 can be provided to their clients. 99 One of the main drivers for Software Defined Networking (SDN) is a 100 decoupling of the network control plane from the data plane. This 101 separation of the control plane from the data plane has been already 102 achieved with the development of MPLS/GMPLS [GMPLS] and PCE [PCE] 103 for TE-based transport networks. One of the advantages of SDN is its 104 logically centralized control regime that allows a global view of 105 the underlying network under its control. Centralized control in SDN 106 helps improve network resources utilization from a distributed 107 network control. For TE-based transport network control, PCE is 108 essentially equivalent to a logically centralized control for path 109 computation function. 111 Two key aspects that need to be solved by SDN are: 113 . Network and service abstraction 114 . End to end coordination of multiple SDN and pre-SDN domains 115 e.g. NMS, MPLS-TE or GMPLS. 117 As transport networks evolve, the need to provide network and 118 service abstraction has emerged as a key requirement for operators; 119 this implies in effect the virtualization of network resources so 120 that the network is "sliced" for different tenants shown as a 121 dedicated portion of the network resources 123 Particular attention needs to be paid to the multi-domain case, 124 where Abstraction and Control of Transport Networks (ACTN) can 125 facilitate virtual network operation via the creation of a single 126 virtualized network or a seamless service. This supports operators 127 in viewing and controlling different domains (at any dimension: 128 applied technology, administrative zones, or vendor-specific 129 technology islands) as a single virtualized network. 131 Network virtualization, in general, refers to allowing the customers 132 to utilize a certain amount of network resources as if they own them 133 and thus control their allocated resources in a way most optimal 134 with higher layer or application processes. This empowerment of 135 customer control facilitates introduction of new services and 136 applications as the customers are permitted to create, modify, and 137 delete their virtual network services. More flexible, dynamic 138 customer control capabilities are added to the traditional VPN along 139 with a customer specific virtual network view. Customers control a 140 view of virtual network resources, specifically allocated to each 141 one of them. This view is called an abstracted network topology. 142 Such a view may be specific to the set of consumed services as well 143 as to a particular customer. As the Customer Network Controller is 144 envisioned to support a plethora of distinct applications, there 145 would be another level of virtualization from the customer to 146 individual applications. 148 The framework described in this draft is named Abstraction and 149 Control of Transport Network (ACTN) and facilitates: 151 - Abstraction of the underlying network resources to higher-layer 152 applications and users (customers); abstraction for a specific 153 application or customer is referred to as virtualization in the 154 ONF SDN architecture. [ONF-ARCH] 156 - Slicing infrastructure to connect multiple customers to meet 157 specific customer's service requirements; 159 - Creation of a virtualized environment allowing operators to 160 view and control multi-subnet multi-technology networks into a 161 single virtualized network; 163 - Possibility of providing a customer with abstracted network or 164 abstracted services (totally hiding the network). 166 - A virtualization/mapping network function that adapts customer 167 requests to the virtual resources (allocated to them) to the 168 supporting physical network control and performs the necessary 169 mapping, translation, isolation and security/policy 170 enforcement, etc.; This function is often referred to as 171 orchestration. 173 - The multi-domain coordination of the underlying transport 174 domains, presenting it as an abstracted topology to the 175 customers via open and programmable interfaces. This allows for 176 the recursion of controllers in a customer-provider 177 relationship. 179 The organization of this draft is as follows. Section 2 provides a 180 discussion for a Business Model, Section 3 ACTN Architecture, 181 Section 4 ACTN Applicability, and Section 5 ACTN Interface 182 requirements. 184 2. Business Model of ACTN 186 The traditional Virtual Private Network (VPN) and Overlay Network 187 (ON) models are built on the premise that one single network 188 provider provides all virtual private or overlay networks to its 189 customers. This model is simple to operate but has some 190 disadvantages in accommodating the increasing need for flexible and 191 dynamic network virtualization capabilities. 193 The ACTN model is built upon entities that reflect the current 194 landscape of network virtualization environments. There are three 195 key entities in the ACTN model [ACTN-PS]: 197 - Customers 198 - Service Providers 199 - Network Providers 201 2.1. Customers 203 Within the ACTN framework, different types of customers may be taken 204 into account depending on the type of their resource needs, on their 205 number and type of access. As example, it is possible to group them 206 into two main categories: 208 Basic Customer: Basic customers include fixed residential users, 209 mobile users and small enterprises. Usually the number of basic 210 customers is high; they require small amounts of resources and are 211 characterized by steady requests (relatively time invariant). A 212 typical request for a basic customer is for a bundle of voice 213 services and internet access. Moreover basic customers do not modify 214 their services themselves; if a service change is needed, it is 215 performed by the provider as proxy and they generally have very few 216 dedicated resources (subscriber drop), with everything else shared 217 on the basis of some SLA, which is usually best-efforts. 219 Advanced Customer: Advanced customers typically include enterprises, 220 governments and utilities. Such customers can ask for both point to 221 point and multipoint connectivity with high resource demand 222 significantly varying in time and from customer to customer. This is 223 one of the reasons why a bundled services offer is not enough but it 224 is desirable to provide each of them with customized virtual network 225 services. Advanced customers may own dedicated virtual resources, or 226 share resources, but shared resources are likely to be governed by 227 more complex SLA agreements; moreover they may have the ability to 228 modify their service parameters directly (within the scope of their 229 virtualized environments. As customers are geographically spread 230 over multiple network provider domains, the necessary control and 231 data interfaces to support such customer needs is no longer a single 232 interface between the customer and one single network provider. With 233 this premise, customers have to interface multiple providers to get 234 their end-to-end network connectivity service and the associated 235 topology information. Customers may have to support multiple virtual 236 network services with different service objectives and QoS 237 requirements. For flexible and dynamic applications, customers may 238 want to control their allocated virtual network resources in a 239 dynamic fashion. To allow that, customers should be given an 240 abstracted view of topology on which they can perform the necessary 241 control decisions and take the corresponding actions. ACTN's primary 242 focus is Advanced Customers. 244 Customers of a given service provider can in turn offer a service to 245 other customers in a recursive way. An example of recursiveness with 246 2 service providers is shown below. 248 - Customer (of service B) 249 - Customer (of service A) & Service Provider (of service B) 250 - Service Provider (of service A) 251 - Network Provider 253 +------------------------------------------------------------+ --- 254 | | ^ 255 | Customer (of service B)| . 256 | +--------------------------------------------------------+ | B 257 | | | |--- . 258 | |Customer (of service A) & Service Provider(of service B)| | ^ . 259 | | +---------------------------------------------------+ | | . . 260 | | | | | | . . 261 | | | Service Provider (of service A)| | | A . 262 | | |+------------------------------------------+ | | | . . 263 | | || | | | | . . 264 | | || Network provider| | | | v v 265 | | |+------------------------------------------+ | | |------ 266 | | +---------------------------------------------------+ | | 267 | +--------------------------------------------------------+ | 268 +------------------------------------------------------------+ 270 Figure 1: Network Recursiveness. 272 2.2. Service Providers 274 Service providers are the providers of virtual network services to 275 their customers. Service providers may or may not own physical 276 network resources. When a service provider is the same as the 277 network provider, this is similar to traditional VPN models. This 278 model works well when the customer maintains a single interface with 279 a single provider. When customer location spans across multiple 280 independent network provider domains, then it becomes hard to 281 facilitate the creation of end-to-end virtual network services with 282 this model. 284 A more interesting case arises when network providers only provide 285 infrastructure while service providers directly interface their 286 customers. In this case, service providers themselves are customers 287 of the network infrastructure providers. One service provider may 288 need to keep multiple independent network providers as its end-users 289 span geographically across multiple network provider domains. 291 Customer X -----------------------------------X 293 Service Provider A X -----------------------------------X 295 Network Provider B X-----------------X 297 Network Provider A X------------------X 299 The ACTN network model is predicated upon this three tier model and 300 is summarized in figure below: 302 +----------------------+ 303 | customer | 304 +----------------------+ 305 | 306 | /\ Service/Customer specific 307 | || Abstract Topology 308 | || 309 +----------------------+ E2E abstract 310 | Service Provider | topology creation 311 +----------------------+ 312 / | \ 314 / | \ Network Topology 315 / | \ (raw or abstract) 316 / | \ 317 +------------------+ +------------------+ +------------------+ 318 |Network Provider 1| |Network Provider 2| |Network Provider 3| 319 +------------------+ +------------------+ +------------------+ 321 Figure 2: Three tier model. 323 There can be multiple types of service providers. 325 . Data Center providers: can be viewed as a service provider type 326 as they own and operate data center resources to various WAN 327 clients, they can lease physical network resources from network 328 providers. 329 . Internet Service Providers (ISP): can be a service provider of 330 internet services to their customers while leasing physical 331 network resources from network providers. 332 . Mobile Virtual Network Operators (MVNO): provide mobile 333 services to their end-users without owning the physical network 334 infrastructure. 336 The network provider space is the one where recursiveness occurs. A 337 customer-provider relationship between multiple service providers 338 can be established leading to a hierarchical architecture of 339 controllers within service provider network. 341 2.3. Network Providers 343 Network Providers are the infrastructure providers that own the 344 physical network resources and provide network resources to their 345 customers. The layered model proposed by this draft separates the 346 concerns of network providers and customers, with service providers 347 acting as aggregators of customer requests. 349 3. ACTN architecture 351 This section provides a high-level control and interface model of 352 ACTN. 354 The ACTN architecture, while being aligned with the ONF SDN 355 architecture [ONF-ARCH], is presenting a 3-tiers reference model. It 356 allows for hierarchy and recursiveness not only of SDN controllers 357 but also of traditionally controlled domains. It defines three types 358 of controllers depending on the functionalities they implement. The 359 main functionalities that are identified are: 361 . Multi domain coordination function: With the definition of 362 domain being "everything that is under the control of the same 363 controller",it is needed to have a control entity that oversees 364 the specific aspects of the different domains and to build a 365 single abstracted end-to-end network topology in order to 366 coordinate end-to-end path computation and path/service 367 provisioning. 369 . Virtualization/Abstraction function: To provide an abstracted 370 view of the underlying network resources towards customer, 371 being it the client or a higher level controller entity. It 372 includes computation of customer resource requests into virtual 373 network paths based on the global network-wide abstracted 374 topology and the creation of an abstracted view of network 375 slices allocated to each customer, according to customer- 376 specific virtual network objective functions, and to the 377 customer traffic profile. 379 . Customer mapping function: In charge of mapping customer VN 380 setup commands into network provisioning requests to the 381 Physical Network Controller (PNC) according to business OSS/NMS 382 provisioned static or dynamic policy. Moreover it provides 383 mapping and translation of customer virtual network slices into 384 physical network resources 386 . Virtual service coordination: Virtual service coordination 387 function in ACTN incorporates customer service-related 388 knowledge into the virtual network operations in order to 389 seamlessly operate virtual networks while meeting customer's 390 service requirements. 392 The functionality is covering two types of services: 394 - Service-aware Connectivity Services: This category includes 395 all the network service operations used to provide 396 connectivity between customer end-points while meeting 397 policies and service related constraints. The data model for 398 this category would include topology entities such as 399 virtual nodes, virtual links, adaptation and termination 400 points and service-related entities such as policies and 401 service related constraints. (See Section 4.2.2) 403 - Network Function Virtualization Services: These kinds of 404 services are usually setup between customers' premises and 405 service provider premises and are provided mostly by cloud 406 providers or content delivery providers. The context may 407 include, but not limited to a security function like 408 firewall, a traffic optimizer, the provisioning of storage 409 or computation capacity where the customer does not care 410 whether the service is implemented in a given data center or 411 another. These services may be hosted virtually by the 412 provider or physically part of the network. This allows the 413 service provider to hide his own resources (both network and 414 data centers) and divert customer requests where most 415 suitable. This is also known as "end points mobility" case 416 and introduces new concepts of traffic and service 417 provisioning and resiliency. (e.g. Virtual Machine 418 mobility)." (See Section 4.2.3) 420 About the Customer service-related knowledge it includes: 422 - VN Service Requirements: The end customer would have 423 specific service requirements for the VN including the 424 customer endpoints access profile as well as the E2E 425 customer service objectives. The ACTN framework 426 architectural "entities" would monitor the E2E service 427 during the lifetime of VN by focusing on both the 428 connectivity provided by the network as well as the customer 429 service objectives. These E2E service requirements go beyond 430 the VN service requirements and include customer 431 infrastructure as well. 433 - Application Service Policy: Apart for network connectivity, 434 the customer may also require some policies for application 435 specific features or services. The ACTN framework would take 436 these application service policies and requirements into 437 consideration while coordinating the virtual network 438 operations, which require end customer connectivity for 439 these advanced services. 441 While the "types" of controller defined are shown in Figure 3 below 442 and are the following: 444 . CNC - Customer Network Controller 445 . MDSC - Multi Domain Service Coordinator 446 . PNC - Physical Network Controller 448 VPN customer NW Mobile Customer ISP NW service Customer 449 | | | 450 +-------+ +-------+ +-------+ 451 | CNC-A | | CNC-B | | CNC-C | 452 +-------+ +-------+ +-------+ 453 \___________ | _____________/ 454 ---------- | ------------ 455 \ | / 456 +-----------------------+ 457 | MDSC | 458 +-----------------------+ 459 __________/ | \_________ 460 ---------- | ------------____ 461 / | \ 462 +-------+ +-------+ +-------+ 463 | PNC | | PNC | | PNC | 464 +-------+ +-------+ +-------+ 465 | GMPLS / | / \ 466 | trigger / | / \ 467 -------- __---- +-----+ __ +-----+ \ 468 ( ) ( )_ | PNC |__ | PCE | \ 469 - - ( Phys ) +-----+ +-----+ ----- 470 ( GMPLS ) (Netw) | / ( ) 471 ( Physical ) ---- | / ( Phys. ) 472 ( Network ) ----- ----- ( Net ) 473 - - ( ) ( ) ----- 474 ( ) ( Phys. ) ( Phys ) 475 -------- ( Net ) ( Net ) 476 ----- ----- 478 Figure 3: ACTN Control Hierarchy 480 3.1. Customer Network Controller 482 A Virtual Network Service is instantiated by the Customer Network 483 Controller via the CMI (CNC-MDSC Interface). As the Customer Network 484 Controller directly interfaces the application stratum, it 485 understands multiple application requirements and their service 486 needs. It is assumed that the Customer Network Controller and the 487 MDSC have a common knowledge on the end-point interfaces based on 488 their business negotiation prior to service instantiation. End-point 489 interfaces refer to customer-network physical interfaces that 490 connect customer premise equipment to network provider equipment. 491 Figure 10 in Appendix shows an example physical network topology 492 that supports multiple customers. In this example, customer A has 493 three end-points A.1, A.2 and A.3. The interfaces between customers 494 and transport networks are assumed to be 40G OTU links. 496 In addition to abstract networks, ACTN allows to provide the CNC 497 with services. Example of services include connectivity between one 498 of the customer's end points with a given set of resources in a data 499 center from the service provider. 501 3.2. Multi Domain Service Coordinator 503 The MDSC (Multi Domain Service Coordinator) sits between the CNC 504 (the one issuing connectivity requests) and the PNCs (Physical 505 Network Controllersr - the ones managing the physical network 506 resources). The MDSC can be collocated with the PNC, especially in 507 those cases where the service provider and the network provider are 508 the same entity. 510 The internal system architecture and building blocks of the MDSC are 511 out of the scope of ACTN. Some examples can be found in the 512 Application Based Network Operations (ABNO) architecture [ABNO] and 513 the ONF SDN architecture [ONF-ARCH]. 515 The MDSC is the only building block of the architecture that is able 516 to implement all the four ACTN main functionalities, i.e. multi 517 domain coordination function, virtualization/abstraction function, 518 customer mapping function and virtual service coordination. 519 A hierarchy of MDSCs can be foreseen for scalability and 520 administrative choices. 522 +-------+ +-------+ +-------+ 523 | CNC-A | | CNC-B | | CNC-C | 524 +-------+ +-------+ +-------+ 525 \___________ | ___________/ 526 ---------- | ---------- 527 \ | / 528 +-----------------------+ 529 | MDSC | 530 +-----------------------+ 531 __________/ | \_________ 532 ---------- | -----------____ 533 / | \ 534 +----------+ +----------+ +--------+ 535 | MDSC | | MDSC | | MDSC | 536 +----------+ +----------+ +--------+ 537 | / | / \ 538 | / | / \ 539 +-----+ +-----+ +-----+ +-----+ +-----+ 540 | PNC | | PNC | | PNC | | PNC | | PNC | 541 +-----+ +-----+ +-----+ +-----+ +-----+ 543 Figure 4: Controller recursiveness 545 A key requirement for allowing recursion of MDSCs is that a single 546 interface needs to be defined both for the north and the south 547 bounds. 548 In order to allow for multi-domain coordination a 1:N relationship 549 must be allowed between MDSCs and between MDSCs and PNCs (i.e. 1 550 parent MDSC and N child MDSC or 1 MDSC and N PNCs). In addition to 551 that it could be possible to have also a M:1 relationship between 552 MDSC and PNC to allow for network resource partitioning/sharing 553 among different customers not necessarily connected to the same MDSC 554 (e.g. different service providers). 555 It should be noted that the interface between the parent MDSC and a 556 child MDSC does not introduce any complexity as it is "internal" and 557 "transparent" from the perspective of the CNCs and the PNCs and it 558 makes use of the same interface model and its primitives as the CMI 559 and MPI. 561 3.3. Physical Network Controller 563 The physical network controller is the one in charge of configuring 564 the network elements, monitoring the physical topology of the 565 network and passing it, either raw or abstracted, to the MDSC. 567 The internal architecture of the PNC, his building blocks and the 568 way it controls its domain, are out of the scope of ACTN. Some 569 examples can be found in the Application Based Network Operations 570 (ABNO) architecture [ABNO] and the ONF SDN architecture [ONF-ARCH] 572 The PNC, in addition to being in charge of controlling the physical 573 network, is able to implement two of the four ACTN main 574 functionalities: multi domain coordination function and 575 virtualization/abstraction function 576 A hierarchy of PNCs can be foreseen for scalability and 577 administrative choices. 579 3.4. ACTN interfaces 581 To allow virtualization and multi domain coordination, the network 582 has to provide open, programmable interfaces, in which customer 583 applications can create, replace and modify virtual network 584 resources and services in an interactive, flexible and dynamic 585 fashion while having no impact on other customers. Direct customer 586 control of transport network elements and virtualized services is 587 not perceived as a viable proposition for transport network 588 providers due to security and policy concerns among other reasons. 589 In addition, as discussed in the previous section, the network 590 control plane for transport networks has been separated from data 591 plane and as such it is not viable for the customer to directly 592 interface with transport network elements. 594 While the current network control plane is well suited for control 595 of physical network resources via dynamic provisioning, path 596 computation, etc., a multi service domain controller needs to be 597 built on top of physical network controller to support network 598 virtualization. On a high-level, virtual network control refers to a 599 mediation layer that performs several functions: 601 Figure 4 depicts a high-level control and interface architecture for 602 ACTN. A number of key ACTN interfaces exist for deployment and 603 operation of ACTN-based networks. These are highlighted in Figure 4 604 (ACTN Interfaces) below: 606 .-------------- 607 ------------- | 608 | Application |-- 609 ------------- 610 ^ 611 | I/F A -------- 612 v ( ) 613 -------------- - - 614 | Customer | ( Customer ) 615 | Network |--------->( Network ) 616 | Controller | ( ) 617 -------------- - - 618 ^ ( ) 619 | I/F B -------- 620 v ^ ^ 621 -------------- : : 622 | MultiDomain | : . 623 | Service | : . 624 | Coordinator| -------- . I/F E 625 -------------- ( ) . 626 ^ - - . 627 | I/F C ( Physical ) . 628 v ( Network ) . 629 --------------- ( ) -------- 630 | |<----> - - ( ) 631 -------------- | ( ) - - 632 | Physical |-- -------- ( Physical ) 633 | Network |<---------------------->( Network ) 634 | Controller | I/F D ( ) 635 -------------- - - 636 ( ) 637 -------- 639 Figure 4: ACTN Interfaces 641 The interfaces and functions are described below: 643 . Interface A: A north-bound interface (NBI) that will 644 communicate the service request or application demand. A 645 request will include specific service properties, including: 646 services, topology, bandwidth and constraint information. 648 . Interface B: The CNC-MDSC Interface (CMI) is an interface 649 between a Customer Network Controller and a Multi Service 650 Domain Controller. It requests the creation of the network 651 resources, topology or services for the applications. The 652 Virtual Network Controller may also report potential network 653 topology availability if queried for current capability from 654 the Customer Network Controller. 656 . Interface C: The MDSC-PNC Interface (MPI) is an interface 657 between a Multi Domain Service Coordinator and a Physical 658 Network Controller. It communicates the creation request, if 659 required, of new connectivity of bandwidth changes in the 660 physical network, via the PNC. In multi-domain environments, 661 the MDSC needs to establish multiple MPIs, one for each PNC, as 662 there are multiple PNCs responsible for its domain control. 664 . Interface D: The provisioning interface for creating forwarding 665 state in the physical network, requested via the Physical 666 Network Controller. 668 . Interface E: A mapping of physical resources to overlay 669 resources. 671 The interfaces within the ACTN scope are B and C. 673 3.5. Work in Scope of ACTN 675 This section provides a summary of use-cases in terms of two 676 categories: (i) service-specific requirements; (ii) network-related 677 requirements. 679 Service-specific requirements listed below are uniquely applied to 680 the work scope of ACTN. Service-specific requirements are related to 681 virtual service coordination function defined in Section 3. These 682 requirements are related to customer's VNs in terms of service 683 policy associated with VNs such as service performance objectives, 684 VN endpoint location information for certain required service- 685 specific functions (e.g., security and others), VN survivability 686 requirement, or dynamic service control policy, etc. 688 Network-related requirements are related to virtual network 689 operation function defined in Section 3. These requirements are 690 related to multi-domain and multi-layer signaling, routing, 691 protection/restoration and synergy, re-optimization/re-grooming, 692 etc. These requirements are not inherently unique for the scope of 693 ACTN but some of these requirements are in scope of ACTN, especially 694 for coherent/seamless operation aspect of multiple controller 695 hierarchy. 697 The following table gives an overview of service-specific 698 requirements and network-related requirements respectively for each 699 ACTN use-case and identifies the work in scope of ACTN. 701 Details on these requirements will be developed into the information 702 model in [ACTN-Info]. 704 Use-case Service- Network-related ACTN Work 705 specific Requirements Scope 706 Requirements 708 ------- -------------- --------------- -------------- 709 [Cheng] - E2E service - Multi-layer - Dynamic 710 provisioning (L2/L2.5) multi-layer 711 - Performance coordination coordination 712 monitoring - VNO for multi- based on 713 - Resource domain transport utilization is 714 utilization networks in scope of 715 abstraction ACTN 716 - YANG for 717 utilization 718 abstraction 720 ------- -------------- ---------------- -------------- 721 [Dhody] - Service - POI - Performance 722 awareness/ Performance related data 723 coordination monitoring model may be 724 between P/O. - Protection/ in scope of 725 Restoration ACTN 726 synergy - Customer's 727 VN 728 survivability 729 policy 730 enforcement 731 for 732 protection/res 733 toration is 734 unique to 735 ACTN. 737 ------- -------------- ---------------- -------------- 738 [Fang] - Dynamic VM - On-demand - Multi- 739 migration virtual circuit destination 740 (service), request service 741 Global load - Network Path selection 742 balancing Connection policy 743 (utilization request enforcement 744 efficiency), and its 745 Disaster related 746 recovery primitives/inf 747 - Service- ormation are 748 aware network unique to 749 query ACTN. 750 - Service - Service- 751 Policy aware network 752 Enforcement query and its 753 data model can 754 be extended by 755 ACTN. 757 ------- -------------- ---------------- -------------- 758 [Klee] - Two stage path - Multi-domain 759 computation service policy 760 E2E signaling coordination 761 coordination to network 762 primitives is 763 - Abstraction of in scope of 764 inter-domain ACTN 765 info 766 - Enforcement of 767 network policy 768 (peering, domain 769 preference) 770 - Network 771 capability 772 exchange 773 (pull/push, 774 abstraction 775 level, etc.) 777 ------- -------------- ---------------- -------------- 778 [Kumaki] - On-demand VN - All of the 779 creation service- 780 - Multi- specific lists 781 service level in the left 782 for VN column is 783 - VN unique to 784 survivability ACTN. 785 /diversity/con 786 fidentiality 788 ------- -------------- ---------------- -------------- 789 [Lopez] - E2E - E2E connection - Escalation 790 accounting and management, path of performance 791 resource usage provisioning and fault 792 data - E2E network management 793 - E2E service monitoring and data to CNC 794 policy fault management and the policy 795 enforcement enforcement 796 for this area 797 is unique to 798 ACTN. 800 ------- -------------- ---------------- -------------- 801 [Shin] - Current - LB for - Multi-layer 802 network recovery routing and 803 resource - Multi-layer optimization 804 abstraction routing and are related to 805 Endpoint/DC optimization VN's dynamic 806 dynamic coordination endpoint 807 selection (for selection 808 VM migration) policy. 810 ------- -------------- ---------------- -------------- 811 [Xu] - Dynamic - Traffic - Dynamic 812 service monitoring service 813 control policy - SLA monitoring control policy 814 enforcement enforcement 815 - Dynamic and its 816 service control 817 control primitives are 818 in scope of 819 ACTN 820 - Data model 821 to support 822 traffic 823 monitoring 824 data is an 825 extension of 826 YANG model 827 ACTN can 828 extend. 830 4. References 832 4.1. Informative References 834 [PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 835 Computation Element (PCE)-Based Architecture", IETF RFC 836 4655, August 2006. 838 [PCE-S] Crabbe, E, et. al., "PCEP extension for stateful 839 PCE",draft-ietf-pce-stateful-pce, work in progress. 841 [GMPLS] Manning, E., et al., "Generalized Multi-Protocol Label 842 Switching (GMPLS) Architecture", RFC 3945, October 2004. 844 [NFV-AF] "Network Functions Virtualization (NFV); Architectural 845 Framework", ETSI GS NFV 002 v1.1.1, October 2013. 847 [ACTN-PS] Y. Lee, D. King, M. Boucadair, R. Jing, L. Contreras 848 Murillo, "Problem Statement for Abstraction and Control of 849 Transport Networks", draft-leeking-actn-problem-statement, 850 work in progress. 852 [ONF] Open Networking Foundation, "OpenFlow Switch Specification 853 Version 1.4.0 (Wire Protocol 0x05)", October 2013. 855 [ABNO] King, D., and Farrel, A., "A PCE-based Architecture for 856 Application-based Network Operations", draft-farrkingel- 857 pce-abno-architecture, work in progress. 859 [ACTN-Info] Y. Lee, S. Belotti, D. Dhody, "Information Model for 860 Abstraction and Control of Transport Networks", draft- 861 leebelotti-teas-actn-info, work in progress. 863 [Cheng] W. Cheng, et. al., "ACTN Use-cases for Packet Transport 864 Networks in Mobile Backhaul Networks", draft-cheng-actn- 865 ptn-requirements, work in progress. 867 [Dhody] D. Dhody, et. al., "Packet Optical Integration (POI) Use 868 Cases for Abstraction and Control of Transport Networks 869 (ACTN)", draft-dhody-actn-poi-use-case, work in progress. 871 [Fang] L. Fang, "ACTN Use Case for Multi-domain Data Center 872 Interconnect", draft-fang-actn-multidomain-dci, work in 873 progress. 875 [Klee] K. Lee, H. Lee, R. Vilata, V. Lopez, "ACTN Use-case for On- 876 demand E2E Connectivity Services in Multiple Vendor Domain 877 Transport Networks", draft-klee-actn-connectivity-multi- 878 vendor-domains, work in progress. 880 [Kumaki] K. Kumaki, T. Miyasaka, "ACTN : Use case for Multi Tenant 881 VNO ", draft-kumaki-actn-multitenant-vno, work in 882 progress. 884 [Lopez] D. Lopez (Ed), "ACTN Use-case for Virtual Network Operation 885 for Multiple Domains in a Single Operator Network", draft- 886 lopez-actn-vno-multidomains, work in progress. 888 [Shin] J. Shin, R. Hwang, J. Lee, "ACTN Use-case for Mobile Virtual 889 Network Operation for Multiple Domains in a Single 890 Operator Network", draft-shin-actn-mvno-multi-domain, work 891 in progress. 893 [Xu] Y. Xu, et. al., "Use Cases and Requirements of Dynamic Service 894 Control based on Performance Monitoring in ACTN 895 Architecture", draft-xu-actn-perf-dynamic-service-control, 896 work in progress. 898 5. Contributors 900 Authors' Addresses 902 Daniele Ceccarelli (Editor) 903 Ericsson 904 Torshamnsgatan,48 905 Stockholm, Sweden 906 Email: daniele.ceccarelli@ericsson.com 908 Young Lee (Editor) 909 Huawei Technologies 910 5340 Legacy Drive 911 Plano, TX 75023, USA 912 Phone: (469)277-5838 913 Email: leeyoung@huawei.com 915 Luyuan Fang 916 Email: luyuanf@gmail.com 918 Diego Lopez 919 Telefonica I+D 920 Don Ramon de la Cruz, 82 921 28006 Madrid, Spain 922 Email: diego@tid.es 924 Sergio Belotti 925 Alcatel Lucent 926 Via Trento, 30 927 Vimercate, Italy 928 Email: sergio.belotti@alcatel-lucent.com 930 Daniel King 931 Lancaster University 932 Email: d.king@lancaster.ac.uk 934 Dhruv Dhoddy 935 Huawei Technologies 936 dhruv.ietf@gmail.com