Contributors

Neutron networking-sfc project next IRC meeting Agenda

Quick introduction of new interested contributors
Spec update, and review
SFC CLI client and Horizon Client dependency on base Neutron CLI and Horizon code
OVS Driver and OVS support for classifier and SFF. If we decide to go for no SFC header with chain ID, then the OVS has to build a forwarding table based on 5-tuple or n-tuple for flow identification.

Updates

Please refer to Meetings/ServiceFunctionChainingMeeting for up-to-date meeting agenda and information regarding openstack/networking-sfc.

IRC Meeting Log

Meeting log

Neutron API Specification for Service Chaining

Blueprint

API for Service Chaining

Introduction

Currently Neutron does not support service chaining. To support service chaining, Service VMs must be attached at points in the network and then traffic must be steered between these attachment points. Please also refer to the Neutron Service Chain BP associated with this specification and the Service Chain Bug.

Overview

All Neutron network services and VMs are connected to a Neutron network via Neutron ports. This makes it possible to create a traffic steering model for service chaining that uses only Neutron ports. This traffic steering model has no notion of the actual services attached to these Neutron ports.

The service VM hosting the service functions is instantiated and configured, then VNICs are added to the VM and then these VNICs are attached to the network by Neutron ports. Once the service function is attached to Neutron ports, the ports may be included in a "port chain" to allow the service function to provide treatment to the user's traffic.

A Port Chain (Service Function Path) consists of:

a set of Neutron port-pairs, to define the sequence of service functions
a set of flow classifiers, to specify the classified traffic flow to enter the chain

If a service function has a pair of ports, the first port in the port-pair is the ingress port of the service function, and the second port is the egress port of the service function. If a service function has one bidirectional port, then both ports in the port-pair have the same value.

The first port of the first port-pair is the head end of the Port Chain. The second port of the last port-pair is the tail end of the Port Chain.

A Neutron port-pair may be associated to more than one Port Chain to allow a service function to be part of multiple chains. A bidirectional service chain would be composed of two unidirectional service paths each using a "port-chain".

If there is more than one service function instance of a specific type available to meet the user's service requirement, their Neutron port-pairs are included in the port chain as a "port-group".

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 a generic module and may be used by different projects like fw, QOS, etc.

The flow classifiers define the source and destination endpoints of the traffic that can enter a port chain.

A flow classifier cannot be part of two different port-chains. A check will be made to ensure that is the case.

If multiple flows go through a port chain, then there will be multiple flow classifiers for that port chain.

Model

       +-------+        +--------+        +---------+
       | Port  |--------| Port   |--------| Neutron |
       | Chain |*      *| Groups |1      *|Port-pair|
       +-------+        +--------+        +---------+
         |1  |1
         |    --------------
         |*                 |1
      +--------------+  +----------+
      | Flow         |  | Chain    |
      | Classifiers  |  |Parameters|
      +--------------+  +----------+

Use Cases

Refer to Neutron/ServiceChainUseCases

Neutron/APIForServiceChaining

Contents