.. This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode ================================================= Neutron service Function Chaining using open-flow ================================================= URL of the launchpad blueprint: [TODO:] Create & add BluePrint URL [[ Ex: https://blueprints.launchpad.net/neutron/+spec/neutron-service-chaining ]] Service function chaining can be defined as an ordered set of service functions that must be applied to packets selected as a result of classification - that is, applying specific services in a pre-defined order for selected traffic. This blueprint proposes a solution to enhance neutron's capibility for providing service function chaining using open-flow. Problem description =================== With network function virtualization (NFV), network services are virtualized and thus could be scattered and deployed anywhere in the network. There is a need to chain these advanced network services (firewall, loadbalancer) through neutron API in openstack network. For example selected traffic must be validated by the firewall first and then sent to the load-balancer for steering to the appropriate destination for processing. Current OpenStack framework does not provides a provision for doing this. Our proposed solution provides a better and an easier approach for achieving service function chaining with minimal complexities using service function pool and open-flow protocol. Moreover, there is no need for the user to be familar with the complexities of open-flow protocol as the solution will hide all the complexities. The solution is simple and can be used in any topology and scenario. Proposed change =============== Our proposed solution will be using open-flow for achieving service function chaining. In this approach we will define a new service-chain plugin using the advanced service framework and use the existing open-flow client for adding/deleting open-flow rules to the open-VSwitch. The flow rules will be based on the user defined service function chain and help to classify and steering the data traffic to the next advanced services as per the service function chain definition. For achieving this we need to have 1. An API to create/delete service function pool (i.e. pool for advanced services like firewall, load-balancer, etc). 2. An API to associate/disassociate an service function instance to/from the service function pool. 3. An API to create/delete flow classifier match rules. 4. An API to create/delete/update service function chain. 5. Database updates (new resources) to support above API's. Alternatives ------------ This blueprint does not mandate that the proposed technology should only to be used for achiving service function chaining. The same may be achieved using service base and insertion [1]_, service insertion [2]_ and traffic steering [3]_. Data model impact ----------------- The following new resources are proposed: 1. ServiceFunctionPool +---------+------+-------+---------+-----------+-------------------+ |Attribute|Type |Access |Default |Validation/|Description | |Name | | |Value |Conversion | | +=========+======+=======+=========+===========+===================+ |id |string|RO, all|generated|N/A |identity | | |(UUID)| | | | | +---------+------+-------+---------+-----------+-------------------+ |name |string|RW, all|'' |string |human-readable | | | | | | |name | +---------+------+-------+---------+-----------+-------------------+ |type |string|RW, all|required |string |service function | | | | | | |types (Ex: FW, LB) | +---------+------+-------+---------+-----------+-------------------+ 2. ServiceFunctionPoolInstance +-------------+------+-------+---------+-------------------+-----------------+ |Attribute |Type |Access |Default |Validation/ |Description | |Name | | |Value |Conversion | | +=============+======+=======+=========+===================+=================+ |id |string|RO, all|generated|N/A |identity | | |(UUID)| | | | | +-------------+------+-------+---------+-------------------+-----------------+ |pool_Id |string|RW, all|required |foreign-key |service | | |(UUID)| | |for |function | | | | | |ServiceFunctionPool|pool id | +-------------+------+-------+---------+-------------------+-----------------+ |name |string|RW, all|'' |string |human-readable | | | | | | |name | +-------------+------+-------+---------+-------------------+-----------------+ |sf_Id |string|RW, all|'' |string |existing service | | |(UUID)| | | |function id | +-------------+------+-------+---------+-------------------+-----------------+ 3. MatchRule +---------+-------+-------+---------+-----------+------------------------+ |Attribute|Type |Access |Default |Validation/|Description | |Name | | |Value |Conversion | | +=========+=======+=======+=========+===========+========================+ |id |string |RO, all|generated|N/A |identity | | |(UUID) | | | | | +---------+-------+-------+---------+-----------+------------------------+ |name |string |RW, all|'' |string |human-readable | | | | | | |name | +---------+-------+-------+---------+-----------+------------------------+ |protocol |string |RW, all|'' |string |protocol type | | | | | | |(Ex:icmp, tcp, udp, arp)| +---------+-------+-------+---------+-----------+------------------------+ |src-port |number |RW, all|'' |string |Source port address | +---------+-------+-------+---------+-----------+------------------------+ |dst-port |number |RW, all|'' |string |Destination port address| +---------+-------+-------+---------+-----------+------------------------+ 4. ServiceFunctionChain +-------------+-------+-------+---------+-----------------+------------------+ |Attribute |Type |Access |Default |Validation/ |Description | |Name | | |Value |Conversion | | +=============+=======+=======+=========+=================+==================+ |id |string |RO, all|generated|N/A |identity | | |(UUID) | | | | | +-------------+-------+-------+---------+-----------------+------------------+ |name |string |RW, all|'' |string |human-readable | | | | | | |name | +-------------+-------+-------+---------+-----------------+------------------+ |chain |string |RW, all|required |list of string |service function | | | | | | |types (Ex: FW, LB)| +-------------+-------+-------+---------+-----------------+------------------+ |rule_Id |string |RW, all|'' |foreign-key |packet classify | | |(UUID) | | |for MatchRule |rule | +-------------+-------+-------+---------+-----------------+------------------+ NOTES: 1. In future, MatchRule attributes can be extended for supporting other filtering options. USAGE WORKFLOW: +----------------------------------------------------------+ | | | +------------------+ +------------------+ | | | | | | | | | +----+ +----+ | | +----+ +----+ | | | | | FW | | FW | | | | LB | | LB | | | | | | 1 | | 2 | | | | 1 | | 2 | | | | | +----+ +----+ | | +----+ +----+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +----------+ OVS1 +---------------+ OVS2 +-----------+ | | +------------+ | | +------------+ | | | | N1 | | N2 | | | +------------------+ +------------------+ | | | +----------------------------------------------------------+ 1. Assume a topology in which a neutron Networks N1, N2 is connected via an open-vSwich. Moreover, advanced services like Firewall FW1, FW2 and Loadbalancer LB1, LB2 are running inside N1 and N2 respectively. 2. Lets say one want to steer traffic first to the firewall (FW1, FW2) and then to a load-balancer (LB1, LB2) as per the service logic. 3. This can be achieved as follws. a. Create service chain pool for the required service functions (in our case we need the pool for FW and LB). neutron sf-pool-create --type FW neutron sf-pool-create --type LB b. Add service function instances to the service function pool. neutron sf-pool-inst-associate --pool_Id fw_sfpool_uuid --sf_Id fw1_uuid neutron sf-pool-inst-associate --pool_Id fw_sfpool_uuid --sf_Id fw2_uuid neutron sf-pool-inst-associate --pool_Id lb_sfpool_uuid --sf_Id lb1_uuid neutron sf-pool-inst-associate --pool_Id lb_sfpool_uuid --sf_Id lb2_uuid c. Create service function chain. neutron sf-chain-create --chain "FW,LB" 4. If one want to set flow classifier rule/s for a service function chain then the below mentioned steps can be followed. (Ex: Let's say one want to apply service function chaining only for "tcp steams destined for port 100" and "udp streams with source port 50".) a. Create match rules. neutron sf-matchrule-create --protocol tcp --dst-port 100 neutron sf-matchrule-create --protocol udp --src-port 50 b. Apply flow classifier rules to the service function chain. neutron sf-chain-update --sf_chain_Id sf_chain_uuid --rule_Id rule_uuid1 --rule_Id rule_uuid2 5. After the configuration is done, required open-flow tables are modified at the OVS. REST API impact --------------- 1. CRUD for ServiceFunctionPool 2. CRUD for ServiceFunctionPoolInstance 3. CRUD for MatchRule 4. CRUD for ServiceFunctionChain Security impact --------------- CRUD API is provided using existing API model, no new surface is exposed. Service function configuration is provided by underlying services, so no new surface is exposed. Notifications impact -------------------- No notification impact is expected. Other end user impact --------------------- 1. The CLI/UI impact of this new API (not captured in this blueprint) Performance Impact ------------------ No significant performance impact is expected. Other deployer impact --------------------- No other deployment impacts are expected Developer impact ---------------- No developer impact is expected. Implementation ============== Assignee(s) ----------- The following people are working on several different aspects of the proposed framework: Dongfeng Dhruv Dhody Vikram Choudhary Work Items ---------- 1. Build API 2. Update Datamodel 3. Build unit-tests 4. Update documentation Dependencies ============ None Testing ======= Unit Tests will be provided. Documentation Impact ==================== Documentation will need to be updated for: 1. Services chain model and usage References ========== .. [1] Neutron Service Chaining https://review.openstack.org/#/c/93524 .. [2] Service Insertion blueprint: https://review.openstack.org/#/c/93128 .. [3] Traffic Steering blueprint: https://review.openstack.org/#/c/92477