--- 1/draft-ietf-teas-actn-requirements-05.txt 2017-10-11 07:13:24.011156361 -0700 +++ 2/draft-ietf-teas-actn-requirements-06.txt 2017-10-11 07:13:24.035156921 -0700 @@ -1,34 +1,37 @@ TEAS Working Group Young Lee (Editor) Dhruv Dhody Internet Draft Huawei Intended status: Informational Sergio Belotti Nokia -Expires: November 2017 +Expires: April 10, 2018 Khuzema Pithewan Infinera Daniele Ceccarelli Ericsson Takuya Miyasaka KDDI Jong Yoon Shin SKT - May 12, 2017 + Kwang-koog Lee + KT + + October 11, 2017 Requirements for Abstraction and Control of TE Networks - draft-ietf-teas-actn-requirements-05.txt + draft-ietf-teas-actn-requirements-06.txt Abstract This document provides a set of requirements for abstraction and control of Traffic Engineering networks to facilitate virtual network operation via the creation of a single virtualized network or a seamless service. This supports operators in viewing and controlling different domains (at any dimension: applied technology, administrative zones, or vendor-specific technology islands) as a single virtualized network. @@ -47,21 +50,21 @@ months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on November 12, 2017. + This Internet-Draft will expire on March 10, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -74,21 +77,21 @@ Table of Contents 1. Introduction...................................................3 2. High-level ACTN requirements...................................4 2.1. Service-Specific Requirements.............................4 2.2. Network-Related Requirements..............................7 3. References.....................................................9 3.1. Normative References......................................9 3.2. Informative References....................................9 4. Contributors..................................................10 - Authors' Addresses...............................................10 + Authors' Addresses...............................................11 1. Introduction This document provides a set of requirements for Abstraction and Control of Traffic Engineering (TE) Networks (ACTN) identified in various use-cases specified by the operators. [ACTN-frame] defines the base reference architecture and terminology. ACTN refers to the set of virtual network service operations needed to orchestrate, control and manage large-scale multi-domain TE @@ -146,69 +149,76 @@ the virtual service coordination function. These requirements are related to customer's VNs in terms of service policy associated with VNs such as service performance objectives, VN endpoint location information for certain required service specific functions (e.g., security and others), VN survivability requirement, or dynamic service control policy, etc. Network-related requirements are related to and necessary for coherent/seamless for the virtual network operation function. These requirements are related to multi-domain and multi-layer signaling, - routing, protection/restoration and synergy, re-optimization/re- - grooming, etc. + routing, protection/restoration and re-optimization/re-grooming, + etc. + + Each requirement specified in Sections 2.1 and 2.2 is derived from + ACTN use-cases: [CHENG], [DHODY], [FANG], [KLEE], [KUMAKI], [LOPEZ], + [SHIN], [XU], [XU2], and [SUZUKI]. 2.1. Service-Specific Requirements 1. Requirement 1: Virtual Network Service (VNS) creation Customer MUST be able to request/instantiate the VNS to the network within the confines of mutual agreement between customer and network - operator and network operator's capability. There are different - types of VNS in terms of the VN types the customer is allowed to - operate (e.g., a VN type can be simply a set of end-to-end tunnels, - or it can comprise of virtual nodes and links in mesh fashion, - etc.). The customer MUST be able to express VNS policy that captures - Service Level Agreements (SLA) associated with virtual network - service (e.g., Endpoint selection policy, routing policy, time- - related policy, etc.) + operator and network operator's capability. A VNS is the service + agreement between a customer and provider to provide a VN [ACTN- + Frame]. There are different types of VNS in terms of the VN types + the customer is allowed to operate (e.g., a VN type can be simply a + set of edge-to-edge links, or it can comprise of virtual nodes and + virtual links, etc.). The customer MUST be able to express VNS + policy that captures Service Level Agreements (SLA) associated with + virtual network service (e.g., Endpoint selection policy, routing + policy, time-related policy, etc.) Reference: [KLEE], [LOPEZ], [SHIN], [DHODY], [FANG]. 2. Requirement 2: Virtual Network Service Query Customer SHOULD be able to request VNS Query ("Can you give me these - VN(s)?") that include the following parameters: + VN(s)?") that includes the following parameters: - VN type: various VN types defined by the customer (e.g., path, graph, etc.) - VN end-points (Customer Edge interface information) - VN Topology Service-specific Objective Functions (e.g., maximum bandwidth, minimum latency, minimum hops, etc. and any combination of them). - VN constraints requirement (e.g., Maximum Latency threshold, Minimum Bandwidth, etc.) Reference: [KUMAKI], [FANG], [CHENG]. 3. Requirement 3: VNS Instantiation ("Please create a VNS for me") Customer MUST be able to instantiate VNS that includes various VNS related parameters: - VN type: various VN types defined by the customer (e.g., - path, graph, etc.) + Type 1, Type 2, etc. See [ACTN-Frame] for the definition of + VN Type 1 and Type 2). - VN end-points (Customer Edge interface information) - VN Topology Service-specific Objective Functions (e.g., maximum bandwidth, minimum latency, minimum hops, etc. and any combination of them). - VN constraints requirement (e.g., Maximum Latency threshold, Minimum Bandwidth, etc.) + - VN Topology diversity when there are multiple instances of VNS (e.g., VN1 and VN2 must be disjoint; Node/link disjoint from other VNs) Reference: [KUMAKI], [FANG], [CHENG]. 4. Requirement 4: VNS Lifecycle Management & Operation (M&O) Customer MUST be able to perform the following VNS operations: @@ -235,24 +245,24 @@ candidate sources/destinations, thresholds for load balancing, disaster recovery policy, etc.) Reference: [FANG], [LOPEZ], [SHIN]. 7. Requirement 7: VNS Performance Monitoring The customer MUST be able to define performance monitoring parameters and its associated policy such as frequency of report, abstraction/aggregation level of performance data (e.g., VN level, - tunnel level, virtual link/node level, etc.) with dynamic feedback - loop from the network. + tunnel level, etc.) with dynamic feedback loop from the network. Reference: [XU], [XU2], [DHODY], [CHENG] + 8. Requirement 8: VNS Confidentiality and Security Requirements The following confidentiality/security requirements MUST be supported in all interfaces: - Securing the request and control of resources, confidentially of the information, and availability of function. - Trust domain verification (external entity versus internal entity) - Encrypting data that flow between components, especially when @@ -252,20 +262,22 @@ supported in all interfaces: - Securing the request and control of resources, confidentially of the information, and availability of function. - Trust domain verification (external entity versus internal entity) - Encrypting data that flow between components, especially when they are implemented at remote nodes, regardless if these are external or internal network interfaces. + Reference: [KUMAKI], [FANG], [LOPEZ] + 2.2. Network-Related Requirements 1. Requirement 1: Virtual Network Service Coordination Network MUST be able to support the following VNS operations: - VNS Delete: Upon customer's VNS deletion request, network MUST be able to delete VNS. - VNS Modify: Upon customer's VNS modification request, network MUST be able to modify VNS related parameters during @@ -371,24 +384,20 @@ [XU2] Y. Xu, et. al., "Requirements of Abstract Alarm Report in ACTN architecture", draft-xu-teas-actn-abstract-alarm-report, work-in-progress. [SUZUKI] T. Suzuki, et. al., "Use-case and Requirements for Multi- domain Operation Plane Change", draft-suzuki-teas-actn- multidomain-opc, work-in-progress. 4. Contributors - Kwangkook Lee - KT - Email: kwangkooglee@gmail.com - Yunbin Xu CATR Email: xuyunbin@mail.ritt.com.cn Toshiaki Suzuki Hitachi Email: toshiaki.suzuki.cs@hitachi.com Haomian Zheng Huawei @@ -423,10 +432,14 @@ Stockholm, Sweden Email: daniele.ceccarelli@ericsson.com Takuya Miyasaka KDDI Email: ta-miyasaka@kddi.com Jong Yoon Shin SKT Email: jongyoon.shin@sk.com + + Kwang-koog Lee + KT + Email: kwangkoog.lee@kt.com