Support for Service Function Chaining in Murano

One of the foundations for NFV enabled clouds is to have Networking
Service Function Chaining which provides an ability to define an ordered
list of network services which to form a “chain” of services.
This could be used by f.e. Telcos to simplify management of their
infrastructure.

Implements blueprint: plugin-networking-sfc
Change-Id: I2fff8f01949a708e0251ad860fbd0a238c9e92fc
This commit is contained in:
Bartosz Kupidura 2016-06-02 15:36:11 +02:00 committed by Alexander Saprykin
parent 31a29de0cc
commit 27d7aa3b80
1 changed files with 394 additions and 0 deletions

View File

@ -0,0 +1,394 @@
===============================================
Support for Service Function Chaining in Murano
===============================================
One of the foundations for NFV enabled clouds is to have Networking Service
Function Chaining which provides an ability to define an ordered list of
network services which to form a “chain” of services. This could be used by
f.e. telcos to simplify management of their infrastructure.
Problem description
===================
Service chaining allow to pass traffic from endpoint A to endpoint B thru any
number of additional network service VMs. Those VMs are managed by tenant
admin.
With standard OpenStack networking traffic goes directly from A to B::
+--------+ +--------+
| VM A |-->| VM B |
+--------+ +--------+
With SFC traffic goes thru additional hops, which can perform any action
(firewall, LB, ...)::
+------+ +-------+ +-------+ +-------+ +------+
| | |Service| |Service| |Service| | |
| VM A |-->| VM A |-->| VM B |-->| VM C |-->| VM B |
+------+ +-------+ +-------+ +-------+ +------+
Those service VMs are transparent for end-user.
To achieve this, it would require to extend some of the OpenStack components.
Murano is suitable for defining such chains, but currently lacks of necessary features.
SFC use few entities to deliver chaining:
* Port pair
Represents vNIC (ingress/input, egress/output) attached to service VM.
Those vNICs will be used to receive (ingress) and send (egress) SFC traffic.
* Port group
Represents list of port pairs of different VMs with the same service function.
* Flow classifier
Used to classify network traffic, based on different metrics (e.g. source IP,
destination IP, source port, destination port, ...).
Only traffic which matches flow classifier will be handled by SFC.
* Port chain
Represents a releationship between flow classifiers and port groups.
To be able to use NFV functionality it is needed to have Service Chaining
functionality available in OpenStack.
Neutron does not support Networking SFC out of the box.
Currently Heat does not support configuration for Networking SFC API.
Currently Murano does not support Networking SFC management at all.
If we want to use Murano as a Resource Orchestrator it needs to have support
for configuring Service Chaining.
.. note::
Networking-SFC caveats:
* Current SFC implementation is not mature
* Supports only Open vSwitch
* API under heavy development
* Multiple API limitations
* No ready service VM software (capture SFC traffic, do *thing*, pass SFC
traffic to next hop)
Proposed change
===============
To solve problems above it is needed to introduce changes in Murano.
Having Murano as a Resource Orchestrator we need to have an ability to
configure Networking SFC from within Murano application templates.
This involves to implement changes in several areas.
Murano will be extended with:
* `Murano plugin`_ that will provide Networking SFC class which will be
a wrapper for lower level Neutron API.
* `Murano library package`_ that will provide Murano PL classes for
Networking SFC entities (e.g. PortPair, PortPairGroup, etc.)
Murano plugin
-------------
A python plugin that provides low-level wrappers for Neutron API functions
which are provided by Networking SFC extension. It implements direct method
wrappers for neutronclient library:
.. note:: Interface may change in the future
* ``createPortPair``
* ``deletePortPair``
* ``listPortPairs``
* ``showPortPair``
* ``updatePortPair``
* ``createPortPairGroup``
* ``deletePortPairGroup``
* ``listPortPairGroups``
* ``showPortPairGroup``
* ``updatePortPairGroup``
* ``createFlowClassifier``
* ``deleteFlowClassifier``
* ``listFlowClassifiers``
* ``showFlowClassifier``
* ``updateFlowClassifier``
* ``createPortChain``
* ``deletePortChain``
* ``listPortChains``
* ``showPortChain``
* ``updatePortChain``
Murano library package
----------------------
Application developer should have a possibility to configure Networking SFC
entities from Murano PL classes. We will introduce Murano plugin which will
extend to support configuration of following SFC classes:
* Port Pair
* Port Pair Group
* Flow Classifier
* Port Chain
All above parameters should be provided to successfully configure application
chaining. This should be done in Murano template for meta application
responsible for provisioning whole set of applications. Only mandatory SFC
parameters should be available for editing in Murano application UI.
PortPair class
~~~~~~~~~~~~~~
A Port Pair represents a service function instance. The ingress port and the
egress port of the service function may be specified. If a service function
has one bidirectional port, the ingress port has the same value as the egress
port.
**Properties:**
* ``id`` - Port pair ID
* ``name`` - Port pair name (Default: '')
* ``description`` - Readable description (Default: '')
* ``ingressPort`` - Ingress port (Reference to NeutronPort object)
* ``egressPort`` - Egress port (Reference to NeutronPort object)
.. note:: ingressPort and egressPort need to be changed to references once
Murano Core Library has support of network objects.
**Methods:**
* ``PortPair.deploy()`` - Create port pair object
* ``PortPair..destroy()`` - Cleanup resources (called implicitly)
**Example:**
.. code-block:: yaml
Namespaces:
=: com.example
netsfc: io.murano.extensions.networkingSfc
Name: DemoApp
Properties:
...
portPair: $.class(netsfc:PortPair).notNull()
Methods:
deploy:
Body:
- ...
- $.portPair.deploy()
PortPairGroup class
~~~~~~~~~~~~~~~~~~~
Inside each "port-pair-group", there could be one or more port-pairs.
Multiple port-pairs may be included in a "port-pair-group" to allow the
specification of a set of functionally equivalent SFs that can be be used for
load distribution, i.e., the "port-pair" option may be repeated for multiple
port-pairs of functionally equivalent SFs.
**Properties:**
* ``id`` - Port pair group ID
* ``name`` - Readable name (Default: '')
* ``description`` - Readable description (Default: '')
* ``portPairs`` - List of PortPair class objects.
**Methods:**
See `PortPair class`_
Example:
.. code-block:: yaml
Name: DemoApp
Properties:
...
portPairs: [$.class(netsfc:PortPair).notNull()]
Methods:
deploy:
Body:
- ...
- $.portPairGroup: new(netsfc:PortPairGroup, portPairs => $.portPairs)
- $.portPairGroup.deploy()
FlowClassifier class
~~~~~~~~~~~~~~~~~~~~
Flow classifiers are used to select the traffic that can access the chain.
Traffic that matches any flow classifier will be directed to the first port
in the chain. The flow classifier will be a generic independent module and
may be used by other projects like FW, QOS, etc.
A flow classifier cannot be part of two different port-chains otherwise
ambiguity will arise as to which chain path that flow's packets should go.
A check will be made to ensure no ambiguity. But multiple flow classifiers
can be associated with a port chain since multiple different types of flows
can request the same service treatment path.
**Properties:**
* ``name`` - Classifier name
* ``ethertype`` - IPv4 (default) / IPv6
* ``protocol`` - IP protocol
* ``sourcePortRange`` - Source protocol port; port number or tuple of min and
max ports
* ``destinationPortRange`` - Destination protocol port; port number or tuple of
min and max ports
* ``sourceIpPrefix``
* ``destinationIpPrefix``
* ``logicalSourcePort`` - neutron source port (required)
* ``logicalDestinationPort`` - neutron destination port (required)
* ``l7Parameters`` - dictionary of L7 parameters (not used)
**Methods:**
See `PortPair class`_
PortChain class
~~~~~~~~~~~~~~~
A Port Chain is a directional service chain. The first port of the first
port-pair is the head of the service chain. The second port of the last
port-pair is the tail of the service chain. A bidirectional service chain would
be composed of two unidirectional Port Chains.
**Properties:**
* ``id`` - Port chain ID
* ``name`` - Readable name
* ``description`` - Readable description
* ``portPairGroups`` - List of PortPair class objects
* ``flowClassifiers`` - List of FlowClassifier class objects
**Methods:**
See `PortPair class`_
Delivering Murano extensions
----------------------------
Murano uses stevedore [0] library to support plugins. Basically stevedore
plugin is a python package with special metadata (plugin entry points).
It can be installed as python package (via ``pip``) or distribution specific
package (e.g. DEB, RPM, etc.). Murano plugins provides new classes
that are referenced in the plugin metadata.
Murano library package is a simple **zip** archive which contains
``metadata.yaml`` file and Murano PL classes.
It can be installed from file using ``murano`` command-line tool
or from the repository.
Alternatives
------------
Extend Heat to support Networking SFC.
Instead of accessing Neutron API directly from Murano plugins, Murano can
manage Networking SFC through Heat resources. It will require creating Heat
extension which will delegate SFC configuration from Heat templates.
Heat extension should provide set of resources which will implement.
Networking SFC entities:
* Port Chain
* Port Pair Group
* Port Pair
* Flow Classifier
Heat can be extended by adding new resources using plugins. It provides mapping
between heat resources and python classes. It will implement hooks on heat
events like resource create, update etc.
**PROS:**
* Resource management delegated to Heat. Heat can be used for resource cleanup
* Heat can provide some helpful transactional capabilities
* Cloud operator will be able to use SFC w/ and wo/ Murano
**CONS:**
* Security-related implications for customers, who wants to keep vanilla
OpenStack installation.
Data model impact
-----------------
None
REST API impact
---------------
None
Versioning impact
-----------------
None
Other end user impact
---------------------
End user will be able to use networking SFC from Murano templates.
Networking SFC will introduce additional delay in RTT (round-trip-time).
This mean some applications prone to network delays can stop working.
Deployer impact
---------------
To use SFC with Murano cloud operator needs to install and enable SFC Murano
plugin.
Developer impact
----------------
None
Murano-dashboard / Horizon impact
---------------------------------
None
Implementation
==============
Assignee(s)
-----------
Work Items
----------
* Create Murano Networking SFC plugin
* Create Murano library package
* Create Murano test application
* Implement support of multiple Neutron ports to Murano Core Library
* Tests
Dependencies
============
Murano plugin depends on networking-sfc package, which should be installed.
Testing
=======
Proper functional tests should be implemented.
Documentation Impact
====================
User will be informed how to enable and start using networking SFC inside
Murano templates.
References
==========
[0] - http://docs.openstack.org/developer/stevedore/