OpFlex Control Protocol_Draft

ODL's Third Release – “Lithium” - Introduces New SDN Features & Capabilities

● Increased scalability and performance 
● Network services for cloud data center platforms 
● New features for security and automation 
● New and enhanced APIs for interoperability 
● Six new protocols to support an ever-widening set of use cases ( OpFlex is one of the six protocols)

Abstract

The OpFlex architecture provides a distributed control system based on a declarative policy information model. The policies are defined at a logically centralized policy repository (PR) and enforced within a set of distributed policy elements (PE). The PR communicates with the subordinate PEs using the OpFlex Control protocol. This protocol allows for bidirectional communication of policy, events, statistics, and faults. This document defines the OpFlex Control Protocol.

OpFlex is a policy driven system used to control a large set of physical and virtual devices. The OpFlex system architecture consists of a number of logical components. These are the

 OpFlex protocol uses JSON, XML, or OpFlex-Binary-RPC as the wire encoding.

Policy Repository (PR)
It handles policy resolution requests from the Policy Elements within the same administrative domain. These policies are configured directly by the user via a policy administration interface (API/UI/CLI/etc.)

PR - MIM (Management Information Model)
The hierarchical structure starts at a root node and all policies within the system can be reached via parent and child containment relationships. Each node has a unique Uniform Resource Identifier (URI) [RFC3986] that indicates its place in the tree.

PR -Managed Objects
MOs that contain statistic, fault, or health MOs are said to be observable
Properties, Child Relation, Parent Relation, MO Relations, Statistics, Faults, Health


Endpoint Registry (EPR)

The Endpoint Registry (EPR) is the component that stores the current operational state of the endpoints (EP) within the system
The EP registration information contains the scope of the EP such as the Tenant or logical network as well as location information such as the hypervisor where the EP resides. The EPR can be used by PEs to query the current EPR registrations as well as receive updates when the information changes.

Observer

The Observer serves as the monitoring subsystem that provides a detailed view of the system operational state and performance. It serves as a data repository for information related to trending, forensics, and long-term visibility data such as statistics, events, and faults.

Policy Elements (PE).

Policy elements reside on physical or virtual devices that are subjected to policy control under a given administrative domain. 

Two types of the PE triggers
(a) Local triggers involve local MO state transitions such as new control node additions, removals, or other operational events.
(b) Policy triggers invoked by other PEs are transmitted using the OpFlex Control Protocol

Security

OpFlex Control Protocol SHOULD be secured using Transport Layer Security (TLS) [RFC5246].
A TCP port will be requested from IANA for the OpFlex Control Protocol.

 Terminology:

•  AD: Administrative Domain. A logical instantiation of the OpFlex system components controlled by a single administrative policy. 
• EP: Endpoint. A device connected to the system. 
•  EPR: Endpoint Registry. A logically centralized entity containing the endpoint registrations within associated administrative domain. 
•  OB: Observer. A logically centralized entity that serves as a repository for statistics, faults, and events. 
•  PE: Policy Element. A function associated with entities comprising the policy administrative domain that is responsible for local rendering of policy. 
•  PR: Policy Repository. A logically centralized entity containing the definition of all policies governing the behavior of the associated administrative domain. 
•  OpFlex Device: Entity under the management of a Policy Element.