SDN orchestration and virtualization of heterogeneous multi-domain and multilayer transport networks in the STRAUSS project

Transcription

1 SDN orchestration and virtualization of heterogeneous multi-domain and multilayer transport networks in the STRAUSS project Raul Muñoz, Ricard Vilalta, Arturo Mayoral, Ramon Casellas, Ricardo Martínez Centre Tecnològic de Telecomuicacions de Catalunya (CTTC)

2 Project facts and consortium Project Facts Start Date: 1/6/2013 Duration: 36M EU Funding: 1.49 M JP Funding: 2.82 M EU CONSORTIUM CTTC (ES) ADVA Optical ing (DE), Telefónica I+D (ES) University of Bristol (UK) Fraunhofer HHI (DE) JP CONSORTIUM Osaka University KDDI R&D Laboratories Inc. Fujitsu Ltd. Contact: Raul Muñoz, CTTC Ken-ichi Kitayama, Osaka University Industrial Partners Research Centers Universities 2

3 Project Objectives The STRAUSS project focuses on the design, development and integration of: Highly integrated and scalable software defined optical transceivers supporting bandwidth variable multi-flows for flexible Ethernet transmission based on OFDM and DMT. Flexi-grid DWDM optical circuit switching node architectures for long haul transport. Cost/energy efficient and extremely fast-performing switching node architectures based on variable-capacity and fixed-length optical packet switching technology for access and aggregation networks, and OPS/OCS integrated interface. A virtualization layer for dynamic and on-demand partitioning of the optical infrastructure, offering virtual optical networks. Control plane architectures based on either legacy (e.g. GMPLS) and new (e.g. OpenFlow based) approaches for the control and management of virtual optical networks. A service and network orchestration layer for the interworking and coordination of heterogeneous control planes and transport technologies to offer end-to-end Ethernet transport services. 3

4 Detailed system architecture developed in the STRAUSS project Multi-domain Tenant A Multi-domain Tenant B Customer OpenFlow Customer OpenFlow Multi-domain Hypervisor Virtualization Planner Single-domain Tenant C OPS OpenFlow Multi-domain SDN Orchestrator OPS/OCS OpenFlow Active Stateful PCE Customer OpenFlow Single-domain Hypervisor Eth DMT Trans. OPS OPS/OCS interface HBR Trans Flexi-grid DWDM HBR Trans OFDM S-BVT Flexi/ Fixed DWDM OFDM S-BVT Eth Metro Aggregation Core Regional Metro 4

5 How to offer a transport network operating system for end-to-end services? SDN is based on a logically centralized architecture (control is decupled from data) featuring diverse technologies provided by different vendors controlled through standard interfaces. OpenFlow, the flagship protocol standardized by the ONF, offers a logical switch abstraction, hiding vendor-specific hardware details, and mapping high level instructions of the protocol. Ideally the same network controller may perform unified multi-technology and multi-vendor control SDN OF 1.3 OF 1.3 OF 1.3 OF 1.4 OF 1.4 OF 1.4 OF 1.0 OF 1.0 OF 1.0 Vendor C Vendor A Vendor A Vendor C Vendor B Vendor C Vendor B (Packet Transport ) Vendor B (e.g. WDM/Fleix-grid) Vendor A (Packet Transport ) 5

6 How to offer a transport network operating system for end-to-end services? But not realistic in transport networks operators fragment their transport networks into multiple vendor domains because transport equipment do not interoperate at the data plane level (only at the grey interface level) Each vendor offers its own control plane technology (SDN with proprietary extensions or legacy implementations) Why proprietary? Specific vendor-proprietary parameters are required to be configured. SDN Vendor A OF 1.3 OF 1.3 OF 1.3 PCEP, BGP- LS G/MPLS - PCE Control Plane Vendor B SDN Vendor C OF 1.0 OF 1.0 OF 1.0 PI specific interface for advanced configuration (e.g., SNMP), using the vendor s proprietary information model. (Packet Transport ) (e.g. WDM/Flexi-grid) (Packet Transport ) OpenFlow interface for basic switching configuration. 6

7 The STRAUSS approach: Multi-domain SDN orchestrator Multi-domain SDN orchestrator acting as unified transport network operating system composition of end-to-end provisioning services across multiple domains/layers regardless the control plane technology of each domain. Based on the Application-Based Operations (ABNO) defined by IETF using standard building blocks. Two different operating ways have been analyzed and evaluated: 1) Physical network topology and Centralized Path Computation (PDP OFC 2014). 2) Abstracted network topology and Distributed Path Computation (ECOC provisioning, ECOC recovery). Multi-domain SDN orchestration OF 1.3 SDN Vendor A GMPLS/PCE Vendor B SDN Vendor C OF 1.3 OF 1.3 OF 1.0 OF 1.0 OF 1.0 (Packet Transport ) (e.g. WDM/Fleix-grid) (Packet Transport ) 7

