Transport SDN in ONF

© 2015 Open Networking Foundation

Transport SDN in ONF

Karthik Sethuraman, NEC

Vice-Chair: ONF Open Transport WG

[email protected]

March 14, 2016

mailto:[email protected]

Revision 1.0


Content

2

• Introduction and Drivers

• Use Cases & Applications

• Architectures & Interfaces

• Activity and Projects in ONF

We will mainly look at SDN from a Transport perspective …

Revision 1.0


What we see in the market?

3

A New Kind of

Business Customer

A New Kind of

Business Customer

• Private and public cloud

• Elastic compute and

storageElastic

Compute & Storage

Requires an Elastic

Network

A New Kind of Service

Provider

SaaS, IaaS, PaaS

Elastic compute & storage

Multi-tenant

A New Network is Required

Hypergrowth - Mobile,

Video, Cloud…

A New Kind

of Consumer

• Living in the cloud

• Streaming Downloads

• Driving new network

loads

• Bandwidth-on-demand to

match the compute/storage

on-demand technology

• Multi-tenant

• Higher utilization, greater

efficiency

• Scalable and resilient

• Faster service deployment

Revision 1.0


Transport Use Cases – Network Perspective

4

Global

Tier 1/2/3 Networks

Mobile

Backhaul

Data Center

Interconnect

Carrier’s

Carriers

Different Network Requirements

Fast service provisioning Fast service provisioning

High number of services High number of services

Changing bandwidth Changing bandwidth

Number of Vendors Number of vendors High number of vendors

Business/Operational boundaries Complex networks

Revision 1.0


Transport Use Cases – Service Perspective

5

Multi-vendor support

Network or Transport as a

Service (NaaS / TaaS)

Datacenter interconnections

Multi-layer network management

DataCenter

IP Router

DWDMTransport

Control

Vendor A Vendor B Vendor C

Ethernet

ODU

Och

Automatic load dependent fast service creation

One standardized SDN control interface for easy integration of 3rd party vendors

Multilayer optimized L0-3 system with• common workflows• automatic routing• interworking

Fully automate service requests incl. network planning and equipment configuration

Matching

Hypergrowth in

data volume

Extremely dynamic

traffic pattern

Dealing with

Heterogeneous

technologies

Optimized layer

usage

Addressing

Non-automated

Operational

processes

High network

complexity

Dealing with

Different control

interfaces

Missing control IF

between vendors

Automated service creation covering L0 to L3

Addressing

Time to service

Ease of operation

Service

differentiation

Service Management Elastic bandwidthprovisioning

Creation of elastic services with automatic or “on request” changes in bandwidth

Dealing with

Statistical

bandwidth sharing

Dynamic data flow

changes

Revision 1.0


Transport Use Cases – Technology Perspective

6

L3 - IP

L1 – OTN

L0 – OcH

L2.5 – MPLS-TP

L2 – Packet

Different Network Requirements

• High number of services

• Complex network

• Numerous Protocol

• Legacy infrastructure

• Difficult to change / migrate

• Newer technology – very high flexibility

• Complex services (e-line, e-tree, e-lan, e-access)

• Interworking with IP domain

• Will have high number of services


• Too much flexibility

• Complex service types


• Switching complexity

• Deterministic Protection / Restoration

• Complex Technology – optical impairments on fiber

• New flexibility with color-/directionless architectures

• High bandwidth / slow switching times

Revision 1.0


Tremendous increase in complexity

More and more traffic

More and more layers & protocols

Changing traffic pattern

New Application (e.g. DC)

Multiple Vendors

SDN addresses this ideas

What are operator challenges for Transport networks?

7

Operator

L3 - IP

L2.5 – MPLS-TP

L1 – OTN

L0 – OcH

L2.5 – MPLS-TP

L2 – Packet

Revision 1.0


What are the vendor challenges?

8

High cost pressure

Less distinguishing HW features

High coast on protocol development

Need innovative feature set

SDN enables new approaches

Vendor

L3 - IP

L2.5 – MPLS-TP

L1 – OTN

L0 – OcH

L2.5 – MPLS-TP

L2 – Packet

Revision 1.0


Transport Use Cases – Business Perspective

9

Operator

Save OPEX Save CAPEX

Generate new business

through innovation

$How to maximize revenue?

Revision 1.0


Content

10






Revision 1.0


Use Case: Multi-Vendor network integration

EMS/NMS1

EMS/NMS2

EMS/NMS3

OSS and BSS

SNMP, CLI, CORBA, etc…

OSS and BSS& Applications

Current Situation:• Individual EMS/NMS per vendor• Huge complexity and cost in building/maintaining

