From patchwork Tue Dec 27 22:11:44 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John McDowall X-Patchwork-Id: 709113 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3tp9pJ2CR7z9t0m for ; Wed, 28 Dec 2016 09:41:44 +1100 (AEDT) Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id EB67395E; Tue, 27 Dec 2016 22:40:14 +0000 (UTC) X-Original-To: dev@openvswitch.org Delivered-To: ovs-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F1E2893E for ; Tue, 27 Dec 2016 22:40:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail30c40.carrierzone.com (mail30c40.carrierzone.com [209.235.156.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E14F5141 for ; Tue, 27 Dec 2016 22:40:07 +0000 (UTC) X-Authenticated-User: john.mcdowall.com Received: from localhost.localdomain ([199.167.55.50]) (authenticated bits=0) by mail30c40.carrierzone.com (8.14.9/8.14.9) with ESMTP id uBRMBnJt014107; Tue, 27 Dec 2016 22:11:59 +0000 From: John McDowall To: dev@openvswitch.org Date: Tue, 27 Dec 2016 14:11:44 -0800 Message-Id: <3b2de8b86e3d7b08a318320ebf416d6c5ad907c9.1482874169.git.jmcdowall@paloaltonetworks.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <9b2deaf71fd094c41e8ba2a74d9db3a48d4db9a3.1482874169.git.jmcdowall@paloaltonetworks.com> References: <9b2deaf71fd094c41e8ba2a74d9db3a48d4db9a3.1482874169.git.jmcdowall@paloaltonetworks.com> In-Reply-To: References: X-CTCH-RefID: str=0001.0A010204.5862E730.0013, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.2 cv=eKZjtDh1 c=1 sm=1 tr=0 a=hHPLsF2s57XWilXSBaWDGg==:117 a=hHPLsF2s57XWilXSBaWDGg==:17 a=n9OnpkR2AAAA:8 a=SGADynmgAAAA:8 a=fE96FHpdAAAA:8 a=BGDSmYTKtnbQ3OQw98oA:9 a=-ljFsvRusiAbVWph:21 a=qwraW3URUbOpc3JW:21 a=RFQGswWORRGXZzP9:21 a=wkciDmZbm64A:10 a=GEBZpoAfm-0A:10 a=nZwUGa2FY5DoeBLS5moG:22 a=zIHXHKGEX091kyoLcxqF:22 a=pgi6P_vP06QAnjKcxqsl:22 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: John McDowall Subject: [ovs-dev] [RFC PATCH 3/5] Included architecture of SFC in documentation X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: ovs-dev-bounces@openvswitch.org Errors-To: ovs-dev-bounces@openvswitch.org This a write up of the architecture. It needs updating bu the basics are correct. Co-authored-by: Flavio Fernandes Reported at: https://mail.openvswitch.org/pipermail/ovs-discuss/2016-March/040381.html Reported at: https://mail.openvswitch.org/pipermail/ovs-discuss/2016-May/041359.html Signed-off-by: John McDowall --- ovn/ovn-architecture.7.xml | 185 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 185 insertions(+) diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml index d96e4b141..73342f2e0 100644 --- a/ovn/ovn-architecture.7.xml +++ b/ovn/ovn-architecture.7.xml @@ -381,6 +381,13 @@ switch. Logical switches and routers are both implemented as logical datapaths. + +
  • + Logical services are logical references to virtual network functions + (VNF). Adding a logical service requires adding steering rules to the OVN Northbound + database. These are the only rules necessary to implement traffic steering for VNFs. + The section below "Life Cycle of an inserted VNF" provides more details. +

    • Life Cycle of a VIF

    @@ -536,6 +543,184 @@ +

    Life Cycle of an inserted Virtual Network Function (VNF)

    + +

    + OVN provides an abstraction to enable the insertion of an arbitrary virtual network + function (VNF) into the path of traffic to and from an application. A VNF is different + from an application VM in that it acts on traffic between applications, and im most + cases does not terminiate a flow. Proxy functions are an exception as they terminate the + flow from the src and create a new flow to the dst. Examples of VNF's are security functions, + load balancing, and traffic enhancement services, this is not a complete list. +

    +

    + The requirements on the VNF to be inserted are minimal, it must + act as a bump in the wire (BITW) and can have one or two virtual network + ports for traffic. If it has two network ports traffic is directed into one and out the other, + if it has only one port, then traffic is bi-directional. The requirement for the VNF to act as + a BITW removes the need for the VNF to participate in L3/L2 networking which provides + improved agility and reduces the coupling between OVN and the VNF. +

    +

    + The service insertion is implemented by adding 4 new flow rules into the ovn-nb database for + each VNF inserted. The rules are added into the last table in the ingress path (L2_LKUP). + The service insertion rules have a higher priority than the standard forwarding rules. + This means that they override the existing forwarding rules. There are four + new rules added for each insertion. Two ingress and two egress, The first ingress + rule sends all traffic destined for the application into the VNF ingress port and the + second rule takes all traffic destined to the application from the VNF egress port + to the application, the priorities are such that the second rule is always checked + first. In the egress direction the rules are similar if the traffic is from the + application it is sent to the VNF egress port and if if is from the application + and is from the VNF ingress port it is delivered to the destination. + +

    +

    + The steps in this example refer to the details of the OVN Northbound database schema. + There is a new table in the OVN Northbound database to support service insertion + called Services this contains the required information for each new + service inserted. The same service can be used for multiple applications, as + there is typically a n:1 relationship between applications and VNFs. A + single VNF may be part of several service insertions, but each one is logically + separate. +

    +

    + The steps in this example refer often to details of the OVN and OVN + Northbound database schemas. Please see ovn-sb(5) and + ovn-nb(5), respectively, for the full story on these + databases. The ovn-nb database has specific schema enhancements for the service + insertion function. The ovn-sb database has no schema changes for the + service insertion function. +

    +

    + The following steps are an overview to inserting a new VNF into the traffic path. + The sections below go into each step in more detail. +

    +
      +
    1. + The service insertion lifecycle begins when a CMS administrator creates a new + virtual network function (VNF) using the CMS user + interface or API. The CMS administrator creates the logical ports (ingress and egress) + for the VNF. If the CMS is Openstack this will create a reusable port-pair defining the + interface to the VNF. There is also typically a seperate management port for the VNF, + but that is not relevant to the service insertion workflow. A single VNF can + participate with several applications, either as a security VM, protecting multiple + applications or as a load balancer VM, distributing load across multiple applications. +
      2. + +
    2. + The next step in the life cycle occurs when a CMS administrator creates a new application + with a VIF using the CMS user interface or API and adds it to a switch (one + implemented by OVN as a logical switch). Alternatively an already running application could + be used. + + The CMS can now attach the port pair to the VIF by defining the logical port in the + service function classifier. This will direct traffic to the VIF to go through + the VNF, applying the rules discussed earlier. +
      3. + +
    3. + While within CMS the service insertion may be broken down into multiple reusable steps + (as is the case with Openstack). Within OVN the creating of a new service insertion + is treated as an atomic operation. This enables the easy atomic insertion and deletion of + service insertions. This is important as it is envisioned that the number of serivce + insertions can easily number in the hundreds, all with separate lifecycles. For each new + service insertion operation a new row is added to the OVN Northbound Database. The new row is + only added to the ovn-nb when the VNF, application and network are enabled by the CMS. + + Once the serivce insertion is applied to the ovn-nb database, the ovn-nb controller will be + notified of a change and the rules will be pushed down to the specific OVS instances, using + the existing OVN mechanisms. It is important to note here that the logical abstraction of + OVN enables service insertion with minimal changes. +
      4. + +
    4. + When the application VM shuts down the classification rule should be removed, however as + no traffic will be destinated to the application there would be no issues. If the VM is + being moved and the new application VM port is used to update the service then the change + would be detected and the rules pushed down. +
      5. +
    5. + A VNF can be removed at any time and traffic flows will revert to the pre-VNF traffic + paths if it is removed from the ovn-nb database. OVN must detect that the VNF has been + shut-off as it must remove all the rules that are attached to that VNF. Otherwise + traffic loss will occur, if a failure in a VNF occurs that is not detected. +
      6. + +
    6. + On every hypervisor, ovn-controller receives the + Logical_Service table updates that ovn-northd made + in the previous step. As long as the VM that owns the VIF is powered + off, ovn-controller cannot do much; it cannot, for example, + arrange to send packets to or receive packets from the VIF, because the + VIF does not actually exist anywhere. In addition the VNF cannot be inserted + into the traffic path as it will have no source to forward traffic too. + +
      7. + +
    7. + Some CMS systems, including OpenStack, fully start a VM only when its + networking is ready. To support this, ovn-northd notices + the chassis column updated for the row in + Binding table and pushes this upward by updating the + column in the OVN + Northbound database's table to + indicate that the VIF is now up. The CMS, if it uses this feature, can + then react by allowing the VM's execution to proceed. + + Traffic now flows into and out of the VM that has a VNF inserted in its + datapath. The rules are applied to direct traffic to the VNF on the way + into the VM and on the way out of the VM. +
      8. + + + +
    8. + On every hypervisor but the one where the VIF resides, + ovn-controller notices the completely populated row in the + Binding table. This provides ovn-controller + the physical location of the logical port, so each instance updates the + OpenFlow tables of its switch (based on logical datapath flows in the OVN + DB Logical_Flow table) so that packets to and from the VIF + can be properly handled via tunnels. +
      9. + + +
    9. + Eventually, a user removes the inserted service function from the ovn nb + database. The rules are then updated in the southbound database and pushed + down to the relevant ovs. No other SIF is impacted as the row in the ovn nb + is independant of all the other SIF. + +
      10. + +
    10. + The CMS plugin removes the SIF from the OVN Northbound database, + by deleting its row in the Logical_Service table. +
      11. + +
    11. + ovn-northd receives the OVN Northbound update and in turn + updates the OVN Southbound database accordingly, by removing or updating + the rows from the OVN Southbound database Logical_Service table. +
      12. + +
    12. + On every hypervisor, ovn-controller receives the + Logical_Service table updates that ovn-northd made + in the previous step. ovn-controller updates OpenFlow + tables to reflect the update. The datapath for the VM will now revert to + paths that existed before the VNF was inserted into the data path. +
      13. +
    +

    Life Cycle of a Container Interface Inside a VM