transport sdn & opendaylight use cases in korea

20

Upload: justin-park

Post on 12-Apr-2017

104 views

Category:

Internet


1 download

TRANSCRIPT

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

Implementation Details(4/4)

#ODSummit

<Service Input for ServiceManager> <Result with APIDocs>

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

#ODSummit

OpenDaylight Use Cases in Korea

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]

Thank You

#ODSummit