idnits 2.17.1 draft-leebelotti-teas-actn-info-05.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.) ** There are 2 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2016) is 2740 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ACTN-REQ' is mentioned on line 263, but not defined == Missing Reference: 'RFC5441' is mentioned on line 429, but not defined == Missing Reference: 'RFC3630' is mentioned on line 462, but not defined == Missing Reference: 'RFC7471' is mentioned on line 462, but not defined == Missing Reference: 'RFC4427' is mentioned on line 491, but not defined == Unused Reference: 'DRAFT-SER-AWARE' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'Stateful-PCE' is defined on line 704, 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: 3 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: April 2017 7 Dhruv Dhody 8 Huawei 10 Daniele Ceccarelli 11 Ericsson 13 Bin Young Yun 14 ETRI 16 October 24, 2016 18 Information Model for Abstraction and Control of TE Networks (ACTN) 20 draft-leebelotti-teas-actn-info-05.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 April 24, 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 1.1. Terminology...............................................4 68 2. ACTN Common Interfaces Information Model.......................6 69 2.1. VN Action Primitives......................................7 70 2.1.1. VN Instantiate.......................................7 71 2.1.2. VN Modify............................................7 72 2.1.3. VN Delete............................................8 73 2.1.4. VN Update............................................8 74 2.1.5. VN Path Compute......................................8 75 2.1.6. VN Query.............................................9 76 2.1.7. TE Update (for TE resources).........................9 77 2.2. VN Objects...............................................10 78 2.2.1. VN Identifier.......................................10 79 2.2.2. VN Service Characteristics..........................10 80 2.2.3. VN End-Point........................................13 81 2.2.4. VN Objective Function...............................13 82 2.2.5. VN Action Status....................................14 83 2.2.6. VN Associated LSP...................................14 84 2.2.7. VN Computed Path....................................14 85 2.2.8. VN Service Preference...............................15 86 2.3. Mapping of VN Primitives with VN Objects.................15 87 3. References....................................................17 88 3.1. Normative References.....................................17 89 3.2. Informative References...................................17 90 4. Contributors..................................................18 91 Contributors' Addresses..........................................18 92 Authors' Addresses...............................................18 93 Appendix A: ACTN Applications....................................19 94 A.1. Coordination of Multi-destination Service 95 Requirement/Policy.........................................19 96 A.2. Application Service Policy-aware Network Operation....21 97 A.3. Network Function Virtualization Service Enabled 98 Connectivity...............................................23 99 A.4. Dynamic Service Control Policy Enforcement for 100 Performance and Fault Management...........................25 101 A.5. E2E VN Survivability and Multi-Layer (Packet-Optical) 102 Coordination for Protection/Restoration....................26 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 o A Virtual Network is a client view (typically a network slice) 154 of the transport network. It is presented by the provider as a 155 set of physical and/or abstracted resources. Depending on the 156 agreement between client and provider various VN operations and 157 VN views are possible. There are three aspects related to VN: 159 1) VN Creation: VN could be pre-configured and created via 160 static negotiation between customer and provider. In 161 other cases, VN could also be created dynamically based 162 on the request from the customer with given SLA 163 attributes which satisfy the customer's objectives. 165 2) Dynamic Operations: VN could be further modified and 166 deleted based on customer request to request changes in 167 the network resources reserved for the customer. The 168 customer can further act upon the virtual network 169 resources to perform E2E tunnel management (set- 170 up/release/modify). These changes will incur subsequent 171 LSP management on the operator's level. 173 3) VN View: (a) VN can be seen as an (or set of) e2e 174 tunnel(s) from a customer point of view where an e2e 175 tunnel is referred as a VN member. Each VN member (i.e., 176 e2e tunnel) can then be formed by recursive aggregation 177 of lower level paths at a provider level. Such end to end 178 tunnels may comprise of customer end points, access 179 links, intra domain paths and inter-domain link. In this 180 view VN is thus a list of VN members. (b) VN can also be 181 seen as a terms of topology comprising of physical and 182 abstracted nodes and links. The nodes in this case 183 include physical customer end points, border nodes, and 184 internal nodes as well as abstracted nodes. Similarly the 185 links includes physical access, inter-domain and intra- 186 domain links as well as abstracted links. The abstracted 187 nodes and links in this view can be pre-negotiated or 188 created dynamically. 190 o A Virtual Network Service (VNS) is the creation and offering of 191 a Virtual Network by a provider to a customer in accordance 192 with SLA agreements reached between them (e.g., re satisfying 193 the customer's objectives). 195 o Abstraction is the process of applying policy to the available 196 TE information within a domain, to produce selective 197 information that represents the potential ability to connect 198 across the domain. Thus, abstraction does not necessarily 199 offer all possible connectivity options, but it presents a 200 general view of potential connectivity according to the 201 policies that determine how the domain's administrator wants to 202 allow the domain resources to be used [RFC7926]. 204 o Abstract topology: Every lower controller in the provider 205 network, when is representing its network topology to a higher 206 layer, it may want to selective hide details of the actual 207 network topology, as suggested for abstraction in [RFC7926]. In 208 such case, an abstract topology may be used for this purpose. 210 Abstract topology enhances scalability for the MDSC to operate 211 multi-domain networks. 213 2. ACTN Common Interfaces Information Model 215 This section provides ACTN common interface information model to 216 describe in terms of primitives, objects, their properties 217 (represented as attributes), their relationships, and the resources 218 for the service applications needed in the ACTN context. 220 Basic primitives (messages) are required between the CNC-MDSC and 221 MDSC-PNC controllers. These primitives can then be used to support 222 different ACTN network control functions like network topology 223 request/query, VN service request, path computation and connection 224 control, VN service policy negotiation, enforcement, routing 225 options, etc. 227 The standard interface is described between a client controller and 228 a server controller. A client-server relationship is recursive 229 between a CNC and a MDSC and between a MDSC and a PNC. In the CMI, 230 the client is a CNC while the server is a MDSC. In the MPI, the 231 client is a MDSC and the server is a PNC. There may also be MDSC- 232 MDSC interface(s) that need to be supported. This may arise in a 233 hierarchy of MDSCs in which workloads may need to be partitioned to 234 multiple MDSCs. 236 Basic primitives (messages) are required between the CNC-MDSC and 237 MDSC-PNC controllers. These primitives can then be used to support 238 different ACTN network control functions like network topology 239 request/query, VN service request, path computation and connection 240 control, VN service policy negotiation, enforcement, routing 241 options, etc. 243 At a minimum, the following VN action primitives should be 244 supported: 246 - VN Instantiate (See Section 2.1.1. for the description) 248 - VN Modify (See Section 2.1.2. for the description) 250 - VN Delete (See Section 2.1.3. for the description) 252 - VN Update ((See Section 2.1.4. for the description) 254 - VN Path Compute (See Section 2.1.5. for the description) 255 - VN Query (See Section 2.1.6. for the description) 257 In addition to VN action primitives, TE Update primitive should also 258 be supported (See Section 2.1.7. for the description). 260 2.1. VN Action Primitives 262 This section provides a list of main primitives necessary to satisfy 263 ACTN requirements specified in [ACTN-REQ]. 265 describes main primitives. VN Action can be one of the 266 following primitives: (i) VN Instantiate; (ii) VN Modify; (iii) VN 267 Delete; (iv) VN Update; (v) VN Path Compute; (vi) VN Query. 269 ::= | 271 | 273 | 275 | 277 | 279 281 2.1.1. VN Instantiate 283 refers to an action from customers/applications to 284 request their VNs. This primitive can also be applied from an MDSC 285 to a PNC requesting a VN (if the domain the PNC supports can 286 instantiate the entire VN) or a part of VN elements. Please see the 287 definition of VN in the section 2. 289 2.1.2. VN Modify 291 refers to an action from customers/applications to 292 modify an existing VN (i.e., instantiated VN). This primitive can 293 also be applied from an MDSC to a PNC requesting a VN (if the domain 294 the PNC supports can instantiate the entire VN) or a part of VN 295 elements. 297 2.1.3. VN Delete 299 refers to an action from customers/applications to 300 delete an existing VN. This primitive can also be applied from an 301 MDSC to a PNC requesting a VN (if the domain the PNC supports can 302 instantiate the entire VN) or a part of VN elements. 304 2.1.4. VN Update 306 refers to any update to the VN that need to be updated 307 to the subscribers. VN Update fulfills a push model at CMI level, to 308 make aware customers of any specific changes in the topology details 309 related to VN instantiated. 311 Note the VN Update means the connection-related information (e.g., 312 LSPs) update that has association with VNs. 314 2.1.5. VN Path Compute 316 consists of Request and Reply. Request refers to 317 an action from customers/applications to request a VN path 318 computation. This primitive can also be applied from an MDSC to a 319 PNC requesting a VN (if the domain the PNC supports can instantiate 320 the entire VN) or a part of VN elements. 322 Reply refers to the reply in response to Request. 325 Request/Reply is to be differentiated from a VN 326 Instantiate. The purpose of VN Path Compute is a priori exploration 327 to estimate network resources availability and getting a list of 328 possible paths matching customer/applications constraints. To make 329 this type of request Customer/application controller can have a 330 shared (with lower controller) view of an abstract network topology 331 on which to get the constraints used as input in a Path Computation 332 request. The list of paths obtained by the request can be used by 333 customer/applications to give path constrains during VNS 334 connectivity request and to compel the lower level controller (e.g. 335 MDSC) to select the path that Client/application controller has 336 chosen among the set of paths returned by the Path Computation 337 primitives. The importance of this primitives is for example in a 338 scenario like multi-domain in which the optimal path obtained by an 339 orchestrator as sum of optimal paths for different domain controller 340 cannot be the optimal path in the Client/application controller 341 prospective. This only applies between CNC and MDSC. 343 2.1.6. VN Query 345 refers to any query pertaining to the VN that has been 346 already instantiated. VN Query fulfills a pull model and permit to 347 get topology view. 349 refers to the reply in response to . 351 2.1.7. TE Update (for TE resources) 353 it is a primitives specifically related to MPI 354 interface to provide TE resource update between any domain 355 controller towards MDSC regarding the entire content of any "domain 356 controller" TE topology or an abstracted filtered view of TE 357 topology depending on negotiated policy. 359 ::= [] 361 ::= 363 ::= [] 365 ::= 367 ::= [] 369 Where 371 provides information on level of abstraction (as 372 determined a priori). 374 ::= information related to the specific te- 375 topology related to nodes and links present in this TE-topology. 377 ::= detailed information related to a specific node 378 belonging to a te-topology e.g. te-node-attributes [TE-TOPO]. 380 ::= information related to the specific link related 381 belonging to a te-topology e.g. te-link-attributes [TE-TOPO]. 383 ::= information details associated to the 384 termination point of te-link related to a specific node e.g. 385 interface-switching-capability [TE-TOPO]. 387 2.2. VN Objects 389 This section provides a list of objects associated to VN action 390 primitives. 392 2.2.1. VN Identifier 394 is a unique identifier of the VN. 396 2.2.2. VN Service Characteristics 398 VN Service Characteristics describes the customer/application 399 requirements against the VNs to be instantiated. 401 ::= 403 (...) 405 407 Where 409 ::= |||| 412 The Connectivity Type identifies the type of required VN Service. In 413 addition to the classical type of services (e.g. P2P/P2MP etc.), 414 ACTN defines the "multi-destination" service that is a new P2P 415 service where the end points are not fixed. They can be chosen among 416 a list of pre-configured end points or dynamically provided by the 417 CNC. 419 ::= 421 [] 423 The VN Traffic Matrix represents the traffic matrix parameters 424 required against the service connectivity required and so the VN 425 request instantiation between service related Access Points [ACTN- 426 Frame]. Bandwidth is a mandatory parameter and a number of optional 427 constrains can be specified in the (e.g. diversity, 428 cost). They can include objective functions and TE metrics bounds as 429 specified in [RFC5441]. 431 Further details on the VN constraints are specified below: 433 ::= [] 435 [] 437 [] 439 441 Where: 443 Identifies the layer at which the VN service is 444 requested. It could be for example MPLS, ODU, and OCh. 446 This allows asking for diversity constraints for a VN 447 Instantiate/Modify or a VN Path Compute. For example, a new VN or 448 a path is requested in total diversity from an existing one (e.g. 449 diversity exclusion). 451 ::= (...) | 453 (...) 455 Based on the realization of VN required, group of 456 physical resources can be impacted by the same risk. An E2E 457 tunnel can be impacted by this shared risk. This is used to get 458 the SRLG associated with the different tunnels composing a VN. 460 can include all the Metrics (cost, delay, delay 461 variation, latency), bandwidth utilization parameters defined and 462 referenced by [RFC3630] and [RFC7471]. 464 describes all attributes related to the VN 465 recovery level and its survivability policy enforced by the 466 customers/applications. 468 ::= 470 [] 472 [] 474 Where: 476 It is a value representing the requested 477 level of resiliency required against the VN. The following 478 values are defined: 480 . Unprotected VN 481 . VN with per tunnel recovery: The recovery level is defined 482 against the tunnels composing the VN and it is specified in 483 the . 485 ::= <0:1>|<1+1>|<1:1>|<1:N>|| 487 489 The VN Tunnel Recovery Level indicates the type of protection 490 or restoration mechanism applied to the VN. It augments the 491 recovery types defined in [RFC4427]. 493 ::= [] 495 [] 497 [] 499 [] 501 Where: 503 is a delegation policy to the Server 504 to allow or not a local reroute fix upon a failure of the 505 primary LSP. 507 is only applied on the MPI where the MDSC 508 (client) provides a domain preference to each PNC 509 (server).e.g. when a inter-domain link fails, then PNC can 510 choose the alternative peering with this info. 512 is a policy that allows a server to trigger an 513 updated VN topology upon failure without an explicit request 514 from the client. Push action can be set as default unless 515 otherwise specified. 517 is another policy that triggers an 518 incremental update from the server since the last period of 519 update. Incremental update can be set as default unless 520 otherwise specified. 522 2.2.3. VN End-Point 524 Object describes the VN's customer end-point 525 characteristics. 527 ::= ( 529 [] 531 [])... 533 Where: 535 It represents a unique identifier of the 536 client end-point. They are used by the customer to ask for the 537 setup of a virtual network creation. A is defined 538 against each AP in the network and is shared between customer and 539 provider. Both the customer and the provider will map it against 540 his own physical resources. 542 An optional object that identifies the 543 capabilities of the access link related to the given access point. 544 (e.g., max-bandwidth, bandwidth availability, etc.) 546 indicates if an End-point is source or not. 548 2.2.4. VN Objective Function 550 The VN Objective Function applies to each VN member (i.e., each E2E 551 tunnel) of a VN. 553 The VN Objective Function can reuse objective functions defined in 554 [RFC5541] section 4. 556 For a single path computation, the following objective functions are 557 defined: 559 o MCP is the Minimum Cost Path with respect to a specific 560 metric (e.g. shortest path). 562 o MLP is the Minimum Load Path, that means find a path 563 composted by te-link least loaded. 564 o MBP is the Maximum residual Bandwidth Path. 566 For a concurrent path computation, the following objective functions 567 are defined: 569 o MBC is to Minimize aggregate Bandwidth Consumption. 570 o MLL is to Minimize the Load of the most loaded Link. 571 o MCC is to Minimize the Cumulative Cost of a set of paths. 573 2.2.5. VN Action Status 575 is the status indicator whether the VN has been 576 successfully instantiated, modified, or deleted in the server 577 network or not in response to a particular VN action. 579 Note that this action status object can be implicitly indicated and 580 thus not included in any of the VN primitives discussed in Section 581 2.3. 583 2.2.6. VN Associated LSP 585 describes the instantiated LSPs that is 586 associated with the VN. is used between each 587 domain PNC and the MDSC as part of VN Update once the VN is 588 instantiated in each domain network and when CNC want to have more 589 details about the topology instantiated as consequence of a VN 590 Instantiate. 592 ::= (...) 594 2.2.7. VN Computed Path 596 The VN Computed Path is the list of paths obtained after the VN path 597 computation request from higher controller. Note that the computed 598 path is to be distinguished from the LSP. When the computed path is 599 signaled in the network (and thus the resource is reserved for that 600 path), it becomes an LSP. 602 ::= (...) 604 2.2.8. VN Service Preference 606 This section provides VN Service preference. VN Service is defined 607 in Section 2. 609 ::= [] 611 [] 613 [] 615 Where 617 describes any preference related to 623 Virtual Network Service (VNS) that application/client can enforce 624 via CNC towards lower level controllers. For example, permission 625 the correct selection from the network of the destination related 626 to the indicated VNF It is e.g. the case of VM migration among 627 data center and CNC can enforce specific policy that can permit 628 MDSC/PNC to calculate the correct path for the connectivity 629 supporting the data center interconnection required by 630 application. 632 describes if the End- 633 Point (e.g. Data Center) can support load balancing, disaster 634 recovery or VM migration and so can be part of the selection by 635 MDSC following service Preference enforcement by CNC. 637 2.3. Mapping of VN Primitives with VN Objects 639 This section describes the mapping of VN Primitives with VN Objects 640 based on Section 2.2. 642 ::= 644 646 648 [] 650 ::= 652 654 [] 656 658 [] 660 ::= 662 :: = 664 666 ::= 668 670 672 ::= 674 ::= 676 ::= 678 680 3. References 682 3.1. Normative References 684 [DRAFT-SER-AWARE] Dhruv Dhody, Qin Wu, Vishwas Manral, Zafar Ali, 685 and Kenji Kumaki, "Extensions to the Path Computation 686 Element Communication Protocol (PCEP) to compute service 687 aware Label Switched Path (LSP).," June 2016, draft-ietf- 688 pce-pcep-service-aware-10. 690 3.2. Informative References 692 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 693 draft-ietf-teas-yang-te-topo, work in progress.Informative 694 References 696 [ACTN-Req] Y. Lee, et al., "Requirements for Abstraction and Control 697 of Transport Networks", draft-lee-teas-actn-requirements, 698 work in progress. 700 [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and 701 Control of Transport Networks", draft-ceccarelli-teas- 702 actn-framework, work in progress. 704 [Stateful-PCE] E. Crabbe, et al., "PCEP Extensions for Stateful 705 PCE", draft-ietf-pce-stateful-pce, work in progress. 707 [RFC5541] JL. Le Roux, JP. Vasseur and Y. Lee, "Encoding of Objective Functions 708 in the Path Computation Element Communication Protocol (PCEP)", RFC 709 5541, June 2009. 711 [RFC7926] A.Farrel, et al., "Problem Statement and Architecture for 712 Information Exchange between Interconnected Traffic- 713 Engineered Networks", RFC 7926, July 2016. 715 4. Contributors 717 Contributors' Addresses 719 Authors' Addresses 721 Young Lee (Editor) 722 Huawei Technologies 723 5340 Legacy Drive 724 Plano, TX 75023, USA 725 Phone: (469)277-5838 726 Email: leeyoung@huawei.com 728 Sergio Belotti (Editor) 729 Alcatel Lucent 730 Via Trento, 30 731 Vimercate, Italy 732 Email: sergio.belotti@alcatel-lucent.com 734 Dhruv Dhody 735 Huawei Technologies, 736 Divyashree Technopark, Whitefield 737 Bangalore, India 738 Email: dhruv.ietf@gmail.com 740 Daniele Ceccarelli 741 Ericsson 742 Torshamnsgatan,48 743 Stockholm, Sweden 744 Email: daniele.ceccarelli@ericsson.com 746 Bin Young Yun 747 ETRI 748 Email: byyun@etri.re.kr 750 Haomian Zheng 751 Huawei Technologies 752 Email: zhenghaomian@huawei.com 754 Xian Zhang 755 Huawei Technologies 756 Email: zhang.xian@huawei.com 758 Appendix A: ACTN Applications 760 A.1. Coordination of Multi-destination Service Requirement/Policy 762 +----------------+ 763 | CNC | 764 | (Global DC | 765 | Operation | 766 | Control) | 767 +--------+-------+ 768 | | Service Requirement/Policy: 769 | | - Endpoint/DC location info 770 | | - Endpoint/DC dynamic 771 | | selection policy 772 | | (for VM migration, DR, LB) 773 | v 774 +---------+---------+ 775 | Multi-domain | Service policy-driven 776 |Service Coordinator| dynamic DC selection 777 +-----+---+---+-----+ 778 | | | 779 | | | 780 +----------------+ | +----------------+ 781 | | | 782 +-----+-----+ +-----+------+ +------+-----+ 783 | PNC for | | PNC for | | PNC for | 784 | Transport | | Transport | | Transport | 785 | Network A | | Network B | | network C | 786 +-----------+ +------------+ +------------+ 787 | | | 788 +---+ ------ ------ ------ +---+ 789 |DC1|--//// \\\\ //// \\\\ //// \\\\---+DC5| 790 +---+ | | | | | | +---+ 791 | TN A +-----+ TN B +----+ TN C | 792 / | | | | | 793 / \\\\ //// / \\\\ //// \\\\ //// 794 +---+ ------ / ------ \ ------ \ 795 |DC2| / \ \+---+ 796 +---+ / \ |DC6| 797 +---+ \ +---+ +---+ 798 |DC3| \|DC4| 799 +---+ +---+ 801 DR: Disaster Recovery 802 LB: Load Balancing 803 Figure A.1: Service Policy-driven Data Center Selection 805 Figure A.1 shows how VN service policies from the CNC are 806 incorporated by the MDSC to support multi-destination applications. 807 Multi-destination applications refer to applications in which the 808 selection of the destination of a network path for a given source 809 needs to be decided dynamically to support such applications. 811 Data Center selection problems arise for VM mobility, disaster 812 recovery and load balancing cases. VN's service policy plays an 813 important role for virtual network operation. Service policy can be 814 static or dynamic. Dynamic service policy for data center selection 815 may be placed as a result of utilization of data center resources 816 supporting VNs. The MDSC would then incorporate this information to 817 meet the service objective of this application. 819 A.2. Application Service Policy-aware Network Operation 821 +----------------+ 822 | CNC | 823 | (Global DC | 824 | Operation | 825 | Control) | 826 +--------+-------+ 827 | | Application Service Policy 828 | | - VNF requirement (e.g. 829 | | security function, etc.) 830 | | - Location profile for each VNF 831 | v 832 +---------+---------+ 833 | Multi-domain | Dynamically select the 834 |Service Coordinator| network destination to 835 +-----+---+---+-----+ meet VNF requirement. 836 | | | 837 | | | 838 +---------------+ | +----------------+ 839 | | | 840 +------+-----+ +-----+------+ +------+-----+ 841 | PNC for | | PNC for | | PNC for | 842 | Transport | | Transport | | Transport | 843 | Network A | | Network B | | network C | 844 | | | | | | 845 +------------+ +------------+ +------------+ 846 | | | 847 {VNF b} | | | {VNF b,c} 848 +---+ ------ ------ ------ +---+ 849 |DC1|--//// \\\\ //// \\\\ //// \\\\-|DC5| 850 +---+ | | | | | |+---+ 851 | TN A +---+ TN B +--+ TN C | 852 / | | | | | 853 / \\\\ //// / \\\\ //// \\\\ //// 854 +---+ ------ / ------ \ ------ \ 855 |DC2| / \ \\+---+ 856 +---+ / \ |DC6| 857 {VNF a} +---+ +---+ +---+ 858 |DC3| |DC4| {VNF a,b,c} 859 +---+ +---+ 860 {VNF a, b} {VNF a, c} 862 Figure A.2: Application Service Policy-aware Network Operation 864 This scenario is similar to the previous case in that the VN service 865 policy for the application can be met by a set of multiple 866 destinations that provide the required virtual network functions 867 (VNF). Virtual network functions can be, for example, security 868 functions required by the VN application. The VN service policy by 869 the CNC would indicate the locations of a certain VNF that can be 870 fulfilled. This policy information is critical in finding the 871 optimal network path subject to this constraint. As VNFs can be 872 dynamically moved across different DCs, this policy should be 873 dynamically enforced from the CNC to the MDSC and the PNCs. 875 A.3. Network Function Virtualization Service Enabled Connectivity 877 +----------------+ 878 | CNC | 879 | (Global DC | 880 | Operation | 881 | Control) | 882 +--------+-------+ 883 | | Service Policy related to VNF 884 | | (e.g., firewall, traffic 885 | | optimizer) 886 | | 887 | v 888 +---------+---------+ 889 | Multi-domain | Select network 890 |Service Coordinator| connectivity subject to 891 +-----+---+---+-----+ meeting service policy 892 | | | 893 | | | 894 +---------------+ | +----------------+ 895 | | | 896 +------+-----+ +-----+------+ +------+-----+ 897 | PNC for | | PNC for | | PNC for | 898 | Transport | | Transport | | Transport | 899 | Network A | | Network B | | network C | 900 | | | | | | 901 +------------+ +------------+ +------------+ 902 | | | 903 | | | 904 +---+ ------ ------ ------ +---+ 905 |DC1|--//// \\\\ //// \\\\ //// \\\\-|DC5| 906 +---+ | | | | | |+---+ 907 | TN A +---+ TN B +--+ TN C | 908 / | | | | | 909 / \\\\ //// / \\\\ //// \\\\ //// 910 +---+ ------ / ------ \ ------ \ 911 |DC2| / \ \\+---+ 912 +---+ / \ |DC6| 913 +---+ +---+ +---+ 914 |DC3| |DC4| 915 +---+ +---+ 917 Figure A.3: Network Function Virtualization Service Enabled 918 Connectivity 920 Network Function Virtualization Services are usually setup between 921 customers' premises and service provider premises and are provided 922 mostly by cloud providers or content delivery providers. The context 923 may include, but not limited to a security function like firewall, a 924 traffic optimizer, the provisioning of storage or computation 925 capacity where the customer does not care whether the service is 926 implemented in a given data center or another. The customer has to 927 provide (and CNC is providing this)the type of VNF he needs and the 928 policy associated with it (e.g. metric like estimated delay to reach 929 where VNF is located in the DC). The policy linked to VNF is 930 requested as part of the VN instantiation. These services may be 931 hosted virtually by the provider or physically part of the network. 932 This allows the service provider to hide his own resources (both 933 network and data centers) and divert customer requests where most 934 suitable. This is also known as "end points mobility" case and 935 introduces new concepts of traffic and service provisioning and 936 resiliency (e.g., Virtual Machine mobility). 938 A.4. Dynamic Service Control Policy Enforcement for Performance and 939 Fault Management 941 +------------------------------------------------+ 942 | Customer Network Controller | 943 +------------------------------------------------+ 944 1.Traffic| /|\4.Traffic | /|\ 945 Monitor& | | Monitor | | 8.Traffic 946 Optimize | | Result 5.Service | | modify & 947 Policy | | modify& | | optimize 948 \|/ | optimize Req.\|/ | result 949 +------------------------------------------------+ 950 | Multi-domain Service Coordinator | 951 +------------------------------------------------+ 952 2. Path | /|\3.Traffic | /|\ 953 Monitor | | Monitor | |7.Path 954 Request | | Result 6.Path | | modify & 955 | | modify& | | optimize 956 \|/ | optimize Req.\|/ | result 957 +------------------------------------------------+ 958 | Physical Network Controller | 959 +------------------------------------------------+ 961 Figure A.4: Dynamic Service Control for Performance and Fault 962 Management 964 Figure A.4 shows the flow of dynamic service control policy 965 enforcement for performance and fault management initiated by 966 customer per VN. The feedback loop and filtering mechanism tailored 967 for VNs performed by the MDSC differentiates this ACTN scope from 968 traditional network management paradigm. VN level dynamic OAM data 969 model is a building block to support this capability. 971 A.5. E2E VN Survivability and Multi-Layer (Packet-Optical) Coordination 972 for Protection/Restoration 974 +----------------+ 975 | Customer | 976 | Network | 977 | Controller | 978 +--------*-------+ 979 * | E2E VN Survivability Req. 980 * | - VN Protection/Restoration 981 * v - 1+1, Restoration, etc. 982 +------*-----+ - End Point (EP) info. 983 | | 984 | MDSC | MDSC enforces VN survivability 985 | | requirement, determining the 986 | | optimal combination of Packet/ 987 +------*-----+ Optical protection/restoration 988 * Optical bypass, etc. 989 * 990 * 991 ********************************************** 992 * * * * 993 +----*-----+ +----*----+ +----*-----+ +----*----+ 994 |PNC for | |PNC for | |PNC for | |PNC for | 995 |Access N. | |Packet C.| |Optical C.| |Access N.| 996 +----*-----+ +----*----+ +----*-----+ +---*-----+ 997 * --*--- * * 998 * /// \\\ * * 999 --*--- | Packet | * ----*- 1000 /// \\\ | Core +------+------/// \\\ 1001 | Access +----\\ /// * | Access | 1002 | Network | ---+-- * | Network | +---+ 1003 |\\\ /// | * \\\ ///---+EP6| 1004 | +---+- | | -----* -+---+ +---+ 1005 +-+-+ | | +----/// \\\ | | 1006 |EP1| | +--------------+ Optical | | | +---+ 1007 +---+ | | Core +------+ +--+EP5| 1008 +-+-+ \\\ /// +---+ 1009 |EP2| ------ | 1010 +---+ | | 1011 +--++ ++--+ 1012 |EP3| |EP4| 1013 +---+ +---+ 1015 Figure A.5: E2E VN Survivability and Multi-layer Coordination for 1016 Protection and Restoration 1018 Figure A.5 shows the need for E2E protection/restoration control 1019 coordination that involves CNC, MDSC and PNCs to meet the VN 1020 survivability requirement. VN survivability requirement and its 1021 policy need to be translated into multi-domain and multi-layer 1022 network protection and restoration scenarios across different 1023 controller types. After an E2E path is setup successfully, the MDSC 1024 has a unique role to enforce policy-based flexible VN survivability 1025 requirement by coordinating all PNC domains. 1027 As seen in Figure A.5, multi-layer (i.e., packet/optical) 1028 coordination is a subset of this E2E protection/restoration control 1029 operation. The MDSC has a role to play in determining an optimal 1030 protection/restoration level based on the customer's VN 1031 survivability requirement. For instance, the MDSC needs to interface 1032 the PNC for packet core as well as the PNC for optical core and 1033 enforce protection/restoration policy as part of the E2E 1034 protection/restoration. Neither the PNC for packet core nor the PNC 1035 for optical core is in a position to be aware of the E2E path and 1036 its protection/restoration situation. This role of the MDSC is 1037 unique for this reason. In some cases, the MDSC will have to 1038 determine and enforce optical bypass to find a feasible reroute path 1039 upon packet core network failure which cannot be resolved the packet 1040 core network itself. 1042 To coordinate this operation, the PNCs will need to update its 1043 domain level abstract topology upon resource changes due to a 1044 network failure or other factors. The MDSC will incorporate all 1045 these update to determine if an alternative E2E reroute path is 1046 necessary or not based on the changes reported from the PNCs. It 1047 will need to update the E2E abstract topology and the affected CN's 1048 VN topology in real-time. This refers to dynamic synchronization of 1049 topology from Physical topology to abstract topology to VN topology. 1051 MDSC will also need to perform the path restoration signaling to the 1052 affected PNCs whenever necessary.