This document is for a deprecated release of Opendaylight and will receive only security updates.
OpenDaylight Service Function Chaining (SFC) provides the ability to define an ordered list of a network services (e.g. firewalls, load balancers). These service are then “stitched” together in the network to create a service chain. This project provides the infrastructure (chaining logic, APIs) needed for ODL to provision a service chain in the network and an end-user application for defining such chains.
Description of classifier can be found in: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/
Classifier manages everything from starting the packet listener to creation (and removal) of appropriate ip(6)tables rules and marking received packets accordingly. Its functionality is available only on Linux as it leverdges NetfilterQueue, which provides access to packets matched by an iptables rule. Classifier requires root privileges to be able to operate.
So far it is capable of processing ACL for MAC addresses, ports, IPv4 and IPv6. Supported protocols are TCP and UDP.
Python code located in the project repository sfc-py/common/classifier.py.
Note
classifier assumes that Rendered Service Path (RSP) already exists in ODL when an ACL referencing it is obtained
After this process is over, every packet successfully matched to an iptables rule (i.e. successfully classified) will be NSH encapsulated and forwarded to a related SFF, which knows how to traverse the RSP.
Rules are created using appropriate iptables command. If the Access Control Entry (ACE) rule is MAC address related both iptables and ip6tabeles rules re issued. If ACE rule is IPv4 address related, only iptables rules are issued, same for IPv6.
Note
iptables raw table contains all created rules
Information regarding already registered RSP(s) are stored in an internal data-store, which is represented as a dictionary:
{rsp_id: {'name': <rsp_name>,
'chains': {'chain_name': (<ipv>,),
...
},
'sff': {'ip': <ip>,
'port': <port>,
'starting-index': <starting-index>,
'transport-type': <transport-type>
},
},
...
}
name: name of the RSPchains: dictionary of iptables chains related to the RSP with
information about IP version for which the chain existsSFF: SFF forwarding parametersip: SFF IP addressport: SFF portstarting-index: index given to packet at first RSP hoptransport-type: encapsulation protocolThis features exposes API to configure classifier (corresponds to service-function-classifier.yang)
See: sfc-model/src/main/yang/service-function-classifier.yang
SFC-OVS provides integration of SFC with Open vSwitch (OVS) devices. Integration is realized through mapping of SFC objects (like SF, SFF, Classifier, etc.) to OVS objects (like Bridge, TerminationPoint=Port/Interface). The mapping takes care of automatic instantiation (setup) of corresponding object whenever its counterpart is created. For example, when a new SFF is created, the SFC-OVS plugin will create a new OVS bridge and when a new OVS Bridge is created, the SFC-OVS plugin will create a new SFF.
SFC-OVS uses the OVSDB MD-SAL Southbound API for getting/writing information from/to OVS devices. The core functionality consists of two types of mapping:
SFC < — > OVS mapping flow diagram
The Southbound REST Plugin is used to send configuration from DataStore down to network devices supporting a REST API (i.e. they have a configured REST URI). It supports POST/PUT/DELETE operations, which are triggered accordingly by changes in the SFC data stores.
Southbound REST Plugin Architecture diagram
The plugin provides Southbound REST API designated to listening REST devices. It supports POST/PUT/DELETE operations. The operation (with corresponding JSON-encoded data) is sent to unique REST URL belonging to certain datatype.
http://<host>:<port>/config/ietf-acl:access-lists/access-list/http://<host>:<port>/config/service-function:service-functions/service-function/http://<host>:<port>/config/service-function:service-function-groups/service-function-group/http://<host>:<port>/config/service-function-scheduler-type:service-function-scheduler-types/service-function-scheduler-type/http://<host>:<port>/config/service-function-forwarder:service-function-forwarders/service-function-forwarder/http://<host>:<port>/operational/rendered-service-path:rendered-service-paths/rendered-service-path/Therefore, network devices willing to receive REST messages must listen on these REST URLs.
Note
Service Classifier Function (SCF) URL does not exist, because SCF is
considered as one of the network devices willing to receive REST
messages. However, there is a listener hooked on the SCF data store,
which is triggering POST/PUT/DELETE operations of ACL object,
because ACL is referenced in service-function-classifier.yang
SFC Load-Balancing feature implements load balancing of Service Functions, rather than a one-to-one mapping between Service Function Forwarder and Service Function.
Service Function Groups (SFG) can replace Service Functions (SF) in the Rendered Path model. A Service Path can only be defined using SFGs or SFs, but not a combination of both.
Relevant objects in the YANG model are as follows:
Service-Function-Group-Algorithm:
Service-Function-Group-Algorithms {
Service-Function-Group-Algorithm {
String name
String type
}
}
Available types: ALL, SELECT, INDIRECT, FAST_FAILURE
Service-Function-Group:
Service-Function-Groups {
Service-Function-Group {
String name
String serviceFunctionGroupAlgorithmName
String type
String groupId
Service-Function-Group-Element {
String service-function-name
int index
}
}
}
ServiceFunctionHop: holds a reference to a name of SFG (or SF)
This feature enhances the existing SFC API.
REST API commands include: * For Service Function Group (SFG): read existing SFG, write new SFG, delete existing SFG, add Service Function (SF) to SFG, and delete SF from SFG * For Service Function Group Algorithm (SFG-Alg): read, write, delete
Bundle providing the REST API: sfc-sb-rest * Service Function Groups and Algorithms are defined in: sfc-sfg and sfc-sfg-alg * Relevant JAVA API: SfcProviderServiceFunctionGroupAPI, SfcProviderServiceFunctionGroupAlgAPI
When creating the Rendered Service Path (RSP), the earlier release of SFC chose the first available service function from a list of service function names. Now a new API is introduced to allow developers to develop their own schedule algorithms when creating the RSP. There are four scheduling algorithms (Random, Round Robin, Load Balance and Shortest Path) are provided as examples for the API definition. This guide gives a simple introduction of how to develop service function scheduling algorithms based on the current extensible framework.
The following figure illustrates the service function selection framework and algorithms.
SF Scheduling Algorithm framework Architecture
The YANG Model defines the Service Function Scheduling Algorithm type identities and how they are stored in the MD-SAL data store for the scheduling algorithms.
The MD-SAL data store stores all informations for the scheduling algorithms, including their types, names, and status.
The API provides some basic APIs to manage the informations stored in the MD-SAL data store, like putting new items into it, getting all scheduling algorithms, etc.
The RESTCONF API provides APIs to manage the informations stored in the MD-SAL data store through RESTful calls.
The Service Function Chain Renderer gets the enabled scheduling algorithm type, and schedules the service functions with scheduling algorithm implementation.
While developing a new Service Function Scheduling Algorithm, a new class should be added and it should extend the base schedule class SfcServiceFunctionSchedulerAPI. And the new class should implement the abstract function:
public List<String> scheduleServiceFuntions(ServiceFunctionChain chain, int serviceIndex).
Please refer the API docs generated in the mdsal-apidocs.