SDN Framework and APIs
2 likes661 views
The document outlines the goals and progress of the OIF's Transport SDN Framework and APIs aimed at developing interoperable solutions for multi-technology networks. It details the objectives of various working groups, including interoperability trials and requirements for future optical networks, as well as the implementation of SDN control capabilities in transport networks. Key highlights include the framework's architecture, northbound API specifications, and ongoing collaboration with industry groups to standardize and facilitate transport network control.
SDN Framework and 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
- 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
- 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