OSS/BSS – EMS/NMS interfaces• Complex and slow for introducing new services

spanning multiple network domains

SDN:• New level of programmability on top of orchestrator• EMS/NMS bypassed for service creation – standardised

& simplified workflow• Open Source based orchestrators for project speed up• Reduced complexity through abstraction &

virtualization in controller / orchestrator NBI

$$$+

Controller

Orchestrator

NetworkDomain

Controller

NetworkDomain

NetworkDomain

NetworkDomain

NetworkDomain

NetworkDomain

Controller

Revision 1.0


Use Case: Multi-Layer (Packet-Optical) Management

12


PacketController

Orchestrator

TransportController

Current Situation:• Service creation is done in different domains

separately

• Routing is optimized for one layer onlyand does not consider behaviour of other layers

SDN:• Controller shields complexity of the network

towards orchestrator

• Orchestrator gets abstracted and simplified view on the network

• Orchestrator coordinates routing over several layers and can consider e.g.:

Topology & SLRG

• Optimization over several layers for equipment and link utilization can be considered

Revision 1.0


Use Case: Multi-Layer/Multi-Domain/Multi-Technology

13

Long HaulMetro DWDMMetro DWDM

RouterAccess

Orchestrator / Controller

+ / - LAG Members+/- Wavelengths, OTN Channels

Multi-layer MonitoringMulti-layer Optimisation

E2E Path Maintenance

Revision 1.0


Use Case: Bandwidth on Demand

14

• Application– Creation of new service through online portal

– Change topology (end-point) configurations

– Change service parameters. E.g.» Add/remove/change service classes

» Modify bandwidths (possibly per service class)

• Business Benefits– A new type of service offering

– Meets market demand

– Differentiator

– Self-service can reduce operations costs

• Requirements– Introduction of User SDN-controller/orchestrator

– Application / Portal Software

– Engineering rules and / or user policy

• Often a first step towards dynamic service– Visual

– Unique capability

– …quickly becoming a requirement

Orchestrator / Controller

Portal

Transport SDNNetworks

Revision 1.0


Use Cases around Data Center

15

There are different areas where SDN can help:

1. In the Data Center to optimize local infrastructure & to interwork with NFV

2. Between clients and the Data Center to secure bandwidth

3. Between Data Center to establish new bandwidth or scheduled bandwidth e.g. for backup tasks

1

2

3

Revision 1.0


Datacenter Interconnect Use Case

16

• Open Multi-Vendor, Multi-Layer interfaces

• Example

ONF TAPI - Topology, Connectivity

ONF - OpenFlow 1.3

Network Planner/Resource Manager

DWDM

Transport Controller

SDN NetworkOrchestrator

OFP 1.3OFP 1.3

ONF TAPI

Controller ControllerOFP Optical

E2E Network Orchestrator

Revision 1.0


Options for Multi-layer Service Restoration

17

Application

Orchestrator

Restoration interfaces and application

Two options for service restoration in an SDN architecture

• Controller has integrated restoration functions for

restoration inside a domain

Rerouting happen according the pre-defined SLA

parameter in the network

Advantage: Restoration is fast and simple (parameter of

the service from application point of view)

• Orchestrator based rerouting - use the standard

ONF Transport API interface

Will be used mainly for multi domain / multi-layer

restoration e.g. in combination with protection

as of speed.

Advantage: complex restoration scenarios possible over

multiple-domains (vendors) with customer specific

behaviors

Controller

Network

Element

3rd party

Controller

Network

Element

Revision 1.0


Use Case: E2E Service Restoration

18


PacketController

Orchestrator

TransportController

Current Situation:• Service creation done in domains separately

– Router» FRR, 1:1 LSP, LAG, etc…» Service: PWE3

– Och» 1+1 / Ring (protection path reserved)» NMS, GMPLS setup

SDN:• Multi-layer view on the network• Consideration current state of network for service

restoration:– Free resources – multiple layers– Error on other layers– SLRG

• Restoration according required SLA• New resilience classes for services

Revision 1.0


Use Case: Multi-Layer Service Restoration – Service Classes

19

Service SLA-based restoration

• Premium services SLA = Premium price

• Avoid over-protection of non-SLA services

Level Restoration SLA Network Mapping

Gold < 50 ms• OCh: 1+1• L2/L3: PWE3/FRR, etc• Access: Diverse

Silver < 10 Sec• OCh: Unprotected• L2/L3: Slow re-route• Access: Unprotected

Bronze None• OCh: Unprotected• L2/L3: Slow re-route• Access: Unprotected

Requirements:

