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]