From c772a1dbc7ace58d099570d41a889adf851c8ba8 Mon Sep 17 00:00:00 2001 From: Ulas Kozat Date: Mon, 28 Dec 2015 16:05:13 -0800 Subject: Added networking-sfc from openstack project with merge date Dec 23 2015 Added patch 13 for subject "add missing db migration files" Change-Id: Id51a160335a14870c1dd816a44baf9b1958b9ac6 --- doc/source/system_design and_workflow.rst | 245 ++++++++++++++++++++++++++++++ 1 file changed, 245 insertions(+) create mode 100644 doc/source/system_design and_workflow.rst (limited to 'doc/source/system_design and_workflow.rst') diff --git a/doc/source/system_design and_workflow.rst b/doc/source/system_design and_workflow.rst new file mode 100644 index 0000000..11e0849 --- /dev/null +++ b/doc/source/system_design and_workflow.rst @@ -0,0 +1,245 @@ +.. + Copyright 2015 Futurewei. All rights reserved. + + Licensed under the Apache License, Version 2.0 (the "License"); you may + not use this file except in compliance with the License. You may obtain + a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, WITHOUT + WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + License for the specific language governing permissions and limitations + under the License. + + + Convention for heading levels in Neutron devref: + ======= Heading 0 (reserved for the title in a document) + ------- Heading 1 + ~~~~~~~ Heading 2 + +++++++ Heading 3 + ''''''' Heading 4 + (Avoid deeper levels because they do not render well.) + + +========================== +System Design and Workflow +========================== + +Problem Description +=================== +The `Service Chaining API specification `_ proposes a Neutron port based solution for setting up a service chain. A specification on the system architecture and related API work flow is needed to guide the code design. + +System Architecture +============================ +The following figure shows the generic architecture of the Port Chain +Plugin. As shown in the diagram, Port Chain Plugin can be backed by +different service providers such as OVS Driver and/or different types of +SDN Controller Drivers. Through the "Common Driver API", these +different drivers can provide different implementations for the service +chain path rendering. In the first release and deployment based on this +release, we will only deliver codes for the OVS driver. In the next release, +we can add codes to support multiple active drivers:: + + Port Chain Plugin With Different Types of Drivers + +-----------------------------------------------------------------+ + | +-----------------------------------------------------------+ | + | | Port Chain API | | + | +-----------------------------------------------------------+ | + | | Port Chain Database | | + | +-----------------------------------------------------------+ | + | | Driver Manager | | + | +-----------------------------------------------------------+ | + | | Common Driver API | | + | +-----------------------------------------------------------+ | + | | | + | +------------+------------------------+---------------------+ | + | | OVS Driver | Controller Driver1 | Controller Driver2 | | + | +------------+------------------------+---------------------+ | + +-------|------------------|-------------------------|------------+ + | | | + +-----------+ +-----------------+ +-----------------+ + | OVS Agent | | SDN Controller1 | | SDN Controller2 | + +-----------+ +-----------------+ +-----------------+ + +The second figure below shows the reference implementation architecture, +which is through the OVS Driver path. The figure shows the components +that will be added on the Neutron Server and the compute nodes to +support this Neutron Based SFC functionality. As shown in the diagram, +a new Port Chain Plugin will be added to the Neutron Server. +The existing "OVS Driver" and "OVS Agent" will be extended to support +the service chain functionality. The OVS Driver will communicate with +each OVS Agent to program its OVS forwarding table properly so that a +tenant's traffic flow can be steered through the user defined sequence +of Neutron ports to get the desired service treatment from the Service +Function running on the VMs. + +A separate `OVS Driver and Agent specification `_ will describe in more +detail on the design consideration of the Driver, Agent, and how to set up the +classification rules on the OVS to identify different flows and how to +set up the OVS forwarding table. In the reference implementation, the OVS Driver +communicates with OVS Agent through RPC to program the OVS. The communication +between the OVS Agent and the OVS is through OVSDB/Openflow:: + + + Port Chain Plugin With OVS Driver + +-------------------------------+ + | +-------------------------+ | + | | Port Chain API | | + | +-------------------------+ | + | | Port Chain Database | | + | +-------------------------+ | + | | Driver Manager | | + | +-------------------------+ | + | | Common Driver API | | + | +-------------------------+ | + | | | + | +-------------------------+ | + | | OVS Driver | | + | +-------------------------+ | + +-------|----------------|------+ + | | + +-----------+ +-----------+ + | OVS Agent | | OVS Agent | + +-----------+ +-----------+ + +Port Chain Creation Workflow +============================ +The following example shows how the Neutron CLI commands may be used to +create a port-chain consisting of a service VM vm1 and a service VM +vm2. The user can be an Admin/Tenant or an Application built on top. + +Traffic flow into the Port Chain will be from source IP address +22.1.20.1 TCP port 23 to destination IP address 171.4.5.6 TCP port 100. +The flow needs to be treated by SF1 running on VM1 identified by +Neutron port pair [p1, p2] and SF2 running on VM2 identified by Neutron +port pair [p3, p4]. + +The net1 should be created before creating Neutron port using existing +Neutron API. The design has no restriction on the type of net1, i.e. it +can be any type of Neutron network since SFC traffic will be tunneled +transparently through the type of communication channels of net1. +If the transport between vSwitches is VXLAN, then we will use that VXLAN +tunnel (and NOT create another new tunnel) to transport the SFC traffic +through. If the transport between vSwitches is Ethernet, then the SFC +traffic will be transported through Ethernet. In other words, the SFC +traffic will be carried over existing transport channel between vSwitches +and the external transport channel between vSwitches is set up for net1 +through existing Neutron API and ML2. The built-in OVS backend +implements tunneling the original flow packets over VXLAN tunnel. The detailed +outer VXLAN tunnel transport format and inner SFC flow format including +how to leverage existing OVS's support for MPLS label to carry chain ID +will be described in the `Port Chain OVS Driver and Agent specification `_. +In the future we can add implementation of tunneling the SFC flow packets over +flat L2 Ethernet or L3 IP network or GRE tunnel etc. + +Boot service VMs and attach ports +--------------------------------- +Create Neutron ports on network net1:: + + neutron port-create --name p1 net1 + neutron port-create --name p2 net1 + neutron port-create --name p3 net1 + neutron port-create --name p4 net1 + +Boot VM1 from Nova with ports p1 and p2 using two --nic options:: + + nova boot --image xxx --nic port-id=p1 --nic port-id=p2 vm1 + +Boot VM2 from Nova with ports p3 and p4 using two --nic options:: + + nova boot --image yyy --nic port-id=p3 --nic port-id=p4 vm2 + +Alternatively, the user can create each VM with one VNIC and then +attach another Neutron port to the VM:: + + nova boot --image xxx --nic port-id=p1 vm1 + nova interface-attach --port-id p2 vm1 + nova boot --image yyy --nic port-id=p3 vm2 + nova interface-attach --port-id p4 vm2 + +Once the Neutron ports p1 - p4 exist, the Port Chain is created using +the steps described below. + +Create Flow Classifier +---------------------- +Create flow-classifier FC1 that matches on source IP address 22.1.20.1 +(ingress direction) and destination IP address 171.4.5.6 (egress +direction) with TCP connection, source port 23 and destination port +100:: + + neutron flow-classifier-create + --ip-version ipv4 + --source-ip-prefix 22.1.20.1/32 + --destination-ip-prefix 172.4.5.6/32 + --protocol tcp + --source-port 23:23 + --destination-port 100:100 FC1 + +Create Port Pair +----------------- +Create port-pair PP1 with ports p1 and p2, port-pair PP2 with +ports p3 and p4, port-pair PP3 with ports P5 and P6:: + + neutron port-pair-create + --ingress=p1 + --egress=p2 PP1 + neutron port-pair-create + --ingress=p3 + --egress=p4 PP2 + neutron port-pair-create + --ingress=p5 + --egress=p6 PP3 + +Create Port Group +----------------- +Create port-pair-group PG1 with port-pair PP1 and PP2, and +port-pair-group PG2 with port-pair PP3:: + + neutron port-pair-group-create + --port-pair PP1 --port-pair PP2 PG1 + neutron port-pair-group-create + --port-pair PP3 PG2 + +Create Port Chain +----------------- + +Create port-chain PC1 with port-group PG1 and PG2, and flow +classifier FC1:: + + neutron port-chain-create + --port-pair-group PG1 --port-pair-group PG2 --flow-classifier FC1 PC1 + +This will result in the Port chain driver being invoked to create the +Port Chain. + +The following diagram illustrates the code execution flow (not the +exact codes) for the port chain creation:: + + PortChainAPIParsingAndValidation: create_port_chain + | + V + PortChainPlugin: create_port_chain + | + V + PortChainDbPlugin: create_port_chain + | + V + DriverManager: create_port_chain + | + V + portchain.drivers.OVSDriver: create_port_chain + +The vSwitch Driver needs to figure out which switch VM1 is connecting +with and which switch VM2 is connecting with (for OVS case, the OVS +driver has that information given the VMs' port info). As to the +connection setup between the two vSwitches, it should be done through +existing ML2 plugin mechanism. The connection between these two +vSwitches should already be set up before the user initiates the SFC +request. The service chain flow packets will be tunneled through the +connecting type/technology (e.g. VXLAN or GRE) between the two +vSwitches. For our reference code implementation, we will use VXLAN to +show a complete data path setup. Please refer to the `OVS Driver and OVS +Agent specification `_ for more detail info. + -- cgit 1.2.3-korg