The document summarizes findings from testing the ONF Transport API (T-API) across multiple transport network domains. Key findings include: - T-API is aligning with RESTCONF best practices and incorporating MEF extensions to support additional use cases. - Notifications need further formalization to support multi-domain restoration. - Additional testing identified areas for performance improvements and clearer error reporting. - The demonstration showed cooperation across multiple companies and identified strengths and areas for T-API to continue evolving.

1. Open Transport API for Interoperable
Optical Networking
Oscar Gonzalez de Dios
12th October 2018
SDN/NFV World Congress
Open
Networking
Foundation
www.opennetworking.org www.mef.netwww.oiforum.com

2. Agenda
• Motivation
• Objectives
• Overview of Tests
• Findings and Summary
2

3. Motivation
• Operators need flexibility and tools to fully utilize the
potential of the optical transport networks
• SDN – the key to improve Transport Control
– Adapt Network Element Behaviour to Operator requirements
– Enables full automation
– Enables multi-domain scenarios
– Allows Vendor-agnostic network control
Programmability enables carrier requirements to be met
3

4. How can programmability be provided?
• Open APIs between SDN Components
Control
Components
Service Management
Connection
Management Routing Control
Path Query Topology
Signaling Proto Dataplane Config
Link Management
Discovery Routing Proto
Directory
Service Requests
Dataplane http://www.oiforum.com/documents/framework-for-transport-sdn-components-and-apis
4

5. ONF SDN Architecture
5
Application
Layer
Control Layer
Infrastructure Layer
Domain 1
NE NE NE
Domain 2
NE NE NE
Domain 3
NE NE NE
Multi-Domain
Controller
Domain
Controller
Domain
Controller
Domain
Controller
SBI
NBI
SBI
Cloud
Orchestrator
Compute Storage
NBI
SDN framework for multi-domain
operator networks
• SBI – SouthBound to NEs
• Standard config interfaces such
as OpenConfig
• Programmatic interfaces such as
OpenFlow and P4
• NBI – NorthBound from Control
Layer Elements
• Transport API
• Offers network abstraction
• Controller-agnostic

6. TAPI 2.0
6
NENESDN Controller
NENEApplication
Transport API
NE
Network Resource
Groups NENESDN Controller
Transport APISBIs (e.g. Openflow Optical)
Topology
Service
Connectivity
Service
Path
Computation
Service
Shared Network Information Context
Virtual
Network
Service
Notification
Service
OAM
Service
• Topology Service
• Connectivity Service
• Notification Service
•

7. • Evaluate current state of SDN in Transport industry
– Validate APIs in SDN Framework
• Useful:
– Do the defined API solve a business problem?
– Is the API consistent with business structural boundaries?
• Perform well:
– Would a different API improve performance?
• Can be implemented
2018 OIF Interoperability Demonstration:
SDN Transport APIs
7

8. OIF SDN Framework
8
Control
Components
Service Management
Connection
Management Routing Control
Path Query Topology
Signaling Proto Dataplane Config
Link Management
Discovery Routing Proto
Directory
Service Requests
Dataplane http://www.oiforum.com/documents/framework-for-transport-sdn-components-and-apis

9. • Participants from OIF, ONF and MEF
– OIF: ADVA, CenturyLink, China Telecom, Coriant, CTTC, Infinera, NEC/Netcracker, Nokia, SK Telecom, SM
Optics, Telefonica, Telus
– ONF: China Telecom, CTTC, Infinera, NEC/Netcracker, Nokia, SK Telecom, SMOptics, Telefonica, Telus
– MEF: ADVA, CenturyLink, China Telecom, Coriant, Infinera, NEC/Netcracker, Nokia, SM Optics, Telefonica, Telus
2018 OIF Interoperability Demonstration:
SDN Transport APIs
9
Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct
2017 2018
Tech Spec Start
Contract/NDA Test start Test end
Readouts
4Q OIF
ONF
1Q OIF OFC
ONS
2QOIF NGON 3QOIF
ECOC L123
Late Participation
Request
MEF
ONF
MEF MEF

10. 2018 Interoperability Demonstration:
SDN Transport APIs
10

