Lyndon Ong, of Ciena and the OIF Marketing Committee Co-Chair spoke at Globecom 2015. Focus on work in OIF Transport SDN Framework and joint work between OIF and ONF on Transport APIs

1. SDN Framework and APIs
Lyndon Ong
OIF Marketing Committee Co-Chair
Ciena
Globecom 2015
San Diego, CA, USA
December 8, 2015

2. Transport SDN Framework and APIs
OIF Network & Operations
Working Group
Objective: facilitate the development of
interoperable networking and operations
solutions for multi-technology networks
Leadership: Peter Landon, BTI, Chair
OIF Interoperability Working
Group (Network)
Objective: define and carry out proofs of
concept multi-vendor interoperability trials
of OIF Implementation Agreements
Leadership: Jonathan Sadler, Coriant, Chair
OIF Carrier Working Group
Objective: develop requirements and
guidelines for the services and functions to
be supported by future optical networks
Leadership: Vishnu Shukla, Verizon, Chair
ONF Open Transport Working
Group
Objectives
• Develop SDN and OpenFlow® standard-
based control capabilities for carrier
transport networks.
• Recent change: addition of Wireless
Transport project
Leadership: Lyndon Ong, Ciena,
Chair
Work to date
• Transport SDN Use Cases & Functional
Requirements
• OpenFlow Extensions for Optical Transport
• 2014 Joint Demo with OIF
In Progress: T-API, Information
Model & OpenFlow v1.1
• Focus on work in OIF Transport SDN Framework and joint work
between OIF and ONF on Transport API

3. Carrier Network Transformation
→ Proprietary, vendor-specific silos
→ Complex to operate, integrate across
vendors/technologies
→ Logically centralized, vendor-agnostic
control and service orchestration
→ Virtualization of physical network resources
→ Open, programmable carrier networks
OSS Platform
Proprietary OS
Vendor X HW
Proprietary OS
Vendor Y HW
Proprietary OS
Vendor Z HW
Current Networks Software-Defined Networks
OSS Platform/SDN Apps
Multi-vendor Network with
Integrated SDN Control
SDN SW
SDN-
enabled HW
Open APIs
Vendor EMS
SDN Control Infrastructure

4. OIF Transport SDN Toolkit
Work in Progress
Essential tools for Transport SDN deployment
• Framework Architecture for applying SDN to a carrier’s multi-
domain, multi-layer transport network
• Transport SDN API specifications to allow easy deployment of
SDN applications
Orchestration
Services
Framework
SDN APIs
SDN Reference Architecture
Interoperability demos
Carrier Requirements

5. OIF/ONF Global Demo Topology
Results of Implementation Experience
• Carrier labs in 3 continents
• Real optical switches
• Prototype OpenFlow with
optical extensions
• Proprietary switch-to-
controller interfaces
• Framework must support
multiple heterogeneous
domains
• Operator green- and brown-
field multi-vendor network
• Northbound API is critical
• Allows orchestration to
integrate domains

6. OIF Framework for Transport SDN
Technical Paper
Incorporating:
 SDN Reference Architecture
 Carrier SDN Requirements
 2014 Global Transport SDN Demo
Objective:
• Lay out the application of SDN to carriers’
multi-domain, multilayer transport
networks
• Define the basis for standard Northbound
API for transport network control
• http://www.oiforum.com/documents/fr
amework-for-transport-sdn-
components-and-apis
6

7. Application
Layer
Control Layer
Infrastructure Layer
Domain 1
NE NE NE
Domain 2
NE NE NE
Domain 3
NE NE NE
Network
Orchestrator
Parent
Controller
Domain
Controller
Domain
Controller
Domain
Controller
SBI
NBI
SBI
Cloud
Orchestrator
Compute Storage
Multi-Domain Transport SDN Model
Multi-Domain Integration
Transport SDN framework
for carrier networks
• Can be realized over
diverse carrier networks
• Highly flexible - multiple
technology layers,
multiple domains,
greenfield and
brownfield
• Need for standards on
application layer
interface to control layer
(NBI)

8. SDN Access to Network Control
NB Interfaces
 SDN - Opening up access to control components
 Call/Connection Control, Topology, Path Query, Virtualization
 Replace internal, proprietary interfaces
 Decoupling of functional blocks enables augmentation and/or
replacement
 Delivering new network behaviors
Business
Application
Business
Application
Virtualization/Abstraction

9. Transport API Project
Northbound Interface – OIF API Project
• OIF Project to define API specs
• Based on OIF/ONF prototyping and testing of
REST/JSON APIs
Joint work with ONF for commonality across
technologies & SDOs
• Common Core Information Model
• Mapping to REST/JSON interfaces (and
YANG/NETCONF)

