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