Network Abstractions at
Different Layers of the
Stack
Mohammad Banikazemi
November 2013
IBM Research
Outline
IBM Research
Network Abstractions at Different Layers
 Neutron: The OpenStack Networking
 Application-centric Abstractions for Neutron:
Policy Extension Framework
 Application-centric Network Policies
 Conclusion

Different Layers
IBM Research



Neutron is the OpenStack
networking
Higher layers consume
networking resources
through the Neutron API
Lower layers realize these
networking resources
through a pluggable
architecture
App
App
App
App
Cloud
Orchestrator
Heat
Nova
Neutron
Network Controller
Abstractions at Higher Layers
IBM Research


Simple and application centric
Non-network centric: Interested in the needed
network functions and not how they are realized
Tier 2
Tier 1
Tier 3
External Network
Internet
Firewall
Load
Balancer
QoS
Abstractions in Lower Layers
IBM Research
Network centric
 Device oriented (switches/routers)
 Topology aware
 Packet forwarding/routing, Path
computation
 No standard northbound API

* 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
IBM Research

Defines a minimal set of interfaces required for
setting up networks for users
Network
• network: isolated layer-2 broadcast
domain; private/shared
Subnet
• 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
Port

Extendable
Neutron Expansion through Extensions
IBM Research



Physical networks
Layer 3 networking
Layers 4-7 services
Router
NAT, Floating IP
Port Binding
Network
Provider
Network
Multi-Provider
Network
Subnet
LBaaS, FWaaS
VPNaaS,
Port
Security Group
Neutron: The 3-tier App Example
IBM Research

One possible implementation using a single router
External Network
Router
Network/subnet
Network/subnet
Network/subnet
Port
Realizing the Application
IBM Research
 Consider part of the 3-tier app:
GROUP:WEB
GROUP:Inet
FW
LB
(Not including calls for creation of
Security Groups, FW and LB)
neutron net-create inet --router:external=True
neutron subnet-create inet 172.16.1.0/24 --disable-dhcp –name inet
neutron net-create web
neutron subnet-create web 10.0.0.0/24 web –name web
neutron router-create router1
neutron router-interface-add router1 web
neutron router-gateway-set router1 inet
neutron floatingip-create --port_id <internal VM port-id> inet
The Problem
IBM Research
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

Neutron: Policy Extension Framework
IBM Research

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

* 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
IBM Research

Simple, application-oriented network model
group
logical 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.
Policy Rules and Policy Sets
IBM Research



Policy: made of Policy Rules
Policy Rule: applies actions to selected net traffic
Policy Set: An aggregation of policies; Can
represent an application pattern
Policyrule
Traffic: Http Action: Allow
Policyset
Policies: [policy_web, policy_db]
Policy: The Hierarchy
IBM Research
Policy
Policy Set
Connectivity Groups
Policy
Policy
Policy
(Source & Destination)
Policy Rule
Traffic
Classifier
Action
Policy Rules
Policy Rules
Policy Rules
Policy Rule
Policy Rule: Action Types
IBM Research



Basic connectivity
ACL
Service chaining (Middleboxes)
 List
of services
 Neutron services (*aaS) and/or other services
 Service configuration


QoS and Monitoring
Logical middleboxes
Proposed Neutron CLI
IBM Research
GROUP:WEB
Policy:Web
GROUP:Inet
FW1
LB1
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
The 3-tier App Example: Revisited
IBM Research
GROUP:LOGIC
GROUP:Web
Policy:Web
Policy:DB
GROUP:DB
GROUP:Inet
Heat Template Sketch for 3-tier App
IBM Research
Policy_web_ingress:
cg_inet:
Type: OS::Neutron::policy
Type: OS::Neutron::connectivity_group
Properties:
Properties:
connectivity_groups: {“cg_inet”, “cg_web”}
endpoints: {“inet”}
Policy_rules: [“policy_rule_web”]
configuration: “external”
Policy_rule_web:
cg_web:
Type: OS::Neutron::policy_rule
Type: OS::Neutron::connetivity_group
Properties:
Properties:
traffic_spec:
ports: 80,443
endpoints: { “webserver1”, “webserver2”,
webserver3”}
protocol: “tcp”
action_type:
service_chain: {FW1, LB1}
service_conf: {}

Endpoints:


Current Neutron resources
Neutron resource creation can be explicit or implicit; Can be
automated at higher layers
Extending Heat
IBM Research

Expanding the role of Heat

Open Specifications: TOSCA
Software
Orchestration
Infrastructure
Orchestration
Heat
Nova
Cinder
Neutron
Application-centric Network Services
IBM Research
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

Dynamic Updates
IBM Research

Updating the Connectivity Group will also notify
components of the associated policy
Logical Middlebox: Monitoring
IBM Research




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
Closed-loop Processing
IBM Research

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
Topology Based Policies
IBM Research


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
 Separate
 Network
routes
routes on each direction
hop-count limit
Beyond Single Tenant Policies
IBM Research
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

Conclusion
IBM Research




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
Acknowledgement
IBM Research



Anees Shaikh
David Olshefski and John Tracey
Marcio Silva
Thank You
IBM Research
* Photo credit: wikiHow