This is the slides I used for the talk I gave at the OpenStack Summit in Hong Kong, November 2013. In this presentation/talk I argue that we need to have a more application-centric and policy oriented set of abstractions in Neutron, the OpenStack networking project.

1. Network Abstractions at
Different Layers of the
Stack
Mohammad Banikazemi
November 2013
IBM Research

2. 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


3. 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

4. Abstractions at Higher Layers
IBM Research


Simple and application centric
Non-network centric: Interested in the needed
network functions and not how they are
Tier 2
realized
Tier 1
Tier 3
External Network
Internet
Firewall
Load
Balancer
QoS

5. 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

6. 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

7. Neutron Expansion
throughExtensions



IBM Research
Physical networks
Layer 3 networking
Layers 4-7 services
Router
NAT, Floating IP
Network
Provider
Network
Multi-Provider
Network
Subnet
Port Binding
LBaaS, FWaaS
VPNaaS,
Port
Security Group

8. 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

9. 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

10. 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


11. 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) : ” Groupbased Policy Abstractions” aka “Connectivity Group Extension API” or “Policy
Extension Framework”

12. 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.

13. 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]

14. 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

15. 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

16. 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 --policyrule
policyrule-web

17. The 3-tier App Example:
Revisited
IBM Research
GROUP:LOGIC
GROUP:Web
Policy:Web
Policy:DB
GROUP:DB
GROUP:Inet

18. 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:
traffic_spec:
ports: 80,443
Properties:
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

19. Extending Heat
IBM Research

Expanding the role of
Heat

Open Specifications:
TOSCA
Software
Orchestration
Infrastructure
Orchestration
Heat
Nova
Cinder
Neutron

20. 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


21. Dynamic Updates
IBM Research

Updating the Connectivity Group will also
notify components of the associated policy

22. 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

23. 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

24. 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

25. 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


26. 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 applicationcentric 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

27. Acknowledgement
IBM Research



Anees Shaikh
David Olshefski and John Tracey
Marcio Silva

28. Thank You
IBM Research
* Photo credit: wikiHow