idnits 2.17.1 draft-ietf-teas-actn-requirements-08.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 12) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 25, 2018) is 2276 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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 Internet Draft Huawei 3 Intended status: Informational 4 Daniele Ceccarelli 5 Expires July 25, 2018. Ericsson 7 Takuya Miyasaka 8 KDDI 10 Jong Yoon Shin 11 SKT 13 Kwang-koog Lee 14 KT 16 January 25, 2018 18 Requirements for Abstraction and Control of TE Networks 20 draft-ietf-teas-actn-requirements-08.txt 22 Abstract 24 This document provides a set of requirements for abstraction and 25 control of Traffic Engineering networks to facilitate virtual 26 network operation via the creation of a single virtualized network 27 or a seamless service. This supports operators in viewing and 28 controlling different domains (at any dimension: applied technology, 29 administrative zones, or vendor-specific technology islands) as a 30 single virtualized network. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with 35 the provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six 43 months and may be updated, replaced, or obsoleted by other documents 44 at any time. It is inappropriate to use Internet-Drafts as 45 reference material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on July 25, 2018. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with 65 respect to this document. Code Components extracted from this 66 document must include Simplified BSD License text as described in 67 Section 4.e of the Trust Legal Provisions and are provided without 68 warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction...................................................2 73 2. High-level ACTN requirements...................................4 74 2.1. Service-Specific Requirements.............................4 75 2.2. Network-Related Requirements..............................7 76 3. References.....................................................9 77 3.1. Normative References......................................9 78 3.2. Informative References....................................9 79 4. Contributors..................................................10 80 Authors' Addresses...............................................11 82 1. Introduction 84 This document provides a set of requirements for Abstraction and 85 Control of Traffic Engineering (TE) Networks (ACTN) identified in 86 various use-cases specified by the operators. [ACTN-Frame] defines 87 the base reference architecture and terminology. 89 ACTN refers to the set of virtual network service operations needed 90 to orchestrate, control and manage large-scale multi-domain TE 91 networks so as to facilitate network programmability, automation, 92 efficient resource sharing, and end-to-end virtual service aware 93 connectivity. 95 These operations are summarized as follows: 97 - Abstraction and coordination of underlying network resources 98 independent of how these resources are managed or controlled, 99 so that higher-layer entities can dynamically control virtual 100 networks based on those resources. Control includes creating, 101 modifying, monitoring, and deleting virtual networks. 103 - Collation of the resources from multiple TE networks (multiple 104 technologies, equipment from multiple vendors, under the 105 control of multiple administrations) through a process of 106 hierarchical abstraction to present a customer with a single 107 virtual network. This is achieved by presenting the network 108 domain as an abstracted topology to the customer via open and 109 programmable interfaces. Hierarchical abstraction allows for 110 the recursion of controllers in a customer-provider 111 relationship. 113 - Orchestration of end-to-end virtual network services and 114 applications via allocation of network resources to meet 115 specific service, application and customer requirements. 117 - Adaptation of customer requests (to control virtual resources) 118 to the physical network resources performing the necessary 119 mapping, translation, isolation and, policy that allows 120 conveying, managing and enforcing customer policies with 121 respect to the services and the network of the customer. 123 - Provision via a data model of a computation scheme and virtual 124 control capability to customers who request virtual network 125 services. Note that these customers could, themselves, be 126 service providers. 128 ACTN solutions will build on, and extend, existing TE constructs and 129 TE mechanisms wherever possible and appropriate. Support for 130 controller-based approaches is specifically included in the possible 131 solution set. 133 1.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in 138 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 2. High-level ACTN requirements 143 This section provides a summary of use-cases in terms of two 144 categories: (i) service-specific requirements; (ii) network-related 145 requirements. All these requirements are specified by operators that 146 are interested in implementing ACTN. 148 Service-specific requirements listed below are uniquely applied to 149 the work scope of ACTN. Service-specific requirements are related to 150 the virtual service coordination function. These requirements are 151 related to customer's Virtual Networks (VN) in terms of service 152 policy associated with VNs such as service performance objectives, 153 VN endpoint location information for certain required service 154 specific functions (e.g., security and others), VN survivability 155 requirement, or dynamic service control policy, etc. 157 Network-related requirements are related to and necessary for 158 coherent/seamless for the virtual network operation function. These 159 requirements are related to multi-domain and multi-layer signaling, 160 routing, protection/restoration and re-optimization/re-grooming, 161 etc. 163 Each requirement specified in Sections 2.1 and 2.2 is derived from 164 ACTN use-cases: [CHENG], [DHODY], [FANG], [KLEE], [KUMAKI], [LOPEZ], 165 [SHIN], [XU], [XU2], and [SUZUKI]. 167 2.1. Service-Specific Requirements 169 1. Requirement 1: Virtual Network Service (VNS) creation 171 Customer MUST be able to request/instantiate the VNS to the network 172 within the confines of mutual agreement between customer and network 173 operator and network operator's capability. A VNS is the service 174 agreement between a customer and provider to provide a VN [ACTN- 175 Frame]. There are different types of VNS in terms of the VN types 176 the customer is allowed to operate (e.g., a VN type can be simply a 177 set of edge-to-edge links, or it can comprise of virtual nodes and 178 virtual links, etc.). The customer MUST be able to express VNS 179 policy that captures Service Level Agreements (SLA) associated with 180 virtual network service (e.g., Endpoint selection policy, routing 181 policy, time-related policy, etc.) 183 Reference: [KLEE], [LOPEZ], [SHIN], [DHODY], [FANG]. 185 2. Requirement 2: Virtual Network Service Query 187 Customer SHOULD be able to request VNS Query ("Can you give me these 188 VN(s)?") that include the following parameters: 190 - VN type: various VN types defined by the customer (e.g., 191 path, graph, etc.) 192 - VN end-points (Customer Edge interface information) 193 - VN Topology Service-specific Objective Functions (e.g., 194 maximum bandwidth, minimum latency, minimum hops, etc. and 195 any combination of them). 196 - VN constraints requirement (e.g., Maximum Latency threshold, 197 Minimum Bandwidth, etc.) 199 Reference: [KUMAKI], [FANG], [CHENG]. 201 3. Requirement 3: VNS Instantiation ("Please create a VNS for me") 203 Customer MUST be able to instantiate VNS that includes various VNS 204 related parameters: 206 - VN type: various VN types defined by the customer (e.g., 207 Type 1, Type 2, etc. See [ACTN-Frame] for the definition of 208 VN Type 1 and Type 2). 209 - VN end-points (Customer Edge interface information) 210 - VN Topology Service-specific Objective Functions (e.g., 211 maximum bandwidth, minimum latency, minimum hops, etc. and 212 any combination of them). 214 - VN constraints requirement (e.g., Maximum Latency threshold, 215 Minimum Bandwidth, etc.) 216 - VN Topology diversity when there are multiple instances of 217 VNS (e.g., VN1 and VN2 must be disjoint; Node/link disjoint 218 from other VNs) 220 Reference: [KUMAKI], [FANG], [CHENG]. 222 4. Requirement 4: VNS Lifecycle Management & Operation (M&O) 224 Customer MUST be able to perform the following VNS operations: 226 - VNS Delete: Customer MUST be able to delete VNS. 227 - VNS Modify: Customer MUST be able to modify VNS related 228 parameters during the lifecycle of the instantiated VNS. 230 Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE]. 232 5. Requirement 5: VNS Isolation 234 Customer's VN should be able to use arbitrary network topology, 235 routing, or forwarding functions as well as customized control 236 mechanisms independent of the underlying physical network and of 237 other coexisting virtual networks. Other customers' VNS operation 238 MUST NOT impact a particular customer's VNS network operation. 240 Reference: [KUMAKI], [FANG], [LOPEZ] 242 6. Requirement 6: Multi-Destination Coordination 244 Customer MUST be able to define and convey service/preference 245 requirements for multi-destination applications (e.g., set of 246 candidate sources/destinations, thresholds for load balancing, 247 disaster recovery policy, etc.) 249 Reference: [FANG], [LOPEZ], [SHIN]. 251 7. Requirement 7: VNS Performance Monitoring 253 The customer MUST be able to define performance monitoring 254 parameters and its associated policy such as frequency of report, 255 abstraction/aggregation level of performance data (e.g., VN level, 256 tunnel level, etc.) with dynamic feedback loop from the network. 258 Reference: [XU], [XU2], [DHODY], [CHENG] 260 8. Requirement 8: VNS Confidentiality and Security Requirements 262 The following confidentiality/security requirements MUST be 263 supported in all interfaces: 265 - Securing the request and control of resources, confidentially 266 of the information, and availability of function. 267 - Trust domain verification (external entity versus internal 268 entity) 269 - Encrypting data that flow between components, especially when 270 they are implemented at remote nodes, regardless if these are 271 external or internal network interfaces. 273 Reference: [KUMAKI], [FANG], [LOPEZ] 275 2.2. Network-Related Requirements 277 1. Requirement 1: Virtual Network Service Coordination 279 Network MUST be able to support the following VNS operations: 281 - VNS Delete: Upon customer's VNS deletion request, network 282 MUST be able to delete VNS. 283 - VNS Modify: Upon customer's VNS modification request, 284 network MUST be able to modify VNS related parameters during 285 the lifecycle of the instantiated VNS. 286 - VNS Monitor: Upon customer's VNS performance monitoring 287 setup, the network MUST be able to support VNS level 288 Operations, Administration and Management (OAM) Monitoring 289 under policy agreement. 291 Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE]. 293 2. Requirement 2: Topology Abstraction Capability 295 The network MUST be capable of managing its networks based on the 296 principle of topology abstraction to be able to scale multi-layer, 297 multi-domain networks. 299 Reference: [KLEE], [LOPEZ], [DHODY], [CHENG]. 301 3. Requirement 3: Multi-Domain & Multi-layer Coordination 303 Network coordination for multi-domain and multi-layer path 304 computation and path setup operation MUST be provided: 306 - End-to-end path computation across multi-domain networks 307 (based on abstract topology from each domain) 308 - Domain sequence determination 309 - Request for path signaling to each domain controller 310 - Alternative path computation if any of the domain 311 controllers cannot find its domain path 313 Reference: [CHENG], [DHODY], [KLEE], [LOPEZ], [SHIN], [SUZUKI]. 315 4. Requirement 4: End-to-End Path Restoration 317 End-to-end Path Restoration Operations MUST be provided with 318 seamless coordination between domain-level recovery schemes and 319 cross-domain recovery schemes. 321 Reference: [CHENG], [KLEE], [DHODY], [LOPEZ], [SHIN]. 323 5. Requirement 5: Dynamicity of virtual network control operations 325 Dynamic virtual network control operations MUST be supported. This 326 includes, but is not limited to, the following: 328 - Real-time VNS control (e.g., fast recovery/reroute upon 329 network failure). 330 - Fast convergence of abstracted topologies upon changes due 331 to failure or reconfiguration across the network domain 332 view, the multi-domain network view and the customer view. 334 - Large-scale VNS operation (e.g., the ability to query tens 335 of thousands of nodes, and to examine tens of thousands of 336 connectivity requests) for time-sensitive applications. 338 Reference: [SHIN], [XU], [XU2], [KLEE], [KUMAKI], [SUZUKI]. 340 3. Security Considerations 342 The ACTN requirements described in this document do not directly 343 bear specific security concerns. When these requirements are 344 implemented in specific interfaces, securing the request and control 345 of resources, confidentially of the information, and availability of 346 function, should all be critical security considerations. 348 4. IANA Considerations 350 This document has no actions for IANA. 352 5. References 354 5.1. Normative References 356 [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and 357 Control of Transport Networks", draft-ietf-teas-actn- 358 framework, work in progress. 360 5.2. Informative References 362 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 363 Requirement Levels", RFC 2119, March 1997. 365 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 366 Key Words", RFC 8174, May 2017. 368 [CHENG] W. Cheng, et. al., "ACTN Use-cases for Packet Transport 369 Networks in Mobile Backhaul Networks", draft-cheng-actn- 370 ptn-requirements-00, July 21, 2014. 372 [DHODY] D. Dhody, et. al., "Packet Optical Integration (POI) Use 373 Cases for Abstraction and Control of Transport Networks 374 (ACTN)", draft-dhody-actn-poi-use-case-07, October 28, 375 2016. 377 [FANG] L. Fang, "ACTN Use Case for Multi-domain Data Center 378 Interconnect", draft-fang-actn-multidomain-dci-01, 379 September 29, 2014. 381 [KLEE] K. Lee, H. Lee, R. Vilata, V. Lopez, "ACTN Use-case for E2E 382 Network Services in Multiple Vendor Domain Transport 383 Networks", draft-klee-teas-actn-connectivity-multi-domain- 384 03, July 31, 2017. 386 [KUMAKI] K. Kumaki, T. Miyasaka, "ACTN : Use case for Multi Tenant 387 VNO", draft-kumaki-teas-actn-multitenant-vno-00, May 29, 388 2014. 390 [LOPEZ] D. Lopez (Ed), "ACTN Use-case for Virtual Network Operation 391 for Multiple Domains in a Single Operator Network", draft- 392 lopez-actn-vno-multidomains-01, October 27, 2014. 394 [SHIN] J. Shin, R. Hwang, J. Lee, "ACTN Use-case for Mobile Virtual 395 Network Operation for Multiple Domains in a Single 396 Operator Network", draft-shin-actn-mvno-multi-domain-00, 397 June 30, 2014. 399 [XU] Y. Xu, et. al., "Use Cases and Requirements of Dynamic Service 400 Control based on Performance Monitoring in ACTN 401 Architecture", draft-xu-actn-perf-dynamic-service-control- 402 03, April 23, 2015. 404 [XU2] Y. Xu, et. al., "Requirements of Abstract Alarm Report in ACTN 405 architecture", draft-xu-teas-actn-abstract-alarm-report- 406 00, July 6, 2015. 408 [SUZUKI] T. Suzuki, et. al., "Use-case and Requirements for Multi- 409 domain Operation Plane Change", draft-suzuki-teas-actn- 410 multidomain-opc-00, July 6, 2015. 412 6. Contributors 413 Yunbin Xu 414 CATR 415 Email: xuyunbin@ritt.cn 417 Toshiaki Suzuki 418 Hitachi 419 Email: toshiaki.suzuki.cs@hitachi.com 421 Haomian Zheng 422 Huawei 423 Email: zhenghaomian@huawei.com 425 Authors' Addresses 427 Young Lee (Editor) 428 Huawei Technologies 429 5340 Legacy Drive 430 Plano, TX 75023, USA 431 Phone: (469)277-5838 432 Email: leeyoung@huawei.com 434 Daniele Ceccarelli 435 Ericsson 436 Torshamnsgatan,48 437 Stockholm, Sweden 438 Email: daniele.ceccarelli@ericsson.com 440 Takuya Miyasaka 441 KDDI 442 Email: ta-miyasaka@kddi.com 444 Jong Yoon Shin 445 SKT 446 Email: jongyoon.shin@sk.com 448 Kwang-koog Lee 449 KT 450 Email: kwangkoog.lee@kt.com 452 Dhruv Dhody 453 Huawei Technologies 454 Email: dhruv.ietf@gmail.com 456 Sergio Belotti 457 Nokia 458 Via Trento, 30 459 Vimercate, Italy 460 Email: sergio.belotti@nokia.com 462 Khuzema Pithewan 463 Peloton Technology 464 Email: khuzemap@gmail.com