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).

1. OpenDaylight and OpFlex
Scott Mann

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