Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2018 OIF SDN T-API Readout 6.2018

118 views

Published on

SDN Transport API Interop Readout for NGON 2018

Published in: Technology
  • Be the first to comment

  • Be the first to like this

2018 OIF SDN T-API Readout 6.2018

  1. 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. 2. Agenda • Motivation – OIF, ONF, MEF • Objectives • Overview of Tests • Deep Dive into API messaging – Topology – Connectivity Service – Notification • Findings and Summary 2
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 17. 2018 Interoperability Demonstration: SDN Transport APIs 17
  18. 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. 19. Test Tracking 19
  20. 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. 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. 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. 23. INTERFACES IN ACTION 23
  24. 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. 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. 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. 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. 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. 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. 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. 31. FINDINGS 31
  32. 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. 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. 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. 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. 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

×