Internet DRAFT - draft-zheng-teas-actn-multivendor-interop
draft-zheng-teas-actn-multivendor-interop
TEAS Working Group Haomian Zheng
Internet Draft Young Lee
Intended status: Informational Huawei
Daniele Ceccarelli
Ericsson
Jong Yoon Shin
SK Telecom
Yunbin Xu
CAICT
Yunbo Li
China Mobile
Yan Shi
China Unicom
Boyuan Yan
BUPT
Expires: April 30 2017 October 31, 2016
Inter-op Test Cases in Multi-vendor Scenario based on ACTN Architecture
draft-zheng-teas-actn-multivendor-interop-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
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 April 30, 2017.
Zheng et al Expires April 2017 [Page 1]
draft-zheng-teas-actn-multivendor-interop-00 October 2016
Copyright Notice
Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
ACTN is a practical approach to repurpose existing and well-defined
technologies, and underpinning them with SDN principle. It provides
a hierarchal architecture to scale and support multi-vendor multi-
domain interworking using RESTconf(YANG Model)/PCEP/BGP-LS.
This document contains a test case proposal focused multi-domain,
multi-vendor interoperation test cases for the ACTN framework. These
test cases cover four test scenarios, including topology
abstraction, E2E service provisioning, DC load balancing and inter-
domain restoration, to demonstrate the fundamental ideas of the ACTN
framework and standards.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction ................................................ 3
Zheng et al Expires April 2017 [Page 2]
draft-zheng-teas-actn-multivendor-interop-00 October 2016
2. Terminology ................................................. 3
3. Related work: Architecture, Modeling and Protocols........... 4
4. Test-cases .................................................. 4
4.1. Topology Abstraction ................................... 4
4.2. E2E Service Provisioning ............................... 6
4.3. DC Load Balancing ...................................... 8
4.4. Inter-domain Recovery .................................. 8
5. Implementation Details....................................... 8
6. Future work ................................................. 9
7. Security Considerations...................................... 9
8. References .................................................. 9
8.1. Informative References.................................. 9
9. Contributors' Addresses..................................... 10
10. Acknowledgment ............................................ 12
1. Introduction
The ACTN interoperation test cases are designed to demonstrate the
on-going work in IETF of the ACTN framework, including:
- ACTN basic solutions for SDN architecture to support multi-domain,
multi-vendor supporting.
- ACTN important interfaces are focused on IETF standards for multi-
protocol supporting.
This document is focused on the demonstration of interoperation test
case procedures to show how ACTN architecture can be implemented.
The ACTN hierarchical controllers include Customer Network
Controller (CNC), the Multi-domain Service Coordinator (MDSC), and
Physical Network Controller (PNC). In this interoperation test, we
focus on the MDSC, PNC, and the MDSC-PNC Interface (MPI) between
them. The ACTN MPI can support both RESTCONF/YANG and PCEP-LS and
gives a deployment choice that meets the need of the operators.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Zheng et al Expires April 2017 [Page 3]
draft-zheng-teas-actn-multivendor-interop-00 October 2016
3. Related work: Architecture, Modeling and Protocols
ACTN provides description about future requirements in SDN
literature in [ACTN-Requirements]. ACTN framework has been proposed
in [ACTN-Frame] to support all the requirements. The information
model has been defined in [ACTN-Info].
From the solution perspective, ACTN work has been associated with
some other IETF works in various working group including netmod,
i2rs, rtgwg, ccamp, pce and so on. Yang models, defined in Netconf
[RFC6241]/Restconf [Restconf], have been considered as an approach
for network configuration. [ACTN-YANG] has described the
applicability of YANG models in the ACTN framework, where various
yang models including TE topology model from [TE-Topology], tunnel
model from [TE-Tunnel] and service model from [Transport-Service-
Model] and [ACTN-VN-YANG] have been applied on the ACTN interfaces
to complete different functions. PCE protocol in the pce working
group has also been considered to be extended and applied for the
ACTN interfaces. The applicability draft can be found in [ACTN-PCE].
PCEP extensions with Link State features can be found in [PCEP-LS]
for topology discovery, and PCE Initation mechanism defined in [PCE-
Init] can be used to set up the connections.
4. Test-cases
This section provides a number of test cases. Currently the test is
basically conducted between the MDSC and PNC, i.e., on the MPI
interface in the ACTN architecture. The scenario we are going to
test includes the topology abstraction, E2E service provisioning, DC
load balancing and Inter-domain recovery.
Some fundamental environment has been set up and applied to all the
test cases. On the network element level, emulators from various
vendors have been connected with their corresponding PNC. The
interface between PNC and network elements is known as the
southbound interface (SBI) in SDN literature. The protocol on SBI
can be vendor-specific.
The MDSC can be either from network operators or vendors, to
coordinate among multiple PNCs. The interaction between the MDSC and
the PNCs, which is known as MPI in ACTN and considered as a part of
northbound interface in SDN literature, should be standard.
4.1. Topology Abstraction
This scenario is used to verify the multi-domain topology collection
on the MDSC level. Multi-technology network (IP, MPLS, Transport)
Zheng et al Expires April 2017 [Page 4]
draft-zheng-teas-actn-multivendor-interop-00 October 2016
should report their topology and the MDSC should be capable of
integrating different topologies together.
MDSC, PNC and network elements are involved in this scenario. The
PNC needs to collect the information from the network elements and
maintain its own TE Database. Given the physical topology, the PNC
may simplify the topology and report an 'abstract' version to the
MDSC. The interaction on MPI to exchange the topology information
may be via RESTconf with topology YANG model. The example of
topology abstraction is shown in Fig. 1, PNC collect the information
of 6 network elements in every single domain, and abstract the
topology into a 4-point format. Then the abstracted topology can be
reported to MDSC. In this example, MDSC will receive the information
from two PNC domains, and manipulate on an 8-point abstracted
topology.
+---+ +---+ +---+ +---+
|NE1+---+NE2+----+NE3+---+NE4+
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
+-+-+ +-+-+ +-+-+ +-+-+
|NE5+---+NE6+----+NE7+---+NE8+
+---+ +---+ +---+ +---+
+-------+
| MDSC |
+--/\---+
Abstract Domain1 // \\ Abstract Domain2
+---+ +---+ // \\ +---+ +---+
|NE1+---+NE2+ // \\ |NE1+---+NE2+
+-+-+ +-+-+ +--+--* \+-------+ +-+-+ +-+-+
| | | PNC | | PNC | | |
+-+-+ +-+-+ +--+--+ +---+---+ +-+-+ +-+-+
|NE3+---+NE4+ | | |NE3+---+NE4+
+---+ +---+ | | +---+ +---+
Zheng et al Expires April 2017 [Page 5]
draft-zheng-teas-actn-multivendor-interop-00 October 2016
+--------------+---------+ +--------+--------------+
| +---+ +---+ +---+ | | +---+ +---+ +---+ |
| |NE1+---+NE2+---+NE3| | | |NE1+---+NE2+---+NE3| |
| +-+-+ +-+-+ +-+-+ | | +-+-+ +-+-+ +-+-+ |
| | | | | | | | | |
| +-+-+ +-+-+ +-+-+ | | +-+-+ +-+-+ +-+-+ |
| |NE4+---+NE5+---+NE6| | | |NE4+---+NE5+---+NE6| |
| +---+ +---+ +---+ | | +---+ +---+ +---+ |
| Domain 1 | | Domain 2 |
+------------------------+ +-----------------------+
Fig. 1 Topology Abstraction Scenario
Dynamical changes in topology should also be considered. For example
when there is a new node discovered in the network, the incremental
topology should be correctly detected on PNC, and the abstraction
may need to be adjusted accordingly and reported to MDSC for update.
4.2. E2E Service Provisioning
This test case is used to verify the Restconf/YANG functionality on
service provisioning via interaction between MDSC and PNC. Inter-
domain connection, shown in Fig. 2, is expected to be established.
In Fig. 2 the topology on the MDSC is shown, and the network element
information is hidden.
+---+ +---+ +---+ +---+ +---+ +---+
| A1+---+ A2+----+ B1+---+ B2+----+ C1+---+ C2+
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| | | | | |
+-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| A3+---+ A4+----+ B3+---+ B4+----+ C3+---+ C4+
+---+ +---+ +---+ +---+ +---+ +---+
+------+
Zheng et al Expires April 2017 [Page 6]
draft-zheng-teas-actn-multivendor-interop-00 October 2016
| MDSC |
-+--+---+--
---- | ----
---- | ----
+------+ +--+---+ +------+
| PNC A| |PNC B | | PNC C|
+------+ +------+ +------+
Fig. 2: E2E Service Provisioning Scenario
We assume there is request of 100GE service from A1 to C2, following
steps need to be completed to set up the connection.
Step 1: MDSC compute an inter-domain path and translate the multi-
domain request into multiple single domain requests of domain A, B
and C.
Step 2: MDSC sends decomposed requests to each PNC, and each PNC
compute intra-domain path:
a) Send request to PNC of domain A to set up a service from A1 to
A2.
b) Send request to PNC of domain B to set up a service from B1 to
B2.
c) Send request to PNC of domain C to set up a service from C1 to
C2.
d) These requests may be sent in parallel.
Step 3: Each PNC responds successfully creation, or failure with
error message.
Step 4: MDSC receives responds from all the PNCs, and successfully
set up a multi-domain service.
The communication between MDSC and PNC could be completed by
Restconf protocol associated with tunnel YANG model or service YANG
model. The communication between PNC and network elements can be
vendor-specific in this scenario.
Zheng et al Expires April 2017 [Page 7]
draft-zheng-teas-actn-multivendor-interop-00 October 2016
4.3. DC Load Balancing
DC Load balancing is more advanced scenario based on active LSP set
up in the network. In this scenario, the result of previous 2
scenarios needs to be reused. We assumed there are two disjoint
LSPs, one from A1 to C2, and another from A1 to C4. Explicit route
can be found as following:
LSP1: A1-A2-B1-B2-C1-C2;
LSP2: A1-A3-A4-B3-B4-C3-C4;
The bandwidth of LSP1 and LSP2 are set to 300G and 100G respectively
before load balancing, with a target on adjusting both of them to
200G for load balancing. MDSC need to send update message to PNCs to
adjust their bandwidth on corresponding links.
The interaction on MPI in this case can be completed by Restconf
protocol with topology and service YANG model. The interactions
between PNC and network elements are vendor-specific.
4.4. Inter-domain Recovery
Another test case about inter-domain recovery is also designed to
verify the function of cross-domain restoration. In this case a
cross-domain LSP is set up, such as reusing the LSP1 in section 4.3.
Then a failure in one domain is emulated in one domain, and the PNC
of this domain cannot find sufficient resources within the domain so
that it MUST turn to the MDSC for inter-domain restoration. MDSC
then need to update the topology and resource usage in every domain
to compute a path for re-routing. After MDSC got an answer, it will
deliver another E2E service, which is a repeating of section 4.2.
The interaction on MPI in this case can be completed by Restconf
protocol with topology and service YANG model. The interactions
between PNC and network elements are vendor-specific.
5. Implementation Details
The implementation and inter-op test is on-going. Once the result is
available, this section will be updated.
Zheng et al Expires April 2017 [Page 8]
draft-zheng-teas-actn-multivendor-interop-00 October 2016
The progress of future test work will be updated and available at
the ACTN wiki page: https://sites.google.com/site/openactn/.
6. Future work
Inter-op test can be done either with emulation environment or
physical devices in the lab. Some of the test related work in this
draft will be done on emulations via remote labs of various vendors,
or during IETF Hackathon activity. This will be a continuing
activity with follow-up work in coming IETF meetings. More
participants will be welcomed to join this effort to further promote
IETF work to expedite SDN deployment.
7. Security Considerations
This document is an informational draft. When the models
mentioned in this draft are implemented, detailed security
consideration will be given in such work.
8. References
8.1. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration
Protocol(NETCONF)", RFC 6241.
[Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf, work in progress.
[ACTN-Requirements] Y. Lee, et al., "ACTN Requirements for
Abstraction and Control of TE Networks", draft-ietf-teas-
actn-requirements, work in progress.
[ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and
Control of Traffic Engineered Networks", draft-ietf-teas-
actn-framework, work in progress.
Zheng et al Expires April 2017 [Page 9]
draft-zheng-teas-actn-multivendor-interop-00 October 2016
[TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies",
draft-ietf-teas-yang-te-topo, work in progress.
[TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, work in progress.
[ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN
Operation", draft-lee-teas-actn-vn-yang, work in progress.
[ACTN-Info] Y. Lee & S. Belotti, "Information Model for Abstraction
and Control of TE Networks (ACTN)", draft-leebelotti-teas-
actn-info, work in progress.
[Transport-Service-Model] X. Zhang (Editor), "A Service YANG Model
for Connection-oriented Transport Networks", draft-zhang-
teas-transport-service-model, work in progress.
[ACTN-YANG] Y. Lee, X. Zhang, D. Ceccarelli, B. Yoon, O.Gonzalez de
Dios, J. Shin, Applicability of YANG models for
Abstraction and Control of Traffic Engineered Networks,
work in progress.
[ACTN-PCE] D.Dhody, Y. Lee, D. Ceccarelli, Applicability of Path
Computation Element (PCE) for Abstraction and Control of
TE Networks (ACTN), work in progress.
[PCE-LS] D.Dhody, Y. Lee, D. Ceccarelli, PCEP Extension for
Distribution of Link-State and TE Information, work in
progress.
[PCE-Init] E. Crabbe, I. Minei, S. Sivabalan, R. Varga, PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model, work in progress.
9. Contributors' Addresses
Kun Xiang
Huawei Technologies
Email: xiangkun@huawei.com
Zheng et al Expires April 2017 [Page 10]
draft-zheng-teas-actn-multivendor-interop-00 October 2016
Xian Zhang
Huawei Technologies
Email zhang.xian@huawei.com
Xin Liu
Huawei Technologies
Email liuxin12@huawei.com
Lei Wang
China Communications Corporation
Email wangleiyj@chinamobile.com
Weiqiang Cheng
China Communications Corporation
Email chengweiqiang@chinamobile.com
Liang Geng
China Communications Corporation
Email gengliang@chinamobile.com
Dong Wang
China Communications Corporation
Email wangdongyjy@chinamobile.com
Dhruv Dhody
Huawei Technologies
Email: dhruv.ietf@gmail.com
Satish Karunanithi
Huawei Technologies
Email: satishk@huawei.com
Wei Wang
Beijing University of Post and Telecommunications
Email: weiw@bupt.edu.cn
Zheng et al Expires April 2017 [Page 11]
draft-zheng-teas-actn-multivendor-interop-00 October 2016
Yongli Zhao
Beijing University of Post and Telecommunications
Email: yonglizhao@bupt.edu.cn
Jie Zhang
Beijing University of Post and Telecommunications
Email: lgr24@bupt.edu.cn
10. Acknowledgment
TBD
Authors' Address
Haomian Zheng
Huawei Technologies
Email: Zhenghaomian@huawei.com
Young Lee
Huawei Technologies
5340 Legacy Dr.
Plano, TX 75023, USA
Phone: (469)277-5838
Email: leeyoung@huawei.com
Daniele Ceccarelli
Ericsson
Torshamnsgatan,48
Stockholm, Sweden
Email: daniele.ceccarelli@ericsson.com
Jong Yoon Shin
SK Telecom
Zheng et al Expires April 2017 [Page 12]
draft-zheng-teas-actn-multivendor-interop-00 October 2016
Email: jongyoon.shin@sk.com
Yunbin Xu
China Academy of Information and Communication Technology
Email: xuyunbin@mail.ritt.com.cn
Yunbo Li
China Communications Corporation
Email liyunbo@chinamobile.com
Yan Shi
China Unicom
Email shiyan49@chinaunicom.cn
Boyuan Yan
Beijing University of Post and Telecommunications
Email: yanboyuan@bupt.edu.cn
Zheng et al Expires April 2017 [Page 13]
