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.
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
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
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
ď¨
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
1- Neutron is the openstacknetworking layer. 2- Higher layers ⌠3- Lower Layers ⌠before we look at Neutron abstraction lets look at other layers.
Now, let us focus on Neutron and see what abstractions it provides
---- physical network / device oriented Physical data center structureprovider network Layer 3 networking (router)NATfloating IPs (for externally accessible services)---- modeled after Amazon VPC Security groupsaccess control rules for ingress / egress traffic on Neutron ports---- vendor device modelsL4 â L7 servicesload balancer as a service (LBaaS)other service APIs being developed (firewall, VPN, âŚ)