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. Learn how the OIF's interoperability demo is helping to bring T-API to market.

1. OIF SDN Transport API
NFV Proof of Concept
May 4, 2017
Layer 123 NFV World Congress
Lyndon Ong, Ciena (lyong@Ciena.com)
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
3
Programmability enables carrier requirements to be met

4. 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

5. Transport SDN Model
• Open API for network control is essential
5
MW Controller
Optical
Controller
IP Controller
Multi-Domain Controller
Common
technological
models
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

6. Transport API Architecture
6
Topology
Service
Connectivity
Service
Path
Computation
Service
Shared Network Information Context
Virtual
Network
Service
Notification
Service
NE
Network Resource
Groups NENESDN Controller
NENESDN Controller
NENEApplication
Transport API
Transport API
SBIs (e.g. Openflow
Optical)
• 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

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 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

8. Topology Model
02.n
A
A.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
17
18
19
22
Service Level Topology
may only show Service
Endpoints
A.1
01
11
1213
14
16
01
A FwdingDomain (Node/Topology)
LTP (Node Edge Point)
Link
01.1 LTP (Service End Point)
01.1
01.n
02.1
20
21

9. 2016 SDN T-API Interop Demo
9

10. Timeline
• Extensive preparation and testing
10
Test end
May Jun
2016
ONF Workday
Contract/NDA
Jul Aug
BCE
MarSep Oct Nov Dec Jan Feb
ECOC
2016
3Q OIF 4Q OIF
L123 SDN
Test start Readouts
OECC
2Q16 OIF
ETSI NFV
MWC
2017
1Q OIF OFC
2017
ONF Interim
Tech Spec Start
Proposed and accepted as an ETSI NFV PoC by ETSI TST WG
See http://nfvwiki.etsi.org/index.php?title=Mapping_ETSI-NFV_onto_Multi-Vendor,_Multi-
Domain_Transport_SDN (Hiroshi Dempo, NEC, editor)

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

12. Topology CaptureHTTP/1.1 201 Created
Content-Type: application/json
Server: Werkzeug/0.11.11 Python/2.7.5
Date: 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

13. 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

14. Test Case tracking

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.
15

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
www.oiforum.com

18. www.oiforum.com
Thank You!