Network Abstractions at Different Layers of the Stack

Mohammad BanikazemiNovember 2013

IBM Research

Outline Network Abstractions at Different

Layers Neutron: The OpenStack Networking Application-centric Abstractions for

Neutron: Policy Extension Framework Application-centric Network Policies Conclusion

IBM Research

Different Layers Neutron is the

OpenStack networking Higher layers consume

networking resources through the Neutron API

Lower layers realize these networking resources through a pluggable architecture

Neutron

App App App App

Network Controller

NovaHeat

Cloud Orchestrator

IBM Research

Abstractions at Higher Layers Simple and application centric Non-network centric: Interested in the

needed network functions and not how they are realized

Q

IBM Research

Tier 1

Tier 2

Tier 3

Firewall Load Balancer QoS

External NetworkInternet

Abstractions in Lower Layers

Network centric Device oriented

(switches/routers) Topology aware Packet forwarding/routing, Path

computation No standard northbound API

IBM Research

* M. Banikazemi, D. Olshefski, A. Shaikh, J. Tracey, and G. Wang, Meridian: An SDN Platform for Cloud Network Services, IEEE Communications Magazine, Feb 2013

Neutron: A Quantum Approach

Defines a minimal set of interfaces required for setting up networks for users

Extendable

IBM Research

Port

Network

Subnet

• network: isolated layer-2 broadcast domain; private/shared

• Subnet: CIDR IP address block associated with a network; optionally associated gateway, DNS/DHCP servers

• port: virtual switch port on a network; has MAC and IP address properties

Neutron Expansion through Extensions

Physical networks Layer 3 networking Layers 4-7 services

IBM Research

Port

Network

Subnet

RouterNAT, Floating IP

Security Group

LBaaS, FWaaS

VPNaaS,

Provider Network

Port Binding

Multi-Provider Network

Neutron: The 3-tier App Example

Q

Network/subnet

Network/subnet

Network/subnet

Router

External Network

Port

Q

IBM Research

One possible implementation using a single router

Realizing the ApplicationIBM Research

GROUP:Inet GROUP:WEB Consider part of the 3-tier app:(Not including calls for creation of Security Groups, FW and LB)neutron net-create inet --router:external=Trueneutron subnet-create inet 172.16.1.0/24 --disable-dhcp –name inetneutron net-create web

neutron subnet-create web 10.0.0.0/24 web –name web

neutron router-create router1neutron router-interface-add router1 webneutron router-gateway-set router1 inetneutron floatingip-create --port_id <internal VM port-id> inet

FW LB

The Problem Neutron abstractions are closer to

physical devices Not easily understood and consumed

by higher layers and users The Policy Extension Framework

adds application centric abstractions to Neutron

IBM Research

Neutron: Policy Extension Framework

Basic abstractions we need: Connectivity Groups: Grouping of

endpoints Policy: Specifying the network functions

governing connectivity of these groups Extending the current Neutron object

model Using the existing Neutron resources

IBM Research

* Icehouse Design Summit Session (IBM and Cisco joint proposal) : ” Group-based Policy Abstractions” aka “Connectivity Group Extension API” or “Policy Extension Framework”

Policy Extension Framework Simple, application-oriented network model

grouplogical grouping of VMs• traditional: MAC, IP, port• abstract/cloud: virtual network, application group

policy• between pairs of groups• establish communication• attach properties to the communication• e.g., ACLs, middleboxes, QoS, reliability, etc.

IBM Research

Policy Rules and Policy Sets Policy: made of Policy Rules Policy Rule: applies actions to selected

net traffic Policy Set: An aggregation of policies;

Can represent an application pattern

PolicyruleTraffic: Http Action: Allow

Policyset Policies: [policy_web, policy_db]

policy_web policy_db

IBM Research

Policy: The Hierarchy

Policy RulesConnectivity Groups (Source & Destination)

Policy

Policy RulesPolicy Rules

Policy Rule

TrafficClassifier

Policy Rule

Action

Policy Set

PolicyPolicyPolicy

IBM Research

Policy Rule: Action Types Basic connectivity ACL Service chaining (Middleboxes)

List of services Neutron services (*aaS) and/or other

services Service configuration

QoS and Monitoring Logical middleboxes

IBM Research

Proposed Neutron CLI

neutron connectivitygroup-create inet –external

neutron connectivitygroup-create web

neutron policy-rule-create policyrule-web  --protocol http,https --action fw1,lb1

neutron policy-create policy-web-ingress --policy-endpoints inet,web  --policy-rule   policyrule-web

IBM Research

GROUP:InetPolicy:Web

GROUP:WEB

FW1 LB1

The 3-tier App Example: Revisited

Q

IBM Research

Q

GROUP:Web

GROUP:DB

GROUP:LOGIC

Policy:Web Policy:DB

GROUP:Inet

Heat Template Sketch for 3-tier App

Endpoints: Current Neutron resources Neutron resource creation can be explicit or implicit; Can be

automated at higher layers

IBM Research

Policy_web_ingress: Type: OS::Neutron::policy Properties: connectivity_groups: {“cg_inet”, “cg_web”} Policy_rules: [“policy_rule_web”]

Policy_rule_web: Type: OS::Neutron::policy_rule Properties: traffic_spec: ports: 80,443 protocol: “tcp” action_type: service_chain: {FW1, LB1} service_conf: {}

cg_inet: Type: OS::Neutron::connectivity_group Properties: endpoints: {“inet”} configuration: “external”

cg_web: Type: OS::Neutron::connetivity_group Properties: endpoints: { “webserver1”, “webserver2”, webserver3”}

Extending Heat Expanding the role of

Heat

IBM Research

Nova Cinder Neutron

InfrastructureOrchestration

SoftwareOrchestration

Heat

Open Specifications: TOSCA

Application-centric Network Services

With the basic abstractions in place, we can build on how networking resources are used

Provide interesting application-centric functionalities

Let us look at a few example use cases

IBM Research

Dynamic Updates Updating the Connectivity Group will

also notify components of the associated policy

Q

IBM Research

Logical Middlebox: Monitoring

Monitoring defined as policy Collecting network specific statistics for

applications Aggregate based on flows, endpoint,

groups of endpoints, applications Feeds to the comprehensive closed-loop

processing

IBM Research

QM

Closed-loop Processing Standard MAPE (Monitor, Analyze, Plan, Execute)

model with application-centric network monitoring Application specifies the service level required Application publishes the service level it is

experiencing If service level is not met, application level

monitoring data is analyzed If the problem is deemed to be network related,

actions are taken by modifying the network policies Rerouting paths Bandwidth reservation and throttling

Updating network service if changes in compute resources is initiated

IBM Research

Topology Based Policies Network controllers provide a wide

selection of topology related information and features

Make those available at higher layers through policies Colocation/Anti-colocation for network

routes Non-overlapping routes

Asymmetric routes Separate routes on each direction

Network hop-count limit

IBM Research

Beyond Single Tenant Policies

The policy extension is defined for a given tenant

Can be extended such that network functions can be provided by a tenant to one or more tenants and/or external users

Require to setup the networks across tenants

Admin based vs. tenant centric

IBM Research

Conclusion Different abstractions are useful at

different layers OpenStack Networking needs to be able

to support and use these The framework for new application-centric

network abstractions being proposed

Let us discuss the details at the design session “Connectivity Group Extension” (“Group-based Policy Abstractions for Neutron”) on Friday Nov. 8th @ 3:10pm

IBM Research

Acknowledgement Anees Shaikh David Olshefski and John Tracey

Marcio Silva

IBM Research

* Photo credit: wikiHow

IBM Research

Thank You