OIF SDN Transport API NFV Proof of Concept. May 4, 2017 Layer 123 NFV World Congress Lyndon Ong, Ciena OIF MA&E Committee Co-Chair

Transcription

1 OIF SDN Transport API NFV Proof of Concept May 4, 2017 Layer 123 NFV World Congress Lyndon Ong, Ciena OIF MA&E Committee Co-Chair

2 Agenda NFV/SDN Relationship Transport API OIF Transport SDN Interop Testing NFV PoC Findings and Next Steps

3 Enabling NFV Transport for Carriers Deploying NFV Across Carrier Transport Infrastructure Diverse Transport Networks Multi-Vendor Multi-Technology Complex Management NFV Needs Deploy functions quickly and ubiquitously Flexible allocation of network resources and connectivity Virtualize resources across vendors and network domains Programmability enables carrier requirements to be met 3

4 Supporting network programmability NFV and SDN Integration The target scope in OIF Network controller for the WAN Architectural model: Multi-layered Multi-domain/multi-vendor Network Controller Model Hierarchical: E2E/ Domain Network Controller NBI/ SBI: TAPI Network elements in the WAN Optical network Nodes Packet network Nodes ETSI GS NFV-MAN 001 V

5 Transport SDN Model Open API for network control is essential Common abstraction model OSS/App Multi-Domain Controller Transport API Implementation of the MEF LSO Presto interface and subject of MEF work on Network Resource Provisioning API Common technological models TAPI Agent TAPI Agent TAPI Agent MW Controller Optical Controller IP Controller 5

6 Transport API Architecture Topology Service Connectivity Service Application Path Computation Service Shared Network Information Context SBIs (e.g. Openflow Optical) Network Resource Groups SDN Controller Transport API Virtual Network Service Transport API SDN Controller Notification Service Topology Service Retrieve Topology, Node, Link & Edge-Point details (Across al layers) Connectivity Service Retrieve & Request P2P, P2MP, MP2MP connectivity (Across all layers) Notification Service Subscription and filtering / Autonomous event notification Path Computation Service Request for Computation & Optimization of paths Virtual Network Service Create, Update, Delete Virtual Network topologies 6

7 T-API SDK: Organization and Modularity ONF Transport API Functional Requirements ONF TR-527, June 2016 ONF Open Transport WG Project Input to the TAPI SDK (Software Development Kit) Software-wise, T-API SDK is packaged as 4 Eclipse subprojects ( ONFOpenTransport ) Papyrus-UML Information Model Technology-agnostic generic framework + technology specific extensions (OTN, ETH) based on ONF Core Information Model Auto-generated Using ONF OSSDN EAGLE Project Tools YANG Data Schema Swagger-JSON RESTConf API Reference Implementation (RI) in Python Iterative design process with code development an integral part of the cycle Purpose-specific Use cases Functional Requirements Information Model (UML in Papyrus) Data-Schema (JSON/YANG) API Code 7

8 Topology Model A FwdingDomain (Node/Topology) 01 LTP (Node Edge Point) 01.1 LTP (Service End Point) Link Network Control Domain Internal Service Provider Topology retrieves a detailed internal topology n 01 A A A.2.1 A.2 A.2.2 A A 02.n 21 A A B 02 Service Level Topology may only show Service Endpoints 02.1

9 2016 SDN T-API Interop Demo 9

10 10 Timeline Extensive preparation and testing ETSI NFV ONF Interim BCE OECC ONF Workday 3Q OIF ECOC 2016 L123 SDN 4Q OIF 1Q OIF MWC 2017 OFC May Q16 OIF Jun Jul Aug Contract/NDA Sep Oct Nov Dec Jan Feb Test start Test end 2017 Mar Readouts Tech Spec Start Proposed and accepted as an ETSI NFV PoC by ETSI TST WG See Domain_Transport_SDN (Hiroshi Dempo, C, editor)