11. • Telefonica Lab testbed.
• Three vendors participating:
Nokia, ADVA and Coriant.
• ONF TAPI 2.0.2 tested
individually in each domain.
• Topology, Connectivity and
Notification services tested.
OIF Copyright © 2016
2018 OIF Interoperability Event
Telefonica Lab Setup
S0001-1:
10.95.86.154
S0001-3:
10.95.86.156
S0001-2:
10.95.86.155
NOKIA_NODE_4:
172.30.15.123 /32
NOKIA_NODE_5:
172.30.15.122 /32
NOKIA_NODE_2:
172.30.15.121/32
ADVA_FSP300
0_196:
10.95.86.196
ADVA_FSP300
0_198:
10.95.86.198
ADVA_FSP300
0_197:
10.95.86.197
CORIANT | 10.95.86.157
NOKIA | 172.30.18.75
ADVA | 10.95.86.200
ADV.C.2
ADV.C.1
ADV.B.2
ADV.B.1
COR.B.1
COR.C.1COR.A.2
MX240-2|10.95.86.133 MX240-3|10.95.86.134
NOKIA_NODE_3:
172.16.15..91/32
NODO4/A2325A-1-15-
LINENODO5/A2325A-4-
2-LINEOMS
Link_5_1015002_3
_1015001
Link_3_1015002_5
_1015001
FSP3000_198[OL-2] ---
FSP3000_197
[OL-1]
FSP3000_196 [OL-1] ---
FSP3000_198
[OL-2]
FSP3000_196 [OL-1] ---
FSP3000_197
[OL-2]
Nokia NRC-T
IP: 172.30.18.75
Nokia NFM-T ADVA FSP
Network HyperVisor
IP: 10.95.86.200
CORIANT TRASCEND
Network HyperVisor
IP: 10.95.86.200
Telefonica SDTN
Controller
IP: 10.95.86.30
NODO2/AHPLG-2-14-
LINENODO-3/AHPLG-1-
6-LINEOMS
NODO2/AM2125A-2-3-
LINEOUT NODO5/
AM2125A-2-6-LINEIN OMS
NODO5/A2325A-2-14-LINE
NODO-3/A2325A-1-14-LINE
OMS
NODO4/AHPLG-1-6-LINE
NODO2/AHPLG-2-6-LINE
OMS

12. Test Cases summary
12
Topology Discovery API Test Cases
The following set of test cases are specific to the TAPI support of Topology Service. The set of
test cases examine basic topology retrieval from ICM Client (i.e., SOF) to ICM.
Test Case Test Description Result
Topology.1.1 Retrieval of Context Object-details
Topology.1.2 Retrieval of collection of Topology object-references.
Topology.1.3 Retrieval of Topology object-details.
Topology.1.4 Retrieval of a collection of Link object-references
contained in a specific Topology.
Topology.1.5 Retrieval of a collection of Node object-references
contained in a specific Topology.
Topology.1.6 Retrieval of Link object-details.
Topology.1.7 Retrieval of Node object-details.
Topology.1.8 Retrieval of a collection of NodeEdgePoint object-
references contained in specific Topology and Node.
Topology.1.9 Retrieval of NodeEdgePoint object-details.
Connectivity Service Request API Test Cases
The following set of test cases are specific to the TAPI support of Connectivity Service. Both
unconstrained and constrained service provisioning test cases are provided.
Test Case Test Description Result
Unconstrained Single Domain Provisioning
ConnSvc.1.1 Retrieval of Service End Point List.
ConnSvc.1.2 Retrieval of Service End Point Attributes.
ConnSvc.1.3 Connectivity Service Activation.
ConnSvc.1.4 Retrieval of Connectivity Service and Attributes.
ConnSvc.1.5 Retrieval of Connection(s) and Connection attributes.
ConnSvc.1.6 Update of Service Capacity.
ConnSvc.1.7 Deletion of Connectivity Service.
ConnSvc.1.8 Retrieval of Connection End-points and Attributes
Test Case Test Description Result
Constrained Single Domain Provisioning
ConnSvc.2.1 Create Redundant Service (Disjoint path).
ConnSvc.2.2 Create Connection with SRG parameter (Disjoint links)
ConnSvc.2.3 Create Connection with SRG parameter (Disjoint nodes)
ConnSvc.2.4 Create Connection excluding a list of links (Disjoint links)
ConnSvc.2.5 Create Connection excluding a list of nodes (Disjoint
nodes)
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
60.00%
70.00%
80.00%
Vendor A Vendor B Vendor C
%Test
Summary Telefonica Lab results
Not
Compliant
(NC)
Not Tested
(NT)
Fully
Compliant
(FC)
Notification API (Resiliency) Test Cases
The following set of test cases are specific to the TAPI support of Notification Service.
Specifically examined with Notification Service is the ability to support resiliency.
Test Case Test Description Result
Resilience
Resilience.1.1 MD-Controller creations connection with restoration.
Resilience.1.2 MD-Controller creates connection with 1+1.
Dynamic Topology State Notifications
Notify.1.1 Noticeable changes of state after failure conditions.
Notify.1.2 Noticeable changes of state after maintenance conditions.
Notify.1.3 Noticeable changes of state after creation of connectivity
(e.g., change in Link capacity, state, etc or client-layer
Link Creation).
Notify.1.4 Noticeable changes of state after deletion of connectivity
(e.g., change in Link capacity, state, etc. or client-layer
Link Deletion)

