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

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