mb openstack-nov2013v7
DESCRIPTION
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.TRANSCRIPT
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=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
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
PolicyPolicy
Policy
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:Inet
Policy: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