idnits 2.17.1 draft-ietf-teas-actn-requirements-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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 163: '... Customer MUST be able to request/in...' RFC 2119 keyword, line 169: '....). The customer MUST be able to expre...' RFC 2119 keyword, line 178: '... Customer SHOULD be able to request ...' RFC 2119 keyword, line 194: '... Customer MUST be able to instantiat...' RFC 2119 keyword, line 213: '... Customer MUST be able to perform th...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Customer's VN should be able to use arbitrary network topology, routing, or forwarding functions as well as customized control mechanisms independent of the underlying physical network and of other coexisting virtual networks. Other customers' VNS operation MUST not impact a particular customer's VNS network operation. -- The document date (May 12, 2017) is 2541 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ACTN-frame' is mentioned on line 90, but not defined == Unused Reference: 'ACTN-Frame' is defined on line 330, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Young Lee (Editor) 2 Dhruv Dhody 3 Internet Draft Huawei 5 Intended status: Informational Sergio Belotti 6 Nokia 7 Expires: November 2017 8 Khuzema Pithewan 9 Infinera 11 Daniele Ceccarelli 12 Ericsson 14 Takuya Miyasaka 15 KDDI 17 Jong Yoon Shin 18 SKT 20 May 12, 2017 22 Requirements for Abstraction and Control of TE Networks 24 draft-ietf-teas-actn-requirements-05.txt 26 Abstract 28 This document provides a set of requirements for abstraction and 29 control of Traffic Engineering networks to facilitate virtual 30 network operation via the creation of a single virtualized network 31 or a seamless service. This supports operators in viewing and 32 controlling different domains (at any dimension: applied technology, 33 administrative zones, or vendor-specific technology islands) as a 34 single virtualized network. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with 39 the provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six 47 months and may be updated, replaced, or obsoleted by other documents 48 at any time. It is inappropriate to use Internet-Drafts as 49 reference material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 This Internet-Draft will expire on November 12, 2017. 59 Copyright Notice 61 Copyright (c) 2017 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with 69 respect to this document. Code Components extracted from this 70 document must include Simplified BSD License text as described in 71 Section 4.e of the Trust Legal Provisions and are provided without 72 warranty as described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction...................................................3 77 2. High-level ACTN requirements...................................4 78 2.1. Service-Specific Requirements.............................4 79 2.2. Network-Related Requirements..............................7 80 3. References.....................................................9 81 3.1. Normative References......................................9 82 3.2. Informative References....................................9 83 4. Contributors..................................................10 84 Authors' Addresses...............................................10 86 1. Introduction 88 This document provides a set of requirements for Abstraction and 89 Control of Traffic Engineering (TE) Networks (ACTN) identified in 90 various use-cases specified by the operators. [ACTN-frame] defines 91 the base reference architecture and terminology. 93 ACTN refers to the set of virtual network service operations needed 94 to orchestrate, control and manage large-scale multi-domain TE 95 networks so as to facilitate network programmability, automation, 96 efficient resource sharing, and end-to-end virtual service aware 97 connectivity. 99 These operations are summarized as follows: 101 - Abstraction and coordination of underlying network resources 102 independent of how these resources are managed or controlled, 103 so that higher-layer entities can dynamically control virtual 104 networks based on those resources. Control includes creating, 105 modifying, monitoring, and deleting virtual networks. 107 - Collation of the resources from multiple TE networks (multiple 108 technologies, equipment from multiple vendors, under the 109 control of multiple administrations) through a process of 110 hierarchical abstraction to present a customer with a single 111 virtual network. This is achieved by presenting the network 112 domain as an abstracted topology to the customer via open and 113 programmable interfaces. Hierarchical abstraction allows for 114 the recursion of controllers in a customer-provider 115 relationship. 117 - Orchestration of end-to-end virtual network services and 118 applications via allocation of network resources to meet 119 specific service, application and customer requirements. 121 - Adaptation of customer requests (to control virtual resources) 122 to the physical network resources performing the necessary 123 mapping, translation, isolation and, policy that allows 124 conveying, managing and enforcing customer policies with 125 respect to the services and the network of the customer. 127 - Provision via a data model of a computation scheme and virtual 128 control capability to customers who request virtual network 129 services. Note that these customers could, themselves, be 130 service providers. 132 ACTN solutions will build on, and extend, existing TE constructs and 133 TE mechanisms wherever possible and appropriate. Support for 134 controller-based approaches is specifically included in the possible 135 solution set. 137 2. High-level ACTN requirements 139 This section provides a summary of use-cases in terms of two 140 categories: (i) service-specific requirements; (ii) network-related 141 requirements. All these requirements are specified by operators that 142 are interested in implementing ACTN. 144 Service-specific requirements listed below are uniquely applied to 145 the work scope of ACTN. Service-specific requirements are related to 146 the virtual service coordination function. These requirements are 147 related to customer's VNs in terms of service policy associated with 148 VNs such as service performance objectives, VN endpoint location 149 information for certain required service specific functions (e.g., 150 security and others), VN survivability requirement, or dynamic 151 service control policy, etc. 153 Network-related requirements are related to and necessary for 154 coherent/seamless for the virtual network operation function. These 155 requirements are related to multi-domain and multi-layer signaling, 156 routing, protection/restoration and synergy, re-optimization/re- 157 grooming, etc. 159 2.1. Service-Specific Requirements 161 1. Requirement 1: Virtual Network Service (VNS) creation 163 Customer MUST be able to request/instantiate the VNS to the network 164 within the confines of mutual agreement between customer and network 165 operator and network operator's capability. There are different 166 types of VNS in terms of the VN types the customer is allowed to 167 operate (e.g., a VN type can be simply a set of end-to-end tunnels, 168 or it can comprise of virtual nodes and links in mesh fashion, 169 etc.). The customer MUST be able to express VNS policy that captures 170 Service Level Agreements (SLA) associated with virtual network 171 service (e.g., Endpoint selection policy, routing policy, time- 172 related policy, etc.) 174 Reference: [KLEE], [LOPEZ], [SHIN], [DHODY], [FANG]. 176 2. Requirement 2: Virtual Network Service Query 178 Customer SHOULD be able to request VNS Query ("Can you give me these 179 VN(s)?") that include the following parameters: 181 - VN type: various VN types defined by the customer (e.g., 182 path, graph, etc.) 183 - VN end-points (Customer Edge interface information) 184 - VN Topology Service-specific Objective Functions (e.g., 185 maximum bandwidth, minimum latency, minimum hops, etc. and 186 any combination of them). 187 - VN constraints requirement (e.g., Maximum Latency threshold, 188 Minimum Bandwidth, etc.) 190 Reference: [KUMAKI], [FANG], [CHENG]. 192 3. Requirement 3: VNS Instantiation ("Please create a VNS for me") 194 Customer MUST be able to instantiate VNS that includes various VNS 195 related parameters: 197 - VN type: various VN types defined by the customer (e.g., 198 path, graph, etc.) 199 - VN end-points (Customer Edge interface information) 200 - VN Topology Service-specific Objective Functions (e.g., 201 maximum bandwidth, minimum latency, minimum hops, etc. and 202 any combination of them). 203 - VN constraints requirement (e.g., Maximum Latency threshold, 204 Minimum Bandwidth, etc.) 205 - VN Topology diversity when there are multiple instances of 206 VNS (e.g., VN1 and VN2 must be disjoint; Node/link disjoint 207 from other VNs) 209 Reference: [KUMAKI], [FANG], [CHENG]. 211 4. Requirement 4: VNS Lifecycle Management & Operation (M&O) 213 Customer MUST be able to perform the following VNS operations: 215 - VNS Delete: Customer MUST be able to delete VNS. 216 - VNS Modify: Customer MUST be able to modify VNS related 217 parameters during the lifecycle of the instantiated VNS. 219 Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE]. 221 5. Requirement 5: VNS Isolation 223 Customer's VN should be able to use arbitrary network topology, 224 routing, or forwarding functions as well as customized control 225 mechanisms independent of the underlying physical network and of 226 other coexisting virtual networks. Other customers' VNS operation 227 MUST not impact a particular customer's VNS network operation. 229 Reference: [KUMAKI], [FANG], [LOPEZ] 231 6. Requirement 6: Multi-Destination Coordination 233 Customer MUST be able to define and convey service/preference 234 requirements for multi-destination applications (e.g., set of 235 candidate sources/destinations, thresholds for load balancing, 236 disaster recovery policy, etc.) 238 Reference: [FANG], [LOPEZ], [SHIN]. 240 7. Requirement 7: VNS Performance Monitoring 242 The customer MUST be able to define performance monitoring 243 parameters and its associated policy such as frequency of report, 244 abstraction/aggregation level of performance data (e.g., VN level, 245 tunnel level, virtual link/node level, etc.) with dynamic feedback 246 loop from the network. 248 Reference: [XU], [XU2], [DHODY], [CHENG] 249 8. Requirement 8: VNS Confidentiality and Security Requirements 251 The following confidentiality/security requirements MUST be 252 supported in all interfaces: 254 - Securing the request and control of resources, confidentially 255 of the information, and availability of function. 256 - Trust domain verification (external entity versus internal 257 entity) 258 - Encrypting data that flow between components, especially when 259 they are implemented at remote nodes, regardless if these are 260 external or internal network interfaces. 262 2.2. Network-Related Requirements 264 1. Requirement 1: Virtual Network Service Coordination 266 Network MUST be able to support the following VNS operations: 268 - VNS Delete: Upon customer's VNS deletion request, network 269 MUST be able to delete VNS. 270 - VNS Modify: Upon customer's VNS modification request, 271 network MUST be able to modify VNS related parameters during 272 the lifecycle of the instantiated VNS. 273 - VNS Update: Upon customer's VNS performance monitoring 274 setup, the network MUST be able to support VNS level 275 Operations, Administration and Management (OAM) Monitoring 276 under policy agreement. 278 Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE]. 280 2. Requirement 2: Topology Abstraction Capability 282 The network MUST be capable of managing its networks based on the 283 principle of topology abstraction to be able to scale multi-layer, 284 multi-domain networks. 286 Reference: [KLEE], [LOPEZ], [DHODY], [CHENG]. 288 3. Requirement 3: Multi-Domain & Multi-layer Coordination 290 Network coordination for multi-domain and multi-layer path 291 computation and path setup operation MUST be provided: 293 - End-to-end path computation across multi-domain networks 294 (based on abstract topology from each domain) 295 - Domain sequence determination 296 - Request for path signaling to each domain controller 297 - Alternative path computation if any of the domain 298 controllers cannot find its domain path 300 Reference: [CHENG], [DHODY], [KLEE], [LOPEZ], [SHIN], [SUZUKI]. 302 4. Requirement 4: End-to-End Path Restoration 304 End-to-end Path Restoration Operations MUST be provided with 305 seamless coordination between domain-level recovery schemes and 306 cross-domain recovery schemes. 308 Reference: [CHENG], [KLEE], [DHODY], [LOPEZ], [SHIN]. 310 5. Requirement 5: Dynamicity of virtual network control operations 312 Dynamic virtual network control operations MUST be supported. This 313 includes, but is not limited to, the following: 315 - Real-time VNS control (e.g., fast recovery/reroute upon 316 network failure). 317 - Fast convergence of abstracted topologies upon changes due 318 to failure or reconfiguration across the network domain 319 view, the multi-domain network view and the customer view. 320 - Large-scale VNS operation (e.g., the ability to query tens 321 of thousands of nodes, and to examine tens of thousands of 322 connectivity requests) for time-sensitive applications. 324 Reference: [SHIN], [XU], [XU2], [KLEE], [KUMAKI], [SUZUKI]. 326 3. References 328 3.1. Normative References 330 [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and 331 Control of Transport Networks", draft-ietf-teas-actn- 332 framework, work in progress. 334 3.2. Informative References 336 [CHENG] W. Cheng, et. al., "ACTN Use-cases for Packet Transport 337 Networks in Mobile Backhaul Networks", draft-cheng-actn- 338 ptn-requirements, work in progress. 340 [DHODY] D. Dhody, et. al., "Packet Optical Integration (POI) Use 341 Cases for Abstraction and Control of Transport Networks 342 (ACTN)", draft-dhody-actn-poi-use-case, work in progress. 344 [FANG] L. Fang, "ACTN Use Case for Multi-domain Data Center 345 Interconnect", draft-fang-actn-multidomain-dci, work in 346 progress. 348 [KLEE] K. Lee, H. Lee, R. Vilata, V. Lopez, "ACTN Use-case for E2E 349 Network Services in Multiple Vendor Domain Transport 350 Networks", draft-klee-teas-actn-connectivity-multi-domain, 351 work-in-progress. 353 [KUMAKI] K. Kumaki, T. Miyasaka, "ACTN : Use case for Multi Tenant 354 VNO", draft-kumaki-teas-actn-multitenant-vno, work in 355 progress. 357 [LOPEZ] D. Lopez (Ed), "ACTN Use-case for Virtual Network Operation 358 for Multiple Domains in a Single Operator Network", draft- 359 lopez-actn-vno-multidomains, work in progress. 361 [SHIN] J. Shin, R. Hwang, J. Lee, "ACTN Use-case for Mobile Virtual 362 Network Operation for Multiple Domains in a Single 363 Operator Network", draft-shin-actn-mvno-multi-domain, work 364 in progress. 366 [XU] Y. Xu, et. al., "Use Cases and Requirements of Dynamic Service 367 Control based on Performance Monitoring in ACTN 368 Architecture", draft-xu-actn-perf-dynamic-service-control, 369 work in progress. 371 [XU2] Y. Xu, et. al., "Requirements of Abstract Alarm Report in ACTN 372 architecture", draft-xu-teas-actn-abstract-alarm-report, 373 work-in-progress. 375 [SUZUKI] T. Suzuki, et. al., "Use-case and Requirements for Multi- 376 domain Operation Plane Change", draft-suzuki-teas-actn- 377 multidomain-opc, work-in-progress. 379 4. Contributors 381 Kwangkook Lee 382 KT 383 Email: kwangkooglee@gmail.com 385 Yunbin Xu 386 CATR 387 Email: xuyunbin@mail.ritt.com.cn 389 Toshiaki Suzuki 390 Hitachi 391 Email: toshiaki.suzuki.cs@hitachi.com 393 Haomian Zheng 394 Huawei 395 Email: zhenghaomian@huawei.com 397 Authors' Addresses 399 Young Lee (Editor) 400 Huawei Technologies 401 5340 Legacy Drive 402 Plano, TX 75023, USA 403 Phone: (469)277-5838 404 Email: leeyoung@huawei.com 406 Dhruv Dhody 407 Huawei Technologies 408 Email: dhruv.ietf@gmail.com 410 Sergio Belotti 411 Nokia 412 Via Trento, 30 413 Vimercate, Italy 414 Email: sergio.belotti@nokia.com 416 Khuzema Pithewan 417 Infinera 418 Email: kpithewan@infinera.com 420 Daniele Ceccarelli 421 Ericsson 422 Torshamnsgatan,48 423 Stockholm, Sweden 424 Email: daniele.ceccarelli@ericsson.com 426 Takuya Miyasaka 427 KDDI 428 Email: ta-miyasaka@kddi.com 430 Jong Yoon Shin 431 SKT 432 Email: jongyoon.shin@sk.com