transport sdn in onf currently not considered in sdn standardization • get a simplified view on...
TRANSCRIPT
© 2015 Open Networking Foundation
Transport SDN in ONF
Karthik Sethuraman, NEC
Vice-Chair: ONF Open Transport WG
March 14, 2016
Revision 1.0
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
• High number of services
• Too much flexibility
• Complex service types
• High number of services
• 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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
Transport Use Cases – Business Perspective
9
Operator
Save OPEX Save CAPEX
Generate new business
through innovation
$How to maximize revenue?
Revision 1.0
© 2016 Open Networking Foundation
Content
10
• 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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
Use Case: Multi-Layer (Packet-Optical) Management
12
OSS and BSS& Applications
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
Use Case: E2E Service Restoration
18
OSS and BSS& Applications
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
Use Case: MPLS-TP / IP-MPLS stitching
21
IP-MPLS DomainMPLS-TP Domain
Label stitching
Orchestrator
SDN Applications
Transport
Controller
IP
Controller
Revision 1.0
© 2016 Open Networking Foundation
Use Case: Congestion Control
22
IP-MPLS DomainMPLS-TP Domain
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
Content
29
• 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
© 2016 Open Networking Foundation
SDN & Related Areas
30
Data Center/Enterprise
SDN
Transport (Packet + Optical)
SDN
SDN
Network Function Virtualization
Revision 1.0
© 2016 Open Networking Foundation
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
Revision 1.0
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation
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
© 2016 Open Networking Foundation38
2014 OIF-ONF Transport SDN Interop Demo
Revision 1.0
© 2016 Open Networking Foundation39
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
© 2016 Open Networking Foundation
Content
40
• 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
© 2016 Open Networking Foundation41
• 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
• 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
© 2016 Open Networking Foundation42
• 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
© 2016 Open Networking Foundation43
• 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
© 2016 Open Networking Foundation44
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
© 2016 Open Networking Foundation45
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
© 2016 Open Networking Foundation46
• 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
© 2016 Open Networking Foundation47
• 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
© 2016 Open Networking Foundation
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
– 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
© 2016 Open Networking Foundation49
• 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
© 2016 Open Networking Foundation50
• 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
© 2016 Open Networking Foundation51
• 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 Open Networking Foundation52
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
© 2016 Open Networking Foundation53
• 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
© 2015 Open Networking Foundation
Thank youwww.opennetworking.org