• Multi-layer PCE/routing

• Multi-layer visibility

Business Benefits:

• Improves network utilisation

– Avoids over-provisioning

• Reactive SLA-based pricing

– Enable Premium pricing

Revision 1.0


Use Case: Combined Restoration and Protection

20

IP-MPLS DomainMPLS-TP Domain

Use case description:

1. 1:1 LSP protection with disjoint LSP paths in the MPLS-TP and IP-MPLS domains

2. When working path fails traffic switches to protection

3. Disabled path is deleted

4. New protection path is calculated by the SDN controller

Revision 1.0


Use Case: MPLS-TP / IP-MPLS stitching

21


Label stitching

Orchestrator

SDN Applications

Transport

Controller

IP

Controller

Revision 1.0


Use Case: Congestion Control

22


Use case description:

1. Congestion is monitored by SDN application – network wide (!)

2. When congestion is detected, lower QoS services are redirected to links with

available capacity

Revision 1.0


Use Case: Core Router Interworking

23

Regeneration

points

Transponder &

Regenerator

Pools

Orchestrator

SDN Applications

Transport

Controller

Link Aggregation

Group

Link Aggregation

Group

Colored or Grey

interconnections

• Core routers connected via n x lambda

• Low utilization of this links & router interfaces today

• Interworking IP/Transport aremanually (phone/paper) => very slow

New:

• Put unused resources in pools

• Hibernate Transponders for maxpower saving

• Manage router & Transport via SDN

• Fast service changes as of automated interfaces in SDN

• traffic pattern changes• errors (e.g. fiber breaks) • maintenance

IP

Controller

Revision 1.0


Use Case: Equipment Utilization & Planning

24

Analytics and Planning

PacketController

Orchestrator

TransportController

Current Situation:• Feedback from equipment installed in the network

via proprietary interfaces & solutions• No real time feedback => slow and faulty processes• Services are created over physical existing equipment only• No abstracted view – feedback shows real equipment which

is vendor specific.• Unutilized equipment or bottlenecks on links or equipment

can not be recognized

SDN:• This use case is in scope of several operators • Would solve a real issue of operators• Currently not considered in SDN standardization• Get a simplified view on resource utilization on top layer to

identify: Unused equipment Resource/Link utilization

• Creation of services over planned (not physical existing) equipment to reserve future resources (plug & play)

Revision 1.0


Software Defined Optics (SDO) – SDN for Flexible Photonic System

25

Current optical network Software-defined Optical Network

Flexible channel grid

Fixed channel grid

Fixed routing

Impairment-aware routing

Fixed format transponder

Variable format transponder

-1.5 -1 -0.5 0 0.5 1 1.5-1.5

-1

-0.5

0

0.5

1

1.5

-1.5 -1 -0.5 0 0.5 1 1.5-1.5

-1

-0.5

0

0.5

1

1.5

-10 -8 -6 -4 -2 09

10

11

12

13

14

15

16

Launch Power per (dBm)

Q (

dB

)

LE

SPMC

XPMC

FEC Limit

…

CH2

CH4

CH20

IM

19GHz

p/4

MZM1

MZM2p/2

MZM1

MZM2

PD+TIA

PD+TIA

Data1

Data2

Delay

PMOC ATT.

EDFA

10 even channels

10 odd channels

AWG

IL

SW

TOF (0.4nm)

SW

80km SMF

x5

WSSPD

PD

PD

PD

Pol. diversity

90 degree hybrid

Real timeScope

Coherent detection

LOPM-EDFA

20ps/div

(iii)

20 22 24 26 28 30 32 34 36 3810

11

12

13

14

15

16

17

18

19

20

OSNR (dB)

Q-F

acto

r (d

B)

WDM+25GHz IL

single channel+25GHz IL

single channel w/o IL

Single + 25GHz IL

Single , NO IL

WDM + 25GHz IL

SIN

R (

dB

)

Colored, directional ROADM

CDC multi-degree ROADM

A Flexible Transport Plane (SDO), with:• Multi-degree variable super-channel transponder:

• Multiple optical subcarriers – different flows to different destinations• Independently adjustable modulation format, power level, FEC coding, etc.

• Multi-degree flex-grid wavelength cross-connect:• allows programmable CDC switching on fine grid WDM channels, etc.

• Adaptive hybrid amplifier: • deliver optimum power level based on traffic needs with energy efficiency.

Transponder WXC

OpenFlow

agent

Amplifier

Packet SDN controller

Extended OpenFlow protocol

Transport SDN controller

Transport network planner

Intelligent Control Plane for cross-network optimization:• Monitors the physical condition changes.• Configures flexible optical hardware to achieve

