Back in 2005, virtual network operators (VNOs) were common. Although multinational corporations (MNCs) could buy wide-area network services in most countries, VNOs’ value was in serving MNCs, regardless of size, as the one point of contact for global WANs. In addition to simplifying adds, moves, and changes, VNOs enforced MNCs’ business policies from a central location and attempted to solve the inter-carrier communication challenge.

Although most VNOs did not survive, soon communication service providers (CSPs) will offer similar and more complex services to small MNCs and individuals. Technologies like cloud, software-defined networking (SDN), network function virtualization (NFV), and policy controls will make this possible.

For the last two years CSPs have tested SDN, NFV, and OpenStack through proof-of-concept projects to determine how to adopt these technologies and gain greater agility in delivering new services.

Over-the-top providers like Amazon and Google have created expectations about delivering services in minutes that previously took weeks and months.

Before the cloud, CSPs invested significant time checking for network capacity, switches, routers, firewall-appliances, and people’s availability to deliver such services. Now, CSPs can invest that time developing software functions (e.g., NFV) and cloud-based services like LBaaS, FWaaS, VPNaaS, and MVNO (mobile virtual network operator).

Still, even after getting SDN, NFV, and OpenStack working flawlessly, checking whether businesses and consumers can gain access to those resources must be done quickly and in accord with business policies. In other words, the process of implementing, monitoring, and resolving conflicting business policies must be automated.

There are two OpenStack projects that can help here: Group-Based Policy (GBP) and Congress. Both are aimed at automating policy management for cloud services. Here's a look at each.

GBP captures the intent of developers and application-requirements for networking and security by using a declarative API and policy model. With GBP, developers only specify what to do instead of how to do it.

GBP captures the virtual machine’s (application) requirements for Layers 2-7, including service chaining, in groups comprising network endpoints and their properties. All virtual machines associated with a group share the same policy.

Currently, GBP is targeted at OpenStack networking only. However, the framework is general enough to include compute and storage as well.

Congress is a declarative language used for monitoring, enforcing, and auditing policies (business logic) for the data center. It can delegate tasks to other policy systems, too.

Congress is domain independent, so it can monitor the behavior of systems including compute, storage, and networking. Although Congress is an OpenStack project, it was designed to manage any collection of cloud services, including AWS and CloudStack.

Congress’s most recent alpha-release monitors policy violations. In the near future, Congress will support the enforcement of those policies by executing API calls that will change the behavior of systems within the data center.

One final point: Although most discussions now are about hybrid clouds – how to connect private and public clouds – what if the customer happens to be an MNC? What if the customer wants to buy cloud services from multiple CSPs? OpenStack projects aimed at automating policy management for cloud services like GBP and Congress will make cloud federation (i.e., inter-cloud communication) possible.