+
+Directional data plane locators for symmetric paths
+---------------------------------------------------
+
+Overview
+~~~~~~~~
+
+A symmetric path results from a Service Function Path with the symmetric field
+set or when any of the constituent Service Functions is set as bidirectional.
+Such a path is defined by two Rendered Service Paths where one of them steers
+the traffic through the same Service Functions as the other but in opposite
+order. These two Rendered Service Paths are also said to be symmetric to each
+other and gives to each path a sense of direction: The Rendered Service Path
+that corresponds to the same order of Service Functions as that defined on the
+Service Function Chain is tagged as the forward or up-link path, while the
+Rendered Service Path that corresponds to the opposite order is tagged as
+reverse or down-link path.
+
+Directional data plane locators allow the use of different interfaces or
+interface details between the Service Function Forwarder and the Service
+Function in relation with the direction of the path for which they are being
+used. This function is relevant for Service Functions that would have no other
+way of discerning the direction of the traffic, like for example legacy
+bump-in-the-wire network devices.
+
+::
+
+ +-----------------------------------------------+
+ | |
+ | |
+ | SF |
+ | |
+ | sf-forward-dpl sf-reverse-dpl |
+ +--------+-----------------------------+--------+
+ | |
+ ^ | + + | ^
+ | | | | | |
+ | | | | | |
+ + | + + | +
+ Forward Path | Reverse Path Forward Path | Reverse Path
+ + | + + | +
+ | | | | | |
+ | | | | | |
+ | | | | | |
+ + | v v | +
+ | |
+ +-----------+-----------------------------------------+
+ Forward Path | sff-forward-dpl sff-reverse-dpl | Forward Path
+ +--------------> | | +-------------->
+ | |
+ | SFF |
+ | |
+ <--------------+ | | <--------------+
+ Reverse Path | | Reverse Path
+ +-----------------------------------------------------+
+
+As shown in the previous figure, the forward path egress from the Service
+Function Forwarder towards the Service Function is defined by the
+sff-forward-dpl and sf-forward-dpl data plane locators. The forward path
+ingress from the Service Function to the Service Function Forwarder is defined
+by the sf-reverse-dpl and sff-reverse-dpl data plane locators. For the reverse
+path, it's the opposite: the sff-reverse-dpl and sf-reverse-dpl define the
+egress from the Service Function Forwarder to the Service Function, and the
+sf-forward-dpl and sff-forward-dpl define the ingress into the Service Function
+Forwarder from the Service Function.
+
+.. note:: Directional data plane locators are only supported in combination
+ with the SFC OF Renderer at this time.
+
+Configuration
+~~~~~~~~~~~~~
+
+Directional data plane locators are configured within the
+service-function-forwarder in the service-function-dictionary entity, which
+describes the association between a Service Function Forwarder and Service
+Functions:
+
+.. code-block:: service-function-forwarder.yang
+
+ list service-function-dictionary {
+ key "name";
+ leaf name {
+ type sfc-common:sf-name;
+ description
+ "The name of the service function.";
+ }
+ container sff-sf-data-plane-locator {
+ description
+ "SFF and SF data plane locators to use when sending
+ packets from this SFF to the associated SF";
+ leaf sf-dpl-name {
+ type sfc-common:sf-data-plane-locator-name;
+ description
+ "The SF data plane locator to use when sending
+ packets to the associated service function.
+ Used both as forward and reverse locators for
+ paths of a symmetric chain.";
+ }
+ leaf sff-dpl-name {
+ type sfc-common:sff-data-plane-locator-name;
+ description
+ "The SFF data plane locator to use when sending
+ packets to the associated service function.
+ Used both as forward and reverse locators for
+ paths of a symmetric chain.";
+ }
+ leaf sf-forward-dpl-name {
+ type sfc-common:sf-data-plane-locator-name;
+ description
+ "The SF data plane locator to use when sending
+ packets to the associated service function
+ on the forward path of a symmetric chain";
+ }
+ leaf sf-reverse-dpl-name {
+ type sfc-common:sf-data-plane-locator-name;
+ description
+ "The SF data plane locator to use when sending
+ packets to the associated service function
+ on the reverse path of a symmetric chain";
+ }
+ leaf sff-forward-dpl-name {
+ type sfc-common:sff-data-plane-locator-name;
+ description
+ "The SFF data plane locator to use when sending
+ packets to the associated service function
+ on the forward path of a symmetric chain.";
+ }
+ leaf sff-reverse-dpl-name {
+ type sfc-common:sff-data-plane-locator-name;
+ description
+ "The SFF data plane locator to use when sending
+ packets to the associated service function
+ on the reverse path of a symmetric chain.";
+ }
+ }
+ }
+
+Example
+~~~~~~~
+
+The following configuration example is based on the Logical SFF configuration
+one. Only the Service Function and Service Function Forwarder configuration
+changes with respect to that example:
+
+.. code-block:: bash
+
+ 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.**
+
+.. code-block:: json
+
+ {
+ "service-functions": {
+ "service-function": [
+ {
+ "name": "firewall-1",
+ "type": "firewall",
+ "sf-data-plane-locator": [
+ {
+ "name": "sf-firewall-net-A-dpl",
+ "interface-name": "eccb57ae-5a2e-467f-823e-45d7bb2a6a9a",
+ "transport": "service-locator:mac",
+ "service-function-forwarder": "sfflogical1"
+
+ },
+ {
+ "name": "sf-firewall-net-B-dpl",
+ "interface-name": "7764b6f1-a5cd-46be-9201-78f917ddee1d",
+ "transport": "service-locator:mac",
+ "service-function-forwarder": "sfflogical1"
+
+ }
+ ]
+ },
+ {
+ "name": "dpi-1",
+ "type": "dpi",
+ "sf-data-plane-locator": [
+ {
+ "name": "sf-dpi-net-A-dpl",
+ "interface-name": "df15ac52-e8ef-4e9a-8340-ae0738aba0c0",
+ "transport": "service-locator:mac",
+ "service-function-forwarder": "sfflogical1"
+ },
+ {
+ "name": "sf-dpi-net-B-dpl",
+ "interface-name": "1bb09b01-422d-4ccf-8d7a-9ebf00d1a1a5",
+ "transport": "service-locator:mac",
+ "service-function-forwarder": "sfflogical1"
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+.. code-block:: bash
+
+ 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.**
+
+.. code-block:: json
+
+ {
+ "service-function-forwarders": {
+ "service-function-forwarder": [
+ {
+ "name": "sfflogical1"
+ "sff-data-plane-locator": [
+ {
+ "name": "sff-firewall-net-A-dpl",
+ "data-plane-locator": {
+ "interface-name": "eccb57ae-5a2e-467f-823e-45d7bb2a6a9a",
+ "transport": "service-locator:mac"
+ }
+ },
+ {
+ "name": "sff-firewall-net-B-dpl",
+ "data-plane-locator": {
+ "interface-name": "7764b6f1-a5cd-46be-9201-78f917ddee1d",
+ "transport": "service-locator:mac"
+ }
+ },
+ {
+ "name": "sff-dpi-net-A-dpl",
+ "data-plane-locator": {
+ "interface-name": "df15ac52-e8ef-4e9a-8340-ae0738aba0c0",
+ "transport": "service-locator:mac"
+ }
+ },
+ {
+ "name": "sff-dpi-net-B-dpl",
+ "data-plane-locator": {
+ "interface-name": "1bb09b01-422d-4ccf-8d7a-9ebf00d1a1a5",
+ "transport": "service-locator:mac"
+ }
+ }
+ ],
+ "service-function-dictionary": [
+ {
+ "name": "firewall-1",
+ "sff-sf-data-plane-locator": {
+ "sf-forward-dpl-name": "sf-firewall-net-A-dpl",
+ "sf-reverse-dpl-name": "sf-firewall-net-B-dpl",
+ "sff-forward-dpl-name": "sff-firewall-net-A-dpl",
+ "sff-reverse-dpl-name": "sff-firewall-net-B-dpl",
+ }
+ },
+ {
+ "name": "dpi-1",
+ "sff-sf-data-plane-locator": {
+ "sf-forward-dpl-name": "sf-dpi-net-A-dpl",
+ "sf-reverse-dpl-name": "sf-dpi-net-B-dpl",
+ "sff-forward-dpl-name": "sff-dpi-net-A-dpl",
+ "sff-reverse-dpl-name": "sff-dpi-net-B-dpl",
+ }
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+In comparison with the Logical SFF example, noticed that each Service Function
+is configured with two data plane locators instead of one so that each can be
+used in different directions of the path. To specify which locator is used on
+which direction, the Service Function Forwarder configuration is also more
+extensive compared to the previous example.
+
+When comparing this example with the Logical SFF one, that the Service Function
+Forwarder is configured with data plane locators and that they hold the same
+interface name values as the corresponding Service Function interfaces. This is
+because in the Logical SFF particular case, a single logical interface fully
+describes an attachment of a Service Function Forwarder to a Service Function
+on both the Service Function and Service Function Forwarder sides. For
+non-Logical SFF scenarios, it would be expected for the data plane locators to
+have different values as we have seen on other examples through out this user
+guide. For example, if mac addresses are to be specified in the locators, the
+Service Function would have a different mac address than the Service Function
+Forwarder.
+
+
+As a result of the overall configuration, two Rendered Service Paths are
+implemented. The forward path:
+
+::
+
+ +------------+ +-------+
+ | firewall-1 | | dpi- 1 |
+ +---+---+----+ +--+--+-+
+ ^ | ^ |
+ net-A-dpl| |net-B-dpl net-A-dpl| |net-B-dpl
+ | | | |
+ +----------+ | | | | +----------+
+ | client A +--------------+ +------------------------+ +------------>+ server B |
+ +----------+ +----------+
+
+And the reverse path:
+
+::
+
+ +------------+ +-------+
+ | firewall 1 | | dpi-1 |
+ +---+---+----+ +--+--+-+
+ | ^ | ^
+ net-A-dpl| |net-B-dpl net-A-dpl| |net-B-dpl
+ | | | |
+ +----------+ | | | | +----------+
+ | client A +<-------------+ +------------------------+ +-------------+ server B |
+ +----------+ +----------+
+
+Consider the following notes to put the example in context:
+
+- The classification function is obviated from the illustration.
+- The forward path is up-link traffic from a client in network A to a server in
+ network B.
+- The reverse path is down-link traffic from a server in network B to a client
+ in network A.
+- The service functions might be legacy bump-in-the-wire network devices that
+ need to use different interfaces for each network.
+
+SFC Statistics User Guide
+-------------------------
+
+Statistics can be queried for Rendered Service Paths created on OVS bridges.
+Future support will be added for Service Function Forwarders and Service
+Functions. Future support will also be added for VPP and IOs-XE devices.
+
+To use SFC statistics the 'odl-sfc-statistics' Karaf feature needs to be
+installed.
+
+Statistics are queried by sending an RPC RESTconf message to ODL. For
+RSPs, its possible to either query statistics for one individual RSP
+or for all RSPs, as follows:
+
+Querying statistics for a specific RSP:
+
+.. code-block:: bash
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
+ --data '{ "input": { "name" : "path1-Path-42" } }' -X POST --user admin:admin
+ http://localhost:8181/restconf/operations/sfc-statistics-operations:get-rsp-statistics
+
+
+Querying statistics for all RSPs:
+
+.. code-block:: bash
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
+ --data '{ "input": { } }' -X POST --user admin:admin
+ http://localhost:8181/restconf/operations/sfc-statistics-operations:get-rsp-statistics
+
+
+The following is the sort of output that can be expected for each RSP.
+
+.. code-block:: json
+
+ {
+ "output": {
+ "statistics": [
+ {
+ "name": "sfc-path-1sf1sff-Path-34",
+ "statistic-by-timestamp": [
+ {
+ "service-statistic": {
+ "bytes-in": 0,
+ "bytes-out": 0,
+ "packets-in": 0,
+ "packets-out": 0
+ },
+ "timestamp": 1518561500480
+ }
+ ]
+ }
+ ]
+ }
+ }
+
Code Review / docs.git / blobdiff