Dynamic Connectivity Setup in Multi-Site Network Services

OSM Release 5 Feature 5945 OSM Release 5 Feature 5945 Enable dynamic connectivity setup in multi dynamic connectivity setup in multi- -site Network Services Network Services Enable site June 7, 2018 METRO-HAUL: METRO High bandwidth, 5G Application-aware optical network, with edge storage, compute and low Latency H2020-ICT-2016-2 Metro-Haul Grant No. 761727 http://metro-haul.eu

Feature 5945 recap Feature 5945 recap Feature description: https://osm.etsi.org/gerrit/#/c/5945/4/Release5/Enable_dynamic_connectivity_setup_in_multi- site_Network_Services.md Proposed in OSM#5-F2F Louisville Feature summary: Automate inter-DC network creation through a WIM (WAN Infrastructure Manager) that will cover not only the WAN deployments, but also will be extended to transport networks in general. Transport Networks are expected to be SDN controlled in the future. Several alternatives emerging as candidate for for Transport Network SDN NBI (ONF TAPI, IETF NBI models, etc) Feature objective is to extend OSM with a plugin model for integration of different types of WIM connectors (implementing different types of SBIs to the Transport Network) that can be invoked whenever OSM has to instantiate a Network Service that spans several sites

Functional modules Functional modules RO WIM connector VIM A VIM B WIM SDN Controller Compute node B1 Compute node A1 Switch A1 Switch B1 Spine switch Spine switch WAN Switch A2 Switch B2 Compute node B2 Compute node A2 Demarcation point Demarcation point Datacenter A Datacenter B WAN Service Provider

Feature 5945 assumptions Feature 5945 assumptions Assumption #1: WIM connector thread is part of the RO, and it starts as soon as RO starts WIM connector thread has its own tables as part of the RO database that store: WIM API access information (IP address, port, authentication method, credentials, etc) All WIM related physical port mappings in the demarcation points between NFVI ports in the different DCs and the corresponding WAN service endpoints Assumption #2: WIM provides a single point of contact for a specific WAN network to OSM WIM provides an abstraction of the underlying WAN network to OSM via exposed Service Endpoints. Different levels of abstraction can be provided as needed by OSM and agreed with WAN service provider (big box abstraction vs full topology exposure) A hierarchy of SDN controllers could be in place in the WAN service provider (to cope for different technological segments or different administrative domains making up the whole specific WAN network), but that is not visible to OSM Several WIMs can be required if: The connectivity between different DCs involved in a Network Service is achieved over different WAN networks (e.g. for availability or for Network Services spanning more than 2 DCs). This case can be in scope of Feature 5945, but is not the focus of first implementation The connectivity between 2 DCs crosses several WAN networks that do not share a common upper WIM (e.g. 2 different WAN providers). In that case, OSM would have to do the stitching of the connectivity service over each WAN. This case is in principle out of scope of Feature 5945 (not even considered in ETSI IFA 022).

Feature 5945 initial focus (Phase I) Feature 5945 initial focus (Phase I) Assumption #3 (Phase I): Focus on single WIM case (with potential multiple underlying SDN controllers in a hierarchy) Assumption #4 (Phase I): WIM provides a single-node topology abstraction to OSM Only the relevant service endpoints are known to OSM WAN Path computation is out of OSM scope Assumption #5 (Phase I): WAN connectivity is limited to Layer 2 VLAN-based Point-to-Point connectivity with VLAN translation Similar to an MEF Ethernet Virtual Private Line (EVPL) service Assumption #6 (Phase I): First WIM connector to develop will be ONF TAPI based Still under study if standard TAPI is enough or if it is required a MEF-extended TAPI (to account for VLAN information to be passed to/from the WIM and have the WAN perform the VLAN translation) Assumption #7 (Phase I): At least bandwidth required in the WAN connectivity will be specified Other parameters could be present in future implementations (delay, redundancy, etc)

Feature 5945 Phase I example use case Feature 5945 Phase I example use case RO WIM Connector VIM A VIM B WIM (SDN Controller) Transport switch B + Port P Transport switch A + Port N Register external port with WIM Compute node A1 Compute node B1 SDN assist SDN assist Spine switch YB YA Switch XA Compute node A2 Compute node B2 WAN Domain VLANs VLANs DC internal network DC internal network Connectivity provisioned by WIM

Sample high level workflow Sample high level workflow SDN RO WIM Controller AddWIM AddPortMapping Deploy NSD Detect inter-DC VLD Create_nw bw endpoints Create_nw Done Done Network created

Code design Code design Similar to the VIM connector, a generic WIM connector class will be created as an abstract class with specific underlying implementations for different kinds of WIMs In addition to the abstract class, specific WIM connectors (children of the abstract WIM connector) will use APIs of WIM to instantiate connectivity between service endpoints A specific WIM connector will be implemented to talk to an Onos-based controller with TAPI interface in Phase I