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