1 Service Function Chaining
2 =========================
4 OpenDaylight Service Function Chaining (SFC) Overview
5 -----------------------------------------------------
7 OpenDaylight Service Function Chaining (SFC) provides the ability to
8 define an ordered list of a network services (e.g. firewalls, load
9 balancers). These service are then "stitched" together in the network to
10 create a service chain. This project provides the infrastructure
11 (chaining logic, APIs) needed for ODL to provision a service chain in
12 the network and an end-user application for defining such chains.
14 - ACE - Access Control Entry
16 - ACL - Access Control List
18 - SCF - Service Classifier Function
20 - SF - Service Function
22 - SFC - Service Function Chain
24 - SFF - Service Function Forwarder
26 - SFG - Service Function Group
28 - SFP - Service Function Path
30 - RSP - Rendered Service Path
32 - NSH - Network Service Header
34 SFC Classifier Control and Date plane Developer guide
35 -----------------------------------------------------
40 Description of classifier can be found in:
41 https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/
43 Classifier manages everything from starting the packet listener to
44 creation (and removal) of appropriate ip(6)tables rules and marking
45 received packets accordingly. Its functionality is **available only on
46 Linux** as it leverages **NetfilterQueue**, which provides access to
47 packets matched by an **iptables** rule. Classifier requires **root
48 privileges** to be able to operate.
50 So far it is capable of processing ACL for MAC addresses, ports, IPv4
51 and IPv6. Supported protocols are TCP and UDP.
53 Classifier Architecture
54 ~~~~~~~~~~~~~~~~~~~~~~~
56 Python code located in the project repository
57 sfc-py/common/classifier.py.
61 classifier assumes that Rendered Service Path (RSP) **already
62 exists** in ODL when an ACL referencing it is obtained
64 1. sfc\_agent receives an ACL and passes it for processing to the
67 2. the RSP (its SFF locator) referenced by ACL is requested from ODL
69 3. if the RSP exists in the ODL then ACL based iptables rules for it are
72 After this process is over, every packet successfully matched to an
73 iptables rule (i.e. successfully classified) will be NSH encapsulated
74 and forwarded to a related SFF, which knows how to traverse the RSP.
76 Rules are created using appropriate iptables command. If the Access
77 Control Entry (ACE) rule is MAC address related both iptables and
78 IPv6 tables rules are issued. If ACE rule is IPv4 address related, only
79 iptables rules are issued, same for IPv6.
83 iptables **raw** table contains all created rules
85 Information regarding already registered RSP(s) are stored in an
86 internal data-store, which is represented as a dictionary:
90 {rsp_id: {'name': <rsp_name>,
91 'chains': {'chain_name': (<ipv>,),
96 'starting-index': <starting-index>,
97 'transport-type': <transport-type>
103 - ``name``: name of the RSP
105 - ``chains``: dictionary of iptables chains related to the RSP with
106 information about IP version for which the chain exists
108 - ``SFF``: SFF forwarding parameters
110 - ``ip``: SFF IP address
114 - ``starting-index``: index given to packet at first RSP hop
116 - ``transport-type``: encapsulation protocol
118 Key APIs and Interfaces
119 ~~~~~~~~~~~~~~~~~~~~~~~
121 This features exposes API to configure classifier (corresponds to
122 service-function-classifier.yang)
124 API Reference Documentation
125 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
127 See: sfc-model/src/main/yang/service-function-classifier.yang
135 SFC-OVS provides integration of SFC with Open vSwitch (OVS) devices.
136 Integration is realized through mapping of SFC objects (like SF, SFF,
137 Classifier, etc.) to OVS objects (like Bridge,
138 TerminationPoint=Port/Interface). The mapping takes care of automatic
139 instantiation (setup) of corresponding object whenever its counterpart
140 is created. For example, when a new SFF is created, the SFC-OVS plug-in
141 will create a new OVS bridge and when a new OVS Bridge is created, the
142 SFC-OVS plug-in will create a new SFF.
147 SFC-OVS uses the OVSDB MD-SAL Southbound API for getting/writing
148 information from/to OVS devices. The core functionality consists of two
151 a. mapping from OVS to SFC
153 - OVS Bridge is mapped to SFF
155 - OVS TerminationPoints are mapped to SFF DataPlane locators
157 b. mapping from SFC to OVS
159 - SFF is mapped to OVS Bridge
161 - SFF DataPlane locators are mapped to OVS TerminationPoints
163 .. figure:: ./images/sfc/sfc-ovs-architecture.png
164 :alt: SFC < — > OVS mapping flow diagram
166 SFC < — > OVS mapping flow diagram
168 Key APIs and Interfaces
169 ~~~~~~~~~~~~~~~~~~~~~~~
171 - SFF to OVS mapping API (methods to convert SFF object to OVS Bridge
172 and OVS TerminationPoints)
174 - OVS to SFF mapping API (methods to convert OVS Bridge and OVS
175 TerminationPoints to SFF object)
177 SFC Southbound REST Plug-in
178 --------------------------
183 The Southbound REST Plug-in is used to send configuration from datastore
184 down to network devices supporting a REST API (i.e. they have a
185 configured REST URI). It supports POST/PUT/DELETE operations, which are
186 triggered accordingly by changes in the SFC data stores.
188 - Access Control List (ACL)
190 - Service Classifier Function (SCF)
192 - Service Function (SF)
194 - Service Function Group (SFG)
196 - Service Function Schedule Type (SFST)
198 - Service Function Forwarder (SFF)
200 - Rendered Service Path (RSP)
202 Southbound REST Plug-in Architecture
203 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
205 1. **listeners** - used to listen on changes in the SFC data stores
207 2. **JSON exporters** - used to export JSON-encoded data from
208 binding-aware data store objects
210 3. **tasks** - used to collect REST URIs of network devices and to send
211 JSON-encoded data down to these devices
213 .. figure:: ./images/sfc/sb-rest-architecture.png
214 :alt: Southbound REST Plug-in Architecture diagram
216 Southbound REST Plug-in Architecture diagram
218 Key APIs and Interfaces
219 ~~~~~~~~~~~~~~~~~~~~~~~
221 The plug-in provides Southbound REST API designated to listening REST
222 devices. It supports POST/PUT/DELETE operations. The operation (with
223 corresponding JSON-encoded data) is sent to unique REST URL belonging to
226 - Access Control List (ACL):
227 ``http://<host>:<port>/config/ietf-acl:access-lists/access-list/``
229 - Service Function (SF):
230 ``http://<host>:<port>/config/service-function:service-functions/service-function/``
232 - Service Function Group (SFG):
233 ``http://<host>:<port>/config/service-function:service-function-groups/service-function-group/``
235 - Service Function Schedule Type (SFST):
236 ``http://<host>:<port>/config/service-function-scheduler-type:service-function-scheduler-types/service-function-scheduler-type/``
238 - Service Function Forwarder (SFF):
239 ``http://<host>:<port>/config/service-function-forwarder:service-function-forwarders/service-function-forwarder/``
241 - Rendered Service Path (RSP):
242 ``http://<host>:<port>/operational/rendered-service-path:rendered-service-paths/rendered-service-path/``
244 Therefore, network devices willing to receive REST messages must listen
249 Service Classifier Function (SCF) URL does not exist, because SCF is
250 considered as one of the network devices willing to receive REST
251 messages. However, there is a listener hooked on the SCF data store,
252 which is triggering POST/PUT/DELETE operations of ACL object,
253 because ACL is referenced in ``service-function-classifier.yang``
255 Service Function Load Balancing Developer Guide
256 -----------------------------------------------
261 SFC Load-Balancing feature implements load balancing of Service
262 Functions, rather than a one-to-one mapping between Service Function
263 Forwarder and Service Function.
265 Load Balancing Architecture
266 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
268 Service Function Groups (SFG) can replace Service Functions (SF) in the
269 Rendered Path model. A Service Path can only be defined using SFGs or
270 SFs, but not a combination of both.
272 Relevant objects in the YANG model are as follows:
274 1. Service-Function-Group-Algorithm:
278 Service-Function-Group-Algorithms {
279 Service-Function-Group-Algorithm {
287 Available types: ALL, SELECT, INDIRECT, FAST_FAILURE
289 2. Service-Function-Group:
293 Service-Function-Groups {
294 Service-Function-Group {
296 String serviceFunctionGroupAlgorithmName
299 Service-Function-Group-Element {
300 String service-function-name
306 3. ServiceFunctionHop: holds a reference to a name of SFG (or SF)
308 Key APIs and Interfaces
309 ~~~~~~~~~~~~~~~~~~~~~~~
311 This feature enhances the existing SFC API.
313 REST API commands include: \* For Service Function Group (SFG): read
314 existing SFG, write new SFG, delete existing SFG, add Service Function
315 (SF) to SFG, and delete SF from SFG \* For Service Function Group
316 Algorithm (SFG-Alg): read, write, delete
318 Bundle providing the REST API: sfc-sb-rest \* Service Function Groups
319 and Algorithms are defined in: sfc-sfg and sfc-sfg-alg \* Relevant JAVA
320 API: SfcProviderServiceFunctionGroupAPI,
321 SfcProviderServiceFunctionGroupAlgAPI
323 Service Function Scheduling Algorithms
324 --------------------------------------
329 When creating the Rendered Service Path (RSP), the earlier release of
330 SFC chose the first available service function from a list of service
331 function names. Now a new API is introduced to allow developers to
332 develop their own schedule algorithms when creating the RSP. There are
333 four scheduling algorithms (Random, Round Robin, Load Balance and
334 Shortest Path) are provided as examples for the API definition. This
335 guide gives a simple introduction of how to develop service function
336 scheduling algorithms based on the current extensible framework.
341 The following figure illustrates the service function selection
342 framework and algorithms.
344 .. figure:: ./images/sfc-sf-selection-arch.png
345 :alt: SF Scheduling Algorithm framework Architecture
347 SF Scheduling Algorithm framework Architecture
349 The YANG Model defines the Service Function Scheduling Algorithm type
350 identities and how they are stored in the MD-SAL data store for the
351 scheduling algorithms.
353 The MD-SAL data store stores all informations for the scheduling
354 algorithms, including their types, names, and status.
356 The API provides some basic APIs to manage the informations stored in
357 the MD-SAL data store, like putting new items into it, getting all
358 scheduling algorithms, etc.
360 The RESTCONF API provides APIs to manage the informations stored in the
361 MD-SAL data store through RESTful calls.
363 The Service Function Chain Renderer gets the enabled scheduling
364 algorithm type, and schedules the service functions with scheduling
365 algorithm implementation.
367 Key APIs and Interfaces
368 ~~~~~~~~~~~~~~~~~~~~~~~
370 While developing a new Service Function Scheduling Algorithm, a new
371 class should be added and it should extend the base schedule class
372 SfcServiceFunctionSchedulerAPI. And the new class should implement the
375 ``public List<String> scheduleServiceFuntions(ServiceFunctionChain chain, int serviceIndex)``.
377 - **``ServiceFunctionChain chain``**: the chain which will be rendered
379 - **``int serviceIndex``**: the initial service index for this rendered
382 - **``List<String>``**: a list of service function names which scheduled
383 by the Service Function Scheduling Algorithm.
385 API Reference Documentation
386 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
388 Please refer the API docs generated in the mdsal-apidocs.
391 Logical Service Function Forwarder
392 ----------------------------------
400 When the current SFC is deployed in a cloud environment, it is assumed that each
401 switch connected to a Service Function is configured as a Service Function Forwarder and
402 each Service Function is connected to its Service Function Forwarder depending on the
403 Compute Node where the Virtual Machine is located. This solution allows the basic cloud
404 use cases to be fulfilled, as for example, the ones required in OPNFV Brahmaputra, however,
405 some advanced use cases, like the transparent migration of VMs can not be implemented.
406 The Logical Service Function Forwarder enables the following advanced use cases:
408 1. Service Function mobility without service disruption
409 2. Service Functions load balancing and failover
411 As shown in the picture below, the Logical Service Function Forwarder concept extends the current
412 SFC northbound API to provide an abstraction of the underlying Data Center infrastructure.
413 The Data Center underlaying network can be abstracted by a single SFF. This single SFF uses
414 the logical port UUID as data plane locator to connect SFs globally and in a location-transparent manner.
415 SFC makes use of Genius project to track the location of the SF's logical ports.
417 .. figure:: ./images/sfc/single-logical-sff-concept.png
418 :alt: Single Logical SFF concept
420 The SFC internally distributes the necessary flow state over the relevant switches based on the
421 internal Data Center topology and the deployment of SFs.
423 Changes in data model
424 ~~~~~~~~~~~~~~~~~~~~~
425 The Logical Service Function Forwarder concept extends the current SFC northbound API to provide
426 an abstraction of the underlying Data Center infrastructure.
428 The Logical SFF simplifies the configuration of the current SFC data model by reducing the number
429 of parameters to be be configured in every SFF, since the controller will discover those parameters
430 by interacting with the services offered by the Genius project.
432 The following picture shows the Logical SFF data model. The model gets simplified as most of the
433 configuration parameters of the current SFC data model are discovered in runtime. The complete
434 YANG model can be found here `logical SFF model
435 <https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/service-function-forwarder-logical.yang>`__.
437 .. figure:: ./images/sfc/logical-sff-datamodel.png
438 :alt: Logical SFF data model
440 There are other minor changes in the data model; the SFC encapsulation type has been added or moved in the following files:
442 - `RSP data model <https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/rendered-service-path.yang>`__
444 - `SFP data model <https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/service-function-path.yang>`__
446 - `Service Locator data model <https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/service-locator.yang>`__
448 Interaction with Genius
449 ~~~~~~~~~~~~~~~~~~~~~~~
451 Feature *sfc-genius* functionally enables SFC integration with Genius. This allows configuring a Logical SFF
452 and SFs attached to this Logical SFF via logical interfaces (i.e. neutron ports) that are registered with Genius.
454 As shown in the following picture, SFC will interact with Genius project's services to provide the
455 Logical SFF functionality.
457 .. figure:: ./images/sfc/sfc-genius-interaction.png
460 The following are the main Genius' services used by SFC:
462 1. Interaction with Interface Tunnel Manager (ITM)
464 2. Interaction with the Interface Manager
466 3. Interaction with Resource Manager
468 SFC Service registration with Genius
469 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
471 Genius handles the coexistence of different network services. As such, SFC service is registered with Genius
472 performing the following actions:
475 As soon as a Service Function associated to the Logical SFF is involved in a Rendered Service Path, SFC service is
476 bound to its logical interface via Genius Interface Manager. This has the effect of forwarding every incoming packet
477 from the Service Function to the SFC pipeline of the attached switch, as long as it is not consumed by a different
478 bound service with higher priority.
480 SFC Service Terminating Action
481 As soon as SFC service is bound to the interface of a Service Function for the first time on a specific switch, a
482 terminating service action is configured on that switch via Genius Interface Tunnel Manager. This has the effect of
483 forwarding every incoming packet from a different switch to the SFC pipeline as long as the traffic is VXLAN
484 encapsulated on VNI 0.
486 The following sequence diagrams depict how the overall process takes place:
488 .. figure:: ./images/sfc/sfc-genius-at-rsp-render.png
489 :alt: sfc-genius at RSP render
491 SFC genius module interaction with Genius at RSP creation.
493 .. figure:: ./images/sfc/sfc-genius-at-rsp-removal.png
494 :alt: sfc-genius at RSP removal
496 SFC genius module interaction with Genius at RSP removal.
498 For more information on how Genius allows different services to coexist, see the :ref:`Genius User Guide
499 <genius-user-guide>`.
503 During path rendering, Genius is queried to obtain needed information, such as:
505 - Location of a logical interface on the data-plane.
506 - Tunnel interface for a specific pair of source and destination switches.
507 - Egress OpenFlow actions to output packets to a specific interface.
509 See :ref:`RSP Rendering <sfc-genius-path-rendering>` section for more information.
513 Upon VM migration, it's logical interface is first unregistered and then registered with Genius, possibly at a new
514 physical location. *sfc-genius* reacts to this by re-rendering all the RSPs on which the associated SF
515 participates, if any.
517 The following picture illustrates the process:
519 .. figure:: ./images/sfc/sfc-genius-at-vm-migration.png
520 :alt: sfc-genius at VM migration
522 SFC genius module at VM migration.
524 .. _sfc-genius-path-rendering:
526 RSP Rendering changes for paths using the Logical SFF
527 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
529 #. **Construction of the auxiliary rendering graph**
531 When starting the rendering of a RSP, the SFC renderer builds an auxiliary graph with information about the required hops for traffic traversing the path. RSP processing is achieved by iteratively evaluating each of the entries in the graph, writing the required flows in the proper switch for each hop.
533 It is important to note that the graph includes both traffic ingress (i.e. traffic entering into the first SF) and traffic egress (i.e. traffic leaving the chain from the last SF) as hops. Therefore, the number of entries in the graph equals the number of SFs in the chain plus one.
535 .. figure:: ./images/sfc/sfc-genius-example-auxiliary-graph.png
537 The process of rendering a chain when the switches involved are part of the Logical SFF also starts with the construction of the hop graph. The difference is that when the SFs used in the chain are using a logical interface, the SFC renderer will also retrieve from Genius the DPIDs for the switches, storing them in the graph. In this context, those switches are the ones in the compute nodes each SF is hosted on at the time the chain is rendered.
539 .. figure:: ./images/sfc/sfc-genius-example-auxiliary-graph-logical-sff.png
541 #. **New transport processor**
543 Transport processors are classes which calculate and write the correct flows for a chain. Each transport processor specializes on writing the flows for a given combination of transport type and SFC encapsulation.
545 A specific transport processor has been created for paths using a Logical SFF. A particularity of this transport processor is that its use is not only determined by the transport / SFC encapsulation combination, but also because the chain is using a Logical SFF. The actual condition evaluated for selecting the Logical SFF transport processor is that the SFs in the chain are using logical interface locators, and that the DPIDs for those locators can be successfully retrieved from Genius.
547 .. figure:: ./images/sfc/transport_processors_class_diagram.png
549 The main differences between the Logical SFF transport processor and other processors are the following:
551 - Instead of srcSff, dstSff fields in the hops graph (which are all equal in a path using a Logical SFF), the Logical SFF transport processor uses previously stored srcDpnId, dstDpnId fields in order to know whether an actual hop between compute nodes must be performed or not (it is possible that two consecutive SFs are collocated in the same compute node).
553 - When a hop between switches really has to be performed, it relies on Genius for getting the actions to perform that hop. The retrieval of those actions involve two steps:
555 - First, Genius' Overlay Tunnel Manager module is used in order to retrieve the target interface for a jump between the source and the destination DPIDs.
557 - Then, egress instructions for that interface are retrieved from Genius's Interface Manager.
559 - There are no next hop rules between compute nodes, only egress instructions (the transport zone tunnels have all the required routing information).
561 - Next hop information towards SFs uses mac adresses which are also retrieved from the Genius datastore.
563 - The Logical SFF transport processor performs NSH decapsulation in the last switch of the chain.
565 #. **Post-rendering update of the operational data model**
567 When the rendering of a chain finishes successfully, the Logical SFF Transport Processor perform two operational datastore modifications in order to provide some relevant runtime information about the chain. The exposed information is the following:
569 - Rendered Service Path state: when the chain uses a Logical SFF, DPIDs for the switches in the compute nodes on which the SFs participating in the chain are hosted are added to the hop information.
571 - SFF state: A new list of all RSPs which use each DPID is has been added. It is updated on each RSP addition / deletion.
576 This section explains the changes made to the SFC classifier, enabling it
577 to be attached to Logical SFFs.
579 Refer to the following image to better understand the concept, and the required
580 steps to implement the feature.
582 .. figure:: ./images/sfc/sfc-classifier-genius-integration.png
583 :alt: Classifier integration with Genius
585 SFC classifier integration with Genius.
587 As stated in the :ref:`SFC User Guide <sfc-user-guide-classifier-impacts>`,
588 the classifier needs to be provisioned using logical interfaces as attachment
591 When that happens, MDSAL will trigger an event in the odl-sfc-scf-openflow feature
592 (i.e. the sfc-classifier), which is responsible for installing the classifier
593 flows in the classifier switches.
595 The first step of the process, is to bind the interfaces to classify in Genius,
596 in order for the desired traffic (originating from the VMs having the
597 provisioned attachment-points) to enter the SFC pipeline. This will make traffic
598 reach table 82 (SFC classifier table), coming from table 0 (table managed by
599 Genius, shared by all applications).
601 The next step, is deciding which flows to install in the SFC classifier table.
602 A table-miss flow will be installed, having a MatchAny clause, whose action is
603 to jump to Genius's egress dispatcher table. This enables traffic intended for
604 other applications to still be processed.
606 The flow that allows the SFC pipeline to continue is added next, having higher
607 match priority than the table-miss flow. This flow has two responsabilities:
609 1. **Push the NSH header, along with its metadata (required within the SFC pipeline)**
611 Features the specified ACL matches as match criteria, and push NSH along
612 with its metadata into the Action list.
614 2. **Advance the SFC pipeline**
616 Forward the traffic to the first Service Function in the RSP. This steers
617 packets into the SFC domain, and how it is done depends on whether the
618 classifier is co-located with the first service function in the specified
621 Should the classifier be co-located (i.e. in the same compute node), a
622 new instruction is appended to the flow, telling all matches to jump to
623 the transport ingress table.
625 If not, Genius's tunnel manager service is queried to get the tunnel
626 interface connecting the classifier node with the compute node where the
627 first Service Function is located, and finally, Genius's interface manager
628 service is queried asking for instructions on how to reach that tunnel
631 These actions are then appended to the Action list already containing push
632 NSH and push NSH metadata Actions, and written in an Apply-Actions
633 Instruction into the datastore.