SDN Transport API Interop Readout for NGON 2018

1. 2018 OIF Interop Demonstration
SDN Transport APIs
Jonathan Sadler (Coriant)
Interop Working Group Chair
OIF Technical Committee
Open
Networking
Foundation
www.opennetworking.org www.mef.netwww.oiforum.com

2. Agenda
• Motivation
– OIF, ONF, MEF
• Objectives
• Overview of Tests
• Deep Dive into API messaging
– Topology
– Connectivity Service
– Notification
• Findings and Summary
2

3. SDN improves Transport Control
• Eliminate “One-size-fits-all” solutions
– NE-behaviors may not match carrier requirements
– Example
• Combined Reroute and Protection
Programmability enables carrier requirements to be met
400% Capacity use
50ms protection all the time
300% Capacity use
50ms protection switch first fault
~300ms switch second and subsequent
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. ONF TAPI Work
6
• Developed in the Open Transport Config & Control Project (OTCC)
• Based on the ONF Common Information Model (CIM) – TR-512
• Pruned and Refactored for transport networks
• Models multiple technologies, transitional links
• Recursive hierarchical structure
• Transport API (TAPI)
• Utilizes open source methods
• Open calls and discussions
• Focus on data models and software implementation
• Uses ONF Tooling for automated mapping of UML to YANG to JSON
• Key product is SDK on ONF open source project github site
• Includes UML, YANG, JSON schema and Python reference code
• https://github.com/OpenNetworkingFoundation/TAPI
Functional
Requirements
Information Model
(UML in Papyrus)
Data-Schema
(JSON/YANG)
API Code
Purpose-specific Use
cases

7. TAPI 2.0
7
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
•

8. e.g.: Dynamic L1 Connectivity Service
portal
Service provider
WAN
controller
Business Applications
Service Orchestrator
LSO Adagio
LSO
Allegro
LO
Cantata
LSO Legato
LSO Presto
service
realization
subscriber
intent
Service Orchestration Using MEF LSO Paradigm

9. e.g.: Multi-Operator CE Service
Business
Applications
Service
Orchestrator
Business
Applications
Service
Orchestrator
Service provider Access Provider
LSO
Sonata
LSO
Interlude
portal
Across Multiple Operator Domains
service
realization
subscriber
intent

10. Business
Applications
Service
Orchestration
Functionality
Business
Applications
The LSO Reference Architecture
LSO
CANTATA
(CUS:BUS)
Customer
Domain
SP
Domain
Partner
Domain
customer
application
coordinator
CUS: Customer Application Coordinator
BUS: Business Applications
SOF: Service Orchestration Functionality
ICM: Infrastructure Control and Management
ECM: Element Control and Management
LSO
ALLEGRO
(CUS:SOF)
LSO SONATA
(BUS:BUS)
LSO
INTERLUDE
(SOF:SOF)
LSO LEGATO
(BUS:SOF)
Infrastructure Control
and Management
LSO PRESTO
(SOF:ICM)
Service
Orchestration
Functionality
Infrastructure Control
and Management
LSO LEGATO
(BUS:SOF)
LSO PRESTO
(SOF:ICM)
Element Control and
Management
Element Control and
Management
LSO ADAGIO
(ICM:ECM)
LSO ADAGIO
(ICM:ECM)
ENNI
Network Infrastructure Network Infrastructure

11. MEF- Defined Subscriber Layer 1 Connectivity Service
SA Service Attribute
SN Subscriber Network
UNI1 ID
Physical Layer1: (p, c, o)
Client protocol
Coding function
Optical Interface function
L1VC End Point ID1
L1VC End Point UNI1
Subscriber L1VC SAs
Subscriber L1VC ID
Subscriber L1VC End Point List
Subscriber L1VC SLS: (ts, T, PM)
Metrics: Delay, ES, SES, UAS, Availability
UNI2 ID
Physical Layer2: (p, c, o)
Client protocol = UNI1 (p)
Coding function = UNI1 (c)
Optical Interface may differ
L1VC End Point ID2
L1VC End Point UNI2
Subscriber L1VC End Point
SN SN
UNI 1 UNI 2
Service Provider
Network
Subscriber L1VC
UNI2 SAsUNI1 SAs
Subscriber L1VC End Point2 SAs
Subscriber L1VC End Point1 SAs

12. • Collaboration between OIF, ONF and MEF
– OIF – Optical and Transport Networks
• API Framework
• Prototype API experience – 2014 & 2016 Interop Demonstration events
– ONF – SDN
• SDN Architecture
• Transport API Project
– MEF – Service Management
• Lifecycle Service Orchestration
• Connectivity Service Specifications (Ethernet, Layer 1)
2018 OIF Interoperability Demonstration:
SDN Transport APIs
12

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

14. OIF SDN Framework
14
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

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

16. Timeline
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
16

17. 2018 Interoperability Demonstration:
SDN Transport APIs
17

18. Pairings
• Lab A
– Orchestrators: Vd
– Dataplane: Vb1, Vb2, Vc
• Lab B
– Orchestrators: Cb
– Dataplane: Va, Vb, Ve
• Lab C
– Orchestrators: Cd, Ve
– Datraplane: Ve, Vf
3 pairings
3 pairings
4 pairings
27 Pairs 18

