idnits 2.17.1 draft-ietf-teas-actn-info-model-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 23, 2017) is 2498 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ACTN-REQ' is mentioned on line 200, but not defined == Missing Reference: 'RFC5441' is mentioned on line 365, but not defined == Missing Reference: 'RFC3630' is mentioned on line 398, but not defined == Missing Reference: 'RFC7471' is mentioned on line 398, but not defined == Missing Reference: 'RFC4427' is mentioned on line 429, but not defined == Unused Reference: 'DRAFT-SER-AWARE' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'Stateful-PCE' is defined on line 635, 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 2017 7 Dhruv Dhody 8 Huawei 10 Daniele Ceccarelli 11 Ericsson 13 Bin Young Yun 14 ETRI 16 June 23, 2017 18 Information Model for Abstraction and Control of TE Networks (ACTN) 20 draft-ietf-teas-actn-info-model-01.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 August 23, 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............................................6 74 2.1.5. VN Path Compute......................................7 75 2.1.6. VN Query.............................................7 76 2.1.7. TE Update (for TE resources).........................7 77 2.2. VN Objects................................................8 78 2.2.1. VN Identifier........................................8 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 2.1. VN Action Primitives 199 This section provides a list of main primitives necessary to satisfy 200 ACTN requirements specified in [ACTN-REQ]. 202 describes main primitives. VN Action can be one of the 203 following primitives: (i) VN Instantiate; (ii) VN Modify; (iii) VN 204 Delete; (iv) VN Update; (v) VN Path Compute; (vi) VN Query. 206 ::= | 208 | 210 | 212 | 214 | 216 218 2.1.1. VN Instantiate 220 refers to an action from customers/applications to 221 request their VNs. This primitive can also be applied from an MDSC 222 to a PNC requesting a VN (if the domain the PNC supports can 223 instantiate the entire VN) or a part of VN elements. Please see the 224 definition of VN in [ACTN-Frame]. 226 2.1.2. VN Modify 228 refers to an action from customers/applications to 229 modify an existing VN (i.e., instantiated VN). This primitive can 230 also be applied from an MDSC to a PNC requesting a VN (if the domain 231 the PNC supports can instantiate the entire VN) or a part of VN 232 elements. 234 2.1.3. VN Delete 236 refers to an action from customers/applications to 237 delete an existing VN. This primitive can also be applied from an 238 MDSC to a PNC requesting a VN (if the domain the PNC supports can 239 instantiate the entire VN) or a part of VN elements. 241 2.1.4. VN Update 243 refers to any update to the VN that need to be updated 244 to the subscribers. VN Update fulfills a push model at CMI level, to 245 make aware customers of any specific changes in the topology details 246 related to VN instantiated. 248 Note the VN Update means the connection-related information (e.g., 249 LSPs) update that has association with VNs. 251 2.1.5. VN Path Compute 253 consists of Request and Reply. Request refers to 254 an action from customers/applications to request a VN path 255 computation. This primitive can also be applied from an MDSC to a 256 PNC requesting a VN (if the domain the PNC supports can instantiate 257 the entire VN) or a part of VN elements. 259 Reply refers to the reply in response to Request. 262 Request/Reply is to be differentiated from a VN 263 Instantiate. The purpose of VN Path Compute is a priori exploration 264 to estimate network resources availability and getting a list of 265 possible paths matching customer/applications constraints. To make 266 this type of request Customer/application controller can have a 267 shared (with lower controller) view of an abstract network topology 268 on which to get the constraints used as input in a Path Computation 269 request. The list of paths obtained by the request can be used by 270 customer/applications to give path constrains during VNS 271 connectivity request and to compel the lower level controller (e.g. 272 MDSC) to select the path that Client/application controller has 273 chosen among the set of paths returned by the Path Computation 274 primitives. The importance of this primitives is for example in a 275 scenario like multi-domain in which the optimal path obtained by an 276 orchestrator as sum of optimal paths for different domain controller 277 cannot be the optimal path in the Client/application controller 278 prospective. This only applies between CNC and MDSC. 280 2.1.6. VN Query 282 refers to any query pertaining to the VN that has been 283 already instantiated. VN Query fulfills a pull model and permit to 284 get topology view. 286 refers to the reply in response to . 288 2.1.7. TE Update (for TE resources) 289 it is a primitives specifically related to MPI 290 interface to provide TE resource update between any domain 291 controller towards MDSC regarding the entire content of any "domain 292 controller" TE topology or an abstracted filtered view of TE 293 topology depending on negotiated policy. 295 ::= [] 297 ::= 299 ::= [] 301 ::= 303 ::= [] 305 Where 307 provides information on level of abstraction (as 308 determined a priori). 310 ::= information related to the specific te- 311 topology related to nodes and links present in this TE-topology. 313 ::= detailed information related to a specific node 314 belonging to a te-topology e.g. te-node-attributes [TE-TOPO]. 316 ::= information related to the specific link related 317 belonging to a te-topology e.g. te-link-attributes [TE-TOPO]. 319 ::= information details associated to the 320 termination point of te-link related to a specific node e.g. 321 interface-switching-capability [TE-TOPO]. 323 2.2. VN Objects 325 This section provides a list of objects associated to VN action 326 primitives. 328 2.2.1. VN Identifier 330 is a unique identifier of the VN. 332 2.2.2. VN Service Characteristics (applicable only to CMI) 334 VN Service Characteristics describes the customer/application 335 requirements against the VNs to be instantiated. 337 ::= 339 (...) 341 343 Where 345 ::= |||| 348 The Connectivity Type identifies the type of required VN Service. In 349 addition to the classical type of services (e.g. P2P/P2MP etc.), 350 ACTN defines the "multi-destination" service that is a new P2P 351 service where the end points are not fixed. They can be chosen among 352 a list of pre-configured end points or dynamically provided by the 353 CNC. 355 ::= 357 [] 359 The VN Traffic Matrix represents the traffic matrix parameters 360 required against the service connectivity required and so the VN 361 request instantiation between service related Access Points [ACTN- 362 Frame]. Bandwidth is a mandatory parameter and a number of optional 363 constrains can be specified in the (e.g. diversity, 364 cost). They can include objective functions and TE metrics bounds as 365 specified in [RFC5441]. 367 Further details on the VN constraints are specified below: 369 ::= [] 371 [] 373 [] 375 ( | ) 377 Where: 379 Identifies the layer topology at which the VN 380 service is requested. It could be for example MPLS, ODU, and OCh. 382 This allows asking for diversity constraints for a VN 383 Instantiate/Modify or a VN Path Compute. For example, a new VN or 384 a path is requested in total diversity from an existing one (e.g. 385 diversity exclusion). 387 ::= (...) | 389 (...) 391 Based on the realization of VN required, group of 392 physical resources can be impacted by the same risk. An E2E 393 tunnel can be impacted by this shared risk. This is used to get 394 the SRLG associated with the different tunnels composing a VN. 396 can include all the Metrics (cost, delay, delay 397 variation, latency), bandwidth utilization parameters defined and 398 referenced by [RFC3630] and [RFC7471]. 400 See Section 2.2.4. 402 describes all attributes related to the VN 403 recovery level and its survivability policy enforced by the 404 customers/applications. 406 ::= 408 [] 410 [] 412 Where: 414 It is a value representing the requested 415 level of resiliency required against the VN. The following 416 values are defined: 418 . Unprotected VN 419 . VN with per tunnel recovery: The recovery level is defined 420 against the tunnels composing the VN and it is specified in 421 the . 423 ::= <0:1>|<1+1>|<1:1>|<1:N>|| 425 427 The VN Tunnel Recovery Level indicates the type of protection 428 or restoration mechanism applied to the VN. It augments the 429 recovery types defined in [RFC4427]. 431 ::= [] 433 [] 435 [] 437 [] 439 Where: 441 is a delegation policy to the Server 442 to allow or not a local reroute fix upon a failure of the 443 primary LSP. 445 is only applied on the MPI where the MDSC 446 (client) provides a domain preference to each PNC 447 (server).e.g. when a inter-domain link fails, then PNC can 448 choose the alternative peering with this info. 450 is a policy that allows a server to trigger an 451 updated VN topology upon failure without an explicit request 452 from the client. Push action can be set as default unless 453 otherwise specified. 455 is another policy that triggers an 456 incremental update from the server since the last period of 457 update. Incremental update can be set as default unless 458 otherwise specified. 460 2.2.3. VN End-Point 462 Object describes the VN's customer end-point 463 characteristics. 465 ::= ( 467 [] 469 [])... 471 Where: 473 It represents a unique identifier of the 474 client end-point. They are used by the customer to ask for the 475 setup of a virtual network creation. A is defined 476 against each AP in the network and is shared between customer and 477 provider. Both the customer and the provider will map it against 478 his own physical resources. 480 An optional object that identifies the 481 capabilities of the access link related to the given access point. 482 (e.g., max-bandwidth, bandwidth availability, etc.) 484 indicates if an End-point is source or not. 486 2.2.4. VN Objective Function 488 The VN Objective Function applies to each VN member (i.e., each E2E 489 tunnel) of a VN. 491 The VN Objective Function can reuse objective functions defined in 492 [RFC5541] section 4. 494 For a single path computation, the following objective functions are 495 defined: 497 o MCP is the Minimum Cost Path with respect to a specific 498 metric (e.g. shortest path). 499 o MLP is the Minimum Load Path, that means find a path 500 composted by te-link least loaded. 501 o MBP is the Maximum residual Bandwidth Path. 503 For a concurrent path computation, the following objective functions 504 are defined: 506 o MBC is to Minimize aggregate Bandwidth Consumption. 507 o MLL is to Minimize the Load of the most loaded Link. 508 o MCC is to Minimize the Cumulative Cost of a set of paths. 510 2.2.5. VN Action Status 512 is the status indicator whether the VN has been 513 successfully instantiated, modified, or deleted in the server 514 network or not in response to a particular VN action. 516 Note that this action status object can be implicitly indicated and 517 thus not included in any of the VN primitives discussed in Section 518 2.3. 520 2.2.6. VN Associated LSP 522 describes the instantiated LSPs that is 523 associated with the VN. is used between each 524 domain PNC and the MDSC as part of VN Update once the VN is 525 instantiated in each domain network and when CNC want to have more 526 details about the topology instantiated as consequence of a VN 527 Instantiate. 529 ::= (...) 531 2.2.7. VN Computed Path 533 The VN Computed Path is the list of paths obtained after the VN path 534 computation request from higher controller. Note that the computed 535 path is to be distinguished from the LSP. When the computed path is 536 signaled in the network (and thus the resource is reserved for that 537 path), it becomes an LSP. 539 ::= (...) 541 2.2.8. VN Service Preference 543 This section provides VN Service preference. VN Service is defined 544 in Section 2. 546 ::= [] 548 [] 550 [] 552 Where 554 describes any preference related to 560 Virtual Network Service (VNS) that application/client can enforce 561 via CNC towards lower level controllers. For example, permission 562 the correct selection from the network of the destination related 563 to the indicated VNF It is e.g. the case of VM migration among 564 data center and CNC can enforce specific policy that can permit 565 MDSC/PNC to calculate the correct path for the connectivity 566 supporting the data center interconnection required by 567 application. 569 describes if the End- 570 Point (e.g. Data Center) can support load balancing, disaster 571 recovery or VM migration and so can be part of the selection by 572 MDSC following service Preference enforcement by CNC. 574 2.3. Mapping of VN Primitives with VN Objects 576 This section describes the mapping of VN Primitives with VN Objects 577 based on Section 2.2. 579 ::= 581 583 [] 585 ::= 587 589 591 [] 593 ::= 595 :: = 597 599 ::= 601 603 ::= 605 ::= 607 ::= 609 611 3. References 613 3.1. Normative References 615 [DRAFT-SER-AWARE] Dhruv Dhody, Qin Wu, Vishwas Manral, Zafar Ali, 616 and Kenji Kumaki, "Extensions to the Path Computation 617 Element Communication Protocol (PCEP) to compute service 618 aware Label Switched Path (LSP).," June 2016, draft-ietf- 619 pce-pcep-service-aware-10. 621 3.2. Informative References 623 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 624 draft-ietf-teas-yang-te-topo, work in progress.Informative 625 References 627 [ACTN-Req] Y. Lee, et al., "Requirements for Abstraction and Control 628 of Transport Networks", draft-lee-teas-actn-requirements, 629 work in progress. 631 [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and 632 Control of Transport Networks", draft-ceccarelli-teas- 633 actn-framework, work in progress. 635 [Stateful-PCE] E. Crabbe, et al., "PCEP Extensions for Stateful 636 PCE", draft-ietf-pce-stateful-pce, work in progress. 638 [RFC5541] JL. Le Roux, JP. Vasseur and Y. Lee, "Encoding of 639 Objective Functions in the Path Computation Element 640 Communication Protocol (PCEP)", RFC 5541, June 2009. 642 [RFC7926] A.Farrel, et al., "Problem Statement and Architecture for 643 Information Exchange between Interconnected Traffic- 644 Engineered Networks", RFC 7926, July 2016. 646 4. Contributors 648 Contributors' Addresses 650 Authors' Addresses 652 Young Lee (Editor) 653 Huawei Technologies 654 5340 Legacy Drive 655 Plano, TX 75023, USA 656 Phone: (469)277-5838 657 Email: leeyoung@huawei.com 659 Sergio Belotti (Editor) 660 Alcatel Lucent 661 Via Trento, 30 662 Vimercate, Italy 663 Email: sergio.belotti@alcatel-lucent.com 665 Dhruv Dhody 666 Huawei Technologies, 667 Divyashree Technopark, Whitefield 668 Bangalore, India 669 Email: dhruv.ietf@gmail.com 671 Daniele Ceccarelli 672 Ericsson 673 Torshamnsgatan,48 674 Stockholm, Sweden 675 Email: daniele.ceccarelli@ericsson.com 677 Bin Young Yun 678 ETRI 679 Email: byyun@etri.re.kr 681 Haomian Zheng 682 Huawei Technologies 683 Email: zhenghaomian@huawei.com 685 Xian Zhang 686 Huawei Technologies 687 Email: zhang.xian@huawei.com 689 Appendix A: ACTN Applications 691 A.1. Coordination of Multi-destination Service Requirement/Policy 693 +----------------+ 694 | CNC | 695 | (Global DC | 696 | Operation | 697 | Control) | 698 +--------+-------+ 699 | | Service Requirement/Policy: 700 | | - Endpoint/DC location info 701 | | - Endpoint/DC dynamic 702 | | selection policy 703 | | (for VM migration, DR, LB) 704 | v 705 +---------+---------+ 706 | Multi-domain | Service policy-driven 707 |Service Coordinator| dynamic DC selection 708 +-----+---+---+-----+ 709 | | | 710 | | | 711 +----------------+ | +----------------+ 712 | | | 713 +-----+-----+ +-----+------+ +------+-----+ 714 | PNC for | | PNC for | | PNC for | 715 | Transport | | Transport | | Transport | 716 | Network A | | Network B | | network C | 717 +-----------+ +------------+ +------------+ 718 | | | 719 +---+ ------ ------ ------ +---+ 720 |DC1|--//// \\\\ //// \\\\ //// \\\\---+DC5| 721 +---+ | | | | | | +---+ 722 | TN A +-----+ TN B +----+ TN C | 723 / | | | | | 724 / \\\\ //// / \\\\ //// \\\\ //// 725 +---+ ------ / ------ \ ------ \ 726 |DC2| / \ \+---+ 727 +---+ / \ |DC6| 728 +---+ \ +---+ +---+ 729 |DC3| \|DC4| 730 +---+ +---+ 732 DR: Disaster Recovery 733 LB: Load Balancing 734 Figure A.1: Service Policy-driven Data Center Selection 736 Figure A.1 shows how VN service policies from the CNC are 737 incorporated by the MDSC to support multi-destination applications. 738 Multi-destination applications refer to applications in which the 739 selection of the destination of a network path for a given source 740 needs to be decided dynamically to support such applications. 742 Data Center selection problems arise for VM mobility, disaster 743 recovery and load balancing cases. VN's service policy plays an 744 important role for virtual network operation. Service policy can be 745 static or dynamic. Dynamic service policy for data center selection 746 may be placed as a result of utilization of data center resources 747 supporting VNs. The MDSC would then incorporate this information to 748 meet the service objective of this application. 750 A.2. Application Service Policy-aware Network Operation 752 +----------------+ 753 | CNC | 754 | (Global DC | 755 | Operation | 756 | Control) | 757 +--------+-------+ 758 | | Application Service Policy 759 | | - VNF requirement (e.g. 760 | | security function, etc.) 761 | | - Location profile for each VNF 762 | v 763 +---------+---------+ 764 | Multi-domain | Dynamically select the 765 |Service Coordinator| network destination to 766 +-----+---+---+-----+ meet VNF requirement. 767 | | | 768 | | | 769 +---------------+ | +----------------+ 770 | | | 771 +------+-----+ +-----+------+ +------+-----+ 772 | PNC for | | PNC for | | PNC for | 773 | Transport | | Transport | | Transport | 774 | Network A | | Network B | | network C | 775 | | | | | | 776 +------------+ +------------+ +------------+ 777 | | | 778 {VNF b} | | | {VNF b,c} 779 +---+ ------ ------ ------ +---+ 780 |DC1|--//// \\\\ //// \\\\ //// \\\\-|DC5| 781 +---+ | | | | | |+---+ 782 | TN A +---+ TN B +--+ TN C | 783 / | | | | | 784 / \\\\ //// / \\\\ //// \\\\ //// 785 +---+ ------ / ------ \ ------ \ 786 |DC2| / \ \\+---+ 787 +---+ / \ |DC6| 788 {VNF a} +---+ +---+ +---+ 789 |DC3| |DC4| {VNF a,b,c} 790 +---+ +---+ 791 {VNF a, b} {VNF a, c} 793 Figure A.2: Application Service Policy-aware Network Operation 795 This scenario is similar to the previous case in that the VN service 796 policy for the application can be met by a set of multiple 797 destinations that provide the required virtual network functions 798 (VNF). Virtual network functions can be, for example, security 799 functions required by the VN application. The VN service policy by 800 the CNC would indicate the locations of a certain VNF that can be 801 fulfilled. This policy information is critical in finding the 802 optimal network path subject to this constraint. As VNFs can be 803 dynamically moved across different DCs, this policy should be 804 dynamically enforced from the CNC to the MDSC and the PNCs. 806 A.3. Network Function Virtualization Service Enabled Connectivity 808 +----------------+ 809 | CNC | 810 | (Global DC | 811 | Operation | 812 | Control) | 813 +--------+-------+ 814 | | Service Policy related to VNF 815 | | (e.g., firewall, traffic 816 | | optimizer) 817 | | 818 | v 819 +---------+---------+ 820 | Multi-domain | Select network 821 |Service Coordinator| connectivity subject to 822 +-----+---+---+-----+ meeting service policy 823 | | | 824 | | | 825 +---------------+ | +----------------+ 826 | | | 827 +------+-----+ +-----+------+ +------+-----+ 828 | PNC for | | PNC for | | PNC for | 829 | Transport | | Transport | | Transport | 830 | Network A | | Network B | | network C | 831 | | | | | | 832 +------------+ +------------+ +------------+ 833 | | | 834 | | | 835 +---+ ------ ------ ------ +---+ 836 |DC1|--//// \\\\ //// \\\\ //// \\\\-|DC5| 837 +---+ | | | | | |+---+ 838 | TN A +---+ TN B +--+ TN C | 839 / | | | | | 840 / \\\\ //// / \\\\ //// \\\\ //// 841 +---+ ------ / ------ \ ------ \ 842 |DC2| / \ \\+---+ 843 +---+ / \ |DC6| 844 +---+ +---+ +---+ 845 |DC3| |DC4| 846 +---+ +---+ 848 Figure A.3: Network Function Virtualization Service Enabled 849 Connectivity 851 Network Function Virtualization Services are usually setup between 852 customers' premises and service provider premises and are provided 853 mostly by cloud providers or content delivery providers. The context 854 may include, but not limited to a security function like firewall, a 855 traffic optimizer, the provisioning of storage or computation 856 capacity where the customer does not care whether the service is 857 implemented in a given data center or another. The customer has to 858 provide (and CNC is providing this)the type of VNF he needs and the 859 policy associated with it (e.g. metric like estimated delay to reach 860 where VNF is located in the DC). The policy linked to VNF is 861 requested as part of the VN instantiation. These services may be 862 hosted virtually by the provider or physically part of the network. 863 This allows the service provider to hide his own resources (both 864 network and data centers) and divert customer requests where most 865 suitable. This is also known as "end points mobility" case and 866 introduces new concepts of traffic and service provisioning and 867 resiliency (e.g., Virtual Machine mobility). 869 A.4. Dynamic Service Control Policy Enforcement for Performance and 870 Fault Management 872 +------------------------------------------------+ 873 | Customer Network Controller | 874 +------------------------------------------------+ 875 1.Traffic| /|\4.Traffic | /|\ 876 Monitor& | | Monitor | | 8.Traffic 877 Optimize | | Result 5.Service | | modify & 878 Policy | | modify& | | optimize 879 \|/ | optimize Req.\|/ | result 880 +------------------------------------------------+ 881 | Multi-domain Service Coordinator | 882 +------------------------------------------------+ 883 2. Path | /|\3.Traffic | /|\ 884 Monitor | | Monitor | |7.Path 885 Request | | Result 6.Path | | modify & 886 | | modify& | | optimize 887 \|/ | optimize Req.\|/ | result 888 +------------------------------------------------+ 889 | Physical Network Controller | 890 +------------------------------------------------+ 892 Figure A.4: Dynamic Service Control for Performance and Fault 893 Management 895 Figure A.4 shows the flow of dynamic service control policy 896 enforcement for performance and fault management initiated by 897 customer per VN. The feedback loop and filtering mechanism tailored 898 for VNs performed by the MDSC differentiates this ACTN scope from 899 traditional network management paradigm. VN level dynamic OAM data 900 model is a building block to support this capability. 902 A.5. E2E VN Survivability and Multi-Layer (Packet-Optical) Coordination 903 for Protection/Restoration 905 +----------------+ 906 | Customer | 907 | Network | 908 | Controller | 909 +--------*-------+ 910 * | E2E VN Survivability Req. 911 * | - VN Protection/Restoration 912 * v - 1+1, Restoration, etc. 913 +------*-----+ - End Point (EP) info. 914 | | 915 | MDSC | MDSC enforces VN survivability 916 | | requirement, determining the 917 | | optimal combination of Packet/ 918 +------*-----+ Optical protection/restoration 919 * Optical bypass, etc. 920 * 921 * 922 ********************************************** 923 * * * * 924 +----*-----+ +----*----+ +----*-----+ +----*----+ 925 |PNC for | |PNC for | |PNC for | |PNC for | 926 |Access N. | |Packet C.| |Optical C.| |Access N.| 927 +----*-----+ +----*----+ +----*-----+ +---*-----+ 928 * --*--- * * 929 * /// \\\ * * 930 --*--- | Packet | * ----*- 931 /// \\\ | Core +------+------/// \\\ 932 | Access +----\\ /// * | Access | 933 | Network | ---+-- * | Network | +---+ 934 |\\\ /// | * \\\ ///---+EP6| 935 | +---+- | | -----* -+---+ +---+ 936 +-+-+ | | +----/// \\\ | | 937 |EP1| | +--------------+ Optical | | | +---+ 938 +---+ | | Core +------+ +--+EP5| 939 +-+-+ \\\ /// +---+ 940 |EP2| ------ | 941 +---+ | | 942 +--++ ++--+ 943 |EP3| |EP4| 944 +---+ +---+ 946 Figure A.5: E2E VN Survivability and Multi-layer Coordination for 947 Protection and Restoration 949 Figure A.5 shows the need for E2E protection/restoration control 950 coordination that involves CNC, MDSC and PNCs to meet the VN 951 survivability requirement. VN survivability requirement and its 952 policy need to be translated into multi-domain and multi-layer 953 network protection and restoration scenarios across different 954 controller types. After an E2E path is setup successfully, the MDSC 955 has a unique role to enforce policy-based flexible VN survivability 956 requirement by coordinating all PNC domains. 958 As seen in Figure A.5, multi-layer (i.e., packet/optical) 959 coordination is a subset of this E2E protection/restoration control 960 operation. The MDSC has a role to play in determining an optimal 961 protection/restoration level based on the customer's VN 962 survivability requirement. For instance, the MDSC needs to interface 963 the PNC for packet core as well as the PNC for optical core and 964 enforce protection/restoration policy as part of the E2E 965 protection/restoration. Neither the PNC for packet core nor the PNC 966 for optical core is in a position to be aware of the E2E path and 967 its protection/restoration situation. This role of the MDSC is 968 unique for this reason. In some cases, the MDSC will have to 969 determine and enforce optical bypass to find a feasible reroute path 970 upon packet core network failure which cannot be resolved the packet 971 core network itself. 973 To coordinate this operation, the PNCs will need to update its 974 domain level abstract topology upon resource changes due to a 975 network failure or other factors. The MDSC will incorporate all 976 these update to determine if an alternative E2E reroute path is 977 necessary or not based on the changes reported from the PNCs. It 978 will need to update the E2E abstract topology and the affected CN's 979 VN topology in real-time. This refers to dynamic synchronization of 980 topology from Physical topology to abstract topology to VN topology. 982 MDSC will also need to perform the path restoration signaling to the 983 affected PNCs whenever necessary.