Meridian

Meridian: An SDN Platform for cloud networking services Guided by, Savitha Murthy Assoc. Prof, Dept., Of CSE, PESIT.

Presented by, Akshitha.H.M I sem, MTech, CSE, PESIT.

Introduction  Today’s

enterprise information technology environments must be highly responsive and agile n order to support rapidly changing business requirements .  Cloud computing platforms offer a new IT consumption model that enables enterprises to procure computing resources on an asneeded basis and delegate management of the infrastructure to the cloud service provider.  The number and variety of applications moving to cloud grows, cloud service providers have expanded their offerings to include a variety of services beyond 1. basic virtual servers 2. storage volumes 3. network connectivity

 Commercial cloud platforms today supports variety of

1. Server types (processing with GPU). 2.Multiple Storage Models (object, block). 3.Virtual Network.  Cloud networking features have developed recently . ex: 1). Amazon’s AWS - IP connectivity to VPC 2).Openstack - Quantum

 AWS and Openstack -network or device centric cloud networking

models. -users must configure --switches, subnets, ACL’S -used by their cloud applications to create virtual topology  This model mimics the traditional nature of IT management .

 In cloud - managing the network

- virtualized version - functions as the physical network  Service level model of cloud networking  Emergence of SDN - integrate application provisioning in the cloud with the network through programmable interfaces and automation.

 Hence, this describes the architecture and implementation

of Meridian ,an SDN controller platform that supports a service level model for application networking in clouds.

 It also describes some of the challenges in design and

implementation including how to efficiently handle dynamic updates to virtual networks, orchestration of network tasks on a large set of devices, and how meridian can be integrated with multiple cloud controllers.

Traditional Computer Networks Data flow is controlled by switches and routers and contains the following basic elements:

 Data Forwarding plane: Packet streaming

 Control plane: Routing algorithms

 Management plane: Configure basic activities

Introducing Software-Defined Networking Software Defined Networking (SDN) is an emerging network architecture where network control plane is decoupled from forwarding plane and is directly programmable

•Lead by Open Networking Foundation(ONF) •SDN-enabled control plane allows the underlying infrastructure to be abstracted •Network appears to the applications as a single, logical switch entity

APPLICATION LAYER CONTROL LAYER

Business Appl Business Appl Business Appl Northbound API SDN CONTROL SOFTWARE

Southbound API(eg. OpenFlow)

INFRASTRUCTUR E LAYER

OpenFlow Switches

Meridian SDN Cloud Networking platform Architecture

 It is organized as three main logical

layers 1).Network model and API 2).Network Orchestration 3).Network driver layer

Abstract API layer •Present application with a network model •Associated APIs that expose only the information needed to interact with the network •Logical view of the network using high-level APIs

Network Orchestration platform •Logical-to-physical translation of commands issued through the abstraction layer. •Convert API calls into the appropriate series of commands on the underlying network •Network-wide service to application. ex: Topology view, notification of changes in link availability. •Path computation according Different routing algorithms •Global annotated view of the data center topology for applications •Planner module that can schedule network configuration or control task

Network driver layer  Consists of plug-in or drivers





 

enable the controller to interface with various network technologies or tools. The orchestration layer uses these drivers to issue commands on specific devices or collect information from the network. Meridian-Implemented a logical driver that interfaces to OpenFlow devices. Drivers to enable virtual network creation Topology data gathered

Meridian implementation  Meridian prototype is build on the open source floodlight controller

platform.  Floodlight is a modular java based (OpenFlow controller) that provides OpenFlow protocol support and a number of services such as (1). Basic link discovery. (2).Routing for open-flow enabled switches.

• Extending Floodlight’s native support, and some new modules to

implement the meridian architecture.

Meridian network Abstraction Model •This model allows users to think of networking in terms of logical topologies for their cloud-based applications. •Meridian provides a service-level network model for users to specify logical connectivity and policies or services associated with the virtual links between VMs. • In the Meridian network service model, five types of entities are defined: 1).

Application

2.)

Middleware OS VM Endpoint (VNI,VM)

Group( same connectivity properties)

3.)service : entity- services on a connectivity path. example : users can define a customized routing policy. 4). segment: To specify the connectivity path between two groups, -defined by a 3- tuple: {g1, g2, svc} -g1and g2 are the endpoint groups -svc is the requested network service(s) (bidirectional virtual link) Segment

Service

(Attaching services to segment)

5).virtnet:

A virtual network is a logical topology containing groups, segments, services. -It is represented by VN = {G, S} -G is a set of endpoint groups -S is a set of segments defined on G. -Each segment in S is an edge defined by two endpoint groups {g1, g2 ŒE G} and annotated with a specified service svc.

• Using these entities, users can construct a variety of connectivity topologies among VMs belonging to different applications. • Typical enterprise web service applications have a three- tier topology that consists of a 1).web server tier 2).application server tier 3).database tier. • The communication between different tiers often has different service requirements. Ex: restricted communication between tiers using firewall.

