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