11 Transport SDN Interop Testing Multi-vendor, Multi-layer, Multi-domain Common abstraction model Parent MD Controller Transport API Child MD Controller Transport API Common technological models TAPI Agent TAPI Agent TAPI Agent L0 ROADM Controller L1 OTN Controller IP/Optical Controller 11

12 12 Topology Capture HTTP/ Created Content-Type: application/json Server: Werkzeug/ Python/2.7.5 Date: Tue, 12 Dec :41:37 GMT { "_linkport": [ { "_nodeedgepoint": "/restconf/config/context/_topology/7a f-abf2-4c48c4ab9d3e/_node/07d7ad4c d98-8be8-4e6826cece43/_ownednodeedgepoint/37a03a6b-3e95-48bb-a253-fd5b3d2f597b/", "direction": "BIDIRECTIONAL", "localid": "lp13", "role": "SYMMETRIC" }, { "_nodeedgepoint": "/restconf/config/context/_topology/7a f-abf2-4c48c4ab9d3e/_node/019ac632-20d b77c ee60ed6/_ownedNodeEdgePoint/a4b af-4c38-862b-6c4a46ca9ec7/", "direction": "BIDIRECTIONAL", "localid": "lp31", "role": "SYMMETRIC" } ], "_node": [ "/restconf/config/context/_topology/7a f-abf2-4c48c4ab9d3e/_node/07d7ad4c d98-8be8-4e6826cece43/", "/restconf/config/context/_topology/7a f-abf2-4c48c4ab9d3e/_node/019ac632-20d b77c-80852ee60ed6/" ], "_state": { "administrativestate": "UNLOCKED", "lifecyclestate": "INSTALLED", "operationalstate": "ENABLED" },

13 Service Invocation Capture POST /restconf/config/context/_connectivityservice/ Content-Type: application/json { "_serviceport": [ { "_serviceendpoint":"\/restconf\/config\/context\/_serviceendpoint\/tsdn:sm:script::2\/", 13 "direction": "INPUT", "role": "ROOT" }, { "_serviceendpoint": "\/restconf\/config\/context\/_serviceendpoint\/tsdn:adva:script::5\/", "direction": "OUTPUT", "role": "LEAF" } ], "_connconstraint": { "servicetype": "POINT_TO_POINT_CONCTIVITY", "requestedcapacity": {}, "_includepath": [ { "_node": [ "\/restconf\/config\/context\/_topology\/top\/_node\/tsdn:sm:script\/", "\/restconf\/config\/context\/_topology\/top\/_node\/tsdn:adva:script\/" ], "_nodeedgepoint": [ "\/restconf\/config\/context\/_topology\/top\/_node\/tsdn:sm:script\/_ownednodeedgepoint\/tsdn:sm:script::4\/", "\/restconf\/config\/context\/_topology\/top\/_node\/tsdn:adva:script\/_ownednodeedgepoint\/tsdn:adva:script::3\/" ], "localid": 0 } ] }

14 Test Case tracking

15 15 Findings Transport API is a solution that enables SDN for Carriers Networks with an evolutionary approach. It automates and simplifies the operation of transport domains for L0, L1 and L2 services. Network topology information elements can be taken from the underlying network infrastructure configured by multiple vendors network equipment. T-API implementation deployed in a hierarchical SDN controllers tree enables real-time orchestration of on-demand connectivity setup, control and monitoring across diverse multi-layer, multi-domain, multi-vendor, networks.

16 Next Steps T-API 2.0 Based on demo feedback, further align T-API with YANG Best Practices Object ID format and lifecycle Separation of Configuration, Operational Data T-API functionality extended for additional use cases Path computation refinements, e.g., forwarding attributes, constraints Protected and Recoverable Services OAM, Generalized Notification and Telemetry Carrier Input to OIF: Help Bring T-API to the Market Interoperability Testing of TAPI 2.0 Implementations Potential Certification

17 SDN Transport API Interop Demo Resources and upcoming events Press release, 14 February, 2017 Light Reading webinar, 15 March see the replay at: OIF SDN T-API Interop Demonstration Results Technical white paper and Executive summary paper download at

18 Thank You!