13. Changes since 2016 to be tested
• Alignment with updates to IETF RESTCONF Best Practices
– Separation of config and operational data
• Further formalization of Notification
– Prototype in T-API 1.0
• Addition of Ethernet Connectivity Service
– Incorporation of MEF NRP
• Additional attributes for service requests
– New resilience types (1+1 Protection, 1+1 w/ Reroute, etc.)
– Additional constraints (SRG)
13

14. Use Case - Multi-domain orchestration
Service provider equipment is in different domains
• Different Geographies
• Different Vendors
• Different Technologies
Service request is decomposed to separate invocation on each domain
Service Request
Pre-established Links
Dynamically
established Links
Service Layer (e.g. Ethernet)
Lower Layer (e.g. ODUk)
Connection
Ca Cb
Cs
Cc
14

15. Use Case - Multi-domain reroute
Service reroute may fail if a reroute is limited to a single domain. Allowing the service layer controller to
invoke alternate connection(s) in other domains may restore the service.
Pre-established Links
Dynamically
established Links
Service Layer (e.g. Ethernet)
Lower Layer (e.g. ODUk)
Connection
Requires notifications from domain controller to service controller
15

16. FINDINGS
16

17. Findings
• ONF’s alignment of T-API with IETF RESTCONF is a good start
– Provides developers access to RESTCONF tool environment
– Some additional alignment changes still required (addressed in T-API 2.1)
• MEF’s extensions to T-API for LSO Presto and Ethernet are necessary
extensions to meet operator requirements for T-API
• Additional use cases are supported by the formalized notifications interface
– Multi-domain/Multi-layer Reroute
– Network reoptimization
• Swagger definitions can aid automated testing
– Specifies behavior of request and response
17

18. Findings
• Controllers abstract the network in different ways
– E.g. Unidirectional vs Bidirectional links
• Controllers provide/report different capabilities
– E.g. Connectivity restrictions
• Division of responsibility between controllers unclear
– E.g. Multi-domain Path Computation
• Additional use cases exist and need to validated
– Use of topology interface for Path Computation
– Service Management interface
18

19. Findings
• Restoration control evolution required
– Need extensions for operations control for rerouted services
(Forced reroute, Freeze, Make Permanent, Restoration scheduling)
• T-API evolution is required to increase performance
– Reduce number of API operations required when following relations between
tables
– Remove need for bulk retrieval to follow some relations
– Architecture description for notification hub
• Better error reporting required across interface
– HTTP result codes (e.g. 20x, 40x) do not provide enough clarity
19

20. Summary
• Demonstration shows:
– Cooperation between 12 companies
• 5 Service providers(4 Host, 1 Consulting)
• 6 Vendors
• 1 Research Institutions
– Transport SDN APIs are evolving
• Additional capability added to APIs meeting additional service provider requirements
– Testing is a success
• Identified strengths and areas for further activity
• Next step:
– T-API 2.2
20

21. Acknolwledgment
• Part of the work carried out in Telefonica lab was
funded by EU-H2020 Metrohaul project (grant no.
761727).
21