+.. _sfc-user-guide:
+
Service Function Chaining
=========================
SFC OpenFlow Renderer High Level Architecture
+.. _sfc-user-guide-sfc-of-pipeline:
+
SFC OpenFlow Switch Flow pipeline
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
as illustrated above. Additionally, the SFs must be created and
connected.
+Note that RSP symmetry depends on Service Function Path symmetric field, if present.
+If not, the RSP will be symmetric if any of the SFs involved in the chain
+has the bidirectional field set to true.
+
Target Environment
^^^^^^^^^^^^^^^^^^
{
"name": "sf1",
"type": "http-header-enrichment",
- "nsh-aware": true,
"ip-mgmt-address": "10.0.0.2",
"sf-data-plane-locator": [
{
{
"name": "sf2",
"type": "firewall",
- "nsh-aware": true,
"ip-mgmt-address": "10.0.0.3",
"sf-data-plane-locator": [
{
"service-function-chain": [
{
"name": "sfc-chain1",
- "symmetric": true,
"sfc-service-function": [
{
"name": "hdr-enrich-abstract1",
{
"input": {
"name": "sfc-path1",
- "parent-service-function-path": "sfc-path1",
- "symmetric": true
+ "parent-service-function-path": "sfc-path1"
}
}
{
"name": "sf1",
"type": "http-header-enrichment",
- "nsh-aware": false,
"ip-mgmt-address": "10.0.0.2",
"sf-data-plane-locator": [
{
{
"name": "sf2",
"type": "firewall",
- "nsh-aware": false,
"ip-mgmt-address": "10.0.0.3",
"sf-data-plane-locator": [
{
"service-function-chain": [
{
"name": "sfc-chain1",
- "symmetric": true,
"sfc-service-function": [
{
"name": "hdr-enrich-abstract1",
{
"input": {
"name": "sfc-path1",
- "parent-service-function-path": "sfc-path1",
- "symmetric": true
+ "parent-service-function-path": "sfc-path1"
}
}
{
"name": "Firewall",
"ip-mgmt-address": "172.25.73.23",
- "type": "service-function-type: firewall",
- "nsh-aware": true,
+ "type": "firewall",
"sf-data-plane-locator": [
{
"name": "firewall-dpl",
{
"name": "Dpi",
"ip-mgmt-address": "172.25.73.23",
- "type":"service-function-type: dpi",
- "nsh-aware": true,
+ "type":"dpi",
"sf-data-plane-locator": [
{
"name": "dpi-dpl",
{
"name": "Qos",
"ip-mgmt-address": "172.25.73.23",
- "type":"service-function-type: qos",
- "nsh-aware": true,
+ "type":"qos",
"sf-data-plane-locator": [
{
"name": "qos-dpl",
}
All these SFs are configured on the same device as the LSF. The next
-step is to prepare Service Function Chain. SFC is symmetric.
+step is to prepare Service Function Chain.
::
"service-function-chain": [
{
"name": "CSR3XSF",
- "symmetric": "true",
"sfc-service-function": [
{
"name": "Firewall",
- "type": "service-function-type: firewall"
+ "type": "firewall"
},
{
"name": "Dpi",
- "type": "service-function-type: dpi"
+ "type": "dpi"
},
{
"name": "Qos",
- "type": "service-function-type: qos"
+ "type": "qos"
}
]
}
{
"input": {
"name": "CSR3XSF-Path-RSP",
- "parent-service-function-path": "CSR3XSF-Path",
- "symmetric": true
+ "parent-service-function-path": "CSR3XSF-Path"
}
}
Prerequisites
'''''''''''''
-- Depolyed topology (include SFFs, SFs and their links).
+- Deployed topology (include SFFs, SFs and their links).
- Dijkstra’s algorithm. More information on Dijkstra’s algorithm can be
found on the wiki here:
"service-function-dictionary": [
{
"sff-sf-data-plane-locator": {
- "port": 10001,
- "ip": "10.3.1.103"
+ "sf-dpl-name": "sf1dpl",
+ "sff-dpl-name": "sff1dpl"
},
"name": "napt44-1",
- "type": "service-function-type:napt44"
+ "type": "napt44"
},
{
"sff-sf-data-plane-locator": {
- "port": 10003,
- "ip": "10.3.1.102"
+ "sf-dpl-name": "sf2dpl",
+ "sff-dpl-name": "sff2dpl"
},
"name": "firewall-1",
- "type": "service-function-type:firewall"
+ "type": "firewall"
}
],
"connected-sff-dictionary": [
"service-function-dictionary": [
{
"sff-sf-data-plane-locator": {
- "port": 10002,
- "ip": "10.3.1.103"
+ "sf-dpl-name": "sf1dpl",
+ "sff-dpl-name": "sff1dpl"
},
"name": "napt44-2",
- "type": "service-function-type:napt44"
+ "type": "napt44"
},
{
"sff-sf-data-plane-locator": {
- "port": 10004,
- "ip": "10.3.1.101"
+ "sf-dpl-name": "sf2dpl",
+ "sff-dpl-name": "sff2dpl"
},
"name": "firewall-2",
- "type": "service-function-type:firewall"
+ "type": "firewall"
}
],
"connected-sff-dictionary": [
"service-function-dictionary": [
{
"sff-sf-data-plane-locator": {
- "port": 10005,
- "ip": "10.3.1.104"
+ "sf-dpl-name": "sf1dpl",
+ "sff-dpl-name": "sff1dpl"
},
"name": "test-server",
- "type": "service-function-type:dpi"
+ "type": "dpi"
},
{
"sff-sf-data-plane-locator": {
- "port": 10006,
- "ip": "10.3.1.102"
+ "sf-dpl-name": "sf2dpl",
+ "sff-dpl-name": "sff2dpl"
},
"name": "test-client",
- "type": "service-function-type:dpi"
+ "type": "dpi"
}
],
"connected-sff-dictionary": [
}
],
"name": "napt44-1",
- "type": "service-function-type:napt44",
- "nsh-aware": true
+ "type": "napt44"
},
{
"rest-uri": "http://localhost:10002",
}
],
"name": "napt44-2",
- "type": "service-function-type:napt44",
- "nsh-aware": true
+ "type": "napt44"
},
{
"rest-uri": "http://localhost:10003",
}
],
"name": "firewall-1",
- "type": "service-function-type:firewall",
- "nsh-aware": true
+ "type": "firewall"
},
{
"rest-uri": "http://localhost:10004",
}
],
"name": "firewall-2",
- "type": "service-function-type:firewall",
- "nsh-aware": true
+ "type": "firewall"
},
{
"rest-uri": "http://localhost:10005",
}
],
"name": "test-server",
- "type": "service-function-type:dpi",
- "nsh-aware": true
+ "type": "dpi"
},
{
"rest-uri": "http://localhost:10006",
}
],
"name": "test-client",
- "type": "service-function-type:dpi",
- "nsh-aware": true
+ "type": "dpi"
}
]
}
"ip-mgmt-address": "10.3.1.103",
"algorithm": "alg1",
"name": "SFG1",
- "type": "service-function-type:napt44",
+ "type": "napt44",
"sfc-service-function": [
{
"name":"napt44-104"
Overview
~~~~~~~~
-Early Service Function Chaining (SFC) Proof of Transit (SFC Proof of
-Transit) implements Service Chaining Proof of Transit functionality on
-capable switches. After the creation of an Rendered Service Path (RSP),
-a user can configure to enable SFC proof of transit on the selected RSP
-to effect the proof of transit.
+Several deployments use traffic engineering, policy routing, segment
+routing or service function chaining (SFC) to steer packets through a
+specific set of nodes. In certain cases regulatory obligations or a
+compliance policy require to prove that all packets that are supposed to
+follow a specific path are indeed being forwarded across the exact set
+of nodes specified. I.e. if a packet flow is supposed to go through a
+series of service functions or network nodes, it has to be proven that
+all packets of the flow actually went through the service chain or
+collection of nodes specified by the policy. In case the packets of a
+flow weren’t appropriately processed, a proof of transit egress device
+would be required to identify the policy violation and take
+corresponding actions (e.g. drop or redirect the packet, send an alert
+etc.) corresponding to the policy.
+
+Service Function Chaining (SFC) Proof of Transit (SFC PoT)
+implements Service Chaining Proof of Transit functionality on capable
+network devices. Proof of Transit defines mechanisms to securely
+prove that traffic transited the defined path. After the creation of an
+Rendered Service Path (RSP), a user can configure to enable SFC proof
+of transit on the selected RSP to effect the proof of transit.
+
+To ensure that the data traffic follows a specified path or a function
+chain, meta-data is added to user traffic in the form of a header. The
+meta-data is based on a 'share of a secret' and provisioned by the SFC
+PoT configuration from ODL over a secure channel to each of the nodes
+in the SFC. This meta-data is updated at each of the service-hop while
+a designated node called the verifier checks whether the collected
+meta-data allows the retrieval of the secret.
+
+The following diagram shows the overview and essentially utilizes Shamir's
+secret sharing algorithm, where each service is given a point on the
+curve and when the packet travels through each service, it collects these
+points (meta-data) and a verifier node tries to re-construct the curve
+using the collected points, thus verifying that the packet traversed
+through all the service functions along the chain.
+
+.. figure:: ./images/sfc/sfc-pot-intro.png
+ :alt: SFC Proof of Transit overview
+
+ SFC Proof of Transit overview
+
+Transport options for different protocols includes a new TLV in SR header
+for Segment Routing, NSH Type-2 meta-data, IPv6 extension headers, IPv4
+variants and for VXLAN-GPE. More details are captured in the following
+link.
+
+In-situ OAM: https://github.com/CiscoDevNet/iOAM
Common acronyms used in the following sections:
- RSP - Rendered Service Path
-- SFCPOT - Service Function Chain Proof of Transit
+- SFC PoT - Service Function Chain Proof of Transit
+
SFC Proof of Transit Architecture
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-When SFC Proof of Transit is initialized, all required listeners are
-registered to handle incoming data. It involves ``SfcPotNodeListener``
-which stores data about all node devices including their mountpoints
-(used here as databrokers), ``SfcPotRSPDataListener``,
-``RenderedPathListener``. ``RenderedPathListener`` is used to listen for
-RSP changes. ``SfcPotRSPDataListener`` implements RPC services to enable
-or disable SFC Proof of Transit on a particular RSP. When the SFC Proof
-of Transit is invoked, RSP listeners and service implementations are
-setup to receive SFCPOT configurations. When a user configures via a
-POST RPC call to enable SFCPOT on a particular RSP, the configuration
-drives the creation of necessary augmentations to the RSP to effect the
-SFCPOT configurations.
-
-SFC Proof of Transit details
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+SFC PoT feature is implemented as a two-part implementation with a
+north-bound handler that augments the RSP while a south-bound renderer
+auto-generates the required parameters and passes it on to the nodes
+that belong to the SFC.
-Several deployments use traffic engineering, policy routing, segment
-routing or service function chaining (SFC) to steer packets through a
-specific set of nodes. In certain cases regulatory obligations or a
-compliance policy require to prove that all packets that are supposed to
-follow a specific path are indeed being forwarded across the exact set
-of nodes specified. I.e. if a packet flow is supposed to go through a
-series of service functions or network nodes, it has to be proven that
-all packets of the flow actually went through the service chain or
-collection of nodes specified by the policy. In case the packets of a
-flow weren’t appropriately processed, a proof of transit egress device
-would be required to identify the policy violation and take
-corresponding actions (e.g. drop or redirect the packet, send an alert
-etc.) corresponding to the policy.
+The north-bound feature is enabled via odl-sfc-pot feature while the
+south-bound renderer is enabled via the odl-sfc-pot-netconf-renderer
+feature. For the purposes of SFC PoT handling, both features must be
+installed.
+
+RPC handlers to augment the RSP are part of ``SfcPotRpc`` while the
+RSP augmentation to enable or disable SFC PoT feature is done via
+``SfcPotRspProcessor``.
-The SFCPOT approach is based on meta-data which is added to every
-packet. The meta data is updated at every hop and is used to verify
-whether a packet traversed all required nodes. A particular path is
-either described by a set of secret keys, or a set of shares of a single
-secret. Nodes on the path retrieve their individual keys or shares of a
-key (using for e.g. Shamir’s Shared Sharing Secret scheme) from a
-central controller. The complete key set is only known to the verifier-
-which is typically the ultimate node on a path that requires proof of
-transit. Each node in the path uses its secret or share of the secret to
-update the meta-data of the packets as the packets pass through the
-node. When the verifier receives a packet, it can use its key(s) along
-with the meta-data to validate whether the packet traversed the service
-chain correctly.
SFC Proof of Transit entities
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the controller along with necessary parameters to control some of the
aspects of the SFC Proof of Transit process.
-The RPC handler identifies the RSP and generates SFC Proof of Transit
-parameters like secret share, secret etc., and adds the generated SFCPOT
-configuration parameters to SFC main as well as the various SFC hops.
-The last node in the SFC is configured as a verifier node to allow
-SFCPOT Proof of Transit process to be completed.
-
-The SFCPOT configuration generators and related handling are done by
-``SfcPotAPI``, ``SfcPotConfigGenerator``, ``SfcPotListener``,
-``SfcPotPolyAPI``, ``SfcPotPolyClassAPI`` and ``SfcPotPolyClass``.
+The RPC handler identifies the RSP and adds PoT feature meta-data like
+enable/disable, number of PoT profiles, profiles refresh parameters etc.,
+that directs the south-bound renderer appropriately when RSP changes
+are noticed via call-backs in the renderer handlers.
Administering SFC Proof of Transit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- odl-sfc-pot
+Please note that the odl-sfc-pot-netconf-renderer or other renderers in future
+must be installed for the feature to take full-effect. The details of the renderer
+features are described in other parts of this document.
+
SFC Proof of Transit Tutorial
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^^^^^^^^^^^^^
To enable a device to handle SFC Proof of Transit, it is expected that
-the netconf server device advertise capability as under ioam-scv.yang
-present under src/main/yang folder of sfc-pot feature. It is also
-expected that netconf notifications be enabled and its support
-capability advertised as capabilities.
+the NETCONF node device advertise capability as under ioam-sb-pot.yang
+present under sfc-model/src/main/yang folder. It is also expected that base
+NETCONF support be enabled and its support capability advertised as capabilities.
+
+NETCONF support:``urn:ietf:params:netconf:base:1.0``
+
+PoT support: ``(urn:cisco:params:xml:ns:yang:sfc-ioam-sb-pot?revision=2017-01-12)sfc-ioam-sb-pot``
It is also expected that the devices are netconf mounted and available
in the topology-netconf store.
Instructions
^^^^^^^^^^^^
-When SFC Proof of Transit is installed, all netconf nodes in
-topology-netconf are processed and all capable nodes with accessible
-mountpoints are cached.
+When SFC Proof of Transit is installed, all netconf nodes in topology-netconf
+are processed and all capable nodes with accessible mountpoints are cached.
-First step is to create the required RSP as usually done.
+First step is to create the required RSP as is usually done using RSP creation
+steps in SFC main.
Once RSP name is available it is used to send a POST RPC to the
controller similar to below:
-::
+POST -
+http://ODL-IP:8181/restconf/operations/sfc-ioam-nb-pot:enable-sfc-ioam-pot-rendered-path/
- POST ./restconf/operations/sfc-ioam-nb-pot:enable-sfc-ioam-pot-rendered-path
+.. code-block:: json
{
- "input": {
- "sfc-ioam-pot-rsp-name": "rsp1"
- }
+ "input":
+ {
+ "sfc-ioam-pot-rsp-name": "sfc-path-3sf3sff",
+ "ioam-pot-enable":true,
+ "ioam-pot-num-profiles":2,
+ "ioam-pot-bit-mask":"bits32",
+ "refresh-period-time-units":"milliseconds",
+ "refresh-period-value":5000
+ }
}
The following can be used to disable the SFC Proof of Transit on an RSP
-which removes the augmentations and stores back the RSP without the
-SFCPOT enabled features and also sending down a delete configuration to
-the SFCPOT configuration sub-tree in the nodes.
+which disables the PoT feature.
-::
+POST -
+http://ODL-IP:8181/restconf/operations/sfc-ioam-nb-pot:disable-sfc-ioam-pot-rendered-path/
- POST ./restconf/operations/sfc-ioam-nb-pot:disable-sfc-ioam-pot-rendered-path
+.. code-block:: json
{
- "input": {
- "sfc-ioam-pot-rsp-name": "rsp1"
- }
+ "input":
+ {
+ "sfc-ioam-pot-rsp-name": "sfc-path-3sf3sff",
+ }
}
+SFC PoT NETCONF Renderer User Guide
+-----------------------------------
+
+Overview
+~~~~~~~~
+
+The SFC Proof of Transit (PoT) NETCONF renderer implements SFC Proof of
+Transit functionality on NETCONF-capable devices, that have advertised
+support for in-situ OAM (iOAM) support.
+
+It listens for an update to an existing RSP with enable or disable proof of
+transit support and adds the auto-generated SFC PoT configuration parameters
+to all the SFC hop nodes. The last node in the SFC is configured as a
+verifier node to allow SFC PoT process to be completed.
+
+Common acronyms are used as below:
+
+- SF - Service Function
+
+- SFC - Service Function Chain
+
+- RSP - Rendered Service Path
+
+- SFF - Service Function Forwarder
+
+
+Mapping to SFC entities
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The renderer module listens to RSP updates in ``SfcPotNetconfRSPListener``
+and triggers configuration generation in ``SfcPotNetconfIoam`` class. Node
+arrival and leaving are managed via ``SfcPotNetconfNodeManager`` and
+``SfcPotNetconfNodeListener``. In addition there is a timer thread that
+runs to generate configuration periodically to refresh the profiles in the
+nodes that are part of the SFC.
+
+
+Administering SFC PoT NETCONF Renderer
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To use the SFC Proof of Transit Karaf, the following Karaf features must
+be installed:
+
+- odl-sfc-model
+
+- odl-sfc-provider
+
+- odl-sfc-netconf
+
+- odl-restconf-all
+
+- odl-netconf-topology
+
+- odl-netconf-connector-all
+
+- odl-sfc-pot
+
+- odl-sfc-pot-netconf-renderer
+
+
+SFC PoT NETCONF Renderer Tutorial
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Overview
+^^^^^^^^
+
+This tutorial is a simple example how to enable SFC PoT on NETCONF-capable
+devices.
+
+Preconditions
+^^^^^^^^^^^^^
+
+The NETCONF-capable device will have to support sfc-ioam-sb-pot.yang file.
+
+It is expected that a NETCONF-capable VPP device has Honeycomb (Hc2vpp)
+Java-based agent that helps to translate between NETCONF and VPP internal
+APIs.
+
+More details are here:
+In-situ OAM: https://github.com/CiscoDevNet/iOAM
+
+Steps
+^^^^^
+When the SFC PoT NETCONF renderer module is installed, all NETCONF nodes in
+topology-netconf are processed and all sfc-ioam-sb-pot yang capable nodes
+with accessible mountpoints are cached.
+
+The first step is to create RSP for the SFC as per SFC guidelines above.
+
+Enable SFC PoT is done on the RSP via RESTCONF to the ODL as outlined above.
+
+Internally, the NETCONF renderer will act on the callback to a modified RSP
+that has PoT enabled.
+
+In-situ OAM algorithms for auto-generation of SFC PoT parameters are
+generated automatically and sent to these nodes via NETCONF.
+
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
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/service-node:service-nodes/
-
-**Service Nodes JSON.**
-
-::
-
- {
- "service-nodes": {
- "service-node": [
- {
- "name": "classifier1",
- "service-function": [
- ],
- "ip-mgmt-address": "192.168.1.10"
- },
- {
- "name": "sf1",
- "service-function": [
- "dpi-1"
- ],
- "ip-mgmt-address": "192.168.1.30"
- },
- {
- "name": "sf2",
- "service-function": [
- "firewall-1"
- ],
- "ip-mgmt-address": "192.168.1.40"
- },
- {
- "name": "classifier2",
- "service-function": [
- ],
- "ip-mgmt-address": "192.168.1.60"
- }
- ]
- }
- }
-
::
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": {
"service-function": [
{
- "name": "dpi-1",
- "ip-mgmt-address": "192.168.1.30",
- "rest-uri": "http://192.168.1.30:5000",
- "type": "dpi",
- "nsh-aware": "true",
+ "name": "firewall-1",
+ "type": "firewall",
"sf-data-plane-locator": [
{
- "name": "dpi-1-dpl",
- "interface-name": "e0fffc12-a46e-4575-bf36-8383c8edefed",
+ "name": "firewall-dpl",
+ "interface-name": "eccb57ae-5a2e-467f-823e-45d7bb2a6a9a",
+ "transport": "service-locator:eth-nsh",
"service-function-forwarder": "sfflogical1"
+
}
]
},
{
- "name": "firewall-1",
- "ip-mgmt-address": "192.168.1.40",
- "rest-uri": "http://192.168.1.40:5000",
- "type": "firewall",
- "nsh-aware": "true",
+ "name": "dpi-1",
+ "type": "dpi",
"sf-data-plane-locator": [
{
- "name": "firewall-1-dpl",
- "interface-name": "952a5486-d1a5-40cd-a7c1-cc61e59a2b36",
+ "name": "dpi-dpl",
+ "interface-name": "df15ac52-e8ef-4e9a-8340-ae0738aba0c0",
+ "transport": "service-locator:eth-nsh",
"service-function-forwarder": "sfflogical1"
}
]
"service-function-chain": [
{
"name": "SFC1",
- "symmetric": "true",
"sfc-service-function": [
{
"name": "dpi-abstract1",
},
{
"name": "SFC2",
- "symmetric": "true",
"sfc-service-function": [
{
"name": "dpi-abstract1",
]
}
}
+
+::
+
+ 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