docs/user-guide/service-function-chaining.rst

   1 .. _sfc-user-guide:
   2
   3 Service Function Chaining
   4 =========================
   5
   6 OpenDaylight Service Function Chaining (SFC) Overview
   7 -----------------------------------------------------
   8
   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.
  15
  16 -  ACE - Access Control Entry
  17
  18 -  ACL - Access Control List
  19
  20 -  SCF - Service Classifier Function
  21
  22 -  SF - Service Function
  23
  24 -  SFC - Service Function Chain
  25
  26 -  SFF - Service Function Forwarder
  27
  28 -  SFG - Service Function Group
  29
  30 -  SFP - Service Function Path
  31
  32 -  RSP - Rendered Service Path
  33
  34 -  NSH - Network Service Header
  35
  36 SFC User Interface
  37 ------------------
  38
  39 Overview
  40 ~~~~~~~~
  41
  42 The SFC User interface comes with a Command Line Interface (CLI): it provides
  43 several Karaf console commands to show the SFC model (SF, SFFs, etc.) provisioned
  44 in the datastore.
  45
  46
  47 SFC Web Interface (SFC-UI)
  48 ~~~~~~~~~~~~~~~~~~~~~~~~~~
  49
  50 Architecture
  51 ^^^^^^^^^^^^
  52
  53 SFC-UI operates purely by using RESTCONF.
  54
  55 .. figure:: ./images/sfc/sfc-ui-architecture.png
  56    :alt: SFC-UI integration into ODL
  57
  58    SFC-UI integration into ODL
  59
  60 How to access
  61 ^^^^^^^^^^^^^
  62
  63 1. Run ODL distribution (run karaf)
  64
  65 2. In Karaf console execute: ``feature:install odl-sfc-ui``
  66
  67 3. Visit SFC-UI on: ``http://<odl_ip_address>:8181/sfc/index.html``
  68
  69
  70 SFC Command Line Interface (SFC-CLI)
  71 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  72
  73 Overview
  74 ^^^^^^^^
  75
  76 The Karaf Container offers a complete Unix-like console that allows managing
  77 the container. This console can be extended with custom commands to manage the
  78 features deployed on it. This feature will add some basic commands to show the
  79 provisioned SFC entities.
  80
  81 How to use it
  82 ^^^^^^^^^^^^^
  83
  84 The SFC-CLI implements commands to show some of the provisioned SFC entities:
  85 Service Functions, Service Function Forwarders, Service Function
  86 Chains, Service Function Paths, Service Function Classifiers, Service Nodes and
  87 Service Function Types:
  88
  89 * List one/all provisioned Service Functions:
  90
  91   .. code-block:: bash
  92
  93      sfc:sf-list [--name <name>]
  94
  95 * List one/all provisioned Service Function Forwarders:
  96
  97   .. code-block:: bash
  98
  99      sfc:sff-list [--name <name>]
 100
 101 * List one/all provisioned Service Function Chains:
 102
 103   .. code-block:: bash
 104
 105      sfc:sfc-list [--name <name>]
 106
 107 * List one/all provisioned Service Function Paths:
 108
 109   .. code-block:: bash
 110
 111      sfc:sfp-list [--name <name>]
 112
 113 * List one/all provisioned Service Function Classifiers:
 114
 115   .. code-block:: bash
 116
 117      sfc:sc-list [--name <name>]
 118
 119 * List one/all provisioned Service Nodes:
 120
 121   .. code-block:: bash
 122
 123      sfc:sn-list [--name <name>]
 124
 125 * List one/all provisioned Service Function Types:
 126
 127   .. code-block:: bash
 128
 129      sfc:sft-list [--name <name>]
 130
 131 SFC Southbound REST Plug-in
 132 ---------------------------
 133
 134 Overview
 135 ~~~~~~~~
 136
 137 The Southbound REST Plug-in is used to send configuration from datastore
 138 down to network devices supporting a REST API (i.e. they have a
 139 configured REST URI). It supports POST/PUT/DELETE operations, which are
 140 triggered accordingly by changes in the SFC data stores.
 141
 142 -  Access Control List (ACL)
 143
 144 -  Service Classifier Function (SCF)
 145
 146 -  Service Function (SF)
 147
 148 -  Service Function Group (SFG)
 149
 150 -  Service Function Schedule Type (SFST)
 151
 152 -  Service Function Forwarder (SFF)
 153
 154 -  Rendered Service Path (RSP)
 155
 156 Southbound REST Plug-in Architecture
 157 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 158
 159 From the user perspective, the REST plug-in is another SFC Southbound
 160 plug-in used to communicate with network devices.
 161
 162 .. figure:: ./images/sfc/sb-rest-architecture-user.png
 163    :alt: Southbound REST Plug-in integration into ODL
 164
 165    Southbound REST Plug-in integration into ODL
 166
 167 Configuring Southbound REST Plugin
 168 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 169
 170 1. Run ODL distribution (run karaf)
 171
 172 2. In Karaf console execute: ``feature:install odl-sfc-sb-rest``
 173
 174 3. Configure REST URIs for SF/SFF through SFC User Interface or RESTCONF
 175    (required configuration steps can be found in the tutorial stated
 176    bellow)
 177
 178 Tutorial
 179 ~~~~~~~~
 180
 181 Comprehensive tutorial on how to use the Southbound REST Plug-in and how
 182 to control network devices with it can be found on:
 183 https://wiki.opendaylight.org/view/Service_Function_Chaining:Main#SFC_103
 184
 185 SFC-OVS integration
 186 -------------------
 187
 188 Overview
 189 ~~~~~~~~
 190
 191 SFC-OVS provides integration of SFC with Open vSwitch (OVS) devices.
 192 Integration is realized through mapping of SFC objects (like SF, SFF,
 193 Classifier, etc.) to OVS objects (like Bridge,
 194 TerminationPoint=Port/Interface). The mapping takes care of automatic
 195 instantiation (setup) of corresponding object whenever its counterpart
 196 is created. For example, when a new SFF is created, the SFC-OVS plug-in
 197 will create a new OVS bridge.
 198
 199 The feature is intended for SFC users willing to use Open vSwitch as an
 200 underlying network infrastructure for deploying RSPs (Rendered Service
 201 Paths).
 202
 203 SFC-OVS Architecture
 204 ~~~~~~~~~~~~~~~~~~~~
 205
 206 SFC-OVS uses the OVSDB MD-SAL Southbound API for getting/writing
 207 information from/to OVS devices. From the user perspective SFC-OVS acts
 208 as a layer between SFC datastore and OVSDB.
 209
 210 .. figure:: ./images/sfc/sfc-ovs-architecture-user.png
 211    :alt: SFC-OVS integration into ODL
 212
 213    SFC-OVS integration into ODL
 214
 215 Configuring SFC-OVS
 216 ~~~~~~~~~~~~~~~~~~~
 217
 218 1. Run ODL distribution (run karaf)
 219
 220 2. In Karaf console execute: ``feature:install odl-sfc-ovs``
 221
 222 3. Configure Open vSwitch to use ODL as a manager, using following
 223    command: ``ovs-vsctl set-manager tcp:<odl_ip_address>:6640``
 224
 225 Tutorials
 226 ~~~~~~~~~
 227
 228 Verifying mapping from SFF to OVS
 229 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 230
 231 Overview
 232 ''''''''
 233
 234 This tutorial shows the usual workflow during creation of an OVS
 235 Bridge with use of the SFC APIs.
 236
 237 Prerequisites
 238 '''''''''''''
 239
 240 -  Open vSwitch installed (ovs-vsctl command available in shell)
 241
 242 -  SFC-OVS feature configured as stated above
 243
 244 Instructions
 245 ''''''''''''
 246
 247 1. In a shell execute: ``ovs-vsctl set-manager tcp:<odl_ip_address>:6640``
 248
 249 2. Send POST request to URL:
 250    ``http://<odl_ip_address>:8181/restconf/operations/service-function-forwarder-ovs:create-ovs-bridge``
 251    Use Basic auth with credentials: "admin", "admin" and set
 252    ``Content-Type: application/json``. The content of POST request
 253    should be following:
 254
 255 ::
 256
 257     {
 258         "input":
 259         {
 260             "name": "br-test",
 261             "ovs-node": {
 262                 "ip": "<Open_vSwitch_ip_address>"
 263             }
 264         }
 265     }
 266
 267 Open\_vSwitch\_ip\_address is the IP address of the machine where Open vSwitch
 268 is installed.
 269
 270 Verification
 271 ''''''''''''
 272
 273 In a shell execute: ``ovs-vsctl show``. There should be a Bridge with
 274 the name *br-test* and one port/interface called *br-test*.
 275
 276 Also, the corresponding SFF for this OVS Bridge should be configured,
 277 which can be verified through the SFC User Interface or RESTCONF as
 278 follows.
 279
 280 a. Visit the SFC User Interface:
 281    ``http://<odl_ip_address>:8181/sfc/index.html#/sfc/serviceforwarder``
 282
 283 b. Use pure RESTCONF and send a GET request to URL:
 284    ``http://<odl_ip_address>:8181/restconf/config/service-function-forwarder:service-function-forwarders``
 285
 286 There should be an SFF, whose name will be ending with *br1* and the
 287 SFF should contain two DataPlane locators: *br1* and *testPort*.
 288
 289
 290 SFC Classifier User Guide
 291 -------------------------
 292
 293 Overview
 294 ~~~~~~~~
 295
 296 Description of classifier can be found in:
 297 https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/
 298
 299 There are two types of classifier:
 300
 301 1. OpenFlow Classifier
 302
 303 2. Iptables Classifier
 304
 305 OpenFlow Classifier
 306 ~~~~~~~~~~~~~~~~~~~
 307
 308 OpenFlow Classifier implements the classification criteria based on
 309 OpenFlow rules deployed into an OpenFlow switch. An Open vSwitch will
 310 take the role of a classifier and performs various encapsulations such
 311 NSH, VLAN, MPLS, etc. In the existing implementation, classifier can
 312 support NSH encapsulation. Matching information is based on ACL for MAC
 313 addresses, ports, protocol, IPv4 and IPv6. Supported protocols are TCP,
 314 UDP and SCTP. Actions information in the OF rules, shall be forwarding
 315 of the encapsulated packets with specific information related to the
 316 RSP.
 317
 318 Classifier Architecture
 319 ^^^^^^^^^^^^^^^^^^^^^^^
 320
 321 The OVSDB Southbound interface is used to create an instance of a bridge
 322 in a specific location (via IP address). This bridge contains the
 323 OpenFlow rules that perform the classification of the packets and react
 324 accordingly. The OpenFlow Southbound interface is used to translate the
 325 ACL information into OF rules within the Open vSwitch.
 326
 327 .. note::
 328
 329     in order to create the instance of the bridge that takes the role of
 330     a classifier, an "empty" SFF must be created.
 331
 332 Configuring Classifier
 333 ^^^^^^^^^^^^^^^^^^^^^^
 334
 335 1. An empty SFF must be created in order to host the ACL that contains
 336    the classification information.
 337
 338 2. SFF data plane locator must be configured
 339
 340 3. Classifier interface must be manually added to SFF bridge.
 341
 342 Administering or Managing Classifier
 343 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 344
 345 Classification information is based on MAC addresses, protocol, ports
 346 and IP. ACL gathers this information and is assigned to an RSP which
 347 turns to be a specific path for a Service Chain.
 348
 349 Iptables Classifier
 350 ~~~~~~~~~~~~~~~~~~~
 351
 352 Classifier manages everything from starting the packet listener to
 353 creation (and removal) of appropriate ip(6)tables rules and marking
 354 received packets accordingly. Its functionality is **available only on
 355 Linux** as it leverdges **NetfilterQueue**, which provides access to
 356 packets matched by an **iptables** rule. Classifier requires **root
 357 privileges** to be able to operate.
 358
 359 So far it is capable of processing ACL for MAC addresses, ports, IPv4
 360 and IPv6. Supported protocols are TCP and UDP.
 361
 362 Classifier Architecture
 363 ^^^^^^^^^^^^^^^^^^^^^^^
 364
 365 Python code located in the project repository
 366 sfc-py/common/classifier.py.
 367
 368 .. note::
 369
 370     classifier assumes that Rendered Service Path (RSP) **already
 371     exists** in ODL when an ACL referencing it is obtained
 372
 373 1. sfc\_agent receives an ACL and passes it for processing to the
 374    classifier
 375
 376 2. the RSP (its SFF locator) referenced by ACL is requested from ODL
 377
 378 3. if the RSP exists in the ODL then ACL based iptables rules for it are
 379    applied
 380
 381 After this process is over, every packet successfully matched to an
 382 iptables rule (i.e. successfully classified) will be NSH encapsulated
 383 and forwarded to a related SFF, which knows how to traverse the RSP.
 384
 385 Rules are created using appropriate iptables command. If the Access
 386 Control Entry (ACE) rule is MAC address related both iptables and
 387 IPv6 tables rules re issued. If ACE rule is IPv4 address related, only
 388 iptables rules are issued, same for IPv6.
 389
 390 .. note::
 391
 392     iptables **raw** table contains all created rules
 393
 394 Configuring Classifier
 395 ^^^^^^^^^^^^^^^^^^^^^^
 396
 397 | Classfier does’t need any configuration.
 398 | Its only requirement is that the **second (2) Netfilter Queue** is not
 399   used by any other process and is **avalilable for the classifier**.
 400
 401 Administering or Managing Classifier
 402 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 403
 404 Classifier runs alongside sfc\_agent, therefore the command for starting
 405 it locally is:
 406
 407 .. code-block:: bash
 408
 409    sudo python3.4 sfc-py/sfc_agent.py --rest --odl-ip-port localhost:8181
 410    --auto-sff-name --nfq-class
 411
 412 SFC OpenFlow Renderer User Guide
 413 --------------------------------
 414
 415 Overview
 416 ~~~~~~~~
 417
 418 The Service Function Chaining (SFC) OpenFlow Renderer (SFC OF Renderer)
 419 implements Service Chaining on OpenFlow switches. It listens for the
 420 creation of a Rendered Service Path (RSP) in the operational data store,
 421 and once received it programs Service Function Forwarders (SFF) that
 422 are hosted on OpenFlow capable switches to forward packets through the
 423 service chain. Currently the only tested OpenFlow capable switch is
 424 OVS 2.9.
 425
 426 Common acronyms used in the following sections:
 427
 428 -  SF - Service Function
 429
 430 -  SFF - Service Function Forwarder
 431
 432 -  SFC - Service Function Chain
 433
 434 -  SFP - Service Function Path
 435
 436 -  RSP - Rendered Service Path
 437
 438 SFC OpenFlow Renderer Architecture
 439 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 440
 441 The SFC OF Renderer is invoked after a RSP is created in the operational
 442 data store using an MD-SAL listener called ``SfcOfRspDataListener``.
 443 Upon SFC OF Renderer initialization, the ``SfcOfRspDataListener``
 444 registers itself to listen for RSP changes. When invoked, the
 445 ``SfcOfRspDataListener`` processes the RSP and calls the
 446 ``SfcOfFlowProgrammerImpl`` to create the necessary flows in
 447 the Service Function Forwarders configured in the
 448 RSP. Refer to the following diagram for more details.
 449
 450 .. figure:: ./images/sfc/sfcofrenderer_architecture.png
 451    :alt: SFC OpenFlow Renderer High Level Architecture
 452
 453    SFC OpenFlow Renderer High Level Architecture
 454
 455 .. _sfc-user-guide-sfc-of-pipeline:
 456
 457 SFC OpenFlow Switch Flow pipeline
 458 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 459
 460 The SFC OpenFlow Renderer uses the following tables for its Flow
 461 pipeline:
 462
 463 -  Table 0, Classifier
 464
 465 -  Table 1, Transport Ingress
 466
 467 -  Table 2, Path Mapper
 468
 469 -  Table 3, Path Mapper ACL
 470
 471 -  Table 4, Next Hop
 472
 473 -  Table 10, Transport Egress
 474
 475 The OpenFlow Table Pipeline is intended to be generic to work for all of
 476 the different encapsulations supported by SFC.
 477
 478 All of the tables are explained in detail in the following section.
 479
 480 The SFFs (SFF1 and SFF2), SFs (SF1), and topology used for the flow
 481 tables in the following sections are as described in the following
 482 diagram.
 483
 484 .. figure:: ./images/sfc/sfcofrenderer_nwtopo.png
 485    :alt: SFC OpenFlow Renderer Typical Network Topology
 486
 487    SFC OpenFlow Renderer Typical Network Topology
 488
 489 Classifier Table detailed
 490 ^^^^^^^^^^^^^^^^^^^^^^^^^
 491
 492 It is possible for the SFF to also act as a classifier. This table maps
 493 subscriber traffic to RSPs, and is explained in detail in the classifier
 494 documentation.
 495
 496 If the SFF is not a classifier, then this table will just have a simple
 497 Goto Table 1 flow.
 498
 499 Transport Ingress Table detailed
 500 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 501
 502 The Transport Ingress table has an entry per expected tunnel transport
 503 type to be received in a particular SFF, as established in the SFC
 504 configuration.
 505
 506 Here are two example on SFF1: one where the RSP ingress tunnel is MPLS
 507 assuming VLAN is used for the SFF-SF, and the other where the RSP
 508 ingress tunnel is either Eth+NSH or just NSH with no ethernet.
 509
 510 +----------+-------------------------------------+--------------+
 511 | Priority | Match                               | Action       |
 512 +==========+=====================================+==============+
 513 | 256      | EtherType==0x8847 (MPLS unicast)    | Goto Table 2 |
 514 +----------+-------------------------------------+--------------+
 515 | 256      | EtherType==0x8100 (VLAN)            | Goto Table 2 |
 516 +----------+-------------------------------------+--------------+
 517 | 250      | EtherType==0x894f (Eth+NSH)         | Goto Table 2 |
 518 +----------+-------------------------------------+--------------+
 519 | 250      | PacketType==0x894f (NSH no Eth)     | Goto Table 2 |
 520 +----------+-------------------------------------+--------------+
 521 | 5        | Match Any                           | Drop         |
 522 +----------+-------------------------------------+--------------+
 523
 524
 525 Table: Table Transport Ingress
 526
 527 Path Mapper Table detailed
 528 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 529
 530 The Path Mapper table has an entry per expected tunnel transport info to
 531 be received in a particular SFF, as established in the SFC
 532 configuration. The tunnel transport info is used to determine the RSP
 533 Path ID, and is stored in the OpenFlow Metadata. This table is not used
 534 for NSH, since the RSP Path ID is stored in the NSH header.
 535
 536 For SF nodes that do not support NSH tunneling, the IP header DSCP field
 537 is used to store the RSP Path Id. The RSP Path Id is written to the DSCP
 538 field in the Transport Egress table for those packets sent to an SF.
 539
 540 Here is an example on SFF1, assuming the following details:
 541
 542 -  VLAN ID 1000 is used for the SFF-SF
 543
 544 -  The RSP Path 1 tunnel uses MPLS label 100 for ingress and 101 for
 545    egress
 546
 547 -  The RSP Path 2 (symmetric downlink path) uses MPLS label 101 for
 548    ingress and 100 for egress
 549
 550 +----------+-------------------+-----------------------+
 551 | Priority | Match             | Action                |
 552 +==========+===================+=======================+
 553 | 256      | MPLS Label==100   | RSP Path=1, Pop MPLS, |
 554 |          |                   | Goto Table 4          |
 555 +----------+-------------------+-----------------------+
 556 | 256      | MPLS Label==101   | RSP Path=2, Pop MPLS, |
 557 |          |                   | Goto Table 4          |
 558 +----------+-------------------+-----------------------+
 559 | 256      | VLAN ID==1000, IP | RSP Path=1, Pop VLAN, |
 560 |          | DSCP==1           | Goto Table 4          |
 561 +----------+-------------------+-----------------------+
 562 | 256      | VLAN ID==1000, IP | RSP Path=2, Pop VLAN, |
 563 |          | DSCP==2           | Goto Table 4          |
 564 +----------+-------------------+-----------------------+
 565 | 5        | Match Any         | Goto Table 3          |
 566 +----------+-------------------+-----------------------+
 567
 568 Table: Table Path Mapper
 569
 570 Path Mapper ACL Table detailed
 571 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 572
 573 This table is only populated when PacketIn packets are received from the
 574 switch for TcpProxy type SFs. These flows are created with an inactivity
 575 timer of 60 seconds and will be automatically deleted upon expiration.
 576
 577 Next Hop Table detailed
 578 ^^^^^^^^^^^^^^^^^^^^^^^
 579
 580 The Next Hop table uses the RSP Path Id and appropriate packet fields to
 581 determine where to send the packet next. For NSH, only the NSP (Network
 582 Services Path, RSP ID) and NSI (Network Services Index, next hop) fields
 583 from the NSH header are needed to determine the VXLAN tunnel destination
 584 IP. For VLAN or MPLS, then the source MAC address is used to determine
 585 the destination MAC address.
 586
 587 Here are two examples on SFF1, assuming SFF1 is connected to SFF2. RSP
 588 Paths 1 and 2 are symmetric VLAN paths. RSP Paths 3 and 4 are symmetric
 589 NSH paths. RSP Path 1 ingress packets come from external to SFC, for
 590 which we don’t have the source MAC address (MacSrc).
 591
 592 +----------+--------------------------------+--------------------------------+
 593 | Priority | Match                          | Action                         |
 594 +==========+================================+================================+
 595 | 256      | RSP Path==1, MacSrc==SF1       | MacDst=SFF2, Goto Table 10     |
 596 +----------+--------------------------------+--------------------------------+
 597 | 256      | RSP Path==2, MacSrc==SF1       | Goto Table 10                  |
 598 +----------+--------------------------------+--------------------------------+
 599 | 256      | RSP Path==2, MacSrc==SFF2      | MacDst=SF1, Goto Table 10      |
 600 +----------+--------------------------------+--------------------------------+
 601 | 246      | RSP Path==1                    | MacDst=SF1, Goto Table 10      |
 602 +----------+--------------------------------+--------------------------------+
 603 | 550      | dl_type=0x894f,                | load:0xa000002→                |
 604 |          | nsh_spi=3,nsh_si=255           | NXM\_NX\_TUN\_IPV4\_DST[],     |
 605 |          | (NSH, SFF Ingress RSP 3, hop 1)| Goto Table 10                  |
 606 +----------+--------------------------------+--------------------------------+
 607 | 550      | dl_type=0x894f                 | load:0xa00000a→                |
 608 |          | nsh_spi=3,nsh_si=254           | NXM\_NX\_TUN\_IPV4\_DST[],     |
 609 |          | (NSH, SFF Ingress from SF,     | Goto Table 10                  |
 610 |          | RSP 3, hop 2)                  |                                |
 611 +----------+--------------------------------+--------------------------------+
 612 | 550      | dl_type=0x894f,                | load:0xa00000a→                |
 613 |          | nsh_spi=4,nsh_si=254           | NXM\_NX\_TUN\_IPV4\_DST[],     |
 614 |          | (NSH, SFF1 Ingress from SFF2)  | Goto Table 10                  |
 615 +----------+--------------------------------+--------------------------------+
 616 | 5        | Match Any                      | Drop                           |
 617 +----------+--------------------------------+--------------------------------+
 618
 619 Table: Table Next Hop
 620
 621 Transport Egress Table detailed
 622 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 623
 624 The Transport Egress table prepares egress tunnel information and sends
 625 the packets out.
 626
 627 Here are two examples on SFF1. RSP Paths 1 and 2 are symmetric MPLS
 628 paths that use VLAN for the SFF-SF. RSP Paths 3 and 4 are symmetric NSH
 629 paths. Since it is assumed that switches used for NSH will only have one
 630 VXLAN port, the NSH packets are just sent back where they came from.
 631
 632 +----------+--------------------------------+--------------------------------+
 633 | Priority | Match                          | Action                         |
 634 +==========+================================+================================+
 635 | 256      | RSP Path==1, MacDst==SF1       | Push VLAN ID 1000, Port=SF1    |
 636 +----------+--------------------------------+--------------------------------+
 637 | 256      | RSP Path==1, MacDst==SFF2      | Push MPLS Label 101, Port=SFF2 |
 638 +----------+--------------------------------+--------------------------------+
 639 | 256      | RSP Path==2, MacDst==SF1       | Push VLAN ID 1000, Port=SF1    |
 640 +----------+--------------------------------+--------------------------------+
 641 | 246      | RSP Path==2                    | Push MPLS Label 100,           |
 642 |          |                                | Port=Ingress                   |
 643 +----------+--------------------------------+--------------------------------+
 644 | 256      | in_port=1,dl_type=0x894f       | IN\_PORT                       |
 645 |          | nsh_spi=0x3,nsh_si=255         |                                |
 646 |          | (NSH, SFF Ingress RSP 3)       |                                |
 647 +----------+--------------------------------+--------------------------------+
 648 | 256      | in_port=1,dl_type=0x894f,      | IN\_PORT                       |
 649 |          | nsh_spi=0x3,nsh_si=254         |                                |
 650 |          | (NSH,SFF Ingress from SF,RSP 3)|                                |
 651 +----------+--------------------------------+--------------------------------+
 652 | 256      | in_port=1,dl_type=0x894f,      | IN\_PORT                       |
 653 |          | nsh_spi=0x4,nsh_si=254         |                                |
 654 |          | (NSH, SFF1 Ingress from SFF2)  |                                |
 655 +---------+---------------------------------+--------------------------------+
 656 | 5       |  Match Any                      | Drop                           |
 657 +---------+---------------------------------+--------------------------------+
 658
 659 Table: Table Transport Egress
 660
 661 Administering SFC OF Renderer
 662 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 663
 664 To use the SFC OpenFlow Renderer Karaf, at least the following Karaf
 665 features must be installed.
 666
 667 -  odl-openflowplugin-nxm-extensions
 668
 669 -  odl-openflowplugin-flow-services
 670
 671 -  odl-sfc-provider
 672
 673 -  odl-sfc-model
 674
 675 -  odl-sfc-openflow-renderer
 676
 677 -  odl-sfc-ui (optional)
 678
 679 Since OpenDaylight Karaf features internally install dependent features
 680 all of the above features can be installed by simply installing the
 681 ''odl-sfc-openflow-renderer'' feature.
 682
 683 The following command can be used to view all of the currently installed
 684 Karaf features:
 685
 686 .. code-block:: bash
 687
 688    opendaylight-user@root>feature:list -i
 689
 690 Or, pipe the command to a grep to see a subset of the currently
 691 installed Karaf features:
 692
 693 .. code-block:: bash
 694
 695    opendaylight-user@root>feature:list -i | grep sfc
 696
 697 To install a particular feature, use the Karaf ``feature:install``
 698 command.
 699
 700 SFC OF Renderer Tutorial
 701 ~~~~~~~~~~~~~~~~~~~~~~~~
 702
 703 Overview
 704 ^^^^^^^^
 705
 706 In this tutorial, the VXLAN-GPE NSH encapsulations will be shown.
 707 The following Network Topology diagram is a logical view of the
 708 SFFs and SFs involved in creating the Service Chains.
 709
 710 .. figure:: ./images/sfc/sfcofrenderer_nwtopo.png
 711    :alt: SFC OpenFlow Renderer Typical Network Topology
 712
 713    SFC OpenFlow Renderer Typical Network Topology
 714
 715 Prerequisites
 716 ^^^^^^^^^^^^^
 717
 718 To use this example, SFF OpenFlow switches must be created and connected
 719 as illustrated above. Additionally, the SFs must be created and
 720 connected.
 721
 722 Note that RSP symmetry depends on the Service Function Path symmetric
 723 field, if present. If not, the RSP will be symmetric if any of the SFs
 724 involved in the chain has the bidirectional field set to true.
 725
 726 Target Environment
 727 ^^^^^^^^^^^^^^^^^^
 728
 729 The target environment is not important, but this use-case was created
 730 and tested on Linux.
 731
 732 Instructions
 733 ^^^^^^^^^^^^
 734
 735 The steps to use this tutorial are as follows. The referenced
 736 configuration in the steps is listed in the following sections.
 737
 738 There are numerous ways to send the configuration. In the following
 739 configuration chapters, the appropriate ``curl`` command is shown for
 740 each configuration to be sent, including the URL.
 741
 742 Steps to configure the SFC OF Renderer tutorial:
 743
 744 1. Send the ``SF`` RESTCONF configuration
 745
 746 2. Send the ``SFF`` RESTCONF configuration
 747
 748 3. Send the ``SFC`` RESTCONF configuration
 749
 750 4. Send the ``SFP`` RESTCONF configuration
 751
 752 5. The ``RSP`` will be created internally when the ``SFP`` is created.
 753
 754 Once the configuration has been successfully created, query the Rendered
 755 Service Paths with either the SFC UI or via RESTCONF. Notice that the
 756 RSP is symmetrical, so the following 2 RSPs will be created:
 757
 758 -  sfc-path1-Path-<RSP-ID>
 759
 760 -  sfc-path1-Path-<RSP-ID>-Reverse
 761
 762 At this point the Service Chains have been created, and the OpenFlow
 763 Switches are programmed to steer traffic through the Service Chain.
 764 Traffic can now be injected from a client into the Service Chain. To
 765 debug problems, the OpenFlow tables can be dumped with the following
 766 commands, assuming SFF1 is called ``s1`` and SFF2 is called ``s2``.
 767
 768 .. code-block:: bash
 769
 770    sudo ovs-ofctl -O OpenFlow13  dump-flows s1
 771
 772 .. code-block:: bash
 773
 774    sudo ovs-ofctl -O OpenFlow13  dump-flows s2
 775
 776 In all the following configuration sections, replace the ``${JSON}``
 777 string with the appropriate JSON configuration. Also, change the
 778 ``localhost`` destination in the URL accordingly.
 779
 780 SFC OF Renderer NSH Tutorial
 781 ''''''''''''''''''''''''''''
 782
 783 The following configuration sections show how to create the different
 784 elements using NSH encapsulation.
 785
 786 | **NSH Service Function configuration**
 787
 788 The Service Function configuration can be sent with the following
 789 command:
 790
 791 .. code-block:: bash
 792
 793    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
 794    --data '${JSON}' -X PUT --user
 795    admin:admin http://localhost:8181/restconf/config/service-function:service-functions/
 796
 797 **SF configuration JSON.**
 798
 799 .. code-block:: none
 800
 801     {
 802      "service-functions": {
 803        "service-function": [
 804          {
 805            "name": "sf1",
 806            "type": "http-header-enrichment",
 807            "ip-mgmt-address": "10.0.0.2",
 808            "sf-data-plane-locator": [
 809              {
 810                "name": "sf1dpl",
 811                "ip": "10.0.0.10",
 812                "port": 4789,
 813                "transport": "service-locator:vxlan-gpe",
 814                "service-function-forwarder": "sff1"
 815              }
 816            ]
 817          },
 818          {
 819            "name": "sf2",
 820            "type": "firewall",
 821            "ip-mgmt-address": "10.0.0.3",
 822            "sf-data-plane-locator": [
 823              {
 824                "name": "sf2dpl",
 825                 "ip": "10.0.0.20",
 826                 "port": 4789,
 827                 "transport": "service-locator:vxlan-gpe",
 828                "service-function-forwarder": "sff2"
 829              }
 830            ]
 831          }
 832        ]
 833      }
 834     }
 835
 836 | **NSH Service Function Forwarder configuration**
 837
 838 The Service Function Forwarder configuration can be sent with the
 839 following command:
 840
 841 .. code-block:: bash
 842
 843    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
 845 **SFF configuration JSON.**
 846
 847 .. code-block:: none
 848
 849     {
 850      "service-function-forwarders": {
 851        "service-function-forwarder": [
 852          {
 853            "name": "sff1",
 854            "service-node": "openflow:2",
 855            "sff-data-plane-locator": [
 856              {
 857                "name": "sff1dpl",
 858                "data-plane-locator":
 859                {
 860                    "ip": "10.0.0.1",
 861                    "port": 4789,
 862                    "transport": "service-locator:vxlan-gpe"
 863                }
 864              }
 865            ],
 866            "service-function-dictionary": [
 867              {
 868                "name": "sf1",
 869                "sff-sf-data-plane-locator":
 870                {
 871                    "sf-dpl-name": "sf1dpl",
 872                    "sff-dpl-name": "sff1dpl"
 873                }
 874              }
 875            ]
 876          },
 877          {
 878            "name": "sff2",
 879            "service-node": "openflow:3",
 880            "sff-data-plane-locator": [
 881              {
 882                "name": "sff2dpl",
 883                "data-plane-locator":
 884                {
 885                    "ip": "10.0.0.2",
 886                    "port": 4789,
 887                    "transport": "service-locator:vxlan-gpe"
 888                }
 889              }
 890            ],
 891            "service-function-dictionary": [
 892              {
 893                "name": "sf2",
 894                "sff-sf-data-plane-locator":
 895                {
 896                    "sf-dpl-name": "sf2dpl",
 897                    "sff-dpl-name": "sff2dpl"
 898                }
 899              }
 900            ]
 901          }
 902        ]
 903      }
 904     }
 905
 906 | **NSH Service Function Chain configuration**
 907
 908 The Service Function Chain configuration can be sent with the following
 909 command:
 910
 911 .. code-block:: bash
 912
 913    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
 914    --data '${JSON}' -X PUT --user
 915    admin:admin http://localhost:8181/restconf/config/service-function-chain:service-function-chains/
 916
 917 **SFC configuration JSON.**
 918
 919 .. code-block:: none
 920
 921     {
 922      "service-function-chains": {
 923        "service-function-chain": [
 924          {
 925            "name": "sfc-chain1",
 926            "sfc-service-function": [
 927              {
 928                "name": "hdr-enrich-abstract1",
 929                "type": "http-header-enrichment"
 930              },
 931              {
 932                "name": "firewall-abstract1",
 933                "type": "firewall"
 934              }
 935            ]
 936          }
 937        ]
 938      }
 939     }
 940
 941 | **NSH Service Function Path configuration**
 942
 943 The Service Function Path configuration can be sent with the following
 944 command:
 945
 946 .. code-block:: bash
 947
 948    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
 950 **SFP configuration JSON.**
 951
 952 .. code-block:: none
 953
 954     {
 955       "service-function-paths": {
 956         "service-function-path": [
 957           {
 958             "name": "sfc-path1",
 959             "service-chain-name": "sfc-chain1",
 960             "transport-type": "service-locator:vxlan-gpe",
 961             "symmetric": true
 962           }
 963         ]
 964       }
 965     }
 966
 967 | **NSH Rendered Service Path Query**
 968
 969 The following command can be used to query all of the created Rendered
 970 Service Paths:
 971
 972 .. code-block:: bash
 973
 974    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
 976 SFC OF Renderer MPLS Tutorial
 977 '''''''''''''''''''''''''''''
 978
 979 The following configuration sections show how to create the different
 980 elements using MPLS encapsulation.
 981
 982 | **MPLS Service Function configuration**
 983
 984 The Service Function configuration can be sent with the following
 985 command:
 986
 987 .. code-block:: bash
 988
 989    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
 990    --data '${JSON}' -X PUT --user
 991    admin:admin http://localhost:8181/restconf/config/service-function:service-functions/
 992
 993 **SF configuration JSON.**
 994
 995 .. code-block:: none
 996
 997     {
 998      "service-functions": {
 999        "service-function": [
1000          {
1001            "name": "sf1",
1002            "type": "http-header-enrichment",
1003            "ip-mgmt-address": "10.0.0.2",
1004            "sf-data-plane-locator": [
1005              {
1006                "name": "sf1-sff1",
1007                "mac": "00:00:08:01:02:01",
1008                "vlan-id": 1000,
1009                "transport": "service-locator:mac",
1010                "service-function-forwarder": "sff1"
1011              }
1012            ]
1013          },
1014          {
1015            "name": "sf2",
1016            "type": "firewall",
1017            "ip-mgmt-address": "10.0.0.3",
1018            "sf-data-plane-locator": [
1019              {
1020                "name": "sf2-sff2",
1021                "mac": "00:00:08:01:03:01",
1022                "vlan-id": 2000,
1023                "transport": "service-locator:mac",
1024                "service-function-forwarder": "sff2"
1025              }
1026            ]
1027          }
1028        ]
1029      }
1030     }
1031
1032 | **MPLS Service Function Forwarder configuration**
1033
1034 The Service Function Forwarder configuration can be sent with the
1035 following command:
1036
1037 .. code-block:: bash
1038
1039    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
1041 **SFF configuration JSON.**
1042
1043 .. code-block:: none
1044
1045     {
1046      "service-function-forwarders": {
1047        "service-function-forwarder": [
1048          {
1049            "name": "sff1",
1050            "service-node": "openflow:2",
1051            "sff-data-plane-locator": [
1052              {
1053                "name": "ulSff1Ingress",
1054                "data-plane-locator":
1055                {
1056                    "mpls-label": 100,
1057                    "transport": "service-locator:mpls"
1058                },
1059                "service-function-forwarder-ofs:ofs-port":
1060                {
1061                    "mac": "11:11:11:11:11:11",
1062                    "port-id" : "1"
1063                }
1064              },
1065              {
1066                "name": "ulSff1ToSff2",
1067                "data-plane-locator":
1068                {
1069                    "mpls-label": 101,
1070                    "transport": "service-locator:mpls"
1071                },
1072                "service-function-forwarder-ofs:ofs-port":
1073                {
1074                    "mac": "33:33:33:33:33:33",
1075                    "port-id" : "2"
1076                }
1077              },
1078              {
1079                "name": "toSf1",
1080                "data-plane-locator":
1081                {
1082                    "mac": "22:22:22:22:22:22",
1083                    "vlan-id": 1000,
1084                    "transport": "service-locator:mac",
1085                },
1086                "service-function-forwarder-ofs:ofs-port":
1087                {
1088                    "mac": "33:33:33:33:33:33",
1089                    "port-id" : "3"
1090                }
1091              }
1092            ],
1093            "service-function-dictionary": [
1094              {
1095                "name": "sf1",
1096                "sff-sf-data-plane-locator":
1097                {
1098                    "sf-dpl-name": "sf1-sff1",
1099                    "sff-dpl-name": "toSf1"
1100                }
1101              }
1102            ]
1103          },
1104          {
1105            "name": "sff2",
1106            "service-node": "openflow:3",
1107            "sff-data-plane-locator": [
1108              {
1109                "name": "ulSff2Ingress",
1110                "data-plane-locator":
1111                {
1112                    "mpls-label": 101,
1113                    "transport": "service-locator:mpls"
1114                },
1115                "service-function-forwarder-ofs:ofs-port":
1116                {
1117                    "mac": "44:44:44:44:44:44",
1118                    "port-id" : "1"
1119                }
1120              },
1121              {
1122                "name": "ulSff2Egress",
1123                "data-plane-locator":
1124                {
1125                    "mpls-label": 102,
1126                    "transport": "service-locator:mpls"
1127                },
1128                "service-function-forwarder-ofs:ofs-port":
1129                {
1130                    "mac": "66:66:66:66:66:66",
1131                    "port-id" : "2"
1132                }
1133              },
1134              {
1135                "name": "toSf2",
1136                "data-plane-locator":
1137                {
1138                    "mac": "55:55:55:55:55:55",
1139                    "vlan-id": 2000,
1140                    "transport": "service-locator:mac"
1141                },
1142                "service-function-forwarder-ofs:ofs-port":
1143                {
1144                    "port-id" : "3"
1145                }
1146              }
1147            ],
1148            "service-function-dictionary": [
1149              {
1150                "name": "sf2",
1151                "sff-sf-data-plane-locator":
1152                {
1153                    "sf-dpl-name": "sf2-sff2",
1154                    "sff-dpl-name": "toSf2"
1155
1156                },
1157                "service-function-forwarder-ofs:ofs-port":
1158                {
1159                    "port-id" : "3"
1160                }
1161              }
1162            ]
1163          }
1164        ]
1165      }
1166     }
1167
1168 | **MPLS Service Function Chain configuration**
1169
1170 The Service Function Chain configuration can be sent with the following
1171 command:
1172
1173 .. code-block:: bash
1174
1175    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
1176     --data '${JSON}' -X PUT --user admin:admin
1177     http://localhost:8181/restconf/config/service-function-chain:service-function-chains/
1178
1179 **SFC configuration JSON.**
1180
1181 .. code-block:: none
1182
1183     {
1184      "service-function-chains": {
1185        "service-function-chain": [
1186          {
1187            "name": "sfc-chain1",
1188            "sfc-service-function": [
1189              {
1190                "name": "hdr-enrich-abstract1",
1191                "type": "http-header-enrichment"
1192              },
1193              {
1194                "name": "firewall-abstract1",
1195                "type": "firewall"
1196              }
1197            ]
1198          }
1199        ]
1200      }
1201     }
1202
1203 | **MPLS Service Function Path configuration**
1204
1205 The Service Function Path configuration can be sent with the following
1206 command. This will internally trigger the Rendered Service Paths to be
1207 created.
1208
1209 .. code-block:: bash
1210
1211    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
1212    --data '${JSON}' -X PUT --user admin:admin
1213     http://localhost:8181/restconf/config/service-function-path:service-function-paths/
1214
1215 **SFP configuration JSON.**
1216
1217 .. code-block:: none
1218
1219     {
1220       "service-function-paths": {
1221         "service-function-path": [
1222           {
1223             "name": "sfc-path1",
1224             "service-chain-name": "sfc-chain1",
1225             "transport-type": "service-locator:mpls",
1226             "symmetric": true
1227           }
1228         ]
1229       }
1230     }
1231
1232 The following command can be used to query all of the Rendered Service
1233 Paths that were created when the Service Function Path was created:
1234
1235 .. code-block:: bash
1236
1237    curl -H "Content-Type: application/json" -H "Cache-Control: no-cache" -X GET
1238    --user admin:admin http://localhost:8181/restconf/operational/rendered-service-path:rendered-service-paths/
1239
1240 SFC IOS XE Renderer User Guide
1241 ------------------------------
1242
1243 Overview
1244 ~~~~~~~~
1245
1246 The early Service Function Chaining (SFC) renderer for IOS-XE devices
1247 (SFC IOS-XE renderer) implements Service Chaining functionality on
1248 IOS-XE capable switches. It listens for the creation of a Rendered
1249 Service Path (RSP) and sets up Service Function Forwarders (SFF) that
1250 are hosted on IOS-XE switches to steer traffic through the service
1251 chain.
1252
1253 Common acronyms used in the following sections:
1254
1255 -  SF - Service Function
1256
1257 -  SFF - Service Function Forwarder
1258
1259 -  SFC - Service Function Chain
1260
1261 -  SP - Service Path
1262
1263 -  SFP - Service Function Path
1264
1265 -  RSP - Rendered Service Path
1266
1267 -  LSF - Local Service Forwarder
1268
1269 -  RSF - Remote Service Forwarder
1270
1271 SFC IOS-XE Renderer Architecture
1272 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1273
1274 When the SFC IOS-XE renderer is initialized, all required listeners are
1275 registered to handle incoming data. It involves CSR/IOS-XE
1276 ``NodeListener`` which stores data about all configurable devices
1277 including their mountpoints (used here as databrokers),
1278 ``ServiceFunctionListener``, ``ServiceForwarderListener`` (see mapping)
1279 and ``RenderedPathListener`` used to listen for RSP changes. When the
1280 SFC IOS-XE renderer is invoked, ``RenderedPathListener`` calls the
1281 ``IosXeRspProcessor`` which processes the RSP change and creates all
1282 necessary Service Paths and Remote Service Forwarders (if necessary) on
1283 IOS-XE devices.
1284
1285 Service Path details
1286 ~~~~~~~~~~~~~~~~~~~~
1287
1288 Each Service Path is defined by index (represented by NSP) and contains
1289 service path entries. Each entry has appropriate service index (NSI) and
1290 definition of next hop. Next hop can be Service Function, different
1291 Service Function Forwarder or definition of end of chain - terminate.
1292 After terminating, the packet is sent to destination. If a SFF is
1293 defined as a next hop, it has to be present on device in the form of
1294 Remote Service Forwarder. RSFs are also created during RSP processing.
1295
1296 Example of Service Path:
1297
1298 ::
1299
1300     service-chain service-path 200
1301        service-index 255 service-function firewall-1
1302        service-index 254 service-function dpi-1
1303        service-index 253 terminate
1304
1305 Mapping to IOS-XE SFC entities
1306 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1307
1308 Renderer contains mappers for SFs and SFFs. IOS-XE capable device is
1309 using its own definition of Service Functions and Service Function
1310 Forwarders according to appropriate .yang file.
1311 ``ServiceFunctionListener`` serves as a listener for SF changes. If SF
1312 appears in datastore, listener extracts its management ip address and
1313 looks into cached IOS-XE nodes. If some of available nodes match,
1314 Service function is mapped in ``IosXeServiceFunctionMapper`` to be
1315 understandable by IOS-XE device and it’s written into device’s config.
1316 ``ServiceForwarderListener`` is used in a similar way. All SFFs with
1317 suitable management ip address it mapped in
1318 ``IosXeServiceForwarderMapper``. Remapped SFFs are configured as a Local
1319 Service Forwarders. It is not possible to directly create Remote Service
1320 Forwarder using IOS-XE renderer. RSF is created only during RSP
1321 processing.
1322
1323 Administering SFC IOS-XE renderer
1324 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1325
1326 To use the SFC IOS-XE Renderer Karaf, at least the following Karaf
1327 features must be installed:
1328
1329 -  odl-aaa-shiro
1330
1331 -  odl-sfc-model
1332
1333 -  odl-sfc-provider
1334
1335 -  odl-restconf
1336
1337 -  odl-netconf-topology
1338
1339 -  odl-sfc-ios-xe-renderer
1340
1341 SFC IOS-XE renderer Tutorial
1342 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1343
1344 Overview
1345 ^^^^^^^^
1346
1347 This tutorial is a simple example how to create Service Path on IOS-XE
1348 capable device using IOS-XE renderer
1349
1350 Preconditions
1351 ^^^^^^^^^^^^^
1352
1353 To connect to IOS-XE device, it is necessary to use several modified
1354 yang models and override device’s ones. All .yang files are in the
1355 ``Yang/netconf`` folder in the ``sfc-ios-xe-renderer module`` in the SFC
1356 project. These files have to be copied to the ``cache/schema``
1357 directory, before Karaf is started. After that, custom capabilities have
1358 to be sent to network-topology:
1359
1360 *  PUT ./config/network-topology:network-topology/topology/topology-netconf/node/<device-name>
1361
1362    .. code-block:: xml
1363
1364     <node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
1365       <node-id>device-name</node-id>
1366       <host xmlns="urn:opendaylight:netconf-node-topology">device-ip</host>
1367       <port xmlns="urn:opendaylight:netconf-node-topology">2022</port>
1368       <username xmlns="urn:opendaylight:netconf-node-topology">login</username>
1369       <password xmlns="urn:opendaylight:netconf-node-topology">password</password>
1370       <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
1371       <keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">0</keepalive-delay>
1372       <yang-module-capabilities xmlns="urn:opendaylight:netconf-node-topology">
1373          <override>true</override>
1374          <capability xmlns="urn:opendaylight:netconf-node-topology">
1375             urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&amp;revision=2013-07-15
1376          </capability>
1377          <capability xmlns="urn:opendaylight:netconf-node-topology">
1378             urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&amp;revision=2013-07-15
1379          </capability>
1380          <capability xmlns="urn:opendaylight:netconf-node-topology">
1381             urn:ios?module=ned&amp;revision=2016-03-08
1382          </capability>
1383          <capability xmlns="urn:opendaylight:netconf-node-topology">
1384             http://tail-f.com/yang/common?module=tailf-common&amp;revision=2015-05-22
1385          </capability>
1386          <capability xmlns="urn:opendaylight:netconf-node-topology">
1387             http://tail-f.com/yang/common?module=tailf-meta-extensions&amp;revision=2013-11-07
1388          </capability>
1389          <capability xmlns="urn:opendaylight:netconf-node-topology">
1390             http://tail-f.com/yang/common?module=tailf-cli-extensions&amp;revision=2015-03-19
1391          </capability>
1392       </yang-module-capabilities>
1393     </node>
1394
1395 .. note::
1396
1397     The device name in the URL and in the XML must match.
1398
1399 Instructions
1400 ^^^^^^^^^^^^
1401
1402 When the IOS-XE renderer is installed, all NETCONF nodes in
1403 topology-netconf are processed and all capable nodes with accessible
1404 mountpoints are cached. The first step is to create LSF on node.
1405
1406 ``Service Function Forwarder configuration``
1407
1408 *  PUT ./config/service-function-forwarder:service-function-forwarders
1409
1410    .. code-block:: none
1411
1412     {
1413         "service-function-forwarders": {
1414             "service-function-forwarder": [
1415                 {
1416                     "name": "CSR1Kv-2",
1417                     "ip-mgmt-address": "172.25.73.23",
1418                     "sff-data-plane-locator": [
1419                         {
1420                             "name": "CSR1Kv-2-dpl",
1421                             "data-plane-locator": {
1422                                 "transport": "service-locator:vxlan-gpe",
1423                                 "port": 6633,
1424                                 "ip": "10.99.150.10"
1425                             }
1426                         }
1427                     ]
1428                 }
1429             ]
1430         }
1431     }
1432
1433 If the IOS-XE node with appropriate management IP exists, this
1434 configuration is mapped and LSF is created on the device. The same
1435 approach is used for Service Functions.
1436
1437 *  PUT ./config/service-function:service-functions
1438
1439    .. code-block:: none
1440
1441     {
1442         "service-functions": {
1443             "service-function": [
1444                 {
1445                     "name": "Firewall",
1446                     "ip-mgmt-address": "172.25.73.23",
1447                     "type": "firewall",
1448                     "sf-data-plane-locator": [
1449                         {
1450                             "name": "firewall-dpl",
1451                             "port": 6633,
1452                             "ip": "12.1.1.2",
1453                             "transport": "service-locator:gre",
1454                             "service-function-forwarder": "CSR1Kv-2"
1455                         }
1456                     ]
1457                 },
1458                 {
1459                     "name": "Dpi",
1460                     "ip-mgmt-address": "172.25.73.23",
1461                     "type":"dpi",
1462                     "sf-data-plane-locator": [
1463                         {
1464                             "name": "dpi-dpl",
1465                             "port": 6633,
1466                             "ip": "12.1.1.1",
1467                             "transport": "service-locator:gre",
1468                             "service-function-forwarder": "CSR1Kv-2"
1469                         }
1470                     ]
1471                 },
1472                 {
1473                     "name": "Qos",
1474                     "ip-mgmt-address": "172.25.73.23",
1475                     "type":"qos",
1476                     "sf-data-plane-locator": [
1477                         {
1478                             "name": "qos-dpl",
1479                             "port": 6633,
1480                             "ip": "12.1.1.4",
1481                             "transport": "service-locator:gre",
1482                             "service-function-forwarder": "CSR1Kv-2"
1483                         }
1484                     ]
1485                 }
1486             ]
1487         }
1488     }
1489
1490 All these SFs are configured on the same device as the LSF. The next
1491 step is to prepare Service Function Chain.
1492
1493 *  PUT ./config/service-function-chain:service-function-chains/
1494
1495    .. code-block:: none
1496
1497     {
1498         "service-function-chains": {
1499             "service-function-chain": [
1500                 {
1501                     "name": "CSR3XSF",
1502                     "sfc-service-function": [
1503                         {
1504                             "name": "Firewall",
1505                             "type": "firewall"
1506                         },
1507                         {
1508                             "name": "Dpi",
1509                             "type": "dpi"
1510                         },
1511                         {
1512                             "name": "Qos",
1513                             "type": "qos"
1514                         }
1515                     ]
1516                 }
1517             ]
1518         }
1519     }
1520
1521 Service Function Path:
1522
1523 *  PUT ./config/service-function-path:service-function-paths/
1524
1525    .. code-block:: none
1526
1527     {
1528         "service-function-paths": {
1529             "service-function-path": [
1530                 {
1531                     "name": "CSR3XSF-Path",
1532                     "service-chain-name": "CSR3XSF",
1533                     "starting-index": 255,
1534                     "symmetric": "true"
1535                 }
1536             ]
1537         }
1538     }
1539
1540 Without a classifier, there is possibility to POST RSP directly.
1541
1542 *  POST ./operations/rendered-service-path:create-rendered-path
1543
1544    .. code-block:: none
1545
1546     {
1547       "input": {
1548           "name": "CSR3XSF-Path-RSP",
1549           "parent-service-function-path": "CSR3XSF-Path"
1550       }
1551     }
1552
1553 The resulting configuration:
1554
1555 ::
1556
1557     !
1558     service-chain service-function-forwarder local
1559       ip address 10.99.150.10
1560     !
1561     service-chain service-function firewall
1562     ip address 12.1.1.2
1563       encapsulation gre enhanced divert
1564     !
1565     service-chain service-function dpi
1566     ip address 12.1.1.1
1567       encapsulation gre enhanced divert
1568     !
1569     service-chain service-function qos
1570     ip address 12.1.1.4
1571       encapsulation gre enhanced divert
1572     !
1573     service-chain service-path 1
1574       service-index 255 service-function firewall
1575       service-index 254 service-function dpi
1576       service-index 253 service-function qos
1577       service-index 252 terminate
1578     !
1579     service-chain service-path 2
1580       service-index 255 service-function qos
1581       service-index 254 service-function dpi
1582       service-index 253 service-function firewall
1583       service-index 252 terminate
1584     !
1585
1586 Service Path 1 is direct, Service Path 2 is reversed. Path numbers may
1587 vary.
1588
1589 Service Function Scheduling Algorithms
1590 --------------------------------------
1591
1592 Overview
1593 ~~~~~~~~
1594
1595 When creating the Rendered Service Path, the origin SFC controller chose
1596 the first available service function from a list of service function
1597 names. This may result in many issues such as overloaded service
1598 functions and a longer service path as SFC has no means to understand
1599 the status of service functions and network topology. The service
1600 function selection framework supports at least four algorithms (Random,
1601 Round Robin, Load Balancing and Shortest Path) to select the most
1602 appropriate service function when instantiating the Rendered Service
1603 Path. In addition, it is an extensible framework that allows 3rd party
1604 selection algorithm to be plugged in.
1605
1606 Architecture
1607 ~~~~~~~~~~~~
1608
1609 The following figure illustrates the service function selection
1610 framework and algorithms.
1611
1612 .. figure:: ./images/sfc/sf-selection-arch.png
1613    :alt: SF Selection Architecture
1614
1615    SF Selection Architecture
1616
1617 A user has three different ways to select one service function selection
1618 algorithm:
1619
1620 1. Integrated RESTCONF Calls. OpenStack and/or other administration
1621    system could provide plugins to call the APIs to select one
1622    scheduling algorithm.
1623
1624 2. Command line tools. Command line tools such as curl or browser
1625    plugins such as POSTMAN (for Google Chrome) and RESTClient (for
1626    Mozilla Firefox) could select schedule algorithm by making RESTCONF
1627    calls.
1628
1629 3. SFC-UI. Now the SFC-UI provides an option for choosing a selection
1630    algorithm when creating a Rendered Service Path.
1631
1632 The RESTCONF northbound SFC API provides GUI/RESTCONF interactions for
1633 choosing the service function selection algorithm. MD-SAL data store
1634 provides all supported service function selection algorithms, and
1635 provides APIs to enable one of the provided service function selection
1636 algorithms. Once a service function selection algorithm is enabled, the
1637 service function selection algorithm will work when creating a Rendered
1638 Service Path.
1639
1640 Select SFs with Scheduler
1641 ~~~~~~~~~~~~~~~~~~~~~~~~~
1642
1643 Administrator could use both the following ways to select one of the
1644 selection algorithm when creating a Rendered Service Path.
1645
1646 -  Command line tools. Command line tools includes Linux commands curl
1647    or even browser plugins such as POSTMAN(for Google Chrome) or
1648    RESTClient(for Mozilla Firefox). In this case, the following JSON
1649    content is needed at the moment:
1650    Service\_function\_schudule\_type.json
1651
1652    .. code-block:: none
1653
1654        {
1655          "service-function-scheduler-types": {
1656            "service-function-scheduler-type": [
1657              {
1658                "name": "random",
1659                "type": "service-function-scheduler-type:random",
1660                "enabled": false
1661              },
1662              {
1663                "name": "roundrobin",
1664                "type": "service-function-scheduler-type:round-robin",
1665                "enabled": true
1666              },
1667              {
1668                "name": "loadbalance",
1669                "type": "service-function-scheduler-type:load-balance",
1670                "enabled": false
1671              },
1672              {
1673                "name": "shortestpath",
1674                "type": "service-function-scheduler-type:shortest-path",
1675                "enabled": false
1676              }
1677            ]
1678          }
1679        }
1680
1681    If using the Linux curl command, it could be:
1682
1683    .. code-block:: bash
1684
1685       curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
1686       --data '$${Service_function_schudule_type.json}' -X PUT
1687       --user admin:admin http://localhost:8181/restconf/config/service-function-scheduler-type:service-function-scheduler-types/
1688
1689
1690 Here is also a snapshot for using the RESTClient plugin:
1691
1692 .. figure:: ./images/sfc/RESTClient-snapshot.png
1693    :alt: Mozilla Firefox RESTClient
1694
1695    Mozilla Firefox RESTClient
1696
1697 -  SFC-UI.SFC-UI provides a drop down menu for service function
1698    selection algorithm. Here is a snapshot for the user interaction from
1699    SFC-UI when creating a Rendered Service Path.
1700
1701 .. figure:: ./images/sfc/karaf-webui-select-a-type.png
1702    :alt: Karaf Web UI
1703
1704    Karaf Web UI
1705
1706 .. note::
1707
1708     Some service function selection algorithms in the drop list are not
1709     implemented yet. Only the first three algorithms are committed at
1710     the moment.
1711
1712 Random
1713 ^^^^^^
1714
1715 Select Service Function from the name list randomly.
1716
1717 Overview
1718 ''''''''
1719
1720 The Random algorithm is used to select one Service Function from the
1721 name list which it gets from the Service Function Type randomly.
1722
1723 Prerequisites
1724 '''''''''''''
1725
1726 -  Service Function information are stored in datastore.
1727
1728 -  Either no algorithm or the Random algorithm is selected.
1729
1730 Target Environment
1731 ''''''''''''''''''
1732
1733 The Random algorithm will work either no algorithm type is selected or
1734 the Random algorithm is selected.
1735
1736 Instructions
1737 ''''''''''''
1738
1739 Once the plugins are installed into Karaf successfully, a user can use
1740 his favorite method to select the Random scheduling algorithm type.
1741 There are no special instructions for using the Random algorithm.
1742
1743 Round Robin
1744 ^^^^^^^^^^^
1745
1746 Select Service Function from the name list in Round Robin manner.
1747
1748 Overview
1749 ''''''''
1750
1751 The Round Robin algorithm is used to select one Service Function from
1752 the name list which it gets from the Service Function Type in a Round
1753 Robin manner, this will balance workloads to all Service Functions.
1754 However, this method cannot help all Service Functions load the same
1755 workload because it’s flow-based Round Robin.
1756
1757 Prerequisites
1758 '''''''''''''
1759
1760 -  Service Function information are stored in datastore.
1761
1762 -  Round Robin algorithm is selected
1763
1764 Target Environment
1765 ''''''''''''''''''
1766
1767 The Round Robin algorithm will work one the Round Robin algorithm is
1768 selected.
1769
1770 Instructions
1771 ''''''''''''
1772
1773 Once the plugins are installed into Karaf successfully, a user can use
1774 his favorite method to select the Round Robin scheduling algorithm type.
1775 There are no special instructions for using the Round Robin algorithm.
1776
1777 Load Balance Algorithm
1778 ^^^^^^^^^^^^^^^^^^^^^^
1779
1780 Select appropriate Service Function by actual CPU utilization.
1781
1782 Overview
1783 ''''''''
1784
1785 The Load Balance Algorithm is used to select appropriate Service
1786 Function by actual CPU utilization of service functions. The CPU
1787 utilization of service function obtained from monitoring information
1788 reported via NETCONF.
1789
1790 Prerequisites
1791 '''''''''''''
1792
1793 -  CPU-utilization for Service Function.
1794
1795 -  NETCONF server.
1796
1797 -  NETCONF client.
1798
1799 -  Each VM has a NETCONF server and it could work with NETCONF client
1800    well.
1801
1802 Instructions
1803 ''''''''''''
1804
1805 Set up VMs as Service Functions. enable NETCONF server in VMs. Ensure
1806 that you specify them separately. For example:
1807
1808 a. Set up 4 VMs include 2 SFs' type are Firewall, Others are Napt44.
1809    Name them as firewall-1, firewall-2, napt44-1, napt44-2 as Service
1810    Function. The four VMs can run either the same server or different
1811    servers.
1812
1813 b. Install NETCONF server on every VM and enable it. More information on
1814    NETCONF can be found on the OpenDaylight wiki here:
1815    https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf:Manual_netopeer_installation
1816
1817 c. Get Monitoring data from NETCONF server. These monitoring data should
1818    be get from the NETCONF server which is running in VMs. The following
1819    static XML data is an example:
1820
1821 static XML data like this:
1822
1823 .. code-block:: xml
1824
1825     <?xml version="1.0" encoding="UTF-8"?>
1826     <service-function-description-monitor-report>
1827       <SF-description>
1828         <number-of-dataports>2</number-of-dataports>
1829         <capabilities>
1830           <supported-packet-rate>5</supported-packet-rate>
1831           <supported-bandwidth>10</supported-bandwidth>
1832           <supported-ACL-number>2000</supported-ACL-number>
1833           <RIB-size>200</RIB-size>
1834           <FIB-size>100</FIB-size>
1835           <ports-bandwidth>
1836             <port-bandwidth>
1837               <port-id>1</port-id>
1838               <ipaddress>10.0.0.1</ipaddress>
1839               <macaddress>00:1e:67:a2:5f:f4</macaddress>
1840               <supported-bandwidth>20</supported-bandwidth>
1841             </port-bandwidth>
1842             <port-bandwidth>
1843               <port-id>2</port-id>
1844               <ipaddress>10.0.0.2</ipaddress>
1845               <macaddress>01:1e:67:a2:5f:f6</macaddress>
1846               <supported-bandwidth>10</supported-bandwidth>
1847             </port-bandwidth>
1848           </ports-bandwidth>
1849         </capabilities>
1850       </SF-description>
1851       <SF-monitoring-info>
1852         <liveness>true</liveness>
1853         <resource-utilization>
1854             <packet-rate-utilization>10</packet-rate-utilization>
1855             <bandwidth-utilization>15</bandwidth-utilization>
1856             <CPU-utilization>12</CPU-utilization>
1857             <memory-utilization>17</memory-utilization>
1858             <available-memory>8</available-memory>
1859             <RIB-utilization>20</RIB-utilization>
1860             <FIB-utilization>25</FIB-utilization>
1861             <power-utilization>30</power-utilization>
1862             <SF-ports-bandwidth-utilization>
1863               <port-bandwidth-utilization>
1864                 <port-id>1</port-id>
1865                 <bandwidth-utilization>20</bandwidth-utilization>
1866               </port-bandwidth-utilization>
1867               <port-bandwidth-utilization>
1868                 <port-id>2</port-id>
1869                 <bandwidth-utilization>30</bandwidth-utilization>
1870               </port-bandwidth-utilization>
1871             </SF-ports-bandwidth-utilization>
1872         </resource-utilization>
1873       </SF-monitoring-info>
1874     </service-function-description-monitor-report>
1875
1876 a. Unzip SFC release tarball.
1877
1878 b. Run SFC: ${sfc}/bin/karaf. More information on Service Function
1879    Chaining can be found on the OpenDaylight SFC’s wiki page:
1880    https://wiki.opendaylight.org/view/Service_Function_Chaining:Main
1881
1882 a. Deploy the SFC2 (firewall-abstract2⇒napt44-abstract2) and click
1883    button to Create Rendered Service Path in SFC UI
1884    (http://localhost:8181/sfc/index.html).
1885
1886 b. Verify the Rendered Service Path to ensure the CPU utilization of the
1887    selected hop is the minimum one among all the service functions with
1888    same type. The correct RSP is firewall-1⇒napt44-2
1889
1890 Shortest Path Algorithm
1891 ^^^^^^^^^^^^^^^^^^^^^^^
1892
1893 Select appropriate Service Function by Dijkstra’s algorithm. Dijkstra’s
1894 algorithm is an algorithm for finding the shortest paths between nodes
1895 in a graph.
1896
1897 Overview
1898 ''''''''
1899
1900 The Shortest Path Algorithm is used to select appropriate Service
1901 Function by actual topology.
1902
1903 Prerequisites
1904 '''''''''''''
1905
1906 -  Deployed topology (include SFFs, SFs and their links).
1907
1908 -  Dijkstra’s algorithm. More information on Dijkstra’s algorithm can be
1909    found on the wiki here:
1910    http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm
1911
1912 Instructions
1913 ''''''''''''
1914
1915 a. Unzip SFC release tarball.
1916
1917 b. Run SFC: ${sfc}/bin/karaf.
1918
1919 c. Depoly SFFs and SFs. import the service-function-forwarders.json and
1920    service-functions.json in UI
1921    (http://localhost:8181/sfc/index.html#/sfc/config)
1922
1923 service-function-forwarders.json:
1924
1925 .. code-block:: none
1926
1927     {
1928       "service-function-forwarders": {
1929         "service-function-forwarder": [
1930           {
1931             "name": "SFF-br1",
1932             "service-node": "OVSDB-test01",
1933             "rest-uri": "http://localhost:5001",
1934             "sff-data-plane-locator": [
1935               {
1936                 "name": "eth0",
1937                 "service-function-forwarder-ovs:ovs-bridge": {
1938                   "uuid": "4c3778e4-840d-47f4-b45e-0988e514d26c",
1939                   "bridge-name": "br-tun"
1940                 },
1941                 "data-plane-locator": {
1942                   "port": 5000,
1943                   "ip": "192.168.1.1",
1944                   "transport": "service-locator:vxlan-gpe"
1945                 }
1946               }
1947             ],
1948             "service-function-dictionary": [
1949               {
1950                 "sff-sf-data-plane-locator": {
1951                    "sf-dpl-name": "sf1dpl",
1952                    "sff-dpl-name": "sff1dpl"
1953                 },
1954                 "name": "napt44-1",
1955                 "type": "napt44"
1956               },
1957               {
1958                 "sff-sf-data-plane-locator": {
1959                    "sf-dpl-name": "sf2dpl",
1960                    "sff-dpl-name": "sff2dpl"
1961                 },
1962                 "name": "firewall-1",
1963                 "type": "firewall"
1964               }
1965             ],
1966             "connected-sff-dictionary": [
1967               {
1968                 "name": "SFF-br3"
1969               }
1970             ]
1971           },
1972           {
1973             "name": "SFF-br2",
1974             "service-node": "OVSDB-test01",
1975             "rest-uri": "http://localhost:5002",
1976             "sff-data-plane-locator": [
1977               {
1978                 "name": "eth0",
1979                 "service-function-forwarder-ovs:ovs-bridge": {
1980                   "uuid": "fd4d849f-5140-48cd-bc60-6ad1f5fc0a1",
1981                   "bridge-name": "br-tun"
1982                 },
1983                 "data-plane-locator": {
1984                   "port": 5000,
1985                   "ip": "192.168.1.2",
1986                   "transport": "service-locator:vxlan-gpe"
1987                 }
1988               }
1989             ],
1990             "service-function-dictionary": [
1991               {
1992                 "sff-sf-data-plane-locator": {
1993                    "sf-dpl-name": "sf1dpl",
1994                    "sff-dpl-name": "sff1dpl"
1995                 },
1996                 "name": "napt44-2",
1997                 "type": "napt44"
1998               },
1999               {
2000                 "sff-sf-data-plane-locator": {
2001                    "sf-dpl-name": "sf2dpl",
2002                    "sff-dpl-name": "sff2dpl"
2003                 },
2004                 "name": "firewall-2",
2005                 "type": "firewall"
2006               }
2007             ],
2008             "connected-sff-dictionary": [
2009               {
2010                 "name": "SFF-br3"
2011               }
2012             ]
2013           },
2014           {
2015             "name": "SFF-br3",
2016             "service-node": "OVSDB-test01",
2017             "rest-uri": "http://localhost:5005",
2018             "sff-data-plane-locator": [
2019               {
2020                 "name": "eth0",
2021                 "service-function-forwarder-ovs:ovs-bridge": {
2022                   "uuid": "fd4d849f-5140-48cd-bc60-6ad1f5fc0a4",
2023                   "bridge-name": "br-tun"
2024                 },
2025                 "data-plane-locator": {
2026                   "port": 5000,
2027                   "ip": "192.168.1.2",
2028                   "transport": "service-locator:vxlan-gpe"
2029                 }
2030               }
2031             ],
2032             "service-function-dictionary": [
2033               {
2034                 "sff-sf-data-plane-locator": {
2035                    "sf-dpl-name": "sf1dpl",
2036                    "sff-dpl-name": "sff1dpl"
2037                 },
2038                 "name": "test-server",
2039                 "type": "dpi"
2040               },
2041               {
2042                 "sff-sf-data-plane-locator": {
2043                    "sf-dpl-name": "sf2dpl",
2044                    "sff-dpl-name": "sff2dpl"
2045                 },
2046                 "name": "test-client",
2047                 "type": "dpi"
2048               }
2049             ],
2050             "connected-sff-dictionary": [
2051               {
2052                 "name": "SFF-br1"
2053               },
2054               {
2055                 "name": "SFF-br2"
2056               }
2057             ]
2058           }
2059         ]
2060       }
2061     }
2062
2063 service-functions.json:
2064
2065 .. code-block:: none
2066
2067     {
2068       "service-functions": {
2069         "service-function": [
2070           {
2071             "rest-uri": "http://localhost:10001",
2072             "ip-mgmt-address": "10.3.1.103",
2073             "sf-data-plane-locator": [
2074               {
2075                 "name": "preferred",
2076                 "port": 10001,
2077                 "ip": "10.3.1.103",
2078                 "service-function-forwarder": "SFF-br1"
2079               }
2080             ],
2081             "name": "napt44-1",
2082             "type": "napt44"
2083           },
2084           {
2085             "rest-uri": "http://localhost:10002",
2086             "ip-mgmt-address": "10.3.1.103",
2087             "sf-data-plane-locator": [
2088               {
2089                 "name": "master",
2090                 "port": 10002,
2091                 "ip": "10.3.1.103",
2092                 "service-function-forwarder": "SFF-br2"
2093               }
2094             ],
2095             "name": "napt44-2",
2096             "type": "napt44"
2097           },
2098           {
2099             "rest-uri": "http://localhost:10003",
2100             "ip-mgmt-address": "10.3.1.103",
2101             "sf-data-plane-locator": [
2102               {
2103                 "name": "1",
2104                 "port": 10003,
2105                 "ip": "10.3.1.102",
2106                 "service-function-forwarder": "SFF-br1"
2107               }
2108             ],
2109             "name": "firewall-1",
2110             "type": "firewall"
2111           },
2112           {
2113             "rest-uri": "http://localhost:10004",
2114             "ip-mgmt-address": "10.3.1.103",
2115             "sf-data-plane-locator": [
2116               {
2117                 "name": "2",
2118                 "port": 10004,
2119                 "ip": "10.3.1.101",
2120                 "service-function-forwarder": "SFF-br2"
2121               }
2122             ],
2123             "name": "firewall-2",
2124             "type": "firewall"
2125           },
2126           {
2127             "rest-uri": "http://localhost:10005",
2128             "ip-mgmt-address": "10.3.1.103",
2129             "sf-data-plane-locator": [
2130               {
2131                 "name": "3",
2132                 "port": 10005,
2133                 "ip": "10.3.1.104",
2134                 "service-function-forwarder": "SFF-br3"
2135               }
2136             ],
2137             "name": "test-server",
2138             "type": "dpi"
2139           },
2140           {
2141             "rest-uri": "http://localhost:10006",
2142             "ip-mgmt-address": "10.3.1.103",
2143             "sf-data-plane-locator": [
2144               {
2145                 "name": "4",
2146                 "port": 10006,
2147                 "ip": "10.3.1.102",
2148                 "service-function-forwarder": "SFF-br3"
2149               }
2150             ],
2151             "name": "test-client",
2152             "type": "dpi"
2153           }
2154         ]
2155       }
2156     }
2157
2158 The deployed topology like this:
2159
2160 .. code-block:: none
2161
2162                   +----+           +----+          +----+
2163                   |sff1|+----------|sff3|---------+|sff2|
2164                   +----+           +----+          +----+
2165                     |                                  |
2166              +--------------+                   +--------------+
2167              |              |                   |              |
2168         +----------+   +--------+          +----------+   +--------+
2169         |firewall-1|   |napt44-1|          |firewall-2|   |napt44-2|
2170         +----------+   +--------+          +----------+   +--------+
2171
2172 -  Deploy the SFC2(firewall-abstract2⇒napt44-abstract2), select
2173    "Shortest Path" as schedule type and click button to Create Rendered
2174    Service Path in SFC UI (http://localhost:8181/sfc/index.html).
2175
2176 .. figure:: ./images/sfc/sf-schedule-type.png
2177    :alt: select schedule type
2178
2179    select schedule type
2180
2181 -  Verify the Rendered Service Path to ensure the selected hops are
2182    linked in one SFF. The correct RSP is firewall-1⇒napt44-1 or
2183    firewall-2⇒napt44-2. The first SF type is Firewall in Service
2184    Function Chain. So the algorithm will select first Hop randomly among
2185    all the SFs type is Firewall. Assume the first selected SF is
2186    firewall-2. All the path from firewall-1 to SF which type is Napt44
2187    are list:
2188
2189    -  Path1: firewall-2 → sff2 → napt44-2
2190
2191    -  Path2: firewall-2 → sff2 → sff3 → sff1 → napt44-1 The shortest
2192       path is Path1, so the selected next hop is napt44-2.
2193
2194 .. figure:: ./images/sfc/sf-rendered-service-path.png
2195    :alt: rendered service path
2196
2197    rendered service path
2198
2199 Service Function Load Balancing User Guide
2200 ------------------------------------------
2201
2202 Overview
2203 ~~~~~~~~
2204
2205 SFC Load-Balancing feature implements load balancing of Service
2206 Functions, rather than a one-to-one mapping between
2207 Service-Function-Forwarder and Service-Function.
2208
2209 Load Balancing Architecture
2210 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
2211
2212 Service Function Groups (SFG) can replace Service Functions (SF) in the
2213 Rendered Path model. A Service Path can only be defined using SFGs or
2214 SFs, but not a combination of both.
2215
2216 Relevant objects in the YANG model are as follows:
2217
2218 1. Service-Function-Group-Algorithm:
2219
2220    ::
2221
2222        Service-Function-Group-Algorithms {
2223            Service-Function-Group-Algorithm {
2224                String name
2225                String type
2226            }
2227        }
2228
2229    ::
2230
2231        Available types: ALL, SELECT, INDIRECT, FAST_FAILURE
2232
2233 2. Service-Function-Group:
2234
2235    ::
2236
2237        Service-Function-Groups {
2238            Service-Function-Group {
2239                String name
2240                String serviceFunctionGroupAlgorithmName
2241                String type
2242                String groupId
2243                Service-Function-Group-Element {
2244                    String service-function-name
2245                    int index
2246                }
2247            }
2248        }
2249
2250 3. ServiceFunctionHop: holds a reference to a name of SFG (or SF)
2251
2252 Tutorials
2253 ~~~~~~~~~
2254
2255 This tutorial will explain how to create a simple SFC configuration,
2256 with SFG instead of SF. In this example, the SFG will include two
2257 existing SF.
2258
2259 Setup SFC
2260 ^^^^^^^^^
2261
2262 For general SFC setup and scenarios, please see the SFC wiki page:
2263 https://wiki.opendaylight.org/view/Service_Function_Chaining:Main#SFC_101
2264
2265 Create an algorithm
2266 ^^^^^^^^^^^^^^^^^^^
2267
2268 POST -
2269 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2270
2271 .. code-block:: none
2272
2273     {
2274         "service-function-group-algorithm": [
2275           {
2276             "name": "alg1"
2277             "type": "ALL"
2278           }
2279        ]
2280     }
2281
2282 (Header "content-type": application/json)
2283
2284 Verify: get all algorithms
2285 ^^^^^^^^^^^^^^^^^^^^^^^^^^
2286
2287 GET -
2288 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2289
2290 In order to delete all algorithms: DELETE -
2291 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2292
2293 Create a group
2294 ^^^^^^^^^^^^^^
2295
2296 POST -
2297 http://127.0.0.1:8181/restconf/config/service-function-group:service-function-groups
2298
2299 .. code-block:: none
2300
2301     {
2302         "service-function-group": [
2303         {
2304             "rest-uri": "http://localhost:10002",
2305             "ip-mgmt-address": "10.3.1.103",
2306             "algorithm": "alg1",
2307             "name": "SFG1",
2308             "type": "napt44",
2309             "sfc-service-function": [
2310                 {
2311                     "name":"napt44-104"
2312                 },
2313                 {
2314                     "name":"napt44-103-1"
2315                 }
2316             ]
2317           }
2318         ]
2319     }
2320
2321 Verify: get all SFG’s
2322 ^^^^^^^^^^^^^^^^^^^^^
2323
2324 GET -
2325 http://127.0.0.1:8181/restconf/config/service-function-group:service-function-groups
2326
2327 SFC Proof of Transit User Guide
2328 -------------------------------
2329
2330 Overview
2331 ~~~~~~~~
2332
2333 Several deployments use traffic engineering, policy routing, segment
2334 routing or service function chaining (SFC) to steer packets through a
2335 specific set of nodes. In certain cases regulatory obligations or a
2336 compliance policy require to prove that all packets that are supposed to
2337 follow a specific path are indeed being forwarded across the exact set
2338 of nodes specified. I.e. if a packet flow is supposed to go through a
2339 series of service functions or network nodes, it has to be proven that
2340 all packets of the flow actually went through the service chain or
2341 collection of nodes specified by the policy. In case the packets of a
2342 flow weren’t appropriately processed, a proof of transit egress device
2343 would be required to identify the policy violation and take
2344 corresponding actions (e.g. drop or redirect the packet, send an alert
2345 etc.) corresponding to the policy.
2346
2347 Service Function Chaining (SFC) Proof of Transit (SFC PoT)
2348 implements Service Chaining Proof of Transit functionality on capable
2349 network devices.  Proof of Transit defines mechanisms to securely
2350 prove that traffic transited the defined path.  After the creation of an
2351 Rendered Service Path (RSP), a user can configure to enable SFC proof
2352 of transit on the selected RSP to effect the proof of transit.
2353
2354 To ensure that the data traffic follows a specified path or a function
2355 chain, meta-data is added to user traffic in the form of a header.  The
2356 meta-data is based on a 'share of a secret' and provisioned by the SFC
2357 PoT configuration from ODL over a secure channel to each of the nodes
2358 in the SFC.  This meta-data is updated at each of the service-hop while
2359 a designated node called the verifier checks whether the collected
2360 meta-data allows the retrieval of the secret.
2361
2362 The following diagram shows the overview and essentially utilizes Shamir's
2363 secret sharing algorithm, where each service is given a point on the
2364 curve and when the packet travels through each service, it collects these
2365 points (meta-data) and a verifier node tries to re-construct the curve
2366 using the collected points, thus verifying that the packet traversed
2367 through all the service functions along the chain.
2368
2369 .. figure:: ./images/sfc/sfc-pot-intro.png
2370    :alt: SFC Proof of Transit overview
2371
2372    SFC Proof of Transit overview
2373
2374 Transport options for different protocols includes a new TLV in SR header
2375 for Segment Routing, NSH Type-2 meta-data, IPv6 extension headers, IPv4
2376 variants and for VXLAN-GPE.  More details are captured in the following
2377 link.
2378
2379 In-situ OAM: https://github.com/CiscoDevNet/iOAM
2380
2381 Common acronyms used in the following sections:
2382
2383 -  SF - Service Function
2384
2385 -  SFF - Service Function Forwarder
2386
2387 -  SFC - Service Function Chain
2388
2389 -  SFP - Service Function Path
2390
2391 -  RSP - Rendered Service Path
2392
2393 -  SFC PoT - Service Function Chain Proof of Transit
2394
2395
2396 SFC Proof of Transit Architecture
2397 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2398
2399 SFC PoT feature is implemented as a two-part implementation with a
2400 north-bound handler that augments the RSP while a south-bound renderer
2401 auto-generates the required parameters and passes it on to the nodes
2402 that belong to the SFC.
2403
2404 The north-bound feature is enabled via odl-sfc-pot feature while the
2405 south-bound renderer is enabled via the odl-sfc-pot-netconf-renderer
2406 feature.  For the purposes of SFC PoT handling, both features must be
2407 installed.
2408
2409 RPC handlers to augment the RSP are part of ``SfcPotRpc`` while the
2410 RSP augmentation to enable or disable SFC PoT feature is done via
2411 ``SfcPotRspProcessor``.
2412
2413
2414 SFC Proof of Transit entities
2415 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2416
2417 In order to implement SFC Proof of Transit for a service function chain,
2418 an RSP is a pre-requisite to identify the SFC to enable SFC PoT on. SFC
2419 Proof of Transit for a particular RSP is enabled by an RPC request to
2420 the controller along with necessary parameters to control some of the
2421 aspects of the SFC Proof of Transit process.
2422
2423 The RPC handler identifies the RSP and adds PoT feature meta-data like
2424 enable/disable, number of PoT profiles, profiles refresh parameters etc.,
2425 that directs the south-bound renderer appropriately when RSP changes
2426 are noticed via call-backs in the renderer handlers.
2427
2428 Administering SFC Proof of Transit
2429 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2430
2431 To use the SFC Proof of Transit Karaf, at least the following Karaf
2432 features must be installed:
2433
2434 -  odl-sfc-model
2435
2436 -  odl-sfc-provider
2437
2438 -  odl-sfc-netconf
2439
2440 -  odl-restconf
2441
2442 -  odl-netconf-topology
2443
2444 -  odl-netconf-connector-all
2445
2446 -  odl-sfc-pot
2447
2448 Please note that the odl-sfc-pot-netconf-renderer or other renderers in future
2449 must be installed for the feature to take full-effect.  The details of the renderer
2450 features are described in other parts of this document.
2451
2452 SFC Proof of Transit Tutorial
2453 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2454
2455 Overview
2456 ^^^^^^^^
2457
2458 This tutorial is a simple example how to configure Service Function
2459 Chain Proof of Transit using SFC POT feature.
2460
2461 Preconditions
2462 ^^^^^^^^^^^^^
2463
2464 To enable a device to handle SFC Proof of Transit, it is expected that
2465 the NETCONF node device advertise capability as under ioam-sb-pot.yang
2466 present under sfc-model/src/main/yang folder. It is also expected that base
2467 NETCONF support be enabled and its support capability advertised as capabilities.
2468
2469 NETCONF support:``urn:ietf:params:netconf:base:1.0``
2470
2471 PoT support: ``(urn:cisco:params:xml:ns:yang:sfc-ioam-sb-pot?revision=2017-01-12)sfc-ioam-sb-pot``
2472
2473 It is also expected that the devices are netconf mounted and available
2474 in the topology-netconf store.
2475
2476 Instructions
2477 ^^^^^^^^^^^^
2478
2479 When SFC Proof of Transit is installed, all netconf nodes in topology-netconf
2480 are processed and all capable nodes with accessible mountpoints are cached.
2481
2482 First step is to create the required RSP as is usually done using RSP creation
2483 steps in SFC main.
2484
2485 Once RSP name is available it is used to send a POST RPC to the
2486 controller similar to below:
2487
2488 POST -
2489 http://ODL-IP:8181/restconf/operations/sfc-ioam-nb-pot:enable-sfc-ioam-pot-rendered-path/
2490
2491 .. code-block:: none
2492
2493     {
2494         "input":
2495         {
2496             "sfc-ioam-pot-rsp-name": "sfc-path-3sf3sff",
2497             "ioam-pot-enable":true,
2498             "ioam-pot-num-profiles":2,
2499             "ioam-pot-bit-mask":"bits32",
2500             "refresh-period-time-units":"milliseconds",
2501             "refresh-period-value":5000
2502         }
2503     }
2504
2505 The following can be used to disable the SFC Proof of Transit on an RSP
2506 which disables the PoT feature.
2507
2508 POST -
2509 http://ODL-IP:8181/restconf/operations/sfc-ioam-nb-pot:disable-sfc-ioam-pot-rendered-path/
2510
2511 .. code-block:: none
2512
2513     {
2514         "input":
2515         {
2516             "sfc-ioam-pot-rsp-name": "sfc-path-3sf3sff",
2517         }
2518     }
2519
2520 SFC PoT NETCONF Renderer User Guide
2521 -----------------------------------
2522
2523 Overview
2524 ~~~~~~~~
2525
2526 The SFC Proof of Transit (PoT) NETCONF renderer implements SFC Proof of
2527 Transit functionality on NETCONF-capable devices, that have advertised
2528 support for in-situ OAM (iOAM) support.
2529
2530 It listens for an update to an existing RSP with enable or disable proof of
2531 transit support and adds the auto-generated SFC PoT configuration parameters
2532 to all the SFC hop nodes.  The last node in the SFC is configured as a
2533 verifier node to allow SFC PoT process to be completed.
2534
2535 Common acronyms are used as below:
2536
2537 - SF - Service Function
2538
2539 - SFC - Service Function Chain
2540
2541 - RSP - Rendered Service Path
2542
2543 - SFF - Service Function Forwarder
2544
2545
2546 Mapping to SFC entities
2547 ~~~~~~~~~~~~~~~~~~~~~~~
2548
2549 The renderer module listens to RSP updates in ``SfcPotNetconfRSPListener``
2550 and triggers configuration generation in ``SfcPotNetconfIoam`` class.  Node
2551 arrival and leaving are managed via ``SfcPotNetconfNodeManager`` and
2552 ``SfcPotNetconfNodeListener``.  In addition there is a timer thread that
2553 runs to generate configuration periodically to refresh the profiles in the
2554 nodes that are part of the SFC.
2555
2556
2557 Administering SFC PoT NETCONF Renderer
2558 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2559
2560 To use the SFC Proof of Transit Karaf, the following Karaf features must
2561 be installed:
2562
2563 -  odl-sfc-model
2564
2565 -  odl-sfc-provider
2566
2567 -  odl-sfc-netconf
2568
2569 -  odl-restconf-all
2570
2571 -  odl-netconf-topology
2572
2573 -  odl-netconf-connector-all
2574
2575 -  odl-sfc-pot
2576
2577 -  odl-sfc-pot-netconf-renderer
2578
2579
2580 SFC PoT NETCONF Renderer Tutorial
2581 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2582
2583 Overview
2584 ^^^^^^^^
2585
2586 This tutorial is a simple example how to enable SFC PoT on NETCONF-capable
2587 devices.
2588
2589 Preconditions
2590 ^^^^^^^^^^^^^
2591
2592 The NETCONF-capable device will have to support sfc-ioam-sb-pot.yang file.
2593
2594 It is expected that a NETCONF-capable VPP device has Honeycomb (Hc2vpp)
2595 Java-based agent that helps to translate between NETCONF and VPP internal
2596 APIs.
2597
2598 More details are here:
2599 In-situ OAM: https://github.com/CiscoDevNet/iOAM
2600
2601 Steps
2602 ^^^^^
2603 When the SFC PoT NETCONF renderer module is installed, all NETCONF nodes in
2604 topology-netconf are processed and all sfc-ioam-sb-pot yang capable nodes
2605 with accessible mountpoints are cached.
2606
2607 The first step is to create RSP for the SFC as per SFC guidelines above.
2608
2609 Enable SFC PoT is done on the RSP via RESTCONF to the ODL as outlined above.
2610
2611 Internally, the NETCONF renderer will act on the callback to a modified RSP
2612 that has PoT enabled.
2613
2614 In-situ OAM algorithms for auto-generation of SFC PoT parameters are
2615 generated automatically and sent to these nodes via NETCONF.
2616
2617 Logical Service Function Forwarder
2618 ----------------------------------
2619
2620 Overview
2621 ~~~~~~~~
2622
2623 .. _sfc-user-guide-logical-sff-motivation:
2624
2625 Rationale
2626 ^^^^^^^^^
2627 When the current SFC is deployed in a cloud environment, it is assumed that each
2628 switch connected to a Service Function is configured as a Service Function
2629 Forwarder and each Service Function is connected to its Service Function
2630 Forwarder depending on the Compute Node where the Virtual Machine is located.
2631
2632 .. figure:: ./images/sfc/sfc-in-cloud.png
2633    :alt: Deploying SFC in Cloud Environments
2634
2635 As shown in the picture above, this solution allows the basic cloud use cases to
2636 be fulfilled, as for example, the ones required in OPNFV Brahmaputra, however,
2637 some advanced use cases like the transparent migration of VMs can not be
2638 implemented. The Logical Service Function Forwarder enables the following
2639 advanced use cases:
2640
2641 1. Service Function mobility without service disruption
2642 2. Service Functions load balancing and failover
2643
2644 As shown in the picture below, the Logical Service Function Forwarder concept
2645 extends the current SFC northbound API to provide an abstraction of the
2646 underlying Data Center infrastructure. The Data Center underlaying network can
2647 be abstracted by a single SFF. This single SFF uses the logical port UUID as
2648 data plane locator to connect SFs globally and in a location-transparent manner.
2649 SFC makes use of `Genius <./genius-user-guide.html>`__ project to track the
2650 location of the SF's logical ports.
2651
2652 .. figure:: ./images/sfc/single-logical-sff-concept.png
2653    :alt: Single Logical SFF concept
2654
2655 The SFC internally distributes the necessary flow state over the relevant
2656 switches based on the internal Data Center topology and the deployment of SFs.
2657
2658 Changes in data model
2659 ~~~~~~~~~~~~~~~~~~~~~
2660 The Logical Service Function Forwarder concept extends the current SFC
2661 northbound API to provide an abstraction of the underlying Data Center
2662 infrastructure.
2663
2664 The Logical SFF simplifies the configuration of the current SFC data model by
2665 reducing the number of parameters to be be configured in every SFF, since the
2666 controller will discover those parameters by interacting with the services
2667 offered by the `Genius <./genius-user-guide.html>`__ project.
2668
2669 The following picture shows the Logical SFF data model. The model gets
2670 simplified as most of the configuration parameters of the current SFC data model
2671 are discovered in runtime. The complete YANG model can be found here
2672 `logical SFF model <https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/service-function-forwarder-logical.yang>`__.
2673
2674 .. figure:: ./images/sfc/logical-sff-datamodel.png
2675    :alt: Logical SFF data model
2676
2677 How to configure the Logical SFF
2678 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2679 The following are examples to configure the Logical SFF:
2680
2681 .. code-block:: bash
2682
2683    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
2684    --data '${JSON}' -X PUT --user
2685    admin:admin http://localhost:8181/restconf/config/restconf/config/service-function:service-functions/
2686
2687 **Service Functions JSON.**
2688
2689 .. code-block:: none
2690
2691     {
2692     "service-functions": {
2693         "service-function": [
2694             {
2695                 "name": "firewall-1",
2696                 "type": "firewall",
2697                 "sf-data-plane-locator": [
2698                     {
2699                         "name": "firewall-dpl",
2700                         "interface-name": "eccb57ae-5a2e-467f-823e-45d7bb2a6a9a",
2701                         "transport": "service-locator:eth-nsh",
2702                         "service-function-forwarder": "sfflogical1"
2703
2704                     }
2705                 ]
2706             },
2707             {
2708                 "name": "dpi-1",
2709                 "type": "dpi",
2710                 "sf-data-plane-locator": [
2711                     {
2712                         "name": "dpi-dpl",
2713                         "interface-name": "df15ac52-e8ef-4e9a-8340-ae0738aba0c0",
2714                         "transport": "service-locator:eth-nsh",
2715                         "service-function-forwarder": "sfflogical1"
2716                     }
2717                 ]
2718             }
2719         ]
2720     }
2721     }
2722
2723 .. code-block:: bash
2724
2725    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
2726    --data '${JSON}' -X PUT --user
2727    admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/
2728
2729 **Service Function Forwarders JSON.**
2730
2731 .. code-block:: none
2732
2733     {
2734     "service-function-forwarders": {
2735         "service-function-forwarder": [
2736            {
2737                 "name": "sfflogical1"
2738             }
2739         ]
2740     }
2741     }
2742
2743 .. code-block:: bash
2744
2745    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
2746    --data '${JSON}' -X PUT --user
2747    admin:admin http://localhost:8181/restconf/config/service-function-chain:service-function-chains/
2748
2749 **Service Function Chains JSON.**
2750
2751 .. code-block:: none
2752
2753     {
2754     "service-function-chains": {
2755         "service-function-chain": [
2756             {
2757                 "name": "SFC1",
2758                 "sfc-service-function": [
2759                     {
2760                         "name": "dpi-abstract1",
2761                         "type": "dpi"
2762                     },
2763                     {
2764                         "name": "firewall-abstract1",
2765                         "type": "firewall"
2766                     }
2767                 ]
2768             },
2769             {
2770                 "name": "SFC2",
2771                 "sfc-service-function": [
2772                     {
2773                         "name": "dpi-abstract1",
2774                         "type": "dpi"
2775                     }
2776                 ]
2777             }
2778         ]
2779     }
2780     }
2781
2782 .. code-block:: bash
2783
2784    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
2785    --data '${JSON}' -X PUT --user
2786     admin:admin http://localhost:8182/restconf/config/service-function-chain:service-function-paths/
2787
2788 **Service Function Paths JSON.**
2789
2790 .. code-block:: none
2791
2792     {
2793     "service-function-paths": {
2794         "service-function-path": [
2795             {
2796                 "name": "SFP1",
2797                 "service-chain-name": "SFC1",
2798                 "starting-index": 255,
2799                 "symmetric": "true",
2800                 "context-metadata": "NSH1",
2801                 "transport-type": "service-locator:vxlan-gpe"
2802
2803             }
2804         ]
2805     }
2806     }
2807
2808 As a result of above configuration, OpenDaylight renders the needed flows in all involved SFFs. Those flows implement:
2809
2810 - Two Rendered Service Paths:
2811
2812   - dpi-1 (SF1), firewall-1 (SF2)
2813   - firewall-1 (SF2), dpi-1 (SF1)
2814
2815 - The communication between SFFs and SFs based on eth-nsh
2816
2817 - The communication between SFFs based on vxlan-gpe
2818
2819 The following picture shows a topology and traffic flow (in green) which corresponds to the above configuration.
2820
2821 .. figure:: ./images/sfc/single-logical-sff-example.png
2822    :alt: Logical SFF Example
2823    :width: 800px
2824    :height: 600px
2825
2826    Logical SFF Example
2827
2828
2829 The Logical SFF functionality allows OpenDaylight to find out the SFFs holding
2830 the SFs involved in a path. In this example the SFFs affected are Node3 and
2831 Node4 thus the controller renders the flows containing NSH parameters just in
2832 those SFFs.
2833
2834 Here you have the new flows rendered in Node3 and Node4 which implement the NSH
2835 protocol. Every Rendered Service Path is represented by an NSP value. We
2836 provisioned a symmetric RSP so we get two NSPs: 8388613 and 5. Node3 holds the
2837 first SF of NSP 8388613 and the last SF of NSP 5. Node 4 holds the first SF of
2838 NSP 5 and the last SF of NSP 8388613. Both Node3 and Node4 will pop the NSH
2839 header when the received packet has gone through the last SF of its path.
2840
2841 **Rendered flows Node 3**
2842
2843 ::
2844
2845  cookie=0x14, duration=59.264s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
2846  cookie=0x14, duration=59.194s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
2847  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
2848  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
2849  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)
2850  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)
2851  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)
2852  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
2853
2854 **Rendered Flows Node 4**
2855
2856 ::
2857
2858  cookie=0x14, duration=69.040s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
2859  cookie=0x14, duration=69.008s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
2860  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
2861  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
2862  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)
2863  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
2864  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)
2865  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)
2866
2867
2868 An interesting scenario to show the Logical SFF strength is the migration of a
2869 SF from a compute node to another. The OpenDaylight will learn the new topology
2870 by itself, then it will re-render the new flows to the new SFFs affected.
2871
2872 .. figure:: ./images/sfc/single-logical-sff-example-migration.png
2873    :alt: Logical SFF - SF Migration Example
2874    :width: 800px
2875    :height: 600px
2876
2877    Logical SFF - SF Migration Example
2878
2879
2880 In our example, SF2 is moved from Node4 to Node2 then OpenDaylight removes NSH
2881 specific flows from Node4 and puts them in Node2. Check below flows showing this
2882 effect. Now Node3 keeps holding the first SF of NSP 8388613 and the last SF of
2883 NSP 5; but Node2 becomes the new holder of the first SF of NSP 5 and the last SF
2884 of NSP 8388613.
2885
2886 **Rendered Flows Node 3 After Migration**
2887
2888 ::
2889
2890  cookie=0x14, duration=64.044s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
2891  cookie=0x14, duration=63.947s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
2892  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
2893  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
2894  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)
2895  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)
2896  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)
2897  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
2898
2899 **Rendered Flows Node 2 After Migration**
2900
2901 ::
2902
2903  cookie=0x14, duration=56.856s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=5 actions=goto_table:86
2904  cookie=0x14, duration=56.755s, table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388613 actions=goto_table:86
2905  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
2906  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
2907  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)
2908  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
2909  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)
2910  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)
2911
2912 **Rendered Flows Node 4 After Migration**
2913
2914 ::
2915
2916  -- No flows for NSH processing --
2917
2918 .. _sfc-user-guide-classifier-impacts:
2919
2920 Classifier impacts
2921 ~~~~~~~~~~~~~~~~~~
2922
2923 As previously mentioned, in the :ref:`Logical SFF rationale
2924 <sfc-user-guide-logical-sff-motivation>`, the Logical SFF feature relies on
2925 Genius to get the dataplane IDs of the OpenFlow switches, in order to properly
2926 steer the traffic through the chain.
2927
2928 Since one of the classifier's objectives is to steer the packets *into* the
2929 SFC domain, the classifier has to be aware of where the first Service
2930 Function is located - if it migrates somewhere else, the classifier table
2931 has to be updated accordingly, thus enabling the seemless migration of Service
2932 Functions.
2933
2934 For this feature, mobility of the client VM is out of scope, and should be
2935 managed by its high-availability module, or VNF manager.
2936
2937 Keep in mind that classification *always* occur in the compute-node where
2938 the client VM (i.e. traffic origin) is running.
2939
2940 How to attach the classifier to a Logical SFF
2941 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2942
2943 In order to leverage this functionality, the classifier has to be configured
2944 using a Logical SFF as an attachment-point, specifying within it the neutron
2945 port to classify.
2946
2947 The following examples show how to configure an ACL, and a classifier having
2948 a Logical SFF as an attachment-point:
2949
2950 **Configure an ACL**
2951
2952 The following ACL enables traffic intended for port 80 within the subnetwork
2953 192.168.2.0/24, for RSP1 and RSP1-Reverse.
2954
2955 .. code-block:: none
2956
2957         {
2958           "access-lists": {
2959             "acl": [
2960               {
2961                 "acl-name": "ACL1",
2962                 "acl-type": "ietf-access-control-list:ipv4-acl",
2963                 "access-list-entries": {
2964                   "ace": [
2965                     {
2966                       "rule-name": "ACE1",
2967                       "actions": {
2968                         "service-function-acl:rendered-service-path": "RSP1"
2969                       },
2970                       "matches": {
2971                         "destination-ipv4-network": "192.168.2.0/24",
2972                         "source-ipv4-network": "192.168.2.0/24",
2973                         "protocol": "6",
2974                         "source-port-range": {
2975                             "lower-port": 0
2976                         },
2977                         "destination-port-range": {
2978                             "lower-port": 80
2979                         }
2980                       }
2981                     }
2982                   ]
2983                 }
2984               },
2985               {
2986                 "acl-name": "ACL2",
2987                 "acl-type": "ietf-access-control-list:ipv4-acl",
2988                 "access-list-entries": {
2989                   "ace": [
2990                     {
2991                       "rule-name": "ACE2",
2992                       "actions": {
2993                         "service-function-acl:rendered-service-path": "RSP1-Reverse"
2994                       },
2995                       "matches": {
2996                         "destination-ipv4-network": "192.168.2.0/24",
2997                         "source-ipv4-network": "192.168.2.0/24",
2998                         "protocol": "6",
2999                         "source-port-range": {
3000                             "lower-port": 80
3001                         },
3002                         "destination-port-range": {
3003                             "lower-port": 0
3004                         }
3005                       }
3006                     }
3007                   ]
3008                 }
3009               }
3010             ]
3011           }
3012         }
3013
3014 .. code-block:: bash
3015
3016    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
3017    --data '${JSON}' -X PUT --user
3018    admin:admin http://localhost:8181/restconf/config/ietf-access-control-list:access-lists/
3019
3020 **Configure a classifier JSON**
3021
3022 The following JSON provisions a classifier, having a Logical SFF as an
3023 attachment point. The value of the field 'interface' is where you
3024 indicate the neutron ports of the VMs you want to classify.
3025
3026 .. code-block:: none
3027
3028         {
3029           "service-function-classifiers": {
3030             "service-function-classifier": [
3031               {
3032                 "name": "Classifier1",
3033                 "scl-service-function-forwarder": [
3034                   {
3035                     "name": "sfflogical1",
3036                     "interface": "09a78ba3-78ba-40f5-a3ea-1ce708367f2b"
3037                   }
3038                 ],
3039                 "acl": {
3040                     "name": "ACL1",
3041                     "type": "ietf-access-control-list:ipv4-acl"
3042                  }
3043               }
3044             ]
3045           }
3046         }
3047
3048 .. code-block:: bash
3049
3050    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
3051    --data '${JSON}' -X PUT --user
3052    admin:admin http://localhost:8181/restconf/config/service-function-classifier:service-function-classifiers/
3053
3054 .. _sfc-user-guide-pipeline-impacts:
3055
3056 SFC pipeline impacts
3057 ~~~~~~~~~~~~~~~~~~~~
3058
3059 After binding SFC service with a particular interface by means of Genius, as
3060 explained in the :ref:`Genius User Guide <genius-user-guide-binding-services>`,
3061 the entry point in the SFC pipeline will be table 82
3062 (SFC_TRANSPORT_CLASSIFIER_TABLE), and from that point, packet processing will be
3063 similar to the :ref:`SFC OpenFlow pipeline <sfc-user-guide-sfc-of-pipeline>`,
3064 just with another set of specific tables for the SFC service.
3065
3066 This picture shows the SFC pipeline after service integration with Genius:
3067
3068 .. figure:: ./images/sfc/LSFF_pipeline.png
3069    :alt: SFC Logical SFF OpenFlow pipeline
3070
3071    SFC Logical SFF OpenFlow pipeline
3072
3073 Directional data plane locators for symmetric paths
3074 ---------------------------------------------------
3075
3076 Overview
3077 ~~~~~~~~
3078
3079 A symmetric path results from a Service Function Path with the symmetric field
3080 set or when any of the constituent Service Functions is set as bidirectional.
3081 Such a path is defined by two Rendered Service Paths where one of them steers
3082 the traffic through the same Service Functions as the other but in opposite
3083 order. These two Rendered Service Paths are also said to be symmetric to each
3084 other and gives to each path a sense of direction: The Rendered Service Path
3085 that corresponds to the same order of Service Functions as that defined on the
3086 Service Function Chain is tagged as the forward or up-link path, while the
3087 Rendered Service Path that corresponds to the opposite order is tagged as
3088 reverse or down-link path.
3089
3090 Directional data plane locators allow the use of different interfaces or
3091 interface details between the Service Function Forwarder and the Service
3092 Function in relation with the direction of the path for which they are being
3093 used. This function is relevant for Service Functions that would have no other
3094 way of discerning the direction of the traffic, like for example legacy
3095 bump-in-the-wire network devices.
3096
3097 ::
3098
3099                         +-----------------------------------------------+
3100                         |                                               |
3101                         |                                               |
3102                         |                      SF                       |
3103                         |                                               |
3104                         |  sf-forward-dpl                sf-reverse-dpl |
3105                         +--------+-----------------------------+--------+
3106                                  |                             |
3107                          ^       |      +              +       |      ^
3108                          |       |      |              |       |      |
3109                          |       |      |              |       |      |
3110                          +       |      +              +       |      +
3111                     Forward Path | Reverse Path   Forward Path | Reverse Path
3112                          +       |      +              +       |      +
3113                          |       |      |              |       |      |
3114                          |       |      |              |       |      |
3115                          |       |      |              |       |      |
3116                          +       |      v              v       |      +
3117                                  |                             |
3118                      +-----------+-----------------------------------------+
3119       Forward Path   |     sff-forward-dpl               sff-reverse-dpl   |   Forward Path
3120     +--------------> |                                                     | +-------------->
3121                      |                                                     |
3122                      |                         SFF                         |
3123                      |                                                     |
3124     <--------------+ |                                                     | <--------------+
3125       Reverse Path   |                                                     |   Reverse Path
3126                      +-----------------------------------------------------+
3127
3128 As shown in the previous figure, the forward path egress from the Service
3129 Function Forwarder towards the Service Function is defined by the
3130 sff-forward-dpl and sf-forward-dpl data plane locators. The forward path
3131 ingress from the Service Function to the Service Function Forwarder is defined
3132 by the sf-reverse-dpl and sff-reverse-dpl data plane locators. For the reverse
3133 path, it's the opposite: the sff-reverse-dpl and sf-reverse-dpl define the
3134 egress from the Service Function Forwarder to the Service Function, and the
3135 sf-forward-dpl and sff-forward-dpl define the ingress into the Service Function
3136 Forwarder from the Service Function.
3137
3138 .. note:: Directional data plane locators are only supported in combination
3139           with the SFC OF Renderer at this time.
3140
3141 Configuration
3142 ~~~~~~~~~~~~~
3143
3144 Directional data plane locators are configured within the
3145 service-function-forwarder in the service-function-dictionary entity, which
3146 describes the association between a Service Function Forwarder and Service
3147 Functions:
3148
3149 .. code-block:: none
3150    :caption: service-function-forwarder.yang
3151
3152         list service-function-dictionary {
3153             key "name";
3154             leaf name {
3155               type sfc-common:sf-name;
3156               description
3157                   "The name of the service function.";
3158             }
3159             container sff-sf-data-plane-locator {
3160               description
3161                 "SFF and SF data plane locators to use when sending
3162                  packets from this SFF to the associated SF";
3163               leaf sf-dpl-name {
3164                 type sfc-common:sf-data-plane-locator-name;
3165                 description
3166                   "The SF data plane locator to use when sending
3167                    packets to the associated service function.
3168                    Used both as forward and reverse locators for
3169                    paths of a symmetric chain.";
3170               }
3171               leaf sff-dpl-name {
3172                 type sfc-common:sff-data-plane-locator-name;
3173                 description
3174                   "The SFF data plane locator to use when sending
3175                    packets to the associated service function.
3176                    Used both as forward and reverse locators for
3177                    paths of a symmetric chain.";
3178               }
3179               leaf sf-forward-dpl-name {
3180                 type sfc-common:sf-data-plane-locator-name;
3181                 description
3182                   "The SF data plane locator to use when sending
3183                    packets to the associated service function
3184                    on the forward path of a symmetric chain";
3185               }
3186               leaf sf-reverse-dpl-name {
3187                 type sfc-common:sf-data-plane-locator-name;
3188                 description
3189                   "The SF data plane locator to use when sending
3190                    packets to the associated service function
3191                    on the reverse path of a symmetric chain";
3192               }
3193               leaf sff-forward-dpl-name {
3194                 type sfc-common:sff-data-plane-locator-name;
3195                 description
3196                   "The SFF data plane locator to use when sending
3197                    packets to the associated service function
3198                    on the forward path of a symmetric chain.";
3199               }
3200               leaf sff-reverse-dpl-name {
3201                 type sfc-common:sff-data-plane-locator-name;
3202                 description
3203                   "The SFF data plane locator to use when sending
3204                    packets to the associated service function
3205                    on the reverse path of a symmetric chain.";
3206               }
3207             }
3208         }
3209
3210 Example
3211 ~~~~~~~
3212
3213 The following configuration example is based on the Logical SFF configuration
3214 one. Only the Service Function and Service Function Forwarder configuration
3215 changes with respect to that example:
3216
3217 .. code-block:: bash
3218
3219    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
3220    --data '${JSON}' -X PUT --user
3221    admin:admin http://localhost:8181/restconf/config/restconf/config/service-function:service-functions/
3222
3223 **Service Functions JSON.**
3224
3225 .. code-block:: none
3226
3227     {
3228     "service-functions": {
3229         "service-function": [
3230             {
3231                 "name": "firewall-1",
3232                 "type": "firewall",
3233                 "sf-data-plane-locator": [
3234                     {
3235                         "name": "sf-firewall-net-A-dpl",
3236                         "interface-name": "eccb57ae-5a2e-467f-823e-45d7bb2a6a9a",
3237                         "transport": "service-locator:mac",
3238                         "service-function-forwarder": "sfflogical1"
3239
3240                     },
3241                     {
3242                         "name": "sf-firewall-net-B-dpl",
3243                         "interface-name": "7764b6f1-a5cd-46be-9201-78f917ddee1d",
3244                         "transport": "service-locator:mac",
3245                         "service-function-forwarder": "sfflogical1"
3246
3247                     }
3248                 ]
3249             },
3250             {
3251                 "name": "dpi-1",
3252                 "type": "dpi",
3253                 "sf-data-plane-locator": [
3254                     {
3255                         "name": "sf-dpi-net-A-dpl",
3256                         "interface-name": "df15ac52-e8ef-4e9a-8340-ae0738aba0c0",
3257                         "transport": "service-locator:mac",
3258                         "service-function-forwarder": "sfflogical1"
3259                     },
3260                     {
3261                         "name": "sf-dpi-net-B-dpl",
3262                         "interface-name": "1bb09b01-422d-4ccf-8d7a-9ebf00d1a1a5",
3263                         "transport": "service-locator:mac",
3264                         "service-function-forwarder": "sfflogical1"
3265                     }
3266                 ]
3267             }
3268         ]
3269     }
3270     }
3271
3272 .. code-block:: bash
3273
3274    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
3275    --data '${JSON}' -X PUT --user
3276    admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/
3277
3278 **Service Function Forwarders JSON.**
3279
3280 .. code-block:: none
3281
3282     {
3283     "service-function-forwarders": {
3284         "service-function-forwarder": [
3285             {
3286                 "name": "sfflogical1"
3287                 "sff-data-plane-locator": [
3288                     {
3289                         "name": "sff-firewall-net-A-dpl",
3290                         "data-plane-locator": {
3291                             "interface-name": "eccb57ae-5a2e-467f-823e-45d7bb2a6a9a",
3292                             "transport": "service-locator:mac"
3293                         }
3294                     },
3295                     {
3296                         "name": "sff-firewall-net-B-dpl",
3297                         "data-plane-locator": {
3298                             "interface-name": "7764b6f1-a5cd-46be-9201-78f917ddee1d",
3299                             "transport": "service-locator:mac"
3300                         }
3301                     },
3302                     {
3303                         "name": "sff-dpi-net-A-dpl",
3304                         "data-plane-locator": {
3305                             "interface-name": "df15ac52-e8ef-4e9a-8340-ae0738aba0c0",
3306                             "transport": "service-locator:mac"
3307                         }
3308                     },
3309                     {
3310                         "name": "sff-dpi-net-B-dpl",
3311                         "data-plane-locator": {
3312                             "interface-name": "1bb09b01-422d-4ccf-8d7a-9ebf00d1a1a5",
3313                             "transport": "service-locator:mac"
3314                         }
3315                     }
3316                 ],
3317                 "service-function-dictionary": [
3318                     {
3319                         "name": "firewall-1",
3320                         "sff-sf-data-plane-locator": {
3321                             "sf-forward-dpl-name": "sf-firewall-net-A-dpl",
3322                             "sf-reverse-dpl-name": "sf-firewall-net-B-dpl",
3323                             "sff-forward-dpl-name": "sff-firewall-net-A-dpl",
3324                             "sff-reverse-dpl-name": "sff-firewall-net-B-dpl",
3325                         }
3326                     },
3327                     {
3328                         "name": "dpi-1",
3329                         "sff-sf-data-plane-locator": {
3330                             "sf-forward-dpl-name": "sf-dpi-net-A-dpl",
3331                             "sf-reverse-dpl-name": "sf-dpi-net-B-dpl",
3332                             "sff-forward-dpl-name": "sff-dpi-net-A-dpl",
3333                             "sff-reverse-dpl-name": "sff-dpi-net-B-dpl",
3334                         }
3335                     }
3336                 ]
3337             }
3338         ]
3339     }
3340     }
3341
3342 In comparison with the Logical SFF example, noticed that each Service Function
3343 is configured with two data plane locators instead of one so that each can be
3344 used in different directions of the path. To specify which locator is used on
3345 which direction, the Service Function Forwarder configuration is also more
3346 extensive compared to the previous example.
3347
3348 When comparing this example with the Logical SFF one, that the Service Function
3349 Forwarder is configured with data plane locators and that they hold the same
3350 interface name values as the corresponding Service Function interfaces. This is
3351 because in the Logical SFF particular case, a single logical interface fully
3352 describes an attachment of a Service Function Forwarder to a Service Function
3353 on both the Service Function and Service Function Forwarder sides. For
3354 non-Logical SFF scenarios, it would be expected for the data plane locators to
3355 have different values as we have seen on other examples through out this user
3356 guide. For example, if mac addresses are to be specified in the locators, the
3357 Service Function would have a different mac address than the Service Function
3358 Forwarder.
3359
3360
3361 As a result of the overall configuration, two Rendered Service Paths are
3362 implemented. The forward path:
3363
3364 ::
3365
3366                         +------------+                +-------+
3367                         | firewall-1 |                | dpi- 1 |
3368                         +---+---+----+                +--+--+-+
3369                             ^   |                        ^  |
3370                    net-A-dpl|   |net-B-dpl      net-A-dpl|  |net-B-dpl
3371                             |   |                        |  |
3372   +----------+              |   |                        |  |             +----------+
3373   | client A +--------------+   +------------------------+  +------------>+ server B |
3374   +----------+                                                            +----------+
3375
3376 And the reverse path:
3377
3378 ::
3379
3380                         +------------+                +-------+
3381                         | firewall 1 |                | dpi-1 |
3382                         +---+---+----+                +--+--+-+
3383                             |   ^                        |  ^
3384                    net-A-dpl|   |net-B-dpl      net-A-dpl|  |net-B-dpl
3385                             |   |                        |  |
3386   +----------+              |   |                        |  |             +----------+
3387   | client A +<-------------+   +------------------------+  +-------------+ server B |
3388   +----------+                                                            +----------+
3389
3390 Consider the following notes to put the example in context:
3391
3392 - The classification function is obviated from the illustration.
3393 - The forward path is up-link traffic from a client in network A to a server in
3394   network B.
3395 - The reverse path is down-link traffic from a server in network B to a client
3396   in network A.
3397 - The service functions might be legacy bump-in-the-wire network devices that
3398   need to use different interfaces for each network.
3399
3400 SFC Statistics User Guide
3401 -------------------------
3402
3403 Statistics can be queried for Rendered Service Paths created on OVS bridges.
3404 Future support will be added for Service Function Forwarders and Service
3405 Functions. Future support will also be added for VPP and IOs-XE devices.
3406
3407 To use SFC statistics the 'odl-sfc-statistics' Karaf feature needs to be
3408 installed.
3409
3410 Statistics are queried by sending an RPC RESTconf message to ODL. For
3411 RSPs, its possible to either query statistics for one individual RSP
3412 or for all RSPs, as follows:
3413
3414 Querying statistics for a specific RSP:
3415
3416 .. code-block:: bash
3417
3418    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
3419    --data '{ "input": { "name" : "path1-Path-42" } }' -X POST --user admin:admin
3420    http://localhost:8181/restconf/operations/sfc-statistics-operations:get-rsp-statistics
3421
3422
3423 Querying statistics for all RSPs:
3424
3425 .. code-block:: bash
3426
3427    curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
3428    --data '{ "input": { } }' -X POST --user admin:admin
3429    http://localhost:8181/restconf/operations/sfc-statistics-operations:get-rsp-statistics
3430
3431
3432 The following is the sort of output that can be expected for each RSP.
3433
3434 .. code-block:: none
3435
3436    {
3437        "output": {
3438            "statistics": [
3439                {
3440                    "name": "sfc-path-1sf1sff-Path-34",
3441                    "statistic-by-timestamp": [
3442                        {
3443                            "service-statistic": {
3444                                "bytes-in": 0,
3445                                "bytes-out": 0,
3446                                "packets-in": 0,
3447                                "packets-out": 0
3448                            },
3449                            "timestamp": 1518561500480
3450                        }
3451                    ]
3452                }
3453            ]
3454        }
3455    }