optimal utilization and spectral efficiency.• Interacts with the packet SDN controller (which

monitors the network traffic and provides information of new demands) for joint network optimization.

Open Interfaces for common control of multi-vendor NW

Revision 1.0


SDO in Photonic Transmission

26

I

Q

I

Q

I

Q

I

Q

QPSK 8-QAM 16-QAM 64-QAM

Shorter distance Higher modulation level

Higher spectral efficiency Higher capacity

Lower data rate Lower modulation level

Better impairment tolerance Longer distance

λ

λ

λ

λ

Longer

distance

Less

crosstalk

Larger

channel

spacing

Lower data

rate

Shorter

distance

Closer

channel

spacing

Higher

spectral

efficiency

Higher

capacity

λ

λ

λ

λ

Higher data

capacity

per

channel

More

subcarriers

More

spectrum

available

Less data

Fewer

subcarriers

Less

spectrum

required,

lower power

consumption

Flexible Modulation Formats Flexible Channel Spacings

Flexible Subcarriers in Superchannel Flexible FEC Codings

Longer

distance,

better

impairment

tolerance

Longer/

stronger

FEC

coding

Lower data

rate

Shorter

distance/

less

impairment

Weaker/

lower

overhead

FEC coding

Higher

capacity

FEC

O/HData

FEC

O/HData

FEC

O/HData

FEC

O/HData

Revision 1.0


SDO in Photonic Switching

27

ROADM

T

P

N

D

T

P

N

D

T

P

N

D

T

P

N

D

ROADM

T

P

N

D

T

P

N

D

T

P

N

D

T

P

N

D

ROADM

T

P

N

D

T

P

N

D

T

P

N

D

T

P

N

D

ROADM

T

P

N

D

T

P

N

D

T

P

N

D

T

P

N

D

ROADM

T

P

N

D

T

P

N

D

T

P

N

D

T

P

N

D

ROADM

T

P

N

D

T

P

N

D

T

P

N

D

T

P

N

D

Colorless: Any wavelength can be dropped to or added from each transponder.

Directionless: Any transponder can receive signal dropped from any input degree, and can add signal to any output degree.

Contentionless: Signals with same wavelength can be added/dropped to/from different inputs simultaneously.

Gridless: Different channels can occupy different amount of optical spectrum bandwidth concurrently, and these bandwidths can be changed dynamically.

Filterless: Each transponder can pick the target WDM channel from multiple WDM channels without using demultiplexer or filter.

Gapless: WDM channels that will be switched to the same destination are grouped into wavebands to reduce filtering effect and reduce switching elements.

Revision 1.0


SDO in RWSA: Routing, Wavelength & Spectrum Assignment

28

Impairment-aware Routing

CDC Multi-degree ROADM

Spectrum shaping with high level code

High spectrum efficiency

Long distance

QPSK: high OSNR tolerance

Variable Format Transceiver Flex Grid

1Tb signal 800Gb Optimized

Variable Rate Transceiver・High capacity with multiplexing multiple optical subcarriers・High spectrum efficiency with dynamic number of subcarriers

Failure

Example: On short distance working path , high level code modulation results in higher spectrum efficiency. On protection path that is long distance, modulation format is changed to low level code for high OSNR tolerance.

Impairment-aware

Client 800Gbps

Revision 1.0


Content

29






Revision 1.0


SDN & Related Areas

30

Data Center/Enterprise

SDN

Transport (Packet + Optical)

SDN

SDN

Network Function Virtualization

Revision 1.0


Data-Center/Enterprise SDN versus Transport SDN?

31

Transport SDN

SDN principles applied to transport networks

Layer 0 (optical)

Layer 1 (OTN)

Layer 2 (Carrier ETH)

Layer 2.5 (MPLS-TP)

History: Fast service setup required as of high bandwidth demand

New technologies introduce flexible optical layer

Operator to solve integration problems

ONF OTWG Openflow for Optical (1st release available)

ONF Transport APIs – YANG/JSON (draft available today)

2014 interoperability tests in several vendor labs done

Data Center/Enterprise SDN

SDN principles applied to packet networks

Layer 2 (ETH)

Layer 3 (IP/MPLS)

History: Campus networks – research of new protocols

Frustration of device SW changes for any new function

Relatively Mature

SDN ideas solidified ~ 2008

First ONF OpenFlow specs in 2009

OpenFlow interface widely deployed (1.3.x)

InfrastructureLayer

Control Layer

Application Layer App xx App yy

routing NE discovery

App zz

FM PM