10. Transport API Activities
10
Objective
• Purpose-specific API to facilitate SDN control of
Transport networks
Scope – based on Framework
• Topology Service
• Retrieve Topology, Node, Link & Edge-Point details
• Connectivity Service
• Retrieve & Request P2P, P2MP, MP2MP connectivity for
(L0/L1/L2) layers
• Path Computation Service
• Request for Computation & Optimization of paths
• Virtual Network Service
• Create, Update, Delete Virtual Network topologies

11. API Model
Applications include Bandwidth on Demand, Data Center Interconnect, IP
over DWDM, Virtual Network Services, Network Analytics, etc.
Process: UML Info Model  YANG and JSON schema  Netconf and REST
interfaces
11
Topology
Service Connectivity Service
Network Information Model Database
Path Computation
Network
Virtualization
D/I-CPI (SBI)
A/I-CPI (NBI)
NENENE
NENEN/EMS
NENESDN Controller
NENELegacy Controller
NENESDN Orchestrator
NENEApplication
Transport API
Transport APIOpenflow Legacy Protocols Legacy APIs

12. T-API High Level Work Process
Use cases – describe concepts and API
usage
• Contributions from ONF members
Functional Requirements
• Formal requirements TR
Information Model
• T-API UML Module within the ONF
Common IM
• Based on and extends ONF Core IM
Data Schema
• Develop JSON and YANG schema
encoding from T-API IM
Software Prototyping
• Follow “Agile” development and “fail-
fast” processes
Work on all items (Req, IM, API) in parallel
12
Add, Modify, Clarify
Functional Requirements
Update Transport API
Information Model (UML
in Papyrus)
Update Transport API
Data-Schema
(JSON/YANG)
Prototype the APIs
Collect and Analyze the
Purpose-specific Use
cases

13. Connectivity Service Functional Reqts
(draft)
TAPI_FR_0001 Create Connectivity Service
Description
 Causes creation of a Forwarding-Construct representing the Service request to connect the Service-
End-Points within the shared Context between API Client and Provider
 Returns Service ID to be used as reference for future actions
 Initial definition will be for a basic point-to-point bidirectional service
Pre-conditions
 Requestor/Client has visibility of the set of Service-End-Points between which connectivity is
desired within the Context
 Requestor/Client has information about the types of connectivity available and constraints it can
specify such as Service Level
 Requestor/Client may be aware of other existing Connectivity Services and their IDs
Inputs
 List of ServiceEnds and details of each including
– Role of the terminating ServiceEndPoint in the context of the Service
– Directionality of the terminating ServiceEndPoint in the context of the Service
– Reference (Name/ID) to terminating ServiceEndPoint
 Connectivity Requirements such as Layer and Capacity
 Connectivity Constraints such as Latency, Cost, etc
 Start Time & End Time
Outputs
 Service ID
 Operational State
 Lifecycle State
 Confirmation of Service Characteristics : See above inputs
Notifications
Success/Failure
Change of Operational State
Error-conditions
Service not supported
Service input not supported
Endpoint not recognized
Post-conditions
Sources
Oif – cite specific documents
Onf
IETF

14. Connectivity Service IM
(draft)

15. API Divergence Problem
Absent Standards
Potential API divergence
• Vendor-specific
• Controller-specific
• Technology-specific
• Language-specific
• SDO-specific
Need for commonality
• Common core model
• Common subset
• Extensible

16. Common Information Model
Define a common object model
for all types of Software Defined
Networks
• Basic components like network
resources, service constructs
Use protocol-independent
method (UML modeling)
• Capable of being mapped to
different schemas and protocols
• YANG/NETCONF, JSON/REST,
OpenFlow
Work to develop common view
across groups
• ONF, OIF, ITU-T, TMF, MEF, etc.
CIM
O
N
F
OIF ITU-T

17. Achieving Common APIs
The Tools and Remaining Challenges
Keys to achieving interoperable common APIs
Base efforts on Common Information Model and API specification
Verify APIs interoperability and function via Implementation and
Testing
• Joint OIF/ONF Interop of both SBI and NBI
Open-Source Friendly Process with Open Documentation
Draft TAPI documents available via github (ONF OpenTransport project
“Snowmass” )
• https://github.com/OpenNetworkingFoundation/ONFOpenTransport
Open Source Implementation project “Englewood”
• Part of ONF OpenSource SDN Initiative
• https://github.com/OpenNetworkingFoundation/Englewood

18. Thank You!
www.oiforum.com

19. Agenda
Transport SDN Drivers, Needs, Challenges
• Dave Brown, OIF VP of Marketing; Alcatel-Lucent
Global Transport SDN Prototype Demo
• Jonathan Sadler, OIF Technical Committee Vice Chair; Coriant
SDN Framework and APIs
• Lyndon Ong, OIF Market Awareness and Education Committee Co-Chair;
Ciena
Virtual Transport Network Service
• Vishnu Shukla, OIF Carrier Working Group Chair; Verizon
Wrap up