idnits 2.17.1 draft-ietf-teas-actn-requirements-09.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 : ---------------------------------------------------------------------------- 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 (March 1, 2018) is 2242 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 September 1, 2018. Ericsson 7 Takuya Miyasaka 8 KDDI 10 Jong Yoon Shin 11 SKT 13 Kwang-koog Lee 14 KT 16 March 1, 2018 18 Requirements for Abstraction and Control of TE Networks 20 draft-ietf-teas-actn-requirements-09 22 Abstract 24 This document provides a set of functional requirements for 25 abstraction and control of Traffic Engineering networks to 26 facilitate virtual network operation via the creation of a single 27 virtualized network or a seamless service. This supports operators 28 in viewing and controlling different domains (at any dimension: 29 applied technology, administrative zones, or vendor-specific 30 technology islands) as a 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 September 1, 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...................................................3 73 1.1. Requirements Language.....................................4 74 2. High-level ACTN requirements...................................4 75 2.1. Service-Specific Requirements.............................5 76 2.2. Network-Related Requirements..............................7 77 3. Security Considerations........................................9 78 4. IANA Considerations............................................9 79 5. References....................................................10 80 5.1. Normative References.....................................10 81 5.2. Informative References...................................10 82 6. Contributors..................................................11 83 Authors' Addresses...............................................12 85 1. Introduction 87 This document provides a set of functional requirements for 88 Abstraction and Control of Traffic Engineering (TE) Networks (ACTN) 89 identified in various use-cases specified by the operators. [ACTN- 90 Frame] defines the base reference architecture and terminology. 92 ACTN refers to the set of virtual network service operations needed 93 to coordinate, control and manage large-scale multi-domain TE 94 networks so as to facilitate network programmability, automation, 95 efficient resource sharing, and end-to-end virtual service aware 96 connectivity. 98 These operations are summarized as follows: 100 - Abstraction and coordination of underlying network resources 101 independent of how these resources are managed or controlled, 102 so that higher-layer entities can dynamically control virtual 103 networks based on those resources. Control includes creating, 104 modifying, monitoring, and deleting virtual networks. 106 - Collation of the identifiers and other attributes of the 107 resources from multiple TE networks (multiple technologies, 108 equipment from multiple vendors, under the control of multiple 109 administrations) through a process of recursive abstraction to 110 present a customer with a single virtual network. This is 111 achieved by presenting the network domain as an abstracted 112 topology to the customer via open and programmable interfaces. 113 Recursive abstraction allows for the recursion of abstracted 114 data in a hierarchy of controllers.. It is expected that the 115 recursion levels should be at least three levels: customer 116 level, multi-domain network level, and domain network level. 118 - Coordination of end-to-end virtual network services and 119 applications via allocation of network resources to meet 120 specific service, application and customer requirements. Refer 121 to [ACTN-Frame] for the definition of coordination. 123 - Adaptation of customer requests (to control virtual resources) 124 to the physical network resources performing the necessary 125 mapping, translation, isolation and, policy that allows 126 conveying, managing and enforcing customer policies with 127 respect to the services and the network of the customer. 129 - Provision via a data model and virtual control capability to 130 customers who request virtual network services. Note that these 131 customers could, themselves, be service providers. 133 ACTN solutions will build on, and extend, existing TE constructs and 134 TE mechanisms wherever possible and appropriate. Support for 135 controller-based approaches is specifically included in the possible 136 solution set. 138 1.1. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in 143 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 2. High-level ACTN requirements 148 This section provides a summary of use-cases in terms of two 149 categories: (i) service-specific requirements; (ii) network-related 150 requirements. All these requirements are specified by operators that 151 are interested in implementing ACTN. 153 Service-specific requirements listed below are uniquely applied to 154 the work scope of ACTN. Service-specific requirements are related to 155 the virtual service coordination function. These requirements are 156 related to customer's Virtual Networks (VN) in terms of service 157 policy associated with VNs such as service performance objectives, 158 VN endpoint location information for certain required service 159 specific functions (e.g., security and others), VN survivability 160 requirement, or dynamic service control policy, etc. 162 Network-related requirements are related to and necessary for 163 coherent/seamless for the virtual network operation function. These 164 requirements are related to multi-domain and multi-layer signaling, 165 routing, protection/restoration and re-optimization/re-grooming, 166 etc. 168 Each requirement specified in Sections 2.1 and 2.2 is derived from 169 ACTN use-cases: [CHENG], [DHODY], [FANG], [KLEE], [KUMAKI], [LOPEZ], 170 [SHIN], [XU], [XU2], and [SUZUKI]. 172 2.1. Service-Specific Requirements 174 1. Requirement 1: Virtual Network Service (VNS) creation 176 Customer MUST be able to request/instantiate the VNS to the network 177 within the confines of mutual agreement between customer and network 178 operator and network operator's capability. A VNS is the service 179 agreement between a customer and provider to provide a VN [ACTN- 180 Frame]. There are different types of VNS in terms of the VN types 181 the customer is allowed to operate (e.g., a VN type can be simply a 182 set of edge-to-edge links, or it can comprise of virtual nodes and 183 virtual links, etc.). The customer MUST be able to express VNS 184 preference that captures Service Level Agreements (SLA) associated 185 with virtual network service (e.g., Endpoint selection preference, 186 routing preference, time-related preference, etc.) 188 Reference: [KLEE], [LOPEZ], [SHIN], [DHODY], [FANG]. 190 2. Requirement 2: Virtual Network Service Query 192 Customer SHOULD be able to request VNS Query ("Can you give me these 193 VN(s)?") that include the following parameters: 195 - VN type: various VN types defined by the customer (e.g., 196 path, graph, etc.) 197 - VN end-points (Customer Edge interface information) 198 - VN Topology Service-specific Objective Functions (e.g., a 199 set of objective functions as defined in [RFC5541] to be 200 supported on the paths, but not limited to). 201 - VN constraints requirement (e.g., Maximum Latency threshold, 202 Minimum Bandwidth, etc.) 204 Reference: [KUMAKI], [FANG], [CHENG]. 206 3. Requirement 3: VNS Instantiation ("Please create a VNS for me") 208 Customer MUST be able to instantiate VNS that includes various VNS 209 related parameters: 211 - VN type: various VN types defined by the customer (e.g., 212 Type 1, Type 2, etc. See [ACTN-Frame] for the definition of 213 VN Type 1 and Type 2). 214 - VN end-points (Customer Edge interface information) 215 - VN Topology Service-specific Objective Functions (e.g., a 216 set of objective functions as defined in [RFC5541] to be 217 supported on the paths, but not limited to). 218 - VN constraints requirement (e.g., Maximum Latency threshold, 219 Minimum Bandwidth, etc.) 220 - VN Topology diversity when there are multiple instances of 221 VNS (e.g., VN1 and VN2 must be disjoint; Node/link disjoint 222 from other VNs) 224 Note that Requirement 3 provides specific details of Requirement 1. 226 Reference: [KUMAKI], [FANG], [CHENG]. 228 4. Requirement 4: VNS Lifecycle Management & Operation (M&O) 230 Customer MUST be able to perform the following VNS operations: 232 - VNS Delete: Customer MUST be able to delete VNS. 233 - VNS Modify: Customer MUST be able to modify VNS related 234 parameters during the lifecycle of the instantiated VNS. 236 Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE]. 238 5. Requirement 5: VNS Isolation 240 Customer's VN should be able to use arbitrary network topology, 241 routing, or forwarding functions as well as customized control 242 mechanisms independent of the underlying physical network and of 243 other coexisting virtual networks. Other customers' VNS operation 244 MUST NOT impact a particular customer's VNS network operation. 246 Reference: [KUMAKI], [FANG], [LOPEZ] 248 6. Requirement 6: Multi-Destination Coordination 250 Customer MUST be able to define and convey service/preference 251 requirements for multi-destination applications (e.g., set of 252 candidate sources/destinations, thresholds for load balancing, 253 disaster recovery preference, etc.) 255 Reference: [FANG], [LOPEZ], [SHIN]. 257 7. Requirement 7: VNS Performance Monitoring 259 The customer MUST be able to define performance monitoring 260 parameters and its associated preference such as frequency of 261 report, abstraction/aggregation level of performance data (e.g., VN 262 level, tunnel level, etc.) with dynamic feedback loop from the 263 network. 265 Reference: [XU], [XU2], [DHODY], [CHENG] 267 8. Requirement 8: VNS Confidentiality and Security Requirements 269 The following confidentiality/security requirements MUST be 270 supported in all interfaces: 272 - Securing the request and control of resources, confidentially 273 of the information, and availability of function. 274 - Trust domain verification between a customer entity and a 275 network entity. It verifies if a trust relationship has been 276 established between these entities. 277 - Encrypting data that flow between components, especially when 278 they are implemented at remote nodes, regardless if these are 279 external or internal network interfaces. 281 Reference: [KUMAKI], [FANG], [LOPEZ] 283 2.2. Network-Related Requirements 285 1. Requirement 1: Virtual Network Service Coordination 287 Network MUST be able to support the following VNS operations: 289 - VNS Create: Upon customer's VNS creation request, network 290 MUST be able to create VNS within the confines of network 291 resource availability. 292 - VNS Delete: Upon customer's VNS deletion request, network 293 MUST be able to delete VNS. 294 - VNS Modify: Upon customer's VNS modification request, 295 network MUST be able to modify VNS related parameters during 296 the lifecycle of the instantiated VNS. 297 - VNS Monitor: Upon customer's VNS performance monitoring 298 setup, the network MUST be able to support VNS level 299 Operations, Administration and Management (OAM) Monitoring 300 under service agreement. 302 Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE]. 304 2. Requirement 2: Topology Abstraction Capability 306 The network MUST be capable of managing its networks based on the 307 principle of topology abstraction to be able to scale multi-layer, 308 multi-domain networks. 310 Reference: [KLEE], [LOPEZ], [DHODY], [CHENG]. 312 3. Requirement 3: Multi-Domain & Multi-layer Coordination 314 Network coordination for multi-domain and multi-layer path 315 computation and path setup operation MUST be provided: 317 - End-to-end path computation across multi-domain networks 318 (based on abstract topology from each domain) 319 - Domain sequence determination 320 - Request for path signaling to each domain controller 321 - Alternative TE path computation if any of the domain 322 controllers cannot find its domain path 324 Reference: [CHENG], [DHODY], [KLEE], [LOPEZ], [SHIN], [SUZUKI]. 326 4. Requirement 4: End-to-End Path Protection 328 End-to-end Path Protection Operations MUST be provided with seamless 329 coordination between domain-level protection schemes and cross- 330 domain protection schemes. 332 Reference: [CHENG], [KLEE], [DHODY], [LOPEZ], [SHIN]. 334 5. Requirement 5: Dynamicity of virtual network control operations 336 Dynamic virtual network control operations MUST be supported. This 337 includes, but is not limited to, the following: 339 - Real-time VNS control (e.g., fast recovery/reroute upon 340 network failure). 341 - Fast convergence of abstracted topologies upon changes due 342 to failure or reconfiguration across the network domain 343 view, the multi-domain network view and the customer view. 344 - Large-scale VNS operation (e.g., the ability to process tens 345 of thousands of connectivity requests) for time-sensitive 346 applications. 348 Reference: [SHIN], [XU], [XU2], [KLEE], [KUMAKI], [SUZUKI]. 350 3. Security Considerations 352 The ACTN requirements described in this document do not directly 353 bear specific security concerns. When these requirements are 354 implemented in specific interfaces, securing the request and control 355 of resources, confidentially of the information, and availability of 356 function, should all be critical security considerations. 358 4. IANA Considerations 360 This document has no actions for IANA. 362 5. References 364 5.1. Normative References 366 [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and 367 Control of Transport Networks", draft-ietf-teas-actn- 368 framework, work in progress. 370 5.2. Informative References 372 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 373 Requirement Levels", RFC 2119, March 1997. 375 [RFC5541] JL. Le Roux, JP. Vasseur, and Y. Lee, "Encoding of 376 Objective Functions in the Path Computation Element 377 Communication Protocol (PCEP)", RFC 5541, June 2009. 379 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 380 Key Words", RFC 8174, May 2017. 382 [CHENG] W. Cheng, et. al., "ACTN Use-cases for Packet Transport 383 Networks in Mobile Backhaul Networks", draft-cheng-actn- 384 ptn-requirements-00, July 21, 2014. 386 [DHODY] D. Dhody, et. al., "Packet Optical Integration (POI) Use 387 Cases for Abstraction and Control of Transport Networks 388 (ACTN)", draft-dhody-actn-poi-use-case-07, October 28, 389 2016. 391 [FANG] L. Fang, "ACTN Use Case for Multi-domain Data Center 392 Interconnect", draft-fang-actn-multidomain-dci-01, 393 September 29, 2014. 395 [KLEE] K. Lee, H. Lee, R. Vilata, V. Lopez, "ACTN Use-case for E2E 396 Network Services in Multiple Vendor Domain Transport 397 Networks", draft-klee-teas-actn-connectivity-multi-domain- 398 03, July 31, 2017. 400 [KUMAKI] K. Kumaki, T. Miyasaka, "ACTN : Use case for Multi Tenant 401 VNO", draft-kumaki-teas-actn-multitenant-vno-00, May 29, 402 2014. 404 [LOPEZ] D. Lopez (Ed), "ACTN Use-case for Virtual Network Operation 405 for Multiple Domains in a Single Operator Network", draft- 406 lopez-actn-vno-multidomains-01, October 27, 2014. 408 [SHIN] J. Shin, R. Hwang, J. Lee, "ACTN Use-case for Mobile Virtual 409 Network Operation for Multiple Domains in a Single 410 Operator Network", draft-shin-actn-mvno-multi-domain-00, 411 June 30, 2014. 413 [XU] Y. Xu, et. al., "Use Cases and Requirements of Dynamic Service 414 Control based on Performance Monitoring in ACTN 415 Architecture", draft-xu-actn-perf-dynamic-service-control- 416 03, April 23, 2015. 418 [XU2] Y. Xu, et. al., "Requirements of Abstract Alarm Report in ACTN 419 architecture", draft-xu-teas-actn-abstract-alarm-report- 420 00, July 6, 2015. 422 [SUZUKI] T. Suzuki, et. al., "Use-case and Requirements for Multi- 423 domain Operation Plane Change", draft-suzuki-teas-actn- 424 multidomain-opc-00, July 6, 2015. 426 6. Contributors 428 Dhruv Dhody 429 Huawei Technologies 430 Email: dhruv.ietf@gmail.com 432 Sergio Belotti 433 Nokia 434 Via Trento, 30 435 Vimercate, Italy 436 Email: sergio.belotti@nokia.com 438 Khuzema Pithewan 439 Peloton Technology 440 Email: khuzemap@gmail.com 442 Yunbin Xu 443 CATR 444 Email: xuyunbin@ritt.cn 446 Toshiaki Suzuki 447 Hitachi 448 Email: toshiaki.suzuki.cs@hitachi.com 450 Haomian Zheng 451 Huawei 452 Email: zhenghaomian@huawei.com 454 Authors' Addresses 456 Young Lee (Editor) 457 Huawei Technologies 458 5340 Legacy Drive 459 Plano, TX 75023, USA 460 Phone: (469)277-5838 461 Email: leeyoung@huawei.com 463 Daniele Ceccarelli 464 Ericsson 465 Torshamnsgatan,48 466 Stockholm, Sweden 467 Email: daniele.ceccarelli@ericsson.com 469 Takuya Miyasaka 470 KDDI 471 Email: ta-miyasaka@kddi.com 473 Jong Yoon Shin 474 SKT 475 Email: jongyoon.shin@sk.com 477 Kwang-koog Lee 478 KT 479 Email: kwangkoog.lee@kt.com