Concepts

Summary

With Bayware, organizations can divide services distributed across private and public clouds into isolated domains without network configuration and irrespective of geographic location, virtualization platform, and IP/MAC addresses. Services may be running on bare metal or in VMs or containers.

IT teams can explicitly define data exchange instances (contracts), specifying interaction patterns, ACLs, and data pathways. Each permission set within a contract is labeled as a distinct role. These roles, then, can be attached to any service.

As a service instance binds to an endpoint, the endpoint dynamically obtains permissions based on the service role. In this way, the service instance will only be able to establish authorized connectivity with the policy set not only at the network edge, but through the entire infrastructure.

When a service instance sends a new flow, every Bayware-enabled switch en route verifies permissions linked to the service instance role before forwarding packets belonging to the flow.

Communication logic and policy preserve uniformity within different virtualization environments and across private and public clouds while still allowing for personalized forwarding, path protection, and load balancing down to the flow level.

Policy Model

Fig. 2 Figure 1. Bayware Policy Model

Organization. The top-level abstraction in the Bayware policy model is Organization. Typically, an Organization represents the entire customer infrastructure (intranet). Several customers can create and share an Organization to enable data exchange between their infrastructure (extranet). The Organization abstraction globally prevents overlapping of network policy object identifiers. An Organization nests two types of upper-level policy objects: Network Microservice Templates and Isolation Domains.

Templates and Network Functions. A Template represents a particular network microservice (point-to-point, load balancing, multicast, multipath, cost-based routing, etc.). It conveys the sense of the communication logic (connectivity and policy) that is available for use in the organization. A Template comprises one or several ephemeral Network Functions. Each Function realizes a network task performed on the packets in the data path (send, tag-based send, receive, publish-to-rendezvous-point, subscribe-from-rendezvous-point, etc.). Together, Functions within a Template implement a communication pattern.

Domains. A Domain serves as a logical division between different portions of the system. The Domain abstraction allows slicing the system into fully isolated communication realms, conveying the sense of a virtual private network. A Domain is a collection of resource users and contracts. Visibility of resource users and contracts within the system is limited by the Domain boundaries. All or a subset of an organization’s network microservice templates are allowed for use in each Domain.

Contracts and Roles. A Contract is an abstraction of a data exchange instance. The Contract abstraction is comparable to the notion of topics in a messaging systems. All communications in the system are organized in the form of Contracts. Each party to a Contract acquires rights and duties relative to the rights and duties of the other parties. If a service wants to send data, it must enter into a data-specific Contract in the desired Role (e.g., sender). If another service wants to receive that data, it must enter the same Contract in a different Role (e.g., receiver).

A Contract Role determines service capabilities at the Contract level. A Role uses a Contract party as a target. In other words, a service is given access to specific data exchange capabilities defined in the Contract by assigning a Role to the service in that Contract. A Role is unique within a Contract only.

Contracts are associated with templates. A Role inherits permissions from a network function in the associated template. Multiple Roles can be created from the same network function. The permissions for each Role may be customized as long as these permissions are a subset of those set by the parent network microservice template. This allows one to create fine-tuned versions of the same network function without recompiling the function itself. A function, send, can be customized as send-through-node, send-along-path, etc.

Users. A User is an abstracted entity that receives access to compute resources to run application services. A User belongs to only one domain and is unique within that domain only. However, user@domain must be unique within the entire organization.

Services. Sets of applications, individual applications or application modules are represented in the policy model as Services. A Service enters into one or more contracts with the desired role. A Service may communicate with other services through its contractual relationships. A given Service may be replicated on a compute resource or across multiple compute resources. Identical policy is applied to each Service instance.

Resources and Endpoints. A compute node is a set of Resources to which users are given access. Network Endpoints represent communication capabilities available for the service instances running on this node. A service instance binds to an Endpoint. An IP interface represents a typical network Endpoint.

Rule. A network Rule is created from a contract role and dedicated to a specific endpoint. Likewise, that endpoint is tied to a service instance originally authorized from the same contract role. (See Figure 1.) The Rule, therefore, is the output of the network policy instantiation process. It is enforced via ACLs at compute nodes and flow soft states at network nodes.

Policy Instantiation Workflow

Fig. 3 Figure 2. Policy Instantiation Workflow

While policy enforcement is a fully automated process, the policy instantiation requires involvement from the IT team. Mostly this effort involves designing contracts; the other steps are performed relatively infrequently.

The policy instantiation workflow comprises four distinct processes:

1. Create Domain.

   The system administrator creates a domain (similar to a VPN) for use in the organization. The administrator assigns a name to the domain, specifies its type as “services” and chooses a user authentication method.

2. Install Template.

   The system administrator installs a template (similar to a VNF) developed with Network Microservice SDK. The template contains one or more network functions that the administrator can customize after installation. The template may also be authorized for use in multiple domains.

3. Construct Contract.

   The domain administrator creates a contract (similar to a messaging topic) for use in the domain by assigning a name and choosing a template . The administrator creates contract roles from the template’s network functions, with or without function customization.

4. Label Service.

   The domain administrator labels a service with one or more contract roles. It can be done in two ways: through direct association between a resource user and a service (bare metal and VMs) or labeling a service itself (pods and containers). The former requires the domain administrator to create a new user with one or more contract roles each time a new type of service is set up. The latter is a fully automated process in which the domain administrator uses the service orchestration system to label the service.