| Name | Organization | |
|---|---|---|
| Angelos Mimidis | Technical University of Denmark | agmimi@fotonik.dtu.dk |
| Jose Soler | Technical University of Denmark | joss@fotonik.dtu.dk |
| Ferran Canellas | Technical University of Denmark | |
| Nestor Bonjorn | Technical University of Denmark | nestorbonjorn@gmail.com |
This document describes a network policy framework (NPF) for ONOS, including its design, implementation and operation. The purpose of this NPF is to provide an abstraction layer that hides the technology-specific details of the control and data planes by providing a human-readable interface that simplifies the enforcement of low-level and technology-specific actions to the network (e.g. installation of OpenFlow rules, constraint monitoring, etc.). This prototype is integrated into the ONOS SDN controller and it is responsible for translating generic policies received through a dedicated REST API into OpenFlow (OF) flow rules.
The network policy framework has been tested with ONOS versions 1.13.2 and 1.15.0-rc2
This work has been performed in the framework of the NGPaaS project, funded by the European Commission under the Horizon 2020 and 5G-PPP Phase2 programmes, under Grant Agreement No. 761 557 (http://ngpaas.eu).
The source code of the Network Policy Framework is currently available at:
The NPF was designed to support platform-wide and technology-agnostic policies. To this end, a policy model and a policy life cycle were defined. The former allows defining policies in a generic way regardless of the underlying technologies, while the latter defines the possible states of a policy as well as the logic to move from one state to another. These two concepts are summarized hereafter.
The policy model used by the policy framework is based on the Policy Core Information Model (PCIM), defined in the IETF’s RFC 3060 [8] and RFC 3460 [9]. In it, each policy is characterized as a Policy Rule, which is associated to a specific Policy Type, and is comprised by a set of Policy Conditions and Policy Actions, each of them having a pair of a Policy Variable and a Policy Value. Moreover, the policy framework allows multiple Policy Rules to be added at the same time as a Policy Group. In this case, the Policy Rules are processed in priority order, based on a priority field that needs to be defined in each Policy Rule.
The set of Policy Conditions of a Policy Rule are represented as a 2-dimensional list, as illustrated in Fig. 1. This can be treated by the framework in two different ways:
A single Policy Condition evaluates to true when a particular traffic matches the Policy Variable and the Policy Value. If the whole CNF or DNF expression of Policy Conditions evaluates to true, the corresponding Policy Actions are applied.
Note that any set of conditions expressed in CNF can be converted to DNF and vice versa. This is interesting because a policy expressed in DNF can be directly mapped to a set of flow rules as follows:
- Each condition clause corresponds to a flow rule, where
- Each condition corresponds to a parameter of the traffic to match
Note that the current version of the Policy Framework does not supported negated conditions when defining policies.
The Policy Lifecycle manages the state of the network policies based on three validations: formal, context and conflict. The formal validation analyzes whether the structure of the policy is valid or not. The way it is analyzed is specific to the type of policy being pushed; however, a structured way would be the following:
The context validation analyzes if the resources involved in the policy are available or not. This analysis also depends on the type of policy being pushed. However, there are 3 different scenarios:
Formal and context validations only consider a particular policy instance. Conflict Validation is needed to make sure that this policy instance is not in conflict with existing policy instances already enforced in the network and; therefore, the behavior of the network is always the expected. In contrast to the first two validations, Conflict Validation is generic for all policy types. Conflict Validation comprises of two steps, Conflict Identification and Conflict Resolution. Conflict Identification is responsible for checking if a new policy instance is in conflict with any other existing policy instances. If this is true then the role of Conflict Resolution is to decide which policy instance is to prevail. With regards to Conflict Identification, two policy instances are considered conflicting if the following conditions are met:
The dependency between Policy Conditions can be better understood with an example:
Two policies that define source and/or destination IP addresses as conditions are analyzed in 3 different scenarios:
a) Both define a different source IP address so both conditions are independent.
b) One condition defines the source IP and the other the destination IP. Applying the definition of independent policies, we see that they are dependent. In case we have traffic going from 10.0.0.1 to 10.0.0.2 both policies would match it.
The conditions of the green policy are contained within the conditions of the blue policy.
If, and only if, a conflict has been identified by the previous step, then the Policy Resolution is called by the framework. In order to resolve the identified conflict, the framework utilizes the priorities assigned to each of the conflicting policy instances. Given a conflict, one of the following scenarios can take place.
Depending on the resolution of these three validations, a policy can be in any of the following six states:
The logic that runs the different validation steps and handles the resulting state of the Policy Life-cycle is depicted in Figure 3.
When a policy is pushed to the framework by the administrator, the framework starts treating it in the New state. The first step is to convert the form of its Policy Conditions to DNF, so that the policy can be mapped to flow rules. Then, the policy goes through a formal validation process, where the policy syntax and structure are evaluated. If it does not pass this validation, the policy is moved to the Removed state (2), but if it passes the formal validation, it is moved to the Formally validated state (1). Then, conflicting actions are analyzed. In case there is any conflict, the policy is moved to the Pending state (4), waiting for new circumstances to arise (7). If there is no conflict, the policy is moved to the Conflict Validated state (3). In this case, the policy goes through a context validation process, where the application of the policy in the system is evaluated in terms of available resources. If it does not pass this validation the policy is moved to the Pending state (6), whereas if it is context validated it is moved to the Enforced state (5). Only, in this case, the policy is enforced in the underlying system. Moreover, the administrator can request to deactivate an Enforced policy (9) (i.e., move it to the Pending state), as well as to remove a Pending (8) or Enforced (10) policy (i.e., move it to the Removed state), at any time. If an Enforced policy is either removed or deactivated, it is also un-deployed from the underlying system. Finally, a policy in Pending state tries to change its state (7) in two different scenarios, depending on how they reached the Pending state:
In order to implement and validate the presented policy framework, a prototype has been developed. This prototype follows a modular approach and it is divided into two blocks:
This disaggregation between the PM and the PTs offers two advantages over a monolithic approach (everything as a single ONOS application):
Figure 4 illustrates this design in detail. Both the PM and the PTs expose a REST API, which have different purposes. The former is a Northbound interface, meant for the interaction between the administrator of the system and the PM. This API allows CRUD operations for policy instances. The latter is an internal interface that is used by the PM when the functions implemented in a particular PT have to be called. With this approach, all generic actions/requests (e.g. request for a policy status) can be addressed to the PM, hence simplifying and generalizing the implementation of new policy types.
The GET requests are used to retrieve information about the policies installed in the framework and, as mentioned above, do not involve communication with the PTs. The POST request is used to push new policies to the framework in JSON format. Since this requires the validation and enforcement of the policies, this command will trigger POST requests to the REST API of the corresponding PT. Two PUT requests are available. One is used to register a PT in the PM and the other one is used to modify the priority of a policy. This process implies that this policy has to be removed from the network and pushed again with the new priority. For this reason, this endpoint also involves the validation and enforcement of a policy and; thus, the communication with the corresponding PT. Finally, DELETE requests are used to remove or deactivate a policy from the system, or to remove a PT. All of these endpoints return error/success messages. If an error occurs, not only the type of validation error is returned, but also specific details about the error so that it can be easily fixed.
Figure 5 depicts the internal operations of the PF, with respect to the interactions between the different involved entities. First, the installation of the PM is shown in red. Since it is a native ONOS application, the commands for installation and activation are sent to the ONOS core. A similar process is drawn in green for the installation of a PT. However, this process also includes the registration process of the PT in the PM so it can be used in the future. The process in purple shows the policy instantiation process. A policy instance is pushed by the network administrator, it is validated, and then a set of OF rules are installed in the network. Finally, the id assigned to the policy instance is returned to the network administrator for administration purposes. The process of policy instance removal is shown in blue. The network administrator requests to delete a policy instance with a specific id, and then the remove endpoint of the PT is used to purge the corresponding OF rules from the network. The process in orange corresponds to the PT removal, where the network administrator communicates with ONOS core to uninstall the PT. This triggers the de-registration of that PT from the PM, which eventually removes all the policy instances and flow rules corresponding to that PT from the PM and the underlying network. Finally, the yellow process corresponds to the PM removal, which uninstalls the PM and removes all the flow rules, associated with the PF, from the network devices.
Three different PTs have been already implemented: Firewall, NAT and Connectivity
This policy type implements a simple packet-filtering firewall, which allows a network administrator to block traffic that matches a set of specified parameters.
This policy type implements a simple network address translation, which allows a network administrator to specify the address a host will have when communicating with hosts in another network.
This policy allows to control the connectivity between a pair of hosts.
Both the PM and the PTs are installed in ONOS as any other ONOS app. The only requirement is that the PM is previously installed in order to install a PT. Otherwise, a Runtime exception is thrown, as PTs are dependent on libraries/calls implemented in the PM.
Using the Policy Manager is very simple. An administrator just needs to send a REST message to any endpoint.
In order to push a new policy framework, a POST request has to be sent to http://localhost:8181/onos/policymanager/policies passing the policy in JSON format. Example:
{
"policies":
[
{
"priority":"3",
"type": "FIREWALL",
"form": "DNF",
"conditions":[[
{"variable": "src_mac",
"value": "00:0a:95:9d:68:12"}
]],
"actions":[
{"variable":"allow",
"value": "false"}]
}
]
}
This JSON represents a Policy Group, where each policy within “policies” is a Policy Rule. For each policy rule, a priority (higher value, higher priority), the type, the form (CNF or DNF), the conditions (as a list of lists understood as CNF or DNF depending on the type) and the actions (as a list) must be provided.
The reply message is another JSON that contains the HTTP response code, a list of the policy ids assigned to the pushed policies, and a list of messages, specifying for each policy the success/error message.
The returned policy id varies depending on three cases:
In order to create a new policy type, an ONOS app with a REST interface has to be created (like steps 4 and 5 of section 3.1.1). Then, in order to integrate it in the Policy Framework and be accessible by the Policy Manager, the following steps have to be performed (the order is not important):
@Activate protected void activate() { log.info("Firewall Policy started"); //The endpoint MUST match the policy type Response response = RESTtarget.path("policytype/register/firewall") .request(MediaType.APPLICATION_JSON) .put(Entity.text("")); if (response.getStatus() != Response.Status.OK.getStatusCode()){ log.info("Policy Framework not found."); throw new RuntimeException(); } log.info("Firewall policy type successfully registered."); } @Deactivate protected void deactivate() { log.info("Firewall Policy stopping"); log.info("De-registering Firewall Policy from PM"); Response response = RESTtarget.path("policytype/deregister/firewall").request(MediaType.APPLICATION_JSON).delete(); String prsJSON = response.readEntity(String.class); log.info(prsJSON); PolicyRules prs = parsePolicyRules(prsJSON); for (PolicyRule pr:prs.getPolicyRules()) { remove(pr); } log.info("Firewall Policies Deleted"); } public PolicyRules parsePolicyRules(String json) { ObjectMapper mapper = new ObjectMapper(); mapper.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES); PolicyRules policyRules = null; try { policyRules = mapper.readValue(json, PolicyRules.class); } catch (Exception e) { e.printStackTrace(); } return policyRules; }
<dependency>
<groupId>eu.ngpaas</groupId>
<artifactId>ngpaas-pm-api</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
For the new conflict validation method, an endpoint called /rules (POST) has been developed, which given a policy it returns the Forwarding Objectives that would be enforced and a list of the devices where this enforcement would happen.
Note: when installing flow rules in the network it is recommended to install them defining an Application Id based on the policy id (currently the Application ID is defined as “Policy<PolicyID>”). In this way, with the new conflict validation it is possible to know the two flow rules that are conflicting, which Policy id (and, thus, the policy type) they have. Moreover, it also simplifies the remove function, since it is possible to remove all the flow rules with a given Application id, without needing to calculate again which flow rules have to be removed.
Given that some parts of the formal validation are common for all the PTs, a helper class called PolicyHelper in the shared libraries (eu.ngpaas.pmLib) contains useful functions that can be accessed by any PT:
A simple example is in the Connectivity policy, in which a pair of source and destination addresses must be provided. However, this function allows much more complex relations.
A similar work could be done for the Context validation since in most cases it only consists of checking if a host exists or not.
Policy Manager REST API endpoints | Description | |
GET | /policies | Lists all policy instances in the framework regardless of state |
/policies/active | Lists only active policy instances | |
/policies/id/{id} | Returns the policy instance with the given id | |
/policies/state/{state} | Lists all policy instances in the given state | |
/policies/type/{type} | Lists all policy instances of a given type | |
/policies/types | Lists all registered policy types | |
/policies/num | Gets the total number of policy instances | |
/policies/activate/{id} | Activates the policy instance with the given id | |
POST | /policies | Pushes a policy instance to the framework |
PUT | /policytype/register/{pt} | Register a policy type with the given name |
/policies/{id}/priority/{np} | Changes the priority of the policy instance with the given id | |
DELETE | /policies/deactivate/{id} | Deactivates the policy instance with given id |
/policies/{id} | Deletes the policy instance with given id | |
/policies | Deletes all policy instances | |
/policytype/deregister/{pt} | Deregisters the policy type of the given name | |