8 STRAUSS Multi-domain SDN orchestrator Final architecture: PCE Topology Manager Provisioning Manager VNTM Flow Server OAM Handler Abstraction Manager Cognition Policer 8

9 The need for generic control functions and a control orchestration protocol The NBI of the domain controllers are typically technology and vendor dependent. The multi-domain SDN orchestrator shall implement different plugins for each of the controller s NBI. The STRAUSS project defines a generic functional model of a control plane that can be used regardless of a particular vendor, and defines the associated protocol (Control Orchestration Protocol - -) Multi-domain SDN orchestration Control Orchestration Protocol () (SDN) (GMPLS/PCE) (SDN) OF 1.3 OF 1.3 OF 1.3 OF 1.0 OF 1.0 OF 1.0 (Packet Transport ) (e.g. WDM/Flexi-grid) (Packet Transport ) 9

10 : Definition of YANG data models and RESTCONF protocol provides a research-oriented multi-layer approach using YANG models and RESTconf protocols: In line with OIF/ONF Transport SDN API. OIF/ONF Transport SDN API is focused on standardization efforts for orchestration of REST NBI for SDN controllers. definition: Topology (service-topology.yang): topological information about the network, which includes a common and homogeneous definition of the network topologies included in the TE Databases (TED) of the different control instances. Path computation (service-path-computation.yang): provide an interface to request and return Path objects which contain the information about the route between two Endpoints. Provisioning (service-call.yang ): Call/Connection separation. Common provisioning model which defines an end-to-end connectivity provisioning service. A draft definition is open for discussion and can be downloaded and contributed to at: 10

11 Integration of heterogeneous wireless and transport networks 5G services requires the integration of all network segments (radio/fixed access, metro and core) with heterogeneous wireless and optical technologies. enables the integration of multiple Radio Access Technologies (RAT) with heterogeneous control planes and technologies (5G, mmwave, LTE/LTE-A, Wi-Fi, etc.) E2E Orchestrator (parent) RAT1 RAT2 controller RAT2 RAT1 Core Transport 11

12 Multi-domain network virtualization for multitenant networks A network hypervisor is placed on top of the E2E network orchestrator using It is responsible for: The dynamic management of endto-end virtual network tenants in response to application demands Representing the abstracted topology of each virtual tenant network to the tenant SDN controller. SDN SDN Tenant1 SDN Tenant2 E2E Hypervisor SDN SDN Tenant OF OF OF E2E Orchestrator (parent) SDN Allowing the tenant SDN controller to control the virtual tenant network through a well-defined interface (e.g., OpenFlow protocol) 12 Core Transport 12

13 Hierarchical SDN Orchestration We have proposed a hierarchical orchestration approach with different levels of hierarchy (parent/child architecture) for scalability, modularity, and security purposes in multitechnology multi-domain heterogeneous wireless/optical networks Each successively higher level has the potential for greater abstraction and broader scope, and each level may exist in a different trust domain. can be used as the NBI of the child SDN orchestrator and as SouthBound Interface (SBI) of a parent SDN orchestrator in order to provision E2E services E2E Orchestrator (parent) Transport Orchestrator (child) Core Transport Core Transport 13

14 Peer SDN Orchestration In a multi-carrier scenario there's no hierarchy, no cross-domain control, no cross-domain visibility. It is reasonable that a peer interconnection model is needed. The Peer SDN model corresponds to a set of controllers, interconnected in an arbitrary mesh, which cooperate to provision end-to-end services. The controllers hide the internal control technology and synchronize state using East/West interfaces. can be used as the East/West interface. Transport Orchestrator (child) Transport Orchestrator (child) Core Transport Core Transport 14

15 Global orchestration of cloud and network resources A Global orchestrator acts as a unified cloud and network operating system enabling the dynamic management of the virtual cloud and network resources allocated to the specific tenants (slices) is a key enabler for the integration of cloud and network resources Virtual network resources Global cloud and network orchestrator (VIM) E2E Orchestrator (parent) Transport Orchestrator (child) Virtual computing and storage resoruces SDN Core DC cloud orchestrator Core Transport 15

16 Conclusions Transport networks are key to enable the deployment of 5G, but it is required to be integrated with all heterogeneous wireless networks and distributed cloud infrastructures. Two main challenges has been identified: A multi-domain network orchestration mechanism across heterogeneous multidomain wireless/optical networks to offer dynamic and flexible E2E connectivity and virtual network provisioning services An integrated orchestration of distributed cloud resources (virtual compute and storage) and network resources The definition of a generic functional model of a control plane for the provisioning of connectivity, topology dissemination and path computation, and of an associated protocol () between the domain controllers and the network orchestrator is key to address the required integration at network and cloud level. 16

17 Thank you! どうもありがとうございます Doumo arigatou gozaimasu Raul Munoz