Transport SDN and Use Cases in Korea
#ODSummit
Justin Park, Researcher/Programmer, ETRI
September 28, 2016
Agenda
#ODSummit
• Introduction & Background • Who we are
• Transport networks
• Problem Definition
• Why OpenDaylight
• Architecture
• OpenDaylight Use Cases
• Takeaways
• Future Plans
• Q&A
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>
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>
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)
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.
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
Producer Data 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]']"
Implementation Details (4/1)
#ODSummit
<Architecture of Calamari T-SDN Controller by ETRI>
T-SDN controller
Model Driven Service Abstraction Layer
Restconf
Inventory 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
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 <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
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
10GbE NNI Link
xe-12/1
xe-12/2
xe-12/3
WooriNet EMS
OCES PTN
WooriNet PTN
T-SDN Controller Calamari
4K Stream transmitter 4K 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
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
KT (Korea Telecom) Architecture
MD-SAL
OSGi Framework
Karaf runtime Data Store
(In-Memory)
Data Broker Clustering Mgr.
PCE Provisioning Path Designer Topology Mgr.
Inventory Mgr.
Service Functions
Service Mgr.
OpenFlow NetConf Corba SB Protocol
Plugins
Northbound API(RESTfull)
Resource
DB
(SQL) Event Mgr.
Fault Mgr.
GUI
RCA
Statistics
Web Browser Client
Socket
TL-1 SNMP
Client Mgr.
Fault Manager(Legacy NMS) T-SDN Platform
GW Server
AP Server
Client
Controller
3rd Party App
• 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
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
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]
Top Related