Date: Thu, 28 Mar 2024 11:31:35 +0000 (UTC) Message-ID: <1228685884.733.1711625495369@ip-10-30-146-46.us-west-2.compute.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_732_979965703.1711625495369" ------=_Part_732_979965703.1711625495369 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The goal is to implement the composit= ion feature for ONOS. It will allow ONOS to run multiple applications concu= rrently and ONOS will automatically resolve conflicts that may arise from t= hese applications. We will support the following three composition operator= s:
Parallel operator (+):= strong> The parallel composition of two application P + Q operates by logically (though not necess= arily physically) copyi= ng the packet, applying P to one copy and Q to the other, and taking the union of the results.&nbs= p;For example, let P be a mo= nitoring policy and Q be a routing policy. If P counts packets based on source IP prefix and Q for= wards packets based on = destination IP prefix, P + Q does both operations on all packets.
Sequential operator (>>): The sequential operator= enables two controllers to pr= ocess traffic one after another. For example, let P be a load-balancing policy, and let Q be a&nbs= p;routing policy. More speci= fically, for packets destined to anycast IP address 3.0.0.0, P = rewrites the destination IP to a se= rver replica's IP based on source IP prefix, and Q forwards packets based on destination IP prefix= . To obtain the combine= d behavior of P and Q---to first rewrite the destination IP address and then forward the rewritten= packet to the correct place=E2=80=94the network administrator uses the policy P >> Q.
Override operator (|>): Each controller x provides ONOS with a member policy speci= fying how x wants the n= etwork to process packets. The policy x |> T attempts to apply x's member policy to any incomin= g packet t. If x's policy does not specify how to handle t, then T is used as a default. For examp= le, suppose one control= ler x is running an elephant flow routing application and another controller y is running an infra= structure routing application. If we want x to override y for elephant flow packets, y to route al= l regular traffic, and = any packet not covered by either policy to be dropped, we use the policy x = |> (y |> drop).= span>
The implementation will include sev= eral components which will be contained in an experimental package on the m= aster branch.
Policy Interface Definition= : This component exposes an API for the network admin to conf= igure the composition policy. It interprets the composition policy and conf= igures ONOS to perform composition based on the policy.
FlowRuleService Implementation: The existing FlowRuleManager receives flo= w rules from applications and maintains a flow table for each switch, where= the primary partition resides on the same instance as the switch's master.= The FlowRuleManager component will be copied and= extended to include the following:
Composition Library: Thi= s stateless library (adapted from CoVisor) has access to the application an= d intermediate flow tables as well as the policy.
Switch Rule Installation: This component installs OpenFlow rules to physical switches, sends barrie= r request messages, and receives barrier reply messages. Since a rule = from an application may generate multiple rules for a physical switch, we s= end confirmation to the application until we receive barrier reply mes= sages for all the generated rules.
createPolicy(String policy): We use a string to re= present the policy. It will be interpreted by ONOS and is used to configure= the composition. Example: createPolicy("Monitor + Router").