The Importance of Rich APIs in Transport SDN

Jonathan Sadler, Coriant

Vice-chairOIF Technical Committee

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

SDN improves transport control Eliminate “One-size-fits-all” solutions

• NE-behaviors may not matchcarrier requirements

• Example• Combined Reroute and Protection

Programmability enables carrier requirements to be met

400% Capacity use50ms protection all the time

300% Capacity use50ms protection switch first fault

~300ms switch second and subsequent

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 TransportNetwork

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 system6

ResourceBookkeepin

g

FabricConfig

Connection Management

Topology

Path Computation

Service Management

CPU MgmtMem Mgmt

Virtualization

NE

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 APIs7

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

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

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

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

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

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

Summary Service Providers want programmable network

control• Lower costs, New Services, Differentiation

SDN APIs in a Component Architectureenable programmability• Components may be added in parallel, upgraded

Rich APIs required• Connection Management, Path Computation, Topology

14