Unlock the Benefits of Transport SDNOIF Transport SDN API Interop Demo
June 13th, 2017
Optinet China Conference 2017
Junjie Li, China Telecom ([email protected])
OIF Board Member
Agenda
• Motivation and Overview
• Key Findings
• Next Step
• Current OIF Works
www.oiforum.com 2
About the OIF
The Optical Internetworking Forum:
• Represents an end-to-end ecosystem membership base of 100+ members
• Accelerating market adoption and ROI for new technologies• OIF 100G DWDM work united the industry around a
100G framework and IAs for photonics, FEC and module MSA
• Electrical work defines critical backplane, chip and module interfaces for 100-400G
• Enabling interoperability in optical transmission networks, to create an open ecosystem• Implementation Agreements
• Large scale interoperability testing
• Certification
www.oiforum.com
Network
Operators
System
Suppliers
Transceiver
Suppliers
Component
Suppliers
www.oiforum.com 3
Optical Networks Transformation
• Proprietary, vendor-specific silos• Complex to operate across vendors and
technologies
Interoperable networks Open APIs to OSS/Apps End to end orchestration
OSS
Proprietary OS
Vendor X HW
Proprietary OS
Vendor Y HW
Proprietary OS
Vendor Z HW
from closed networks… …to open networks
OSS / Apps
Virtualized Multi-vendor Multi-
domain Network
open SW
open HW
Open APIsVendor-specific
management
systems SDN Control Infrastructure
Addressing optical control plane interoperability.
www.oiforum.com 4
The OIF and Transport SDN
Goal: accelerate commercial deployment by defining, testing and assuring interoperability of key network functions and interfaces
Work to date: Use cases and reference architecture Carrier requirements and framework 2014 interop demo – partnered with ONF, tested pre-standard ONF
OpenFlow extensions and APIs, led to ONF T-API specs
2016: OIF SDN Transport API Interoperability Demo • Validate specs in multi-layer, multi-domain environments in carrier
labs• Communicate findings – whitepaper, read-out events, liaisons
It’s all about interoperability
www.oiforum.com 5
OIF SDN Framework
ControlComponents Service Management
ConnectionManagement Routing Control
Path Query Topology
Signaling ProtoDataplane
Config
Link Management
Discovery Routing Proto
Directory
Service Requests
Dataplane
www.oiforum.com
Service RequestTopology
Focus of 2016Interop Event
6
2016 SDN Transport API Interoperability Demonstration
Accelerating Momentum on the Road to Next-Generation Architectures
OpenNetworkingFoundation
www.oiforum.com 7
2016 SDN T-API Interop Demo
8www.oiforum.com
Timeline
• Extensive preparation and testing
Test end
May Jun
2016
ONF Workday
Contract/NDA
Jul Aug
BCE
MarSep Oct Nov Dec Jan Feb
ECOC2016
3Q OIF 4Q OIF
L123 SDN
Test startReadouts
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)
www.oiforum.com 9
T-API modules tested
Source: ONF TR-527
www.oiforum.com 10
T-API modules tested (cont’)
• Topology Service– Retrieve most basic data about controlled network
– Abstract view of devices and connections
• Connectivity Service– Creation, List, Query, Retrieval, Deletion
– Multiple and programmable constraints
– Multi layers supported, ETH demoed
• Notification Service– Autonomous notification from the network of significant events
– Notification has proven higher efficiency than periodical polling
www.oiforum.com 11
2016 SDN T-API Worldwide Interop Topo
www.oiforum.com 12
Use Cases Tested
• #1: ESTI-NFV POC Demo
• #2: Multi-Domain Service Provisioning
• #3: Low Latency L0 Path across Metro/Regional Data Centers
• #4: Variable Bandwidth Paths across Core
www.oiforum.com 13
NFV POC Demo
Network controller for the WAN
• Architec tura l model:
• Multi-layered
• Multi-vendor doma ins
• Network Controller Model
• Hiera rchica l: E2E/ Doma in Netw ork
Contro ller
• NBI/ SBI: TAPI
Network elements in the WAN
• Optica l network Nodes
• Packet network Nodes
ETSI GS NFV-MAN 001 V1.1.1
The target scope for Interop
www.oiforum.com 14
Multi-Domain Service Provisioning
Applications: Multi-domain provisioning and recovery, packet/optical integration, NFV/network coordination
DomainController
South Bound Interface
Multi-Domain Controller
North Bound Interface
Domain Controller
Domain Controller
www.oiforum.com 15
Agenda
• Motivation and Overview
• Key Findings
• Next Step
• Current OIF Works
www.oiforum.com 16
Demo 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.
17www.oiforum.com
Findings – T-API• T-API provides functions necessary for multi-domain orchestration
– Topology view– Connection establishment– Topology abstraction
• T-API localizes interoperability to Orchestrator/Controller interface– GMPLS requires NEs in a sequence to have a consistent behavior in order to
achieve interoperability
• T-API supports multiple technologies– Ethernet– OTN– DWDM
www.oiforum.com 18
Findings - GAPS
• 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
• Maintaining RPC and REST styles is confusing– Not all implementations supported both styles
www.oiforum.com 19
Agenda
• Motivation and Overview
• Key Findings
• Next Step
• Current OIF Works
www.oiforum.com 20
Next Steps• T-API needs to be validated for additional use cases
– Use of topology interface for Path Computation
– Service Management interface
• T-API evolution is needed to meet current Transport Network uses
– Protected Services
– Generalized Notification Service
• Based on demo feedback, ONF will align T-API with YANG Best Practices
– Object ID format and lifecycle
– Separation of Configuration, Operational Data
www.oiforum.com 21
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
• Planning 2018 Interop Test
www.oiforum.com 22
Agenda
• Motivation and Overview
• Key Findings
• Next Step
• Current OIF Works
www.oiforum.com 23
Current OIF Works
• CFP2-DCO and CFP8-ACO
• CEI-56G and CEI-112G
• FlexE
• 400G ZR
• OIF VTNS Specification
• OIF Certification Project
www.oiforum.com 24
OIF UNI Certification ProjectFrom Testing to Certification
Issue to be solved : Multi-vendor interoperability of the optical control plane is still missing from commercial products, although various demonstrations have proven it is feasible.
Certification is a powerful tool to bridge the gap between technical standards and commercial implementations: it will provide a unique reference and a market advantage to compliant, interoperable products.
In line with its mission is to enable global interoperability in optical transmission networks, OIF surveyed the market and decided to create a certification program for interoperable products – starting with the Optical Control Plane UNI.
www.oiforum.com 25
www.oiforum.com
Thank You!
Technical White Paper and Executive Summary Paper ––Please download at www.oiforum.com
Top Related