Mb openstack-nov2013v7


Published on

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.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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, …)
  • Mb openstack-nov2013v7

    1. 1. Network Abstractions at Different Layers of the Stack Mohammad Banikazemi November 2013 IBM Research
    2. 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. 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. 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. 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. 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. 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. 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. 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 --disable-dhcp – name inet neutron net-create web neutron subnet-create web web –name web neutron router-create router1 neutron router-interface-add router1 web neutron router-gateway-set router1 inet
    10. 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. 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. 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. 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. 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. 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. 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. 17. The 3-tier App Example: Revisited IBM Research GROUP:LOGIC GROUP:Web Policy:Web Policy:DB GROUP:DB GROUP:Inet
    18. 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. 19. Extending Heat IBM Research  Expanding the role of Heat  Open Specifications: TOSCA Software Orchestration Infrastructure Orchestration Heat Nova Cinder Neutron
    20. 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. 21. Dynamic Updates IBM Research  Updating the Connectivity Group will also notify components of the associated policy
    22. 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. 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. 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. 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. 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. 27. Acknowledgement IBM Research    Anees Shaikh David Olshefski and John Tracey Marcio Silva
    28. 28. Thank You IBM Research * Photo credit: wikiHow