3 Service Function Chaining
4 =========================
6 OpenDaylight Service Function Chaining (SFC) Overview
7 -----------------------------------------------------
9 OpenDaylight Service Function Chaining (SFC) provides the ability to
10 define an ordered list of network services (e.g. firewalls, load
11 balancers). These services are then "stitched" together in the network
12 to create a service chain. This project provides the infrastructure
13 (chaining logic, APIs) needed for ODL to provision a service chain in
14 the network and an end-user application for defining such chains.
16 - ACE - Access Control Entry
18 - ACL - Access Control List
20 - SCF - Service Classifier Function
22 - SF - Service Function
24 - SFC - Service Function Chain
26 - SFF - Service Function Forwarder
28 - SFG - Service Function Group
30 - SFP - Service Function Path
32 - RSP - Rendered Service Path
34 - NSH - Network Service Header
42 The SFC User interface comes in two flavors:
44 - Web Interface (SFC-UI): is based on Dlux project. It provides an easy way to
45 create, read, update and delete configuration stored in the datastore.
46 Moreover, it shows the status of all SFC features (e.g installed,
47 uninstalled) and Karaf log messages as well.
49 - Command Line Interface (CLI): it provides several Karaf console commands to
50 show the SFC model (SF, SFFs, etc.) provisioned in the datastore.
53 SFC Web Interface (SFC-UI)
54 ~~~~~~~~~~~~~~~~~~~~~~~~~~
59 SFC-UI operates purely by using RESTCONF.
61 .. figure:: ./images/sfc/sfc-ui-architecture.png
62 :alt: SFC-UI integration into ODL
64 SFC-UI integration into ODL
69 1. Run ODL distribution (run karaf)
71 2. In Karaf console execute: ``feature:install odl-sfc-ui``
73 3. Visit SFC-UI on: ``http://<odl_ip_address>:8181/sfc/index.html``
76 SFC Command Line Interface (SFC-CLI)
77 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
82 The Karaf Container offers a complete Unix-like console that allows managing
83 the container. This console can be extended with custom commands to manage the
84 features deployed on it. This feature will add some basic commands to show the
85 provisioned SFC entities.
90 The SFC-CLI implements commands to show some of the provisioned SFC entities:
91 Service Functions, Service Function Forwarders, Service Function
92 Chains, Service Function Paths, Service Function Classifiers, Service Nodes and
93 Service Function Types:
95 * List one/all provisioned Service Functions:
99 sfc:sf-list [--name <name>]
101 * List one/all provisioned Service Function Forwarders:
105 sfc:sff-list [--name <name>]
107 * List one/all provisioned Service Function Chains:
111 sfc:sfc-list [--name <name>]
113 * List one/all provisioned Service Function Paths:
117 sfc:sfp-list [--name <name>]
119 * List one/all provisioned Service Function Classifiers:
123 sfc:sc-list [--name <name>]
125 * List one/all provisioned Service Nodes:
129 sfc:sn-list [--name <name>]
131 * List one/all provisioned Service Function Types:
135 sfc:sft-list [--name <name>]
137 SFC Southbound REST Plug-in
138 ---------------------------
143 The Southbound REST Plug-in is used to send configuration from datastore
144 down to network devices supporting a REST API (i.e. they have a
145 configured REST URI). It supports POST/PUT/DELETE operations, which are
146 triggered accordingly by changes in the SFC data stores.
148 - Access Control List (ACL)
150 - Service Classifier Function (SCF)
152 - Service Function (SF)
154 - Service Function Group (SFG)
156 - Service Function Schedule Type (SFST)
158 - Service Function Forwarder (SFF)
160 - Rendered Service Path (RSP)
162 Southbound REST Plug-in Architecture
163 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
165 From the user perspective, the REST plug-in is another SFC Southbound
166 plug-in used to communicate with network devices.
168 .. figure:: ./images/sfc/sb-rest-architecture-user.png
169 :alt: Southbound REST Plug-in integration into ODL
171 Southbound REST Plug-in integration into ODL
173 Configuring Southbound REST Plugin
174 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
176 1. Run ODL distribution (run karaf)
178 2. In Karaf console execute: ``feature:install odl-sfc-sb-rest``
180 3. Configure REST URIs for SF/SFF through SFC User Interface or RESTCONF
181 (required configuration steps can be found in the tutorial stated
187 Comprehensive tutorial on how to use the Southbound REST Plug-in and how
188 to control network devices with it can be found on:
189 https://wiki.opendaylight.org/view/Service_Function_Chaining:Main#SFC_103
197 SFC-OVS provides integration of SFC with Open vSwitch (OVS) devices.
198 Integration is realized through mapping of SFC objects (like SF, SFF,
199 Classifier, etc.) to OVS objects (like Bridge,
200 TerminationPoint=Port/Interface). The mapping takes care of automatic
201 instantiation (setup) of corresponding object whenever its counterpart
202 is created. For example, when a new SFF is created, the SFC-OVS plug-in
203 will create a new OVS bridge.
205 The feature is intended for SFC users willing to use Open vSwitch as an
206 underlying network infrastructure for deploying RSPs (Rendered Service
212 SFC-OVS uses the OVSDB MD-SAL Southbound API for getting/writing
213 information from/to OVS devices. From the user perspective SFC-OVS acts
214 as a layer between SFC datastore and OVSDB.
216 .. figure:: ./images/sfc/sfc-ovs-architecture-user.png
217 :alt: SFC-OVS integration into ODL
219 SFC-OVS integration into ODL
224 1. Run ODL distribution (run karaf)
226 2. In Karaf console execute: ``feature:install odl-sfc-ovs``
228 3. Configure Open vSwitch to use ODL as a manager, using following
229 command: ``ovs-vsctl set-manager tcp:<odl_ip_address>:6640``
234 Verifying mapping from SFF to OVS
235 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
240 This tutorial shows the usual workflow during creation of an OVS
241 Bridge with use of the SFC APIs.
246 - Open vSwitch installed (ovs-vsctl command available in shell)
248 - SFC-OVS feature configured as stated above
253 1. In a shell execute: ``ovs-vsctl set-manager tcp:<odl_ip_address>:6640``
255 2. Send POST request to URL:
256 ``http://<odl_ip_address>:8181/restconf/operations/service-function-forwarder-ovs:create-ovs-bridge``
257 Use Basic auth with credentials: "admin", "admin" and set
258 ``Content-Type: application/json``. The content of POST request
268 "ip": "<Open_vSwitch_ip_address>"
273 Open\_vSwitch\_ip\_address is the IP address of the machine where Open vSwitch
279 In a shell execute: ``ovs-vsctl show``. There should be a Bridge with
280 the name *br-test* and one port/interface called *br-test*.
282 Also, the corresponding SFF for this OVS Bridge should be configured,
283 which can be verified through the SFC User Interface or RESTCONF as
286 a. Visit the SFC User Interface:
287 ``http://<odl_ip_address>:8181/sfc/index.html#/sfc/serviceforwarder``
289 b. Use pure RESTCONF and send a GET request to URL:
290 ``http://<odl_ip_address>:8181/restconf/config/service-function-forwarder:service-function-forwarders``
292 There should be an SFF, whose name will be ending with *br1* and the
293 SFF should contain two DataPlane locators: *br1* and *testPort*.
296 SFC Classifier User Guide
297 -------------------------
302 Description of classifier can be found in:
303 https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/
305 There are two types of classifier:
307 1. OpenFlow Classifier
309 2. Iptables Classifier
314 OpenFlow Classifier implements the classification criteria based on
315 OpenFlow rules deployed into an OpenFlow switch. An Open vSwitch will
316 take the role of a classifier and performs various encapsulations such
317 NSH, VLAN, MPLS, etc. In the existing implementation, classifier can
318 support NSH encapsulation. Matching information is based on ACL for MAC
319 addresses, ports, protocol, IPv4 and IPv6. Supported protocols are TCP,
320 UDP and SCTP. Actions information in the OF rules, shall be forwarding
321 of the encapsulated packets with specific information related to the
324 Classifier Architecture
325 ^^^^^^^^^^^^^^^^^^^^^^^
327 The OVSDB Southbound interface is used to create an instance of a bridge
328 in a specific location (via IP address). This bridge contains the
329 OpenFlow rules that perform the classification of the packets and react
330 accordingly. The OpenFlow Southbound interface is used to translate the
331 ACL information into OF rules within the Open vSwitch.
335 in order to create the instance of the bridge that takes the role of
336 a classifier, an "empty" SFF must be created.
338 Configuring Classifier
339 ^^^^^^^^^^^^^^^^^^^^^^
341 1. An empty SFF must be created in order to host the ACL that contains
342 the classification information.
344 2. SFF data plane locator must be configured
346 3. Classifier interface must be manually added to SFF bridge.
348 Administering or Managing Classifier
349 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
351 Classification information is based on MAC addresses, protocol, ports
352 and IP. ACL gathers this information and is assigned to an RSP which
353 turns to be a specific path for a Service Chain.
358 Classifier manages everything from starting the packet listener to
359 creation (and removal) of appropriate ip(6)tables rules and marking
360 received packets accordingly. Its functionality is **available only on
361 Linux** as it leverdges **NetfilterQueue**, which provides access to
362 packets matched by an **iptables** rule. Classifier requires **root
363 privileges** to be able to operate.
365 So far it is capable of processing ACL for MAC addresses, ports, IPv4
366 and IPv6. Supported protocols are TCP and UDP.
368 Classifier Architecture
369 ^^^^^^^^^^^^^^^^^^^^^^^
371 Python code located in the project repository
372 sfc-py/common/classifier.py.
376 classifier assumes that Rendered Service Path (RSP) **already
377 exists** in ODL when an ACL referencing it is obtained
379 1. sfc\_agent receives an ACL and passes it for processing to the
382 2. the RSP (its SFF locator) referenced by ACL is requested from ODL
384 3. if the RSP exists in the ODL then ACL based iptables rules for it are
387 After this process is over, every packet successfully matched to an
388 iptables rule (i.e. successfully classified) will be NSH encapsulated
389 and forwarded to a related SFF, which knows how to traverse the RSP.
391 Rules are created using appropriate iptables command. If the Access
392 Control Entry (ACE) rule is MAC address related both iptables and
393 IPv6 tables rules re issued. If ACE rule is IPv4 address related, only
394 iptables rules are issued, same for IPv6.
398 iptables **raw** table contains all created rules
400 Configuring Classifier
401 ^^^^^^^^^^^^^^^^^^^^^^
403 | Classfier does’t need any configuration.
404 | Its only requirement is that the **second (2) Netfilter Queue** is not
405 used by any other process and is **avalilable for the classifier**.
407 Administering or Managing Classifier
408 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
410 Classifier runs alongside sfc\_agent, therefore the command for starting
415 sudo python3.4 sfc-py/sfc_agent.py --rest --odl-ip-port localhost:8181
416 --auto-sff-name --nfq-class
418 SFC OpenFlow Renderer User Guide
419 --------------------------------
424 The Service Function Chaining (SFC) OpenFlow Renderer (SFC OF Renderer)
425 implements Service Chaining on OpenFlow switches. It listens for the
426 creation of a Rendered Service Path (RSP) in the operational data store,
427 and once received it programs Service Function Forwarders (SFF) that
428 are hosted on OpenFlow capable switches to forward packets through the
431 Common acronyms used in the following sections:
433 - SF - Service Function
435 - SFF - Service Function Forwarder
437 - SFC - Service Function Chain
439 - SFP - Service Function Path
441 - RSP - Rendered Service Path
443 SFC OpenFlow Renderer Architecture
444 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
446 The SFC OF Renderer is invoked after a RSP is created in the operational
447 data store using an MD-SAL listener called ``SfcOfRspDataListener``.
448 Upon SFC OF Renderer initialization, the ``SfcOfRspDataListener``
449 registers itself to listen for RSP changes. When invoked, the
450 ``SfcOfRspDataListener`` processes the RSP and calls the
451 ``SfcOfFlowProgrammerImpl`` to create the necessary flows in
452 the Service Function Forwarders configured in the
453 RSP. Refer to the following diagram for more details.
455 .. figure:: ./images/sfc/sfcofrenderer_architecture.png
456 :alt: SFC OpenFlow Renderer High Level Architecture
458 SFC OpenFlow Renderer High Level Architecture
460 .. _sfc-user-guide-sfc-of-pipeline:
462 SFC OpenFlow Switch Flow pipeline
463 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
465 The SFC OpenFlow Renderer uses the following tables for its Flow
468 - Table 0, Classifier
470 - Table 1, Transport Ingress
472 - Table 2, Path Mapper
474 - Table 3, Path Mapper ACL
478 - Table 10, Transport Egress
480 The OpenFlow Table Pipeline is intended to be generic to work for all of
481 the different encapsulations supported by SFC.
483 All of the tables are explained in detail in the following section.
485 The SFFs (SFF1 and SFF2), SFs (SF1), and topology used for the flow
486 tables in the following sections are as described in the following
489 .. figure:: ./images/sfc/sfcofrenderer_nwtopo.png
490 :alt: SFC OpenFlow Renderer Typical Network Topology
492 SFC OpenFlow Renderer Typical Network Topology
494 Classifier Table detailed
495 ^^^^^^^^^^^^^^^^^^^^^^^^^
497 It is possible for the SFF to also act as a classifier. This table maps
498 subscriber traffic to RSPs, and is explained in detail in the classifier
501 If the SFF is not a classifier, then this table will just have a simple
504 Transport Ingress Table detailed
505 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
507 The Transport Ingress table has an entry per expected tunnel transport
508 type to be received in a particular SFF, as established in the SFC
511 Here are two example on SFF1: one where the RSP ingress tunnel is MPLS
512 assuming VLAN is used for the SFF-SF, and the other where the RSP
513 ingress tunnel is NSH GRE (UDP port 4789):
515 +----------+-------------------------------------+--------------+
516 | Priority | Match | Action |
517 +==========+=====================================+==============+
518 | 256 | EtherType==0x8847 (MPLS unicast) | Goto Table 2 |
519 +----------+-------------------------------------+--------------+
520 | 256 | EtherType==0x8100 (VLAN) | Goto Table 2 |
521 +----------+-------------------------------------+--------------+
522 | 256 | EtherType==0x0800,udp,tp\_dst==4789 | Goto Table 2 |
524 +----------+-------------------------------------+--------------+
525 | 5 | Match Any | Drop |
526 +----------+-------------------------------------+--------------+
528 Table: Table Transport Ingress
530 Path Mapper Table detailed
531 ^^^^^^^^^^^^^^^^^^^^^^^^^^
533 The Path Mapper table has an entry per expected tunnel transport info to
534 be received in a particular SFF, as established in the SFC
535 configuration. The tunnel transport info is used to determine the RSP
536 Path ID, and is stored in the OpenFlow Metadata. This table is not used
537 for NSH, since the RSP Path ID is stored in the NSH header.
539 For SF nodes that do not support NSH tunneling, the IP header DSCP field
540 is used to store the RSP Path Id. The RSP Path Id is written to the DSCP
541 field in the Transport Egress table for those packets sent to an SF.
543 Here is an example on SFF1, assuming the following details:
545 - VLAN ID 1000 is used for the SFF-SF
547 - The RSP Path 1 tunnel uses MPLS label 100 for ingress and 101 for
550 - The RSP Path 2 (symmetric downlink path) uses MPLS label 101 for
551 ingress and 100 for egress
553 +----------+-------------------+-----------------------+
554 | Priority | Match | Action |
555 +==========+===================+=======================+
556 | 256 | MPLS Label==100 | RSP Path=1, Pop MPLS, |
558 +----------+-------------------+-----------------------+
559 | 256 | MPLS Label==101 | RSP Path=2, Pop MPLS, |
561 +----------+-------------------+-----------------------+
562 | 256 | VLAN ID==1000, IP | RSP Path=1, Pop VLAN, |
563 | | DSCP==1 | Goto Table 4 |
564 +----------+-------------------+-----------------------+
565 | 256 | VLAN ID==1000, IP | RSP Path=2, Pop VLAN, |
566 | | DSCP==2 | Goto Table 4 |
567 +----------+-------------------+-----------------------+
568 | 5 | Match Any | Goto Table 3 |
569 +----------+-------------------+-----------------------+
571 Table: Table Path Mapper
573 Path Mapper ACL Table detailed
574 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
576 This table is only populated when PacketIn packets are received from the
577 switch for TcpProxy type SFs. These flows are created with an inactivity
578 timer of 60 seconds and will be automatically deleted upon expiration.
580 Next Hop Table detailed
581 ^^^^^^^^^^^^^^^^^^^^^^^
583 The Next Hop table uses the RSP Path Id and appropriate packet fields to
584 determine where to send the packet next. For NSH, only the NSP (Network
585 Services Path, RSP ID) and NSI (Network Services Index, next hop) fields
586 from the NSH header are needed to determine the VXLAN tunnel destination
587 IP. For VLAN or MPLS, then the source MAC address is used to determine
588 the destination MAC address.
590 Here are two examples on SFF1, assuming SFF1 is connected to SFF2. RSP
591 Paths 1 and 2 are symmetric VLAN paths. RSP Paths 3 and 4 are symmetric
592 NSH paths. RSP Path 1 ingress packets come from external to SFC, for
593 which we don’t have the source MAC address (MacSrc).
595 +----------+--------------------------------+--------------------------------+
596 | Priority | Match | Action |
597 +==========+================================+================================+
598 | 256 | RSP Path==1, MacSrc==SF1 | MacDst=SFF2, Goto Table 10 |
599 +----------+--------------------------------+--------------------------------+
600 | 256 | RSP Path==2, MacSrc==SF1 | Goto Table 10 |
601 +----------+--------------------------------+--------------------------------+
602 | 256 | RSP Path==2, MacSrc==SFF2 | MacDst=SF1, Goto Table 10 |
603 +----------+--------------------------------+--------------------------------+
604 | 246 | RSP Path==1 | MacDst=SF1, Goto Table 10 |
605 +----------+--------------------------------+--------------------------------+
606 | 256 | nsp=3,nsi=255 (SFF Ingress RSP | load:0xa000002→NXM\_NX\_TUN\_I |
607 | | 3) | PV4\_DST[], |
608 | | | Goto Table 10 |
609 +----------+--------------------------------+--------------------------------+
610 | 256 | nsp=3,nsi=254 (SFF Ingress | load:0xa00000a→NXM\_NX\_TUN\_I |
611 | | from SF, RSP 3) | PV4\_DST[], |
612 | | | Goto Table 10 |
613 +----------+--------------------------------+--------------------------------+
614 | 256 | nsp=4,nsi=254 (SFF1 Ingress | load:0xa00000a→NXM\_NX\_TUN\_I |
615 | | from SFF2) | PV4\_DST[], |
616 | | | Goto Table 10 |
617 +----------+--------------------------------+--------------------------------+
618 | 5 | Match Any | Drop |
619 +----------+--------------------------------+--------------------------------+
621 Table: Table Next Hop
623 Transport Egress Table detailed
624 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
626 The Transport Egress table prepares egress tunnel information and sends
629 Here are two examples on SFF1. RSP Paths 1 and 2 are symmetric MPLS
630 paths that use VLAN for the SFF-SF. RSP Paths 3 and 4 are symmetric NSH
631 paths. Since it is assumed that switches used for NSH will only have one
632 VXLAN port, the NSH packets are just sent back where they came from.
634 +----------+--------------------------------+--------------------------------+
635 | Priority | Match | Action |
636 +==========+================================+================================+
637 | 256 | RSP Path==1, MacDst==SF1 | Push VLAN ID 1000, Port=SF1 |
638 +----------+--------------------------------+--------------------------------+
639 | 256 | RSP Path==1, MacDst==SFF2 | Push MPLS Label 101, Port=SFF2 |
640 +----------+--------------------------------+--------------------------------+
641 | 256 | RSP Path==2, MacDst==SF1 | Push VLAN ID 1000, Port=SF1 |
642 +----------+--------------------------------+--------------------------------+
643 | 246 | RSP Path==2 | Push MPLS Label 100, |
645 +----------+--------------------------------+--------------------------------+
646 | 256 | nsp=3,nsi=255 (SFF Ingress RSP | IN\_PORT |
648 +----------+--------------------------------+--------------------------------+
649 | 256 | nsp=3,nsi=254 (SFF Ingress | IN\_PORT |
650 | | from SF, RSP 3) | |
651 +----------+--------------------------------+--------------------------------+
652 | 256 | nsp=4,nsi=254 (SFF1 Ingress | IN\_PORT |
654 +----------+--------------------------------+--------------------------------+
655 | 5 | Match Any | Drop |
656 +----------+--------------------------------+--------------------------------+
658 Table: Table Transport Egress
660 Administering SFC OF Renderer
661 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
663 To use the SFC OpenFlow Renderer Karaf, at least the following Karaf
664 features must be installed.
666 - odl-openflowplugin-nxm-extensions
668 - odl-openflowplugin-flow-services
674 - odl-sfc-openflow-renderer
676 - odl-sfc-ui (optional)
678 Since OpenDaylight Karaf features internally install dependent features
679 all of the above features can be installed by simply installing the
680 ''odl-sfc-openflow-renderer'' feature.
682 The following command can be used to view all of the currently installed
687 opendaylight-user@root>feature:list -i
689 Or, pipe the command to a grep to see a subset of the currently
690 installed Karaf features:
694 opendaylight-user@root>feature:list -i | grep sfc
696 To install a particular feature, use the Karaf ``feature:install``
699 SFC OF Renderer Tutorial
700 ~~~~~~~~~~~~~~~~~~~~~~~~
705 In this tutorial, the VXLAN-GPE NSH encapsulations will be shown.
706 The following Network Topology diagram is a logical view of the
707 SFFs and SFs involved in creating the Service Chains.
709 .. figure:: ./images/sfc/sfcofrenderer_nwtopo.png
710 :alt: SFC OpenFlow Renderer Typical Network Topology
712 SFC OpenFlow Renderer Typical Network Topology
717 To use this example, SFF OpenFlow switches must be created and connected
718 as illustrated above. Additionally, the SFs must be created and
721 Note that RSP symmetry depends on the Service Function Path symmetric
722 field, if present. If not, the RSP will be symmetric if any of the SFs
723 involved in the chain has the bidirectional field set to true.
728 The target environment is not important, but this use-case was created
734 The steps to use this tutorial are as follows. The referenced
735 configuration in the steps is listed in the following sections.
737 There are numerous ways to send the configuration. In the following
738 configuration chapters, the appropriate ``curl`` command is shown for
739 each configuration to be sent, including the URL.
741 Steps to configure the SFC OF Renderer tutorial:
743 1. Send the ``SF`` RESTCONF configuration
745 2. Send the ``SFF`` RESTCONF configuration
747 3. Send the ``SFC`` RESTCONF configuration
749 4. Send the ``SFP`` RESTCONF configuration
751 5. The ``RSP`` will be created internally when the ``SFP`` is created.
753 Once the configuration has been successfully created, query the Rendered
754 Service Paths with either the SFC UI or via RESTCONF. Notice that the
755 RSP is symmetrical, so the following 2 RSPs will be created:
757 - sfc-path1-Path-<RSP-ID>
759 - sfc-path1-Path-<RSP-ID>-Reverse
761 At this point the Service Chains have been created, and the OpenFlow
762 Switches are programmed to steer traffic through the Service Chain.
763 Traffic can now be injected from a client into the Service Chain. To
764 debug problems, the OpenFlow tables can be dumped with the following
765 commands, assuming SFF1 is called ``s1`` and SFF2 is called ``s2``.
769 sudo ovs-ofctl -O OpenFlow13 dump-flows s1
773 sudo ovs-ofctl -O OpenFlow13 dump-flows s2
775 In all the following configuration sections, replace the ``${JSON}``
776 string with the appropriate JSON configuration. Also, change the
777 ``localhost`` destination in the URL accordingly.
779 SFC OF Renderer NSH Tutorial
780 ''''''''''''''''''''''''''''
782 The following configuration sections show how to create the different
783 elements using NSH encapsulation.
785 | **NSH Service Function configuration**
787 The Service Function configuration can be sent with the following
792 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
793 --data '${JSON}' -X PUT --user
794 admin:admin http://localhost:8181/restconf/config/service-function:service-functions/
796 **SF configuration JSON.**
801 "service-functions": {
802 "service-function": [
805 "type": "http-header-enrichment",
806 "ip-mgmt-address": "10.0.0.2",
807 "sf-data-plane-locator": [
812 "transport": "service-locator:vxlan-gpe",
813 "service-function-forwarder": "sff1"
820 "ip-mgmt-address": "10.0.0.3",
821 "sf-data-plane-locator": [
826 "transport": "service-locator:vxlan-gpe",
827 "service-function-forwarder": "sff2"
835 | **NSH Service Function Forwarder configuration**
837 The Service Function Forwarder configuration can be sent with the
842 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/
844 **SFF configuration JSON.**
849 "service-function-forwarders": {
850 "service-function-forwarder": [
853 "service-node": "openflow:2",
854 "sff-data-plane-locator": [
857 "data-plane-locator":
861 "transport": "service-locator:vxlan-gpe"
865 "service-function-dictionary": [
868 "sff-sf-data-plane-locator":
870 "sf-dpl-name": "sf1dpl",
871 "sff-dpl-name": "sff1dpl"
878 "service-node": "openflow:3",
879 "sff-data-plane-locator": [
882 "data-plane-locator":
886 "transport": "service-locator:vxlan-gpe"
890 "service-function-dictionary": [
893 "sff-sf-data-plane-locator":
895 "sf-dpl-name": "sf2dpl",
896 "sff-dpl-name": "sff2dpl"
905 | **NSH Service Function Chain configuration**
907 The Service Function Chain configuration can be sent with the following
912 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
913 --data '${JSON}' -X PUT --user
914 admin:admin http://localhost:8181/restconf/config/service-function-chain:service-function-chains/
916 **SFC configuration JSON.**
921 "service-function-chains": {
922 "service-function-chain": [
924 "name": "sfc-chain1",
925 "sfc-service-function": [
927 "name": "hdr-enrich-abstract1",
928 "type": "http-header-enrichment"
931 "name": "firewall-abstract1",
940 | **NSH Service Function Path configuration**
942 The Service Function Path configuration can be sent with the following
947 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/
949 **SFP configuration JSON.**
954 "service-function-paths": {
955 "service-function-path": [
958 "service-chain-name": "sfc-chain1",
959 "transport-type": "service-locator:vxlan-gpe",
966 | **NSH Rendered Service Path Query**
968 The following command can be used to query all of the created Rendered
973 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/
975 SFC OF Renderer MPLS Tutorial
976 '''''''''''''''''''''''''''''
978 The following configuration sections show how to create the different
979 elements using MPLS encapsulation.
981 | **MPLS Service Function configuration**
983 The Service Function configuration can be sent with the following
988 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
989 --data '${JSON}' -X PUT --user
990 admin:admin http://localhost:8181/restconf/config/service-function:service-functions/
992 **SF configuration JSON.**
997 "service-functions": {
998 "service-function": [
1001 "type": "http-header-enrichment",
1002 "ip-mgmt-address": "10.0.0.2",
1003 "sf-data-plane-locator": [
1006 "mac": "00:00:08:01:02:01",
1008 "transport": "service-locator:mac",
1009 "service-function-forwarder": "sff1"
1016 "ip-mgmt-address": "10.0.0.3",
1017 "sf-data-plane-locator": [
1020 "mac": "00:00:08:01:03:01",
1022 "transport": "service-locator:mac",
1023 "service-function-forwarder": "sff2"
1031 | **MPLS Service Function Forwarder configuration**
1033 The Service Function Forwarder configuration can be sent with the
1036 .. code-block:: bash
1038 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/
1040 **SFF configuration JSON.**
1042 .. code-block:: json
1045 "service-function-forwarders": {
1046 "service-function-forwarder": [
1049 "service-node": "openflow:2",
1050 "sff-data-plane-locator": [
1052 "name": "ulSff1Ingress",
1053 "data-plane-locator":
1056 "transport": "service-locator:mpls"
1058 "service-function-forwarder-ofs:ofs-port":
1060 "mac": "11:11:11:11:11:11",
1065 "name": "ulSff1ToSff2",
1066 "data-plane-locator":
1069 "transport": "service-locator:mpls"
1071 "service-function-forwarder-ofs:ofs-port":
1073 "mac": "33:33:33:33:33:33",
1079 "data-plane-locator":
1081 "mac": "22:22:22:22:22:22",
1083 "transport": "service-locator:mac",
1085 "service-function-forwarder-ofs:ofs-port":
1087 "mac": "33:33:33:33:33:33",
1092 "service-function-dictionary": [
1095 "sff-sf-data-plane-locator":
1097 "sf-dpl-name": "sf1-sff1",
1098 "sff-dpl-name": "toSf1"
1105 "service-node": "openflow:3",
1106 "sff-data-plane-locator": [
1108 "name": "ulSff2Ingress",
1109 "data-plane-locator":
1112 "transport": "service-locator:mpls"
1114 "service-function-forwarder-ofs:ofs-port":
1116 "mac": "44:44:44:44:44:44",
1121 "name": "ulSff2Egress",
1122 "data-plane-locator":
1125 "transport": "service-locator:mpls"
1127 "service-function-forwarder-ofs:ofs-port":
1129 "mac": "66:66:66:66:66:66",
1135 "data-plane-locator":
1137 "mac": "55:55:55:55:55:55",
1139 "transport": "service-locator:mac"
1141 "service-function-forwarder-ofs:ofs-port":
1147 "service-function-dictionary": [
1150 "sff-sf-data-plane-locator":
1152 "sf-dpl-name": "sf2-sff2",
1153 "sff-dpl-name": "toSf2"
1156 "service-function-forwarder-ofs:ofs-port":
1167 | **MPLS Service Function Chain configuration**
1169 The Service Function Chain configuration can be sent with the following
1172 .. code-block:: bash
1174 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
1175 --data '${JSON}' -X PUT --user admin:admin
1176 http://localhost:8181/restconf/config/service-function-chain:service-function-chains/
1178 **SFC configuration JSON.**
1180 .. code-block:: json
1183 "service-function-chains": {
1184 "service-function-chain": [
1186 "name": "sfc-chain1",
1187 "sfc-service-function": [
1189 "name": "hdr-enrich-abstract1",
1190 "type": "http-header-enrichment"
1193 "name": "firewall-abstract1",
1202 | **MPLS Service Function Path configuration**
1204 The Service Function Path configuration can be sent with the following
1207 .. code-block:: bash
1209 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
1210 --data '${JSON}' -X PUT --user admin:admin
1211 http://localhost:8181/restconf/config/service-function-path:service-function-paths/
1213 **SFP configuration JSON.**
1215 .. code-block:: json
1218 "service-function-paths": {
1219 "service-function-path": [
1221 "name": "sfc-path1",
1222 "service-chain-name": "sfc-chain1",
1223 "transport-type": "service-locator:mpls",
1230 | **MPLS Rendered Service Path creation**
1232 .. code-block:: bash
1234 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
1235 --data '${JSON}' -X POST --user admin:admin
1236 http://localhost:8181/restconf/operations/rendered-service-path:create-rendered-path/
1238 | **MPLS Rendered Service Path Query**
1240 The following command can be used to query all of the created Rendered
1243 .. code-block:: bash
1245 curl -H "Content-Type: application/json" -H "Cache-Control: no-cache" -X GET
1246 --user admin:admin http://localhost:8181/restconf/operational/rendered-service-path:rendered-service-paths/
1248 SFC IOS XE Renderer User Guide
1249 ------------------------------
1254 The early Service Function Chaining (SFC) renderer for IOS-XE devices
1255 (SFC IOS-XE renderer) implements Service Chaining functionality on
1256 IOS-XE capable switches. It listens for the creation of a Rendered
1257 Service Path (RSP) and sets up Service Function Forwarders (SFF) that
1258 are hosted on IOS-XE switches to steer traffic through the service
1261 Common acronyms used in the following sections:
1263 - SF - Service Function
1265 - SFF - Service Function Forwarder
1267 - SFC - Service Function Chain
1271 - SFP - Service Function Path
1273 - RSP - Rendered Service Path
1275 - LSF - Local Service Forwarder
1277 - RSF - Remote Service Forwarder
1279 SFC IOS-XE Renderer Architecture
1280 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1282 When the SFC IOS-XE renderer is initialized, all required listeners are
1283 registered to handle incoming data. It involves CSR/IOS-XE
1284 ``NodeListener`` which stores data about all configurable devices
1285 including their mountpoints (used here as databrokers),
1286 ``ServiceFunctionListener``, ``ServiceForwarderListener`` (see mapping)
1287 and ``RenderedPathListener`` used to listen for RSP changes. When the
1288 SFC IOS-XE renderer is invoked, ``RenderedPathListener`` calls the
1289 ``IosXeRspProcessor`` which processes the RSP change and creates all
1290 necessary Service Paths and Remote Service Forwarders (if necessary) on
1293 Service Path details
1294 ~~~~~~~~~~~~~~~~~~~~
1296 Each Service Path is defined by index (represented by NSP) and contains
1297 service path entries. Each entry has appropriate service index (NSI) and
1298 definition of next hop. Next hop can be Service Function, different
1299 Service Function Forwarder or definition of end of chain - terminate.
1300 After terminating, the packet is sent to destination. If a SFF is
1301 defined as a next hop, it has to be present on device in the form of
1302 Remote Service Forwarder. RSFs are also created during RSP processing.
1304 Example of Service Path:
1308 service-chain service-path 200
1309 service-index 255 service-function firewall-1
1310 service-index 254 service-function dpi-1
1311 service-index 253 terminate
1313 Mapping to IOS-XE SFC entities
1314 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1316 Renderer contains mappers for SFs and SFFs. IOS-XE capable device is
1317 using its own definition of Service Functions and Service Function
1318 Forwarders according to appropriate .yang file.
1319 ``ServiceFunctionListener`` serves as a listener for SF changes. If SF
1320 appears in datastore, listener extracts its management ip address and
1321 looks into cached IOS-XE nodes. If some of available nodes match,
1322 Service function is mapped in ``IosXeServiceFunctionMapper`` to be
1323 understandable by IOS-XE device and it’s written into device’s config.
1324 ``ServiceForwarderListener`` is used in a similar way. All SFFs with
1325 suitable management ip address it mapped in
1326 ``IosXeServiceForwarderMapper``. Remapped SFFs are configured as a Local
1327 Service Forwarders. It is not possible to directly create Remote Service
1328 Forwarder using IOS-XE renderer. RSF is created only during RSP
1331 Administering SFC IOS-XE renderer
1332 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1334 To use the SFC IOS-XE Renderer Karaf, at least the following Karaf
1335 features must be installed:
1345 - odl-netconf-topology
1347 - odl-sfc-ios-xe-renderer
1349 SFC IOS-XE renderer Tutorial
1350 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1355 This tutorial is a simple example how to create Service Path on IOS-XE
1356 capable device using IOS-XE renderer
1361 To connect to IOS-XE device, it is necessary to use several modified
1362 yang models and override device’s ones. All .yang files are in the
1363 ``Yang/netconf`` folder in the ``sfc-ios-xe-renderer module`` in the SFC
1364 project. These files have to be copied to the ``cache/schema``
1365 directory, before Karaf is started. After that, custom capabilities have
1366 to be sent to network-topology:
1368 * PUT ./config/network-topology:network-topology/topology/topology-netconf/node/<device-name>
1372 <node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
1373 <node-id>device-name</node-id>
1374 <host xmlns="urn:opendaylight:netconf-node-topology">device-ip</host>
1375 <port xmlns="urn:opendaylight:netconf-node-topology">2022</port>
1376 <username xmlns="urn:opendaylight:netconf-node-topology">login</username>
1377 <password xmlns="urn:opendaylight:netconf-node-topology">password</password>
1378 <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
1379 <keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">0</keepalive-delay>
1380 <yang-module-capabilities xmlns="urn:opendaylight:netconf-node-topology">
1381 <override>true</override>
1382 <capability xmlns="urn:opendaylight:netconf-node-topology">
1383 urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2013-07-15
1385 <capability xmlns="urn:opendaylight:netconf-node-topology">
1386 urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&revision=2013-07-15
1388 <capability xmlns="urn:opendaylight:netconf-node-topology">
1389 urn:ios?module=ned&revision=2016-03-08
1391 <capability xmlns="urn:opendaylight:netconf-node-topology">
1392 http://tail-f.com/yang/common?module=tailf-common&revision=2015-05-22
1394 <capability xmlns="urn:opendaylight:netconf-node-topology">
1395 http://tail-f.com/yang/common?module=tailf-meta-extensions&revision=2013-11-07
1397 <capability xmlns="urn:opendaylight:netconf-node-topology">
1398 http://tail-f.com/yang/common?module=tailf-cli-extensions&revision=2015-03-19
1400 </yang-module-capabilities>
1405 The device name in the URL and in the XML must match.
1410 When the IOS-XE renderer is installed, all NETCONF nodes in
1411 topology-netconf are processed and all capable nodes with accessible
1412 mountpoints are cached. The first step is to create LSF on node.
1414 ``Service Function Forwarder configuration``
1416 * PUT ./config/service-function-forwarder:service-function-forwarders
1418 .. code-block:: json
1421 "service-function-forwarders": {
1422 "service-function-forwarder": [
1425 "ip-mgmt-address": "172.25.73.23",
1426 "sff-data-plane-locator": [
1428 "name": "CSR1Kv-2-dpl",
1429 "data-plane-locator": {
1430 "transport": "service-locator:vxlan-gpe",
1432 "ip": "10.99.150.10"
1441 If the IOS-XE node with appropriate management IP exists, this
1442 configuration is mapped and LSF is created on the device. The same
1443 approach is used for Service Functions.
1445 * PUT ./config/service-function:service-functions
1447 .. code-block:: json
1450 "service-functions": {
1451 "service-function": [
1454 "ip-mgmt-address": "172.25.73.23",
1456 "sf-data-plane-locator": [
1458 "name": "firewall-dpl",
1461 "transport": "service-locator:gre",
1462 "service-function-forwarder": "CSR1Kv-2"
1468 "ip-mgmt-address": "172.25.73.23",
1470 "sf-data-plane-locator": [
1475 "transport": "service-locator:gre",
1476 "service-function-forwarder": "CSR1Kv-2"
1482 "ip-mgmt-address": "172.25.73.23",
1484 "sf-data-plane-locator": [
1489 "transport": "service-locator:gre",
1490 "service-function-forwarder": "CSR1Kv-2"
1498 All these SFs are configured on the same device as the LSF. The next
1499 step is to prepare Service Function Chain.
1501 * PUT ./config/service-function-chain:service-function-chains/
1503 .. code-block:: json
1506 "service-function-chains": {
1507 "service-function-chain": [
1510 "sfc-service-function": [
1529 Service Function Path:
1531 * PUT ./config/service-function-path:service-function-paths/
1533 .. code-block:: json
1536 "service-function-paths": {
1537 "service-function-path": [
1539 "name": "CSR3XSF-Path",
1540 "service-chain-name": "CSR3XSF",
1541 "starting-index": 255,
1548 Without a classifier, there is possibility to POST RSP directly.
1550 * POST ./operations/rendered-service-path:create-rendered-path
1552 .. code-block:: json
1556 "name": "CSR3XSF-Path-RSP",
1557 "parent-service-function-path": "CSR3XSF-Path"
1561 The resulting configuration:
1566 service-chain service-function-forwarder local
1567 ip address 10.99.150.10
1569 service-chain service-function firewall
1571 encapsulation gre enhanced divert
1573 service-chain service-function dpi
1575 encapsulation gre enhanced divert
1577 service-chain service-function qos
1579 encapsulation gre enhanced divert
1581 service-chain service-path 1
1582 service-index 255 service-function firewall
1583 service-index 254 service-function dpi
1584 service-index 253 service-function qos
1585 service-index 252 terminate
1587 service-chain service-path 2
1588 service-index 255 service-function qos
1589 service-index 254 service-function dpi
1590 service-index 253 service-function firewall
1591 service-index 252 terminate
1594 Service Path 1 is direct, Service Path 2 is reversed. Path numbers may
1597 Service Function Scheduling Algorithms
1598 --------------------------------------
1603 When creating the Rendered Service Path, the origin SFC controller chose
1604 the first available service function from a list of service function
1605 names. This may result in many issues such as overloaded service
1606 functions and a longer service path as SFC has no means to understand
1607 the status of service functions and network topology. The service
1608 function selection framework supports at least four algorithms (Random,
1609 Round Robin, Load Balancing and Shortest Path) to select the most
1610 appropriate service function when instantiating the Rendered Service
1611 Path. In addition, it is an extensible framework that allows 3rd party
1612 selection algorithm to be plugged in.
1617 The following figure illustrates the service function selection
1618 framework and algorithms.
1620 .. figure:: ./images/sfc/sf-selection-arch.png
1621 :alt: SF Selection Architecture
1623 SF Selection Architecture
1625 A user has three different ways to select one service function selection
1628 1. Integrated RESTCONF Calls. OpenStack and/or other administration
1629 system could provide plugins to call the APIs to select one
1630 scheduling algorithm.
1632 2. Command line tools. Command line tools such as curl or browser
1633 plugins such as POSTMAN (for Google Chrome) and RESTClient (for
1634 Mozilla Firefox) could select schedule algorithm by making RESTCONF
1637 3. SFC-UI. Now the SFC-UI provides an option for choosing a selection
1638 algorithm when creating a Rendered Service Path.
1640 The RESTCONF northbound SFC API provides GUI/RESTCONF interactions for
1641 choosing the service function selection algorithm. MD-SAL data store
1642 provides all supported service function selection algorithms, and
1643 provides APIs to enable one of the provided service function selection
1644 algorithms. Once a service function selection algorithm is enabled, the
1645 service function selection algorithm will work when creating a Rendered
1648 Select SFs with Scheduler
1649 ~~~~~~~~~~~~~~~~~~~~~~~~~
1651 Administrator could use both the following ways to select one of the
1652 selection algorithm when creating a Rendered Service Path.
1654 - Command line tools. Command line tools includes Linux commands curl
1655 or even browser plugins such as POSTMAN(for Google Chrome) or
1656 RESTClient(for Mozilla Firefox). In this case, the following JSON
1657 content is needed at the moment:
1658 Service\_function\_schudule\_type.json
1660 .. code-block:: json
1663 "service-function-scheduler-types": {
1664 "service-function-scheduler-type": [
1667 "type": "service-function-scheduler-type:random",
1671 "name": "roundrobin",
1672 "type": "service-function-scheduler-type:round-robin",
1676 "name": "loadbalance",
1677 "type": "service-function-scheduler-type:load-balance",
1681 "name": "shortestpath",
1682 "type": "service-function-scheduler-type:shortest-path",
1689 If using the Linux curl command, it could be:
1691 .. code-block:: bash
1693 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
1694 --data '$${Service_function_schudule_type.json}' -X PUT
1695 --user admin:admin http://localhost:8181/restconf/config/service-function-scheduler-type:service-function-scheduler-types/
1698 Here is also a snapshot for using the RESTClient plugin:
1700 .. figure:: ./images/sfc/RESTClient-snapshot.png
1701 :alt: Mozilla Firefox RESTClient
1703 Mozilla Firefox RESTClient
1705 - SFC-UI.SFC-UI provides a drop down menu for service function
1706 selection algorithm. Here is a snapshot for the user interaction from
1707 SFC-UI when creating a Rendered Service Path.
1709 .. figure:: ./images/sfc/karaf-webui-select-a-type.png
1716 Some service function selection algorithms in the drop list are not
1717 implemented yet. Only the first three algorithms are committed at
1723 Select Service Function from the name list randomly.
1728 The Random algorithm is used to select one Service Function from the
1729 name list which it gets from the Service Function Type randomly.
1734 - Service Function information are stored in datastore.
1736 - Either no algorithm or the Random algorithm is selected.
1741 The Random algorithm will work either no algorithm type is selected or
1742 the Random algorithm is selected.
1747 Once the plugins are installed into Karaf successfully, a user can use
1748 his favorite method to select the Random scheduling algorithm type.
1749 There are no special instructions for using the Random algorithm.
1754 Select Service Function from the name list in Round Robin manner.
1759 The Round Robin algorithm is used to select one Service Function from
1760 the name list which it gets from the Service Function Type in a Round
1761 Robin manner, this will balance workloads to all Service Functions.
1762 However, this method cannot help all Service Functions load the same
1763 workload because it’s flow-based Round Robin.
1768 - Service Function information are stored in datastore.
1770 - Round Robin algorithm is selected
1775 The Round Robin algorithm will work one the Round Robin algorithm is
1781 Once the plugins are installed into Karaf successfully, a user can use
1782 his favorite method to select the Round Robin scheduling algorithm type.
1783 There are no special instructions for using the Round Robin algorithm.
1785 Load Balance Algorithm
1786 ^^^^^^^^^^^^^^^^^^^^^^
1788 Select appropriate Service Function by actual CPU utilization.
1793 The Load Balance Algorithm is used to select appropriate Service
1794 Function by actual CPU utilization of service functions. The CPU
1795 utilization of service function obtained from monitoring information
1796 reported via NETCONF.
1801 - CPU-utilization for Service Function.
1807 - Each VM has a NETCONF server and it could work with NETCONF client
1813 Set up VMs as Service Functions. enable NETCONF server in VMs. Ensure
1814 that you specify them separately. For example:
1816 a. Set up 4 VMs include 2 SFs' type are Firewall, Others are Napt44.
1817 Name them as firewall-1, firewall-2, napt44-1, napt44-2 as Service
1818 Function. The four VMs can run either the same server or different
1821 b. Install NETCONF server on every VM and enable it. More information on
1822 NETCONF can be found on the OpenDaylight wiki here:
1823 https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf:Manual_netopeer_installation
1825 c. Get Monitoring data from NETCONF server. These monitoring data should
1826 be get from the NETCONF server which is running in VMs. The following
1827 static XML data is an example:
1829 static XML data like this:
1833 <?xml version="1.0" encoding="UTF-8"?>
1834 <service-function-description-monitor-report>
1836 <number-of-dataports>2</number-of-dataports>
1838 <supported-packet-rate>5</supported-packet-rate>
1839 <supported-bandwidth>10</supported-bandwidth>
1840 <supported-ACL-number>2000</supported-ACL-number>
1841 <RIB-size>200</RIB-size>
1842 <FIB-size>100</FIB-size>
1845 <port-id>1</port-id>
1846 <ipaddress>10.0.0.1</ipaddress>
1847 <macaddress>00:1e:67:a2:5f:f4</macaddress>
1848 <supported-bandwidth>20</supported-bandwidth>
1851 <port-id>2</port-id>
1852 <ipaddress>10.0.0.2</ipaddress>
1853 <macaddress>01:1e:67:a2:5f:f6</macaddress>
1854 <supported-bandwidth>10</supported-bandwidth>
1859 <SF-monitoring-info>
1860 <liveness>true</liveness>
1861 <resource-utilization>
1862 <packet-rate-utilization>10</packet-rate-utilization>
1863 <bandwidth-utilization>15</bandwidth-utilization>
1864 <CPU-utilization>12</CPU-utilization>
1865 <memory-utilization>17</memory-utilization>
1866 <available-memory>8</available-memory>
1867 <RIB-utilization>20</RIB-utilization>
1868 <FIB-utilization>25</FIB-utilization>
1869 <power-utilization>30</power-utilization>
1870 <SF-ports-bandwidth-utilization>
1871 <port-bandwidth-utilization>
1872 <port-id>1</port-id>
1873 <bandwidth-utilization>20</bandwidth-utilization>
1874 </port-bandwidth-utilization>
1875 <port-bandwidth-utilization>
1876 <port-id>2</port-id>
1877 <bandwidth-utilization>30</bandwidth-utilization>
1878 </port-bandwidth-utilization>
1879 </SF-ports-bandwidth-utilization>
1880 </resource-utilization>
1881 </SF-monitoring-info>
1882 </service-function-description-monitor-report>
1884 a. Unzip SFC release tarball.
1886 b. Run SFC: ${sfc}/bin/karaf. More information on Service Function
1887 Chaining can be found on the OpenDaylight SFC’s wiki page:
1888 https://wiki.opendaylight.org/view/Service_Function_Chaining:Main
1890 a. Deploy the SFC2 (firewall-abstract2⇒napt44-abstract2) and click
1891 button to Create Rendered Service Path in SFC UI
1892 (http://localhost:8181/sfc/index.html).
1894 b. Verify the Rendered Service Path to ensure the CPU utilization of the
1895 selected hop is the minimum one among all the service functions with
1896 same type. The correct RSP is firewall-1⇒napt44-2
1898 Shortest Path Algorithm
1899 ^^^^^^^^^^^^^^^^^^^^^^^
1901 Select appropriate Service Function by Dijkstra’s algorithm. Dijkstra’s
1902 algorithm is an algorithm for finding the shortest paths between nodes
1908 The Shortest Path Algorithm is used to select appropriate Service
1909 Function by actual topology.
1914 - Deployed topology (include SFFs, SFs and their links).
1916 - Dijkstra’s algorithm. More information on Dijkstra’s algorithm can be
1917 found on the wiki here:
1918 http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm
1923 a. Unzip SFC release tarball.
1925 b. Run SFC: ${sfc}/bin/karaf.
1927 c. Depoly SFFs and SFs. import the service-function-forwarders.json and
1928 service-functions.json in UI
1929 (http://localhost:8181/sfc/index.html#/sfc/config)
1931 service-function-forwarders.json:
1933 .. code-block:: json
1936 "service-function-forwarders": {
1937 "service-function-forwarder": [
1940 "service-node": "OVSDB-test01",
1941 "rest-uri": "http://localhost:5001",
1942 "sff-data-plane-locator": [
1945 "service-function-forwarder-ovs:ovs-bridge": {
1946 "uuid": "4c3778e4-840d-47f4-b45e-0988e514d26c",
1947 "bridge-name": "br-tun"
1949 "data-plane-locator": {
1951 "ip": "192.168.1.1",
1952 "transport": "service-locator:vxlan-gpe"
1956 "service-function-dictionary": [
1958 "sff-sf-data-plane-locator": {
1959 "sf-dpl-name": "sf1dpl",
1960 "sff-dpl-name": "sff1dpl"
1966 "sff-sf-data-plane-locator": {
1967 "sf-dpl-name": "sf2dpl",
1968 "sff-dpl-name": "sff2dpl"
1970 "name": "firewall-1",
1974 "connected-sff-dictionary": [
1982 "service-node": "OVSDB-test01",
1983 "rest-uri": "http://localhost:5002",
1984 "sff-data-plane-locator": [
1987 "service-function-forwarder-ovs:ovs-bridge": {
1988 "uuid": "fd4d849f-5140-48cd-bc60-6ad1f5fc0a1",
1989 "bridge-name": "br-tun"
1991 "data-plane-locator": {
1993 "ip": "192.168.1.2",
1994 "transport": "service-locator:vxlan-gpe"
1998 "service-function-dictionary": [
2000 "sff-sf-data-plane-locator": {
2001 "sf-dpl-name": "sf1dpl",
2002 "sff-dpl-name": "sff1dpl"
2008 "sff-sf-data-plane-locator": {
2009 "sf-dpl-name": "sf2dpl",
2010 "sff-dpl-name": "sff2dpl"
2012 "name": "firewall-2",
2016 "connected-sff-dictionary": [
2024 "service-node": "OVSDB-test01",
2025 "rest-uri": "http://localhost:5005",
2026 "sff-data-plane-locator": [
2029 "service-function-forwarder-ovs:ovs-bridge": {
2030 "uuid": "fd4d849f-5140-48cd-bc60-6ad1f5fc0a4",
2031 "bridge-name": "br-tun"
2033 "data-plane-locator": {
2035 "ip": "192.168.1.2",
2036 "transport": "service-locator:vxlan-gpe"
2040 "service-function-dictionary": [
2042 "sff-sf-data-plane-locator": {
2043 "sf-dpl-name": "sf1dpl",
2044 "sff-dpl-name": "sff1dpl"
2046 "name": "test-server",
2050 "sff-sf-data-plane-locator": {
2051 "sf-dpl-name": "sf2dpl",
2052 "sff-dpl-name": "sff2dpl"
2054 "name": "test-client",
2058 "connected-sff-dictionary": [
2071 service-functions.json:
2073 .. code-block:: json
2076 "service-functions": {
2077 "service-function": [
2079 "rest-uri": "http://localhost:10001",
2080 "ip-mgmt-address": "10.3.1.103",
2081 "sf-data-plane-locator": [
2083 "name": "preferred",
2086 "service-function-forwarder": "SFF-br1"
2093 "rest-uri": "http://localhost:10002",
2094 "ip-mgmt-address": "10.3.1.103",
2095 "sf-data-plane-locator": [
2100 "service-function-forwarder": "SFF-br2"
2107 "rest-uri": "http://localhost:10003",
2108 "ip-mgmt-address": "10.3.1.103",
2109 "sf-data-plane-locator": [
2114 "service-function-forwarder": "SFF-br1"
2117 "name": "firewall-1",
2121 "rest-uri": "http://localhost:10004",
2122 "ip-mgmt-address": "10.3.1.103",
2123 "sf-data-plane-locator": [
2128 "service-function-forwarder": "SFF-br2"
2131 "name": "firewall-2",
2135 "rest-uri": "http://localhost:10005",
2136 "ip-mgmt-address": "10.3.1.103",
2137 "sf-data-plane-locator": [
2142 "service-function-forwarder": "SFF-br3"
2145 "name": "test-server",
2149 "rest-uri": "http://localhost:10006",
2150 "ip-mgmt-address": "10.3.1.103",
2151 "sf-data-plane-locator": [
2156 "service-function-forwarder": "SFF-br3"
2159 "name": "test-client",
2166 The deployed topology like this:
2168 .. code-block:: json
2170 +----+ +----+ +----+
2171 |sff1|+----------|sff3|---------+|sff2|
2172 +----+ +----+ +----+
2174 +--------------+ +--------------+
2176 +----------+ +--------+ +----------+ +--------+
2177 |firewall-1| |napt44-1| |firewall-2| |napt44-2|
2178 +----------+ +--------+ +----------+ +--------+
2180 - Deploy the SFC2(firewall-abstract2⇒napt44-abstract2), select
2181 "Shortest Path" as schedule type and click button to Create Rendered
2182 Service Path in SFC UI (http://localhost:8181/sfc/index.html).
2184 .. figure:: ./images/sfc/sf-schedule-type.png
2185 :alt: select schedule type
2187 select schedule type
2189 - Verify the Rendered Service Path to ensure the selected hops are
2190 linked in one SFF. The correct RSP is firewall-1⇒napt44-1 or
2191 firewall-2⇒napt44-2. The first SF type is Firewall in Service
2192 Function Chain. So the algorithm will select first Hop randomly among
2193 all the SFs type is Firewall. Assume the first selected SF is
2194 firewall-2. All the path from firewall-1 to SF which type is Napt44
2197 - Path1: firewall-2 → sff2 → napt44-2
2199 - Path2: firewall-2 → sff2 → sff3 → sff1 → napt44-1 The shortest
2200 path is Path1, so the selected next hop is napt44-2.
2202 .. figure:: ./images/sfc/sf-rendered-service-path.png
2203 :alt: rendered service path
2205 rendered service path
2207 Service Function Load Balancing User Guide
2208 ------------------------------------------
2213 SFC Load-Balancing feature implements load balancing of Service
2214 Functions, rather than a one-to-one mapping between
2215 Service-Function-Forwarder and Service-Function.
2217 Load Balancing Architecture
2218 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
2220 Service Function Groups (SFG) can replace Service Functions (SF) in the
2221 Rendered Path model. A Service Path can only be defined using SFGs or
2222 SFs, but not a combination of both.
2224 Relevant objects in the YANG model are as follows:
2226 1. Service-Function-Group-Algorithm:
2230 Service-Function-Group-Algorithms {
2231 Service-Function-Group-Algorithm {
2239 Available types: ALL, SELECT, INDIRECT, FAST_FAILURE
2241 2. Service-Function-Group:
2245 Service-Function-Groups {
2246 Service-Function-Group {
2248 String serviceFunctionGroupAlgorithmName
2251 Service-Function-Group-Element {
2252 String service-function-name
2258 3. ServiceFunctionHop: holds a reference to a name of SFG (or SF)
2263 This tutorial will explain how to create a simple SFC configuration,
2264 with SFG instead of SF. In this example, the SFG will include two
2270 For general SFC setup and scenarios, please see the SFC wiki page:
2271 https://wiki.opendaylight.org/view/Service_Function_Chaining:Main#SFC_101
2277 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2279 .. code-block:: json
2282 "service-function-group-algorithm": [
2290 (Header "content-type": application/json)
2292 Verify: get all algorithms
2293 ^^^^^^^^^^^^^^^^^^^^^^^^^^
2296 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2298 In order to delete all algorithms: DELETE -
2299 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2305 http://127.0.0.1:8181/restconf/config/service-function-group:service-function-groups
2307 .. code-block:: json
2310 "service-function-group": [
2312 "rest-uri": "http://localhost:10002",
2313 "ip-mgmt-address": "10.3.1.103",
2314 "algorithm": "alg1",
2317 "sfc-service-function": [
2322 "name":"napt44-103-1"
2329 Verify: get all SFG’s
2330 ^^^^^^^^^^^^^^^^^^^^^
2333 http://127.0.0.1:8181/restconf/config/service-function-group:service-function-groups
2335 SFC Proof of Transit User Guide
2336 -------------------------------
2341 Several deployments use traffic engineering, policy routing, segment
2342 routing or service function chaining (SFC) to steer packets through a
2343 specific set of nodes. In certain cases regulatory obligations or a
2344 compliance policy require to prove that all packets that are supposed to
2345 follow a specific path are indeed being forwarded across the exact set
2346 of nodes specified. I.e. if a packet flow is supposed to go through a
2347 series of service functions or network nodes, it has to be proven that
2348 all packets of the flow actually went through the service chain or
2349 collection of nodes specified by the policy. In case the packets of a
2350 flow weren’t appropriately processed, a proof of transit egress device
2351 would be required to identify the policy violation and take
2352 corresponding actions (e.g. drop or redirect the packet, send an alert
2353 etc.) corresponding to the policy.
2355 Service Function Chaining (SFC) Proof of Transit (SFC PoT)
2356 implements Service Chaining Proof of Transit functionality on capable
2357 network devices. Proof of Transit defines mechanisms to securely
2358 prove that traffic transited the defined path. After the creation of an
2359 Rendered Service Path (RSP), a user can configure to enable SFC proof
2360 of transit on the selected RSP to effect the proof of transit.
2362 To ensure that the data traffic follows a specified path or a function
2363 chain, meta-data is added to user traffic in the form of a header. The
2364 meta-data is based on a 'share of a secret' and provisioned by the SFC
2365 PoT configuration from ODL over a secure channel to each of the nodes
2366 in the SFC. This meta-data is updated at each of the service-hop while
2367 a designated node called the verifier checks whether the collected
2368 meta-data allows the retrieval of the secret.
2370 The following diagram shows the overview and essentially utilizes Shamir's
2371 secret sharing algorithm, where each service is given a point on the
2372 curve and when the packet travels through each service, it collects these
2373 points (meta-data) and a verifier node tries to re-construct the curve
2374 using the collected points, thus verifying that the packet traversed
2375 through all the service functions along the chain.
2377 .. figure:: ./images/sfc/sfc-pot-intro.png
2378 :alt: SFC Proof of Transit overview
2380 SFC Proof of Transit overview
2382 Transport options for different protocols includes a new TLV in SR header
2383 for Segment Routing, NSH Type-2 meta-data, IPv6 extension headers, IPv4
2384 variants and for VXLAN-GPE. More details are captured in the following
2387 In-situ OAM: https://github.com/CiscoDevNet/iOAM
2389 Common acronyms used in the following sections:
2391 - SF - Service Function
2393 - SFF - Service Function Forwarder
2395 - SFC - Service Function Chain
2397 - SFP - Service Function Path
2399 - RSP - Rendered Service Path
2401 - SFC PoT - Service Function Chain Proof of Transit
2404 SFC Proof of Transit Architecture
2405 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2407 SFC PoT feature is implemented as a two-part implementation with a
2408 north-bound handler that augments the RSP while a south-bound renderer
2409 auto-generates the required parameters and passes it on to the nodes
2410 that belong to the SFC.
2412 The north-bound feature is enabled via odl-sfc-pot feature while the
2413 south-bound renderer is enabled via the odl-sfc-pot-netconf-renderer
2414 feature. For the purposes of SFC PoT handling, both features must be
2417 RPC handlers to augment the RSP are part of ``SfcPotRpc`` while the
2418 RSP augmentation to enable or disable SFC PoT feature is done via
2419 ``SfcPotRspProcessor``.
2422 SFC Proof of Transit entities
2423 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2425 In order to implement SFC Proof of Transit for a service function chain,
2426 an RSP is a pre-requisite to identify the SFC to enable SFC PoT on. SFC
2427 Proof of Transit for a particular RSP is enabled by an RPC request to
2428 the controller along with necessary parameters to control some of the
2429 aspects of the SFC Proof of Transit process.
2431 The RPC handler identifies the RSP and adds PoT feature meta-data like
2432 enable/disable, number of PoT profiles, profiles refresh parameters etc.,
2433 that directs the south-bound renderer appropriately when RSP changes
2434 are noticed via call-backs in the renderer handlers.
2436 Administering SFC Proof of Transit
2437 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2439 To use the SFC Proof of Transit Karaf, at least the following Karaf
2440 features must be installed:
2450 - odl-netconf-topology
2452 - odl-netconf-connector-all
2456 Please note that the odl-sfc-pot-netconf-renderer or other renderers in future
2457 must be installed for the feature to take full-effect. The details of the renderer
2458 features are described in other parts of this document.
2460 SFC Proof of Transit Tutorial
2461 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2466 This tutorial is a simple example how to configure Service Function
2467 Chain Proof of Transit using SFC POT feature.
2472 To enable a device to handle SFC Proof of Transit, it is expected that
2473 the NETCONF node device advertise capability as under ioam-sb-pot.yang
2474 present under sfc-model/src/main/yang folder. It is also expected that base
2475 NETCONF support be enabled and its support capability advertised as capabilities.
2477 NETCONF support:``urn:ietf:params:netconf:base:1.0``
2479 PoT support: ``(urn:cisco:params:xml:ns:yang:sfc-ioam-sb-pot?revision=2017-01-12)sfc-ioam-sb-pot``
2481 It is also expected that the devices are netconf mounted and available
2482 in the topology-netconf store.
2487 When SFC Proof of Transit is installed, all netconf nodes in topology-netconf
2488 are processed and all capable nodes with accessible mountpoints are cached.
2490 First step is to create the required RSP as is usually done using RSP creation
2493 Once RSP name is available it is used to send a POST RPC to the
2494 controller similar to below:
2497 http://ODL-IP:8181/restconf/operations/sfc-ioam-nb-pot:enable-sfc-ioam-pot-rendered-path/
2499 .. code-block:: json
2504 "sfc-ioam-pot-rsp-name": "sfc-path-3sf3sff",
2505 "ioam-pot-enable":true,
2506 "ioam-pot-num-profiles":2,
2507 "ioam-pot-bit-mask":"bits32",
2508 "refresh-period-time-units":"milliseconds",
2509 "refresh-period-value":5000
2513 The following can be used to disable the SFC Proof of Transit on an RSP
2514 which disables the PoT feature.
2517 http://ODL-IP:8181/restconf/operations/sfc-ioam-nb-pot:disable-sfc-ioam-pot-rendered-path/
2519 .. code-block:: json
2524 "sfc-ioam-pot-rsp-name": "sfc-path-3sf3sff",
2528 SFC PoT NETCONF Renderer User Guide
2529 -----------------------------------
2534 The SFC Proof of Transit (PoT) NETCONF renderer implements SFC Proof of
2535 Transit functionality on NETCONF-capable devices, that have advertised
2536 support for in-situ OAM (iOAM) support.
2538 It listens for an update to an existing RSP with enable or disable proof of
2539 transit support and adds the auto-generated SFC PoT configuration parameters
2540 to all the SFC hop nodes. The last node in the SFC is configured as a
2541 verifier node to allow SFC PoT process to be completed.
2543 Common acronyms are used as below:
2545 - SF - Service Function
2547 - SFC - Service Function Chain
2549 - RSP - Rendered Service Path
2551 - SFF - Service Function Forwarder
2554 Mapping to SFC entities
2555 ~~~~~~~~~~~~~~~~~~~~~~~
2557 The renderer module listens to RSP updates in ``SfcPotNetconfRSPListener``
2558 and triggers configuration generation in ``SfcPotNetconfIoam`` class. Node
2559 arrival and leaving are managed via ``SfcPotNetconfNodeManager`` and
2560 ``SfcPotNetconfNodeListener``. In addition there is a timer thread that
2561 runs to generate configuration periodically to refresh the profiles in the
2562 nodes that are part of the SFC.
2565 Administering SFC PoT NETCONF Renderer
2566 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2568 To use the SFC Proof of Transit Karaf, the following Karaf features must
2579 - odl-netconf-topology
2581 - odl-netconf-connector-all
2585 - odl-sfc-pot-netconf-renderer
2588 SFC PoT NETCONF Renderer Tutorial
2589 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2594 This tutorial is a simple example how to enable SFC PoT on NETCONF-capable
2600 The NETCONF-capable device will have to support sfc-ioam-sb-pot.yang file.
2602 It is expected that a NETCONF-capable VPP device has Honeycomb (Hc2vpp)
2603 Java-based agent that helps to translate between NETCONF and VPP internal
2606 More details are here:
2607 In-situ OAM: https://github.com/CiscoDevNet/iOAM
2611 When the SFC PoT NETCONF renderer module is installed, all NETCONF nodes in
2612 topology-netconf are processed and all sfc-ioam-sb-pot yang capable nodes
2613 with accessible mountpoints are cached.
2615 The first step is to create RSP for the SFC as per SFC guidelines above.
2617 Enable SFC PoT is done on the RSP via RESTCONF to the ODL as outlined above.
2619 Internally, the NETCONF renderer will act on the callback to a modified RSP
2620 that has PoT enabled.
2622 In-situ OAM algorithms for auto-generation of SFC PoT parameters are
2623 generated automatically and sent to these nodes via NETCONF.
2625 Logical Service Function Forwarder
2626 ----------------------------------
2631 .. _sfc-user-guide-logical-sff-motivation:
2635 When the current SFC is deployed in a cloud environment, it is assumed that each
2636 switch connected to a Service Function is configured as a Service Function
2637 Forwarder and each Service Function is connected to its Service Function
2638 Forwarder depending on the Compute Node where the Virtual Machine is located.
2640 .. figure:: ./images/sfc/sfc-in-cloud.png
2641 :alt: Deploying SFC in Cloud Environments
2643 As shown in the picture above, this solution allows the basic cloud use cases to
2644 be fulfilled, as for example, the ones required in OPNFV Brahmaputra, however,
2645 some advanced use cases like the transparent migration of VMs can not be
2646 implemented. The Logical Service Function Forwarder enables the following
2649 1. Service Function mobility without service disruption
2650 2. Service Functions load balancing and failover
2652 As shown in the picture below, the Logical Service Function Forwarder concept
2653 extends the current SFC northbound API to provide an abstraction of the
2654 underlying Data Center infrastructure. The Data Center underlaying network can
2655 be abstracted by a single SFF. This single SFF uses the logical port UUID as
2656 data plane locator to connect SFs globally and in a location-transparent manner.
2657 SFC makes use of `Genius <./genius-user-guide.html>`__ project to track the
2658 location of the SF's logical ports.
2660 .. figure:: ./images/sfc/single-logical-sff-concept.png
2661 :alt: Single Logical SFF concept
2663 The SFC internally distributes the necessary flow state over the relevant
2664 switches based on the internal Data Center topology and the deployment of SFs.
2666 Changes in data model
2667 ~~~~~~~~~~~~~~~~~~~~~
2668 The Logical Service Function Forwarder concept extends the current SFC
2669 northbound API to provide an abstraction of the underlying Data Center
2672 The Logical SFF simplifies the configuration of the current SFC data model by
2673 reducing the number of parameters to be be configured in every SFF, since the
2674 controller will discover those parameters by interacting with the services
2675 offered by the `Genius <./genius-user-guide.html>`__ project.
2677 The following picture shows the Logical SFF data model. The model gets
2678 simplified as most of the configuration parameters of the current SFC data model
2679 are discovered in runtime. The complete YANG model can be found here
2680 `logical SFF model <https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/service-function-forwarder-logical.yang>`__.
2682 .. figure:: ./images/sfc/logical-sff-datamodel.png
2683 :alt: Logical SFF data model
2685 How to configure the Logical SFF
2686 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2687 The following are examples to configure the Logical SFF:
2689 .. code-block:: bash
2691 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
2692 --data '${JSON}' -X PUT --user
2693 admin:admin http://localhost:8181/restconf/config/restconf/config/service-function:service-functions/
2695 **Service Functions JSON.**
2697 .. code-block:: json
2700 "service-functions": {
2701 "service-function": [
2703 "name": "firewall-1",
2705 "sf-data-plane-locator": [
2707 "name": "firewall-dpl",
2708 "interface-name": "eccb57ae-5a2e-467f-823e-45d7bb2a6a9a",
2709 "transport": "service-locator:eth-nsh",
2710 "service-function-forwarder": "sfflogical1"
2718 "sf-data-plane-locator": [
2721 "interface-name": "df15ac52-e8ef-4e9a-8340-ae0738aba0c0",
2722 "transport": "service-locator:eth-nsh",
2723 "service-function-forwarder": "sfflogical1"
2731 .. code-block:: bash
2733 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
2734 --data '${JSON}' -X PUT --user
2735 admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/
2737 **Service Function Forwarders JSON.**
2739 .. code-block:: json
2742 "service-function-forwarders": {
2743 "service-function-forwarder": [
2745 "name": "sfflogical1"
2751 .. code-block:: bash
2753 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
2754 --data '${JSON}' -X PUT --user
2755 admin:admin http://localhost:8181/restconf/config/service-function-chain:service-function-chains/
2757 **Service Function Chains JSON.**
2759 .. code-block:: json
2762 "service-function-chains": {
2763 "service-function-chain": [
2766 "sfc-service-function": [
2768 "name": "dpi-abstract1",
2772 "name": "firewall-abstract1",
2779 "sfc-service-function": [
2781 "name": "dpi-abstract1",
2790 .. code-block:: bash
2792 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
2793 --data '${JSON}' -X PUT --user
2794 admin:admin http://localhost:8182/restconf/config/service-function-chain:service-function-paths/
2796 **Service Function Paths JSON.**
2798 .. code-block:: json
2801 "service-function-paths": {
2802 "service-function-path": [
2805 "service-chain-name": "SFC1",
2806 "starting-index": 255,
2807 "symmetric": "true",
2808 "context-metadata": "NSH1",
2809 "transport-type": "service-locator:vxlan-gpe"
2816 As a result of above configuration, OpenDaylight renders the needed flows in all involved SFFs. Those flows implement:
2818 - Two Rendered Service Paths:
2820 - dpi-1 (SF1), firewall-1 (SF2)
2821 - firewall-1 (SF2), dpi-1 (SF1)
2823 - The communication between SFFs and SFs based on eth-nsh
2825 - The communication between SFFs based on vxlan-gpe
2827 The following picture shows a topology and traffic flow (in green) which corresponds to the above configuration.
2829 .. figure:: ./images/sfc/single-logical-sff-example.png
2830 :alt: Logical SFF Example
2837 The Logical SFF functionality allows OpenDaylight to find out the SFFs holding
2838 the SFs involved in a path. In this example the SFFs affected are Node3 and
2839 Node4 thus the controller renders the flows containing NSH parameters just in
2842 Here you have the new flows rendered in Node3 and Node4 which implement the NSH
2843 protocol. Every Rendered Service Path is represented by an NSP value. We
2844 provisioned a symmetric RSP so we get two NSPs: 8388613 and 5. Node3 holds the
2845 first SF of NSP 8388613 and the last SF of NSP 5. Node 4 holds the first SF of
2846 NSP 5 and the last SF of NSP 8388613. Both Node3 and Node4 will pop the NSH
2847 header when the received packet has gone through the last SF of its path.
2849 **Rendered flows Node 3**
2853 cookie=0x14, duration=59.264s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
2854 cookie=0x14, duration=59.194s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
2855 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
2856 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
2857 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)
2858 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)
2859 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)
2860 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
2862 **Rendered Flows Node 4**
2866 cookie=0x14, duration=69.040s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
2867 cookie=0x14, duration=69.008s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
2868 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
2869 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
2870 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)
2871 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
2872 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)
2873 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)
2876 An interesting scenario to show the Logical SFF strength is the migration of a
2877 SF from a compute node to another. The OpenDaylight will learn the new topology
2878 by itself, then it will re-render the new flows to the new SFFs affected.
2880 .. figure:: ./images/sfc/single-logical-sff-example-migration.png
2881 :alt: Logical SFF - SF Migration Example
2885 Logical SFF - SF Migration Example
2888 In our example, SF2 is moved from Node4 to Node2 then OpenDaylight removes NSH
2889 specific flows from Node4 and puts them in Node2. Check below flows showing this
2890 effect. Now Node3 keeps holding the first SF of NSP 8388613 and the last SF of
2891 NSP 5; but Node2 becomes the new holder of the first SF of NSP 5 and the last SF
2894 **Rendered Flows Node 3 After Migration**
2898 cookie=0x14, duration=64.044s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
2899 cookie=0x14, duration=63.947s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
2900 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
2901 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
2902 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)
2903 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)
2904 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)
2905 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
2907 **Rendered Flows Node 2 After Migration**
2911 cookie=0x14, duration=56.856s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
2912 cookie=0x14, duration=56.755s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
2913 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
2914 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
2915 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)
2916 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
2917 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)
2918 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)
2920 **Rendered Flows Node 4 After Migration**
2924 -- No flows for NSH processing --
2926 .. _sfc-user-guide-classifier-impacts:
2931 As previously mentioned, in the :ref:`Logical SFF rationale
2932 <sfc-user-guide-logical-sff-motivation>`, the Logical SFF feature relies on
2933 Genius to get the dataplane IDs of the OpenFlow switches, in order to properly
2934 steer the traffic through the chain.
2936 Since one of the classifier's objectives is to steer the packets *into* the
2937 SFC domain, the classifier has to be aware of where the first Service
2938 Function is located - if it migrates somewhere else, the classifier table
2939 has to be updated accordingly, thus enabling the seemless migration of Service
2942 For this feature, mobility of the client VM is out of scope, and should be
2943 managed by its high-availability module, or VNF manager.
2945 Keep in mind that classification *always* occur in the compute-node where
2946 the client VM (i.e. traffic origin) is running.
2948 How to attach the classifier to a Logical SFF
2949 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2951 In order to leverage this functionality, the classifier has to be configured
2952 using a Logical SFF as an attachment-point, specifying within it the neutron
2955 The following examples show how to configure an ACL, and a classifier having
2956 a Logical SFF as an attachment-point:
2958 **Configure an ACL**
2960 The following ACL enables traffic intended for port 80 within the subnetwork
2961 192.168.2.0/24, for RSP1 and RSP1-Reverse.
2963 .. code-block:: json
2970 "acl-type": "ietf-access-control-list:ipv4-acl",
2971 "access-list-entries": {
2974 "rule-name": "ACE1",
2976 "service-function-acl:rendered-service-path": "RSP1"
2979 "destination-ipv4-network": "192.168.2.0/24",
2980 "source-ipv4-network": "192.168.2.0/24",
2982 "source-port-range": {
2985 "destination-port-range": {
2995 "acl-type": "ietf-access-control-list:ipv4-acl",
2996 "access-list-entries": {
2999 "rule-name": "ACE2",
3001 "service-function-acl:rendered-service-path": "RSP1-Reverse"
3004 "destination-ipv4-network": "192.168.2.0/24",
3005 "source-ipv4-network": "192.168.2.0/24",
3007 "source-port-range": {
3010 "destination-port-range": {
3022 .. code-block:: bash
3024 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
3025 --data '${JSON}' -X PUT --user
3026 admin:admin http://localhost:8181/restconf/config/ietf-access-control-list:access-lists/
3028 **Configure a classifier JSON**
3030 The following JSON provisions a classifier, having a Logical SFF as an
3031 attachment point. The value of the field 'interface' is where you
3032 indicate the neutron ports of the VMs you want to classify.
3034 .. code-block:: json
3037 "service-function-classifiers": {
3038 "service-function-classifier": [
3040 "name": "Classifier1",
3041 "scl-service-function-forwarder": [
3043 "name": "sfflogical1",
3044 "interface": "09a78ba3-78ba-40f5-a3ea-1ce708367f2b"
3049 "type": "ietf-access-control-list:ipv4-acl"
3056 .. code-block:: bash
3058 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
3059 --data '${JSON}' -X PUT --user
3060 admin:admin http://localhost:8181/restconf/config/service-function-classifier:service-function-classifiers/
3062 .. _sfc-user-guide-pipeline-impacts:
3064 SFC pipeline impacts
3065 ~~~~~~~~~~~~~~~~~~~~
3067 After binding SFC service with a particular interface by means of Genius, as
3068 explained in the :ref:`Genius User Guide <genius-user-guide-binding-services>`,
3069 the entry point in the SFC pipeline will be table 82
3070 (SFC_TRANSPORT_CLASSIFIER_TABLE), and from that point, packet processing will be
3071 similar to the :ref:`SFC OpenFlow pipeline <sfc-user-guide-sfc-of-pipeline>`,
3072 just with another set of specific tables for the SFC service.
3074 This picture shows the SFC pipeline after service integration with Genius:
3076 .. figure:: ./images/sfc/LSFF_pipeline.png
3077 :alt: SFC Logical SFF OpenFlow pipeline
3079 SFC Logical SFF OpenFlow pipeline
3081 Directional data plane locators for symmetric paths
3082 ---------------------------------------------------
3087 A symmetric path results from a Service Function Path with the symmetric field
3088 set or when any of the constituent Service Functions is set as bidirectional.
3089 Such a path is defined by two Rendered Service Paths where one of them steers
3090 the traffic through the same Service Functions as the other but in opposite
3091 order. These two Rendered Service Paths are also said to be symmetric to each
3092 other and gives to each path a sense of direction: The Rendered Service Path
3093 that corresponds to the same order of Service Functions as that defined on the
3094 Service Function Chain is tagged as the forward or up-link path, while the
3095 Rendered Service Path that corresponds to the opposite order is tagged as
3096 reverse or down-link path.
3098 Directional data plane locators allow the use of different interfaces or
3099 interface details between the Service Function Forwarder and the Service
3100 Function in relation with the direction of the path for which they are being
3101 used. This function is relevant for Service Functions that would have no other
3102 way of discerning the direction of the traffic, like for example legacy
3103 bump-in-the-wire network devices.
3107 +-----------------------------------------------+
3112 | sf-forward-dpl sf-reverse-dpl |
3113 +--------+-----------------------------+--------+
3119 Forward Path | Reverse Path Forward Path | Reverse Path
3126 +-----------+-----------------------------------------+
3127 Forward Path | sff-forward-dpl sff-reverse-dpl | Forward Path
3128 +--------------> | | +-------------->
3132 <--------------+ | | <--------------+
3133 Reverse Path | | Reverse Path
3134 +-----------------------------------------------------+
3136 As shown in the previous figure, the forward path egress from the Service
3137 Function Forwarder towards the Service Function is defined by the
3138 sff-forward-dpl and sf-forward-dpl data plane locators. The forward path
3139 ingress from the Service Function to the Service Function Forwarder is defined
3140 by the sf-reverse-dpl and sff-reverse-dpl data plane locators. For the reverse
3141 path, it's the opposite: the sff-reverse-dpl and sf-reverse-dpl define the
3142 egress from the Service Function Forwarder to the Service Function, and the
3143 sf-forward-dpl and sff-forward-dpl define the ingress into the Service Function
3144 Forwarder from the Service Function.
3146 .. note:: Directional data plane locators are only supported in combination
3147 with the SFC OF Renderer at this time.
3152 Directional data plane locators are configured within the
3153 service-function-forwarder in the service-function-dictionary entity, which
3154 describes the association between a Service Function Forwarder and Service
3157 .. code-block:: service-function-forwarder.yang
3159 list service-function-dictionary {
3162 type sfc-common:sf-name;
3164 "The name of the service function.";
3166 container sff-sf-data-plane-locator {
3168 "SFF and SF data plane locators to use when sending
3169 packets from this SFF to the associated SF";
3171 type sfc-common:sf-data-plane-locator-name;
3173 "The SF data plane locator to use when sending
3174 packets to the associated service function.
3175 Used both as forward and reverse locators for
3176 paths of a symmetric chain.";
3179 type sfc-common:sff-data-plane-locator-name;
3181 "The SFF data plane locator to use when sending
3182 packets to the associated service function.
3183 Used both as forward and reverse locators for
3184 paths of a symmetric chain.";
3186 leaf sf-forward-dpl-name {
3187 type sfc-common:sf-data-plane-locator-name;
3189 "The SF data plane locator to use when sending
3190 packets to the associated service function
3191 on the forward path of a symmetric chain";
3193 leaf sf-reverse-dpl-name {
3194 type sfc-common:sf-data-plane-locator-name;
3196 "The SF data plane locator to use when sending
3197 packets to the associated service function
3198 on the reverse path of a symmetric chain";
3200 leaf sff-forward-dpl-name {
3201 type sfc-common:sff-data-plane-locator-name;
3203 "The SFF data plane locator to use when sending
3204 packets to the associated service function
3205 on the forward path of a symmetric chain.";
3207 leaf sff-reverse-dpl-name {
3208 type sfc-common:sff-data-plane-locator-name;
3210 "The SFF data plane locator to use when sending
3211 packets to the associated service function
3212 on the reverse path of a symmetric chain.";
3220 The following configuration example is based on the Logical SFF configuration
3221 one. Only the Service Function and Service Function Forwarder configuration
3222 changes with respect to that example:
3224 .. code-block:: bash
3226 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
3227 --data '${JSON}' -X PUT --user
3228 admin:admin http://localhost:8181/restconf/config/restconf/config/service-function:service-functions/
3230 **Service Functions JSON.**
3232 .. code-block:: json
3235 "service-functions": {
3236 "service-function": [
3238 "name": "firewall-1",
3240 "sf-data-plane-locator": [
3242 "name": "sf-firewall-net-A-dpl",
3243 "interface-name": "eccb57ae-5a2e-467f-823e-45d7bb2a6a9a",
3244 "transport": "service-locator:mac",
3245 "service-function-forwarder": "sfflogical1"
3249 "name": "sf-firewall-net-B-dpl",
3250 "interface-name": "7764b6f1-a5cd-46be-9201-78f917ddee1d",
3251 "transport": "service-locator:mac",
3252 "service-function-forwarder": "sfflogical1"
3260 "sf-data-plane-locator": [
3262 "name": "sf-dpi-net-A-dpl",
3263 "interface-name": "df15ac52-e8ef-4e9a-8340-ae0738aba0c0",
3264 "transport": "service-locator:mac",
3265 "service-function-forwarder": "sfflogical1"
3268 "name": "sf-dpi-net-B-dpl",
3269 "interface-name": "1bb09b01-422d-4ccf-8d7a-9ebf00d1a1a5",
3270 "transport": "service-locator:mac",
3271 "service-function-forwarder": "sfflogical1"
3279 .. code-block:: bash
3281 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
3282 --data '${JSON}' -X PUT --user
3283 admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/
3285 **Service Function Forwarders JSON.**
3287 .. code-block:: json
3290 "service-function-forwarders": {
3291 "service-function-forwarder": [
3293 "name": "sfflogical1"
3294 "sff-data-plane-locator": [
3296 "name": "sff-firewall-net-A-dpl",
3297 "data-plane-locator": {
3298 "interface-name": "eccb57ae-5a2e-467f-823e-45d7bb2a6a9a",
3299 "transport": "service-locator:mac"
3303 "name": "sff-firewall-net-B-dpl",
3304 "data-plane-locator": {
3305 "interface-name": "7764b6f1-a5cd-46be-9201-78f917ddee1d",
3306 "transport": "service-locator:mac"
3310 "name": "sff-dpi-net-A-dpl",
3311 "data-plane-locator": {
3312 "interface-name": "df15ac52-e8ef-4e9a-8340-ae0738aba0c0",
3313 "transport": "service-locator:mac"
3317 "name": "sff-dpi-net-B-dpl",
3318 "data-plane-locator": {
3319 "interface-name": "1bb09b01-422d-4ccf-8d7a-9ebf00d1a1a5",
3320 "transport": "service-locator:mac"
3324 "service-function-dictionary": [
3326 "name": "firewall-1",
3327 "sff-sf-data-plane-locator": {
3328 "sf-forward-dpl-name": "sf-firewall-net-A-dpl",
3329 "sf-reverse-dpl-name": "sf-firewall-net-B-dpl",
3330 "sff-forward-dpl-name": "sff-firewall-net-A-dpl",
3331 "sff-reverse-dpl-name": "sff-firewall-net-B-dpl",
3336 "sff-sf-data-plane-locator": {
3337 "sf-forward-dpl-name": "sf-dpi-net-A-dpl",
3338 "sf-reverse-dpl-name": "sf-dpi-net-B-dpl",
3339 "sff-forward-dpl-name": "sff-dpi-net-A-dpl",
3340 "sff-reverse-dpl-name": "sff-dpi-net-B-dpl",
3349 In comparison with the Logical SFF example, noticed that each Service Function
3350 is configured with two data plane locators instead of one so that each can be
3351 used in different directions of the path. To specify which locator is used on
3352 which direction, the Service Function Forwarder configuration is also more
3353 extensive compared to the previous example.
3355 When comparing this example with the Logical SFF one, that the Service Function
3356 Forwarder is configured with data plane locators and that they hold the same
3357 interface name values as the corresponding Service Function interfaces. This is
3358 because in the Logical SFF particular case, a single logical interface fully
3359 describes an attachment of a Service Function Forwarder to a Service Function
3360 on both the Service Function and Service Function Forwarder sides. For
3361 non-Logical SFF scenarios, it would be expected for the data plane locators to
3362 have different values as we have seen on other examples through out this user
3363 guide. For example, if mac addresses are to be specified in the locators, the
3364 Service Function would have a different mac address than the Service Function
3368 As a result of the overall configuration, two Rendered Service Paths are
3369 implemented. The forward path:
3373 +------------+ +-------+
3374 | firewall-1 | | dpi- 1 |
3375 +---+---+----+ +--+--+-+
3377 net-A-dpl| |net-B-dpl net-A-dpl| |net-B-dpl
3379 +----------+ | | | | +----------+
3380 | client A +--------------+ +------------------------+ +------------>+ server B |
3381 +----------+ +----------+
3383 And the reverse path:
3387 +------------+ +-------+
3388 | firewall 1 | | dpi-1 |
3389 +---+---+----+ +--+--+-+
3391 net-A-dpl| |net-B-dpl net-A-dpl| |net-B-dpl
3393 +----------+ | | | | +----------+
3394 | client A +<-------------+ +------------------------+ +-------------+ server B |
3395 +----------+ +----------+
3397 Consider the following notes to put the example in context:
3399 - The classification function is obviated from the illustration.
3400 - The forward path is up-link traffic from a client in network A to a server in
3402 - The reverse path is down-link traffic from a server in network B to a client
3404 - The service functions might be legacy bump-in-the-wire network devices that
3405 need to use different interfaces for each network.
3407 SFC Statistics User Guide
3408 -------------------------
3410 Statistics can be queried for Rendered Service Paths created on OVS bridges.
3411 Future support will be added for Service Function Forwarders and Service
3412 Functions. Future support will also be added for VPP and IOs-XE devices.
3414 To use SFC statistics the 'odl-sfc-statistics' Karaf feature needs to be
3417 Statistics are queried by sending an RPC RESTconf message to ODL. For
3418 RSPs, its possible to either query statistics for one individual RSP
3419 or for all RSPs, as follows:
3421 Querying statistics for a specific RSP:
3423 .. code-block:: bash
3425 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
3426 --data '{ "input": { "name" : "path1-Path-42" } }' -X POST --user admin:admin
3427 http://localhost:8181/restconf/operations/sfc-statistics-operations:get-rsp-statistics
3430 Querying statistics for all RSPs:
3432 .. code-block:: bash
3434 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
3435 --data '{ "input": { } }' -X POST --user admin:admin
3436 http://localhost:8181/restconf/operations/sfc-statistics-operations:get-rsp-statistics
3439 The following is the sort of output that can be expected for each RSP.
3441 .. code-block:: json
3447 "name": "sfc-path-1sf1sff-Path-34",
3448 "statistic-by-timestamp": [
3450 "service-statistic": {
3456 "timestamp": 1518561500480
Code Review / docs.git / blob