idnits 2.17.1 draft-ietf-teas-actn-info-model-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 -- The document date (June 30, 2017) is 2492 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ACTN-REQ' is mentioned on line 203, but not defined == Missing Reference: 'RFC5441' is mentioned on line 369, but not defined == Missing Reference: 'RFC3630' is mentioned on line 401, but not defined == Missing Reference: 'RFC7471' is mentioned on line 401, but not defined == Missing Reference: 'RFC4427' is mentioned on line 432, but not defined == Unused Reference: 'DRAFT-SER-AWARE' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'Stateful-PCE' is defined on line 638, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-pce-pcep-service-aware-10 Summary: 2 errors (**), 0 flaws (~~), 9 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 Nokia 6 Expires: December 30, 2017 7 Dhruv Dhody 8 Huawei 10 Daniele Ceccarelli 11 Ericsson 13 Bin Young Yun 14 ETRI 16 June 30, 2017 18 Information Model for Abstraction and Control of TE Networks (ACTN) 20 draft-ietf-teas-actn-info-model-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 December 30, 2017. 49 Copyright Notice 51 Copyright (c) 2017 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 1.1. Terminology...............................................4 68 2. ACTN Common Interfaces Information Model.......................4 69 2.1. VN Action Primitives......................................5 70 2.1.1. VN Instantiate.......................................6 71 2.1.2. VN Modify............................................6 72 2.1.3. VN Delete............................................6 73 2.1.4. VN Update............................................7 74 2.1.5. VN Path Compute......................................7 75 2.1.6. VN Query.............................................7 76 2.1.7. TE Update (for TE resources).........................8 77 2.2. VN Objects................................................8 78 2.2.1. VN Identifier........................................9 79 2.2.2. VN Service Characteristics...........................9 80 2.2.3. VN End-Point........................................11 81 2.2.4. VN Objective Function...............................12 82 2.2.5. VN Action Status....................................13 83 2.2.6. VN Associated LSP...................................13 84 2.2.7. VN Computed Path....................................13 85 2.2.8. VN Service Preference...............................13 86 2.3. Mapping of VN Primitives with VN Objects.................14 87 3. References....................................................15 88 3.1. Normative References.....................................15 89 3.2. Informative References...................................16 90 4. Contributors..................................................16 91 Contributors' Addresses..........................................16 92 Authors' Addresses...............................................16 93 Appendix A: ACTN Applications....................................18 94 A.1. Coordination of Multi-destination Service 95 Requirement/Policy.........................................18 96 A.2. Application Service Policy-aware Network Operation....20 97 A.3. Network Function Virtualization Service Enabled 98 Connectivity...............................................22 99 A.4. Dynamic Service Control Policy Enforcement for 100 Performance and Fault Management...........................24 101 A.5. E2E VN Survivability and Multi-Layer (Packet-Optical) 102 Coordination for Protection/Restoration....................25 104 1. Introduction 106 This draft provides an information model for the requirements 107 identified in the ACTN requirements [ACTN-Req] and the ACTN 108 interfaces identified in the ACTN architecture and framework 109 document [ACTN-Frame]. 111 The purpose of this draft is to put all information elements of ACTN 112 in one place before proceeding to development work necessary for 113 protocol extensions and data models. 115 The ACTN reference architecture identified a three-tier control 116 hierarchy as depicted in Figure 1: 118 - Customer Network Controllers (CNC) 119 - Multi-Domain Service Coordinator (MDSC) 120 - Physical Network Controllers (PNC). 122 +-------+ +-------+ +-------+ 123 | CNC-A | | CNC-B | | CNC-C | 124 +-------+ +-------+ +-------+ 125 \___________ | ____________ _/ 126 ---------- | CMI ------------ 127 \ | / 128 +-----------------------+ 129 | MDSC | 130 +-----------------------+ 131 _________/ | \_________ 132 -------- | MPI ------------____ 133 / | \ 134 +-------+ +-------+ +-------+ 135 | PNC | | PNC | | PNC | 136 +-------+ +-------+ +-------+ 138 Figure 1: A Three-tier ACTN control hierarchy 140 The two interfaces with respect to the MDSC, one north of the MDSC 141 and the other south of the MDSC are referred to as CMI (CNC-MDSC 142 Interface) and MPI (MDSC-PNC Interface), respectively. It is 143 intended to model these two interfaces and derivative interfaces 144 thereof (e.g., MDSC to MSDC in a hierarchy of MDSCs) with one common 145 model. 147 Appendix A provides some relevant ACTN use-cases extracted from 148 [ACTN-Req]. Appendix A is information only and may help readers 149 understand the context of key use-cases addressed in [ACTN-Req]. 151 1.1. Terminology 153 Refer VN, VNS to [ACTN-Frame] and abstraction and abstract topology 154 to [RFC7926]. 156 2. ACTN Common Interfaces Information Model 158 This section provides ACTN common interface information model to 159 describe in terms of primitives, objects, their properties 160 (represented as attributes), their relationships, and the resources 161 for the service applications needed in the ACTN context. 163 The standard interface is described between a client controller and 164 a server controller. A client-server relationship is recursive 165 between a CNC and a MDSC and between a MDSC and a PNC. In the CMI, 166 the client is a CNC while the server is a MDSC. In the MPI, the 167 client is a MDSC and the server is a PNC. There may also be MDSC- 168 MDSC interface(s) that need to be supported. This may arise in a 169 hierarchy of MDSCs in which workloads may need to be partitioned to 170 multiple MDSCs. 172 Basic primitives (messages) are required between the CNC-MDSC and 173 MDSC-PNC controllers. These primitives can then be used to support 174 different ACTN network control functions like network topology 175 request/query, VN service request, path computation and connection 176 control, VN service policy negotiation, enforcement, routing 177 options, etc. 179 At a minimum, the following VN action primitives should be 180 supported: 182 - VN Instantiate (See Section 2.1.1. for the description) 184 - VN Modify (See Section 2.1.2. for the description) 186 - VN Delete (See Section 2.1.3. for the description) 188 - VN Update ((See Section 2.1.4. for the description) 190 - VN Path Compute (See Section 2.1.5. for the description) 192 - VN Query (See Section 2.1.6. for the description) 194 In addition to VN action primitives, TE Update primitive should also 195 be supported (See Section 2.1.7. for the description). 197 Note that all VN action primitives defined above are applicable only 198 to CMI while TE update primitive is applicable to both CMI and MPI." 200 2.1. VN Action Primitives 202 This section provides a list of main primitives necessary to satisfy 203 ACTN requirements specified in [ACTN-REQ]. 205 describes main primitives. VN Action can be one of the 206 following primitives: (i) VN Instantiate; (ii) VN Modify; (iii) VN 207 Delete; (iv) VN Update; (v) VN Path Compute; (vi) VN Query. 209 ::= | 211 | 213 | 215 | 217 | 219 221 2.1.1. VN Instantiate 223 refers to an action from customers/applications to 224 request their VNs. This primitive can also be applied from an MDSC 225 to a PNC requesting a VN (if the domain the PNC supports can 226 instantiate the entire VN) or a part of VN elements. Please see the 227 definition of VN in [ACTN-Frame]. 229 2.1.2. VN Modify 231 refers to an action from customers/applications to 232 modify an existing VN (i.e., instantiated VN). This primitive can 233 also be applied from an MDSC to a PNC requesting a VN (if the domain 234 the PNC supports can instantiate the entire VN) or a part of VN 235 elements. 237 2.1.3. VN Delete 239 refers to an action from customers/applications to 240 delete an existing VN. This primitive can also be applied from an 241 MDSC to a PNC requesting a VN (if the domain the PNC supports can 242 instantiate the entire VN) or a part of VN elements. 244 2.1.4. VN Update 246 refers to any update to the VN that need to be updated 247 to the subscribers. VN Update fulfills a push model at CMI level, to 248 make aware customers of any specific changes in the topology details 249 related to VN instantiated. 251 Note the VN Update means the connection-related information (e.g., 252 LSPs) update that has association with VNs. 254 2.1.5. VN Path Compute 256 consists of Request and Reply. Request refers to 257 an action from customers/applications to request a VN path 258 computation. This primitive can also be applied from an MDSC to a 259 PNC requesting a VN (if the domain the PNC supports can instantiate 260 the entire VN) or a part of VN elements. 262 Reply refers to the reply in response to Request. 265 Request/Reply is to be differentiated from a VN 266 Instantiate. The purpose of VN Path Compute is a priori exploration 267 to estimate network resources availability and getting a list of 268 possible paths matching customer/applications constraints. To make 269 this type of request Customer/application controller can have a 270 shared (with lower controller) view of an abstract network topology 271 on which to get the constraints used as input in a Path Computation 272 request. The list of paths obtained by the request can be used by 273 customer/applications to give path constrains during VNS 274 connectivity request and to compel the lower level controller (e.g. 275 MDSC) to select the path that Client/application controller has 276 chosen among the set of paths returned by the Path Computation 277 primitives. The importance of this primitives is for example in a 278 scenario like multi-domain in which the optimal path obtained by an 279 orchestrator as sum of optimal paths for different domain controller 280 cannot be the optimal path in the Client/application controller 281 prospective. This only applies between CNC and MDSC. 283 2.1.6. VN Query 285 refers to any query pertaining to the VN that has been 286 already instantiated. VN Query fulfills a pull model and permit to 287 get topology view. 289 refers to the reply in response to . 291 2.1.7. TE Update (for TE resources) 293 it is a primitives specifically related to MPI 294 interface to provide TE resource update between any domain 295 controller towards MDSC regarding the entire content of any "domain 296 controller" TE topology or an abstracted filtered view of TE 297 topology depending on negotiated policy. 299 ::= [] 301 ::= 303 ::= [] 305 ::= 307 ::= [] 309 Where 311 provides information on level of abstraction (as 312 determined a priori). 314 ::= information related to the specific te- 315 topology related to nodes and links present in this TE-topology. 317 ::= detailed information related to a specific node 318 belonging to a te-topology e.g. te-node-attributes [TE-TOPO]. 320 ::= information related to the specific link related 321 belonging to a te-topology e.g. te-link-attributes [TE-TOPO]. 323 ::= information details associated to the 324 termination point of te-link related to a specific node e.g. 325 interface-switching-capability [TE-TOPO]. 327 2.2. VN Objects 329 This section provides a list of objects associated to VN action 330 primitives. 332 2.2.1. VN Identifier 334 is a unique identifier of the VN. 336 2.2.2. VN Service Characteristics (applicable only to CMI) 338 VN Service Characteristics describes the customer/application 339 requirements against the VNs to be instantiated. 341 ::= 343 (...) 345 347 Where 349 ::= |||| 352 The Connectivity Type identifies the type of required VN Service. In 353 addition to the classical type of services (e.g. P2P/P2MP etc.), 354 ACTN defines the "multi-destination" service that is a new P2P 355 service where the end points are not fixed. They can be chosen among 356 a list of pre-configured end points or dynamically provided by the 357 CNC. 359 ::= 361 [] 363 The VN Traffic Matrix represents the traffic matrix parameters 364 required against the service connectivity required and so the VN 365 request instantiation between service related Access Points [ACTN- 366 Frame]. Bandwidth is a mandatory parameter and a number of optional 367 constrains can be specified in the (e.g. diversity, 368 cost). They can include objective functions and TE metrics bounds as 369 specified in [RFC5441]. 371 Further details on the VN constraints are specified below: 373 ::= [] 375 [] 377 [] 378 ( | ) 380 Where: 382 Identifies the layer topology at which the VN 383 service is requested. It could be for example MPLS, ODU, and OCh. 385 This allows asking for diversity constraints for a VN 386 Instantiate/Modify or a VN Path Compute. For example, a new VN or 387 a path is requested in total diversity from an existing one (e.g. 388 diversity exclusion). 390 ::= (...) | 392 (...) 394 Based on the realization of VN required, group of 395 physical resources can be impacted by the same risk. An E2E 396 tunnel can be impacted by this shared risk. This is used to get 397 the SRLG associated with the different tunnels composing a VN. 399 can include all the Metrics (cost, delay, delay 400 variation, latency), bandwidth utilization parameters defined and 401 referenced by [RFC3630] and [RFC7471]. 403 See Section 2.2.4. 405 describes all attributes related to the VN 406 recovery level and its survivability policy enforced by the 407 customers/applications. 409 ::= 411 [] 413 [] 415 Where: 417 It is a value representing the requested 418 level of resiliency required against the VN. The following 419 values are defined: 421 . Unprotected VN 422 . VN with per tunnel recovery: The recovery level is defined 423 against the tunnels composing the VN and it is specified in 424 the . 426 ::= <0:1>|<1+1>|<1:1>|<1:N>|| 428 430 The VN Tunnel Recovery Level indicates the type of protection 431 or restoration mechanism applied to the VN. It augments the 432 recovery types defined in [RFC4427]. 434 ::= [] 436 [] 438 [] 440 [] 442 Where: 444 is a delegation policy to the Server 445 to allow or not a local reroute fix upon a failure of the 446 primary LSP. 448 is only applied on the MPI where the MDSC 449 (client) provides a domain preference to each PNC 450 (server).e.g. when a inter-domain link fails, then PNC can 451 choose the alternative peering with this info. 453 is a policy that allows a server to trigger an 454 updated VN topology upon failure without an explicit request 455 from the client. Push action can be set as default unless 456 otherwise specified. 458 is another policy that triggers an 459 incremental update from the server since the last period of 460 update. Incremental update can be set as default unless 461 otherwise specified. 463 2.2.3. VN End-Point 465 Object describes the VN's customer end-point 466 characteristics. 468 ::= ( 470 [] 472 [])... 474 Where: 476 It represents a unique identifier of the 477 client end-point. They are used by the customer to ask for the 478 setup of a virtual network creation. A is defined 479 against each AP in the network and is shared between customer and 480 provider. Both the customer and the provider will map it against 481 his own physical resources. 483 An optional object that identifies the 484 capabilities of the access link related to the given access point. 485 (e.g., max-bandwidth, bandwidth availability, etc.) 487 indicates if an End-point is source or not. 489 2.2.4. VN Objective Function 491 The VN Objective Function applies to each VN member (i.e., each E2E 492 tunnel) of a VN. 494 The VN Objective Function can reuse objective functions defined in 495 [RFC5541] section 4. 497 For a single path computation, the following objective functions are 498 defined: 500 o MCP is the Minimum Cost Path with respect to a specific 501 metric (e.g. shortest path). 502 o MLP is the Minimum Load Path, that means find a path 503 composted by te-link least loaded. 504 o MBP is the Maximum residual Bandwidth Path. 506 For a concurrent path computation, the following objective functions 507 are defined: 509 o MBC is to Minimize aggregate Bandwidth Consumption. 510 o MLL is to Minimize the Load of the most loaded Link. 511 o MCC is to Minimize the Cumulative Cost of a set of paths. 513 2.2.5. VN Action Status 515 is the status indicator whether the VN has been 516 successfully instantiated, modified, or deleted in the server 517 network or not in response to a particular VN action. 519 Note that this action status object can be implicitly indicated and 520 thus not included in any of the VN primitives discussed in Section 521 2.3. 523 2.2.6. VN Associated LSP 525 describes the instantiated LSPs that is 526 associated with the VN. is used between each 527 domain PNC and the MDSC as part of VN Update once the VN is 528 instantiated in each domain network and when CNC want to have more 529 details about the topology instantiated as consequence of a VN 530 Instantiate. 532 ::= (...) 534 2.2.7. VN Computed Path 536 The VN Computed Path is the list of paths obtained after the VN path 537 computation request from higher controller. Note that the computed 538 path is to be distinguished from the LSP. When the computed path is 539 signaled in the network (and thus the resource is reserved for that 540 path), it becomes an LSP. 542 ::= (...) 544 2.2.8. VN Service Preference 546 This section provides VN Service preference. VN Service is defined 547 in Section 2. 549 ::= [] 551 [] 553 [] 555 Where 557 describes any preference related to 563 Virtual Network Service (VNS) that application/client can enforce 564 via CNC towards lower level controllers. For example, permission 565 the correct selection from the network of the destination related 566 to the indicated VNF It is e.g. the case of VM migration among 567 data center and CNC can enforce specific policy that can permit 568 MDSC/PNC to calculate the correct path for the connectivity 569 supporting the data center interconnection required by 570 application. 572 describes if the End- 573 Point (e.g. Data Center) can support load balancing, disaster 574 recovery or VM migration and so can be part of the selection by 575 MDSC following service Preference enforcement by CNC. 577 2.3. Mapping of VN Primitives with VN Objects 579 This section describes the mapping of VN Primitives with VN Objects 580 based on Section 2.2. 582 ::= 584 586 [] 588 ::= 590 592 594 [] 596 ::= 598 :: = 600 602 ::= 604 606 ::= 608 ::= 610 ::= 612 614 3. References 616 3.1. Normative References 618 [DRAFT-SER-AWARE] Dhruv Dhody, Qin Wu, Vishwas Manral, Zafar Ali, 619 and Kenji Kumaki, "Extensions to the Path Computation 620 Element Communication Protocol (PCEP) to compute service 621 aware Label Switched Path (LSP).," June 2016, draft-ietf- 622 pce-pcep-service-aware-10. 624 3.2. Informative References 626 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 627 draft-ietf-teas-yang-te-topo, work in progress.Informative 628 References 630 [ACTN-Req] Y. Lee, et al., "Requirements for Abstraction and Control 631 of Transport Networks", draft-lee-teas-actn-requirements, 632 work in progress. 634 [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and 635 Control of Transport Networks", draft-ceccarelli-teas- 636 actn-framework, work in progress. 638 [Stateful-PCE] E. Crabbe, et al., "PCEP Extensions for Stateful 639 PCE", draft-ietf-pce-stateful-pce, work in progress. 641 [RFC5541] JL. Le Roux, JP. Vasseur and Y. Lee, "Encoding of 642 Objective Functions in the Path Computation Element 643 Communication Protocol (PCEP)", RFC 5541, June 2009. 645 [RFC7926] A.Farrel, et al., "Problem Statement and Architecture for 646 Information Exchange between Interconnected Traffic- 647 Engineered Networks", RFC 7926, July 2016. 649 4. Contributors 651 Contributors' Addresses 653 Authors' Addresses 655 Young Lee (Editor) 656 Huawei Technologies 657 5340 Legacy Drive 658 Plano, TX 75023, USA 659 Phone: (469)277-5838 660 Email: leeyoung@huawei.com 662 Sergio Belotti (Editor) 663 Alcatel Lucent 664 Via Trento, 30 665 Vimercate, Italy 666 Email: sergio.belotti@alcatel-lucent.com 668 Dhruv Dhody 669 Huawei Technologies, 670 Divyashree Technopark, Whitefield 671 Bangalore, India 672 Email: dhruv.ietf@gmail.com 674 Daniele Ceccarelli 675 Ericsson 676 Torshamnsgatan,48 677 Stockholm, Sweden 678 Email: daniele.ceccarelli@ericsson.com 680 Bin Young Yun 681 ETRI 682 Email: byyun@etri.re.kr 684 Haomian Zheng 685 Huawei Technologies 686 Email: zhenghaomian@huawei.com 688 Xian Zhang 689 Huawei Technologies 690 Email: zhang.xian@huawei.com 692 Appendix A: ACTN Applications 694 A.1. Coordination of Multi-destination Service Requirement/Policy 696 +----------------+ 697 | CNC | 698 | (Global DC | 699 | Operation | 700 | Control) | 701 +--------+-------+ 702 | | Service Requirement/Policy: 703 | | - Endpoint/DC location info 704 | | - Endpoint/DC dynamic 705 | | selection policy 706 | | (for VM migration, DR, LB) 707 | v 708 +---------+---------+ 709 | Multi-domain | Service policy-driven 710 |Service Coordinator| dynamic DC selection 711 +-----+---+---+-----+ 712 | | | 713 | | | 714 +----------------+ | +----------------+ 715 | | | 716 +-----+-----+ +-----+------+ +------+-----+ 717 | PNC for | | PNC for | | PNC for | 718 | Transport | | Transport | | Transport | 719 | Network A | | Network B | | network C | 720 +-----------+ +------------+ +------------+ 721 | | | 722 +---+ ------ ------ ------ +---+ 723 |DC1|--//// \\\\ //// \\\\ //// \\\\---+DC5| 724 +---+ | | | | | | +---+ 725 | TN A +-----+ TN B +----+ TN C | 726 / | | | | | 727 / \\\\ //// / \\\\ //// \\\\ //// 728 +---+ ------ / ------ \ ------ \ 729 |DC2| / \ \+---+ 730 +---+ / \ |DC6| 731 +---+ \ +---+ +---+ 732 |DC3| \|DC4| 733 +---+ +---+ 735 DR: Disaster Recovery 736 LB: Load Balancing 737 Figure A.1: Service Policy-driven Data Center Selection 739 Figure A.1 shows how VN service policies from the CNC are 740 incorporated by the MDSC to support multi-destination applications. 741 Multi-destination applications refer to applications in which the 742 selection of the destination of a network path for a given source 743 needs to be decided dynamically to support such applications. 745 Data Center selection problems arise for VM mobility, disaster 746 recovery and load balancing cases. VN's service policy plays an 747 important role for virtual network operation. Service policy can be 748 static or dynamic. Dynamic service policy for data center selection 749 may be placed as a result of utilization of data center resources 750 supporting VNs. The MDSC would then incorporate this information to 751 meet the service objective of this application. 753 A.2. Application Service Policy-aware Network Operation 755 +----------------+ 756 | CNC | 757 | (Global DC | 758 | Operation | 759 | Control) | 760 +--------+-------+ 761 | | Application Service Policy 762 | | - VNF requirement (e.g. 763 | | security function, etc.) 764 | | - Location profile for each VNF 765 | v 766 +---------+---------+ 767 | Multi-domain | Dynamically select the 768 |Service Coordinator| network destination to 769 +-----+---+---+-----+ meet VNF requirement. 770 | | | 771 | | | 772 +---------------+ | +----------------+ 773 | | | 774 +------+-----+ +-----+------+ +------+-----+ 775 | PNC for | | PNC for | | PNC for | 776 | Transport | | Transport | | Transport | 777 | Network A | | Network B | | network C | 778 | | | | | | 779 +------------+ +------------+ +------------+ 780 | | | 781 {VNF b} | | | {VNF b,c} 782 +---+ ------ ------ ------ +---+ 783 |DC1|--//// \\\\ //// \\\\ //// \\\\-|DC5| 784 +---+ | | | | | |+---+ 785 | TN A +---+ TN B +--+ TN C | 786 / | | | | | 787 / \\\\ //// / \\\\ //// \\\\ //// 788 +---+ ------ / ------ \ ------ \ 789 |DC2| / \ \\+---+ 790 +---+ / \ |DC6| 791 {VNF a} +---+ +---+ +---+ 792 |DC3| |DC4| {VNF a,b,c} 793 +---+ +---+ 794 {VNF a, b} {VNF a, c} 796 Figure A.2: Application Service Policy-aware Network Operation 798 This scenario is similar to the previous case in that the VN service 799 policy for the application can be met by a set of multiple 800 destinations that provide the required virtual network functions 801 (VNF). Virtual network functions can be, for example, security 802 functions required by the VN application. The VN service policy by 803 the CNC would indicate the locations of a certain VNF that can be 804 fulfilled. This policy information is critical in finding the 805 optimal network path subject to this constraint. As VNFs can be 806 dynamically moved across different DCs, this policy should be 807 dynamically enforced from the CNC to the MDSC and the PNCs. 809 A.3. Network Function Virtualization Service Enabled Connectivity 811 +----------------+ 812 | CNC | 813 | (Global DC | 814 | Operation | 815 | Control) | 816 +--------+-------+ 817 | | Service Policy related to VNF 818 | | (e.g., firewall, traffic 819 | | optimizer) 820 | | 821 | v 822 +---------+---------+ 823 | Multi-domain | Select network 824 |Service Coordinator| connectivity subject to 825 +-----+---+---+-----+ meeting service policy 826 | | | 827 | | | 828 +---------------+ | +----------------+ 829 | | | 830 +------+-----+ +-----+------+ +------+-----+ 831 | PNC for | | PNC for | | PNC for | 832 | Transport | | Transport | | Transport | 833 | Network A | | Network B | | network C | 834 | | | | | | 835 +------------+ +------------+ +------------+ 836 | | | 837 | | | 838 +---+ ------ ------ ------ +---+ 839 |DC1|--//// \\\\ //// \\\\ //// \\\\-|DC5| 840 +---+ | | | | | |+---+ 841 | TN A +---+ TN B +--+ TN C | 842 / | | | | | 843 / \\\\ //// / \\\\ //// \\\\ //// 844 +---+ ------ / ------ \ ------ \ 845 |DC2| / \ \\+---+ 846 +---+ / \ |DC6| 847 +---+ +---+ +---+ 848 |DC3| |DC4| 849 +---+ +---+ 851 Figure A.3: Network Function Virtualization Service Enabled 852 Connectivity 854 Network Function Virtualization Services are usually setup between 855 customers' premises and service provider premises and are provided 856 mostly by cloud providers or content delivery providers. The context 857 may include, but not limited to a security function like firewall, a 858 traffic optimizer, the provisioning of storage or computation 859 capacity where the customer does not care whether the service is 860 implemented in a given data center or another. The customer has to 861 provide (and CNC is providing this)the type of VNF he needs and the 862 policy associated with it (e.g. metric like estimated delay to reach 863 where VNF is located in the DC). The policy linked to VNF is 864 requested as part of the VN instantiation. These services may be 865 hosted virtually by the provider or physically part of the network. 866 This allows the service provider to hide his own resources (both 867 network and data centers) and divert customer requests where most 868 suitable. This is also known as "end points mobility" case and 869 introduces new concepts of traffic and service provisioning and 870 resiliency (e.g., Virtual Machine mobility). 872 A.4. Dynamic Service Control Policy Enforcement for Performance and 873 Fault Management 875 +------------------------------------------------+ 876 | Customer Network Controller | 877 +------------------------------------------------+ 878 1.Traffic| /|\4.Traffic | /|\ 879 Monitor& | | Monitor | | 8.Traffic 880 Optimize | | Result 5.Service | | modify & 881 Policy | | modify& | | optimize 882 \|/ | optimize Req.\|/ | result 883 +------------------------------------------------+ 884 | Multi-domain Service Coordinator | 885 +------------------------------------------------+ 886 2. Path | /|\3.Traffic | /|\ 887 Monitor | | Monitor | |7.Path 888 Request | | Result 6.Path | | modify & 889 | | modify& | | optimize 890 \|/ | optimize Req.\|/ | result 891 +------------------------------------------------+ 892 | Physical Network Controller | 893 +------------------------------------------------+ 895 Figure A.4: Dynamic Service Control for Performance and Fault 896 Management 898 Figure A.4 shows the flow of dynamic service control policy 899 enforcement for performance and fault management initiated by 900 customer per VN. The feedback loop and filtering mechanism tailored 901 for VNs performed by the MDSC differentiates this ACTN scope from 902 traditional network management paradigm. VN level dynamic OAM data 903 model is a building block to support this capability. 905 A.5. E2E VN Survivability and Multi-Layer (Packet-Optical) Coordination 906 for Protection/Restoration 908 +----------------+ 909 | Customer | 910 | Network | 911 | Controller | 912 +--------*-------+ 913 * | E2E VN Survivability Req. 914 * | - VN Protection/Restoration 915 * v - 1+1, Restoration, etc. 916 +------*-----+ - End Point (EP) info. 917 | | 918 | MDSC | MDSC enforces VN survivability 919 | | requirement, determining the 920 | | optimal combination of Packet/ 921 +------*-----+ Optical protection/restoration 922 * Optical bypass, etc. 923 * 924 * 925 ********************************************** 926 * * * * 927 +----*-----+ +----*----+ +----*-----+ +----*----+ 928 |PNC for | |PNC for | |PNC for | |PNC for | 929 |Access N. | |Packet C.| |Optical C.| |Access N.| 930 +----*-----+ +----*----+ +----*-----+ +---*-----+ 931 * --*--- * * 932 * /// \\\ * * 933 --*--- | Packet | * ----*- 934 /// \\\ | Core +------+------/// \\\ 935 | Access +----\\ /// * | Access | 936 | Network | ---+-- * | Network | +---+ 937 |\\\ /// | * \\\ ///---+EP6| 938 | +---+- | | -----* -+---+ +---+ 939 +-+-+ | | +----/// \\\ | | 940 |EP1| | +--------------+ Optical | | | +---+ 941 +---+ | | Core +------+ +--+EP5| 942 +-+-+ \\\ /// +---+ 943 |EP2| ------ | 944 +---+ | | 945 +--++ ++--+ 946 |EP3| |EP4| 947 +---+ +---+ 949 Figure A.5: E2E VN Survivability and Multi-layer Coordination for 950 Protection and Restoration 952 Figure A.5 shows the need for E2E protection/restoration control 953 coordination that involves CNC, MDSC and PNCs to meet the VN 954 survivability requirement. VN survivability requirement and its 955 policy need to be translated into multi-domain and multi-layer 956 network protection and restoration scenarios across different 957 controller types. After an E2E path is setup successfully, the MDSC 958 has a unique role to enforce policy-based flexible VN survivability 959 requirement by coordinating all PNC domains. 961 As seen in Figure A.5, multi-layer (i.e., packet/optical) 962 coordination is a subset of this E2E protection/restoration control 963 operation. The MDSC has a role to play in determining an optimal 964 protection/restoration level based on the customer's VN 965 survivability requirement. For instance, the MDSC needs to interface 966 the PNC for packet core as well as the PNC for optical core and 967 enforce protection/restoration policy as part of the E2E 968 protection/restoration. Neither the PNC for packet core nor the PNC 969 for optical core is in a position to be aware of the E2E path and 970 its protection/restoration situation. This role of the MDSC is 971 unique for this reason. In some cases, the MDSC will have to 972 determine and enforce optical bypass to find a feasible reroute path 973 upon packet core network failure which cannot be resolved the packet 974 core network itself. 976 To coordinate this operation, the PNCs will need to update its 977 domain level abstract topology upon resource changes due to a 978 network failure or other factors. The MDSC will incorporate all 979 these update to determine if an alternative E2E reroute path is 980 necessary or not based on the changes reported from the PNCs. It 981 will need to update the E2E abstract topology and the affected CN's 982 VN topology in real-time. This refers to dynamic synchronization of 983 topology from Physical topology to abstract topology to VN topology. 985 MDSC will also need to perform the path restoration signaling to the 986 affected PNCs whenever necessary.