http://www.openflow.org/wk/images/9/9d/SDN_based_MPLS.png

http://www.openflow.org/wk/images/9/9d/SDN_based_MPLS.png

Revision 1.0


SDN for DC/Enterprise Networks

32

• It takes me too long to deploy new services

– New services require a new Protocol or Device

– Constrained by Vendors – procure, design,

integrate, deploy, cycle

• My network is difficult to operate

– Too complex

– High number of new protocols

– Protocol test needed between vendors

– New standards increase cost / decrease stability

– Don’t touch! You’ll break it!

• My network has a mind of its own

– Current protocols are distributed and make local

decisions rather than network wide

– Distributed protocols are not optimized for end-

to-end and layer-to-layer

– Congestion control is hard with distributed

management planes

– Lack of traffic visibly

Revision 1.0

© 2016 Open Networking Foundation33

SDN for Transport Networks

EMS/NMS1

EMS/NMS2

EMS/NMS3

OSS and BSS

SNMP, CLI, CORBA, etc…

$$$+

NetworkDomain

NetworkDomain

NetworkDomain

Traditionally the transport networks are more static Traffic growth and higher layer applications flexibility was

not strong driver in transport Focus was more on stability and quality Robust engineered networks, typically for peak capacities Architectures traditionally couple of layers

Electrical SDH layers had some limited flexibility Optical layers have been totally static in past

Expensive OSS integration of number of vendors domains

Modern transport networks are required to be more dynamic Packet optical devices & introduction of ETH/MPLS-TP Optical switching with new optical technology e.g. CDC ,

FLEX-Grid ROADMs Hyper-growth transport capacity demands High price pressure requires operators to optimize and

focus on new business Application focused – programmable – automation OPEX reduction a must

Revision 1.0


Why do we need SDN in Transport?

34

Programmability:

Programmable interfaces

Applications focused architecture

Abstraction & Virtualization

Multi-Tenant capabilities

Integration focused:

Multi-layer

Multi-vendor

Innovation:

Opens doors for new service models

Service differentiation through new application

Simplified Architectures:

Integrated E2E / Multi-layer service creation

Automatic reaction on errors or any changes

Financial Benefits:

Opex: efficient service setup

Capex: fast ROI / hardware utilization

New revenue opportunities

Openness:

Open Stanadsrds & Interfaces

Open Source SW

Principles of SDN What it Enables in Transport Network

Revision 1.0


Is T- SDN different from traditional architectures?

35

OSS/BSS/App

Systems

NMS/

EMS

NENENE

TraditionalArchitecture

SDN

Controller

Apps

NENENE

SDNArchitecture

The difference is NOT:

Standardized Management Interfaces

Standardized Architecture

Partly not the Open Interfaces

Partly not even the use cases

The difference is:

A new way of thinking

Application focused architecture and interfaces

Application takes control over the service

definition and delivery at faster time scales

Simplification through Abstraction & Virtualization

Open Source based platforms & development

Revision 1.0


Where does Transport SDN fit in? The Big picture…

36

IT Apps

Customer Order Orchestration

Alarms

MetricsVNF-M SDN ControllerVIM

NFV OrchestrationNFV Orchestration

VIM T-SDN Controller

Transport SDN DomainsNFV Infrastructure Domains

Traditional Network Domains

VNF-M

Service Activation Request

Alarms/Metrics/Config

ONF TAPI Connectivity

Topology Request

Alarms/Metrics/Config

VNF Request VNF Fault/KPIs

VNFVNF

Service Activation Request

Alarms, Metrics,

Config info

PNFPNF

Cust

omer

O

rche

stra

tion

La

yer

Serv

ice

Orc

hest

rati

on

Laye

r

NFV

O

rche

stra

tion

La

yer

Cont

rolle

rs

Laye

rIn

fras

truc

ture

La

yer

EMS EMS

Allocation Inventory/Faults/Metrics

VNF Lifecycle

Alarms/Metrics

Customer Order

Service Administration

Order

E2E Service Request

Service

Monitoring

Customer

Customer OrderService

AdministrationService Monitoring

Self-Service Portal

Service Orchestration

DC SDN Controller

Application Cloud ServicesData Center

IT Apps

IaaS/SaaS Cloud Managers

IaaS, SaaS Request

IaaS, SaaS Fault/KPI

OSS

Connectivity Service

DC SDN Controller

Revision 1.0


Where does T-SDN fit in? E2E Network Architecture

37

AggregationSwitches

WDMPacketTransport Node

PacketTransport Node

Home

Fiber

Office

PacketTransport Node

Physical

Server Pool

CDN SBC Security GWBRAS

