oif sdn transport api nfv proof of concept
TRANSCRIPT
OIF SDN Transport APINFV Proof of Concept
May 4, 2017Layer 123 NFV World Congress
Lyndon Ong, Ciena ([email protected])OIF MA&E Committee Co-Chair
Agenda– NFV/SDN Relationship– Transport API– OIF Transport SDN Interop Testing – NFV PoC– Findings and Next Steps
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
3Programmability enables carrier requirements to be met
Supporting network programmability
4
• NFV and SDN Integration� 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 V1.1.1
The target scope in OIF
Transport SDN Model• Open API for network control is essential
5
MW Controller Optical Controller IP Controller
Multi-Domain Controller
Commontechnologicalmodels
TAPI Agent TAPI Agent TAPI Agent
OSS/App
Common abstraction model Transport API
Implementation of the MEF LSO Presto interface and subject of MEF work on Network Resource Provisioning API
Transport API Architecture
6
Topology Service
Connectivity Service
Path Computation
Service
Shared Network Information Context
Virtual Network Service
Notification Service
NENetwork Resource
Groups NENESDN Controller
NENESDN ControllerNENEApplication
Transport API
Transport API
SBIs (e.g. OpenflowOptical)
• 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
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 1.0.0 is packaged as 4 Eclipse sub-projects (https://github.com/OpenNetworkingFoundation/Snowmass-
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
7
Functional Requirements
Information Model (UML in Papyrus)
Data-Schema (JSON/YANG)
API Code
Purpose-specific Use cases
Topology Model
02.n
AA.2
A.3 A.5
A.4
A.2.3A.2.2
A.2.1
Network Control Domain Internal Service Provider Topology retrieves a detailed internal topology
B 0203
04
15
1718
19
22
Service Level Topology may only show Service Endpoints
A.101
11
1213
1416
01
A FwdingDomain (Node/Topology)LTP (Node Edge Point)
Link01.1 LTP (Service End Point)
01.1
01.n
02.1
20
21
2016 SDN T-API Interop Demo
9
Timeline• Extensive preparation and testing
10
Test end
May Jun2016
ONF Workday
Contract/NDA
Jul Aug
BCE
MarSep Oct Nov Dec Jan Feb
ECOC2016
3Q OIF 4Q OIFL123 SDN
Test start Readouts
OECC
2Q16 OIF
ETSI NFVMWC2017
1Q OIF OFC
2017
ONF Interim
Tech Spec Start
Proposed and accepted as an ETSI NFV PoC by ETSI TST WGSee http://nfvwiki.etsi.org/index.php?title=Mapping_ETSI-NFV_onto_Multi-Vendor,_Multi-Domain_Transport_SDN (Hiroshi Dempo, NEC, editor)
Transport SDN Interop Testing• Multi-vendor, Multi-layer, Multi-domain
11
L0 ROADM Controller
L1 OTN Controller
IP/Optical Controller
Child MD Controller
Commontechnologicalmodels
TAPI Agent TAPI Agent TAPI Agent
Parent MD Controller
Common abstraction model Transport API
Transport API
Topology CaptureHTTP/1.1 201 CreatedContent-Type: application/jsonServer: Werkzeug/0.11.11 Python/2.7.5Date: Tue, 12 Dec 2016 4:41:37 GMT{
"_linkPort": [{
"_nodeEdgePoint": "/restconf/config/Context/_topology/7a360591-5561-421f-abf2-4c48c4ab9d3e/_node/07d7ad4c-4214-4d98-8be8-4e6826cece43/_ownedNodeEdgePoint/37a03a6b-3e95-48bb-a253-fd5b3d2f597b/",
"direction": "BIDIRECTIONAL","localId": "lp13","role": "SYMMETRIC"
}, {"_nodeEdgePoint": "/restconf/config/Context/_topology/7a360591-5561-421f-abf2-4c48c4ab9d3e/_node/019ac632-20d6-4750-b77c-
80852ee60ed6/_ownedNodeEdgePoint/a4b58599-58af-4c38-862b-6c4a46ca9ec7/","direction": "BIDIRECTIONAL","localId": "lp31","role": "SYMMETRIC"
}],"_node": [
"/restconf/config/Context/_topology/7a360591-5561-421f-abf2-4c48c4ab9d3e/_node/07d7ad4c-4214-4d98-8be8-4e6826cece43/","/restconf/config/Context/_topology/7a360591-5561-421f-abf2-4c48c4ab9d3e/_node/019ac632-20d6-4750-b77c-80852ee60ed6/"
],"_state": {
"administrativeState": "UNLOCKED","lifecycleState": "INSTALLED","operationalState": "ENABLED"
},
NE
NE
NE
12
Service Invocation CapturePOST /restconf/config/Context/_connectivityService/Content-Type: application/json{"_servicePort": [{"_serviceEndPoint":"\/restconf\/config\/Context\/_serviceEndPoint\/tsdn:sm:script::2\/","direction": "INPUT","role": "ROOT"
},{"_serviceEndPoint": "\/restconf\/config\/Context\/_serviceEndPoint\/tsdn:adva:script::5\/","direction": "OUTPUT","role": "LEAF"
}],"_connConstraint": {"serviceType": "POINT_TO_POINT_CONNECTIVITY","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
}]
}
13
NE
NE
NENE
NE
NENE NE
Test Case tracking
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.
15
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
SDN Transport API Interop DemoResources 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 www.oiforum.com
