< 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/