Programmable FlowPhysical Switches

Applications (Web, Mail, SNS, IPTV, etc.)

NW service(EPC,IMS,MVNO-GW)

Physical Server

Pool

PhysicalServer Pool

Microwave

Mobile PCSmartphone

AggregationSwitches

E2E

Orchestration

TMS TOMS

eNB OLT OLTeNB

④Operations & Orchestration

③ SDN Transport

② NFV (Network

Functions Virtualization)

①Data Center SDN

OSS/BSS

Cloud controllerOpenFlow controller

Programmable Flow

Physical Switches

NMS/EMS

SDN-C

NMS/EMS

Revision 1.0


2014 OIF-ONF Transport SDN Interop Demo

Revision 1.0


ONF Transport – API & Interfaces: Functional Architecture

Topology

ServiceConnectivity

ServicePath Computation

Service

Shared Network Information Context

Virtual Network

ServiceNotification

Service

NENetwork Resource GroupsNENESDN Controller

NENESDN ControllerNENEApplication

Transport API

Transport API

SBIs (e.g. Openflow Optical)

Revision 1.0


Content

40






Revision 1.0


• Charter: The Open Transport project will address SDN and OpenFlow® Standard-based control capabilities for transport technologies

– Including Optical and Wireless

– Identifying/addressing Use Cases

– Application of SDN Architecture

– Information Modeling of transport NW

– Defining standard SDN Interfaces for transport network controllers

• OpenFlow® protocol extensions

• SDN Controller Transport APIs.

• WG Chair: Lyndon Ong

• Vice Chairs: Karthik Sethuraman, Maarten Vissers, Vishnu Shukla

• Biweekly calls: Tuesday 6am US PDT

• [email protected]

• Sub-projects:

– Architecture – Maarten Vissers

– Information Model – Kam Lam

(weekly calls Tuesday 5am US PDT)

– Transport APIs – Karthik Sethuraman

(weekly calls Monday 6am US PDT)

– OpenFlow Protocol – Lyndon Ong

(bi-weekly calls Tuesday 6am US PDT)

– Wireless Transport – Ariel Adam

(bi-weekly calls Tuesday 6am US PDT)

– Snowmass OSSDN project – Karthik

– Englewood OSSDN project – Italo Busi

ONF Open Transport WG (OTWG) – At a Glance

Revision 1.0


• Openflow Optical Extensions– TS-022

– Published as a separate extension document to core Openflow Spec

• Optical Transport Use cases– TR-509

• Requirements Analysis for Transport OpenFlow/SDN

– TR-508

• Openflow-enabled Transport SDN solution brief

– Jointly with ONF-MEC

• Transport SDN Architecture (TR)– In ONF-review/approval process

• 2014 OIF-ONF Joint Prototype Interop– 9 Vendors, 6 Cariers

– Pre-standard Openflow Optical, T-API

Current/near term activities, projects, documents

• Openflow Optical Extensions v1.1 – (Q2 2016)

• Transport API v1.0 – (Q2 2016)– Functional Requirement Spec (FRS)

– UML Info Model, YANG/JSON Schema

– Swagger API, Python Stubs

• Wireless/RAN Transport – (2Q 2016)– PoC: UML Info Model, YANG Schema

– Openflow based PoC completed last year

• Information Model – (2Q 2016)– Technology specific fragments to ONF CIM

– L0/L1 (OTN), L2 (Carrier Ethernet, MPLS-TP)

• OIF-ONF Transport SDN Interop (Q3 2016)

• Next Interim meeting June 13-17– Shenzhen, China (ZTE sponsor)

ONF OTWG Publications and Deliverables

Revision 1.0


• Standardized extensions to OFP 1.3/1.4+

• Allows control of L0/OCH (optical channel) and L1/ODU (electrical timeslot) switching

• New OpenFlow port types– OTU, OPS, OTS, OMS, OCH

– Optical port capabilities including client signals

• New Match fields – Optical Channel Frequency and slot width for L0

– Signal type and tributary slot map for L1

– Uses Set-Action to rewrite label fields

• Support of L0/L1 Adjacency Discovery– Reference standardized L0/L1 data-plane

discovery signaling mechanisms (TTI, etc)

– OF extensions to provision discovery labels and report mismatches/results

• Guidance on use of OF mechanisms for optical transport (e.g. timeouts, flags)

Benefits and Goals

• Enables usage of OpenFlow-based SDN in Optical Transport Networks

• Multilayer integration using OpenFlowprotocol across all layer networks

• Unified control of packet-optical converged transport devices using OpenFlow

• Validated technically

– Prototyped and tested in 2014 OIF/ONF demonstration