•Figure shows an example for a multi-tier web application with six VMs grouped into tiers with segments connecting them. •The segments have been defined with various services such as middlebox traversal or scoped broadcasting. • This model can be used to flexibly construct topologies for many different types of applications.

Meridian Rest API’s:  Floodlight exposes its services to applications using REST APIs in

which applications use standard HTTP requests to send or receive JavaScript Object Notation (JSON) formatted data.  Meridian virtual net- work functionality is implemented in a separate

    

Floodlight module that provides commands for creating, deleting, configuring, and updating individual 1)instances (e.g., a specific group or segment). 2)collections (e.g., the set of all segments in a virtual network) of network entities using corresponding URLs. Instance  (key ,value). Post  to create instance. Put  to modify instance. Adding field to instance  add (key, value) pair. Meridian  commands to validate, install and uninstall virtual network entities.

Orchestrating the Deployment of network services in Meridian  Primary components in meridian’s orchestration layer are the

planner and deployer modules that specify and deploy network tasks.  Meridian planner design : 1).Meridian implements Network services one or more plans. Plans are executed to perform the task. oprtnapp ex: Putclient Virtual network Validate / Install it 2.)Planner

module functions as Scheduler.

3.) Plans

Planner Module Posted(to be executed) Pool of threads for Scheduling Plans

It contains intelligence to complete the task

4.) 5.)

A plan can start an other plan just posting them for planner. Plans can be executed in parallel .This helps in configuring switches in parallel rather start than one at a time. 6.) plan1

Reply

plan2.

7.)Composability of plans  continually grow set of available plans. 8.)This approach is in contrast to providing a single monolithic orchestrator module that contains a single optimization program that provides all the services difficult to extend .

 Combining simple plans into more sophisticated plans led us

to categorizing plans into two types

High level plans 1). They work well with meridian service model instances such as virutal ntws,grps,endpts. 2).ex: they may compute set of paths.

Low level plans 1). They perform low level actions and work with existing ntw objects. 2).ex: they may generate associated OpenFlow rules for those paths from higher plans.  This provides a level of separation and flexibility.  High and low level plans can be extended.  Time based scheduling

Deploying plans in the network  The planner manages the execution and state of Meridian plans.  Specifically, it processes a number of methods that are part of

each plan as described below:  validate() : 1).error checks to determine if installation of the plan is likely to succeed. 2).creates the list of network commands (e.g., OpenFlow rules).  install():

installs the model into the physical network .

 undo(): reverses the install operations per- formed by

the install().  resume(), suspend(): resumes and suspends execution of the plan

Meridian virtual networks with OpenFlow  Given a virtual network topology defined .  Meridian realizes each OpenFlow rules installing

• Implementing various routing policies on the segment Support (ex:shortest path routing)

SERVICES

• To implement a given segment {g1,g2,svc} 1) first locate the attachment points of each endpoint in g1 and g2 using meridians topology service .

 Major challenge : To update dynamic updates to Virtual

network

topology ex: 1)adding /removing segment. 2)adding ep1 to existing grp. 3)Changing svc for a segment.  So Meridian maintains control block for each virtual

network.  Virtual network control block : it keeps record info of the

network

installation operations for virtual network during its life cycle.

Cloud controller Integration  Integrating Meridian with cloud orchestration platforms.

Although these platforms required different approaches for integration  They demonstrate Meridian’s ability to offer a uniform set of

service APIs to multiple higher-layer cloud provisioning systems.  Openstack integration with quantum:

1). open source cloud computing platform. 2). Three major components:

compute ,network, storage. 3).Networking component: Quantum 4).Quantum : pluggable, extendable, API driven

5).It is part of cloud OS which manages and creates network required by cloud apps. 6).Meridian developed quantum plug-in  maps quantum constructs to meridian network model. 7).when quantum network is created ,a meridian virtual network is created with empty group and segment enabling all to all communication within the group. 8).than virtual network is installed.

9).quantum virtual ports  endpoints added to group. 10). This allows quantum network manager component to work with Meridian using Standard API’s.

Summary  Meridian, an SDN-based controller framework

for cloud networking.  A network service model for users to construct and manage logical topologies for their complex workloads.  Current system is only an initial prototype.

Future work  Performance

 Recovery failed plans

Reference  [1] “Openstack cloud software ,”

http://www.openstack.org.  [2] “Cloud Naas: A Cloud Networking Plat- form for Enterprise Applications,” Proc. ACM Symp. Cloud Computing, Oct. 2011.  [3] S. Shenker et al., “The Future of Networking, and the Past of Protocols,” slides at http://www.slideshare.net/martincasado/sdnabstractions, June 2011.  [4]Open Networking Foundation, “SoftwareDefined Net- working: The New Norm for Networks,” white paper, Apr. 2012.