Transport SDN and Use Cases in Korea

Transcription

1

2 Transport SDN and Use Cases in Korea Justin Park, Researcher/Programmer, ETRI September 28, 2016 #ODSummit

3 Agenda Introduction & Background Who we are Transport networks Problem Definition Why OpenDaylight Architecture OpenDaylight Use Cases Takeaways Future Plans Q&A #ODSummit

4 Who we are Taehong Assistant Professor Dr. Park 20+ Years in Computer Networking Dr. Shin Justin 6+ Years in Networking Human 15+ Years in Optical Transport Networking Arm J Computer geek <Introducing SDN Research Team>

5 Transport Network Transport networks are logical circuit networks with QoS-guarantees frequently used by carriers. SONET/SDH provide fault detection (OAM), fast (sub-50ms) protection, end-to-end QoS. Multiprotocol Label Switching - Transport Profile (MPLS-TP) addresses these OAM, protection, and QoS with packet technology. Optical Transport Network (OTN) is successor to SONET/SDH with wavelength switching capability. <A carrier network image from LOGTEL>

6 What is the problem? 1. Lack of Compatibility Not only each protocol, but also each vendor with the same protocol has a different EMS. 2. Lack of agility and scalability - due to lack of unified support for multi-vendor and multilayer network service provisioning a change requires days or even weeks. EMS A EMS B EMS C EMS D MPLS-TP MPLS-TP OTN OTN (A vendor) (B vendor) (C vendor) (D vendor) <EMS for each system>

7 Requirements 1. Operational Simplicity enables network service control/provision with simpler and more open APIs. 2. Differentiated Service Delivery means automatically allocating resources in accordance to the context of an application or a service. 3. Scalability means supporting multi-domain and multi-layer network service control/provision transactions in a scale of hours and minutes, not weeks and days. 4. Interoperability or legacy and multi-domain Interworking is about supporting network diversity.

8 Why OpenDaylight? 1. YANG provides excellent separation between modeling and implementation. 2. MD-SAL provides necessary tools to help enforcing and gluing YANG models to implementations. 3. Routed RPC significantly eases bringing new plugins by decoupling RPCs from plugins. "node-ref":"/tsdn-inventory:nodes/tsdn-inventory:node[tsdn-inventory:node-id='node[kr.re.etri:topology[kr.re.etri:mplstp:oces-daejeon-1]:72899]']" Consumer Producer put Data Broker Consumer Producer Producer call RPC Broker Consumer publish Notification Broker notify Producer Consumer store Consumer Producer Consumer notify Producer <MD-SAL three brokers>

9 Implementation Details (4/1) Operator /GUI Topology Manager Inventory Manager T-SDN controller Service Manager Restconf Inventory Data Store Service Data Store RPC Call RPC Call RPC Impl Vendor A REST API Vendor dependent development Model Driven Service Abstraction Layer Abstract data Node Mgr Session Mgr data Vendor B EMS Vendor C Vendor A node 1 Vendor A node 2 Vendor B EMS Vendor C node 1 Vendor C node 2 <Architecture of Calamari T-SDN Controller by ETRI> #ODSummit

10 Implementation Details (4/2) Modeling 1. common idea tsdn-prefix, node, node-connector, access-if, inventory, port-type 2. difference OTN specific otn-prefix, tributary slots, ODU0-ODU4 MPLS-TP specifics mplstp-prefix, mplstpif, psedowire 3. Data Model 4. RPCs set-accessif, set-mplsif, set-tunnel, set-tunnelxc 5. Notification tunnelupdated, pwupdated, mplsifremoved, and etc. #ODSummit

11 Implementation Details (4/3) RPC call CRUD operation NBI Topology Manager Inventory Manager T-SDN controller Service Manager Restconf Netconf Network-topology Region:1 Node list node: 1 Region: 2 node: 2 Vendor A RPC, notification RPC, notification RPC, notification Topology list Region:1?? l1 l2 Source node Link list l3 tp VendorB: node:1 Nodes Node list node:2 Vendor B EMS VendorA: node:1 IP??? Protection node list Services node:3 Nodeconnector??? list Dest. tp1 tp2 tp3?1?2?3 Mplstp:1 Vendor C service list Working service node list attribut node:3 e node:1 node:2 Ing TP service:2 Eg TP RPC, notification RPC, notification RPC, notification Vendor A node 1 Vendor A node 2 SBI Vendor B EMS Vendor C node 1 Vendor C node 2 <Architecture of MPLS-TP Controller> 11

12 Implementation Details(4/4) <Service Input for ServiceManager> #ODSummit <Result with APIDocs>

13 Testbed Information ETRI OCES POTNs T-SDN Controller TSDNenabled EMS PTN #1 (Coweave) PTN #1 (OCES) PTN #2 (OCES) PTN #1 (TeleField) TSDNenabled EMS PTN #2 (Coweave) PTN #3 (Coweav) Telefield PTNs Coweaver PTNs WooriNet PTNs PTN #2 (Woori) PTN #3 (Woori) PTN #1 (Woori) TSDNenabled EMS <Original Test Plan in 2015> PTN #2 (Telefield) Working Path Protection Path PTN #3 (Telefield) Transport Devices (ETRI Build #7 3 rd floor) #ODSummit

14 Accomplishments SB T-SDN Controller Calamari WooriNet PTN WooriNet EMS xe-12/3 O-101 xe-12/1 1-2 W W K Stream Receiver xe-12/4 xe-12/2 OCES PTN 1-1 W K Stream transmitter 10GbE NNI Link 10GbE UNI Link (eth4: ) ($ iperf ) (eth4: ) ($ iperf ) <Calamari TSDN Controller Testbed in 2015: multi-vendor devices> 14

15 OpenDaylight Use Cases in Korea #ODSummit

16 SKT T-SDN Platform Architecture SK Telecom's T-SDN platform, Transport N/W Unified Management Platform assigns programmability and unified controllability of transport infra N/W from L0 to L3 PCE: Path Computation Element, EMS: Element Management System

17 KT (Korea Telecom) Architecture SDN Controller based on OpenDaylight Helium release Resource Abstraction using shared DB of legacy transport NMS Multiple southbound plugins for MSPP, OXC, and PTN devices Northbound interfaces based on Restful technology T-SDN Platform Fault Manager(Legacy NMS) GUI 3 rd Party App Web Browser Client Client Controller Socket Service Functions Topology Mgr. Service Mgr. Northbound API(RESTfull) Path Designer Provisioning PCE Client Mgr. Statistics MD-SAL Clustering Mgr. Inventory Mgr. Karaf runtime OSGi Framework Data Broker Data Store (In-Memory) Resource DB (SQL) Fault Mgr. RCA Event Mgr. AP Server SB Protocol s OpenFlow NetConf Corba SNMP TL-1 GW Server

18 Takeaways Able to think about the big picture of how a T-SDN controller works It could take weeks or month and still get it wrong. Able to think how to design YANG models for T-SDN T-SDN YANG Model Check for compatibility MPLS-TP OAM frames OTN 100G incompatibility

19 Future Plans Update our YANG model reflecting what we have learned so far Provide a template southbound plugin architecture for many nodes Incorporate more vendors Expand to more Protocols (OTN, ROADM, and etc.) Technical Cooperation This work was supported by ICT R&D program of MSIP/IITP. [B , Smart Networking Core Technology Development]

20 Thank You #ODSummit