OpFlex Policy Agent Architecture
The Fine Print
This document is considered a working document in that it is intended to be a place holder for the project and as the Policy Agent under goes development, this document will change as well and at time be outdated.
This document describes the architecture proposed for the open source Policy Agent for the implementation that will implement the OpFlex protocol. Before one discusses the details of the architecture and assumptions therein, an overview of where and how the Policy Agent will fit into and overall system design is in order. The following is that overview of a Policy system and its various functions. The policy agent’s function is to exchange and enforce policy, acting as a participant in a larger policy management system. Figure 1-1 is an example of such a system. The agent is a Policy Element (PE), which requests Policy Resolution and receives Policy Updates from a Policy Repository (PR). The agent can also indicate the declaration of new End Points to an End Point Registry (EPR), and receive Policy Resolutions and Updates for the End Points. Status information is sent to an Observer, which collects and archives the status. The agent can also trigger behaviors in peering Policy Elements, using the Policy Trigger message. A more complete description of an Policy system can be found in .
Policy and Policy Resolution
A primary function of the policy architecture is the delivery and maintenance of Managed Object (MO) subtrees. Each Policy Element has a Managed Object Store, which provides a means for local caching of policy in the form of Managed Objects. Managed Objects are considered subtrees of a larger Management Information Tree (MIT). The MIT is the superset of all possible policies, and is generated from a user-defined policy model. There are two types of policy models. One is a “Logical Model” in which fabric-specific details are abstracted into an equivalent logical representation. The other is a “Concrete Model” in which the objects in the model refer to physical network elements. The Logical Model is used to create a MIT that can be imported in the policy controller, as well as MO library that can be integrated in the agent (Figure 1-3).
Figure 1-3: Generated Policy Model
Each type of policy is uniquely identified in a given context by its name, where context can be specific to a tenant, a shared common tenant, etc. Resources that use a policy refer to this policy by its name, and a hierarchical closest matching policy is resolved. If no named match exists, a default policy is resolved.
Policy resolution is typically implicit, meaning that it is triggered via a set of internal APIs in the PE as a side effect of a change / stimulus, such as an endpoint attach. Policy resolution consists of sending logical policies to Policy Elements, which maintain read-only copies of the logical policies and apply changes to corresponding concrete model objects. Whenever possible, sets of related policies are resolved together in a single transaction to Policy Elements.
The Policy Repository persists information about which policies are in use and where they have been resolved in an internal registry. When there are subsequent changes to policies -- such as property modifications and lifecycle changes (creation, deletion) -- the Policy Repository sends update notifications to Policy Elements where the affected policies are in use. It is the responsibility of Policy Repository to push the updates to policies that it owns to all the policy clients of the policy. For each policy, the Policy Repository maintains the list of policy clients and policy consumers. As mentioned in above, when a policy is resolved, all policies with that name in the hierarchy are in-scope policies and would be resolved. Whenever a policy is updated, the updated policy is pushed down to all policy clients. The Policy Update message is only used to provide updates to policies that have already been provided to a Policy Element, and not to install an entirely new policy. The Policy Resolution message from the Policy Element must be used to request new policies (i.e. MO sub-trees that the PE doesn’t yet have).
To implement declarative control, a new mechanism is required to transfer abstract policy from a network policy controller to a set of smart devices capable of rendering abstract policy. Unfortunately, existing protocols such as OVSDB favor imperative models and rigid schematics, so they are not appropriate for this use case. In Fact, devOps tools such as Puppet or CFEngine take a similar approach to OpFlex in using declarative languages to configure server resources.
OpFlex is designed to allow a data exchange of a set of managed objects that is defined as part of an informational model. OpFlex itself does not dictate the information model and can be used with any tree-based abstract model in which each node in the tree has a universal resource identifier (URI) associated with it.
The protocol is designed to support XML and JSON (as well as the binary encoding used in some scenarios) and to use standard remote procedure call (RPC) mechanisms such as JSON-RPC over TCP. The use of a secure channel through Secure Sockets Layer (SSL) and Transport Layer Security (TLS) is also recommended.
The protocol defines a number of logical constructs required for its operation (Figure 2).
The policy repository (PR) is a logically centralized entity containing the definition of all policies governing the behavior of the system. In Cisco ACI, this function is performed by the Cisco APIC or by the leaf nodes of the network fabric. The policy authority handles policy resolution requests from each policy element.
Policy Element (Policy Agent)
A policy element (PE) is a logical abstraction for a physical or virtual device that implements and enforces policy. This is where the Policy Agent describe in detail herein resides. Policy elements are responsible for requesting portions of the policy from the policy authority as new endpoints connect, disconnect, or change. Additionally, policy elements are responsible for rendering that policy from an abstract form into a concrete form that maps to their internal capabilities. This process is a local operation and can function differently on each device as long as the semantics of the policy are honored.
The endpoint registry (ER) stores the current operation state (identity, location, etc.) of each endpoint (EP) in the system. The endpoint registry receives information about each endpoint from the local policy element and then can share it with other policy elements in the system. The endpoint registry may be physically co-located with the policy authority, but it may also be distributed in the network fabric itself. In Cisco’s ACI solution, the endpoint registry actually lives in a distributed database within the network itself to provide additional performance and resiliency.
Opflex Protocol Messages
Table 1 Summarizes the RPC methods that OpFlex supports. It is not intended to provide a full description, but to to show how different entities interact through the protocol.
Table 1. RPC Methods Supported by OpFlex.