Network Abstractions at Different Layers of the Stack

IBM Research 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 • Application-centric Network Policies • Conclusion

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

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

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

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

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

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

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

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

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”

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.

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]

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

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

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

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

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”}

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

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

Dynamic Updates IBM Research • Updating the Connectivity Group will also notify components of the associated policy Q

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

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

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

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

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

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

Thank You IBM Research * Photo credit: wikiHow

Network Abstractions at Different Layers of the Stack