[Note: This is the third a four-part series on the OpFlex protocol in Cisco ACI, how it enables an application-centric policy model, and why other SDN protocols do not. Part 1 | Part 2 | Part 4]
The Cisco ACI fabric is designed as an application-centric intelligent network. The Cisco APIC policy model is defined from the top down as a policy enforcement engine focused on the application itself and abstracting the networking functions underneath. The policy model unites with the advanced hardware capabilities of the Cisco ACI fabric underlying the business-application-focused control system.
The Cisco APIC policy object-oriented model is built on the distributed policy enforcement concepts for intelligent devices enabled by OpFlex and characterized by modern development and operations (DevOps) applications such as Puppet and Chef.
At the top level, the Cisco APIC policy model is built on a series of one or more tenants, which allows the network infrastructure administration and data flows to be segregated. Tenants can be customers, business units, or groups, depending on organization needs. Below tenants, the model provides a series of objects that define the application itself. These objects are endpoints and endpoint groups (EPGs) and the policies that define their relationships (see figure below). The relationship between two endpoints, which might be two virtual machines connected in a three-tier web application, can be implemented by routing traffic between the endpoints to firewalls and ADCs that enforce the appropriate security and quality of service (QoS) policies for the application and those endpoints.
For a more thorough description of the Cisco ACI application policy model, please refer to this whitepaper, or this one more specifically on Endpoint Groups.
For this discussion, the important feature to notice is the way that Cisco ACI policies are applied to application endpoints (physical and virtual workloads) and to EPGs. Configuration of individual network devices is ancillary to the requirements of the application and workloads. Individual devices do not require programmatic control as in prior SDN models, but are orchestrated according to the centrally defined and managed policies and according to application policies.
This model is catching hold in the industry and in the open source community. The OpenStack organization has begun work on including group-based policies to extend the OpenStack Neutron API for network orchestration with a declarative policy-based model based closely on EPG policies from Cisco ACI. (Note: “Declarative” refers to the orchestration model in which control is distributed to intelligent devices based on centralized policies, in contrast to retaining per-flow management control within the controller itself.)
The figure below (from the OpenStack website) shows how the group policy model extends the existing OpenStack networking concepts of networks and ports by applying the network objects to a new classifier, called the endpoint, with endpoints then further classified into groups. Policies are applied to endpoint groups, with policies consisting of classifiers, rules, and actions.
As stated in the original group policy proposal:
The main advantage of the extensions described in this blueprint is that they allow for an interface to Neutron which is more application-centric than the existing Neutron APIs. For example, the current Neutron API is focused on very network-centric constructs: ports, networks, subnets, routers, and security groups. In the context of networking, these make complete sense. But in the context of cloud applications, these are more cumbersome than needed. Application developers think in different terms—the policy and group abstractions are designed to allow for the flexibility that an application developer may want when programming something like Neutron.
The goal of these API extensions is that they become the main interface to Neutron for those deploying applications by providing a simpler interface in which to consume Neutron resources.
Similarly, the OpenDaylight open source controller group is working on specifying a group policy plug-in for the OpenDaylight controller. In this case, in addition to adopting the same policy model focused on groups of endpoints, the controller working group is specifying northbound APIs from the controller to accept abstract policy based on application requirements from orchestration tools and systems such as OpenStack, and to offer numerous southbound interfaces to allow network elements to be programmed and managed based on the application policies.
The OpenDaylight project webpage lists the advantages of the group policy approach for SDN controllers:
- Easier, application-focused way to express policy: By creating policies that mirror application semantics, this framework provides a simpler, self-documenting mechanism for capturing policy requirements without requiring detailed knowledge of networking.
- Improved automation: Grouping constructs allow higher-level automation tools to easily manipulate groups of network endpoints simultaneously.
- Consistency: By grouping endpoints and applying policy to groups, the framework offers a consistent and concise way to handle policy changes.
- Extensible policy model: Because the policy model is abstract and not tied to specific network implementations, it can easily capture connectivity, security, Layer 4 through 7, QoS, etc.
As we can see, the open source SDN community is moving toward the group-based policy model inherent in Cisco ACI, which is enabled by the OpFlex protocol, as well as the policy language itself. These efforts are supported by a diverse community of vendors and solution providers, including IBM, Red Hat, Plexxi, Midokura, and Big Switch as well as the OpenDaylight participants. What is coming together is not just another set of SDN protocols or use cases, but an entire architecture for sharing policies and actionable data.
The final part of this blog series will look at the application of the ACI Group Policy model to DevOps.
CONNECT WITH US