OIF presentation at 21st European Conference on Networks and Optical Communications (NOC). Service Providers want programmable network control, Lower costs, New Services, Differentiation. SDN APIs in a Component Architecture enable programmability. Components may be added in parallel, upgraded. Rich APIs required - Connection Management, Path Computation, Topology.

1. The Importance of Rich APIs in Transport SDN
Jonathan Sadler, Coriant
Vice-chair
OIF Technical Committee

2. Premise
Carriers have long desired control for Transport
• Reduce time to deliver service
• Reduce cost using mesh reroute not protection
• Increase availability through 1:n restoration
• New Services
Different approaches have been taken
• Management system based
• GMPLS
What is different about SDN?
3

3. SDN improves transport control
Eliminate “One-size-fits-all” solutions
• NE-behaviors may not match
carrier requirements
• Example
• Combined Reroute and Protection
Programmability enables carrier requirements to be met
400% Capacity use
50ms protection all the time
300% Capacity use
50ms protection switch first fault
~300ms switch second and subsequent
4

4. SDN improves transport control
Eliminate “One-size-fits-all” solutions
Application awareness of network capabilities
• Existing Control Planes are “write-only”
• Request connections without any awareness of network
• Business Applications need detail for services
available
Match carrier services with application needs
Connect
Query
Orchestrator
Transport
Network
5

5. Service Management
Path Computation
APIs make programmability possible
Application Programming Interfaces (APIs)
enable component architecture
• Applications exist separate from common functions
• Common components provides centralized clearing of common information
• Components provide marshalled interface, managing component integrity
• System monitors components to marshal common resources (e.g. memory, CPU usage)
New applications coexist alongside existing Applications
• Enable New behaviors to be delivered by the system
6
Resource
Bookkeeping
Fabric
Config
Connection Management
Topology
Path Computation
Service Management
CPU Mgmt
Mem Mgmt
Virtualization
NE

6. OIF: API Framework
Technical Whitepaper published May 2015
• Developed in conjunction with 2014 Interop event
• Based on ASON architecture
• Specifies a set of interfaces to be made open through APIs
7

7. Interface styles and formats
Two major types
• Netconf
• IETF’s answer to issues encountered with SNMP
• Information models described by “YANG” specifications
• YANG = “Yet another next generation”
• Many YANG models are generated from existing SNMP MIBs
• Supports a number of underlying transport protocols (e.g. SSH, BEEP)
• Actions performed via RPC interface
• Models include object visibility
• REST
• API style used by many websites
• Information models are typically documented using UML or Swagger
• Swagger provides automated tools
• Object SCRUD actions map to HTTP requests
• E.g. POST – Create, PUT – Populate, GET – Read, GET Search
8
Both Object oriented, both use XML or JSON format

8. OIF: SDN APIs
Series of REST JSON APIs used in the 2014 OIF Interop Event
• Service Request*
• Connection Request
• Path Computation*
• Topology*
• Abstraction Control
• Notification
Many vendor implementations exist
Activity on these specifications has reduced
• Current focus is on ONF’s Transport API specification
9
* = API actually tested in the event

9. ONF: Common Information Model & Transport APIs
ONF Common Information Model is continuation of MTOSI
• MTOSI effort started in TMF
• Activity moved to ONF due to changes in company memberships
• Liaison relationships to other SDOs/Forums (e.g. IETF, MEF, OIF)
• IM is designed for both packet and circuit switched technologies
• Describes information independent of interface
ONF Transport APIs are derived from the CIM
• Recognizes interface data models can’t always align with internal model
• Interfaces often enforce limitations not friendly to model: e.g. TL1 input/output buffer size
• Almost all APIs in OIF Framework supported
• Connection management has been merged with service request
• Vendor implementations are just starting
• Specs available via OS-SDN Project Snowmass:
10
Support NETCONF and REST, XML and JSON format
https://github.com/OpenNetworkingFoundation/ONFOpenTransport

10. Many YANG specifications underway in different
working groups
• Can be used with NetConf or RESTConf
Service Request
• TEAS
• TE Tunnel Model
Path Computation
• PCE
• PCEP Model
Topology
• I2RS:
• Layer 2 Topology
• Layer 3 Topology
• TEAS
• TE Topology Model
Abstraction Control
• TEAS
• Abstraction Model
IETF:API work
11
Activities focused on Packet, minimal thought about transport

11. OpenROADM’s APIs
Set of YANG data models specified by AT&T initiative
• Service model
• Network model
• Device model
Interface is NE focused, not end-to-end NMS
Specification is less rigorous than OIF, ONF, IETF
models
• E.g. PM data specification
12

12. Other activities just getting started
Open Config
• Parallel projects: Optical-transport, IP routing, policy
• Optical-transport APIs are NE scoped
• Service providers: Google, AT&T, BT, DT, Facebook,
Microsoft, SKT
Open Compute’s TIP
• Parallel projects: 5G, IP-access, IP/Optical Integration
• Service providers: Facebook, DT, EE, SKT, Telefonica
and Vodaphone
13

13. Summary
Service Providers want programmable network control
• Lower costs, New Services, Differentiation
SDN APIs in a Component Architecture
enable programmability
• Components may be added in parallel, upgraded
Rich APIs required
• Connection Management, Path Computation, Topology
14