– Prototyped and released in ONOS December open source code

OTWG Optical Extensions: Key Issues Addressed

Revision 1.0


OFP-based control of Converged Packet-Optical NEs

L3 - IP

L2.5 – MPLS-TP

L1 – OTN

L0 – OcH

L2.5 – MPLS-TP

L2 – ETH

• Packet-Optical converged network devices

• IP/MPLS(-TP), ETH, ODU, OCH switching

• Openflow – Optical MAT extensions

• ODU/OCH match fields, OF optical ports

• SDN-based forwarding/routing control logic

• Multi-layer Network/Switch Information Model

Revision 1.0


Short Term Work Items

• Draft targeted for quick release (2016Q1)

• Cleanup structure and format of the port extensions TLV

• Usage of a code point for Optical Port type rather than experimenter

• Support existing Optical port extensions in OF 1.4 as OTWG photonic layer

• Additional Optical port types/layers (OTN Client ports) and attributes

• Corrections, clarifications, additional examples to v1.0 spec

Longer Term Work Items

• Worked on in parallel – (2016Q2)

• Support for fixed cross-connections

• Connectivity constraints

• Multilayer adaptation control– based on EXT-112 and 382

• OAM/monitoring– Autonomous Function based on EXT-548

• Protection– Autonomous Function or other mechanism

• Wireless extensions– Likely to be a separate spec

• Programmable OTN (Onf2015.453)– Likely to be whitepaper or use case

OTWG Optical Extensions: Next Steps• Plan: build on OpenFlow Optical extensions v1.0 published in 2015 as TS-022

• Support OpenFlow 1.6 modularization goals

• Tasks categorized into short term tasks (v1.1) and longer term items (v2.0+)

Revision 1.0


• Objective – realize the software-centric approach to standardization

– Purpose-specific API to facilitate SDNcontrol of Transport networks

– Focus is on functional aspects of transport network control/mgmt

– Target is YANG & JSON API libraries

– Demonstrable code

• Activity scoped based on use case contributions and discussions. Examples include

– Bandwidth on Demand

– E2E Connectivity Service

– Multi-layer Resource Optimization and Restoration

– Multi-Domain Topology and Monitoring

– Network Slicing and Virtualization

• Topology Service– Retrieve Topology, Node, Link & Edge-

Point details

• Connectivity Service– Retrieve & Request P2P, P2MP,

MP2MP connectivity

– Across (L0/L1/L2) layers

• Path Computation Service– Request for Computation &

Optimization of paths

• Virtual network Service– Create, Update, Delete Virtual Network

topologies

• Notification Framework– Subscription and filtering

– Autonomous mechanism

Transport API Project Overview

Revision 1.0


• Use cases – describes concepts and API usage– Presentation Slide decks, Contributions welcome

• Functional Requirements– Word doc – onf2015.087.* - last call draft in progress

• Information Model– Develop API-specific UML model (Papyrus tool)

– Based on and extends ONF Core IM

• Data Schema & API– Develop YANG/JSON schema encoding

– Generated from API IM using OSSDN EAGLE tools

– Swagger API/Python code generated from YANG schema

• Software Prototyping– Separate project under ONF Open Source SDN

• Follow “Agile” development and “fail-fast” processes– Work on all items (Req, IM, API) in parallel

TAPI - High Level Weekly Work Flow

Add, Modify, Clarify

Functional Requirements

Update Transport API

Information Model

Update Transport API

Data-Schema

Prototype the APIs

Collect/Analyze purpose-

specific Use cases

Revision 1.0


TAPI Coordinates

48

• Single 2-hour weekly working-level call

– Work on all aspects of T-API

– Status reporting in the OTWG biweekly Tuesday 6 AM call

• Transport API weekly working-level call

– Mondays, 6 AM US Pacific Time

– https://onf.webex.com/onf/j.php?MTID=m4d6b2de664e9c5d76a4de49ca479ce22

• ARO Project Resources and Mailing List

– [email protected]

– https://login.opennetworking.org/bin/c5i?mid=3&rid=5&gid=0&k1=24&tid=1420463562

• OSSDN SNOWMASS/Open Transport API Specification - drafts

– UML Info Model, YANG Schema, JSON Schema, Swagger API

– https://groups.opensourcesdn.org/wg/SNOWMASS/dashboard

– https://github.com/OpenNetworkingFoundation/ONFOpenTransport

• OSSDN ENGLEWOOD - Open Transport API Prototyping

– https://groups.opensourcesdn.org/wg/ENGLEWOOD/dashboard

Revision 1.0


