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]