Post on 12-Jan-2017
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