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 Plugin
65 --------------------------
70 The Southbound REST Plugin 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 Forwader (SFF)
87 - Rendered Service Path (RSP)
89 Southbound REST Plugin Architecture
90 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
92 From the user perspective, the REST plugin is another SFC Southbound
93 plugin used to communicate with network devices.
95 .. figure:: ./images/sfc/sb-rest-architecture-user.png
96 :alt: Soutbound REST Plugin integration into ODL
98 Soutbound REST Plugin 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 Plugin 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 plugin
130 will create a new OVS bridge and when a new OVS Bridge is created, the
131 SFC-OVS plugin 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 workflow 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 mannually 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 ip6tabeles 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 Classfier runs alongside sfc\_agent, therefore the commad 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 OpenFlow Switch Flow pipeline
413 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
415 The SFC OpenFlow Renderer uses the following tables for its Flow
418 - Table 0, Classifier
420 - Table 1, Transport Ingress
422 - Table 2, Path Mapper
424 - Table 3, Path Mapper ACL
428 - Table 10, Transport Egress
430 The OpenFlow Table Pipeline is intended to be generic to work for all of
431 the different encapsulations supported by SFC.
433 All of the tables are explained in detail in the following section.
435 The SFFs (SFF1 and SFF2), SFs (SF1), and topology used for the flow
436 tables in the following sections are as described in the following
439 .. figure:: ./images/sfc/sfcofrenderer_nwtopo.png
440 :alt: SFC OpenFlow Renderer Typical Network Topology
442 SFC OpenFlow Renderer Typical Network Topology
444 Classifier Table detailed
445 ^^^^^^^^^^^^^^^^^^^^^^^^^
447 It is possible for the SFF to also act as a classifier. This table maps
448 subscriber traffic to RSPs, and is explained in detail in the classifier
451 If the SFF is not a classifier, then this table will just have a simple
454 Transport Ingress Table detailed
455 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
457 The Transport Ingress table has an entry per expected tunnel transport
458 type to be received in a particular SFF, as established in the SFC
461 Here are two example on SFF1: one where the RSP ingress tunnel is MPLS
462 assuming VLAN is used for the SFF-SF, and the other where the RSP
463 ingress tunnel is NSH GRE (UDP port 4789):
465 +----------+-------------------------------------+--------------+
466 | Priority | Match | Action |
467 +==========+=====================================+==============+
468 | 256 | EtherType==0x8847 (MPLS unicast) | Goto Table 2 |
469 +----------+-------------------------------------+--------------+
470 | 256 | EtherType==0x8100 (VLAN) | Goto Table 2 |
471 +----------+-------------------------------------+--------------+
472 | 256 | EtherType==0x0800,udp,tp\_dst==4789 | Goto Table 2 |
474 +----------+-------------------------------------+--------------+
475 | 5 | Match Any | Drop |
476 +----------+-------------------------------------+--------------+
478 Table: Table Transport Ingress
480 Path Mapper Table detailed
481 ^^^^^^^^^^^^^^^^^^^^^^^^^^
483 The Path Mapper table has an entry per expected tunnel transport info to
484 be received in a particular SFF, as established in the SFC
485 configuration. The tunnel transport info is used to determine the RSP
486 Path ID, and is stored in the OpenFlow Metadata. This table is not used
487 for NSH, since the RSP Path ID is stored in the NSH header.
489 For SF nodes that do not support NSH tunneling, the IP header DSCP field
490 is used to store the RSP Path Id. The RSP Path Id is written to the DSCP
491 field in the Transport Egress table for those packets sent to an SF.
493 Here is an example on SFF1, assuming the following details:
495 - VLAN ID 1000 is used for the SFF-SF
497 - The RSP Path 1 tunnel uses MPLS label 100 for ingress and 101 for
500 - The RSP Path 2 (symmetric downlink path) uses MPLS label 101 for
501 ingress and 100 for egress
503 +----------+-------------------+-----------------------+
504 | Priority | Match | Action |
505 +==========+===================+=======================+
506 | 256 | MPLS Label==100 | RSP Path=1, Pop MPLS, |
508 +----------+-------------------+-----------------------+
509 | 256 | MPLS Label==101 | RSP Path=2, Pop MPLS, |
511 +----------+-------------------+-----------------------+
512 | 256 | VLAN ID==1000, IP | RSP Path=1, Pop VLAN, |
513 | | DSCP==1 | Goto Table 4 |
514 +----------+-------------------+-----------------------+
515 | 256 | VLAN ID==1000, IP | RSP Path=2, Pop VLAN, |
516 | | DSCP==2 | Goto Table 4 |
517 +----------+-------------------+-----------------------+
518 | 5 | Match Any | Goto Table 3 |
519 +----------+-------------------+-----------------------+
521 Table: Table Path Mapper
523 Path Mapper ACL Table detailed
524 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
526 This table is only populated when PacketIn packets are received from the
527 switch for TcpProxy type SFs. These flows are created with an inactivity
528 timer of 60 seconds and will be automatically deleted upon expiration.
530 Next Hop Table detailed
531 ^^^^^^^^^^^^^^^^^^^^^^^
533 The Next Hop table uses the RSP Path Id and appropriate packet fields to
534 determine where to send the packet next. For NSH, only the NSP (Network
535 Services Path, RSP ID) and NSI (Network Services Index, next hop) fields
536 from the NSH header are needed to determine the VXLAN tunnel destination
537 IP. For VLAN or MPLS, then the source MAC address is used to determine
538 the destination MAC address.
540 Here are two examples on SFF1, assuming SFF1 is connected to SFF2. RSP
541 Paths 1 and 2 are symmetric VLAN paths. RSP Paths 3 and 4 are symmetric
542 NSH paths. RSP Path 1 ingress packets come from external to SFC, for
543 which we don’t have the source MAC address (MacSrc).
545 +----------+--------------------------------+--------------------------------+
546 | Priority | Match | Action |
547 +==========+================================+================================+
548 | 256 | RSP Path==1, MacSrc==SF1 | MacDst=SFF2, Goto Table 10 |
549 +----------+--------------------------------+--------------------------------+
550 | 256 | RSP Path==2, MacSrc==SF1 | Goto Table 10 |
551 +----------+--------------------------------+--------------------------------+
552 | 256 | RSP Path==2, MacSrc==SFF2 | MacDst=SF1, Goto Table 10 |
553 +----------+--------------------------------+--------------------------------+
554 | 246 | RSP Path==1 | MacDst=SF1, Goto Table 10 |
555 +----------+--------------------------------+--------------------------------+
556 | 256 | nsp=3,nsi=255 (SFF Ingress RSP | load:0xa000002→NXM\_NX\_TUN\_I |
557 | | 3) | PV4\_DST[], |
558 | | | Goto Table 10 |
559 +----------+--------------------------------+--------------------------------+
560 | 256 | nsp=3,nsi=254 (SFF Ingress | load:0xa00000a→NXM\_NX\_TUN\_I |
561 | | from SF, RSP 3) | PV4\_DST[], |
562 | | | Goto Table 10 |
563 +----------+--------------------------------+--------------------------------+
564 | 256 | nsp=4,nsi=254 (SFF1 Ingress | load:0xa00000a→NXM\_NX\_TUN\_I |
565 | | from SFF2) | PV4\_DST[], |
566 | | | Goto Table 10 |
567 +----------+--------------------------------+--------------------------------+
568 | 5 | Match Any | Drop |
569 +----------+--------------------------------+--------------------------------+
571 Table: Table Next Hop
573 Transport Egress Table detailed
574 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
576 The Transport Egress table prepares egress tunnel information and sends
579 Here are two examples on SFF1. RSP Paths 1 and 2 are symmetric MPLS
580 paths that use VLAN for the SFF-SF. RSP Paths 3 and 4 are symmetric NSH
581 paths. Since it is assumed that switches used for NSH will only have one
582 VXLANport, the NSH packets are just sent back where they came from.
584 +----------+--------------------------------+--------------------------------+
585 | Priority | Match | Action |
586 +==========+================================+================================+
587 | 256 | RSP Path==1, MacDst==SF1 | Push VLAN ID 1000, Port=SF1 |
588 +----------+--------------------------------+--------------------------------+
589 | 256 | RSP Path==1, MacDst==SFF2 | Push MPLS Label 101, Port=SFF2 |
590 +----------+--------------------------------+--------------------------------+
591 | 256 | RSP Path==2, MacDst==SF1 | Push VLAN ID 1000, Port=SF1 |
592 +----------+--------------------------------+--------------------------------+
593 | 246 | RSP Path==2 | Push MPLS Label 100, |
595 +----------+--------------------------------+--------------------------------+
596 | 256 | nsp=3,nsi=255 (SFF Ingress RSP | IN\_PORT |
598 +----------+--------------------------------+--------------------------------+
599 | 256 | nsp=3,nsi=254 (SFF Ingress | IN\_PORT |
600 | | from SF, RSP 3) | |
601 +----------+--------------------------------+--------------------------------+
602 | 256 | nsp=4,nsi=254 (SFF1 Ingress | IN\_PORT |
604 +----------+--------------------------------+--------------------------------+
605 | 5 | Match Any | Drop |
606 +----------+--------------------------------+--------------------------------+
608 Table: Table Transport Egress
610 Administering SFC OF Renderer
611 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
613 To use the SFC OpenFlow Renderer Karaf, at least the following Karaf
614 features must be installed.
616 - odl-openflowplugin-nxm-extensions
618 - odl-openflowplugin-flow-services
624 - odl-sfc-openflow-renderer
626 - odl-sfc-ui (optional)
628 The following command can be used to view all of the currently installed
633 opendaylight-user@root>feature:list -i
635 Or, pipe the command to a grep to see a subset of the currently
636 installed Karaf features:
640 opendaylight-user@root>feature:list -i | grep sfc
642 To install a particular feature, use the Karaf ``feature:install``
645 SFC OF Renderer Tutorial
646 ~~~~~~~~~~~~~~~~~~~~~~~~
651 In this tutorial, 2 different encapsulations will be shown: MPLS and
652 NSH. The following Network Topology diagram is a logical view of the
653 SFFs and SFs involved in creating the Service Chains.
655 .. figure:: ./images/sfc/sfcofrenderer_nwtopo.png
656 :alt: SFC OpenFlow Renderer Typical Network Topology
658 SFC OpenFlow Renderer Typical Network Topology
663 To use this example, SFF OpenFlow switches must be created and connected
664 as illustrated above. Additionally, the SFs must be created and
670 The target environment is not important, but this use-case was created
676 The steps to use this tutorial are as follows. The referenced
677 configuration in the steps is listed in the following sections.
679 There are numerous ways to send the configuration. In the following
680 configuration chapters, the appropriate ``curl`` command is shown for
681 each configuration to be sent, including the URL.
683 Steps to configure the SFC OF Renderer tutorial:
685 1. Send the ``SF`` RESTCONF configuration
687 2. Send the ``SFF`` RESTCONF configuration
689 3. Send the ``SFC`` RESTCONF configuration
691 4. Send the ``SFP`` RESTCONF configuration
693 5. Create the ``RSP`` with a RESTCONF RPC command
695 Once the configuration has been successfully created, query the Rendered
696 Service Paths with either the SFC UI or via RESTCONF. Notice that the
697 RSP is symmetrical, so the following 2 RSPs will be created:
703 At this point the Service Chains have been created, and the OpenFlow
704 Switches are programmed to steer traffic through the Service Chain.
705 Traffic can now be injected from a client into the Service Chain. To
706 debug problems, the OpenFlow tables can be dumped with the following
707 commands, assuming SFF1 is called ``s1`` and SFF2 is called ``s2``.
711 sudo ovs-ofctl -O OpenFlow13 dump-flows s1
715 sudo ovs-ofctl -O OpenFlow13 dump-flows s2
717 In all the following configuration sections, replace the ``${JSON}``
718 string with the appropriate JSON configuration. Also, change the
719 ``localhost`` desintation in the URL accordingly.
721 SFC OF Renderer NSH Tutorial
722 ''''''''''''''''''''''''''''
724 The following configuration sections show how to create the different
725 elements using NSH encapsulation.
727 | **NSH Service Function configuration**
729 The Service Function configuration can be sent with the following
734 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/
736 **SF configuration JSON.**
741 "service-functions": {
742 "service-function": [
745 "type": "http-header-enrichment",
747 "ip-mgmt-address": "10.0.0.2",
748 "sf-data-plane-locator": [
753 "transport": "service-locator:vxlan-gpe",
754 "service-function-forwarder": "sff1"
762 "ip-mgmt-address": "10.0.0.3",
763 "sf-data-plane-locator": [
768 "transport": "service-locator:vxlan-gpe",
769 "service-function-forwarder": "sff2"
777 | **NSH Service Function Forwarder configuration**
779 The Service Function Forwarder configuration can be sent with the
784 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/
786 **SFF configuration JSON.**
791 "service-function-forwarders": {
792 "service-function-forwarder": [
795 "service-node": "openflow:2",
796 "sff-data-plane-locator": [
799 "data-plane-locator":
803 "transport": "service-locator:vxlan-gpe"
807 "service-function-dictionary": [
810 "sff-sf-data-plane-locator":
812 "sf-dpl-name": "sf1dpl",
813 "sff-dpl-name": "sff1dpl"
820 "service-node": "openflow:3",
821 "sff-data-plane-locator": [
824 "data-plane-locator":
828 "transport": "service-locator:vxlan-gpe"
832 "service-function-dictionary": [
835 "sff-sf-data-plane-locator":
837 "sf-dpl-name": "sf2dpl",
838 "sff-dpl-name": "sff2dpl"
847 | **NSH Service Function Chain configuration**
849 The Service Function Chain configuration can be sent with the following
854 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/
856 **SFC configuration JSON.**
861 "service-function-chains": {
862 "service-function-chain": [
864 "name": "sfc-chain1",
866 "sfc-service-function": [
868 "name": "hdr-enrich-abstract1",
869 "type": "http-header-enrichment"
872 "name": "firewall-abstract1",
881 | **NSH Service Function Path configuration**
883 The Service Function Path configuration can be sent with the following
888 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/
890 **SFP configuration JSON.**
895 "service-function-paths": {
896 "service-function-path": [
899 "service-chain-name": "sfc-chain1",
900 "transport-type": "service-locator:vxlan-gpe",
907 | **NSH Rendered Service Path creation**
911 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/
913 **RSP creation JSON.**
920 "parent-service-function-path": "sfc-path1",
925 | **NSH Rendered Service Path removal**
927 The following command can be used to remove a Rendered Service Path
928 called ``sfc-path1``:
932 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/
934 | **NSH Rendered Service Path Query**
936 The following command can be used to query all of the created Rendered
941 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/
943 SFC OF Renderer MPLS Tutorial
944 '''''''''''''''''''''''''''''
946 The following configuration sections show how to create the different
947 elements using MPLS encapsulation.
949 | **MPLS Service Function configuration**
951 The Service Function configuration can be sent with the following
956 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/
958 **SF configuration JSON.**
963 "service-functions": {
964 "service-function": [
967 "type": "http-header-enrichment",
969 "ip-mgmt-address": "10.0.0.2",
970 "sf-data-plane-locator": [
973 "mac": "00:00:08:01:02:01",
975 "transport": "service-locator:mac",
976 "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",
1154 "sfc-service-function": [
1156 "name": "hdr-enrich-abstract1",
1157 "type": "http-header-enrichment"
1160 "name": "firewall-abstract1",
1169 | **MPLS Service Function Path configuration**
1171 The Service Function Path configuration can be sent with the following
1176 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/
1178 **SFP configuration JSON.**
1183 "service-function-paths": {
1184 "service-function-path": [
1186 "name": "sfc-path1",
1187 "service-chain-name": "sfc-chain1",
1188 "transport-type": "service-locator:mpls",
1195 | **MPLS Rendered Service Path creation**
1199 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/
1201 **RSP creation JSON.**
1207 "name": "sfc-path1",
1208 "parent-service-function-path": "sfc-path1",
1213 | **MPLS Rendered Service Path removal**
1215 The following command can be used to remove a Rendered Service Path
1216 called ``sfc-path1``:
1220 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/
1222 | **MPLS Rendered Service Path Query**
1224 The following command can be used to query all of the created Rendered
1229 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/
1231 SFC IOS XE Renderer User Guide
1232 ------------------------------
1237 The early Service Function Chaining (SFC) renderer for IOS-XE devices
1238 (SFC IOS-XE renderer) implements Service Chaining functionality on
1239 IOS-XE capable switches. It listens for the creation of a Rendered
1240 Service Path (RSP) and sets up Service Function Forwarders (SFF) that
1241 are hosted on IOS-XE switches to steer traffic through the service
1244 Common acronyms used in the following sections:
1246 - SF - Service Function
1248 - SFF - Service Function Forwarder
1250 - SFC - Service Function Chain
1254 - SFP - Service Function Path
1256 - RSP - Rendered Service Path
1258 - LSF - Local Service Forwarder
1260 - RSF - Remote Service Forwarder
1262 SFC IOS-XE Renderer Architecture
1263 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1265 When the SFC IOS-XE renderer is initialized, all required listeners are
1266 registered to handle incoming data. It involves CSR/IOS-XE
1267 ``NodeListener`` which stores data about all configurable devices
1268 including their mountpoints (used here as databrokers),
1269 ``ServiceFunctionListener``, ``ServiceForwarderListener`` (see mapping)
1270 and ``RenderedPathListener`` used to listen for RSP changes. When the
1271 SFC IOS-XE renderer is invoked, ``RenderedPathListener`` calls the
1272 ``IosXeRspProcessor`` which processes the RSP change and creates all
1273 necessary Service Paths and Remote Service Forwarders (if necessary) on
1276 Service Path details
1277 ~~~~~~~~~~~~~~~~~~~~
1279 Each Service Path is defined by index (represented by NSP) and contains
1280 service path entries. Each entry has appropriate service index (NSI) and
1281 definition of next hop. Next hop can be Service Function, different
1282 Service Function Forwarder or definition of end of chain - terminate.
1283 After terminating, the packet is sent to destination. If a SFF is
1284 defined as a next hop, it has to be present on device in the form of
1285 Remote Service Forwarder. RSFs are also created during RSP processing.
1287 Example of Service Path:
1291 service-chain service-path 200
1292 service-index 255 service-function firewall-1
1293 service-index 254 service-function dpi-1
1294 service-index 253 terminate
1296 Mapping to IOS-XE SFC entities
1297 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1299 Renderer contains mappers for SFs and SFFs. IOS-XE capable device is
1300 using its own definition of Service Functions and Service Function
1301 Forwarders according to appropriate .yang file.
1302 ``ServiceFunctionListener`` serves as a listener for SF changes. If SF
1303 appears in datastore, listener extracts its management ip address and
1304 looks into cached IOS-XE nodes. If some of available nodes match,
1305 Service function is mapped in ``IosXeServiceFunctionMapper`` to be
1306 understandable by IOS-XE device and it’s written into device’s config.
1307 ``ServiceForwarderListener`` is used in a similar way. All SFFs with
1308 suitable management ip address it mapped in
1309 ``IosXeServiceForwarderMapper``. Remapped SFFs are configured as a Local
1310 Service Forwarders. It is not possible to directly create Remote Service
1311 Forwarder using IOS-XE renderer. RSF is created only during RSP
1314 Administering SFC IOS-XE renderer
1315 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1317 To use the SFC IOS-XE Renderer Karaf, at least the following Karaf
1318 features must be installed:
1328 - odl-netconf-topology
1330 - odl-sfc-ios-xe-renderer
1332 SFC IOS-XE renderer Tutorial
1333 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1338 This tutorial is a simple example how to create Service Path on IOS-XE
1339 capable device using IOS-XE renderer
1344 To connect to IOS-XE device, it is necessary to use several modified
1345 yang models and override device’s ones. All .yang files are in the
1346 ``Yang/netconf`` folder in the ``sfc-ios-xe-renderer module`` in the SFC
1347 project. These files have to be copied to the ``cache/schema``
1348 directory, before Karaf is started. After that, custom capabilities have
1349 to be sent to network-topology:
1353 PUT ./config/network-topology:network-topology/topology/topology-netconf/node/<device-name>
1355 <node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
1356 <node-id>device-name</node-id>
1357 <host xmlns="urn:opendaylight:netconf-node-topology">device-ip</host>
1358 <port xmlns="urn:opendaylight:netconf-node-topology">2022</port>
1359 <username xmlns="urn:opendaylight:netconf-node-topology">login</username>
1360 <password xmlns="urn:opendaylight:netconf-node-topology">password</password>
1361 <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
1362 <keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">0</keepalive-delay>
1363 <yang-module-capabilities xmlns="urn:opendaylight:netconf-node-topology">
1364 <override>true</override>
1365 <capability xmlns="urn:opendaylight:netconf-node-topology">
1366 urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2013-07-15
1368 <capability xmlns="urn:opendaylight:netconf-node-topology">
1369 urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&revision=2013-07-15
1371 <capability xmlns="urn:opendaylight:netconf-node-topology">
1372 urn:ios?module=ned&revision=2016-03-08
1374 <capability xmlns="urn:opendaylight:netconf-node-topology">
1375 http://tail-f.com/yang/common?module=tailf-common&revision=2015-05-22
1377 <capability xmlns="urn:opendaylight:netconf-node-topology">
1378 http://tail-f.com/yang/common?module=tailf-meta-extensions&revision=2013-11-07
1380 <capability xmlns="urn:opendaylight:netconf-node-topology">
1381 http://tail-f.com/yang/common?module=tailf-cli-extensions&revision=2015-03-19
1383 </yang-module-capabilities>
1388 The device name in the URL and in the XML must match.
1393 When the IOS-XE renderer is installed, all NETCONF nodes in
1394 topology-netconf are processed and all capable nodes with accessible
1395 mountpoints are cached. The first step is to create LSF on node.
1397 ``Service Function Forwarder configuration``
1401 PUT ./config/service-function-forwarder:service-function-forwarders
1404 "service-function-forwarders": {
1405 "service-function-forwarder": [
1408 "ip-mgmt-address": "172.25.73.23",
1409 "sff-data-plane-locator": [
1411 "name": "CSR1Kv-2-dpl",
1412 "data-plane-locator": {
1413 "transport": "service-locator:vxlan-gpe",
1415 "ip": "10.99.150.10"
1424 If the IOS-XE node with appropriate management IP exists, this
1425 configuration is mapped and LSF is created on the device. The same
1426 approach is used for Service Functions.
1430 PUT ./config/service-function:service-functions
1433 "service-functions": {
1434 "service-function": [
1437 "ip-mgmt-address": "172.25.73.23",
1438 "type": "service-function-type: firewall",
1440 "sf-data-plane-locator": [
1442 "name": "firewall-dpl",
1445 "transport": "service-locator:gre",
1446 "service-function-forwarder": "CSR1Kv-2"
1452 "ip-mgmt-address": "172.25.73.23",
1453 "type":"service-function-type: dpi",
1455 "sf-data-plane-locator": [
1460 "transport": "service-locator:gre",
1461 "service-function-forwarder": "CSR1Kv-2"
1467 "ip-mgmt-address": "172.25.73.23",
1468 "type":"service-function-type: qos",
1470 "sf-data-plane-locator": [
1475 "transport": "service-locator:gre",
1476 "service-function-forwarder": "CSR1Kv-2"
1484 All these SFs are configured on the same device as the LSF. The next
1485 step is to prepare Service Function Chain. SFC is symmetric.
1489 PUT ./config/service-function-chain:service-function-chains/
1492 "service-function-chains": {
1493 "service-function-chain": [
1496 "symmetric": "true",
1497 "sfc-service-function": [
1500 "type": "service-function-type: firewall"
1504 "type": "service-function-type: dpi"
1508 "type": "service-function-type: qos"
1516 Service Function Path:
1520 PUT ./config/service-function-path:service-function-paths/
1523 "service-function-paths": {
1524 "service-function-path": [
1526 "name": "CSR3XSF-Path",
1527 "service-chain-name": "CSR3XSF",
1528 "starting-index": 255,
1535 Without a classifier, there is possibility to POST RSP directly.
1539 POST ./operations/rendered-service-path:create-rendered-path
1543 "name": "CSR3XSF-Path-RSP",
1544 "parent-service-function-path": "CSR3XSF-Path",
1549 The resulting configuration:
1554 service-chain service-function-forwarder local
1555 ip address 10.99.150.10
1557 service-chain service-function firewall
1559 encapsulation gre enhanced divert
1561 service-chain service-function dpi
1563 encapsulation gre enhanced divert
1565 service-chain service-function qos
1567 encapsulation gre enhanced divert
1569 service-chain service-path 1
1570 service-index 255 service-function firewall
1571 service-index 254 service-function dpi
1572 service-index 253 service-function qos
1573 service-index 252 terminate
1575 service-chain service-path 2
1576 service-index 255 service-function qos
1577 service-index 254 service-function dpi
1578 service-index 253 service-function firewall
1579 service-index 252 terminate
1582 Service Path 1 is direct, Service Path 2 is reversed. Path numbers may
1585 Service Function Scheduling Algorithms
1586 --------------------------------------
1591 When creating the Rendered Service Path, the origin SFC controller chose
1592 the first available service function from a list of service function
1593 names. This may result in many issues such as overloaded service
1594 functions and a longer service path as SFC has no means to understand
1595 the status of service functions and network topology. The service
1596 function selection framework supports at least four algorithms (Random,
1597 Round Robin, Load Balancing and Shortest Path) to select the most
1598 appropriate service function when instantiating the Rendered Service
1599 Path. In addition, it is an extensible framework that allows 3rd party
1600 selection algorithm to be plugged in.
1605 The following figure illustrates the service function selection
1606 framework and algorithms.
1608 .. figure:: ./images/sfc/sf-selection-arch.png
1609 :alt: SF Selection Architecture
1611 SF Selection Architecture
1613 A user has three different ways to select one service function selection
1616 1. Integrated RESTCONF Calls. OpenStack and/or other administration
1617 system could provide plugins to call the APIs to select one
1618 scheduling algorithm.
1620 2. Command line tools. Command line tools such as curl or browser
1621 plugins such as POSTMAN (for Google Chrome) and RESTClient (for
1622 Mozilla Firefox) could select schedule algorithm by making RESTCONF
1625 3. SFC-UI. Now the SFC-UI provides an option for choosing a selection
1626 algorithm when creating a Rendered Service Path.
1628 The RESTCONF northbound SFC API provides GUI/RESTCONF interactions for
1629 choosing the service function selection algorithm. MD-SAL data store
1630 provides all supported service function selection algorithms, and
1631 provides APIs to enable one of the provided service function selection
1632 algorithms. Once a service function selection algorithm is enabled, the
1633 service function selection algorithm will work when creating a Rendered
1636 Select SFs with Scheduler
1637 ~~~~~~~~~~~~~~~~~~~~~~~~~
1639 Administrator could use both the following ways to select one of the
1640 selection algorithm when creating a Rendered Service Path.
1642 - Command line tools. Command line tools includes Linux commands curl
1643 or even browser plugins such as POSTMAN(for Google Chrome) or
1644 RESTClient(for Mozilla Firefox). In this case, the following JSON
1645 content is needed at the moment:
1646 Service\_function\_schudule\_type.json
1651 "service-function-scheduler-types": {
1652 "service-function-scheduler-type": [
1655 "type": "service-function-scheduler-type:random",
1659 "name": "roundrobin",
1660 "type": "service-function-scheduler-type:round-robin",
1664 "name": "loadbalance",
1665 "type": "service-function-scheduler-type:load-balance",
1669 "name": "shortestpath",
1670 "type": "service-function-scheduler-type:shortest-path",
1677 If using the Linux curl command, it could be:
1681 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '$${Service_function_schudule_type.json}'
1682 -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-scheduler-type:service-function-scheduler-types/
1684 Here is also a snapshot for using the RESTClient plugin:
1686 .. figure:: ./images/sfc/RESTClient-snapshot.png
1687 :alt: Mozilla Firefox RESTClient
1689 Mozilla Firefox RESTClient
1691 - SFC-UI.SFC-UI provides a drop down menu for service function
1692 selection algorithm. Here is a snapshot for the user interaction from
1693 SFC-UI when creating a Rendered Service Path.
1695 .. figure:: ./images/sfc/karaf-webui-select-a-type.png
1702 Some service function selection algorithms in the drop list are not
1703 implemented yet. Only the first three algorithms are committed at
1709 Select Service Function from the name list randomly.
1714 The Random algorithm is used to select one Service Function from the
1715 name list which it gets from the Service Function Type randomly.
1720 - Service Function information are stored in datastore.
1722 - Either no algorithm or the Random algorithm is selected.
1727 The Random algorithm will work either no algorithm type is selected or
1728 the Random algorithm is selected.
1733 Once the plugins are installed into Karaf successfully, a user can use
1734 his favorite method to select the Random scheduling algorithm type.
1735 There are no special instructions for using the Random algorithm.
1740 Select Service Function from the name list in Round Robin manner.
1745 The Round Robin algorithm is used to select one Service Function from
1746 the name list which it gets from the Service Function Type in a Round
1747 Robin manner, this will balance workloads to all Service Functions.
1748 However, this method cannot help all Service Functions load the same
1749 workload because it’s flow-based Round Robin.
1754 - Service Function information are stored in datastore.
1756 - Round Robin algorithm is selected
1761 The Round Robin algorithm will work one the Round Robin algorithm is
1767 Once the plugins are installed into Karaf successfully, a user can use
1768 his favorite method to select the Round Robin scheduling algorithm type.
1769 There are no special instructions for using the Round Robin algorithm.
1771 Load Balance Algorithm
1772 ^^^^^^^^^^^^^^^^^^^^^^
1774 Select appropriate Service Function by actual CPU utilization.
1779 The Load Balance Algorithm is used to select appropriate Service
1780 Function by actual CPU utilization of service functions. The CPU
1781 utilization of service function obtained from monitoring information
1782 reported via NETCONF.
1787 - CPU-utilization for Service Function.
1793 - Each VM has a NETCONF server and it could work with NETCONF client
1799 Set up VMs as Service Functions. enable NETCONF server in VMs. Ensure
1800 that you specify them separately. For example:
1802 a. Set up 4 VMs include 2 SFs' type are Firewall, Others are Napt44.
1803 Name them as firewall-1, firewall-2, napt44-1, napt44-2 as Service
1804 Function. The four VMs can run either the same server or different
1807 b. Install NETCONF server on every VM and enable it. More information on
1808 NETCONF can be found on the OpenDaylight wiki here:
1809 https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf:Manual_netopeer_installation
1811 c. Get Monitoring data from NETCONF server. These monitoring data should
1812 be get from the NETCONF server which is running in VMs. The following
1813 static XML data is an example:
1815 static XML data like this:
1819 <?xml version="1.0" encoding="UTF-8"?>
1820 <service-function-description-monitor-report>
1822 <number-of-dataports>2</number-of-dataports>
1824 <supported-packet-rate>5</supported-packet-rate>
1825 <supported-bandwidth>10</supported-bandwidth>
1826 <supported-ACL-number>2000</supported-ACL-number>
1827 <RIB-size>200</RIB-size>
1828 <FIB-size>100</FIB-size>
1831 <port-id>1</port-id>
1832 <ipaddress>10.0.0.1</ipaddress>
1833 <macaddress>00:1e:67:a2:5f:f4</macaddress>
1834 <supported-bandwidth>20</supported-bandwidth>
1837 <port-id>2</port-id>
1838 <ipaddress>10.0.0.2</ipaddress>
1839 <macaddress>01:1e:67:a2:5f:f6</macaddress>
1840 <supported-bandwidth>10</supported-bandwidth>
1845 <SF-monitoring-info>
1846 <liveness>true</liveness>
1847 <resource-utilization>
1848 <packet-rate-utilization>10</packet-rate-utilization>
1849 <bandwidth-utilization>15</bandwidth-utilization>
1850 <CPU-utilization>12</CPU-utilization>
1851 <memory-utilization>17</memory-utilization>
1852 <available-memory>8</available-memory>
1853 <RIB-utilization>20</RIB-utilization>
1854 <FIB-utilization>25</FIB-utilization>
1855 <power-utilization>30</power-utilization>
1856 <SF-ports-bandwidth-utilization>
1857 <port-bandwidth-utilization>
1858 <port-id>1</port-id>
1859 <bandwidth-utilization>20</bandwidth-utilization>
1860 </port-bandwidth-utilization>
1861 <port-bandwidth-utilization>
1862 <port-id>2</port-id>
1863 <bandwidth-utilization>30</bandwidth-utilization>
1864 </port-bandwidth-utilization>
1865 </SF-ports-bandwidth-utilization>
1866 </resource-utilization>
1867 </SF-monitoring-info>
1868 </service-function-description-monitor-report>
1870 a. Unzip SFC release tarball.
1872 b. Run SFC: ${sfc}/bin/karaf. More information on Service Function
1873 Chaining can be found on the OpenDaylight SFC’s wiki page:
1874 https://wiki.opendaylight.org/view/Service_Function_Chaining:Main
1876 a. Deploy the SFC2 (firewall-abstract2⇒napt44-abstract2) and click
1877 button to Create Rendered Service Path in SFC UI
1878 (http://localhost:8181/sfc/index.html).
1880 b. Verify the Rendered Service Path to ensure the CPU utilization of the
1881 selected hop is the minimum one among all the service functions with
1882 same type. The correct RSP is firewall-1⇒napt44-2
1884 Shortest Path Algorithm
1885 ^^^^^^^^^^^^^^^^^^^^^^^
1887 Select appropriate Service Function by Dijkstra’s algorithm. Dijkstra’s
1888 algorithm is an algorithm for finding the shortest paths between nodes
1894 The Shortest Path Algorithm is used to select appropriate Service
1895 Function by actual topology.
1900 - Depolyed topology (include SFFs, SFs and their links).
1902 - Dijkstra’s algorithm. More information on Dijkstra’s algorithm can be
1903 found on the wiki here:
1904 http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm
1909 a. Unzip SFC release tarball.
1911 b. Run SFC: ${sfc}/bin/karaf.
1913 c. Depoly SFFs and SFs. import the service-function-forwarders.json and
1914 service-functions.json in UI
1915 (http://localhost:8181/sfc/index.html#/sfc/config)
1917 service-function-forwarders.json:
1922 "service-function-forwarders": {
1923 "service-function-forwarder": [
1926 "service-node": "OVSDB-test01",
1927 "rest-uri": "http://localhost:5001",
1928 "sff-data-plane-locator": [
1931 "service-function-forwarder-ovs:ovs-bridge": {
1932 "uuid": "4c3778e4-840d-47f4-b45e-0988e514d26c",
1933 "bridge-name": "br-tun"
1935 "data-plane-locator": {
1937 "ip": "192.168.1.1",
1938 "transport": "service-locator:vxlan-gpe"
1942 "service-function-dictionary": [
1944 "sff-sf-data-plane-locator": {
1949 "type": "service-function-type:napt44"
1952 "sff-sf-data-plane-locator": {
1956 "name": "firewall-1",
1957 "type": "service-function-type:firewall"
1960 "connected-sff-dictionary": [
1968 "service-node": "OVSDB-test01",
1969 "rest-uri": "http://localhost:5002",
1970 "sff-data-plane-locator": [
1973 "service-function-forwarder-ovs:ovs-bridge": {
1974 "uuid": "fd4d849f-5140-48cd-bc60-6ad1f5fc0a1",
1975 "bridge-name": "br-tun"
1977 "data-plane-locator": {
1979 "ip": "192.168.1.2",
1980 "transport": "service-locator:vxlan-gpe"
1984 "service-function-dictionary": [
1986 "sff-sf-data-plane-locator": {
1991 "type": "service-function-type:napt44"
1994 "sff-sf-data-plane-locator": {
1998 "name": "firewall-2",
1999 "type": "service-function-type:firewall"
2002 "connected-sff-dictionary": [
2010 "service-node": "OVSDB-test01",
2011 "rest-uri": "http://localhost:5005",
2012 "sff-data-plane-locator": [
2015 "service-function-forwarder-ovs:ovs-bridge": {
2016 "uuid": "fd4d849f-5140-48cd-bc60-6ad1f5fc0a4",
2017 "bridge-name": "br-tun"
2019 "data-plane-locator": {
2021 "ip": "192.168.1.2",
2022 "transport": "service-locator:vxlan-gpe"
2026 "service-function-dictionary": [
2028 "sff-sf-data-plane-locator": {
2032 "name": "test-server",
2033 "type": "service-function-type:dpi"
2036 "sff-sf-data-plane-locator": {
2040 "name": "test-client",
2041 "type": "service-function-type:dpi"
2044 "connected-sff-dictionary": [
2057 service-functions.json:
2062 "service-functions": {
2063 "service-function": [
2065 "rest-uri": "http://localhost:10001",
2066 "ip-mgmt-address": "10.3.1.103",
2067 "sf-data-plane-locator": [
2069 "name": "preferred",
2072 "service-function-forwarder": "SFF-br1"
2076 "type": "service-function-type:napt44",
2080 "rest-uri": "http://localhost:10002",
2081 "ip-mgmt-address": "10.3.1.103",
2082 "sf-data-plane-locator": [
2087 "service-function-forwarder": "SFF-br2"
2091 "type": "service-function-type:napt44",
2095 "rest-uri": "http://localhost:10003",
2096 "ip-mgmt-address": "10.3.1.103",
2097 "sf-data-plane-locator": [
2102 "service-function-forwarder": "SFF-br1"
2105 "name": "firewall-1",
2106 "type": "service-function-type:firewall",
2110 "rest-uri": "http://localhost:10004",
2111 "ip-mgmt-address": "10.3.1.103",
2112 "sf-data-plane-locator": [
2117 "service-function-forwarder": "SFF-br2"
2120 "name": "firewall-2",
2121 "type": "service-function-type:firewall",
2125 "rest-uri": "http://localhost:10005",
2126 "ip-mgmt-address": "10.3.1.103",
2127 "sf-data-plane-locator": [
2132 "service-function-forwarder": "SFF-br3"
2135 "name": "test-server",
2136 "type": "service-function-type:dpi",
2140 "rest-uri": "http://localhost:10006",
2141 "ip-mgmt-address": "10.3.1.103",
2142 "sf-data-plane-locator": [
2147 "service-function-forwarder": "SFF-br3"
2150 "name": "test-client",
2151 "type": "service-function-type:dpi",
2158 The depolyed topology like this:
2162 +----+ +----+ +----+
2163 |sff1|+----------|sff3|---------+|sff2|
2164 +----+ +----+ +----+
2166 +--------------+ +--------------+
2168 +----------+ +--------+ +----------+ +--------+
2169 |firewall-1| |napt44-1| |firewall-2| |napt44-2|
2170 +----------+ +--------+ +----------+ +--------+
2172 - Deploy the SFC2(firewall-abstract2⇒napt44-abstract2), select
2173 "Shortest Path" as schedule type and click button to Create Rendered
2174 Service Path in SFC UI (http://localhost:8181/sfc/index.html).
2176 .. figure:: ./images/sfc/sf-schedule-type.png
2177 :alt: select schedule type
2179 select schedule type
2181 - Verify the Rendered Service Path to ensure the selected hops are
2182 linked in one SFF. The correct RSP is firewall-1⇒napt44-1 or
2183 firewall-2⇒napt44-2. The first SF type is Firewall in Service
2184 Function Chain. So the algorithm will select first Hop randomly among
2185 all the SFs type is Firewall. Assume the first selected SF is
2186 firewall-2. All the path from firewall-1 to SF which type is Napt44
2189 - Path1: firewall-2 → sff2 → napt44-2
2191 - Path2: firewall-2 → sff2 → sff3 → sff1 → napt44-1 The shortest
2192 path is Path1, so the selected next hop is napt44-2.
2194 .. figure:: ./images/sfc/sf-rendered-service-path.png
2195 :alt: rendered service path
2197 rendered service path
2199 Service Function Load Balancing User Guide
2200 ------------------------------------------
2205 SFC Load-Balancing feature implements load balancing of Service
2206 Functions, rather than a one-to-one mapping between
2207 Service-Function-Forwarder and Service-Function.
2209 Load Balancing Architecture
2210 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
2212 Service Function Groups (SFG) can replace Service Functions (SF) in the
2213 Rendered Path model. A Service Path can only be defined using SFGs or
2214 SFs, but not a combination of both.
2216 Relevant objects in the YANG model are as follows:
2218 1. Service-Function-Group-Algorithm:
2222 Service-Function-Group-Algorithms {
2223 Service-Function-Group-Algorithm {
2231 Available types: ALL, SELECT, INDIRECT, FAST_FAILURE
2233 2. Service-Function-Group:
2237 Service-Function-Groups {
2238 Service-Function-Group {
2240 String serviceFunctionGroupAlgorithmName
2243 Service-Function-Group-Element {
2244 String service-function-name
2250 3. ServiceFunctionHop: holds a reference to a name of SFG (or SF)
2255 This tutorial will explain how to create a simple SFC configuration,
2256 with SFG instead of SF. In this example, the SFG will include two
2262 For general SFC setup and scenarios, please see the SFC wiki page:
2263 https://wiki.opendaylight.org/view/Service_Function_Chaining:Main#SFC_101
2269 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2274 "service-function-group-algorithm": [
2282 (Header "content-type": application/json)
2284 Verify: get all algorithms
2285 ^^^^^^^^^^^^^^^^^^^^^^^^^^
2288 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2290 In order to delete all algorithms: DELETE -
2291 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2297 http://127.0.0.1:8181/restconf/config/service-function-group:service-function-groups
2302 "service-function-group": [
2304 "rest-uri": "http://localhost:10002",
2305 "ip-mgmt-address": "10.3.1.103",
2306 "algorithm": "alg1",
2308 "type": "service-function-type:napt44",
2309 "sfc-service-function": [
2314 "name":"napt44-103-1"
2321 Verify: get all SFG’s
2322 ^^^^^^^^^^^^^^^^^^^^^
2325 http://127.0.0.1:8181/restconf/config/service-function-group:service-function-groups
2327 SFC Proof of Transit User Guide
2328 -------------------------------
2333 Early Service Function Chaining (SFC) Proof of Transit (SFC Proof of
2334 Transit) implements Service Chaining Proof of Transit functionality on
2335 capable switches. After the creation of an Rendered Service Path (RSP),
2336 a user can configure to enable SFC proof of transit on the selected RSP
2337 to effect the proof of transit.
2339 Common acronyms used in the following sections:
2341 - SF - Service Function
2343 - SFF - Service Function Forwarder
2345 - SFC - Service Function Chain
2347 - SFP - Service Function Path
2349 - RSP - Rendered Service Path
2351 - SFCPOT - Service Function Chain Proof of Transit
2353 SFC Proof of Transit Architecture
2354 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2356 When SFC Proof of Transit is initialized, all required listeners are
2357 registered to handle incoming data. It involves ``SfcPotNodeListener``
2358 which stores data about all node devices including their mountpoints
2359 (used here as databrokers), ``SfcPotRSPDataListener``,
2360 ``RenderedPathListener``. ``RenderedPathListener`` is used to listen for
2361 RSP changes. ``SfcPotRSPDataListener`` implements RPC services to enable
2362 or disable SFC Proof of Transit on a particular RSP. When the SFC Proof
2363 of Transit is invoked, RSP listeners and service implementations are
2364 setup to receive SFCPOT configurations. When a user configures via a
2365 POST RPC call to enable SFCPOT on a particular RSP, the configuration
2366 drives the creation of necessary augmentations to the RSP to effect the
2367 SFCPOT configurations.
2369 SFC Proof of Transit details
2370 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2372 Several deployments use traffic engineering, policy routing, segment
2373 routing or service function chaining (SFC) to steer packets through a
2374 specific set of nodes. In certain cases regulatory obligations or a
2375 compliance policy require to prove that all packets that are supposed to
2376 follow a specific path are indeed being forwarded across the exact set
2377 of nodes specified. I.e. if a packet flow is supposed to go through a
2378 series of service functions or network nodes, it has to be proven that
2379 all packets of the flow actually went through the service chain or
2380 collection of nodes specified by the policy. In case the packets of a
2381 flow weren’t appropriately processed, a proof of transit egress device
2382 would be required to identify the policy violation and take
2383 corresponding actions (e.g. drop or redirect the packet, send an alert
2384 etc.) corresponding to the policy.
2386 The SFCPOT approach is based on meta-data which is added to every
2387 packet. The meta data is updated at every hop and is used to verify
2388 whether a packet traversed all required nodes. A particular path is
2389 either described by a set of secret keys, or a set of shares of a single
2390 secret. Nodes on the path retrieve their individual keys or shares of a
2391 key (using for e.g. Shamir’s Shared Sharing Secret scheme) from a
2392 central controller. The complete key set is only known to the verifier-
2393 which is typically the ultimate node on a path that requires proof of
2394 transit. Each node in the path uses its secret or share of the secret to
2395 update the meta-data of the packets as the packets pass through the
2396 node. When the verifier receives a packet, it can use its key(s) along
2397 with the meta-data to validate whether the packet traversed the service
2400 SFC Proof of Transit entities
2401 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2403 In order to implement SFC Proof of Transit for a service function chain,
2404 an RSP is a pre-requisite to identify the SFC to enable SFC PoT on. SFC
2405 Proof of Transit for a particular RSP is enabled by an RPC request to
2406 the controller along with necessary parameters to control some of the
2407 aspects of the SFC Proof of Transit process.
2409 The RPC handler identifies the RSP and generates SFC Proof of Transit
2410 parameters like secret share, secret etc., and adds the generated SFCPOT
2411 configuration parameters to SFC main as well as the various SFC hops.
2412 The last node in the SFC is configured as a verifier node to allow
2413 SFCPOT Proof of Transit process to be completed.
2415 The SFCPOT configuration generators and related handling are done by
2416 ``SfcPotAPI``, ``SfcPotConfigGenerator``, ``SfcPotListener``,
2417 ``SfcPotPolyAPI``, ``SfcPotPolyClassAPI`` and ``SfcPotPolyClass``.
2419 Administering SFC Proof of Transit
2420 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2422 To use the SFC Proof of Transit Karaf, at least the following Karaf
2423 features must be installed:
2433 - odl-netconf-topology
2435 - odl-netconf-connector-all
2439 SFC Proof of Transit Tutorial
2440 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2445 This tutorial is a simple example how to configure Service Function
2446 Chain Proof of Transit using SFC POT feature.
2451 To enable a device to handle SFC Proof of Transit, it is expected that
2452 the netconf server device advertise capability as under ioam-scv.yang
2453 present under src/main/yang folder of sfc-pot feature. It is also
2454 expected that netconf notifications be enabled and its support
2455 capability advertised as capabilities.
2457 It is also expected that the devices are netconf mounted and available
2458 in the topology-netconf store.
2463 When SFC Proof of Transit is installed, all netconf nodes in
2464 topology-netconf are processed and all capable nodes with accessible
2465 mountpoints are cached.
2467 First step is to create the required RSP as usually done.
2469 Once RSP name is avaiable it is used to send a POST RPC to the
2470 controller similar to below:
2474 POST ./restconf/operations/sfc-ioam-nb-pot:enable-sfc-ioam-pot-rendered-path
2478 "sfc-ioam-pot-rsp-name": "rsp1"
2482 The following can be used to disable the SFC Proof of Transit on an RSP
2483 which removes the augmentations and stores back the RSP without the
2484 SFCPOT enabled features and also sending down a delete configuration to
2485 the SFCPOT configuration sub-tree in the nodes.
2489 POST ./restconf/operations/sfc-ioam-nb-pot:disable-sfc-ioam-pot-rendered-path
2493 "sfc-ioam-pot-rsp-name": "rsp1"