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