draft-ietf-teas-actn-requirements-07.txt   draft-ietf-teas-actn-requirements-08.txt 
TEAS Working Group Young Lee (Editor) TEAS Working Group Young Lee (Editor)
Dhruv Dhody
Internet Draft Huawei Internet Draft Huawei
Intended status: Informational
Intended status: Informational Sergio Belotti
Nokia
Expires: April 27, 2018
Khuzema Pithewan
Infinera
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Expires July 25, 2018. Ericsson
Takuya Miyasaka Takuya Miyasaka
KDDI KDDI
Jong Yoon Shin Jong Yoon Shin
SKT SKT
Kwang-koog Lee Kwang-koog Lee
KT KT
October 27, 2017 January 25, 2018
Requirements for Abstraction and Control of TE Networks Requirements for Abstraction and Control of TE Networks
draft-ietf-teas-actn-requirements-07.txt draft-ietf-teas-actn-requirements-08.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 21 skipping to change at page 2, line 16
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 April 27, 2018. This Internet-Draft will expire on July 25, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................2
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...............................................11 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
networks so as to facilitate network programmability, automation, networks so as to facilitate network programmability, automation,
efficient resource sharing, and end-to-end virtual service aware efficient resource sharing, and end-to-end virtual service aware
connectivity. connectivity.
These operations are summarized as follows: These operations are summarized as follows:
skipping to change at page 4, line 12 skipping to change at page 4, line 10
- Provision via a data model of a computation scheme and virtual - Provision via a data model of a computation scheme and virtual
control capability to customers who request virtual network control capability to customers who request virtual network
services. Note that these customers could, themselves, be services. Note that these customers could, themselves, be
service providers. service providers.
ACTN solutions will build on, and extend, existing TE constructs and ACTN solutions will build on, and extend, existing TE constructs and
TE mechanisms wherever possible and appropriate. Support for TE mechanisms wherever possible and appropriate. Support for
controller-based approaches is specifically included in the possible controller-based approaches is specifically included in the possible
solution set. solution set.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. High-level ACTN requirements 2. High-level ACTN requirements
This section provides a summary of use-cases in terms of two This section provides a summary of use-cases in terms of two
categories: (i) service-specific requirements; (ii) network-related categories: (i) service-specific requirements; (ii) network-related
requirements. All these requirements are specified by operators that requirements. All these requirements are specified by operators that
are interested in implementing ACTN. are interested in implementing ACTN.
Service-specific requirements listed below are uniquely applied to Service-specific requirements listed below are uniquely applied to
the work scope of ACTN. Service-specific requirements are related to the work scope of ACTN. Service-specific requirements are related to
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 Virtual Networks (VN) in terms of service
VNs such as service performance objectives, VN endpoint location policy associated with VNs such as service performance objectives,
information for certain required service specific functions (e.g., VN endpoint location information for certain required service
security and others), VN survivability requirement, or dynamic specific functions (e.g., security and others), VN survivability
service control policy, etc. requirement, or dynamic 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 re-optimization/re-grooming, routing, protection/restoration and re-optimization/re-grooming,
etc. etc.
Each requirement specified in Sections 2.1 and 2.2 is derived from Each requirement specified in Sections 2.1 and 2.2 is derived from
ACTN use-cases: [CHENG], [DHODY], [FANG], [KLEE], [KUMAKI], [LOPEZ], ACTN use-cases: [CHENG], [DHODY], [FANG], [KLEE], [KUMAKI], [LOPEZ],
[SHIN], [XU], [XU2], and [SUZUKI]. [SHIN], [XU], [XU2], and [SUZUKI].
skipping to change at page 5, line 18 skipping to change at page 5, line 22
virtual links, etc.). The customer MUST be able to express VNS virtual links, etc.). The customer MUST be able to express VNS
policy that captures Service Level Agreements (SLA) associated with policy that captures Service Level Agreements (SLA) associated with
virtual network service (e.g., Endpoint selection policy, routing virtual network service (e.g., Endpoint selection policy, routing
policy, time-related policy, etc.) 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 includes the following parameters: VN(s)?") that include 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.)
skipping to change at page 6, line 27 skipping to change at page 6, line 29
parameters during the lifecycle of the instantiated VNS. parameters during the lifecycle of the instantiated VNS.
Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE]. Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE].
5. Requirement 5: VNS Isolation 5. Requirement 5: VNS Isolation
Customer's VN should be able to use arbitrary network topology, Customer's VN should be able to use arbitrary network topology,
routing, or forwarding functions as well as customized control routing, or forwarding functions as well as customized control
mechanisms independent of the underlying physical network and of mechanisms independent of the underlying physical network and of
other coexisting virtual networks. Other customers' VNS operation other coexisting virtual networks. Other customers' VNS operation
MUST not impact a particular customer's VNS network operation. MUST NOT impact a particular customer's VNS network operation.
Reference: [KUMAKI], [FANG], [LOPEZ] Reference: [KUMAKI], [FANG], [LOPEZ]
6. Requirement 6: Multi-Destination Coordination 6. Requirement 6: Multi-Destination Coordination
Customer MUST be able to define and convey service/preference Customer MUST be able to define and convey service/preference
requirements for multi-destination applications (e.g., set of requirements for multi-destination applications (e.g., set of
candidate sources/destinations, thresholds for load balancing, candidate sources/destinations, thresholds for load balancing,
disaster recovery policy, etc.) disaster recovery policy, etc.)
skipping to change at page 7, line 34 skipping to change at page 7, line 34
Reference: [KUMAKI], [FANG], [LOPEZ] 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
the lifecycle of the instantiated VNS. the lifecycle of the instantiated VNS.
- VNS Update: Upon customer's VNS performance monitoring - VNS Monitor: Upon customer's VNS performance monitoring
setup, the network MUST be able to support VNS level setup, the network MUST be able to support VNS level
Operations, Administration and Management (OAM) Monitoring Operations, Administration and Management (OAM) Monitoring
under policy agreement. under policy agreement.
Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE]. Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE].
2. Requirement 2: Topology Abstraction Capability 2. Requirement 2: Topology Abstraction Capability
The network MUST be capable of managing its networks based on the The network MUST be capable of managing its networks based on the
principle of topology abstraction to be able to scale multi-layer, principle of topology abstraction to be able to scale multi-layer,
multi-domain networks. multi-domain networks.
Reference: [KLEE], [LOPEZ], [DHODY], [CHENG]. Reference: [KLEE], [LOPEZ], [DHODY], [CHENG].
skipping to change at page 9, line 11 skipping to change at page 9, line 11
- Fast convergence of abstracted topologies upon changes due - Fast convergence of abstracted topologies upon changes due
to failure or reconfiguration across the network domain to failure or reconfiguration across the network domain
view, the multi-domain network view and the customer view. view, the multi-domain network view and the customer view.
- Large-scale VNS operation (e.g., the ability to query tens - Large-scale VNS operation (e.g., the ability to query tens
of thousands of nodes, and to examine tens of thousands of of thousands of nodes, and to examine tens of thousands of
connectivity requests) for time-sensitive applications. connectivity requests) for time-sensitive applications.
Reference: [SHIN], [XU], [XU2], [KLEE], [KUMAKI], [SUZUKI]. Reference: [SHIN], [XU], [XU2], [KLEE], [KUMAKI], [SUZUKI].
3. References 3. Security Considerations
3.1. Normative References The ACTN requirements described in this document do not directly
bear specific security concerns. When these requirements are
implemented in specific interfaces, securing the request and control
of resources, confidentially of the information, and availability of
function, should all be critical security considerations.
4. IANA Considerations
This document has no actions for IANA.
5. References
5.1. Normative References
[ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and
Control of Transport Networks", draft-ietf-teas-actn- Control of Transport Networks", draft-ietf-teas-actn-
framework, work in progress. framework, work in progress.
3.2. Informative References 5.2. Informative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", RFC 8174, May 2017.
[CHENG] W. Cheng, et. al., "ACTN Use-cases for Packet Transport [CHENG] W. Cheng, et. al., "ACTN Use-cases for Packet Transport
Networks in Mobile Backhaul Networks", draft-cheng-actn- Networks in Mobile Backhaul Networks", draft-cheng-actn-
ptn-requirements, work in progress. ptn-requirements-00, July 21, 2014.
[DHODY] D. Dhody, et. al., "Packet Optical Integration (POI) Use [DHODY] D. Dhody, et. al., "Packet Optical Integration (POI) Use
Cases for Abstraction and Control of Transport Networks Cases for Abstraction and Control of Transport Networks
(ACTN)", draft-dhody-actn-poi-use-case, work in progress. (ACTN)", draft-dhody-actn-poi-use-case-07, October 28,
2016.
[FANG] L. Fang, "ACTN Use Case for Multi-domain Data Center [FANG] L. Fang, "ACTN Use Case for Multi-domain Data Center
Interconnect", draft-fang-actn-multidomain-dci, work in Interconnect", draft-fang-actn-multidomain-dci-01,
progress. September 29, 2014.
[KLEE] K. Lee, H. Lee, R. Vilata, V. Lopez, "ACTN Use-case for E2E [KLEE] K. Lee, H. Lee, R. Vilata, V. Lopez, "ACTN Use-case for E2E
Network Services in Multiple Vendor Domain Transport Network Services in Multiple Vendor Domain Transport
Networks", draft-klee-teas-actn-connectivity-multi-domain, Networks", draft-klee-teas-actn-connectivity-multi-domain-
work-in-progress. 03, July 31, 2017.
[KUMAKI] K. Kumaki, T. Miyasaka, "ACTN : Use case for Multi Tenant [KUMAKI] K. Kumaki, T. Miyasaka, "ACTN : Use case for Multi Tenant
VNO", draft-kumaki-teas-actn-multitenant-vno, work in VNO", draft-kumaki-teas-actn-multitenant-vno-00, May 29,
progress. 2014.
[LOPEZ] D. Lopez (Ed), "ACTN Use-case for Virtual Network Operation [LOPEZ] D. Lopez (Ed), "ACTN Use-case for Virtual Network Operation
for Multiple Domains in a Single Operator Network", draft- for Multiple Domains in a Single Operator Network", draft-
lopez-actn-vno-multidomains, work in progress. lopez-actn-vno-multidomains-01, October 27, 2014.
[SHIN] J. Shin, R. Hwang, J. Lee, "ACTN Use-case for Mobile Virtual [SHIN] J. Shin, R. Hwang, J. Lee, "ACTN Use-case for Mobile Virtual
Network Operation for Multiple Domains in a Single Network Operation for Multiple Domains in a Single
Operator Network", draft-shin-actn-mvno-multi-domain, work Operator Network", draft-shin-actn-mvno-multi-domain-00,
in progress. June 30, 2014.
[XU] Y. Xu, et. al., "Use Cases and Requirements of Dynamic Service [XU] Y. Xu, et. al., "Use Cases and Requirements of Dynamic Service
Control based on Performance Monitoring in ACTN Control based on Performance Monitoring in ACTN
Architecture", draft-xu-actn-perf-dynamic-service-control, Architecture", draft-xu-actn-perf-dynamic-service-control-
work in progress. 03, April 23, 2015.
[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. 00, July 6, 2015.
[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-00, July 6, 2015.
4. Contributors
6. Contributors
Yunbin Xu Yunbin Xu
CATR CATR
Email: xuyunbin@ritt.cn Email: xuyunbin@ritt.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 page 11, line 14 skipping to change at page 11, line 25
Authors' Addresses Authors' Addresses
Young Lee (Editor) Young Lee (Editor)
Huawei Technologies Huawei Technologies
5340 Legacy Drive 5340 Legacy Drive
Plano, TX 75023, USA Plano, TX 75023, USA
Phone: (469)277-5838 Phone: (469)277-5838
Email: leeyoung@huawei.com Email: leeyoung@huawei.com
Dhruv Dhody
Huawei Technologies
Email: dhruv.ietf@gmail.com
Sergio Belotti
Nokia
Via Trento, 30
Vimercate, Italy
Email: sergio.belotti@nokia.com
Khuzema Pithewan
Infinera
Email: kpithewan@infinera.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Torshamnsgatan,48 Torshamnsgatan,48
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 Kwang-koog Lee
KT KT
Email: kwangkoog.lee@kt.com Email: kwangkoog.lee@kt.com
Dhruv Dhody
Huawei Technologies
Email: dhruv.ietf@gmail.com
Sergio Belotti
Nokia
Via Trento, 30
Vimercate, Italy
Email: sergio.belotti@nokia.com
Khuzema Pithewan
Peloton Technology
Email: khuzemap@gmail.com
 End of changes. 31 change blocks. 
64 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/