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
40 SFC User Interface (SFC-UI) is based on Dlux project. It provides an
41 easy way to create, read, update and delete configuration stored in
42 datastore. Moreover, it shows the status of all SFC features (e.g
43 installed, uninstalled) and Karaf log messages as well.
48 SFC-UI operates purely by using RESTCONF.
50 .. figure:: ./images/sfc/sfc-ui-architecture.png
51 :alt: SFC-UI integration into ODL
53 SFC-UI integration into ODL
58 1. Run ODL distribution (run karaf)
60 2. In Karaf console execute: ``feature:install odl-sfc-ui``
62 3. Visit SFC-UI on: ``http://<odl_ip_address>:8181/sfc/index.html``
64 SFC Southbound REST Plug-in
65 --------------------------
70 The Southbound REST Plug-in is used to send configuration from datastore
71 down to network devices supporting a REST API (i.e. they have a
72 configured REST URI). It supports POST/PUT/DELETE operations, which are
73 triggered accordingly by changes in the SFC data stores.
75 - Access Control List (ACL)
77 - Service Classifier Function (SCF)
79 - Service Function (SF)
81 - Service Function Group (SFG)
83 - Service Function Schedule Type (SFST)
85 - Service Function Forwarder (SFF)
87 - Rendered Service Path (RSP)
89 Southbound REST Plug-in Architecture
90 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
92 From the user perspective, the REST plug-in is another SFC Southbound
93 plug-in used to communicate with network devices.
95 .. figure:: ./images/sfc/sb-rest-architecture-user.png
96 :alt: Southbound REST Plug-in integration into ODL
98 Southbound REST Plug-in integration into ODL
100 Configuring Southbound REST Plugin
101 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
103 1. Run ODL distribution (run karaf)
105 2. In Karaf console execute: ``feature:install odl-sfc-sb-rest``
107 3. Configure REST URIs for SF/SFF through SFC User Interface or RESTCONF
108 (required configuration steps can be found in the tutorial stated
114 Comprehensive tutorial on how to use the Southbound REST Plug-in and how
115 to control network devices with it can be found on:
116 https://wiki.opendaylight.org/view/Service_Function_Chaining:Main#SFC_101
124 SFC-OVS provides integration of SFC with Open vSwitch (OVS) devices.
125 Integration is realized through mapping of SFC objects (like SF, SFF,
126 Classifier, etc.) to OVS objects (like Bridge,
127 TerminationPoint=Port/Interface). The mapping takes care of automatic
128 instantiation (setup) of corresponding object whenever its counterpart
129 is created. For example, when a new SFF is created, the SFC-OVS plug-in
130 will create a new OVS bridge and when a new OVS Bridge is created, the
131 SFC-OVS plug-in will create a new SFF.
133 The feature is intended for SFC users willing to use Open vSwitch as
134 underlying network infrastructure for deploying RSPs (Rendered Service
140 SFC-OVS uses the OVSDB MD-SAL Southbound API for getting/writing
141 information from/to OVS devices. From the user perspective SFC-OVS acts
142 as a layer between SFC datastore and OVSDB.
144 .. figure:: ./images/sfc/sfc-ovs-architecture-user.png
145 :alt: SFC-OVS integration into ODL
147 SFC-OVS integration into ODL
152 1. Run ODL distribution (run karaf)
154 2. In Karaf console execute: ``feature:install odl-sfc-ovs``
156 3. Configure Open vSwitch to use ODL as a manager, using following
157 command: ``ovs-vsctl set-manager tcp:<odl_ip_address>:6640``
162 Verifying mapping from OVS to SFF
163 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
168 This tutorial shows the usual work flow when OVS configuration is
169 transformed to corresponding SFC objects (in this case SFF).
174 - Open vSwitch installed (ovs-vsctl command available in shell)
176 - SFC-OVS feature configured as stated above
181 1. ``ovs-vsctl set-manager tcp:<odl_ip_address>:6640``
183 2. ``ovs-vsctl add-br br1``
185 3. ``ovs-vsctl add-port br1 testPort``
190 a. visit SFC User Interface:
191 ``http://<odl_ip_address>:8181/sfc/index.html#/sfc/serviceforwarder``
193 b. use pure RESTCONF and send GET request to URL:
194 ``http://<odl_ip_address>:8181/restconf/config/service-function-forwarder:service-function-forwarders``
196 There should be SFF, which name will be ending with *br1* and the SFF
197 should containt two DataPlane locators: *br1* and *testPort*.
199 Verifying mapping from SFF to OVS
200 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
205 This tutorial shows the usual workflow during creation of OVS Bridge
206 with use of SFC APIs.
211 - Open vSwitch installed (ovs-vsctl command available in shell)
213 - SFC-OVS feature configured as stated above
218 1. In shell execute: ``ovs-vsctl set-manager tcp:<odl_ip_address>:6640``
220 2. Send POST request to URL:
221 ``http://<odl_ip_address>:8181/restconf/operations/service-function-forwarder-ovs:create-ovs-bridge``
222 Use Basic auth with credentials: "admin", "admin" and set
223 ``Content-Type: application/json``. The content of POST request
233 "ip": "<Open_vSwitch_ip_address>"
238 Open\_vSwitch\_ip\_address is IP address of machine, where Open vSwitch
244 In shell execute: ``ovs-vsctl show``. There should be Bridge with name
245 *br-test* and one port/interface called *br-test*.
247 Also, corresponding SFF for this OVS Bridge should be configured, which
248 can be verified through SFC User Interface or RESTCONF as stated in
251 SFC Classifier User Guide
252 -------------------------
257 Description of classifier can be found in:
258 https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/
260 There are two types of classifier:
262 1. OpenFlow Classifier
264 2. Iptables Classifier
269 OpenFlow Classifier implements the classification criteria based on
270 OpenFlow rules deployed into an OpenFlow switch. An Open vSwitch will
271 take the role of a classifier and performs various encapsulations such
272 NSH, VLAN, MPLS, etc. In the existing implementation, classifier can
273 support NSH encapsulation. Matching information is based on ACL for MAC
274 addresses, ports, protocol, IPv4 and IPv6. Supported protocols are TCP,
275 UDP and SCTP. Actions information in the OF rules, shall be forwarding
276 of the encapsulated packets with specific information related to the
279 Classifier Architecture
280 ^^^^^^^^^^^^^^^^^^^^^^^
282 The OVSDB Southbound interface is used to create an instance of a bridge
283 in a specific location (via IP address). This bridge contains the
284 OpenFlow rules that perform the classification of the packets and react
285 accordingly. The OpenFlow Southbound interface is used to translate the
286 ACL information into OF rules within the Open vSwitch.
290 in order to create the instance of the bridge that takes the role of
291 a classifier, an "empty" SFF must be created.
293 Configuring Classifier
294 ^^^^^^^^^^^^^^^^^^^^^^
296 1. An empty SFF must be created in order to host the ACL that contains
297 the classification information.
299 2. SFF data plane locator must be configured
301 3. Classifier interface must be manually added to SFF bridge.
303 Administering or Managing Classifier
304 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
306 Classification information is based on MAC addresses, protocol, ports
307 and IP. ACL gathers this information and is assigned to an RSP which
308 turns to be a specific path for a Service Chain.
313 Classifier manages everything from starting the packet listener to
314 creation (and removal) of appropriate ip(6)tables rules and marking
315 received packets accordingly. Its functionality is **available only on
316 Linux** as it leverdges **NetfilterQueue**, which provides access to
317 packets matched by an **iptables** rule. Classifier requires **root
318 privileges** to be able to operate.
320 So far it is capable of processing ACL for MAC addresses, ports, IPv4
321 and IPv6. Supported protocols are TCP and UDP.
323 Classifier Architecture
324 ^^^^^^^^^^^^^^^^^^^^^^^
326 Python code located in the project repository
327 sfc-py/common/classifier.py.
331 classifier assumes that Rendered Service Path (RSP) **already
332 exists** in ODL when an ACL referencing it is obtained
334 1. sfc\_agent receives an ACL and passes it for processing to the
337 2. the RSP (its SFF locator) referenced by ACL is requested from ODL
339 3. if the RSP exists in the ODL then ACL based iptables rules for it are
342 After this process is over, every packet successfully matched to an
343 iptables rule (i.e. successfully classified) will be NSH encapsulated
344 and forwarded to a related SFF, which knows how to traverse the RSP.
346 Rules are created using appropriate iptables command. If the Access
347 Control Entry (ACE) rule is MAC address related both iptables and
348 IPv6 tables rules re issued. If ACE rule is IPv4 address related, only
349 iptables rules are issued, same for IPv6.
353 iptables **raw** table contains all created rules
355 Configuring Classifier
356 ^^^^^^^^^^^^^^^^^^^^^^
358 | Classfier does’t need any configuration.
359 | Its only requirement is that the **second (2) Netfilter Queue** is not
360 used by any other process and is **avalilable for the classifier**.
362 Administering or Managing Classifier
363 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
365 Classifier runs alongside sfc\_agent, therefore the command for starting
370 sudo python3.4 sfc-py/sfc_agent.py --rest --odl-ip-port localhost:8181 --auto-sff-name --nfq-class
372 SFC OpenFlow Renderer User Guide
373 --------------------------------
378 The Service Function Chaining (SFC) OpenFlow Renderer (SFC OF Renderer)
379 implements Service Chaining on OpenFlow switches. It listens for the
380 creation of a Rendered Service Path (RSP), and once received it programs
381 Service Function Forwarders (SFF) that are hosted on OpenFlow capable
382 switches to steer packets through the service chain.
384 Common acronyms used in the following sections:
386 - SF - Service Function
388 - SFF - Service Function Forwarder
390 - SFC - Service Function Chain
392 - SFP - Service Function Path
394 - RSP - Rendered Service Path
396 SFC OpenFlow Renderer Architecture
397 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
399 The SFC OF Renderer is invoked after a RSP is created using an MD-SAL
400 listener called ``SfcOfRspDataListener``. Upon SFC OF Renderer
401 initialization, the ``SfcOfRspDataListener`` registers itself to listen
402 for RSP changes. When invoked, the ``SfcOfRspDataListener`` processes
403 the RSP and calls the ``SfcOfFlowProgrammerImpl`` to create the
404 necessary flows in the Service Function Forwarders configured in the
405 RSP. Refer to the following diagram for more details.
407 .. figure:: ./images/sfc/sfcofrenderer_architecture.png
408 :alt: SFC OpenFlow Renderer High Level Architecture
410 SFC OpenFlow Renderer High Level Architecture
412 .. _sfc-user-guide-sfc-of-pipeline:
414 SFC OpenFlow Switch Flow pipeline
415 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
417 The SFC OpenFlow Renderer uses the following tables for its Flow
420 - Table 0, Classifier
422 - Table 1, Transport Ingress
424 - Table 2, Path Mapper
426 - Table 3, Path Mapper ACL
430 - Table 10, Transport Egress
432 The OpenFlow Table Pipeline is intended to be generic to work for all of
433 the different encapsulations supported by SFC.
435 All of the tables are explained in detail in the following section.
437 The SFFs (SFF1 and SFF2), SFs (SF1), and topology used for the flow
438 tables in the following sections are as described in the following
441 .. figure:: ./images/sfc/sfcofrenderer_nwtopo.png
442 :alt: SFC OpenFlow Renderer Typical Network Topology
444 SFC OpenFlow Renderer Typical Network Topology
446 Classifier Table detailed
447 ^^^^^^^^^^^^^^^^^^^^^^^^^
449 It is possible for the SFF to also act as a classifier. This table maps
450 subscriber traffic to RSPs, and is explained in detail in the classifier
453 If the SFF is not a classifier, then this table will just have a simple
456 Transport Ingress Table detailed
457 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
459 The Transport Ingress table has an entry per expected tunnel transport
460 type to be received in a particular SFF, as established in the SFC
463 Here are two example on SFF1: one where the RSP ingress tunnel is MPLS
464 assuming VLAN is used for the SFF-SF, and the other where the RSP
465 ingress tunnel is NSH GRE (UDP port 4789):
467 +----------+-------------------------------------+--------------+
468 | Priority | Match | Action |
469 +==========+=====================================+==============+
470 | 256 | EtherType==0x8847 (MPLS unicast) | Goto Table 2 |
471 +----------+-------------------------------------+--------------+
472 | 256 | EtherType==0x8100 (VLAN) | Goto Table 2 |
473 +----------+-------------------------------------+--------------+
474 | 256 | EtherType==0x0800,udp,tp\_dst==4789 | Goto Table 2 |
476 +----------+-------------------------------------+--------------+
477 | 5 | Match Any | Drop |
478 +----------+-------------------------------------+--------------+
480 Table: Table Transport Ingress
482 Path Mapper Table detailed
483 ^^^^^^^^^^^^^^^^^^^^^^^^^^
485 The Path Mapper table has an entry per expected tunnel transport info to
486 be received in a particular SFF, as established in the SFC
487 configuration. The tunnel transport info is used to determine the RSP
488 Path ID, and is stored in the OpenFlow Metadata. This table is not used
489 for NSH, since the RSP Path ID is stored in the NSH header.
491 For SF nodes that do not support NSH tunneling, the IP header DSCP field
492 is used to store the RSP Path Id. The RSP Path Id is written to the DSCP
493 field in the Transport Egress table for those packets sent to an SF.
495 Here is an example on SFF1, assuming the following details:
497 - VLAN ID 1000 is used for the SFF-SF
499 - The RSP Path 1 tunnel uses MPLS label 100 for ingress and 101 for
502 - The RSP Path 2 (symmetric downlink path) uses MPLS label 101 for
503 ingress and 100 for egress
505 +----------+-------------------+-----------------------+
506 | Priority | Match | Action |
507 +==========+===================+=======================+
508 | 256 | MPLS Label==100 | RSP Path=1, Pop MPLS, |
510 +----------+-------------------+-----------------------+
511 | 256 | MPLS Label==101 | RSP Path=2, Pop MPLS, |
513 +----------+-------------------+-----------------------+
514 | 256 | VLAN ID==1000, IP | RSP Path=1, Pop VLAN, |
515 | | DSCP==1 | Goto Table 4 |
516 +----------+-------------------+-----------------------+
517 | 256 | VLAN ID==1000, IP | RSP Path=2, Pop VLAN, |
518 | | DSCP==2 | Goto Table 4 |
519 +----------+-------------------+-----------------------+
520 | 5 | Match Any | Goto Table 3 |
521 +----------+-------------------+-----------------------+
523 Table: Table Path Mapper
525 Path Mapper ACL Table detailed
526 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
528 This table is only populated when PacketIn packets are received from the
529 switch for TcpProxy type SFs. These flows are created with an inactivity
530 timer of 60 seconds and will be automatically deleted upon expiration.
532 Next Hop Table detailed
533 ^^^^^^^^^^^^^^^^^^^^^^^
535 The Next Hop table uses the RSP Path Id and appropriate packet fields to
536 determine where to send the packet next. For NSH, only the NSP (Network
537 Services Path, RSP ID) and NSI (Network Services Index, next hop) fields
538 from the NSH header are needed to determine the VXLAN tunnel destination
539 IP. For VLAN or MPLS, then the source MAC address is used to determine
540 the destination MAC address.
542 Here are two examples on SFF1, assuming SFF1 is connected to SFF2. RSP
543 Paths 1 and 2 are symmetric VLAN paths. RSP Paths 3 and 4 are symmetric
544 NSH paths. RSP Path 1 ingress packets come from external to SFC, for
545 which we don’t have the source MAC address (MacSrc).
547 +----------+--------------------------------+--------------------------------+
548 | Priority | Match | Action |
549 +==========+================================+================================+
550 | 256 | RSP Path==1, MacSrc==SF1 | MacDst=SFF2, Goto Table 10 |
551 +----------+--------------------------------+--------------------------------+
552 | 256 | RSP Path==2, MacSrc==SF1 | Goto Table 10 |
553 +----------+--------------------------------+--------------------------------+
554 | 256 | RSP Path==2, MacSrc==SFF2 | MacDst=SF1, Goto Table 10 |
555 +----------+--------------------------------+--------------------------------+
556 | 246 | RSP Path==1 | MacDst=SF1, Goto Table 10 |
557 +----------+--------------------------------+--------------------------------+
558 | 256 | nsp=3,nsi=255 (SFF Ingress RSP | load:0xa000002→NXM\_NX\_TUN\_I |
559 | | 3) | PV4\_DST[], |
560 | | | Goto Table 10 |
561 +----------+--------------------------------+--------------------------------+
562 | 256 | nsp=3,nsi=254 (SFF Ingress | load:0xa00000a→NXM\_NX\_TUN\_I |
563 | | from SF, RSP 3) | PV4\_DST[], |
564 | | | Goto Table 10 |
565 +----------+--------------------------------+--------------------------------+
566 | 256 | nsp=4,nsi=254 (SFF1 Ingress | load:0xa00000a→NXM\_NX\_TUN\_I |
567 | | from SFF2) | PV4\_DST[], |
568 | | | Goto Table 10 |
569 +----------+--------------------------------+--------------------------------+
570 | 5 | Match Any | Drop |
571 +----------+--------------------------------+--------------------------------+
573 Table: Table Next Hop
575 Transport Egress Table detailed
576 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
578 The Transport Egress table prepares egress tunnel information and sends
581 Here are two examples on SFF1. RSP Paths 1 and 2 are symmetric MPLS
582 paths that use VLAN for the SFF-SF. RSP Paths 3 and 4 are symmetric NSH
583 paths. Since it is assumed that switches used for NSH will only have one
584 VXLAN port, the NSH packets are just sent back where they came from.
586 +----------+--------------------------------+--------------------------------+
587 | Priority | Match | Action |
588 +==========+================================+================================+
589 | 256 | RSP Path==1, MacDst==SF1 | Push VLAN ID 1000, Port=SF1 |
590 +----------+--------------------------------+--------------------------------+
591 | 256 | RSP Path==1, MacDst==SFF2 | Push MPLS Label 101, Port=SFF2 |
592 +----------+--------------------------------+--------------------------------+
593 | 256 | RSP Path==2, MacDst==SF1 | Push VLAN ID 1000, Port=SF1 |
594 +----------+--------------------------------+--------------------------------+
595 | 246 | RSP Path==2 | Push MPLS Label 100, |
597 +----------+--------------------------------+--------------------------------+
598 | 256 | nsp=3,nsi=255 (SFF Ingress RSP | IN\_PORT |
600 +----------+--------------------------------+--------------------------------+
601 | 256 | nsp=3,nsi=254 (SFF Ingress | IN\_PORT |
602 | | from SF, RSP 3) | |
603 +----------+--------------------------------+--------------------------------+
604 | 256 | nsp=4,nsi=254 (SFF1 Ingress | IN\_PORT |
606 +----------+--------------------------------+--------------------------------+
607 | 5 | Match Any | Drop |
608 +----------+--------------------------------+--------------------------------+
610 Table: Table Transport Egress
612 Administering SFC OF Renderer
613 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
615 To use the SFC OpenFlow Renderer Karaf, at least the following Karaf
616 features must be installed.
618 - odl-openflowplugin-nxm-extensions
620 - odl-openflowplugin-flow-services
626 - odl-sfc-openflow-renderer
628 - odl-sfc-ui (optional)
630 The following command can be used to view all of the currently installed
635 opendaylight-user@root>feature:list -i
637 Or, pipe the command to a grep to see a subset of the currently
638 installed Karaf features:
642 opendaylight-user@root>feature:list -i | grep sfc
644 To install a particular feature, use the Karaf ``feature:install``
647 SFC OF Renderer Tutorial
648 ~~~~~~~~~~~~~~~~~~~~~~~~
653 In this tutorial, 2 different encapsulations will be shown: MPLS and
654 NSH. The following Network Topology diagram is a logical view of the
655 SFFs and SFs involved in creating the Service Chains.
657 .. figure:: ./images/sfc/sfcofrenderer_nwtopo.png
658 :alt: SFC OpenFlow Renderer Typical Network Topology
660 SFC OpenFlow Renderer Typical Network Topology
665 To use this example, SFF OpenFlow switches must be created and connected
666 as illustrated above. Additionally, the SFs must be created and
669 Note that RSP symmetry depends on Service Function Path symmetric field, if present.
670 If not, the RSP will be symmetric if any of the SFs involved in the chain
671 has the bidirectional field set to true.
676 The target environment is not important, but this use-case was created
682 The steps to use this tutorial are as follows. The referenced
683 configuration in the steps is listed in the following sections.
685 There are numerous ways to send the configuration. In the following
686 configuration chapters, the appropriate ``curl`` command is shown for
687 each configuration to be sent, including the URL.
689 Steps to configure the SFC OF Renderer tutorial:
691 1. Send the ``SF`` RESTCONF configuration
693 2. Send the ``SFF`` RESTCONF configuration
695 3. Send the ``SFC`` RESTCONF configuration
697 4. Send the ``SFP`` RESTCONF configuration
699 5. Create the ``RSP`` with a RESTCONF RPC command
701 Once the configuration has been successfully created, query the Rendered
702 Service Paths with either the SFC UI or via RESTCONF. Notice that the
703 RSP is symmetrical, so the following 2 RSPs will be created:
709 At this point the Service Chains have been created, and the OpenFlow
710 Switches are programmed to steer traffic through the Service Chain.
711 Traffic can now be injected from a client into the Service Chain. To
712 debug problems, the OpenFlow tables can be dumped with the following
713 commands, assuming SFF1 is called ``s1`` and SFF2 is called ``s2``.
717 sudo ovs-ofctl -O OpenFlow13 dump-flows s1
721 sudo ovs-ofctl -O OpenFlow13 dump-flows s2
723 In all the following configuration sections, replace the ``${JSON}``
724 string with the appropriate JSON configuration. Also, change the
725 ``localhost`` destination in the URL accordingly.
727 SFC OF Renderer NSH Tutorial
728 ''''''''''''''''''''''''''''
730 The following configuration sections show how to create the different
731 elements using NSH encapsulation.
733 | **NSH Service Function configuration**
735 The Service Function configuration can be sent with the following
740 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function:service-functions/
742 **SF configuration JSON.**
747 "service-functions": {
748 "service-function": [
751 "type": "http-header-enrichment",
752 "ip-mgmt-address": "10.0.0.2",
753 "sf-data-plane-locator": [
758 "transport": "service-locator:vxlan-gpe",
759 "service-function-forwarder": "sff1"
766 "ip-mgmt-address": "10.0.0.3",
767 "sf-data-plane-locator": [
772 "transport": "service-locator:vxlan-gpe",
773 "service-function-forwarder": "sff2"
781 | **NSH Service Function Forwarder configuration**
783 The Service Function Forwarder configuration can be sent with the
788 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/
790 **SFF configuration JSON.**
795 "service-function-forwarders": {
796 "service-function-forwarder": [
799 "service-node": "openflow:2",
800 "sff-data-plane-locator": [
803 "data-plane-locator":
807 "transport": "service-locator:vxlan-gpe"
811 "service-function-dictionary": [
814 "sff-sf-data-plane-locator":
816 "sf-dpl-name": "sf1dpl",
817 "sff-dpl-name": "sff1dpl"
824 "service-node": "openflow:3",
825 "sff-data-plane-locator": [
828 "data-plane-locator":
832 "transport": "service-locator:vxlan-gpe"
836 "service-function-dictionary": [
839 "sff-sf-data-plane-locator":
841 "sf-dpl-name": "sf2dpl",
842 "sff-dpl-name": "sff2dpl"
851 | **NSH Service Function Chain configuration**
853 The Service Function Chain configuration can be sent with the following
858 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-chain:service-function-chains/
860 **SFC configuration JSON.**
865 "service-function-chains": {
866 "service-function-chain": [
868 "name": "sfc-chain1",
869 "sfc-service-function": [
871 "name": "hdr-enrich-abstract1",
872 "type": "http-header-enrichment"
875 "name": "firewall-abstract1",
884 | **NSH Service Function Path configuration**
886 The Service Function Path configuration can be sent with the following
891 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-path:service-function-paths/
893 **SFP configuration JSON.**
898 "service-function-paths": {
899 "service-function-path": [
902 "service-chain-name": "sfc-chain1",
903 "transport-type": "service-locator:vxlan-gpe",
910 | **NSH Rendered Service Path creation**
914 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X POST --user admin:admin http://localhost:8181/restconf/operations/rendered-service-path:create-rendered-path/
916 **RSP creation JSON.**
923 "parent-service-function-path": "sfc-path1"
927 | **NSH Rendered Service Path removal**
929 The following command can be used to remove a Rendered Service Path
930 called ``sfc-path1``:
934 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '{"input": {"name": "sfc-path1" } }' -X POST --user admin:admin http://localhost:8181/restconf/operations/rendered-service-path:delete-rendered-path/
936 | **NSH Rendered Service Path Query**
938 The following command can be used to query all of the created Rendered
943 curl -H "Content-Type: application/json" -H "Cache-Control: no-cache" -X GET --user admin:admin http://localhost:8181/restconf/operational/rendered-service-path:rendered-service-paths/
945 SFC OF Renderer MPLS Tutorial
946 '''''''''''''''''''''''''''''
948 The following configuration sections show how to create the different
949 elements using MPLS encapsulation.
951 | **MPLS Service Function configuration**
953 The Service Function configuration can be sent with the following
958 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function:service-functions/
960 **SF configuration JSON.**
965 "service-functions": {
966 "service-function": [
969 "type": "http-header-enrichment",
970 "ip-mgmt-address": "10.0.0.2",
971 "sf-data-plane-locator": [
974 "mac": "00:00:08:01:02:01",
976 "transport": "service-locator:mac",
977 "service-function-forwarder": "sff1"
984 "ip-mgmt-address": "10.0.0.3",
985 "sf-data-plane-locator": [
988 "mac": "00:00:08:01:03:01",
990 "transport": "service-locator:mac",
991 "service-function-forwarder": "sff2"
999 | **MPLS Service Function Forwarder configuration**
1001 The Service Function Forwarder configuration can be sent with the
1006 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/
1008 **SFF configuration JSON.**
1013 "service-function-forwarders": {
1014 "service-function-forwarder": [
1017 "service-node": "openflow:2",
1018 "sff-data-plane-locator": [
1020 "name": "ulSff1Ingress",
1021 "data-plane-locator":
1024 "transport": "service-locator:mpls"
1026 "service-function-forwarder-ofs:ofs-port":
1028 "mac": "11:11:11:11:11:11",
1033 "name": "ulSff1ToSff2",
1034 "data-plane-locator":
1037 "transport": "service-locator:mpls"
1039 "service-function-forwarder-ofs:ofs-port":
1041 "mac": "33:33:33:33:33:33",
1047 "data-plane-locator":
1049 "mac": "22:22:22:22:22:22",
1051 "transport": "service-locator:mac",
1053 "service-function-forwarder-ofs:ofs-port":
1055 "mac": "33:33:33:33:33:33",
1060 "service-function-dictionary": [
1063 "sff-sf-data-plane-locator":
1065 "sf-dpl-name": "sf1-sff1",
1066 "sff-dpl-name": "toSf1"
1073 "service-node": "openflow:3",
1074 "sff-data-plane-locator": [
1076 "name": "ulSff2Ingress",
1077 "data-plane-locator":
1080 "transport": "service-locator:mpls"
1082 "service-function-forwarder-ofs:ofs-port":
1084 "mac": "44:44:44:44:44:44",
1089 "name": "ulSff2Egress",
1090 "data-plane-locator":
1093 "transport": "service-locator:mpls"
1095 "service-function-forwarder-ofs:ofs-port":
1097 "mac": "66:66:66:66:66:66",
1103 "data-plane-locator":
1105 "mac": "55:55:55:55:55:55",
1107 "transport": "service-locator:mac"
1109 "service-function-forwarder-ofs:ofs-port":
1115 "service-function-dictionary": [
1118 "sff-sf-data-plane-locator":
1120 "sf-dpl-name": "sf2-sff2",
1121 "sff-dpl-name": "toSf2"
1124 "service-function-forwarder-ofs:ofs-port":
1135 | **MPLS Service Function Chain configuration**
1137 The Service Function Chain configuration can be sent with the following
1142 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-chain:service-function-chains/
1144 **SFC configuration JSON.**
1149 "service-function-chains": {
1150 "service-function-chain": [
1152 "name": "sfc-chain1",
1153 "sfc-service-function": [
1155 "name": "hdr-enrich-abstract1",
1156 "type": "http-header-enrichment"
1159 "name": "firewall-abstract1",
1168 | **MPLS Service Function Path configuration**
1170 The Service Function Path configuration can be sent with the following
1175 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-path:service-function-paths/
1177 **SFP configuration JSON.**
1182 "service-function-paths": {
1183 "service-function-path": [
1185 "name": "sfc-path1",
1186 "service-chain-name": "sfc-chain1",
1187 "transport-type": "service-locator:mpls",
1194 | **MPLS Rendered Service Path creation**
1198 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X POST --user admin:admin http://localhost:8181/restconf/operations/rendered-service-path:create-rendered-path/
1200 **RSP creation JSON.**
1206 "name": "sfc-path1",
1207 "parent-service-function-path": "sfc-path1"
1211 | **MPLS Rendered Service Path removal**
1213 The following command can be used to remove a Rendered Service Path
1214 called ``sfc-path1``:
1218 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '{"input": {"name": "sfc-path1" } }' -X POST --user admin:admin http://localhost:8181/restconf/operations/rendered-service-path:delete-rendered-path/
1220 | **MPLS Rendered Service Path Query**
1222 The following command can be used to query all of the created Rendered
1227 curl -H "Content-Type: application/json" -H "Cache-Control: no-cache" -X GET --user admin:admin http://localhost:8181/restconf/operational/rendered-service-path:rendered-service-paths/
1229 SFC IOS XE Renderer User Guide
1230 ------------------------------
1235 The early Service Function Chaining (SFC) renderer for IOS-XE devices
1236 (SFC IOS-XE renderer) implements Service Chaining functionality on
1237 IOS-XE capable switches. It listens for the creation of a Rendered
1238 Service Path (RSP) and sets up Service Function Forwarders (SFF) that
1239 are hosted on IOS-XE switches to steer traffic through the service
1242 Common acronyms used in the following sections:
1244 - SF - Service Function
1246 - SFF - Service Function Forwarder
1248 - SFC - Service Function Chain
1252 - SFP - Service Function Path
1254 - RSP - Rendered Service Path
1256 - LSF - Local Service Forwarder
1258 - RSF - Remote Service Forwarder
1260 SFC IOS-XE Renderer Architecture
1261 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1263 When the SFC IOS-XE renderer is initialized, all required listeners are
1264 registered to handle incoming data. It involves CSR/IOS-XE
1265 ``NodeListener`` which stores data about all configurable devices
1266 including their mountpoints (used here as databrokers),
1267 ``ServiceFunctionListener``, ``ServiceForwarderListener`` (see mapping)
1268 and ``RenderedPathListener`` used to listen for RSP changes. When the
1269 SFC IOS-XE renderer is invoked, ``RenderedPathListener`` calls the
1270 ``IosXeRspProcessor`` which processes the RSP change and creates all
1271 necessary Service Paths and Remote Service Forwarders (if necessary) on
1274 Service Path details
1275 ~~~~~~~~~~~~~~~~~~~~
1277 Each Service Path is defined by index (represented by NSP) and contains
1278 service path entries. Each entry has appropriate service index (NSI) and
1279 definition of next hop. Next hop can be Service Function, different
1280 Service Function Forwarder or definition of end of chain - terminate.
1281 After terminating, the packet is sent to destination. If a SFF is
1282 defined as a next hop, it has to be present on device in the form of
1283 Remote Service Forwarder. RSFs are also created during RSP processing.
1285 Example of Service Path:
1289 service-chain service-path 200
1290 service-index 255 service-function firewall-1
1291 service-index 254 service-function dpi-1
1292 service-index 253 terminate
1294 Mapping to IOS-XE SFC entities
1295 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1297 Renderer contains mappers for SFs and SFFs. IOS-XE capable device is
1298 using its own definition of Service Functions and Service Function
1299 Forwarders according to appropriate .yang file.
1300 ``ServiceFunctionListener`` serves as a listener for SF changes. If SF
1301 appears in datastore, listener extracts its management ip address and
1302 looks into cached IOS-XE nodes. If some of available nodes match,
1303 Service function is mapped in ``IosXeServiceFunctionMapper`` to be
1304 understandable by IOS-XE device and it’s written into device’s config.
1305 ``ServiceForwarderListener`` is used in a similar way. All SFFs with
1306 suitable management ip address it mapped in
1307 ``IosXeServiceForwarderMapper``. Remapped SFFs are configured as a Local
1308 Service Forwarders. It is not possible to directly create Remote Service
1309 Forwarder using IOS-XE renderer. RSF is created only during RSP
1312 Administering SFC IOS-XE renderer
1313 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1315 To use the SFC IOS-XE Renderer Karaf, at least the following Karaf
1316 features must be installed:
1326 - odl-netconf-topology
1328 - odl-sfc-ios-xe-renderer
1330 SFC IOS-XE renderer Tutorial
1331 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1336 This tutorial is a simple example how to create Service Path on IOS-XE
1337 capable device using IOS-XE renderer
1342 To connect to IOS-XE device, it is necessary to use several modified
1343 yang models and override device’s ones. All .yang files are in the
1344 ``Yang/netconf`` folder in the ``sfc-ios-xe-renderer module`` in the SFC
1345 project. These files have to be copied to the ``cache/schema``
1346 directory, before Karaf is started. After that, custom capabilities have
1347 to be sent to network-topology:
1351 PUT ./config/network-topology:network-topology/topology/topology-netconf/node/<device-name>
1353 <node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
1354 <node-id>device-name</node-id>
1355 <host xmlns="urn:opendaylight:netconf-node-topology">device-ip</host>
1356 <port xmlns="urn:opendaylight:netconf-node-topology">2022</port>
1357 <username xmlns="urn:opendaylight:netconf-node-topology">login</username>
1358 <password xmlns="urn:opendaylight:netconf-node-topology">password</password>
1359 <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
1360 <keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">0</keepalive-delay>
1361 <yang-module-capabilities xmlns="urn:opendaylight:netconf-node-topology">
1362 <override>true</override>
1363 <capability xmlns="urn:opendaylight:netconf-node-topology">
1364 urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2013-07-15
1366 <capability xmlns="urn:opendaylight:netconf-node-topology">
1367 urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&revision=2013-07-15
1369 <capability xmlns="urn:opendaylight:netconf-node-topology">
1370 urn:ios?module=ned&revision=2016-03-08
1372 <capability xmlns="urn:opendaylight:netconf-node-topology">
1373 http://tail-f.com/yang/common?module=tailf-common&revision=2015-05-22
1375 <capability xmlns="urn:opendaylight:netconf-node-topology">
1376 http://tail-f.com/yang/common?module=tailf-meta-extensions&revision=2013-11-07
1378 <capability xmlns="urn:opendaylight:netconf-node-topology">
1379 http://tail-f.com/yang/common?module=tailf-cli-extensions&revision=2015-03-19
1381 </yang-module-capabilities>
1386 The device name in the URL and in the XML must match.
1391 When the IOS-XE renderer is installed, all NETCONF nodes in
1392 topology-netconf are processed and all capable nodes with accessible
1393 mountpoints are cached. The first step is to create LSF on node.
1395 ``Service Function Forwarder configuration``
1399 PUT ./config/service-function-forwarder:service-function-forwarders
1402 "service-function-forwarders": {
1403 "service-function-forwarder": [
1406 "ip-mgmt-address": "172.25.73.23",
1407 "sff-data-plane-locator": [
1409 "name": "CSR1Kv-2-dpl",
1410 "data-plane-locator": {
1411 "transport": "service-locator:vxlan-gpe",
1413 "ip": "10.99.150.10"
1422 If the IOS-XE node with appropriate management IP exists, this
1423 configuration is mapped and LSF is created on the device. The same
1424 approach is used for Service Functions.
1428 PUT ./config/service-function:service-functions
1431 "service-functions": {
1432 "service-function": [
1435 "ip-mgmt-address": "172.25.73.23",
1437 "sf-data-plane-locator": [
1439 "name": "firewall-dpl",
1442 "transport": "service-locator:gre",
1443 "service-function-forwarder": "CSR1Kv-2"
1449 "ip-mgmt-address": "172.25.73.23",
1451 "sf-data-plane-locator": [
1456 "transport": "service-locator:gre",
1457 "service-function-forwarder": "CSR1Kv-2"
1463 "ip-mgmt-address": "172.25.73.23",
1465 "sf-data-plane-locator": [
1470 "transport": "service-locator:gre",
1471 "service-function-forwarder": "CSR1Kv-2"
1479 All these SFs are configured on the same device as the LSF. The next
1480 step is to prepare Service Function Chain.
1484 PUT ./config/service-function-chain:service-function-chains/
1487 "service-function-chains": {
1488 "service-function-chain": [
1491 "sfc-service-function": [
1510 Service Function Path:
1514 PUT ./config/service-function-path:service-function-paths/
1517 "service-function-paths": {
1518 "service-function-path": [
1520 "name": "CSR3XSF-Path",
1521 "service-chain-name": "CSR3XSF",
1522 "starting-index": 255,
1529 Without a classifier, there is possibility to POST RSP directly.
1533 POST ./operations/rendered-service-path:create-rendered-path
1537 "name": "CSR3XSF-Path-RSP",
1538 "parent-service-function-path": "CSR3XSF-Path"
1542 The resulting configuration:
1547 service-chain service-function-forwarder local
1548 ip address 10.99.150.10
1550 service-chain service-function firewall
1552 encapsulation gre enhanced divert
1554 service-chain service-function dpi
1556 encapsulation gre enhanced divert
1558 service-chain service-function qos
1560 encapsulation gre enhanced divert
1562 service-chain service-path 1
1563 service-index 255 service-function firewall
1564 service-index 254 service-function dpi
1565 service-index 253 service-function qos
1566 service-index 252 terminate
1568 service-chain service-path 2
1569 service-index 255 service-function qos
1570 service-index 254 service-function dpi
1571 service-index 253 service-function firewall
1572 service-index 252 terminate
1575 Service Path 1 is direct, Service Path 2 is reversed. Path numbers may
1578 Service Function Scheduling Algorithms
1579 --------------------------------------
1584 When creating the Rendered Service Path, the origin SFC controller chose
1585 the first available service function from a list of service function
1586 names. This may result in many issues such as overloaded service
1587 functions and a longer service path as SFC has no means to understand
1588 the status of service functions and network topology. The service
1589 function selection framework supports at least four algorithms (Random,
1590 Round Robin, Load Balancing and Shortest Path) to select the most
1591 appropriate service function when instantiating the Rendered Service
1592 Path. In addition, it is an extensible framework that allows 3rd party
1593 selection algorithm to be plugged in.
1598 The following figure illustrates the service function selection
1599 framework and algorithms.
1601 .. figure:: ./images/sfc/sf-selection-arch.png
1602 :alt: SF Selection Architecture
1604 SF Selection Architecture
1606 A user has three different ways to select one service function selection
1609 1. Integrated RESTCONF Calls. OpenStack and/or other administration
1610 system could provide plugins to call the APIs to select one
1611 scheduling algorithm.
1613 2. Command line tools. Command line tools such as curl or browser
1614 plugins such as POSTMAN (for Google Chrome) and RESTClient (for
1615 Mozilla Firefox) could select schedule algorithm by making RESTCONF
1618 3. SFC-UI. Now the SFC-UI provides an option for choosing a selection
1619 algorithm when creating a Rendered Service Path.
1621 The RESTCONF northbound SFC API provides GUI/RESTCONF interactions for
1622 choosing the service function selection algorithm. MD-SAL data store
1623 provides all supported service function selection algorithms, and
1624 provides APIs to enable one of the provided service function selection
1625 algorithms. Once a service function selection algorithm is enabled, the
1626 service function selection algorithm will work when creating a Rendered
1629 Select SFs with Scheduler
1630 ~~~~~~~~~~~~~~~~~~~~~~~~~
1632 Administrator could use both the following ways to select one of the
1633 selection algorithm when creating a Rendered Service Path.
1635 - Command line tools. Command line tools includes Linux commands curl
1636 or even browser plugins such as POSTMAN(for Google Chrome) or
1637 RESTClient(for Mozilla Firefox). In this case, the following JSON
1638 content is needed at the moment:
1639 Service\_function\_schudule\_type.json
1644 "service-function-scheduler-types": {
1645 "service-function-scheduler-type": [
1648 "type": "service-function-scheduler-type:random",
1652 "name": "roundrobin",
1653 "type": "service-function-scheduler-type:round-robin",
1657 "name": "loadbalance",
1658 "type": "service-function-scheduler-type:load-balance",
1662 "name": "shortestpath",
1663 "type": "service-function-scheduler-type:shortest-path",
1670 If using the Linux curl command, it could be:
1674 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '$${Service_function_schudule_type.json}'
1675 -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-scheduler-type:service-function-scheduler-types/
1677 Here is also a snapshot for using the RESTClient plugin:
1679 .. figure:: ./images/sfc/RESTClient-snapshot.png
1680 :alt: Mozilla Firefox RESTClient
1682 Mozilla Firefox RESTClient
1684 - SFC-UI.SFC-UI provides a drop down menu for service function
1685 selection algorithm. Here is a snapshot for the user interaction from
1686 SFC-UI when creating a Rendered Service Path.
1688 .. figure:: ./images/sfc/karaf-webui-select-a-type.png
1695 Some service function selection algorithms in the drop list are not
1696 implemented yet. Only the first three algorithms are committed at
1702 Select Service Function from the name list randomly.
1707 The Random algorithm is used to select one Service Function from the
1708 name list which it gets from the Service Function Type randomly.
1713 - Service Function information are stored in datastore.
1715 - Either no algorithm or the Random algorithm is selected.
1720 The Random algorithm will work either no algorithm type is selected or
1721 the Random algorithm is selected.
1726 Once the plugins are installed into Karaf successfully, a user can use
1727 his favorite method to select the Random scheduling algorithm type.
1728 There are no special instructions for using the Random algorithm.
1733 Select Service Function from the name list in Round Robin manner.
1738 The Round Robin algorithm is used to select one Service Function from
1739 the name list which it gets from the Service Function Type in a Round
1740 Robin manner, this will balance workloads to all Service Functions.
1741 However, this method cannot help all Service Functions load the same
1742 workload because it’s flow-based Round Robin.
1747 - Service Function information are stored in datastore.
1749 - Round Robin algorithm is selected
1754 The Round Robin algorithm will work one the Round Robin algorithm is
1760 Once the plugins are installed into Karaf successfully, a user can use
1761 his favorite method to select the Round Robin scheduling algorithm type.
1762 There are no special instructions for using the Round Robin algorithm.
1764 Load Balance Algorithm
1765 ^^^^^^^^^^^^^^^^^^^^^^
1767 Select appropriate Service Function by actual CPU utilization.
1772 The Load Balance Algorithm is used to select appropriate Service
1773 Function by actual CPU utilization of service functions. The CPU
1774 utilization of service function obtained from monitoring information
1775 reported via NETCONF.
1780 - CPU-utilization for Service Function.
1786 - Each VM has a NETCONF server and it could work with NETCONF client
1792 Set up VMs as Service Functions. enable NETCONF server in VMs. Ensure
1793 that you specify them separately. For example:
1795 a. Set up 4 VMs include 2 SFs' type are Firewall, Others are Napt44.
1796 Name them as firewall-1, firewall-2, napt44-1, napt44-2 as Service
1797 Function. The four VMs can run either the same server or different
1800 b. Install NETCONF server on every VM and enable it. More information on
1801 NETCONF can be found on the OpenDaylight wiki here:
1802 https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf:Manual_netopeer_installation
1804 c. Get Monitoring data from NETCONF server. These monitoring data should
1805 be get from the NETCONF server which is running in VMs. The following
1806 static XML data is an example:
1808 static XML data like this:
1812 <?xml version="1.0" encoding="UTF-8"?>
1813 <service-function-description-monitor-report>
1815 <number-of-dataports>2</number-of-dataports>
1817 <supported-packet-rate>5</supported-packet-rate>
1818 <supported-bandwidth>10</supported-bandwidth>
1819 <supported-ACL-number>2000</supported-ACL-number>
1820 <RIB-size>200</RIB-size>
1821 <FIB-size>100</FIB-size>
1824 <port-id>1</port-id>
1825 <ipaddress>10.0.0.1</ipaddress>
1826 <macaddress>00:1e:67:a2:5f:f4</macaddress>
1827 <supported-bandwidth>20</supported-bandwidth>
1830 <port-id>2</port-id>
1831 <ipaddress>10.0.0.2</ipaddress>
1832 <macaddress>01:1e:67:a2:5f:f6</macaddress>
1833 <supported-bandwidth>10</supported-bandwidth>
1838 <SF-monitoring-info>
1839 <liveness>true</liveness>
1840 <resource-utilization>
1841 <packet-rate-utilization>10</packet-rate-utilization>
1842 <bandwidth-utilization>15</bandwidth-utilization>
1843 <CPU-utilization>12</CPU-utilization>
1844 <memory-utilization>17</memory-utilization>
1845 <available-memory>8</available-memory>
1846 <RIB-utilization>20</RIB-utilization>
1847 <FIB-utilization>25</FIB-utilization>
1848 <power-utilization>30</power-utilization>
1849 <SF-ports-bandwidth-utilization>
1850 <port-bandwidth-utilization>
1851 <port-id>1</port-id>
1852 <bandwidth-utilization>20</bandwidth-utilization>
1853 </port-bandwidth-utilization>
1854 <port-bandwidth-utilization>
1855 <port-id>2</port-id>
1856 <bandwidth-utilization>30</bandwidth-utilization>
1857 </port-bandwidth-utilization>
1858 </SF-ports-bandwidth-utilization>
1859 </resource-utilization>
1860 </SF-monitoring-info>
1861 </service-function-description-monitor-report>
1863 a. Unzip SFC release tarball.
1865 b. Run SFC: ${sfc}/bin/karaf. More information on Service Function
1866 Chaining can be found on the OpenDaylight SFC’s wiki page:
1867 https://wiki.opendaylight.org/view/Service_Function_Chaining:Main
1869 a. Deploy the SFC2 (firewall-abstract2⇒napt44-abstract2) and click
1870 button to Create Rendered Service Path in SFC UI
1871 (http://localhost:8181/sfc/index.html).
1873 b. Verify the Rendered Service Path to ensure the CPU utilization of the
1874 selected hop is the minimum one among all the service functions with
1875 same type. The correct RSP is firewall-1⇒napt44-2
1877 Shortest Path Algorithm
1878 ^^^^^^^^^^^^^^^^^^^^^^^
1880 Select appropriate Service Function by Dijkstra’s algorithm. Dijkstra’s
1881 algorithm is an algorithm for finding the shortest paths between nodes
1887 The Shortest Path Algorithm is used to select appropriate Service
1888 Function by actual topology.
1893 - Deployed topology (include SFFs, SFs and their links).
1895 - Dijkstra’s algorithm. More information on Dijkstra’s algorithm can be
1896 found on the wiki here:
1897 http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm
1902 a. Unzip SFC release tarball.
1904 b. Run SFC: ${sfc}/bin/karaf.
1906 c. Depoly SFFs and SFs. import the service-function-forwarders.json and
1907 service-functions.json in UI
1908 (http://localhost:8181/sfc/index.html#/sfc/config)
1910 service-function-forwarders.json:
1915 "service-function-forwarders": {
1916 "service-function-forwarder": [
1919 "service-node": "OVSDB-test01",
1920 "rest-uri": "http://localhost:5001",
1921 "sff-data-plane-locator": [
1924 "service-function-forwarder-ovs:ovs-bridge": {
1925 "uuid": "4c3778e4-840d-47f4-b45e-0988e514d26c",
1926 "bridge-name": "br-tun"
1928 "data-plane-locator": {
1930 "ip": "192.168.1.1",
1931 "transport": "service-locator:vxlan-gpe"
1935 "service-function-dictionary": [
1937 "sff-sf-data-plane-locator": {
1938 "sf-dpl-name": "sf1dpl",
1939 "sff-dpl-name": "sff1dpl"
1945 "sff-sf-data-plane-locator": {
1946 "sf-dpl-name": "sf2dpl",
1947 "sff-dpl-name": "sff2dpl"
1949 "name": "firewall-1",
1953 "connected-sff-dictionary": [
1961 "service-node": "OVSDB-test01",
1962 "rest-uri": "http://localhost:5002",
1963 "sff-data-plane-locator": [
1966 "service-function-forwarder-ovs:ovs-bridge": {
1967 "uuid": "fd4d849f-5140-48cd-bc60-6ad1f5fc0a1",
1968 "bridge-name": "br-tun"
1970 "data-plane-locator": {
1972 "ip": "192.168.1.2",
1973 "transport": "service-locator:vxlan-gpe"
1977 "service-function-dictionary": [
1979 "sff-sf-data-plane-locator": {
1980 "sf-dpl-name": "sf1dpl",
1981 "sff-dpl-name": "sff1dpl"
1987 "sff-sf-data-plane-locator": {
1988 "sf-dpl-name": "sf2dpl",
1989 "sff-dpl-name": "sff2dpl"
1991 "name": "firewall-2",
1995 "connected-sff-dictionary": [
2003 "service-node": "OVSDB-test01",
2004 "rest-uri": "http://localhost:5005",
2005 "sff-data-plane-locator": [
2008 "service-function-forwarder-ovs:ovs-bridge": {
2009 "uuid": "fd4d849f-5140-48cd-bc60-6ad1f5fc0a4",
2010 "bridge-name": "br-tun"
2012 "data-plane-locator": {
2014 "ip": "192.168.1.2",
2015 "transport": "service-locator:vxlan-gpe"
2019 "service-function-dictionary": [
2021 "sff-sf-data-plane-locator": {
2022 "sf-dpl-name": "sf1dpl",
2023 "sff-dpl-name": "sff1dpl"
2025 "name": "test-server",
2029 "sff-sf-data-plane-locator": {
2030 "sf-dpl-name": "sf2dpl",
2031 "sff-dpl-name": "sff2dpl"
2033 "name": "test-client",
2037 "connected-sff-dictionary": [
2050 service-functions.json:
2055 "service-functions": {
2056 "service-function": [
2058 "rest-uri": "http://localhost:10001",
2059 "ip-mgmt-address": "10.3.1.103",
2060 "sf-data-plane-locator": [
2062 "name": "preferred",
2065 "service-function-forwarder": "SFF-br1"
2072 "rest-uri": "http://localhost:10002",
2073 "ip-mgmt-address": "10.3.1.103",
2074 "sf-data-plane-locator": [
2079 "service-function-forwarder": "SFF-br2"
2086 "rest-uri": "http://localhost:10003",
2087 "ip-mgmt-address": "10.3.1.103",
2088 "sf-data-plane-locator": [
2093 "service-function-forwarder": "SFF-br1"
2096 "name": "firewall-1",
2100 "rest-uri": "http://localhost:10004",
2101 "ip-mgmt-address": "10.3.1.103",
2102 "sf-data-plane-locator": [
2107 "service-function-forwarder": "SFF-br2"
2110 "name": "firewall-2",
2114 "rest-uri": "http://localhost:10005",
2115 "ip-mgmt-address": "10.3.1.103",
2116 "sf-data-plane-locator": [
2121 "service-function-forwarder": "SFF-br3"
2124 "name": "test-server",
2128 "rest-uri": "http://localhost:10006",
2129 "ip-mgmt-address": "10.3.1.103",
2130 "sf-data-plane-locator": [
2135 "service-function-forwarder": "SFF-br3"
2138 "name": "test-client",
2145 The deployed topology like this:
2149 +----+ +----+ +----+
2150 |sff1|+----------|sff3|---------+|sff2|
2151 +----+ +----+ +----+
2153 +--------------+ +--------------+
2155 +----------+ +--------+ +----------+ +--------+
2156 |firewall-1| |napt44-1| |firewall-2| |napt44-2|
2157 +----------+ +--------+ +----------+ +--------+
2159 - Deploy the SFC2(firewall-abstract2⇒napt44-abstract2), select
2160 "Shortest Path" as schedule type and click button to Create Rendered
2161 Service Path in SFC UI (http://localhost:8181/sfc/index.html).
2163 .. figure:: ./images/sfc/sf-schedule-type.png
2164 :alt: select schedule type
2166 select schedule type
2168 - Verify the Rendered Service Path to ensure the selected hops are
2169 linked in one SFF. The correct RSP is firewall-1⇒napt44-1 or
2170 firewall-2⇒napt44-2. The first SF type is Firewall in Service
2171 Function Chain. So the algorithm will select first Hop randomly among
2172 all the SFs type is Firewall. Assume the first selected SF is
2173 firewall-2. All the path from firewall-1 to SF which type is Napt44
2176 - Path1: firewall-2 → sff2 → napt44-2
2178 - Path2: firewall-2 → sff2 → sff3 → sff1 → napt44-1 The shortest
2179 path is Path1, so the selected next hop is napt44-2.
2181 .. figure:: ./images/sfc/sf-rendered-service-path.png
2182 :alt: rendered service path
2184 rendered service path
2186 Service Function Load Balancing User Guide
2187 ------------------------------------------
2192 SFC Load-Balancing feature implements load balancing of Service
2193 Functions, rather than a one-to-one mapping between
2194 Service-Function-Forwarder and Service-Function.
2196 Load Balancing Architecture
2197 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
2199 Service Function Groups (SFG) can replace Service Functions (SF) in the
2200 Rendered Path model. A Service Path can only be defined using SFGs or
2201 SFs, but not a combination of both.
2203 Relevant objects in the YANG model are as follows:
2205 1. Service-Function-Group-Algorithm:
2209 Service-Function-Group-Algorithms {
2210 Service-Function-Group-Algorithm {
2218 Available types: ALL, SELECT, INDIRECT, FAST_FAILURE
2220 2. Service-Function-Group:
2224 Service-Function-Groups {
2225 Service-Function-Group {
2227 String serviceFunctionGroupAlgorithmName
2230 Service-Function-Group-Element {
2231 String service-function-name
2237 3. ServiceFunctionHop: holds a reference to a name of SFG (or SF)
2242 This tutorial will explain how to create a simple SFC configuration,
2243 with SFG instead of SF. In this example, the SFG will include two
2249 For general SFC setup and scenarios, please see the SFC wiki page:
2250 https://wiki.opendaylight.org/view/Service_Function_Chaining:Main#SFC_101
2256 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2261 "service-function-group-algorithm": [
2269 (Header "content-type": application/json)
2271 Verify: get all algorithms
2272 ^^^^^^^^^^^^^^^^^^^^^^^^^^
2275 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2277 In order to delete all algorithms: DELETE -
2278 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2284 http://127.0.0.1:8181/restconf/config/service-function-group:service-function-groups
2289 "service-function-group": [
2291 "rest-uri": "http://localhost:10002",
2292 "ip-mgmt-address": "10.3.1.103",
2293 "algorithm": "alg1",
2296 "sfc-service-function": [
2301 "name":"napt44-103-1"
2308 Verify: get all SFG’s
2309 ^^^^^^^^^^^^^^^^^^^^^
2312 http://127.0.0.1:8181/restconf/config/service-function-group:service-function-groups
2314 SFC Proof of Transit User Guide
2315 -------------------------------
2320 Early Service Function Chaining (SFC) Proof of Transit (SFC Proof of
2321 Transit) implements Service Chaining Proof of Transit functionality on
2322 capable switches. After the creation of an Rendered Service Path (RSP),
2323 a user can configure to enable SFC proof of transit on the selected RSP
2324 to effect the proof of transit.
2326 Common acronyms used in the following sections:
2328 - SF - Service Function
2330 - SFF - Service Function Forwarder
2332 - SFC - Service Function Chain
2334 - SFP - Service Function Path
2336 - RSP - Rendered Service Path
2338 - SFCPOT - Service Function Chain Proof of Transit
2340 SFC Proof of Transit Architecture
2341 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2343 When SFC Proof of Transit is initialized, all required listeners are
2344 registered to handle incoming data. It involves ``SfcPotNodeListener``
2345 which stores data about all node devices including their mountpoints
2346 (used here as databrokers), ``SfcPotRSPDataListener``,
2347 ``RenderedPathListener``. ``RenderedPathListener`` is used to listen for
2348 RSP changes. ``SfcPotRSPDataListener`` implements RPC services to enable
2349 or disable SFC Proof of Transit on a particular RSP. When the SFC Proof
2350 of Transit is invoked, RSP listeners and service implementations are
2351 setup to receive SFCPOT configurations. When a user configures via a
2352 POST RPC call to enable SFCPOT on a particular RSP, the configuration
2353 drives the creation of necessary augmentations to the RSP to effect the
2354 SFCPOT configurations.
2356 SFC Proof of Transit details
2357 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2359 Several deployments use traffic engineering, policy routing, segment
2360 routing or service function chaining (SFC) to steer packets through a
2361 specific set of nodes. In certain cases regulatory obligations or a
2362 compliance policy require to prove that all packets that are supposed to
2363 follow a specific path are indeed being forwarded across the exact set
2364 of nodes specified. I.e. if a packet flow is supposed to go through a
2365 series of service functions or network nodes, it has to be proven that
2366 all packets of the flow actually went through the service chain or
2367 collection of nodes specified by the policy. In case the packets of a
2368 flow weren’t appropriately processed, a proof of transit egress device
2369 would be required to identify the policy violation and take
2370 corresponding actions (e.g. drop or redirect the packet, send an alert
2371 etc.) corresponding to the policy.
2373 The SFCPOT approach is based on meta-data which is added to every
2374 packet. The meta data is updated at every hop and is used to verify
2375 whether a packet traversed all required nodes. A particular path is
2376 either described by a set of secret keys, or a set of shares of a single
2377 secret. Nodes on the path retrieve their individual keys or shares of a
2378 key (using for e.g. Shamir’s Shared Sharing Secret scheme) from a
2379 central controller. The complete key set is only known to the verifier-
2380 which is typically the ultimate node on a path that requires proof of
2381 transit. Each node in the path uses its secret or share of the secret to
2382 update the meta-data of the packets as the packets pass through the
2383 node. When the verifier receives a packet, it can use its key(s) along
2384 with the meta-data to validate whether the packet traversed the service
2387 SFC Proof of Transit entities
2388 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2390 In order to implement SFC Proof of Transit for a service function chain,
2391 an RSP is a pre-requisite to identify the SFC to enable SFC PoT on. SFC
2392 Proof of Transit for a particular RSP is enabled by an RPC request to
2393 the controller along with necessary parameters to control some of the
2394 aspects of the SFC Proof of Transit process.
2396 The RPC handler identifies the RSP and generates SFC Proof of Transit
2397 parameters like secret share, secret etc., and adds the generated SFCPOT
2398 configuration parameters to SFC main as well as the various SFC hops.
2399 The last node in the SFC is configured as a verifier node to allow
2400 SFCPOT Proof of Transit process to be completed.
2402 The SFCPOT configuration generators and related handling are done by
2403 ``SfcPotAPI``, ``SfcPotConfigGenerator``, ``SfcPotListener``,
2404 ``SfcPotPolyAPI``, ``SfcPotPolyClassAPI`` and ``SfcPotPolyClass``.
2406 Administering SFC Proof of Transit
2407 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2409 To use the SFC Proof of Transit Karaf, at least the following Karaf
2410 features must be installed:
2420 - odl-netconf-topology
2422 - odl-netconf-connector-all
2426 SFC Proof of Transit Tutorial
2427 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2432 This tutorial is a simple example how to configure Service Function
2433 Chain Proof of Transit using SFC POT feature.
2438 To enable a device to handle SFC Proof of Transit, it is expected that
2439 the netconf server device advertise capability as under ioam-scv.yang
2440 present under src/main/yang folder of sfc-pot feature. It is also
2441 expected that netconf notifications be enabled and its support
2442 capability advertised as capabilities.
2444 It is also expected that the devices are netconf mounted and available
2445 in the topology-netconf store.
2450 When SFC Proof of Transit is installed, all netconf nodes in
2451 topology-netconf are processed and all capable nodes with accessible
2452 mountpoints are cached.
2454 First step is to create the required RSP as usually done.
2456 Once RSP name is available it is used to send a POST RPC to the
2457 controller similar to below:
2461 POST ./restconf/operations/sfc-ioam-nb-pot:enable-sfc-ioam-pot-rendered-path
2465 "sfc-ioam-pot-rsp-name": "rsp1"
2469 The following can be used to disable the SFC Proof of Transit on an RSP
2470 which removes the augmentations and stores back the RSP without the
2471 SFCPOT enabled features and also sending down a delete configuration to
2472 the SFCPOT configuration sub-tree in the nodes.
2476 POST ./restconf/operations/sfc-ioam-nb-pot:disable-sfc-ioam-pot-rendered-path
2480 "sfc-ioam-pot-rsp-name": "rsp1"
2484 Logical Service Function Forwarder
2485 ----------------------------------
2490 .. _sfc-user-guide-logical-sff-motivation:
2494 When the current SFC is deployed in a cloud environment, it is assumed that each
2495 switch connected to a Service Function is configured as a Service Function Forwarder and
2496 each Service Function is connected to its Service Function Forwarder depending on the
2497 Compute Node where the Virtual Machine is located.
2499 .. figure:: ./images/sfc/sfc-in-cloud.png
2500 :alt: Deploying SFC in Cloud Environments
2502 As shown in the picture above, this solution allows the basic cloud use cases to be fulfilled,
2503 as for example, the ones required in OPNFV Brahmaputra, however, some advanced use cases
2504 like the transparent migration of VMs can not be implemented. The Logical Service Function Forwarder
2505 enables the following advanced use cases:
2507 1. Service Function mobility without service disruption
2508 2. Service Functions load balancing and failover
2510 As shown in the picture below, the Logical Service Function Forwarder concept extends the current
2511 SFC northbound API to provide an abstraction of the underlying Data Center infrastructure.
2512 The Data Center underlaying network can be abstracted by a single SFF. This single SFF uses
2513 the logical port UUID as data plane locator to connect SFs globally and in a location-transparent manner.
2514 SFC makes use of `Genius <./genius-user-guide.html>`__ project to track the
2515 location of the SF's logical ports.
2517 .. figure:: ./images/sfc/single-logical-sff-concept.png
2518 :alt: Single Logical SFF concept
2520 The SFC internally distributes the necessary flow state over the relevant switches based on the
2521 internal Data Center topology and the deployment of SFs.
2523 Changes in data model
2524 ~~~~~~~~~~~~~~~~~~~~~
2525 The Logical Service Function Forwarder concept extends the current SFC northbound API to provide
2526 an abstraction of the underlying Data Center infrastructure.
2528 The Logical SFF simplifies the configuration of the current SFC data model by reducing the number
2529 of parameters to be be configured in every SFF, since the controller will discover those parameters
2530 by interacting with the services offered by the `Genius <./genius-user-guide.html>`__ project.
2532 The following picture shows the Logical SFF data model. The model gets simplified as most of the
2533 configuration parameters of the current SFC data model are discovered in runtime. The complete
2534 YANG model can be found here `logical SFF model
2535 <https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/service-function-forwarder-logical.yang>`__.
2537 .. figure:: ./images/sfc/logical-sff-datamodel.png
2538 :alt: Logical SFF data model
2540 How to configure the Logical SFF
2541 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2542 The following are examples to configure the Logical SFF:
2545 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/restconf/config/service-function:service-functions/
2547 **Service Functions JSON.**
2552 "service-functions": {
2553 "service-function": [
2555 "name": "firewall-1",
2557 "sf-data-plane-locator": [
2559 "name": "firewall-dpl",
2560 "interface-name": "eccb57ae-5a2e-467f-823e-45d7bb2a6a9a",
2561 "transport": "service-locator:eth-nsh",
2562 "service-function-forwarder": "sfflogical1"
2570 "sf-data-plane-locator": [
2573 "interface-name": "df15ac52-e8ef-4e9a-8340-ae0738aba0c0",
2574 "transport": "service-locator:eth-nsh",
2575 "service-function-forwarder": "sfflogical1"
2585 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/
2587 **Service Function Forwarders JSON.**
2592 "service-function-forwarders": {
2593 "service-function-forwarder": [
2595 "name": "sfflogical1"
2603 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-chain:service-function-chains/
2605 **Service Function Chains JSON.**
2610 "service-function-chains": {
2611 "service-function-chain": [
2614 "sfc-service-function": [
2616 "name": "dpi-abstract1",
2620 "name": "firewall-abstract1",
2627 "sfc-service-function": [
2629 "name": "dpi-abstract1",
2640 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8182/restconf/config/service-function-chain:service-function-paths/
2642 **Service Function Paths JSON.**
2647 "service-function-paths": {
2648 "service-function-path": [
2651 "service-chain-name": "SFC1",
2652 "starting-index": 255,
2653 "symmetric": "true",
2654 "context-metadata": "NSH1",
2655 "transport-type": "service-locator:vxlan-gpe"
2662 As a result of above configuration, OpenDaylight renders the needed flows in all involved SFFs. Those flows implement:
2664 - Two Rendered Service Paths:
2666 - dpi-1 (SF1), firewall-1 (SF2)
2667 - firewall-1 (SF2), dpi-1 (SF1)
2669 - The communication between SFFs and SFs based on eth-nsh
2671 - The communication between SFFs based on vxlan-gpe
2673 The following picture shows a topology and traffic flow (in green) which corresponds to the above configuration.
2675 .. figure:: ./images/sfc/single-logical-sff-example.png
2676 :alt: Logical SFF Example
2684 The Logical SFF functionality allows OpenDaylight to find out the SFFs holding the SFs involved in a path. In this example
2685 the SFFs affected are Node3 and Node4 thus the controller renders the flows containing NSH parameters just in those SFFs.
2687 Here you have the new flows rendered in Node3 and Node4 which implement the NSH protocol. Every Rendered Service Path is represented
2688 by an NSP value. We provisioned a symmetric RSP so we get two NSPs: 8388613 and 5. Node3 holds the first SF of NSP 8388613 and
2689 the last SF of NSP 5. Node 4 holds the first SF of NSP 5 and the last SF of NSP 8388613. Both Node3 and Node4 will pop the NSH header
2690 when the received packet has gone through the last SF of its path.
2693 **Rendered flows Node 3**
2697 cookie=0x14, duration=59.264s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
2698 cookie=0x14, duration=59.194s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
2699 cookie=0x14, duration=59.257s, table=86, n_packets=0, n_bytes=0, priority=550,nsi=254,nsp=5 actions=load:0x8e0a37cc9094->NXM_NX_ENCAP_ETH_SRC[],load:0x6ee006b4c51e->NXM_NX_ENCAP_ETH_DST[],goto_table:87
2700 cookie=0x14, duration=59.189s, table=86, n_packets=0, n_bytes=0, priority=550,nsi=255,nsp=8388613 actions=load:0x8e0a37cc9094->NXM_NX_ENCAP_ETH_SRC[],load:0x6ee006b4c51e->NXM_NX_ENCAP_ETH_DST[],goto_table:87
2701 cookie=0xba5eba1100000203, duration=59.213s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=253,nsp=5 actions=pop_nsh,set_field:6e:e0:06:b4:c5:1e->eth_src,resubmit(,17)
2702 cookie=0xba5eba1100000201, duration=59.213s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=254,nsp=5 actions=load:0x800->NXM_NX_REG6[],resubmit(,220)
2703 cookie=0xba5eba1100000201, duration=59.188s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=255,nsp=8388613 actions=load:0x800->NXM_NX_REG6[],resubmit(,220)
2704 cookie=0xba5eba1100000201, duration=59.182s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=254,nsp=8388613 actions=set_field:0->tun_id,output:6
2706 **Rendered Flows Node 4**
2710 cookie=0x14, duration=69.040s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
2711 cookie=0x14, duration=69.008s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
2712 cookie=0x14, duration=69.040s, table=86, n_packets=0, n_bytes=0, priority=550,nsi=255,nsp=5 actions=load:0xbea93873f4fa->NXM_NX_ENCAP_ETH_SRC[],load:0x214845ea85d->NXM_NX_ENCAP_ETH_DST[],goto_table:87
2713 cookie=0x14, duration=69.005s, table=86, n_packets=0, n_bytes=0, priority=550,nsi=254,nsp=8388613 actions=load:0xbea93873f4fa->NXM_NX_ENCAP_ETH_SRC[],load:0x214845ea85d->NXM_NX_ENCAP_ETH_DST[],goto_table:87
2714 cookie=0xba5eba1100000201, duration=69.029s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=255,nsp=5 actions=load:0x1100->NXM_NX_REG6[],resubmit(,220)
2715 cookie=0xba5eba1100000201, duration=69.029s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=254,nsp=5 actions=set_field:0->tun_id,output:1
2716 cookie=0xba5eba1100000201, duration=68.999s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=254,nsp=8388613 actions=load:0x1100->NXM_NX_REG6[],resubmit(,220)
2717 cookie=0xba5eba1100000203, duration=68.996s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=253,nsp=8388613 actions=pop_nsh,set_field:02:14:84:5e:a8:5d->eth_src,resubmit(,17)
2720 An interesting scenario to show the Logical SFF strength is the migration of a SF from a compute node to another.
2721 The OpenDaylight will learn the new topology by itself, then it will re-render the new flows to the new SFFs affected.
2723 .. figure:: ./images/sfc/single-logical-sff-example-migration.png
2724 :alt: Logical SFF - SF Migration Example
2728 Logical SFF - SF Migration Example
2731 In our example, SF2 is moved from Node4 to Node2 then OpenDaylight removes NSH specific flows from Node4 and puts them in Node2.
2732 Check below flows showing this effect. Now Node3 keeps holding the first SF of NSP 8388613 and the last SF of NSP 5;
2733 but Node2 becomes the new holder of the first SF of NSP 5 and the last SF of NSP 8388613.
2736 **Rendered Flows Node 3 After Migration**
2740 cookie=0x14, duration=64.044s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
2741 cookie=0x14, duration=63.947s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
2742 cookie=0x14, duration=64.044s, table=86, n_packets=0, n_bytes=0, priority=550,nsi=254,nsp=5 actions=load:0x8e0a37cc9094->NXM_NX_ENCAP_ETH_SRC[],load:0x6ee006b4c51e->NXM_NX_ENCAP_ETH_DST[],goto_table:87
2743 cookie=0x14, duration=63.947s, table=86, n_packets=0, n_bytes=0, priority=550,nsi=255,nsp=8388613 actions=load:0x8e0a37cc9094->NXM_NX_ENCAP_ETH_SRC[],load:0x6ee006b4c51e->NXM_NX_ENCAP_ETH_DST[],goto_table:87
2744 cookie=0xba5eba1100000201, duration=64.034s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=254,nsp=5 actions=load:0x800->NXM_NX_REG6[],resubmit(,220)
2745 cookie=0xba5eba1100000203, duration=64.034s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=253,nsp=5 actions=pop_nsh,set_field:6e:e0:06:b4:c5:1e->eth_src,resubmit(,17)
2746 cookie=0xba5eba1100000201, duration=63.947s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=255,nsp=8388613 actions=load:0x800->NXM_NX_REG6[],resubmit(,220)
2747 cookie=0xba5eba1100000201, duration=63.942s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=254,nsp=8388613 actions=set_field:0->tun_id,output:2
2749 **Rendered Flows Node 2 After Migration**
2753 cookie=0x14, duration=56.856s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
2754 cookie=0x14, duration=56.755s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
2755 cookie=0x14, duration=56.847s, table=86, n_packets=0, n_bytes=0, priority=550,nsi=255,nsp=5 actions=load:0xbea93873f4fa->NXM_NX_ENCAP_ETH_SRC[],load:0x214845ea85d->NXM_NX_ENCAP_ETH_DST[],goto_table:87
2756 cookie=0x14, duration=56.755s, table=86, n_packets=0, n_bytes=0, priority=550,nsi=254,nsp=8388613 actions=load:0xbea93873f4fa->NXM_NX_ENCAP_ETH_SRC[],load:0x214845ea85d->NXM_NX_ENCAP_ETH_DST[],goto_table:87
2757 cookie=0xba5eba1100000201, duration=56.823s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=255,nsp=5 actions=load:0x1100->NXM_NX_REG6[],resubmit(,220)
2758 cookie=0xba5eba1100000201, duration=56.823s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=254,nsp=5 actions=set_field:0->tun_id,output:4
2759 cookie=0xba5eba1100000201, duration=56.755s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=254,nsp=8388613 actions=load:0x1100->NXM_NX_REG6[],resubmit(,220)
2760 cookie=0xba5eba1100000203, duration=56.750s, table=87, n_packets=0, n_bytes=0, priority=650,nsi=253,nsp=8388613 actions=pop_nsh,set_field:02:14:84:5e:a8:5d->eth_src,resubmit(,17)
2762 **Rendered Flows Node 4 After Migration**
2766 -- No flows for NSH processing --
2768 .. _sfc-user-guide-classifier-impacts:
2773 As previously mentioned, in the :ref:`Logical SFF rationale
2774 <sfc-user-guide-logical-sff-motivation>`, the Logical SFF feature relies on
2775 Genius to get the dataplane IDs of the OpenFlow switches, in order to properly
2776 steer the traffic through the chain.
2778 Since one of the classifier's objectives is to steer the packets *into* the
2779 SFC domain, the classifier has to be aware of where the first Service
2780 Function is located - if it migrates somewhere else, the classifier table
2781 has to be updated accordingly, thus enabling the seemless migration of Service
2784 For this feature, mobility of the client VM is out of scope, and should be
2785 managed by its high-availability module, or VNF manager.
2787 Keep in mind that classification *always* occur in the compute-node where
2788 the client VM (i.e. traffic origin) is running.
2790 How to attach the classifier to a Logical SFF
2791 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2793 In order to leverage this functionality, the classifier has to be configured
2794 using a Logical SFF as an attachment-point, specifying within it the neutron
2797 The following examples show how to configure an ACL, and a classifier having
2798 a Logical SFF as an attachment-point:
2800 **Configure an ACL**
2802 The following ACL enables traffic intended for port 80 within the subnetwork
2803 192.168.2.0/24, for RSP1 and RSP1-Reverse.
2812 "acl-type": "ietf-access-control-list:ipv4-acl",
2813 "access-list-entries": {
2816 "rule-name": "ACE1",
2818 "service-function-acl:rendered-service-path": "RSP1"
2821 "destination-ipv4-network": "192.168.2.0/24",
2822 "source-ipv4-network": "192.168.2.0/24",
2824 "source-port-range": {
2827 "destination-port-range": {
2837 "acl-type": "ietf-access-control-list:ipv4-acl",
2838 "access-list-entries": {
2841 "rule-name": "ACE2",
2843 "service-function-acl:rendered-service-path": "RSP1-Reverse"
2846 "destination-ipv4-network": "192.168.2.0/24",
2847 "source-ipv4-network": "192.168.2.0/24",
2849 "source-port-range": {
2852 "destination-port-range": {
2866 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/ietf-access-control-list:access-lists/
2868 **Configure a classifier JSON**
2870 The following JSON provisions a classifier, having a Logical SFF as an
2871 attachment point. The value of the field 'interface' is where you
2872 indicate the neutron ports of the VMs you want to classify.
2877 "service-function-classifiers": {
2878 "service-function-classifier": [
2880 "name": "Classifier1",
2881 "scl-service-function-forwarder": [
2883 "name": "sfflogical1",
2884 "interface": "09a78ba3-78ba-40f5-a3ea-1ce708367f2b"
2889 "type": "ietf-access-control-list:ipv4-acl"
2898 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-classifier:service-function-classifiers/
2900 .. _sfc-user-guide-pipeline-impacts:
2902 SFC pipeline impacts
2903 ~~~~~~~~~~~~~~~~~~~~
2905 After binding SFC service with a particular interface by means of Genius, as explained in the :ref:`Genius User Guide <genius-user-guide-binding-services>`,
2906 the entry point in the SFC pipeline will be table 82 (SFC_TRANSPORT_CLASSIFIER_TABLE), and from that point, packet
2907 processing will be similar to the :ref:`SFC OpenFlow pipeline <sfc-user-guide-sfc-of-pipeline>`, just with another set
2908 of specific tables for the SFC service.
2910 This picture shows the SFC pipeline after service integration with Genius:
2912 .. figure:: ./images/sfc/LSFF_pipeline.png
2913 :alt: SFC Logical SFF OpenFlow pipeline
2915 SFC Logical SFF OpenFlow pipeline