SFC User Interface (SFC-UI) is based on Dlux project. It provides an
easy way to create, read, update and delete configuration stored in
-Datastore. Moreover, it shows the status of all SFC features (e.g
+datastore. Moreover, it shows the status of all SFC features (e.g
installed, uninstalled) and Karaf log messages as well.
SFC-UI Architecture
1. Run ODL distribution (run karaf)
-2. In karaf console execute: ``feature:install odl-sfc-ui``
+2. In Karaf console execute: ``feature:install odl-sfc-ui``
3. Visit SFC-UI on: ``http://<odl_ip_address>:8181/sfc/index.html``
-SFC Southbound REST Plugin
+SFC Southbound REST Plug-in
--------------------------
Overview
~~~~~~~~
-The Southbound REST Plugin is used to send configuration from DataStore
+The Southbound REST Plug-in is used to send configuration from datastore
down to network devices supporting a REST API (i.e. they have a
configured REST URI). It supports POST/PUT/DELETE operations, which are
triggered accordingly by changes in the SFC data stores.
- Service Function Schedule Type (SFST)
-- Service Function Forwader (SFF)
+- Service Function Forwarder (SFF)
- Rendered Service Path (RSP)
-Southbound REST Plugin Architecture
+Southbound REST Plug-in Architecture
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-From the user perspective, the REST plugin is another SFC Southbound
-plugin used to communicate with network devices.
+From the user perspective, the REST plug-in is another SFC Southbound
+plug-in used to communicate with network devices.
.. figure:: ./images/sfc/sb-rest-architecture-user.png
- :alt: Soutbound REST Plugin integration into ODL
+ :alt: Southbound REST Plug-in integration into ODL
- Soutbound REST Plugin integration into ODL
+ Southbound REST Plug-in integration into ODL
Configuring Southbound REST Plugin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Run ODL distribution (run karaf)
-2. In karaf console execute: ``feature:install odl-sfc-sb-rest``
+2. In Karaf console execute: ``feature:install odl-sfc-sb-rest``
3. Configure REST URIs for SF/SFF through SFC User Interface or RESTCONF
(required configuration steps can be found in the tutorial stated
Tutorial
~~~~~~~~
-Comprehensive tutorial on how to use the Southbound REST Plugin and how
+Comprehensive tutorial on how to use the Southbound REST Plug-in and how
to control network devices with it can be found on:
https://wiki.opendaylight.org/view/Service_Function_Chaining:Main#SFC_101
Classifier, etc.) to OVS objects (like Bridge,
TerminationPoint=Port/Interface). The mapping takes care of automatic
instantiation (setup) of corresponding object whenever its counterpart
-is created. For example, when a new SFF is created, the SFC-OVS plugin
+is created. For example, when a new SFF is created, the SFC-OVS plug-in
will create a new OVS bridge and when a new OVS Bridge is created, the
-SFC-OVS plugin will create a new SFF.
+SFC-OVS plug-in will create a new SFF.
The feature is intended for SFC users willing to use Open vSwitch as
underlying network infrastructure for deploying RSPs (Rendered Service
SFC-OVS uses the OVSDB MD-SAL Southbound API for getting/writing
information from/to OVS devices. From the user perspective SFC-OVS acts
-as a layer between SFC DataStore and OVSDB.
+as a layer between SFC datastore and OVSDB.
.. figure:: ./images/sfc/sfc-ovs-architecture-user.png
:alt: SFC-OVS integration into ODL
1. Run ODL distribution (run karaf)
-2. In karaf console execute: ``feature:install odl-sfc-ovs``
+2. In Karaf console execute: ``feature:install odl-sfc-ovs``
3. Configure Open vSwitch to use ODL as a manager, using following
command: ``ovs-vsctl set-manager tcp:<odl_ip_address>:6640``
Overview
''''''''
-This tutorial shows the usual workflow when OVS configuration is
+This tutorial shows the usual work flow when OVS configuration is
transformed to corresponding SFC objects (in this case SFF).
-Prerequisities
+Prerequisites
''''''''''''''
- Open vSwitch installed (ovs-vsctl command available in shell)
This tutorial shows the usual workflow during creation of OVS Bridge
with use of SFC APIs.
-Prerequisities
+Prerequisites
''''''''''''''
- Open vSwitch installed (ovs-vsctl command available in shell)
2. SFF data plane locator must be configured
-3. Classifier interface must be mannually added to SFF bridge.
+3. Classifier interface must be manually added to SFF bridge.
Administering or Managing Classifier
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Rules are created using appropriate iptables command. If the Access
Control Entry (ACE) rule is MAC address related both iptables and
-ip6tabeles rules re issued. If ACE rule is IPv4 address related, only
+IPv6 tables rules re issued. If ACE rule is IPv4 address related, only
iptables rules are issued, same for IPv6.
.. note::
Administering or Managing Classifier
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Classfier runs alongside sfc\_agent, therefore the commad for starting
+Classifier runs alongside sfc\_agent, therefore the command for starting
it locally is:
::
SFC OpenFlow Renderer High Level Architecture
+.. _sfc-user-guide-sfc-of-pipeline:
+
SFC OpenFlow Switch Flow pipeline
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here are two examples on SFF1. RSP Paths 1 and 2 are symmetric MPLS
paths that use VLAN for the SFF-SF. RSP Paths 3 and 4 are symmetric NSH
paths. Since it is assumed that switches used for NSH will only have one
-VXLANport, the NSH packets are just sent back where they came from.
+VXLAN port, the NSH packets are just sent back where they came from.
+----------+--------------------------------+--------------------------------+
| Priority | Match | Action |
In all the following configuration sections, replace the ``${JSON}``
string with the appropriate JSON configuration. Also, change the
-``localhost`` desintation in the URL accordingly.
+``localhost`` destination in the URL accordingly.
SFC OF Renderer NSH Tutorial
''''''''''''''''''''''''''''
}
}
-The depolyed topology like this:
+The deployed topology like this:
::
First step is to create the required RSP as usually done.
-Once RSP name is avaiable it is used to send a POST RPC to the
+Once RSP name is available it is used to send a POST RPC to the
controller similar to below:
::
}
}
+Logical Service Function Forwarder
+----------------------------------
+
+Overview
+~~~~~~~~
+
+.. _sfc-user-guide-logical-sff-motivation:
+
+Rationale
+^^^^^^^^^
+When the current SFC is deployed in a cloud environment, it is assumed that each
+switch connected to a Service Function is configured as a Service Function Forwarder and
+each Service Function is connected to its Service Function Forwarder depending on the
+Compute Node where the Virtual Machine is located.
+
+.. figure:: ./images/sfc/sfc-in-cloud.png
+ :alt: Deploying SFC in Cloud Environments
+
+As shown in the picture above, this solution allows the basic cloud use cases to be fulfilled,
+as for example, the ones required in OPNFV Brahmaputra, however, some advanced use cases
+like the transparent migration of VMs can not be implemented. The Logical Service Function Forwarder
+enables the following advanced use cases:
+
+1. Service Function mobility without service disruption
+2. Service Functions load balancing and failover
+
+As shown in the picture below, the Logical Service Function Forwarder concept extends the current
+SFC northbound API to provide an abstraction of the underlying Data Center infrastructure.
+The Data Center underlaying network can be abstracted by a single SFF. This single SFF uses
+the logical port UUID as data plane locator to connect SFs globally and in a location-transparent manner.
+SFC makes use of `Genius <./genius-user-guide.html>`__ project to track the
+location of the SF's logical ports.
+
+.. figure:: ./images/sfc/single-logical-sff-concept.png
+ :alt: Single Logical SFF concept
+
+The SFC internally distributes the necessary flow state over the relevant switches based on the
+internal Data Center topology and the deployment of SFs.
+
+Changes in data model
+~~~~~~~~~~~~~~~~~~~~~
+The Logical Service Function Forwarder concept extends the current SFC northbound API to provide
+an abstraction of the underlying Data Center infrastructure.
+
+The Logical SFF simplifies the configuration of the current SFC data model by reducing the number
+of parameters to be be configured in every SFF, since the controller will discover those parameters
+by interacting with the services offered by the `Genius <./genius-user-guide.html>`__ project.
+
+The following picture shows the Logical SFF data model. The model gets simplified as most of the
+configuration parameters of the current SFC data model are discovered in runtime. The complete
+YANG model can be found here `logical SFF model
+<https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/service-function-forwarder-logical.yang>`__.
+
+.. figure:: ./images/sfc/logical-sff-datamodel.png
+ :alt: Logical SFF data model
+
+How to configure the Logical SFF
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The following are examples to configure the Logical SFF:
+::
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/restconf/config/service-function:service-functions/
+
+**Service Functions JSON.**
+
+::
+
+ {
+ "service-functions": {
+ "service-function": [
+ {
+ "name": "firewall-1",
+ "type": "firewall",
+ "nsh-aware": "true",
+ "sf-data-plane-locator": [
+ {
+ "name": "firewall-dpl",
+ "interface-name": "eccb57ae-5a2e-467f-823e-45d7bb2a6a9a",
+ "transport": "service-locator:eth-nsh",
+ "service-function-forwarder": "sfflogical1"
+
+ }
+ ]
+ },
+ {
+ "name": "dpi-1",
+ "type": "dpi",
+ "nsh-aware": "true",
+ "sf-data-plane-locator": [
+ {
+ "name": "dpi-dpl",
+ "interface-name": "df15ac52-e8ef-4e9a-8340-ae0738aba0c0",
+ "transport": "service-locator:eth-nsh",
+ "service-function-forwarder": "sfflogical1"
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+::
+
+ 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/
+
+**Service Function Forwarders JSON.**
+
+::
+
+ {
+ "service-function-forwarders": {
+ "service-function-forwarder": [
+ {
+ "name": "sfflogical1"
+ }
+ ]
+ }
+ }
+
+::
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-chain:service-function-chains/
+
+**Service Function Chains JSON.**
+
+::
+
+ {
+ "service-function-chains": {
+ "service-function-chain": [
+ {
+ "name": "SFC1",
+ "symmetric": "true",
+ "sfc-service-function": [
+ {
+ "name": "dpi-abstract1",
+ "type": "dpi"
+ },
+ {
+ "name": "firewall-abstract1",
+ "type": "firewall"
+ }
+ ]
+ },
+ {
+ "name": "SFC2",
+ "symmetric": "true",
+ "sfc-service-function": [
+ {
+ "name": "dpi-abstract1",
+ "type": "dpi"
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+::
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8182/restconf/config/service-function-chain:service-function-paths/
+
+**Service Function Paths JSON.**
+
+::
+
+ {
+ "service-function-paths": {
+ "service-function-path": [
+ {
+ "name": "SFP1",
+ "service-chain-name": "SFC1",
+ "starting-index": 255,
+ "symmetric": "true",
+ "context-metadata": "NSH1",
+ "transport-type": "service-locator:vxlan-gpe"
+
+ }
+ ]
+ }
+ }
+
+As a result of above configuration, OpenDaylight renders the needed flows in all involved SFFs. Those flows implement:
+
+- Two Rendered Service Paths:
+
+ - dpi-1 (SF1), firewall-1 (SF2)
+ - firewall-1 (SF2), dpi-1 (SF1)
+
+- The communication between SFFs and SFs based on eth-nsh
+
+- The communication between SFFs based on vxlan-gpe
+
+The following picture shows a topology and traffic flow (in green) which corresponds to the above configuration.
+
+.. figure:: ./images/sfc/single-logical-sff-example.png
+ :alt: Logical SFF Example
+ :width: 800px
+ :height: 600px
+
+ Logical SFF Example
+
+
+
+The Logical SFF functionality allows OpenDaylight to find out the SFFs holding the SFs involved in a path. In this example
+the SFFs affected are Node3 and Node4 thus the controller renders the flows containing NSH parameters just in those SFFs.
+
+Here you have the new flows rendered in Node3 and Node4 which implement the NSH protocol. Every Rendered Service Path is represented
+by an NSP value. We provisioned a symmetric RSP so we get two NSPs: 8388613 and 5. Node3 holds the first SF of NSP 8388613 and
+the last SF of NSP 5. Node 4 holds the first SF of NSP 5 and the last SF of NSP 8388613. Both Node3 and Node4 will pop the NSH header
+when the received packet has gone through the last SF of its path.
+
+
+**Rendered flows Node 3**
+
+::
+
+ cookie=0x14, duration=59.264s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
+ cookie=0x14, duration=59.194s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
+ 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
+ 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
+ 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)
+ 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)
+ 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)
+ 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
+
+**Rendered Flows Node 4**
+
+::
+
+ cookie=0x14, duration=69.040s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
+ cookie=0x14, duration=69.008s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
+ 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
+ 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
+ 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)
+ 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
+ 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)
+ 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)
+
+
+An interesting scenario to show the Logical SFF strength is the migration of a SF from a compute node to another.
+The OpenDaylight will learn the new topology by itself, then it will re-render the new flows to the new SFFs affected.
+
+.. figure:: ./images/sfc/single-logical-sff-example-migration.png
+ :alt: Logical SFF - SF Migration Example
+ :width: 800px
+ :height: 600px
+
+ Logical SFF - SF Migration Example
+
+
+In our example, SF2 is moved from Node4 to Node2 then OpenDaylight removes NSH specific flows from Node4 and puts them in Node2.
+Check below flows showing this effect. Now Node3 keeps holding the first SF of NSP 8388613 and the last SF of NSP 5;
+but Node2 becomes the new holder of the first SF of NSP 5 and the last SF of NSP 8388613.
+
+
+**Rendered Flows Node 3 After Migration**
+
+::
+
+ cookie=0x14, duration=64.044s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
+ cookie=0x14, duration=63.947s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
+ 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
+ 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
+ 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)
+ 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)
+ 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)
+ 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
+
+**Rendered Flows Node 2 After Migration**
+
+::
+
+ cookie=0x14, duration=56.856s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
+ cookie=0x14, duration=56.755s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
+ 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
+ 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
+ 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)
+ 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
+ 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)
+ 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)
+
+**Rendered Flows Node 4 After Migration**
+
+::
+
+ -- No flows for NSH processing --
+
+.. _sfc-user-guide-classifier-impacts:
+
+Classifier impacts
+~~~~~~~~~~~~~~~~~~
+
+As previously mentioned, in the :ref:`Logical SFF rationale
+<sfc-user-guide-logical-sff-motivation>`, the Logical SFF feature relies on
+Genius to get the dataplane IDs of the OpenFlow switches, in order to properly
+steer the traffic through the chain.
+
+Since one of the classifier's objectives is to steer the packets *into* the
+SFC domain, the classifier has to be aware of where the first Service
+Function is located - if it migrates somewhere else, the classifier table
+has to be updated accordingly, thus enabling the seemless migration of Service
+Functions.
+
+For this feature, mobility of the client VM is out of scope, and should be
+managed by its high-availability module, or VNF manager.
+
+Keep in mind that classification *always* occur in the compute-node where
+the client VM (i.e. traffic origin) is running.
+
+How to attach the classifier to a Logical SFF
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In order to leverage this functionality, the classifier has to be configured
+using a Logical SFF as an attachment-point, specifying within it the neutron
+port to classify.
+
+The following examples show how to configure an ACL, and a classifier having
+a Logical SFF as an attachment-point:
+
+**Configure an ACL**
+
+The following ACL enables traffic intended for port 80 within the subnetwork
+192.168.2.0/24, for RSP1 and RSP1-Reverse.
+
+::
+
+ {
+ "access-lists": {
+ "acl": [
+ {
+ "acl-name": "ACL1",
+ "acl-type": "ietf-access-control-list:ipv4-acl",
+ "access-list-entries": {
+ "ace": [
+ {
+ "rule-name": "ACE1",
+ "actions": {
+ "service-function-acl:rendered-service-path": "RSP1"
+ },
+ "matches": {
+ "destination-ipv4-network": "192.168.2.0/24",
+ "source-ipv4-network": "192.168.2.0/24",
+ "protocol": "6",
+ "source-port-range": {
+ "lower-port": 0
+ },
+ "destination-port-range": {
+ "lower-port": 80
+ }
+ }
+ }
+ ]
+ }
+ },
+ {
+ "acl-name": "ACL2",
+ "acl-type": "ietf-access-control-list:ipv4-acl",
+ "access-list-entries": {
+ "ace": [
+ {
+ "rule-name": "ACE2",
+ "actions": {
+ "service-function-acl:rendered-service-path": "RSP1-Reverse"
+ },
+ "matches": {
+ "destination-ipv4-network": "192.168.2.0/24",
+ "source-ipv4-network": "192.168.2.0/24",
+ "protocol": "6",
+ "source-port-range": {
+ "lower-port": 80
+ },
+ "destination-port-range": {
+ "lower-port": 0
+ }
+ }
+ }
+ ]
+ }
+ }
+ ]
+ }
+ }
+
+::
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/ietf-access-control-list:access-lists/
+
+**Configure a classifier JSON**
+
+The following JSON provisions a classifier, having a Logical SFF as an
+attachment point. The value of the field 'interface' is where you
+indicate the neutron ports of the VMs you want to classify.
+
+::
+
+ {
+ "service-function-classifiers": {
+ "service-function-classifier": [
+ {
+ "name": "Classifier1",
+ "scl-service-function-forwarder": [
+ {
+ "name": "sfflogical1",
+ "interface": "09a78ba3-78ba-40f5-a3ea-1ce708367f2b"
+ }
+ ],
+ "acl": {
+ "name": "ACL1",
+ "type": "ietf-access-control-list:ipv4-acl"
+ }
+ }
+ ]
+ }
+ }
+
+::
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-classifier:service-function-classifiers/
+
+.. _sfc-user-guide-pipeline-impacts:
+
+SFC pipeline impacts
+~~~~~~~~~~~~~~~~~~~~
+
+After binding SFC service with a particular interface by means of Genius, as explained in the :ref:`Genius User Guide <genius-user-guide-binding-services>`,
+the entry point in the SFC pipeline will be table 82 (SFC_TRANSPORT_CLASSIFIER_TABLE), and from that point, packet
+processing will be similar to the :ref:`SFC OpenFlow pipeline <sfc-user-guide-sfc-of-pipeline>`, just with another set
+of specific tables for the SFC service.
+
+This picture shows the SFC pipeline after service integration with Genius:
+
+.. figure:: ./images/sfc/LSFF_pipeline.png
+ :alt: SFC Logical SFF OpenFlow pipeline
+
+ SFC Logical SFF OpenFlow pipeline
+
+
Code Review / docs.git / blobdiff