• Functional Requirements last call draft will be socialized for ONF-wide review and will be available publicly for comments and feedback

– Targeted towards early 2Q 2016 release

• API drafts to be posted and regularly updated on the ONF Github site

– Information Model (UML), Data schema (YANG, JSON, Swagger)

– https://github.com/OpenNetworkingFoundation/ONFOpenTransport

• Next version – planned for 2016Q2-end –around ONF Interim meeting

– Enhance Virtual Network Service features

– P2MP, MP2MP Connectivity Service Use cases

– Protection and OAM Support

– Optical, Packet & Wireless Transport technology layers spec-models

• WDM, OTN, Carrier Ethernet, MPLS-TP

Liaisons and multi-SDO impacts

• Closely working with the ONF-IMP(Information Modeling Project)

• Coordinating with OIF for the 2016 Transport SDN Interop Demo which will use ONF T-API

• Coordinating with MEF to align with LSO-NRP (Network-Resource) information model

• A sub-group in ONF working on a IETF informational draft comparing TEASTopology with T-API Yang output

• Working with OASIS/TOSCA to define templates for orchestration of T-SDN

• Network Interface in the proposed OSSDN CSO - Cross Stratum Orchestration project

TAPI – Next Steps

Revision 1.0


• Demonstrated bandwidth-on-demandapplication and end-to-end service orchestration in a multi-domain environment

• 5 carriers, 9 vendors

• Intra-carrier lab and Inter-carrier lab testing

Architecture

• Domain Controller – Controls vendor domain networks – generally provided by NE vendor

• Parent Controller – Client (datacenter/ packet) controller requiring transport network connections to interconnect L2/L3 switches under its control

– Also used in hierarchical controller architecture to control external vendor transport domain

• Transport Network Orchestrator –Orchestrates end-to-end service setup across multiple controllers

Interfaces

• Service API – The call interface from orchestrator to domain controllers requesting setup of transport connection of specific bandwidth and QoS profile within the controller domain

• Topology API – The interface between orchestrator and domain controller for exchanging network topology (actual or virtual) of the transport domain used for service/connection setup

• Openflow Optical Extensions – The interface between domain controller and its network elements and switches

– Also used in hierarchical controller architecture as the interface between client/parent controller and domain controller

2014 OIF-ONF Transport SDN Interop Demo

Revision 1.0


• Controller

– SBI: ONF OF+ OTWG extensions, Other

– NBI: ONF T-API

• Topology Service

• Connectivity Service,

• Virtual Transport Nw Service

• Notification Service

• Path Computation Service

• NE

– NBI: OF+ OTWG extensions, Other

• Application

– Packet Congestion reroute

– IMS Congestion reroute

– NFV service orchestration

– Others? (multi-layer restoration)

2016 OIF-ONF Transport SDN Interop (Planned)

Test end

Jan Feb

2016

OIF, ONF, NFV

Conf Call

ONF Workday

Contract/NDA

OFC 2016

Mar Apr

BCE

NovMay Jun Jul Aug Sep Oct

ECOC

20162Q OIF 3Q OIF 4Q OIF

L123

SDN

Test start Readouts

OECC

1Q16 OIF

ETSI NFV ETSI NFV

Hard commits due

L123 NFV

Revision 1.0


2016 OIF-ONF Transport SDN Interop

Packet Network

Real Network

Vendor A Vendor C

Vendor B

Virtual Net

AVirtual Net

B

Ctrlr

P1

Ctrlr

A1

Ctrlr

P2

Ctrlr

V1

Ctrlr

V2

Ctrlr

V3

Topo

Abs

Topo

Serv

Req

Serv

Req

Abstract

Control

OF

Congestion

NotificationIMS

Congestion

Serv

Req

VTNS

User

Revision 1.0


• Benefit: Completely automated, programmable, integrated and flexible network – leveraging the installed base in an optimized manner.

• Technical Challenges:

– agree on standardized architectures and abstraction/ virtualization models

– performance of centralized systems & OF

• Commercialization Challenges:

– Open Source business models

– New business models leveraging SDN

• Organizational Challenges:

– Adapt deep rooted processes across traditional silos & boundaries to leverage SDN flexibility

• Deployment Challenges:

– Carrier grade SDN systems for field deployments

– Maturity of SDN network technologies for green field deployments as well as integration of legacy networks

Transport SDN Benefit and Challenges

SDN Software

Availability & Functionality

Network Structure

&

Technology

Adaptation of

Customer

Processes

Successful

SDN

deployment


Thank youwww.opennetworking.org

Transport SDN in ONF

Documents

Transcript of Transport SDN in ONF