Transport SDN & OpenDaylight Use Cases in Korea
•
3 likes•1,204 views
- The document summarizes a presentation on Transport SDN and use cases in Korea. It introduces the speaker and their research team working on Transport SDN. It describes problems with current transport networks and requirements for SDN solutions. It provides an overview of the OpenDaylight platform and how it is being used to develop a Transport SDN controller in Korea called Calamari. It briefly describes implementations with MPLS-TP and testbeds involving multiple vendors. It outlines use cases at two Korean telecom companies, SKT and KT, and concludes with future plans to expand the SDN research.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Transport SDN & OpenDaylight Use Cases in Korea
Similar to Transport SDN & OpenDaylight Use Cases in Korea (20)
Recently uploaded
Recently uploaded (20)
Transport SDN & OpenDaylight Use Cases in Korea
- 2. Transport SDN and Use Cases in Korea #ODSummit Justin Park, Researcher/Programmer, ETRI September 28, 2016
- 3. Agenda #ODSummit • Introduction & Background • Who we are • Transport networks • Problem Definition • Why OpenDaylight • Architecture • OpenDaylight Use Cases • Takeaways • Future Plans • Q&A
- 4. Who we are Dr. Park 20+ Years in Computer Networking Human 15+ Years in Optical Transport Networking Justin 6+ Years in Networking Arm J Computer geek Taehong Assistant Professor Dr. Shin <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 multi- layer network service provisioning a change requires days or even weeks. <EMS for each system> EMS A EMS B EMS C EMS D MPLS-TP MPLS-TP OTN OTN (A vendor) (B vendor) (C vendor) (D vendor)
- 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. <MD-SAL three brokers> Notification Broker Consumer Producer Consumer Producer publish notify Consumer Producer Consumer ProducerData Broker Producer Consumer notify put store RPC Broker Producer Consumer call "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]']"
- 9. Implementation Details (4/1) #ODSummit <Architecture of Calamari T-SDN Controller by ETRI> T-SDN controller Model Driven Service Abstraction Layer RestconfInventory Manager Plugin Service Manager Plugin Topology Manager Plugin Operator /GUI Vendor A node 1 Vendor B EMS Plugin Vendor A node 2 Vendor B EMS Vendor C node 2 Vendor C Plugin Vendor C node 1 RPC Impl Session Mgr Node Mgr REST API data Abstract data Vendor dependent development RPC Call Service Data Store RPC Call Inventory Data Store Vendor A Plugin
- 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. 11<Architecture of MPLS-TP Controller> Implementation Details (4/3) T-SDN controller Vendor A Plugin Vendor A node 1 Restconf Netconf Inventory Manager Plugin Vendor B EMS Plugin Vendor A node 2 Vendor B EMS Vendor C node 2 Vendor C Plugin Vendor C node 1 Service Manager Plugin Topology Manager Plugin NBI SBI Nodes VendorB: node:1 Node- connector list ??? tp1 tp2 tp3 ?1 ?2 ?3 VendorA: node:1 IP ??? node:3 node:2 Node list Region:1 Network-topology Region:1 Region: 2 Node list Link list node: 1 node: 2 ?? l1 l2 l3 Topology list Source Dest. node tp Services Protection node list Mpls- tp:1 Working node list node:2 service list node:1 node:3 service:2 service attribut e Ing TP Eg TP RPC call CRUD operation RPC, notification RPC, notification RPC, notification RPC, notification RPC, notification RPC, notification
- 12. Implementation Details(4/4) #ODSummit <Service Input for ServiceManager> <Result with APIDocs>
- 13. Testbed Information #ODSummit PTN #2 (Woori) PTN #3 (Woori) PTN #1 (Woori) PTN #2 (Coweave) PTN #3 (Coweav) PTN #1 (Coweave) PTN #2 (Telefield) PTN #3 (Telefield) PTN #1 (TeleField)PTN #1 (OCES) PTN #2 (OCES) TSDN- enabled EMS TSDN- enabled EMS TSDN- enabled EMS Working Path Protection Path ETRI OCES POTNs T-SDN Controller Telefield PTNs Coweaver PTNs WooriNet PTNs Transport Devices (ETRI Build #7 3rd floor) <Original Test Plan in 2015>
- 14. 14 10GbE NNI Link xe-12/1 xe-12/2 xe-12/3 WooriNet EMS OCES PTN WooriNet PTN T-SDN Controller Calamari 4K Stream transmitter4K Stream Receiver SB Plugin W3 W1 1-2 1-2 1-2 2-1 10GbE UNI Link O-101 (eth4:100.104.1.1) ($ iperf …) (eth4:100.104.1.2) ($ iperf …) xe-12/4 1-1 W2 1-1 1-1 2-1 <Calamari TSDN Controller Testbed in 2015: multi-vendor devices> Accomplishments
- 15. #ODSummit OpenDaylight Use Cases in Korea
- 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 MD-SAL OSGiFramework Karafruntime DataStore (In-Memory) DataBrokerClusteringMgr. PCEProvisioningPathDesignerTopologyMgr. InventoryMgr. Service Functions ServiceMgr. OpenFlow NetConf Corba SBProtocol Plugins NorthboundAPI(RESTfull) Resource DB (SQL) EventMgr. FaultMgr. GUI RCA Statistics WebBrowser Client Socket TL-1SNMP ClientMgr. FaultManager(LegacyNMS)T-SDNPlatform GW Server AP Server Client Controller 3rd PartyApp • 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
- 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. [B0101-16-0233, Smart Networking Core Technology Development]