Difference between revisions of "Neutron/ServiceInsertionAndChaining"
(→Current Design Discussions) |
Paul Carver (talk | contribs) (→Overview) |
||
| Line 1: | Line 1: | ||
= Overview = | = Overview = | ||
| − | + | Service Function Chaining is a mechanism for overriding the basic destination based forwarding that is typical of IP networks. It is conceptually related to [https://en.wikipedia.org/wiki/Policy-based_routing Policy Based Routing] in physical networks but it is typically thought of as a Software Defined Networking technology. It is often used in conjunction with security functions although it may be used for a broader range of features. Fundamentally SFC is the ability to cause network packet flows to route through a network via a path other than the one that would be chosen by routing table lookups on the packet's destination IP address. It is most commonly used in conjunction with [https://en.wikipedia.org/wiki/Network_functions_virtualization Network Function Virtualization] when recreating in a virtual environment a series of network functions that would have traditionally been implemented as a collection of physical network devices connected in series by cables. | |
| − | + | A very simple example of a service chain would be one that forces all traffic from point A to point B to go through a firewall even though the firewall is not literally between point A and B from a routing table perspective. | |
| − | + | ||
| + | A more complex example is an ordered series of functions, each implemented in multiple VMs, such that traffic must flow through one VM at each hop in the chain but the network uses a hashing algorithm to distribute different flows across multiple VMs at each hop. | ||
| + | |||
| + | An API and initial reference implementation of Service Function Chaining is being developed for Neutron during the Liberty cycle. | ||
| + | |||
| + | * The API specification may be found here: https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst | ||
| + | * The Blueprint for the overall effort may be found here:https://blueprints.launchpad.net/neutron/+spec/openstack-service-chain-framework | ||
| + | * The Blueprint for the initial API work may be found here: https://blueprints.launchpad.net/neutron/+spec/neutron-api-extension-for-service-chaining | ||
| + | * The reviews related to the initial API work may be found here: https://review.openstack.org/#/q/topic:networking-sfc,n,z | ||
| + | |||
| + | The initial reference implementation will be based on programming Open vSwitch with flow table entries that override the default MAC based forwarding and instead forward frames based on criteria defined via the Neutron SFC API. It will also be possible for third party SDN implementations with Neutron integration and SFC capabilities (e.g. Contrail, Nuage, etc) to program their respective forwarding planes based on the Neutron SFC API, but this will be dependent upon the respective vendors updating their Neutron integration. | ||
Revision as of 02:19, 24 July 2015
Overview
Service Function Chaining is a mechanism for overriding the basic destination based forwarding that is typical of IP networks. It is conceptually related to Policy Based Routing in physical networks but it is typically thought of as a Software Defined Networking technology. It is often used in conjunction with security functions although it may be used for a broader range of features. Fundamentally SFC is the ability to cause network packet flows to route through a network via a path other than the one that would be chosen by routing table lookups on the packet's destination IP address. It is most commonly used in conjunction with Network Function Virtualization when recreating in a virtual environment a series of network functions that would have traditionally been implemented as a collection of physical network devices connected in series by cables.
A very simple example of a service chain would be one that forces all traffic from point A to point B to go through a firewall even though the firewall is not literally between point A and B from a routing table perspective.
A more complex example is an ordered series of functions, each implemented in multiple VMs, such that traffic must flow through one VM at each hop in the chain but the network uses a hashing algorithm to distribute different flows across multiple VMs at each hop.
An API and initial reference implementation of Service Function Chaining is being developed for Neutron during the Liberty cycle.
- The API specification may be found here: https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst
- The Blueprint for the overall effort may be found here:https://blueprints.launchpad.net/neutron/+spec/openstack-service-chain-framework
- The Blueprint for the initial API work may be found here: https://blueprints.launchpad.net/neutron/+spec/neutron-api-extension-for-service-chaining
- The reviews related to the initial API work may be found here: https://review.openstack.org/#/q/topic:networking-sfc,n,z
The initial reference implementation will be based on programming Open vSwitch with flow table entries that override the default MAC based forwarding and instead forward frames based on criteria defined via the Neutron SFC API. It will also be possible for third party SDN implementations with Neutron integration and SFC capabilities (e.g. Contrail, Nuage, etc) to program their respective forwarding planes based on the Neutron SFC API, but this will be dependent upon the respective vendors updating their Neutron integration.
