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 Plugin
  65 --------------------------
  66
  67 Overview
  68 ~~~~~~~~
  69
  70 The Southbound REST Plugin 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 Forwader (SFF)
  86
  87 -  Rendered Service Path (RSP)
  88
  89 Southbound REST Plugin Architecture
  90 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  91
  92 From the user perspective, the REST plugin is another SFC Southbound
  93 plugin used to communicate with network devices.
  94
  95 .. figure:: ./images/sfc/sb-rest-architecture-user.png
  96    :alt: Soutbound REST Plugin integration into ODL
  97
  98    Soutbound REST Plugin 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 Plugin 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 plugin
 130 will create a new OVS bridge and when a new OVS Bridge is created, the
 131 SFC-OVS plugin 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 workflow when OVS configuration is
 169 transformed to corresponding SFC objects (in this case SFF).
 170
 171 Prerequisities
 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 Prerequisities
 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 mannually 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 ip6tabeles 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 Classfier runs alongside sfc\_agent, therefore the commad 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 OpenFlow Switch Flow pipeline
 413 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 414
 415 The SFC OpenFlow Renderer uses the following tables for its Flow
 416 pipeline:
 417
 418 -  Table 0, Classifier
 419
 420 -  Table 1, Transport Ingress
 421
 422 -  Table 2, Path Mapper
 423
 424 -  Table 3, Path Mapper ACL
 425
 426 -  Table 4, Next Hop
 427
 428 -  Table 10, Transport Egress
 429
 430 The OpenFlow Table Pipeline is intended to be generic to work for all of
 431 the different encapsulations supported by SFC.
 432
 433 All of the tables are explained in detail in the following section.
 434
 435 The SFFs (SFF1 and SFF2), SFs (SF1), and topology used for the flow
 436 tables in the following sections are as described in the following
 437 diagram.
 438
 439 .. figure:: ./images/sfc/sfcofrenderer_nwtopo.png
 440    :alt: SFC OpenFlow Renderer Typical Network Topology
 441
 442    SFC OpenFlow Renderer Typical Network Topology
 443
 444 Classifier Table detailed
 445 ^^^^^^^^^^^^^^^^^^^^^^^^^
 446
 447 It is possible for the SFF to also act as a classifier. This table maps
 448 subscriber traffic to RSPs, and is explained in detail in the classifier
 449 documentation.
 450
 451 If the SFF is not a classifier, then this table will just have a simple
 452 Goto Table 1 flow.
 453
 454 Transport Ingress Table detailed
 455 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 456
 457 The Transport Ingress table has an entry per expected tunnel transport
 458 type to be received in a particular SFF, as established in the SFC
 459 configuration.
 460
 461 Here are two example on SFF1: one where the RSP ingress tunnel is MPLS
 462 assuming VLAN is used for the SFF-SF, and the other where the RSP
 463 ingress tunnel is NSH GRE (UDP port 4789):
 464
 465 +----------+-------------------------------------+--------------+
 466 | Priority | Match                               | Action       |
 467 +==========+=====================================+==============+
 468 | 256      | EtherType==0x8847 (MPLS unicast)    | Goto Table 2 |
 469 +----------+-------------------------------------+--------------+
 470 | 256      | EtherType==0x8100 (VLAN)            | Goto Table 2 |
 471 +----------+-------------------------------------+--------------+
 472 | 256      | EtherType==0x0800,udp,tp\_dst==4789 | Goto Table 2 |
 473 |          | (IP v4)                             |              |
 474 +----------+-------------------------------------+--------------+
 475 | 5        | Match Any                           | Drop         |
 476 +----------+-------------------------------------+--------------+
 477
 478 Table: Table Transport Ingress
 479
 480 Path Mapper Table detailed
 481 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 482
 483 The Path Mapper table has an entry per expected tunnel transport info to
 484 be received in a particular SFF, as established in the SFC
 485 configuration. The tunnel transport info is used to determine the RSP
 486 Path ID, and is stored in the OpenFlow Metadata. This table is not used
 487 for NSH, since the RSP Path ID is stored in the NSH header.
 488
 489 For SF nodes that do not support NSH tunneling, the IP header DSCP field
 490 is used to store the RSP Path Id. The RSP Path Id is written to the DSCP
 491 field in the Transport Egress table for those packets sent to an SF.
 492
 493 Here is an example on SFF1, assuming the following details:
 494
 495 -  VLAN ID 1000 is used for the SFF-SF
 496
 497 -  The RSP Path 1 tunnel uses MPLS label 100 for ingress and 101 for
 498    egress
 499
 500 -  The RSP Path 2 (symmetric downlink path) uses MPLS label 101 for
 501    ingress and 100 for egress
 502
 503 +----------+-------------------+-----------------------+
 504 | Priority | Match             | Action                |
 505 +==========+===================+=======================+
 506 | 256      | MPLS Label==100   | RSP Path=1, Pop MPLS, |
 507 |          |                   | Goto Table 4          |
 508 +----------+-------------------+-----------------------+
 509 | 256      | MPLS Label==101   | RSP Path=2, Pop MPLS, |
 510 |          |                   | Goto Table 4          |
 511 +----------+-------------------+-----------------------+
 512 | 256      | VLAN ID==1000, IP | RSP Path=1, Pop VLAN, |
 513 |          | DSCP==1           | Goto Table 4          |
 514 +----------+-------------------+-----------------------+
 515 | 256      | VLAN ID==1000, IP | RSP Path=2, Pop VLAN, |
 516 |          | DSCP==2           | Goto Table 4          |
 517 +----------+-------------------+-----------------------+
 518 | 5        | Match Any         | Goto Table 3          |
 519 +----------+-------------------+-----------------------+
 520
 521 Table: Table Path Mapper
 522
 523 Path Mapper ACL Table detailed
 524 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 525
 526 This table is only populated when PacketIn packets are received from the
 527 switch for TcpProxy type SFs. These flows are created with an inactivity
 528 timer of 60 seconds and will be automatically deleted upon expiration.
 529
 530 Next Hop Table detailed
 531 ^^^^^^^^^^^^^^^^^^^^^^^
 532
 533 The Next Hop table uses the RSP Path Id and appropriate packet fields to
 534 determine where to send the packet next. For NSH, only the NSP (Network
 535 Services Path, RSP ID) and NSI (Network Services Index, next hop) fields
 536 from the NSH header are needed to determine the VXLAN tunnel destination
 537 IP. For VLAN or MPLS, then the source MAC address is used to determine
 538 the destination MAC address.
 539
 540 Here are two examples on SFF1, assuming SFF1 is connected to SFF2. RSP
 541 Paths 1 and 2 are symmetric VLAN paths. RSP Paths 3 and 4 are symmetric
 542 NSH paths. RSP Path 1 ingress packets come from external to SFC, for
 543 which we don’t have the source MAC address (MacSrc).
 544
 545 +----------+--------------------------------+--------------------------------+
 546 | Priority | Match                          | Action                         |
 547 +==========+================================+================================+
 548 | 256      | RSP Path==1, MacSrc==SF1       | MacDst=SFF2, Goto Table 10     |
 549 +----------+--------------------------------+--------------------------------+
 550 | 256      | RSP Path==2, MacSrc==SF1       | Goto Table 10                  |
 551 +----------+--------------------------------+--------------------------------+
 552 | 256      | RSP Path==2, MacSrc==SFF2      | MacDst=SF1, Goto Table 10      |
 553 +----------+--------------------------------+--------------------------------+
 554 | 246      | RSP Path==1                    | MacDst=SF1, Goto Table 10      |
 555 +----------+--------------------------------+--------------------------------+
 556 | 256      | nsp=3,nsi=255 (SFF Ingress RSP | load:0xa000002→NXM\_NX\_TUN\_I |
 557 |          | 3)                             | PV4\_DST[],                    |
 558 |          |                                | Goto Table 10                  |
 559 +----------+--------------------------------+--------------------------------+
 560 | 256      | nsp=3,nsi=254 (SFF Ingress     | load:0xa00000a→NXM\_NX\_TUN\_I |
 561 |          | from SF, RSP 3)                | PV4\_DST[],                    |
 562 |          |                                | Goto Table 10                  |
 563 +----------+--------------------------------+--------------------------------+
 564 | 256      | nsp=4,nsi=254 (SFF1 Ingress    | load:0xa00000a→NXM\_NX\_TUN\_I |
 565 |          | from SFF2)                     | PV4\_DST[],                    |
 566 |          |                                | Goto Table 10                  |
 567 +----------+--------------------------------+--------------------------------+
 568 | 5        | Match Any                      | Drop                           |
 569 +----------+--------------------------------+--------------------------------+
 570
 571 Table: Table Next Hop
 572
 573 Transport Egress Table detailed
 574 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 575
 576 The Transport Egress table prepares egress tunnel information and sends
 577 the packets out.
 578
 579 Here are two examples on SFF1. RSP Paths 1 and 2 are symmetric MPLS
 580 paths that use VLAN for the SFF-SF. RSP Paths 3 and 4 are symmetric NSH
 581 paths. Since it is assumed that switches used for NSH will only have one
 582 VXLANport, the NSH packets are just sent back where they came from.
 583
 584 +----------+--------------------------------+--------------------------------+
 585 | Priority | Match                          | Action                         |
 586 +==========+================================+================================+
 587 | 256      | RSP Path==1, MacDst==SF1       | Push VLAN ID 1000, Port=SF1    |
 588 +----------+--------------------------------+--------------------------------+
 589 | 256      | RSP Path==1, MacDst==SFF2      | Push MPLS Label 101, Port=SFF2 |
 590 +----------+--------------------------------+--------------------------------+
 591 | 256      | RSP Path==2, MacDst==SF1       | Push VLAN ID 1000, Port=SF1    |
 592 +----------+--------------------------------+--------------------------------+
 593 | 246      | RSP Path==2                    | Push MPLS Label 100,           |
 594 |          |                                | Port=Ingress                   |
 595 +----------+--------------------------------+--------------------------------+
 596 | 256      | nsp=3,nsi=255 (SFF Ingress RSP | IN\_PORT                       |
 597 |          | 3)                             |                                |
 598 +----------+--------------------------------+--------------------------------+
 599 | 256      | nsp=3,nsi=254 (SFF Ingress     | IN\_PORT                       |
 600 |          | from SF, RSP 3)                |                                |
 601 +----------+--------------------------------+--------------------------------+
 602 | 256      | nsp=4,nsi=254 (SFF1 Ingress    | IN\_PORT                       |
 603 |          | from SFF2)                     |                                |
 604 +----------+--------------------------------+--------------------------------+
 605 | 5        | Match Any                      | Drop                           |
 606 +----------+--------------------------------+--------------------------------+
 607
 608 Table: Table Transport Egress
 609
 610 Administering SFC OF Renderer
 611 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 612
 613 To use the SFC OpenFlow Renderer Karaf, at least the following Karaf
 614 features must be installed.
 615
 616 -  odl-openflowplugin-nxm-extensions
 617
 618 -  odl-openflowplugin-flow-services
 619
 620 -  odl-sfc-provider
 621
 622 -  odl-sfc-model
 623
 624 -  odl-sfc-openflow-renderer
 625
 626 -  odl-sfc-ui (optional)
 627
 628 The following command can be used to view all of the currently installed
 629 Karaf features:
 630
 631 ::
 632
 633     opendaylight-user@root>feature:list -i
 634
 635 Or, pipe the command to a grep to see a subset of the currently
 636 installed Karaf features:
 637
 638 ::
 639
 640     opendaylight-user@root>feature:list -i | grep sfc
 641
 642 To install a particular feature, use the Karaf ``feature:install``
 643 command.
 644
 645 SFC OF Renderer Tutorial
 646 ~~~~~~~~~~~~~~~~~~~~~~~~
 647
 648 Overview
 649 ^^^^^^^^
 650
 651 In this tutorial, 2 different encapsulations will be shown: MPLS and
 652 NSH. The following Network Topology diagram is a logical view of the
 653 SFFs and SFs involved in creating the Service Chains.
 654
 655 .. figure:: ./images/sfc/sfcofrenderer_nwtopo.png
 656    :alt: SFC OpenFlow Renderer Typical Network Topology
 657
 658    SFC OpenFlow Renderer Typical Network Topology
 659
 660 Prerequisites
 661 ^^^^^^^^^^^^^
 662
 663 To use this example, SFF OpenFlow switches must be created and connected
 664 as illustrated above. Additionally, the SFs must be created and
 665 connected.
 666
 667 Target Environment
 668 ^^^^^^^^^^^^^^^^^^
 669
 670 The target environment is not important, but this use-case was created
 671 and tested on Linux.
 672
 673 Instructions
 674 ^^^^^^^^^^^^
 675
 676 The steps to use this tutorial are as follows. The referenced
 677 configuration in the steps is listed in the following sections.
 678
 679 There are numerous ways to send the configuration. In the following
 680 configuration chapters, the appropriate ``curl`` command is shown for
 681 each configuration to be sent, including the URL.
 682
 683 Steps to configure the SFC OF Renderer tutorial:
 684
 685 1. Send the ``SF`` RESTCONF configuration
 686
 687 2. Send the ``SFF`` RESTCONF configuration
 688
 689 3. Send the ``SFC`` RESTCONF configuration
 690
 691 4. Send the ``SFP`` RESTCONF configuration
 692
 693 5. Create the ``RSP`` with a RESTCONF RPC command
 694
 695 Once the configuration has been successfully created, query the Rendered
 696 Service Paths with either the SFC UI or via RESTCONF. Notice that the
 697 RSP is symmetrical, so the following 2 RSPs will be created:
 698
 699 -  sfc-path1
 700
 701 -  sfc-path1-Reverse
 702
 703 At this point the Service Chains have been created, and the OpenFlow
 704 Switches are programmed to steer traffic through the Service Chain.
 705 Traffic can now be injected from a client into the Service Chain. To
 706 debug problems, the OpenFlow tables can be dumped with the following
 707 commands, assuming SFF1 is called ``s1`` and SFF2 is called ``s2``.
 708
 709 ::
 710
 711     sudo ovs-ofctl -O OpenFlow13  dump-flows s1
 712
 713 ::
 714
 715     sudo ovs-ofctl -O OpenFlow13  dump-flows s2
 716
 717 In all the following configuration sections, replace the ``${JSON}``
 718 string with the appropriate JSON configuration. Also, change the
 719 ``localhost`` desintation in the URL accordingly.
 720
 721 SFC OF Renderer NSH Tutorial
 722 ''''''''''''''''''''''''''''
 723
 724 The following configuration sections show how to create the different
 725 elements using NSH encapsulation.
 726
 727 | **NSH Service Function configuration**
 728
 729 The Service Function configuration can be sent with the following
 730 command:
 731
 732 ::
 733
 734     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/
 735
 736 **SF configuration JSON.**
 737
 738 ::
 739
 740     {
 741      "service-functions": {
 742        "service-function": [
 743          {
 744            "name": "sf1",
 745            "type": "http-header-enrichment",
 746            "nsh-aware": true,
 747            "ip-mgmt-address": "10.0.0.2",
 748            "sf-data-plane-locator": [
 749              {
 750                "name": "sf1dpl",
 751                "ip": "10.0.0.10",
 752                "port": 4789,
 753                "transport": "service-locator:vxlan-gpe",
 754                "service-function-forwarder": "sff1"
 755              }
 756            ]
 757          },
 758          {
 759            "name": "sf2",
 760            "type": "firewall",
 761            "nsh-aware": true,
 762            "ip-mgmt-address": "10.0.0.3",
 763            "sf-data-plane-locator": [
 764              {
 765                "name": "sf2dpl",
 766                 "ip": "10.0.0.20",
 767                 "port": 4789,
 768                 "transport": "service-locator:vxlan-gpe",
 769                "service-function-forwarder": "sff2"
 770              }
 771            ]
 772          }
 773        ]
 774      }
 775     }
 776
 777 | **NSH Service Function Forwarder configuration**
 778
 779 The Service Function Forwarder configuration can be sent with the
 780 following command:
 781
 782 ::
 783
 784     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/
 785
 786 **SFF configuration JSON.**
 787
 788 ::
 789
 790     {
 791      "service-function-forwarders": {
 792        "service-function-forwarder": [
 793          {
 794            "name": "sff1",
 795            "service-node": "openflow:2",
 796            "sff-data-plane-locator": [
 797              {
 798                "name": "sff1dpl",
 799                "data-plane-locator":
 800                {
 801                    "ip": "10.0.0.1",
 802                    "port": 4789,
 803                    "transport": "service-locator:vxlan-gpe"
 804                }
 805              }
 806            ],
 807            "service-function-dictionary": [
 808              {
 809                "name": "sf1",
 810                "sff-sf-data-plane-locator":
 811                {
 812                    "sf-dpl-name": "sf1dpl",
 813                    "sff-dpl-name": "sff1dpl"
 814                }
 815              }
 816            ]
 817          },
 818          {
 819            "name": "sff2",
 820            "service-node": "openflow:3",
 821            "sff-data-plane-locator": [
 822              {
 823                "name": "sff2dpl",
 824                "data-plane-locator":
 825                {
 826                    "ip": "10.0.0.2",
 827                    "port": 4789,
 828                    "transport": "service-locator:vxlan-gpe"
 829                }
 830              }
 831            ],
 832            "service-function-dictionary": [
 833              {
 834                "name": "sf2",
 835                "sff-sf-data-plane-locator":
 836                {
 837                    "sf-dpl-name": "sf2dpl",
 838                    "sff-dpl-name": "sff2dpl"
 839                }
 840              }
 841            ]
 842          }
 843        ]
 844      }
 845     }
 846
 847 | **NSH Service Function Chain configuration**
 848
 849 The Service Function Chain configuration can be sent with the following
 850 command:
 851
 852 ::
 853
 854     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/
 855
 856 **SFC configuration JSON.**
 857
 858 ::
 859
 860     {
 861      "service-function-chains": {
 862        "service-function-chain": [
 863          {
 864            "name": "sfc-chain1",
 865            "symmetric": true,
 866            "sfc-service-function": [
 867              {
 868                "name": "hdr-enrich-abstract1",
 869                "type": "http-header-enrichment"
 870              },
 871              {
 872                "name": "firewall-abstract1",
 873                "type": "firewall"
 874              }
 875            ]
 876          }
 877        ]
 878      }
 879     }
 880
 881 | **NSH Service Function Path configuration**
 882
 883 The Service Function Path configuration can be sent with the following
 884 command:
 885
 886 ::
 887
 888     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/
 889
 890 **SFP configuration JSON.**
 891
 892 ::
 893
 894     {
 895       "service-function-paths": {
 896         "service-function-path": [
 897           {
 898             "name": "sfc-path1",
 899             "service-chain-name": "sfc-chain1",
 900             "transport-type": "service-locator:vxlan-gpe",
 901             "symmetric": true
 902           }
 903         ]
 904       }
 905     }
 906
 907 | **NSH Rendered Service Path creation**
 908
 909 ::
 910
 911     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/
 912
 913 **RSP creation JSON.**
 914
 915 ::
 916
 917     {
 918      "input": {
 919          "name": "sfc-path1",
 920          "parent-service-function-path": "sfc-path1",
 921          "symmetric": true
 922      }
 923     }
 924
 925 | **NSH Rendered Service Path removal**
 926
 927 The following command can be used to remove a Rendered Service Path
 928 called ``sfc-path1``:
 929
 930 ::
 931
 932     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/
 933
 934 | **NSH Rendered Service Path Query**
 935
 936 The following command can be used to query all of the created Rendered
 937 Service Paths:
 938
 939 ::
 940
 941     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/
 942
 943 SFC OF Renderer MPLS Tutorial
 944 '''''''''''''''''''''''''''''
 945
 946 The following configuration sections show how to create the different
 947 elements using MPLS encapsulation.
 948
 949 | **MPLS Service Function configuration**
 950
 951 The Service Function configuration can be sent with the following
 952 command:
 953
 954 ::
 955
 956     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/
 957
 958 **SF configuration JSON.**
 959
 960 ::
 961
 962     {
 963      "service-functions": {
 964        "service-function": [
 965          {
 966            "name": "sf1",
 967            "type": "http-header-enrichment",
 968            "nsh-aware": false,
 969            "ip-mgmt-address": "10.0.0.2",
 970            "sf-data-plane-locator": [
 971              {
 972                "name": "sf1-sff1",
 973                "mac": "00:00:08:01:02:01",
 974                "vlan-id": 1000,
 975                "transport": "service-locator:mac",
 976                "service-function-forwarder": "sff1"
 977              }
 978            ]
 979          },
 980          {
 981            "name": "sf2",
 982            "type": "firewall",
 983            "nsh-aware": false,
 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            "symmetric": true,
1154            "sfc-service-function": [
1155              {
1156                "name": "hdr-enrich-abstract1",
1157                "type": "http-header-enrichment"
1158              },
1159              {
1160                "name": "firewall-abstract1",
1161                "type": "firewall"
1162              }
1163            ]
1164          }
1165        ]
1166      }
1167     }
1168
1169 | **MPLS Service Function Path configuration**
1170
1171 The Service Function Path configuration can be sent with the following
1172 command:
1173
1174 ::
1175
1176     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/
1177
1178 **SFP configuration JSON.**
1179
1180 ::
1181
1182     {
1183       "service-function-paths": {
1184         "service-function-path": [
1185           {
1186             "name": "sfc-path1",
1187             "service-chain-name": "sfc-chain1",
1188             "transport-type": "service-locator:mpls",
1189             "symmetric": true
1190           }
1191         ]
1192       }
1193     }
1194
1195 | **MPLS Rendered Service Path creation**
1196
1197 ::
1198
1199     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/
1200
1201 **RSP creation JSON.**
1202
1203 ::
1204
1205     {
1206      "input": {
1207          "name": "sfc-path1",
1208          "parent-service-function-path": "sfc-path1",
1209          "symmetric": true
1210      }
1211     }
1212
1213 | **MPLS Rendered Service Path removal**
1214
1215 The following command can be used to remove a Rendered Service Path
1216 called ``sfc-path1``:
1217
1218 ::
1219
1220     curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '{"input": {"name": "sfc-path1" } }' -X POST --user admin:admin http://localhost:8181/restconf/operations/rendered-service-path:delete-rendered-path/
1221
1222 | **MPLS Rendered Service Path Query**
1223
1224 The following command can be used to query all of the created Rendered
1225 Service Paths:
1226
1227 ::
1228
1229     curl -H "Content-Type: application/json" -H "Cache-Control: no-cache" -X GET --user admin:admin http://localhost:8181/restconf/operational/rendered-service-path:rendered-service-paths/
1230
1231 SFC IOS XE Renderer User Guide
1232 ------------------------------
1233
1234 Overview
1235 ~~~~~~~~
1236
1237 The early Service Function Chaining (SFC) renderer for IOS-XE devices
1238 (SFC IOS-XE renderer) implements Service Chaining functionality on
1239 IOS-XE capable switches. It listens for the creation of a Rendered
1240 Service Path (RSP) and sets up Service Function Forwarders (SFF) that
1241 are hosted on IOS-XE switches to steer traffic through the service
1242 chain.
1243
1244 Common acronyms used in the following sections:
1245
1246 -  SF - Service Function
1247
1248 -  SFF - Service Function Forwarder
1249
1250 -  SFC - Service Function Chain
1251
1252 -  SP - Service Path
1253
1254 -  SFP - Service Function Path
1255
1256 -  RSP - Rendered Service Path
1257
1258 -  LSF - Local Service Forwarder
1259
1260 -  RSF - Remote Service Forwarder
1261
1262 SFC IOS-XE Renderer Architecture
1263 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1264
1265 When the SFC IOS-XE renderer is initialized, all required listeners are
1266 registered to handle incoming data. It involves CSR/IOS-XE
1267 ``NodeListener`` which stores data about all configurable devices
1268 including their mountpoints (used here as databrokers),
1269 ``ServiceFunctionListener``, ``ServiceForwarderListener`` (see mapping)
1270 and ``RenderedPathListener`` used to listen for RSP changes. When the
1271 SFC IOS-XE renderer is invoked, ``RenderedPathListener`` calls the
1272 ``IosXeRspProcessor`` which processes the RSP change and creates all
1273 necessary Service Paths and Remote Service Forwarders (if necessary) on
1274 IOS-XE devices.
1275
1276 Service Path details
1277 ~~~~~~~~~~~~~~~~~~~~
1278
1279 Each Service Path is defined by index (represented by NSP) and contains
1280 service path entries. Each entry has appropriate service index (NSI) and
1281 definition of next hop. Next hop can be Service Function, different
1282 Service Function Forwarder or definition of end of chain - terminate.
1283 After terminating, the packet is sent to destination. If a SFF is
1284 defined as a next hop, it has to be present on device in the form of
1285 Remote Service Forwarder. RSFs are also created during RSP processing.
1286
1287 Example of Service Path:
1288
1289 ::
1290
1291     service-chain service-path 200
1292        service-index 255 service-function firewall-1
1293        service-index 254 service-function dpi-1
1294        service-index 253 terminate
1295
1296 Mapping to IOS-XE SFC entities
1297 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1298
1299 Renderer contains mappers for SFs and SFFs. IOS-XE capable device is
1300 using its own definition of Service Functions and Service Function
1301 Forwarders according to appropriate .yang file.
1302 ``ServiceFunctionListener`` serves as a listener for SF changes. If SF
1303 appears in datastore, listener extracts its management ip address and
1304 looks into cached IOS-XE nodes. If some of available nodes match,
1305 Service function is mapped in ``IosXeServiceFunctionMapper`` to be
1306 understandable by IOS-XE device and it’s written into device’s config.
1307 ``ServiceForwarderListener`` is used in a similar way. All SFFs with
1308 suitable management ip address it mapped in
1309 ``IosXeServiceForwarderMapper``. Remapped SFFs are configured as a Local
1310 Service Forwarders. It is not possible to directly create Remote Service
1311 Forwarder using IOS-XE renderer. RSF is created only during RSP
1312 processing.
1313
1314 Administering SFC IOS-XE renderer
1315 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1316
1317 To use the SFC IOS-XE Renderer Karaf, at least the following Karaf
1318 features must be installed:
1319
1320 -  odl-aaa-shiro
1321
1322 -  odl-sfc-model
1323
1324 -  odl-sfc-provider
1325
1326 -  odl-restconf
1327
1328 -  odl-netconf-topology
1329
1330 -  odl-sfc-ios-xe-renderer
1331
1332 SFC IOS-XE renderer Tutorial
1333 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1334
1335 Overview
1336 ^^^^^^^^
1337
1338 This tutorial is a simple example how to create Service Path on IOS-XE
1339 capable device using IOS-XE renderer
1340
1341 Preconditions
1342 ^^^^^^^^^^^^^
1343
1344 To connect to IOS-XE device, it is necessary to use several modified
1345 yang models and override device’s ones. All .yang files are in the
1346 ``Yang/netconf`` folder in the ``sfc-ios-xe-renderer module`` in the SFC
1347 project. These files have to be copied to the ``cache/schema``
1348 directory, before Karaf is started. After that, custom capabilities have
1349 to be sent to network-topology:
1350
1351 ::
1352
1353     PUT ./config/network-topology:network-topology/topology/topology-netconf/node/<device-name>
1354
1355     <node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
1356       <node-id>device-name</node-id>
1357       <host xmlns="urn:opendaylight:netconf-node-topology">device-ip</host>
1358       <port xmlns="urn:opendaylight:netconf-node-topology">2022</port>
1359       <username xmlns="urn:opendaylight:netconf-node-topology">login</username>
1360       <password xmlns="urn:opendaylight:netconf-node-topology">password</password>
1361       <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
1362       <keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">0</keepalive-delay>
1363       <yang-module-capabilities xmlns="urn:opendaylight:netconf-node-topology">
1364          <override>true</override>
1365          <capability xmlns="urn:opendaylight:netconf-node-topology">
1366             urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&amp;revision=2013-07-15
1367          </capability>
1368          <capability xmlns="urn:opendaylight:netconf-node-topology">
1369             urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&amp;revision=2013-07-15
1370          </capability>
1371          <capability xmlns="urn:opendaylight:netconf-node-topology">
1372             urn:ios?module=ned&amp;revision=2016-03-08
1373          </capability>
1374          <capability xmlns="urn:opendaylight:netconf-node-topology">
1375             http://tail-f.com/yang/common?module=tailf-common&amp;revision=2015-05-22
1376          </capability>
1377          <capability xmlns="urn:opendaylight:netconf-node-topology">
1378             http://tail-f.com/yang/common?module=tailf-meta-extensions&amp;revision=2013-11-07
1379          </capability>
1380          <capability xmlns="urn:opendaylight:netconf-node-topology">
1381             http://tail-f.com/yang/common?module=tailf-cli-extensions&amp;revision=2015-03-19
1382          </capability>
1383       </yang-module-capabilities>
1384     </node>
1385
1386 .. note::
1387
1388     The device name in the URL and in the XML must match.
1389
1390 Instructions
1391 ^^^^^^^^^^^^
1392
1393 When the IOS-XE renderer is installed, all NETCONF nodes in
1394 topology-netconf are processed and all capable nodes with accessible
1395 mountpoints are cached. The first step is to create LSF on node.
1396
1397 ``Service Function Forwarder configuration``
1398
1399 ::
1400
1401     PUT ./config/service-function-forwarder:service-function-forwarders
1402
1403     {
1404         "service-function-forwarders": {
1405             "service-function-forwarder": [
1406                 {
1407                     "name": "CSR1Kv-2",
1408                     "ip-mgmt-address": "172.25.73.23",
1409                     "sff-data-plane-locator": [
1410                         {
1411                             "name": "CSR1Kv-2-dpl",
1412                             "data-plane-locator": {
1413                                 "transport": "service-locator:vxlan-gpe",
1414                                 "port": 6633,
1415                                 "ip": "10.99.150.10"
1416                             }
1417                         }
1418                     ]
1419                 }
1420             ]
1421         }
1422     }
1423
1424 If the IOS-XE node with appropriate management IP exists, this
1425 configuration is mapped and LSF is created on the device. The same
1426 approach is used for Service Functions.
1427
1428 ::
1429
1430     PUT ./config/service-function:service-functions
1431
1432     {
1433         "service-functions": {
1434             "service-function": [
1435                 {
1436                     "name": "Firewall",
1437                     "ip-mgmt-address": "172.25.73.23",
1438                     "type": "service-function-type: firewall",
1439                     "nsh-aware": true,
1440                     "sf-data-plane-locator": [
1441                         {
1442                             "name": "firewall-dpl",
1443                             "port": 6633,
1444                             "ip": "12.1.1.2",
1445                             "transport": "service-locator:gre",
1446                             "service-function-forwarder": "CSR1Kv-2"
1447                         }
1448                     ]
1449                 },
1450                 {
1451                     "name": "Dpi",
1452                     "ip-mgmt-address": "172.25.73.23",
1453                     "type":"service-function-type: dpi",
1454                     "nsh-aware": true,
1455                     "sf-data-plane-locator": [
1456                         {
1457                             "name": "dpi-dpl",
1458                             "port": 6633,
1459                             "ip": "12.1.1.1",
1460                             "transport": "service-locator:gre",
1461                             "service-function-forwarder": "CSR1Kv-2"
1462                         }
1463                     ]
1464                 },
1465                 {
1466                     "name": "Qos",
1467                     "ip-mgmt-address": "172.25.73.23",
1468                     "type":"service-function-type: qos",
1469                     "nsh-aware": true,
1470                     "sf-data-plane-locator": [
1471                         {
1472                             "name": "qos-dpl",
1473                             "port": 6633,
1474                             "ip": "12.1.1.4",
1475                             "transport": "service-locator:gre",
1476                             "service-function-forwarder": "CSR1Kv-2"
1477                         }
1478                     ]
1479                 }
1480             ]
1481         }
1482     }
1483
1484 All these SFs are configured on the same device as the LSF. The next
1485 step is to prepare Service Function Chain. SFC is symmetric.
1486
1487 ::
1488
1489     PUT ./config/service-function-chain:service-function-chains/
1490
1491     {
1492         "service-function-chains": {
1493             "service-function-chain": [
1494                 {
1495                     "name": "CSR3XSF",
1496                     "symmetric": "true",
1497                     "sfc-service-function": [
1498                         {
1499                             "name": "Firewall",
1500                             "type": "service-function-type: firewall"
1501                         },
1502                         {
1503                             "name": "Dpi",
1504                             "type": "service-function-type: dpi"
1505                         },
1506                         {
1507                             "name": "Qos",
1508                             "type": "service-function-type: qos"
1509                         }
1510                     ]
1511                 }
1512             ]
1513         }
1514     }
1515
1516 Service Function Path:
1517
1518 ::
1519
1520     PUT ./config/service-function-path:service-function-paths/
1521
1522     {
1523         "service-function-paths": {
1524             "service-function-path": [
1525                 {
1526                     "name": "CSR3XSF-Path",
1527                     "service-chain-name": "CSR3XSF",
1528                     "starting-index": 255,
1529                     "symmetric": "true"
1530                 }
1531             ]
1532         }
1533     }
1534
1535 Without a classifier, there is possibility to POST RSP directly.
1536
1537 ::
1538
1539     POST ./operations/rendered-service-path:create-rendered-path
1540
1541     {
1542       "input": {
1543           "name": "CSR3XSF-Path-RSP",
1544           "parent-service-function-path": "CSR3XSF-Path",
1545           "symmetric": true
1546       }
1547     }
1548
1549 The resulting configuration:
1550
1551 ::
1552
1553     !
1554     service-chain service-function-forwarder local
1555       ip address 10.99.150.10
1556     !
1557     service-chain service-function firewall
1558     ip address 12.1.1.2
1559       encapsulation gre enhanced divert
1560     !
1561     service-chain service-function dpi
1562     ip address 12.1.1.1
1563       encapsulation gre enhanced divert
1564     !
1565     service-chain service-function qos
1566     ip address 12.1.1.4
1567       encapsulation gre enhanced divert
1568     !
1569     service-chain service-path 1
1570       service-index 255 service-function firewall
1571       service-index 254 service-function dpi
1572       service-index 253 service-function qos
1573       service-index 252 terminate
1574     !
1575     service-chain service-path 2
1576       service-index 255 service-function qos
1577       service-index 254 service-function dpi
1578       service-index 253 service-function firewall
1579       service-index 252 terminate
1580     !
1581
1582 Service Path 1 is direct, Service Path 2 is reversed. Path numbers may
1583 vary.
1584
1585 Service Function Scheduling Algorithms
1586 --------------------------------------
1587
1588 Overview
1589 ~~~~~~~~
1590
1591 When creating the Rendered Service Path, the origin SFC controller chose
1592 the first available service function from a list of service function
1593 names. This may result in many issues such as overloaded service
1594 functions and a longer service path as SFC has no means to understand
1595 the status of service functions and network topology. The service
1596 function selection framework supports at least four algorithms (Random,
1597 Round Robin, Load Balancing and Shortest Path) to select the most
1598 appropriate service function when instantiating the Rendered Service
1599 Path. In addition, it is an extensible framework that allows 3rd party
1600 selection algorithm to be plugged in.
1601
1602 Architecture
1603 ~~~~~~~~~~~~
1604
1605 The following figure illustrates the service function selection
1606 framework and algorithms.
1607
1608 .. figure:: ./images/sfc/sf-selection-arch.png
1609    :alt: SF Selection Architecture
1610
1611    SF Selection Architecture
1612
1613 A user has three different ways to select one service function selection
1614 algorithm:
1615
1616 1. Integrated RESTCONF Calls. OpenStack and/or other administration
1617    system could provide plugins to call the APIs to select one
1618    scheduling algorithm.
1619
1620 2. Command line tools. Command line tools such as curl or browser
1621    plugins such as POSTMAN (for Google Chrome) and RESTClient (for
1622    Mozilla Firefox) could select schedule algorithm by making RESTCONF
1623    calls.
1624
1625 3. SFC-UI. Now the SFC-UI provides an option for choosing a selection
1626    algorithm when creating a Rendered Service Path.
1627
1628 The RESTCONF northbound SFC API provides GUI/RESTCONF interactions for
1629 choosing the service function selection algorithm. MD-SAL data store
1630 provides all supported service function selection algorithms, and
1631 provides APIs to enable one of the provided service function selection
1632 algorithms. Once a service function selection algorithm is enabled, the
1633 service function selection algorithm will work when creating a Rendered
1634 Service Path.
1635
1636 Select SFs with Scheduler
1637 ~~~~~~~~~~~~~~~~~~~~~~~~~
1638
1639 Administrator could use both the following ways to select one of the
1640 selection algorithm when creating a Rendered Service Path.
1641
1642 -  Command line tools. Command line tools includes Linux commands curl
1643    or even browser plugins such as POSTMAN(for Google Chrome) or
1644    RESTClient(for Mozilla Firefox). In this case, the following JSON
1645    content is needed at the moment:
1646    Service\_function\_schudule\_type.json
1647
1648    ::
1649
1650        {
1651          "service-function-scheduler-types": {
1652            "service-function-scheduler-type": [
1653              {
1654                "name": "random",
1655                "type": "service-function-scheduler-type:random",
1656                "enabled": false
1657              },
1658              {
1659                "name": "roundrobin",
1660                "type": "service-function-scheduler-type:round-robin",
1661                "enabled": true
1662              },
1663              {
1664                "name": "loadbalance",
1665                "type": "service-function-scheduler-type:load-balance",
1666                "enabled": false
1667              },
1668              {
1669                "name": "shortestpath",
1670                "type": "service-function-scheduler-type:shortest-path",
1671                "enabled": false
1672              }
1673            ]
1674          }
1675        }
1676
1677    If using the Linux curl command, it could be:
1678
1679    ::
1680
1681        curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '$${Service_function_schudule_type.json}'
1682        -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-scheduler-type:service-function-scheduler-types/
1683
1684    Here is also a snapshot for using the RESTClient plugin:
1685
1686 .. figure:: ./images/sfc/RESTClient-snapshot.png
1687    :alt: Mozilla Firefox RESTClient
1688
1689    Mozilla Firefox RESTClient
1690
1691 -  SFC-UI.SFC-UI provides a drop down menu for service function
1692    selection algorithm. Here is a snapshot for the user interaction from
1693    SFC-UI when creating a Rendered Service Path.
1694
1695 .. figure:: ./images/sfc/karaf-webui-select-a-type.png
1696    :alt: Karaf Web UI
1697
1698    Karaf Web UI
1699
1700 .. note::
1701
1702     Some service function selection algorithms in the drop list are not
1703     implemented yet. Only the first three algorithms are committed at
1704     the moment.
1705
1706 Random
1707 ^^^^^^
1708
1709 Select Service Function from the name list randomly.
1710
1711 Overview
1712 ''''''''
1713
1714 The Random algorithm is used to select one Service Function from the
1715 name list which it gets from the Service Function Type randomly.
1716
1717 Prerequisites
1718 '''''''''''''
1719
1720 -  Service Function information are stored in datastore.
1721
1722 -  Either no algorithm or the Random algorithm is selected.
1723
1724 Target Environment
1725 ''''''''''''''''''
1726
1727 The Random algorithm will work either no algorithm type is selected or
1728 the Random algorithm is selected.
1729
1730 Instructions
1731 ''''''''''''
1732
1733 Once the plugins are installed into Karaf successfully, a user can use
1734 his favorite method to select the Random scheduling algorithm type.
1735 There are no special instructions for using the Random algorithm.
1736
1737 Round Robin
1738 ^^^^^^^^^^^
1739
1740 Select Service Function from the name list in Round Robin manner.
1741
1742 Overview
1743 ''''''''
1744
1745 The Round Robin algorithm is used to select one Service Function from
1746 the name list which it gets from the Service Function Type in a Round
1747 Robin manner, this will balance workloads to all Service Functions.
1748 However, this method cannot help all Service Functions load the same
1749 workload because it’s flow-based Round Robin.
1750
1751 Prerequisites
1752 '''''''''''''
1753
1754 -  Service Function information are stored in datastore.
1755
1756 -  Round Robin algorithm is selected
1757
1758 Target Environment
1759 ''''''''''''''''''
1760
1761 The Round Robin algorithm will work one the Round Robin algorithm is
1762 selected.
1763
1764 Instructions
1765 ''''''''''''
1766
1767 Once the plugins are installed into Karaf successfully, a user can use
1768 his favorite method to select the Round Robin scheduling algorithm type.
1769 There are no special instructions for using the Round Robin algorithm.
1770
1771 Load Balance Algorithm
1772 ^^^^^^^^^^^^^^^^^^^^^^
1773
1774 Select appropriate Service Function by actual CPU utilization.
1775
1776 Overview
1777 ''''''''
1778
1779 The Load Balance Algorithm is used to select appropriate Service
1780 Function by actual CPU utilization of service functions. The CPU
1781 utilization of service function obtained from monitoring information
1782 reported via NETCONF.
1783
1784 Prerequisites
1785 '''''''''''''
1786
1787 -  CPU-utilization for Service Function.
1788
1789 -  NETCONF server.
1790
1791 -  NETCONF client.
1792
1793 -  Each VM has a NETCONF server and it could work with NETCONF client
1794    well.
1795
1796 Instructions
1797 ''''''''''''
1798
1799 Set up VMs as Service Functions. enable NETCONF server in VMs. Ensure
1800 that you specify them separately. For example:
1801
1802 a. Set up 4 VMs include 2 SFs' type are Firewall, Others are Napt44.
1803    Name them as firewall-1, firewall-2, napt44-1, napt44-2 as Service
1804    Function. The four VMs can run either the same server or different
1805    servers.
1806
1807 b. Install NETCONF server on every VM and enable it. More information on
1808    NETCONF can be found on the OpenDaylight wiki here:
1809    https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf:Manual_netopeer_installation
1810
1811 c. Get Monitoring data from NETCONF server. These monitoring data should
1812    be get from the NETCONF server which is running in VMs. The following
1813    static XML data is an example:
1814
1815 static XML data like this:
1816
1817 ::
1818
1819     <?xml version="1.0" encoding="UTF-8"?>
1820     <service-function-description-monitor-report>
1821       <SF-description>
1822         <number-of-dataports>2</number-of-dataports>
1823         <capabilities>
1824           <supported-packet-rate>5</supported-packet-rate>
1825           <supported-bandwidth>10</supported-bandwidth>
1826           <supported-ACL-number>2000</supported-ACL-number>
1827           <RIB-size>200</RIB-size>
1828           <FIB-size>100</FIB-size>
1829           <ports-bandwidth>
1830             <port-bandwidth>
1831               <port-id>1</port-id>
1832               <ipaddress>10.0.0.1</ipaddress>
1833               <macaddress>00:1e:67:a2:5f:f4</macaddress>
1834               <supported-bandwidth>20</supported-bandwidth>
1835             </port-bandwidth>
1836             <port-bandwidth>
1837               <port-id>2</port-id>
1838               <ipaddress>10.0.0.2</ipaddress>
1839               <macaddress>01:1e:67:a2:5f:f6</macaddress>
1840               <supported-bandwidth>10</supported-bandwidth>
1841             </port-bandwidth>
1842           </ports-bandwidth>
1843         </capabilities>
1844       </SF-description>
1845       <SF-monitoring-info>
1846         <liveness>true</liveness>
1847         <resource-utilization>
1848             <packet-rate-utilization>10</packet-rate-utilization>
1849             <bandwidth-utilization>15</bandwidth-utilization>
1850             <CPU-utilization>12</CPU-utilization>
1851             <memory-utilization>17</memory-utilization>
1852             <available-memory>8</available-memory>
1853             <RIB-utilization>20</RIB-utilization>
1854             <FIB-utilization>25</FIB-utilization>
1855             <power-utilization>30</power-utilization>
1856             <SF-ports-bandwidth-utilization>
1857               <port-bandwidth-utilization>
1858                 <port-id>1</port-id>
1859                 <bandwidth-utilization>20</bandwidth-utilization>
1860               </port-bandwidth-utilization>
1861               <port-bandwidth-utilization>
1862                 <port-id>2</port-id>
1863                 <bandwidth-utilization>30</bandwidth-utilization>
1864               </port-bandwidth-utilization>
1865             </SF-ports-bandwidth-utilization>
1866         </resource-utilization>
1867       </SF-monitoring-info>
1868     </service-function-description-monitor-report>
1869
1870 a. Unzip SFC release tarball.
1871
1872 b. Run SFC: ${sfc}/bin/karaf. More information on Service Function
1873    Chaining can be found on the OpenDaylight SFC’s wiki page:
1874    https://wiki.opendaylight.org/view/Service_Function_Chaining:Main
1875
1876 a. Deploy the SFC2 (firewall-abstract2⇒napt44-abstract2) and click
1877    button to Create Rendered Service Path in SFC UI
1878    (http://localhost:8181/sfc/index.html).
1879
1880 b. Verify the Rendered Service Path to ensure the CPU utilization of the
1881    selected hop is the minimum one among all the service functions with
1882    same type. The correct RSP is firewall-1⇒napt44-2
1883
1884 Shortest Path Algorithm
1885 ^^^^^^^^^^^^^^^^^^^^^^^
1886
1887 Select appropriate Service Function by Dijkstra’s algorithm. Dijkstra’s
1888 algorithm is an algorithm for finding the shortest paths between nodes
1889 in a graph.
1890
1891 Overview
1892 ''''''''
1893
1894 The Shortest Path Algorithm is used to select appropriate Service
1895 Function by actual topology.
1896
1897 Prerequisites
1898 '''''''''''''
1899
1900 -  Depolyed topology (include SFFs, SFs and their links).
1901
1902 -  Dijkstra’s algorithm. More information on Dijkstra’s algorithm can be
1903    found on the wiki here:
1904    http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm
1905
1906 Instructions
1907 ''''''''''''
1908
1909 a. Unzip SFC release tarball.
1910
1911 b. Run SFC: ${sfc}/bin/karaf.
1912
1913 c. Depoly SFFs and SFs. import the service-function-forwarders.json and
1914    service-functions.json in UI
1915    (http://localhost:8181/sfc/index.html#/sfc/config)
1916
1917 service-function-forwarders.json:
1918
1919 ::
1920
1921     {
1922       "service-function-forwarders": {
1923         "service-function-forwarder": [
1924           {
1925             "name": "SFF-br1",
1926             "service-node": "OVSDB-test01",
1927             "rest-uri": "http://localhost:5001",
1928             "sff-data-plane-locator": [
1929               {
1930                 "name": "eth0",
1931                 "service-function-forwarder-ovs:ovs-bridge": {
1932                   "uuid": "4c3778e4-840d-47f4-b45e-0988e514d26c",
1933                   "bridge-name": "br-tun"
1934                 },
1935                 "data-plane-locator": {
1936                   "port": 5000,
1937                   "ip": "192.168.1.1",
1938                   "transport": "service-locator:vxlan-gpe"
1939                 }
1940               }
1941             ],
1942             "service-function-dictionary": [
1943               {
1944                 "sff-sf-data-plane-locator": {
1945                   "port": 10001,
1946                   "ip": "10.3.1.103"
1947                 },
1948                 "name": "napt44-1",
1949                 "type": "service-function-type:napt44"
1950               },
1951               {
1952                 "sff-sf-data-plane-locator": {
1953                   "port": 10003,
1954                   "ip": "10.3.1.102"
1955                 },
1956                 "name": "firewall-1",
1957                 "type": "service-function-type:firewall"
1958               }
1959             ],
1960             "connected-sff-dictionary": [
1961               {
1962                 "name": "SFF-br3"
1963               }
1964             ]
1965           },
1966           {
1967             "name": "SFF-br2",
1968             "service-node": "OVSDB-test01",
1969             "rest-uri": "http://localhost:5002",
1970             "sff-data-plane-locator": [
1971               {
1972                 "name": "eth0",
1973                 "service-function-forwarder-ovs:ovs-bridge": {
1974                   "uuid": "fd4d849f-5140-48cd-bc60-6ad1f5fc0a1",
1975                   "bridge-name": "br-tun"
1976                 },
1977                 "data-plane-locator": {
1978                   "port": 5000,
1979                   "ip": "192.168.1.2",
1980                   "transport": "service-locator:vxlan-gpe"
1981                 }
1982               }
1983             ],
1984             "service-function-dictionary": [
1985               {
1986                 "sff-sf-data-plane-locator": {
1987                   "port": 10002,
1988                   "ip": "10.3.1.103"
1989                 },
1990                 "name": "napt44-2",
1991                 "type": "service-function-type:napt44"
1992               },
1993               {
1994                 "sff-sf-data-plane-locator": {
1995                   "port": 10004,
1996                   "ip": "10.3.1.101"
1997                 },
1998                 "name": "firewall-2",
1999                 "type": "service-function-type:firewall"
2000               }
2001             ],
2002             "connected-sff-dictionary": [
2003               {
2004                 "name": "SFF-br3"
2005               }
2006             ]
2007           },
2008           {
2009             "name": "SFF-br3",
2010             "service-node": "OVSDB-test01",
2011             "rest-uri": "http://localhost:5005",
2012             "sff-data-plane-locator": [
2013               {
2014                 "name": "eth0",
2015                 "service-function-forwarder-ovs:ovs-bridge": {
2016                   "uuid": "fd4d849f-5140-48cd-bc60-6ad1f5fc0a4",
2017                   "bridge-name": "br-tun"
2018                 },
2019                 "data-plane-locator": {
2020                   "port": 5000,
2021                   "ip": "192.168.1.2",
2022                   "transport": "service-locator:vxlan-gpe"
2023                 }
2024               }
2025             ],
2026             "service-function-dictionary": [
2027               {
2028                 "sff-sf-data-plane-locator": {
2029                   "port": 10005,
2030                   "ip": "10.3.1.104"
2031                 },
2032                 "name": "test-server",
2033                 "type": "service-function-type:dpi"
2034               },
2035               {
2036                 "sff-sf-data-plane-locator": {
2037                   "port": 10006,
2038                   "ip": "10.3.1.102"
2039                 },
2040                 "name": "test-client",
2041                 "type": "service-function-type:dpi"
2042               }
2043             ],
2044             "connected-sff-dictionary": [
2045               {
2046                 "name": "SFF-br1"
2047               },
2048               {
2049                 "name": "SFF-br2"
2050               }
2051             ]
2052           }
2053         ]
2054       }
2055     }
2056
2057 service-functions.json:
2058
2059 ::
2060
2061     {
2062       "service-functions": {
2063         "service-function": [
2064           {
2065             "rest-uri": "http://localhost:10001",
2066             "ip-mgmt-address": "10.3.1.103",
2067             "sf-data-plane-locator": [
2068               {
2069                 "name": "preferred",
2070                 "port": 10001,
2071                 "ip": "10.3.1.103",
2072                 "service-function-forwarder": "SFF-br1"
2073               }
2074             ],
2075             "name": "napt44-1",
2076             "type": "service-function-type:napt44",
2077             "nsh-aware": true
2078           },
2079           {
2080             "rest-uri": "http://localhost:10002",
2081             "ip-mgmt-address": "10.3.1.103",
2082             "sf-data-plane-locator": [
2083               {
2084                 "name": "master",
2085                 "port": 10002,
2086                 "ip": "10.3.1.103",
2087                 "service-function-forwarder": "SFF-br2"
2088               }
2089             ],
2090             "name": "napt44-2",
2091             "type": "service-function-type:napt44",
2092             "nsh-aware": true
2093           },
2094           {
2095             "rest-uri": "http://localhost:10003",
2096             "ip-mgmt-address": "10.3.1.103",
2097             "sf-data-plane-locator": [
2098               {
2099                 "name": "1",
2100                 "port": 10003,
2101                 "ip": "10.3.1.102",
2102                 "service-function-forwarder": "SFF-br1"
2103               }
2104             ],
2105             "name": "firewall-1",
2106             "type": "service-function-type:firewall",
2107             "nsh-aware": true
2108           },
2109           {
2110             "rest-uri": "http://localhost:10004",
2111             "ip-mgmt-address": "10.3.1.103",
2112             "sf-data-plane-locator": [
2113               {
2114                 "name": "2",
2115                 "port": 10004,
2116                 "ip": "10.3.1.101",
2117                 "service-function-forwarder": "SFF-br2"
2118               }
2119             ],
2120             "name": "firewall-2",
2121             "type": "service-function-type:firewall",
2122             "nsh-aware": true
2123           },
2124           {
2125             "rest-uri": "http://localhost:10005",
2126             "ip-mgmt-address": "10.3.1.103",
2127             "sf-data-plane-locator": [
2128               {
2129                 "name": "3",
2130                 "port": 10005,
2131                 "ip": "10.3.1.104",
2132                 "service-function-forwarder": "SFF-br3"
2133               }
2134             ],
2135             "name": "test-server",
2136             "type": "service-function-type:dpi",
2137             "nsh-aware": true
2138           },
2139           {
2140             "rest-uri": "http://localhost:10006",
2141             "ip-mgmt-address": "10.3.1.103",
2142             "sf-data-plane-locator": [
2143               {
2144                 "name": "4",
2145                 "port": 10006,
2146                 "ip": "10.3.1.102",
2147                 "service-function-forwarder": "SFF-br3"
2148               }
2149             ],
2150             "name": "test-client",
2151             "type": "service-function-type:dpi",
2152             "nsh-aware": true
2153           }
2154         ]
2155       }
2156     }
2157
2158 The depolyed topology like this:
2159
2160 ::
2161
2162                   +----+           +----+          +----+
2163                   |sff1|+----------|sff3|---------+|sff2|
2164                   +----+           +----+          +----+
2165                     |                                  |
2166              +--------------+                   +--------------+
2167              |              |                   |              |
2168         +----------+   +--------+          +----------+   +--------+
2169         |firewall-1|   |napt44-1|          |firewall-2|   |napt44-2|
2170         +----------+   +--------+          +----------+   +--------+
2171
2172 -  Deploy the SFC2(firewall-abstract2⇒napt44-abstract2), select
2173    "Shortest Path" as schedule type and click button to Create Rendered
2174    Service Path in SFC UI (http://localhost:8181/sfc/index.html).
2175
2176 .. figure:: ./images/sfc/sf-schedule-type.png
2177    :alt: select schedule type
2178
2179    select schedule type
2180
2181 -  Verify the Rendered Service Path to ensure the selected hops are
2182    linked in one SFF. The correct RSP is firewall-1⇒napt44-1 or
2183    firewall-2⇒napt44-2. The first SF type is Firewall in Service
2184    Function Chain. So the algorithm will select first Hop randomly among
2185    all the SFs type is Firewall. Assume the first selected SF is
2186    firewall-2. All the path from firewall-1 to SF which type is Napt44
2187    are list:
2188
2189    -  Path1: firewall-2 → sff2 → napt44-2
2190
2191    -  Path2: firewall-2 → sff2 → sff3 → sff1 → napt44-1 The shortest
2192       path is Path1, so the selected next hop is napt44-2.
2193
2194 .. figure:: ./images/sfc/sf-rendered-service-path.png
2195    :alt: rendered service path
2196
2197    rendered service path
2198
2199 Service Function Load Balancing User Guide
2200 ------------------------------------------
2201
2202 Overview
2203 ~~~~~~~~
2204
2205 SFC Load-Balancing feature implements load balancing of Service
2206 Functions, rather than a one-to-one mapping between
2207 Service-Function-Forwarder and Service-Function.
2208
2209 Load Balancing Architecture
2210 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
2211
2212 Service Function Groups (SFG) can replace Service Functions (SF) in the
2213 Rendered Path model. A Service Path can only be defined using SFGs or
2214 SFs, but not a combination of both.
2215
2216 Relevant objects in the YANG model are as follows:
2217
2218 1. Service-Function-Group-Algorithm:
2219
2220    ::
2221
2222        Service-Function-Group-Algorithms {
2223            Service-Function-Group-Algorithm {
2224                String name
2225                String type
2226            }
2227        }
2228
2229    ::
2230
2231        Available types: ALL, SELECT, INDIRECT, FAST_FAILURE
2232
2233 2. Service-Function-Group:
2234
2235    ::
2236
2237        Service-Function-Groups {
2238            Service-Function-Group {
2239                String name
2240                String serviceFunctionGroupAlgorithmName
2241                String type
2242                String groupId
2243                Service-Function-Group-Element {
2244                    String service-function-name
2245                    int index
2246                }
2247            }
2248        }
2249
2250 3. ServiceFunctionHop: holds a reference to a name of SFG (or SF)
2251
2252 Tutorials
2253 ~~~~~~~~~
2254
2255 This tutorial will explain how to create a simple SFC configuration,
2256 with SFG instead of SF. In this example, the SFG will include two
2257 existing SF.
2258
2259 Setup SFC
2260 ^^^^^^^^^
2261
2262 For general SFC setup and scenarios, please see the SFC wiki page:
2263 https://wiki.opendaylight.org/view/Service_Function_Chaining:Main#SFC_101
2264
2265 Create an algorithm
2266 ^^^^^^^^^^^^^^^^^^^
2267
2268 POST -
2269 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2270
2271 ::
2272
2273     {
2274         "service-function-group-algorithm": [
2275           {
2276             "name": "alg1"
2277             "type": "ALL"
2278           }
2279        ]
2280     }
2281
2282 (Header "content-type": application/json)
2283
2284 Verify: get all algorithms
2285 ^^^^^^^^^^^^^^^^^^^^^^^^^^
2286
2287 GET -
2288 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2289
2290 In order to delete all algorithms: DELETE -
2291 http://127.0.0.1:8181/restconf/config/service-function-group-algorithm:service-function-group-algorithms
2292
2293 Create a group
2294 ^^^^^^^^^^^^^^
2295
2296 POST -
2297 http://127.0.0.1:8181/restconf/config/service-function-group:service-function-groups
2298
2299 ::
2300
2301     {
2302         "service-function-group": [
2303         {
2304             "rest-uri": "http://localhost:10002",
2305             "ip-mgmt-address": "10.3.1.103",
2306             "algorithm": "alg1",
2307             "name": "SFG1",
2308             "type": "service-function-type:napt44",
2309             "sfc-service-function": [
2310                 {
2311                     "name":"napt44-104"
2312                 },
2313                 {
2314                     "name":"napt44-103-1"
2315                 }
2316             ]
2317           }
2318         ]
2319     }
2320
2321 Verify: get all SFG’s
2322 ^^^^^^^^^^^^^^^^^^^^^
2323
2324 GET -
2325 http://127.0.0.1:8181/restconf/config/service-function-group:service-function-groups
2326
2327 SFC Proof of Transit User Guide
2328 -------------------------------
2329
2330 Overview
2331 ~~~~~~~~
2332
2333 Early Service Function Chaining (SFC) Proof of Transit (SFC Proof of
2334 Transit) implements Service Chaining Proof of Transit functionality on
2335 capable switches. After the creation of an Rendered Service Path (RSP),
2336 a user can configure to enable SFC proof of transit on the selected RSP
2337 to effect the proof of transit.
2338
2339 Common acronyms used in the following sections:
2340
2341 -  SF - Service Function
2342
2343 -  SFF - Service Function Forwarder
2344
2345 -  SFC - Service Function Chain
2346
2347 -  SFP - Service Function Path
2348
2349 -  RSP - Rendered Service Path
2350
2351 -  SFCPOT - Service Function Chain Proof of Transit
2352
2353 SFC Proof of Transit Architecture
2354 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2355
2356 When SFC Proof of Transit is initialized, all required listeners are
2357 registered to handle incoming data. It involves ``SfcPotNodeListener``
2358 which stores data about all node devices including their mountpoints
2359 (used here as databrokers), ``SfcPotRSPDataListener``,
2360 ``RenderedPathListener``. ``RenderedPathListener`` is used to listen for
2361 RSP changes. ``SfcPotRSPDataListener`` implements RPC services to enable
2362 or disable SFC Proof of Transit on a particular RSP. When the SFC Proof
2363 of Transit is invoked, RSP listeners and service implementations are
2364 setup to receive SFCPOT configurations. When a user configures via a
2365 POST RPC call to enable SFCPOT on a particular RSP, the configuration
2366 drives the creation of necessary augmentations to the RSP to effect the
2367 SFCPOT configurations.
2368
2369 SFC Proof of Transit details
2370 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2371
2372 Several deployments use traffic engineering, policy routing, segment
2373 routing or service function chaining (SFC) to steer packets through a
2374 specific set of nodes. In certain cases regulatory obligations or a
2375 compliance policy require to prove that all packets that are supposed to
2376 follow a specific path are indeed being forwarded across the exact set
2377 of nodes specified. I.e. if a packet flow is supposed to go through a
2378 series of service functions or network nodes, it has to be proven that
2379 all packets of the flow actually went through the service chain or
2380 collection of nodes specified by the policy. In case the packets of a
2381 flow weren’t appropriately processed, a proof of transit egress device
2382 would be required to identify the policy violation and take
2383 corresponding actions (e.g. drop or redirect the packet, send an alert
2384 etc.) corresponding to the policy.
2385
2386 The SFCPOT approach is based on meta-data which is added to every
2387 packet. The meta data is updated at every hop and is used to verify
2388 whether a packet traversed all required nodes. A particular path is
2389 either described by a set of secret keys, or a set of shares of a single
2390 secret. Nodes on the path retrieve their individual keys or shares of a
2391 key (using for e.g. Shamir’s Shared Sharing Secret scheme) from a
2392 central controller. The complete key set is only known to the verifier-
2393 which is typically the ultimate node on a path that requires proof of
2394 transit. Each node in the path uses its secret or share of the secret to
2395 update the meta-data of the packets as the packets pass through the
2396 node. When the verifier receives a packet, it can use its key(s) along
2397 with the meta-data to validate whether the packet traversed the service
2398 chain correctly.
2399
2400 SFC Proof of Transit entities
2401 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2402
2403 In order to implement SFC Proof of Transit for a service function chain,
2404 an RSP is a pre-requisite to identify the SFC to enable SFC PoT on. SFC
2405 Proof of Transit for a particular RSP is enabled by an RPC request to
2406 the controller along with necessary parameters to control some of the
2407 aspects of the SFC Proof of Transit process.
2408
2409 The RPC handler identifies the RSP and generates SFC Proof of Transit
2410 parameters like secret share, secret etc., and adds the generated SFCPOT
2411 configuration parameters to SFC main as well as the various SFC hops.
2412 The last node in the SFC is configured as a verifier node to allow
2413 SFCPOT Proof of Transit process to be completed.
2414
2415 The SFCPOT configuration generators and related handling are done by
2416 ``SfcPotAPI``, ``SfcPotConfigGenerator``, ``SfcPotListener``,
2417 ``SfcPotPolyAPI``, ``SfcPotPolyClassAPI`` and ``SfcPotPolyClass``.
2418
2419 Administering SFC Proof of Transit
2420 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2421
2422 To use the SFC Proof of Transit Karaf, at least the following Karaf
2423 features must be installed:
2424
2425 -  odl-sfc-model
2426
2427 -  odl-sfc-provider
2428
2429 -  odl-sfc-netconf
2430
2431 -  odl-restconf
2432
2433 -  odl-netconf-topology
2434
2435 -  odl-netconf-connector-all
2436
2437 -  odl-sfc-pot
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 server device advertise capability as under ioam-scv.yang
2453 present under src/main/yang folder of sfc-pot feature. It is also
2454 expected that netconf notifications be enabled and its support
2455 capability advertised as capabilities.
2456
2457 It is also expected that the devices are netconf mounted and available
2458 in the topology-netconf store.
2459
2460 Instructions
2461 ^^^^^^^^^^^^
2462
2463 When SFC Proof of Transit is installed, all netconf nodes in
2464 topology-netconf are processed and all capable nodes with accessible
2465 mountpoints are cached.
2466
2467 First step is to create the required RSP as usually done.
2468
2469 Once RSP name is avaiable it is used to send a POST RPC to the
2470 controller similar to below:
2471
2472 ::
2473
2474     POST ./restconf/operations/sfc-ioam-nb-pot:enable-sfc-ioam-pot-rendered-path
2475
2476     {
2477       "input": {
2478         "sfc-ioam-pot-rsp-name": "rsp1"
2479       }
2480     }
2481
2482 The following can be used to disable the SFC Proof of Transit on an RSP
2483 which removes the augmentations and stores back the RSP without the
2484 SFCPOT enabled features and also sending down a delete configuration to
2485 the SFCPOT configuration sub-tree in the nodes.
2486
2487 ::
2488
2489     POST ./restconf/operations/sfc-ioam-nb-pot:disable-sfc-ioam-pot-rendered-path
2490
2491     {
2492       "input": {
2493         "sfc-ioam-pot-rsp-name": "rsp1"
2494       }
2495     }
2496