1 / 28

Network Abstractions at Different Layers of the Stack

Network Abstractions at Different Layers of the Stack. Mohammad Banikazemi November 2013. Outline. IBM Research. Network Abstractions at Different Layers Neutron: The OpenStack Networking Application-centric Abstractions for Neutron : Policy Extension Framework

haig
Download Presentation

Network Abstractions at Different Layers of the Stack

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  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. Abstractionsat 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 Load Balancer Firewall QoS Q

  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 2013

  6. Neutron: A Quantum Approach IBM Research • Defines a minimal set of interfaces required for setting up networks for users • Extendable Network • 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 Subnet Port

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

  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 Q Q

  9. Realizing the Application IBM Research GROUP:WEB GROUP:Inet • Consider part of the 3-tier app: • (Not including calls for creation of • Security Groups, FW and LB) • neutron net-createinet--router:external=True • neutron subnet-createinet 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 router1inet • neutron floatingip-create --port_id <internal VM port-id> inet FW LB

  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) : ” Group-based 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 policy_web policy_db Policyrule Traffic: Http Action: Allow Policyset Policies: [policy_web, policy_db]

  14. Policy: The Hierarchy IBM Research Policy Policy Set Connectivity Groups (Source & Destination) Policy Rules Policy Rules Policy Policy Rules Policy Policy Rule Policy Policy Rule Traffic Classifier Action

  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 • QoSand Monitoring • Logical middleboxes

  16. Proposed Neutron CLI IBM Research GROUP:WEB Policy:Web GROUP:Inet FW1 LB1 neutron connectivitygroup-createinet–external neutron connectivitygroup-create web neutron policy-rule-create policyrule-web  --protocolhttp,https --action fw1,lb1 neutron policy-create policy-web-ingress --policy-endpointsinet,web --policy-rule policyrule-web

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

  18. Heat Template Sketch for 3-tier App IBM Research • Endpoints: • Current Neutron resources • Neutron resource creation can be explicit or implicit; Can be automated at higher layers 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”}

  19. Extending Heat IBM Research • Open Specifications: TOSCA • Expanding the role of Heat 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 Q

  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 Q M

  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 • Updating network service if changes in compute resources is initiated

  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 routes • Separate routes on each direction • Network 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 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

  27. Acknowledgement IBM Research • AneesShaikh • David Olshefski and John Tracey • Marcio Silva

  28. Thank You IBM Research * Photo credit: wikiHow

More Related