Introduction

The goal is to implement the composition feature for ONOS. It will allow ONOS to run multiple applications concurrently and ONOS will automatically resolve conflicts that may arise from these applications. We will support the following three composition operators:

Parallel operator (+): The parallel composition of two application P + Q operates by logically (though not necessarily physically) copying the packet, applying P to one copy and Q to the other, and taking the union of the results. For example, let P be a monitoring policy and Q be a routing policy. If P counts packets based on source IP prefix and Q forwards packets based on destination IP prefix, P + Q does both operations on all packets.

Sequential operator (>>): The sequential operator enables two controllers to process traffic one after another. For example, let P be a load-balancing policy, and let Q be a routing policy. More specifically, for packets destined to anycast IP address 3.0.0.0, P rewrites the destination IP to a server replica's IP based on source IP prefix, and Q forwards packets based on destination IP prefix. To obtain the combined behavior of P and Q---to first rewrite the destination IP address and then forward the rewritten packet to the correct place—the network administrator uses the policy P >> Q.

Override operator (|>): Each controller x provides ONOS with a member policy specifying how x wants the network to process packets. The policy x |> T attempts to apply x's member policy to any incoming packet t. If x's policy does not specify how to handle t, then T is used as a default. For example, suppose one controller x is running an elephant flow routing application and another controller y is running an infrastructure routing application. If we want x to override y for elephant flow packets, y to route all regular traffic, and any packet not covered by either policy to be dropped, we use the policy x |> (y |> drop).

Component

Interface: This component exposes an API for the network admin to configure the composition policy. It interprets the composition policy and configures ONOS to perform composition based on the policy.

Flow Rule Management: This component receives flow rules from each application. It maintains a policy tree to remember all the flow tables of each application and intermediate nodes. The root of the tree contains the flow table of the switch.

Switch Rule Installation: This component installs OpenFlow rules to physical switches, sends barrier request messages, and receives barrier reply messages. Since a rule from an application may generate multiple rules for a physical switch, we send confirmation to the application until we receive barrier reply messages for all the generated rules.

API

createPolicy(String policy): We use a string to represent the policy. It will be interpreted by ONOS and is used to configure the composition. Example: createPolicy("Monitor + Router").