idnits 2.17.1 draft-leebelotti-teas-actn-info-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 188 has weird spacing: '... static negot...' == Line 197 has weird spacing: '...senting its n...' -- The document date (March 9, 2016) is 2969 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ACTN-REQ' is mentioned on line 231, but not defined == Unused Reference: 'Stateful-PCE' is defined on line 579, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Teas Working Group Young Lee 2 Internet Draft Huawei 4 Intended status: Informational Sergio Belotti 5 Alcatel-Lucent 6 Expires: September 2016 7 Dhruv Dhody 8 Huawei 10 Daniele Ceccarelli 11 Ericsson 13 Bin Young Yun 14 ETRI 16 March 9, 2016 18 Information Model for Abstraction and Control of TE Networks (ACTN) 20 draft-leebelotti-teas-actn-info-02.txt 22 Abstract 24 This draft provides an information model for abstraction and control 25 of Traffic Engineered (TE) networks (ACTN). 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with 30 the provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on September 9, 2015. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction...................................................3 67 2. ACTN Common Interfaces Information Model.......................4 68 2.1. VN Action Primitives......................................6 69 2.1.1. VN Instantiate.......................................7 70 2.1.2. VN Modify............................................7 71 2.1.3. VN Delete............................................7 72 2.1.4. VN Update............................................8 73 2.1.5. VN Path Compute......................................8 74 2.1.6. VN Query.............................................9 75 2.1.7. TE Update (for TE resources).........................9 76 2.2. VN Objects...............................................10 77 2.2.1. VN Identifier.......................................10 78 2.2.2. VN Objective Function...............................10 79 2.2.3. VN End-Point........................................11 80 2.2.4. VN Survivability....................................11 81 2.2.5. VN Action Status....................................12 82 2.2.6. VN Associated LSP...................................12 83 2.2.7. VN Service Preference...............................12 84 2.3. Mapping of VN Primitives with VN Objects.................13 85 3. References....................................................15 86 3.1. Informative References...................................15 87 4. Contributors..................................................15 88 Contributors' Addresses..........................................15 89 Authors' Addresses...............................................15 90 Appendix A: ACTN Applications....................................17 91 A.1. Coordination of Multi-destination Service 92 Requirement/Policy.........................................17 93 A.2. Application Service Policy-aware Network Operation....19 94 A.3. Network Function Virtualization Service Enabled 95 Connectivity...............................................26 96 A.4. Dynamic Service Control Policy Enforcement for 97 Performance and Fault Management...........................28 98 A.5. E2E VN Survivability and Multi-Layer (Packet-Optical) 99 Coordination for Protection/Restoration....................29 101 1. Introduction 103 This draft provides an information model for the requirements 104 identified in the ACTN requirements [ACTN-Req] and the ACTN 105 interfaces identified in the ACTN architecture and framework 106 document [ACTN-Frame]. 108 The purpose of this draft is to put all information elements of ACTN 109 in one place before proceeding to development work necessary for 110 protocol extensions and data models. 112 The ACTN reference architecture identified a three-tier control 113 hierarchy as depicted in Figure 1: 115 - Customer Network Controllers (CNC) 116 - Multi-Domain Service Coordinator (MDSC) 117 - Physical Network Controllers (PNC). 119 +-------+ +-------+ +-------+ 120 | CNC-A | | CNC-B | | CNC-C | 121 +-------+ +-------+ +-------+ 122 \___________ | ____________ _/ 123 ---------- | CMI ------------ 124 \ | / 125 +-----------------------+ 126 | MDSC | 127 +-----------------------+ 128 _________/ | \_________ 129 -------- | MPI ------------____ 130 / | \ 131 +-------+ +-------+ +-------+ 132 | PNC | | PNC | | PNC | 133 +-------+ +-------+ +-------+ 135 Figure 1: A Three-tier ACTN control hierarchy 137 The two interfaces with respect to the MDSC, one north of the MDSC 138 and the other south of the MDSC are referred to as CMI (CNC-MDSC 139 Interface) and MPI (MDSC-PNC Interface), respectively. It is 140 intended to model these two interfaces and derivative interfaces 141 thereof (e.g., MDSC to MSDC in a hierarchy of MDSCs) with one common 142 model. 144 Appendix A provides some relevant ACTN use-cases extracted from 145 [ACTN-Req]. Appendix A is information only and may help readers 146 understand the context of key use-cases addressed in [ACTN-Req]. 148 2. ACTN Common Interfaces Information Model 150 This section provides ACTN common interface information model to 151 describe in terms of primitives, objects, their properties 152 (represented as attributes), their relationships, and the resources 153 for the service applications needed in the ACTN context. 155 Basic primitives (messages) are required between the CNC-MDSC and 156 MDSC-PNC controllers. These primitives can then be used to support 157 different ACTN network control functions like network topology 158 request/query, VN service request, path computation and connection 159 control, VN service policy negotiation, enforcement, routing 160 options, etc. 162 The standard interface is described between a client controller and 163 a server controller. A client-server relationship is recursive 164 between a CNC and a MDSC and between a MDSC and a PNC. In the CMI, 165 the client is a CNC while the server is a MDSC. In the MPI, the 166 client is a MDSC and the server is a PNC. There may also be MDSC- 167 MDSC interface(s) that need to be supported. This may arise in a 168 hierarchy of MDSCs in which workloads may need to be partitioned to 169 multiple MDSCs. 171 A Virtual Network is a client view of the transport network. It is 172 composed by a set of physical resources sliced in the provider 173 network and presented to the customer as a set of abstract resources 174 i.e. virtual nodes and virtual links. Depending on the agreement 175 between client and provider a VN can be just represented by how the 176 end points can be connected with given SLA attributes(e.g., re 177 satisfying the customer's objectives), or a pre-configured set of 178 physical resources or can be created as outcome of a dynamic request 179 from customer. 181 1. In the first case can be seen as an (or set of) e2e 182 connection(s) that can be formed by recursive aggregation of 183 lower level connections at provider level. Such end to end 184 connections include: customer end points, access links 185 (physical or virtual), intra domain tunnels and inter-domain 186 link (physical or virtual). 187 2. When VN is pre-configured is provided after a 188 static negotiation between customer and provider while in the 189 third case VN can be dynamically created, deleted, or modified 190 in response to requests from the customer. This implies dynamic 191 changes of network resources reserved for the customer. 192 3. In the second and third case, once that customer has obtained 193 his VN, can act upon the virtual network resources to perform 194 connection management (set-up/release/modify connections). 196 Abstract topology: Every lower controller in the provider network, 197 when is representing its network topology to an higher layer, it 198 may want to hide details of the actual network topology. In such 199 case, an abstract topology may be used for this purpose. Abstract 200 topology enhances scalability for the MDSC to operate multi-domain 201 networks. 203 Basic primitives (messages) are required between the CNC-MDSC and 204 MDSC-PNC controllers. These primitives can then be used to support 205 different ACTN network control functions like network topology 206 request/query, VN service request, path computation and connection 207 control, VN service policy negotiation, enforcement, routing 208 options, etc. 210 At a minimum, the following VN action primitives should be 211 supported: 213 - VN Instantiate (See Section 2.1.1. for the description) 215 - VN Modify (See Section 2.1.2. for the description) 217 - VN Delete (See Section 2.1.3. for the description) 219 - VN Update ((See Section 2.1.4. for the description) 221 - VN Path Compute (See Section 2.1.5. for the description) 223 - VN Query (See Section 2.1.6. for the description) 225 In addition to VN action primitives, TE Update primitive should also 226 be supported (See Section 2.1.7. for the description). 228 2.1. VN Action Primitives 230 This section provides a list of main primitives necessary to satisfy 231 ACTN requirements specified in [ACTN-REQ]. 233 describes main primitives. VN Action can be one of the 234 following primitives: (i) Instantiate; (ii) Modify; (iii) Delete; 235 (iv) Update; (v) Path Compute; (vi) Query. 237 ::= | 239 | 241 | 243 | 245 | 247 249 2.1.1. VN Instantiate 251 refers to an action from customers/applications to 252 request their VNs. This primitive can also be applied from an MDSC 253 to a PNC requesting a VN (if the domain the PNC supports can 254 instantiate the entire VN) or a part of VN elements. Please see the 255 definition of VN in the introduction section. 257 1. In the first case can be seen as an (or set of) e2e 258 connection(s) that can be formed by recursive aggregation of 259 lower level connections at provider level. Such end to end 260 connections include: customer end points, access links 261 (physical or virtual), intra domain tunnels and inter-domain 262 link (physical or virtual). 263 2. When VN is pre-configured is provided after a 264 static negotiation between customer and provider while in the 265 third case VN can be dynamically created, deleted, or modified 266 in response to requests from the customer. This implies dynamic 267 changes of network resources reserved for the customer. 268 3. In the second and third case, once that customer has obtained 269 his VN, can act upon the virtual network resources to perform 270 connection management (set-up/release/modify connections). 272 2.1.2. VN Modify 274 refers to an action from customers/applications to 275 modify an existing VN (i.e., instantiated VN). This primitive can 276 also be applied from an MDSC to a PNC requesting a VN (if the domain 277 the PNC supports can instantiate the entire VN) or a part of VN 278 elements. 280 2.1.3. VN Delete 282 refers to an action from customers/applications to 283 delete an existing VN. This primitive can also be applied from an 284 MDSC to a PNC requesting a VN (if the domain the PNC supports can 285 instantiate the entire VN) or a part of VN elements. 287 2.1.4. VN Update 289 refers to any update to the VN that need to be updated 290 to the subscribers. VN Update fulfills a push model. 292 Note the VN Update means the connection-related information (e.g., 293 LSPs) update that has association with VNs. See Section 2.2.6 for 294 further details. 296 There are other existing and upcoming TE mechanisms to fulfill the 297 same function as VN Update. VN Update can be built on these other 298 existing TE mechanisms. The details are TDB. 300 2.1.5. VN Path Compute 302 consists of Request and Reply. Request refers to 303 an action from customers/applications to request a VN path 304 computation. This primitive can also be applied from an MDSC to a 305 PNC requesting a VN (if the domain the PNC supports can instantiate 306 the entire VN) or a part of VN elements. 308 Reply refers to the reply in response to Request. 311 Request/Reply is to be differentiated from a VN 312 Instantiate. VNS connectivity. The purpose of VN Path Compute is a 313 priori exploration to estimate network resources availability and 314 getting a list of possible paths matching customer/applications 315 constraints. To make this type of request Customer/application 316 controller can have a shared (with lower controller) view of an 317 abstract network topology on which to get the constraints used as 318 input in Path Computation request. The list of paths obtained by the 319 request can be used by customer/applications to give path constrains 320 during VNS connectivity request and to compel the lower level 321 controller (e.g. MDSC)to select the path that Client/application 322 controller has chosen among the set of paths returned by the Path 323 Computation primitives. The importance of this primitives is for 324 example in a scenario like multi-domain in which the optimal path 325 obtained by an orchestrator as sum of optimal paths for different 326 domain controller cannot be the optial optimal path in the 327 Client/application controller prospective. This only applies between 328 CNC and MDSC. 330 2.1.6. VN Query 332 refers to any query pertaining to the VN that has been 333 already instantiated. VN Query fulfills a pull model and permit to 334 get topology view. 336 refers to the reply in response to . 338 2.1.7. TE Update (for TE resources) 340 it is a primitives specifically related to MPI 341 interface to provide TE resource update between any domain 342 controller towards MDSC regarding the entire content of any "domain 343 controller" TE topology or an abstracted filtered view of TE 344 topology depending on negotiated policy. 346 ::= [] 348 ::= 350 ::= [] 352 ::= [] 354 ::= [] 356 Where 358 provides information on level of abstraction (as 359 determined a priori). 361 ::= information related to the specific te- 362 topology related to nodes and links present in this TE-topology. 364 ::= detailed information related to a specific node 365 belonging to a te-topology e.g. te-node-attributes. 367 ::= information related to the specific link related 368 belonging to a te-topology e.g. te-link-attributes. 370 ::= information details associated to the 371 termination point of te-link related to a specific node. 373 2.2. VN Objects 375 This section provides a list of objects associated with VN action 376 primitives. 378 2.2.1. VN Identifier 380 is an identifier that identifies a unique VN. 382 2.2.2. VN Objective Function 384 describes the requirements/preferences of 385 VNs that customers/applications want to instantiate. 387 ::= 389 (...) 391 Note that needs to be defined for each s-d 392 pair being defined under a VN. Note that this is only applicable for 393 P2P or Multi-destination type. For other types, one VN Connectivity 394 Matrix suffices. 396 Where 398 ::= | | | 400 402 ::= 404 [] 406 [] 408 [] 410 2.2.3. VN End-Point 412 Object describes the VN's customer end-point 413 characteristics. 415 ::= ( 417 [] 419 [])... 421 It is assumed that a list of interface identifiers has been known 422 to the server prior to any VN actions. 424 The Client Capability comprises the client interface capability 425 (e.g., maximum interface bandwidth, etc.). 427 indicates if an End-point is source or not. 429 2.2.4. VN Survivability 431 describes all attributes related with the VN 432 protection level and its survivability policy enforced by the 433 customers/applications. 435 ::= 437 439 Where 441 ::= | <1+1> | <1:N> 443 ::= 445 [] 447 449 451 Where 453 is a delegation policy to the Server 454 to allow or not a local reroute fix upon a failure of the 455 primary LSP. 457 is only applied on the MPI where the MDSC 458 (client) provides a domain preference to each PNC (server). 460 is a policy that allows a server to trigger an 461 updated VN topology upon failure without an explicit request 462 from the client. Push action can be set as default unless 463 otherwise specified. 465 is another policy that triggers an 466 incremental update from the server since the last period of 467 update. Incremental update can be set as default unless 468 otherwise specified. 470 2.2.5. VN Action Status 472 is the status indicator whether the VN has been 473 successfully instantiated, modified, or deleted in the server 474 network or not in response to a particular VN action. 476 2.2.6. VN Associated LSP 478 describes the instantiated LSPs that is 479 associated with the VN. is used between each 480 domain PNC and the MDSC as part of VN Update once the VN is 481 instantiated in each domain network. 483 ::= (...) 485 2.2.7. VN Service Preference 487 This section provides VN Service preference. VN Service is defined 488 in Section 2. 490 ::= [] 492 [] 494 [] 496 Where 498 describes the End-Point Location's 499 support for certain Virtual Network Functions (VNFs) (e.g., 500 security function, firewall capability, etc.). 502 describes any preference related to 503 Virtual Network Service (VNS) that application/client can enforce 504 via CNC towards lower level controllers. For example, permission 505 the correct selection from the network of the destination related 506 to the indicated VNF It is e.g. the case of VM migration among 507 data center and CNC can enforce specific policy that can permit 508 MDSC/PNC to calculate the correct path for the connectivity 509 supporting the data center interconnection required by 510 application. 512 describes if the End- 513 Point can support load balancing, disaster recovery or VM 514 migration and so can be part of the selection by MDSC following 515 service Preference enforcement by CNC. 517 2.3. Mapping of VN Primitives with VN Objects 519 This section describes the mapping of VN Primitives with VN Objects 520 based on Section 2.2. 522 ::= 524 [] 526 528 [] 530 [] 532 ::= 534 [] 535 537 [] 539 [] 541 ::= 543 :: = 545 547 ::= 549 [] 551 553 [] 555 [] 557 ::= 559 561 ::= 563 ::= 565 567 3. References 569 3.1. Informative References 571 [ACTN-Req] Y. Lee, et al., "Requirements for Abstraction and Control 572 of Transport Networks", draft-lee-teas-actn-requirements, 573 work in progress. 575 [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and 576 Control of Transport Networks", draft-ceccarelli-teas- 577 actn-framework, work in progress. 579 [Stateful-PCE] E. Crabbe, et al., "PCEP Extensions for Stateful 580 PCE", draft-ietf-pce-stateful-pce, work in progress. 582 4. Contributors 584 Contributors' Addresses 586 Authors' Addresses 588 Young Lee (Editor) 589 Huawei Technologies 590 5340 Legacy Drive 591 Plano, TX 75023, USA 592 Phone: (469)277-5838 593 Email: leeyoung@huawei.com 595 Sergio Belotti (Editor) 596 Alcatel Lucent 597 Via Trento, 30 598 Vimercate, Italy 599 Email: sergio.belotti@alcatel-lucent.com 601 Dhruv Dhoddy 602 Huawei Technologies, 603 Divyashree Technopark, Whitefield 604 Bangalore, India 605 Email: dhruv.ietf@gmail.com 606 Daniele Ceccarelli 607 Ericsson 608 Torshamnsgatan,48 609 Stockholm, Sweden 610 Email: daniele.ceccarelli@ericsson.com 612 Bin Young Yun 613 ETRI 614 Email: byyun@etri.re.kr 616 Haomian Zheng 617 Huawei Technologies 618 Email: zhenghaomian@huawei.com 620 Xian Zhang 621 Huawei Technologies 622 Email: zhang.xian@huawei.com 624 Appendix A: ACTN Applications 626 A.1. Coordination of Multi-destination Service Requirement/Policy 628 +----------------+ 629 | CNC | 630 | (Global DC | 631 | Operation | 632 | Control) | 633 +--------+-------+ 634 | | Service Requirement/Policy: 635 | | - Endpoint/DC location info 636 | | - Endpoint/DC dynamic 637 | | selection policy 638 | | (for VM migration, DR, LB) 639 | v 640 +---------+---------+ 641 | Multi-domain | Service policy-driven 642 |Service Coordinator| dynamic DC selection 643 +-----+---+---+-----+ 644 | | | 645 | | | 646 +----------------+ | +----------------+ 647 | | | 648 +-----+-----+ +-----+------+ +------+-----+ 649 | PNC for | | PNC for | | PNC for | 650 | Transport | | Transport | | Transport | 651 | Network A | | Network B | | network C | 652 +-----------+ +------------+ +------------+ 653 | | | 654 +---+ ------ ------ ------ +---+ 655 |DC1|--//// \\\\ //// \\\\ //// \\\\---+DC5| 656 +---+ | | | | | | +---+ 657 | TN A +-----+ TN B +----+ TN C | 658 / | | | | | 659 / \\\\ //// / \\\\ //// \\\\ //// 660 +---+ ------ / ------ \ ------ \ 661 |DC2| / \ \+---+ 662 +---+ / \ |DC6| 663 +---+ \ +---+ +---+ 664 |DC3| \|DC4| 665 +---+ +---+ 667 DR: Disaster Recovery 668 LB: Load Balancing 669 Figure A.1: Service Policy-driven Data Center Selection 671 Figure A.1 shows how VN service policies from the CNC are 672 incorporated by the MDSC to support multi-destination applications. 673 Multi-destination applications refer to applications in which the 674 selection of the destination of a network path for a given source 675 needs to be decided dynamically to support such applications. 677 Data Center selection problems arise for VM mobility, disaster 678 recovery and load balancing cases. VN's service policy plays an 679 important role for virtual network operation. Service policy can be 680 static or dynamic. Dynamic service policy for data center selection 681 may be placed as a result of utilization of data center resources 682 supporting VNs. The MDSC would then incorporate this information to 683 meet the service objective of this application. 685 A.2. Application Service Policy-aware Network Operation 687 +----------------+ 688 | CNC | 689 | (Global DC | 690 | Operation | 691 | Control) | 692 +--------+-------+ 693 | | Application Service Policy 694 | | - VNF requirement (e.g. 695 | | security function, etc.) 696 | | - Location profile for each VNF 697 | v 698 +---------+---------+ 699 | Multi-domain | Dynamically select the 700 |Service Coordinator| network destination to 701 +-----+---+---+-----+ meet VNF requirement. 702 | | | 703 | | | 704 +---------------+ | +----------------+ 705 | | | 706 +------+-----+ +-----+------+ +------+-----+ 707 | PNC for | | PNC for | | PNC for | 708 | Transport | | Transport | | Transport | 709 | Network A | | Network B | | network C | 710 | | | | | | 711 +------------+ +------------+ +------------+ 712 | | | 713 {VNF b} | | | {VNF b,c} 714 +---+ ------ ------ ------ +---+ 715 |DC1|--//// \\\\ //// \\\\ //// \\\\-|DC5| 716 +---+ | | | | | |+---+ 717 | TN A +---+ TN B +--+ TN C | 718 / | | | | | 719 / \\\\ //// / \\\\ //// \\\\ //// 720 +---+ ------ / ------ \ ------ \ 721 |DC2| / \ \\+---+ 722 +---+ / \ |DC6| 723 {VNF a} +---+ +---+ +---+ 724 |DC3| |DC4| {VNF a,b,c} 725 +---+ +---+ 726 {VNF a, b} {VNF a, c} 728 Figure A.2: Application Service Policy-aware Network Operation 730 This scenario is similar to the previous case in that the VN service 731 policy for the application can be met by a set of multiple 732 destinations that provide the required virtual network functions 733 (VNF). Virtual network functions can be, for example, security 734 functions required by the VN application. The VN service policy by 735 the CNC would indicate the locations of a certain VNF that can be 736 fulfilled. This policy information is critical in finding the 737 optimal network path subject to this constraint. As VNFs can be 738 dynamically moved across different DCs, this policy should be 739 dynamically enforced from the CNC to the MDSC and the PNCs. 741 A.3. Network Function Virtualization Service Enabled Connectivity 743 +----------------+ 744 | CNC | 745 | (Global DC | 746 | Operation | 747 | Control) | 748 +--------+-------+ 749 | | Service Policy related to VNF 750 | | (e.g., firewall, traffic 751 | | optimizer) 752 | | 753 | v 754 +---------+---------+ 755 | Multi-domain | Select network 756 |Service Coordinator| connectivity subject to 757 +-----+---+---+-----+ meeting service policy 758 | | | 759 | | | 760 +---------------+ | +----------------+ 761 | | | 762 +------+-----+ +-----+------+ +------+-----+ 763 | PNC for | | PNC for | | PNC for | 764 | Transport | | Transport | | Transport | 765 | Network A | | Network B | | network C | 766 | | | | | | 767 +------------+ +------------+ +------------+ 768 | | | 769 | | | 770 +---+ ------ ------ ------ +---+ 771 |DC1|--//// \\\\ //// \\\\ //// \\\\-|DC5| 772 +---+ | | | | | |+---+ 773 | TN A +---+ TN B +--+ TN C | 774 / | | | | | 775 / \\\\ //// / \\\\ //// \\\\ //// 776 +---+ ------ / ------ \ ------ \ 777 |DC2| / \ \\+---+ 778 +---+ / \ |DC6| 779 +---+ +---+ +---+ 780 |DC3| |DC4| 781 +---+ +---+ 783 Figure A.3: Network Function Virtualization Service Enabled 784 Connectivity 786 Network Function Virtualization Services are usually setup between 787 customers' premises and service provider premises and are provided 788 mostly by cloud providers or content delivery providers. The context 789 may include, but not limited to a security function like firewall, a 790 traffic optimizer, the provisioning of storage or computation 791 capacity where the customer does not care whether the service is 792 implemented in a given data center or another. The customer has to 793 provide (and CNC is providing this)the type of VNF he needs and the 794 policy associated with it (e.g. metric like estimated delay to reach 795 where VNF is located in the DC). The policy linked to VNF is 796 requested as part of the VN instantiation. These services may be 797 hosted virtually by the provider or physically part of the network. 798 This allows the service provider to hide his own resources (both 799 network and data centers) and divert customer requests where most 800 suitable. This is also known as "end points mobility" case and 801 introduces new concepts of traffic and service provisioning and 802 resiliency (e.g., Virtual Machine mobility). 804 A.4. Dynamic Service Control Policy Enforcement for Performance and 805 Fault Management 807 +------------------------------------------------+ 808 | Customer Network Controller | 809 +------------------------------------------------+ 810 1.Traffic| /|\4.Traffic | /|\ 811 Monitor& | | Monitor | | 8.Traffic 812 Optimize | | Result 5.Service | | modify & 813 Policy | | modify& | | optimize 814 \|/ | optimize Req.\|/ | result 815 +------------------------------------------------+ 816 | Multi-domain Service Coordinator | 817 +------------------------------------------------+ 818 2. Path | /|\3.Traffic | /|\ 819 Monitor | | Monitor | |7.Path 820 Request | | Result 6.Path | | modify & 821 | | modify& | | optimize 822 \|/ | optimize Req.\|/ | result 823 +------------------------------------------------+ 824 | Physical Network Controller | 825 +------------------------------------------------+ 827 Figure A.4: Dynamic Service Control for Performance and Fault 828 Management 830 Figure A.4 shows the flow of dynamic service control policy 831 enforcement for performance and fault management initiated by 832 customer per VN. The feedback loop and filtering mechanism tailored 833 for VNs performed by the MDSC differentiates this ACTN scope from 834 traditional network management paradigm. VN level dynamic OAM data 835 model is a building block to support this capability. 837 A.5. E2E VN Survivability and Multi-Layer (Packet-Optical) Coordination 838 for Protection/Restoration 840 +----------------+ 841 | Customer | 842 | Network | 843 | Controller | 844 +--------*-------+ 845 * | E2E VN Survivability Req. 846 * | - VN Protection/Restoration 847 * v - 1+1, Restoration, etc. 848 +------*-----+ - End Point (EP) info. 849 | | 850 | MDSC | MDSC enforces VN survivability 851 | | requirement, determining the 852 | | optimal combination of Packet/ 853 +------*-----+ Optical protection/restoration 854 * Optical bypass, etc. 855 * 856 * 857 ********************************************** 858 * * * * 859 +----*-----+ +----*----+ +----*-----+ +----*----+ 860 |PNC for | |PNC for | |PNC for | |PNC for | 861 |Access N. | |Packet C.| |Optical C.| |Access N.| 862 +----*-----+ +----*----+ +----*-----+ +---*-----+ 863 * --*--- * * 864 * /// \\\ * * 865 --*--- | Packet | * ----*- 866 /// \\\ | Core +------+------/// \\\ 867 | Access +----\\ /// * | Access | 868 | Network | ---+-- * | Network | +---+ 869 |\\\ /// | * \\\ ///---+EP6| 870 | +---+- | | -----* -+---+ +---+ 871 +-+-+ | | +----/// \\\ | | 872 |EP1| | +--------------+ Optical | | | +---+ 873 +---+ | | Core +------+ +--+EP5| 874 +-+-+ \\\ /// +---+ 875 |EP2| ------ | 876 +---+ | | 877 +--++ ++--+ 878 |EP3| |EP4| 879 +---+ +---+ 881 Figure A.5: E2E VN Survivability and Multi-layer Coordination for 882 Protection and Restoration 884 Figure A.5 shows the need for E2E protection/restoration control 885 coordination that involves CNC, MDSC and PNCs to meet the VN 886 survivability requirement. VN survivability requirement and its 887 policy need to be translated into multi-domain and multi-layer 888 network protection and restoration scenarios across different 889 controller types. After an E2E path is setup successfully, the MDSC 890 has a unique role to enforce policy-based flexible VN survivability 891 requirement by coordinating all PNC domains. 893 As seen in Figure A.5, multi-layer (i.e., packet/optical) 894 coordination is a subset of this E2E protection/restoration control 895 operation. The MDSC has a role to play in determining an optimal 896 protection/restoration level based on the customer's VN 897 survivability requirement. For instance, the MDSC needs to interface 898 the PNC for packet core as well as the PNC for optical core and 899 enforce protection/restoration policy as part of the E2E 900 protection/restoration. Neither the PNC for packet core nor the PNC 901 for optical core is in a position to be aware of the E2E path and 902 its protection/restoration situation. This role of the MDSC is 903 unique for this reason. In some cases, the MDSC will have to 904 determine and enforce optical bypass to find a feasible reroute path 905 upon packet core network failure which cannot be resolved the packet 906 core network itself. 908 To coordinate this operation, the PNCs will need to update its 909 domain level abstract topology upon resource changes due to a 910 network failure or other factors. The MDSC will incorporate all 911 these update to determine if an alternative E2E reroute path is 912 necessary or not based on the changes reported from the PNCs. It 913 will need to update the E2E abstract topology and the affected CN's 914 VN topology in real-time. This refers to dynamic synchronization of 915 topology from Physical topology to abstract topology to VN topology. 917 MDSC will also need to perform the path restoration signaling to the 918 affected PNCs whenever necessary.