Open source policy open daylight and opflex

869 views

Published on

Presentation of an approach to building an OpFlex Agent, which operates in an OpenDaylight and/or OpenStack infrastructure using OVS. This will be presented at LinuxCon in Chicago (August 2014).

Published in: Software
  • Be the first to comment

Open source policy open daylight and opflex

  1. 1. OpenDaylight and OpFlex Scott Mann
  2. 2. The Open Source Policy “Stack” OpFlex Policy Agent with northbound OpFlex protocol interface and southbound interface for device (OVS is the reference implementation). OpFlex protocol defined through IETF (OpFlex Control Protocol draft-smith-opflex-00) Group Policy as defined by OpenDaylight/OpenStack OpenDaylight and OpenStack provide northbound API for Group Policy and southbound interface for OpFlex protocol. Linux (Netlink) OVS (OpenFlow, OVSDB) libvirt API
  3. 3. ODL Group-Based Policy Project The group-based policy project defines an application- centric policy model for OpenDaylight that separates information about application connectivity requirements from information about the underlying details of the network infrastructure.
  4. 4. Group Policy Elements • Policy Repository • A database of policies • A policy consists of • Endpoint Groups (EPGs) described below • Contracts, which describe how/if EPGs communicate with each other • Endpoint Repository • Database of endpoints and their meta-data • Endpoints are things that can communicate like virtual/physical ports • Includes mapping of endpoints into of Endpoint Groups (EPG) • EPGs are the smallest entity that can be specified in a policy • Observer • A repository that maintains a database of status updates and exceptions
  5. 5. The Policy Agent’s Role The policy agent’s function is to exchange and enforce policy, acting as a participant in a larger policy management system.
  6. 6. End Point Registry The Policy Agent in the Policy System Observer Policy Agent Policy Agent (on another device) Policy Resolution Policy Repository Policy Update End Point Declaratio n End Point Policy Update Status Policy Peering via Triggers
  7. 7. Policy Agent in the Policy System Explained • The policy agent (PA) • Requests policy resolution from a Policy Repository (PR) • Receives policy updates from a PR • Indicate end points to an End Point Registry (EPR) • Receive policy resolutions • Receive updates for the End Points • Trigger behaviors in peering Policy Elements (PEs), using the Policy Trigger OpFlex messaging • Status information is sent to an Observer • Collects and archives status • Observer may communicate status to other PEs • PRs, EPRs, PAs, and Observers may be referred to as PEs
  8. 8. Policy Resolution within the Agent Policy Agent Policy Manager Inbound/Outbound TCP/IP Managed Object Database Policy Enforcer In/Out to “device” (e.g., OVS, vSwitches, HW switches, etc.)
  9. 9. Agent Policy Resolution Explained • Policy Manager • “Speaks” OpFlex • Converts OpFlex into format useful to Managed Object Database • Manages TCP connections with PR, EPR, and Observer • Managed Object Database (MODB) • Maintains hierarchical tree model of physical/virtual devices under management • Updates are propagated appropriately via northbound and southbound APIs • Policy Enforcer • Conceptually similar to a device driver • Translates data from MODB into sets of appropriate commands/communications to physical and/or virtual devices • Monitors devices for updates, which are propagated to MODB via API
  10. 10. Reference/OVS Implementation OpFlex Agent Open vSwitch Datapath Flow Table OpenFlow OVSDB Managed Objects Store (MODB) OVS Render Plugin (Policy Enforcement) SW/HW Datapath OpFlex (Policy Manager)
  11. 11. Reference/OVS Implementation • Written in C using standard libraries • Developed with the OpenDaylight project • Eclipse and Apache licensing • Runs on common Linux distributions • Policy Manager • Supports the OpFlex protocol with JSON at L-6 • Support at least 3 PRs • Managed Object Database • Queries by class, object ID, or URIs • Updates generate notifications to Policy Manager and/or Policy Enforcer as appropriate • DB persistence with crash recovery • Policy Enforcer • Policy enforcement between containers and/or virtual machines • Interface to libvirt API (supporting many hypervisors) and OVSDB • OVS management via ovs-vsctl, ovs-ofctl, etc • Network management via ip commands
  12. 12. Policy Agent Southbound Path (OVS Implementation) MODB Update database Inform policy enforcer Policy/End Point Repository JSON Policy Manager Receive update Convert JSON to internal form Policy Enforcer Translate managed object Issue appropriate commands ovs-vsctl ... ovs-ofctl ... ip addr ... ip link ... etc ….
  13. 13. OVS Policy Agent Southbound Path Explained • A policy or policy update arrives at the port of the Policy Manager • JSON is translated into internal form • Internal data is passed to Managed Object module • Data inserted into database • Notification of database change goes out to subscribers • Policy enforcer receives update • New or modified data is passed to translator • Translator produces list of commands suitable for underlying virtual/physical device • Dependencies are identified • Commands are executed asynchronously • Pass/Fail of command execution is recorded • Failure may cause roll back of successful commands • Since all commands are issued asynchronously, determination of successful implementation follows the northbound path described next
  14. 14. Policy Agent Northbound Path (OVS Implementation) Observer Policy/End Point Repository Initial Scan Policy Manager Receive update Convert MODB to JSON MODB Update database Inform policy manager Policy Enforcer Monitor runs continuously Translate received data into MODB OVSDB Asynchronous OVS updates libvirt JSON JSON
  15. 15. OVS Policy Agent Northbound Path Explained • Policy Enforcer receives update and/or asynchronous responses • Translates responses into managed object as appropriate • Notifies Managed Object module of changes • Managed Object module • Notifies Policy Manager of changes • Policy Manager • Converts MO data into JSON • Sends data to appropriate elements (Policy Repository, Endpoint Repository, Observer)
  16. 16. Start Up • Start Up • PE initializes communication with OVS and libvirt • Essentially collects current state • MO module • Reads in crash recovery file, if it exists • Populates MODB with recovery data and/or PE scan data • Policy Manager • Initializes connections with know PEs • Sends current policy (or state) to appropriate PEs
  17. 17. Summary • Currently working on reference policy agent • Implementation: C, Linux, JSON, OVS, libvirt • More detail about the reference architecture may be found at https://wiki. opendaylight.org/view/Opflex_Architecture • The OpFlex IETF draft specification may be found at http://tools.ietf. org/html/draft-smith-opflex-00 • More detail about ODL group policy may be found at https://wiki. opendaylight.org/view/Group_Policy:Main • ODL group policy architecture https://wiki.opendaylight.org/view/Group_Policy:Architecture

×