19. Test Tracking
19

20. 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)
20

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

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

23. INTERFACES IN ACTION
23

24. Topology API Capture
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json
Date: Tue, 12 May 2018 4:41:37 GMT
Connection: close
[
"/restconf/config/context/topology/1e771577-25bb-3e60-b332-7942adf878db",
"/restconf/config/context/topology/711ed90c-9360-3a51-8106-7099f0df8bad"
]
NE
NE
NE
GET /restconf/config/context/topology HTTP/1.1
Accept: application/json
Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
24

25. Topology API Capture
NE
NE
NE
GET /restconf/config/context/topology/1e771577-25bb-3e60-b332-7942adf878db HTTP/1.1
Accept: application/json
Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
25

26. Topology API Capture
HTTP/1.1 200 OK
Content-Type: application/json
Server: Werkzeug/0.11.11 Python/2.7.5
Date: Tue, 12 May 2018 5:23:07 GMT
{
"name": [
{
"value": "mTera_cluster“,
"value-name": "DOMAIN_NAME",
}
],
"uuid": "1e771577-25bb-3e60-b332-7942adf878db “,
"layer-protocol-name": [
"DSR",
"ODU",
"OTSiA",
],
"link": [
… // 15 links reported
],
“node": [
… // 4 nodes reported
]
}
NE
NE
NE
26

27. Service Invocation Flow
POST /restconf/config/Context/_connectivityService/ HTTP/1.1
Accept: application/json
Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
{
"uuid": "MEF_Prov_Test",
"_connConstraint": {
"requestedCapacity": {
"totalSize": "10GBPS“
},
"serviceType": "POINT_TO_POINT_CONNECTIVITY",
"serviceLayer": [
"ODU“
]
},
"_servicePort": [
{
"localId": "sp1",
"serviceLayer": "ODU",
"direction": "BIDIRECTIONAL",
"role": "SYMMETRIC",
"_serviceEndPoint": "network=mynet-L1-test2:node=MA4513080110:ep=(type=ODU2&chassis=1&shelf=A&slot=2&subslot=T3&port=4)“
},
{
"localId": "sp2",
"serviceLayer": "ODU",
"direction": "BIDIRECTIONAL",
"role": "SYMMETRIC",
"_serviceEndPoint": "network=mynet-L1-test2:node=MA4513120153:ep=(type=ODU2&chassis=1&shelf=A&slot=2&subslot=T3&port=4)“
}
]
}
NE
NE
NE
27

28. Notification RegistrationsPOST /restconf/config/context/notif-subscription
Accept: application/json
Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
{
"uuid": "171d1209-ed66-4f84-ab46-dd121ee05624",
"notification-channel": {
"next-sequence-no": 0,
"stream-address": "wss://10.206.156.42:12443/tapi/restconf/streams/notification/171d1209-ed66-4f84-ab46-dd121ee05624"
},
"subscription-filter": {
"name": [
{
"value": "AllNotifAndObjectTypes",
"value-name": "NOTIF_SUBSCRIPTION_NAME"
}
],
"include-content": true,
"requested-notification-types": [
"OBJECT_CREATION", "OBJECT_DELETION", "ATTRIBUTE_VALUE_CHANGE"
],
"requested-object-types": [
"TOPOLOGY", "NODE", "LINK", "CONNECTION", "CONNECTIVITY_SERVICE", "NODE_EDGE_POINT", "SERVICE_INTERFACE_POINT"
]
},
"subscription-state": "ACTIVE",
…
NE
NE
NE NE
NE
NE
28
NE
NE
NE

29. Notification Registrations"supported-notification-types": [
"OBJECT_CREATION", "OBJECT_DELETION", "ATTRIBUTE_VALUE_CHANGE"
],
"supported-object-types": [
"TOPOLOGY", "NODE", "LINK", "CONNECTION", "CONNECTIVITY_SERVICE", "NODE_EDGE_POINT", "SERVICE_INTERFACE_POINT"
]
}
NE
NE
NE NE
NE
NE
29
NE
NE
NE

30. Notification Event
{
"uuid": "75b95bcf-fc04-443f-807b-bb9f0e434404",
"changed-attributes": [{
"new-value": "DISABLED",
"old-value": "ENABLED",
"value-name": "operational-state"
}],
"event-time-stamp": "2018-06-10T10:09:28.014",
"notification-type": "ATTRIBUTE_VALUE_CHANGE",
"sequence-number": 1,
"target-object-identifier": "/restconf/config/context/service-interface-point/adb8c5da-e0c5-36cb-ad5f-bd12144b82e0",
"target-object-name": [{
"value": "SIP_PTP_1_20150001",
"value-name": "TRI"
}, {
"value": "10_GBE_LAN",
"value-name": "SIGNAL_TYPE"
}],
"target-object-type": "SERVICE_INTERFACE_POINT"
}
NE
NE
NE NE
NE
NE
30

31. FINDINGS
31

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

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

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

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

36. 2018 OIF Interoperability Demonstration: SDN Transport APIs
Accelerating Momentum on the Road to Next-Generation Architectures
www.opennetworking.org www.mef.netwww.oiforum.com
“Transport API: Standardization status,
interoperability tests and use cases”
Juan Pedro Fernandez-Palacios
Keynote: June 27, 9:15