docs/user-guide/network-intent-composition-(nic)-user-guide.rst

   1 .. _nic-user-guide:
   2
   3 Network Intent Composition (NIC) User Guide
   4 ===========================================
   5
   6 Overview
   7 --------
   8
   9 Network Intent Composition (NIC) is an interface that allows clients to
  10 express a desired state in an implementation-neutral form that will be
  11 enforced via modification of available resources under the control of
  12 the OpenDaylight system.
  13
  14 This description is purposely abstract as an intent interface might
  15 encompass network services, virtual devices, storage, etc.
  16
  17 The intent interface is meant to be a controller-agnostic interface so
  18 that "intents" are portable across implementations, such as OpenDaylight
  19 and ONOS. Thus an intent specification should not contain implementation
  20 or technology specifics.
  21
  22 The intent specification will be implemented by decomposing the intent
  23 and augmenting it with implementation specifics that are driven by local
  24 implementation rules, policies, and/or settings.
  25
  26 Network Intent Composition (NIC) Architecture
  27 ---------------------------------------------
  28
  29 The core of the NIC architecture is the intent model, which specifies
  30 the details of the desired state. It is the responsibility of the NIC
  31 implementation transforms this desired state to the resources under the
  32 control of OpenDaylight. The component that transforms the intent to the
  33 implementation is typically referred to as a renderer.
  34
  35 For the Boron release, multiple, simultaneous renderers will not be
  36 supported. Instead either the VTN or GBP renderer feature can be
  37 installed, but not both.
  38
  39 For the Boron release, the only actions supported are "ALLOW" and
  40 "BLOCK". The "ALLOW" action indicates that traffic can flow between the
  41 source and destination end points, while "BLOCK" prevents that flow;
  42 although it is possible that an given implementation may augment the
  43 available actions with additional actions.
  44
  45 Besides transforming a desired state to an actual state it is the
  46 responsibility of a renderer to update the operational state tree for
  47 the NIC data model in OpenDaylight to reflect the intent which the
  48 renderer implemented.
  49
  50 Configuring Network Intent Composition (NIC)
  51 --------------------------------------------
  52
  53 For the Boron release there is no default implementation of a renderer,
  54 thus without an additional module installed the NIC will not function.
  55
  56 Administering or Managing Network Intent Composition (NIC)
  57 ----------------------------------------------------------
  58
  59 There is no additional administration of management capabilities related
  60 to the Network Intent Composition features.
  61
  62 Interactions
  63 ------------
  64
  65 A user can interact with the Network Intent Composition (NIC) either
  66 through the RESTful interface using standard RESTCONF operations and
  67 syntax or via the Karaf console CLI.
  68
  69 REST
  70 ~~~~
  71
  72 Configuration
  73 ^^^^^^^^^^^^^
  74
  75 The Network Intent Composition (NIC) feature supports the following REST
  76 operations against the configuration data store.
  77
  78 -  POST - creates a new instance of an intent in the configuration
  79    store, which will trigger the realization of that intent. An ID
  80    *must* be specified as part of this request as an attribute of the
  81    intent.
  82
  83 -  GET - fetches a list of all configured intents or a specific
  84    configured intent.
  85
  86 -  DELETE - removes a configured intent from the configuration store,
  87    which triggers the removal of the intent from the network.
  88
  89 Operational
  90 ^^^^^^^^^^^
  91
  92 The Network Intent Composition (NIC) feature supports the following REST
  93 operations against the operational data store.
  94
  95 -  GET - fetches a list of all operational intents or a specific
  96    operational intent.
  97
  98 Karaf Console CLI
  99 ~~~~~~~~~~~~~~~~~
 100
 101 This feature provides karaf console CLI command to manipulate the intent
 102 data model. The CLI essentailly invokes the equivalent data operations.
 103
 104 intent:add
 105 ^^^^^^^^^^
 106
 107 Creates a new intent in the configuration data tree
 108
 109 ::
 110
 111     DESCRIPTION
 112             intent:add
 113
 114         Adds an intent to the controller.
 115
 116     Examples: --actions [ALLOW] --from <subject> --to <subject>
 117               --actions [BLOCK] --from <subject>
 118
 119     SYNTAX
 120             intent:add [options]
 121
 122     OPTIONS
 123             -a, --actions
 124                     Action to be performed.
 125                     -a / --actions BLOCK/ALLOW
 126                     (defaults to [BLOCK])
 127             --help
 128                     Display this help message
 129             -t, --to
 130                     Second Subject.
 131                     -t / --to <subject>
 132                     (defaults to any)
 133             -f, --from
 134                     First subject.
 135                     -f / --from <subject>
 136                     (defaults to any)
 137
 138 intent:delete
 139 ^^^^^^^^^^^^^
 140
 141 Removes an existing intent from the system
 142
 143 ::
 144
 145     DESCRIPTION
 146             intent:remove
 147
 148         Removes an intent from the controller.
 149
 150     SYNTAX
 151             intent:remove id
 152
 153     ARGUMENTS
 154             id  Intent Id
 155
 156 intent:list
 157 ^^^^^^^^^^^
 158
 159 Lists all the intents in the system
 160
 161 ::
 162
 163     DESCRIPTION
 164             intent:list
 165
 166         Lists all intents in the controller.
 167
 168     SYNTAX
 169             intent:list [options]
 170
 171     OPTIONS
 172             -c, --config
 173                     List Configuration Data (optional).
 174                     -c / --config <ENTER>
 175             --help
 176                     Display this help message
 177
 178 intent:show
 179 ^^^^^^^^^^^
 180
 181 Displayes the details of a single intent
 182
 183 ::
 184
 185     DESCRIPTION
 186             intent:show
 187
 188         Shows detailed information about an intent.
 189
 190     SYNTAX
 191             intent:show id
 192
 193     ARGUMENTS
 194             id  Intent Id
 195
 196 intent:map
 197 ^^^^^^^^^^
 198
 199 List/Add/Delete current state from/to the mapping service.
 200
 201 ::
 202
 203     DESCRIPTION
 204             intent:map
 205
 206             List/Add/Delete current state from/to the mapping service.
 207
 208     SYNTAX
 209             intent:map [options]
 210
 211              Examples: --list, -l [ENTER], to retrieve all keys.
 212                        --add-key <key> [ENTER], to add a new key with empty contents.
 213                        --del-key <key> [ENTER], to remove a key with it's values."
 214                        --add-key <key> --value [<value 1>, <value 2>, ...] [ENTER],
 215                          to add a new key with some values (json format).
 216     OPTIONS
 217            --help
 218                Display this help message
 219            -l, --list
 220                List values associated with a particular key.
 221            -l / --filter <regular expression> [ENTER]
 222            --add-key
 223                Adds a new key to the mapping service.
 224            --add-key <key name> [ENTER]
 225            --value
 226                Specifies which value should be added/delete from the mapping service.
 227            --value "key=>value"... --value "key=>value" [ENTER]
 228                (defaults to [])
 229            --del-key
 230                Deletes a key from the mapping service.
 231            --del-key <key name> [ENTER]
 232
 233 NIC Usage Examples
 234 ------------------
 235
 236 Default Requirements
 237 ~~~~~~~~~~~~~~~~~~~~
 238
 239 Start mininet, and create three switches (s1, s2, and s3) and four hosts
 240 (h1, h2, h3, and h4) in it.
 241
 242 Replace <Controller IP> based on your environment.
 243
 244 ::
 245
 246     $  sudo mn --mac --topo single,2 --controller=remote,ip=<Controller IP>
 247
 248 ::
 249
 250      mininet> net
 251      h1 h1-eth0:s2-eth1
 252      h2 h2-eth0:s2-eth2
 253      h3 h3-eth0:s3-eth1
 254      h4 h4-eth0:s3-eth2
 255      s1 lo:  s1-eth1:s2-eth3 s1-eth2:s3-eth3
 256      s2 lo:  s2-eth1:h1-eth0 s2-eth2:h2-eth0 s2-eth3:s1-eth1
 257      s3 lo:  s3-eth1:h3-eth0 s3-eth2:h4-eth0 s3-eth3:s1-eth2
 258
 259 Downloading and deploy Karaf distribution
 260 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 261
 262 -  Get the Boron distribution.
 263
 264 -  Unzip the downloaded zip distribution.
 265
 266 -  To run the Karaf.
 267
 268 ::
 269
 270     ./bin/karaf
 271
 272 -  Once the console is up, type as below to install feature.
 273
 274 ::
 275
 276     feature:install odl-nic-core-mdsal odl-nic-console odl-nic-listeners
 277
 278 Simple Mininet topology
 279 -----------------------
 280
 281 .. code:: python
 282
 283     !/usr/bin/python
 284
 285     from mininet.topo import Topo
 286
 287     class SimpleTopology( Topo ):
 288         "Simple topology example."
 289
 290         def __init__( self ):
 291             "Create custom topo."
 292
 293
 294         Topo.__init__( self )
 295
 296
 297             Switch1 = self.addSwitch( 's1' )
 298             Switch2 = self.addSwitch( 's2' )
 299             Switch3 = self.addSwitch( 's3' )
 300             Switch4 = self.addSwitch( 's4' )
 301             Host11 = self.addHost( 'h1' )
 302             Host12 = self.addHost( 'h2' )
 303             Host21 = self.addHost( 'h3' )
 304             Host22 = self.addHost( 'h4' )
 305             Host23 = self.addHost( 'h5' )
 306             Service1 = self.addHost( 'srvc1' )
 307
 308
 309             self.addLink( Host11, Switch1 )
 310             self.addLink( Host12, Switch1 )
 311             self.addLink( Host21, Switch2 )
 312             self.addLink( Host22, Switch2 )
 313             self.addLink( Host23, Switch2 )
 314             self.addLink( Switch1, Switch2 )
 315             self.addLink( Switch2, Switch4 )
 316             self.addLink( Switch4, Switch3 )
 317             self.addLink( Switch3, Switch1 )
 318             self.addLink( Switch3, Service1 )
 319             self.addLink( Switch4, Service1 )
 320
 321
 322     topos = { 'simpletopology': ( lambda: SimpleTopology() ) }
 323
 324 -  Initialize topology
 325
 326 -  Add hosts and switches
 327
 328 -  Host used to represent the service
 329
 330 -  Add links
 331
 332     Source: https://gist.github.com/vinothgithub15/315d0a427d5afc39f2d7
 333
 334 How to configure VTN Renderer
 335 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 336
 337 The section demonstrates allow or block packets of the traffic within a
 338 VTN Renderer, according to the specified flow conditions.
 339
 340 The table below lists the actions to be applied when a packet matches
 341 the condition:
 342
 343 +----------------+-----------------------------------------------------------+
 344 | Action         | Function                                                  |
 345 +================+===========================================================+
 346 | Allow          | Permits the packet to be forwarded normally.              |
 347 +----------------+-----------------------------------------------------------+
 348 | Block          | Discards the packet preventing it from being forwarded.   |
 349 +----------------+-----------------------------------------------------------+
 350
 351 Requirement
 352 ^^^^^^^^^^^
 353
 354 -  Before execute the follow steps, please, use default requirements.
 355    See section `Default Requirements <#_default_requirements>`__.
 356
 357 Configuration
 358 ^^^^^^^^^^^^^
 359
 360 Please execute the following curl commands to test network intent using
 361 mininet:
 362
 363 Create Intent
 364 '''''''''''''
 365
 366 To provision the network for the two hosts(h1 and h2) and demonstrates
 367 the action allow.
 368
 369 ::
 370
 371     curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436034 -d '{ "intent:intent" : { "intent:id": "b9a13232-525e-4d8c-be21-cd65e3436034", "intent:actions" : [ { "order" : 2, "allow" : {} } ], "intent:subjects" : [ { "order":1 , "end-point-group" : {"name":"10.0.0.1"} }, { "order":2 , "end-point-group" : {"name":"10.0.0.2"}} ] } }'
 372
 373 To provision the network for the two hosts(h2 and h3) and demonstrates
 374 the action allow.
 375
 376 ::
 377
 378     curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436035 -d '{ "intent:intent" : { "intent:id": "b9a13232-525e-4d8c-be21-cd65e3436035", "intent:actions" : [ { "order" : 2, "allow" : {} } ], "intent:subjects" : [ { "order":1 , "end-point-group" : {"name":"10.0.0.2"} }, { "order":2 , "end-point-group" : {"name":"10.0.0.3"}} ] } }'
 379
 380 Verification
 381 ''''''''''''
 382
 383 As we have applied action type allow now ping should happen between
 384 hosts (h1 and h2) and (h2 and h3).
 385
 386 ::
 387
 388      mininet> pingall
 389      Ping: testing ping reachability
 390      h1 -> h2 X X
 391      h2 -> h1 h3 X
 392      h3 -> X h2 X
 393      h4 -> X X X
 394
 395 Update the intent
 396 '''''''''''''''''
 397
 398 To provision block action that indicates traffic is not allowed between
 399 h1 and h2.
 400
 401 ::
 402
 403     curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436034 -d '{ "intent:intent" : { "intent:id": "b9a13232-525e-4d8c-be21-cd65e3436034", "intent:actions" : [ { "order" : 2, "block" : {} } ], "intent:subjects" : [ { "order":1 , "end-point-group" : {"name":"10.0.0.1"} }, { "order":2 , "end-point-group" : {"name":"10.0.0.2"}} ] } }'
 404
 405 Verification
 406 ''''''''''''
 407
 408 As we have applied action type block now ping should not happen between
 409 hosts (h1 and h2).
 410
 411 ::
 412
 413      mininet> pingall
 414      Ping: testing ping reachability
 415      h1 -> X X X
 416      h2 -> X h3 X
 417      h3 -> X h2 X
 418      h4 -> X X X
 419
 420 .. note::
 421
 422     Old actions and hosts are replaced by the new action and hosts.
 423
 424 Delete the intent
 425 '''''''''''''''''
 426
 427 Respective intent and the traffics will be deleted.
 428
 429 ::
 430
 431     curl -v --user "admin":"admin" -H "Accept: application/json" -H     "Content-type: application/json" -X DELETE http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436035
 432
 433 Verification
 434 ''''''''''''
 435
 436 Deletion of intent and flow.
 437
 438 ::
 439
 440      mininet> pingall
 441      Ping: testing ping reachability
 442      h1 -> X X X
 443      h2 -> X X X
 444      h3 -> X X X
 445      h4 -> X X X
 446
 447 .. note::
 448
 449     Ping between two hosts can also be done using MAC Address
 450
 451 To provision the network for the two hosts(h1 MAC address and h2 MAC
 452 address).
 453
 454 ::
 455
 456     curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436035 -d '{ "intent:intent" : { "intent:id": "b9a13232-525e-4d8c-be21-cd65e3436035", "intent:actions" : [ { "order" : 2, "allow" : {} } ], "intent:subjects" : [ { "order":1 , "end-point-group" : {"name":"6e:4f:f7:27:15:c9"} }, { "order":2 , "end-point-group" : {"name":"aa:7d:1f:4a:70:81"}} ] } }'
 457
 458 How to configure Redirect Action
 459 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 460
 461 The section explains the redirect action supported in NIC. The redirect
 462 functionality supports forwarding (to redirect) the traffic to a service
 463 configured in SFC before forwarding it to the destination.
 464
 465 .. figure:: ./images/nic/Service_Chaining.png
 466    :alt: REDIRECT SERVICE
 467
 468    REDIRECT SERVICE
 469
 470 Following steps explain Redirect action function:
 471
 472 -  Configure the service in SFC using the SFC APIs.
 473
 474 -  Configure the intent with redirect action and the service information
 475    where the traffic needs to be redirected.
 476
 477 -  The flows are computed as below
 478
 479    1. First flow entry between the source host connected node and the
 480       ingress node of the configured service.
 481
 482    2. Second flow entry between the egress Node id the configured
 483       service and the ID and destination host connected host.
 484
 485    3. Third flow entry between the destination host node and the source
 486       host node.
 487
 488 Requirement
 489 ^^^^^^^^^^^
 490
 491 -  Save the mininet `Simple Mininet
 492    topology <#_simple_mininet_topology>`__ script as redirect\_test.py
 493
 494 -  Start mininet, and create switches in it.
 495
 496 Replace <Controller IP> based on your environment.
 497
 498 ::
 499
 500     sudo mn --controller=remote,ip=<Controller IP>--custom redirect_test.py --topo mytopo2
 501
 502 ::
 503
 504      mininet> net
 505      h1 h1-eth0:s1-eth1
 506      h2 h2-eth0:s1-eth2
 507      h3 h3-eth0:s2-eth1
 508      h4 h4-eth0:s2-eth2
 509      h5 h5-eth0:s2-eth3
 510      srvc1 srvc1-eth0:s3-eth3 srvc1-eth1:s4-eth3
 511      s1 lo:  s1-eth1:h1-eth0 s1-eth2:h2-eth0 s1-eth3:s2-eth4 s1-eth4:s3-eth2
 512      s2 lo:  s2-eth1:h3-eth0 s2-eth2:h4-eth0 s2-eth3:h5-eth0 s2-eth4:s1-eth3 s2-eth5:s4-eth1
 513      s3 lo:  s3-eth1:s4-eth2 s3-eth2:s1-eth4 s3-eth3:srvc1-eth0
 514      s4 lo:  s4-eth1:s2-eth5 s4-eth2:s3-eth1 s4-eth3:srvc1-eth1
 515      c0
 516
 517 Starting the Karaf
 518 ^^^^^^^^^^^^^^^^^^
 519
 520 -  Before execute the following steps, please, use the default
 521    requirements. See section `Downloading and deploy Karaf
 522    distribution <#_default_requirements>`__.
 523
 524 Configuration
 525 ^^^^^^^^^^^^^
 526
 527 Mininet
 528 '''''''
 529
 530 .. figure:: ./images/nic/Redirect_flow.png
 531    :alt: CONFIGURATION THE NETWORK IN MININET
 532
 533    CONFIGURATION THE NETWORK IN MININET
 534
 535 -  Configure srvc1 as service node in the mininet environment.
 536
 537 Please execute the following commands in the mininet console (where
 538 mininet script is executed).
 539
 540 ::
 541
 542      srvc1 ip addr del 10.0.0.6/8 dev srvc1-eth0
 543      srvc1 brctl addbr br0
 544      srvc1 brctl addif br0 srvc1-eth0
 545      srvc1 brctl addif br0 srvc1-eth1
 546      srvc1 ifconfig br0 up
 547      srvc1 tc qdisc add dev srvc1-eth1 root netem delay 200ms
 548
 549 Configure service in SFC
 550 ''''''''''''''''''''''''
 551
 552 The service (srvc1) is configured using SFC REST API. As part of the
 553 configuration the ingress and egress node connected the service is
 554 configured.
 555
 556 ::
 557
 558     curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '{
 559       "service-functions": {
 560         "service-function": [
 561           {
 562             "name": "srvc1",
 563             "sf-data-plane-locator": [
 564               {
 565                 "name": "Egress",
 566                 "service-function-forwarder": "openflow:4"
 567               },
 568               {
 569                 "name": "Ingress",
 570                 "service-function-forwarder": "openflow:3"
 571               }
 572             ],
 573             "nsh-aware": false,
 574             "type": "delay"
 575           }
 576         ]
 577       }
 578     }' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function:service-functions/
 579
 580 **SFF RESTCONF Request**
 581
 582 Configuring switch and port information for the service functions.
 583
 584 ::
 585
 586     curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '{
 587       "service-function-forwarders": {
 588         "service-function-forwarder": [
 589           {
 590             "name": "openflow:3",
 591             "service-node": "OVSDB2",
 592             "sff-data-plane-locator": [
 593               {
 594                 "name": "Ingress",
 595                 "data-plane-locator":
 596                 {
 597                     "vlan-id": 100,
 598                     "mac": "11:11:11:11:11:11",
 599                     "transport": "service-locator:mac"
 600                 },
 601                 "service-function-forwarder-ofs:ofs-port":
 602                 {
 603                     "port-id" : "3"
 604                 }
 605               }
 606             ],
 607             "service-function-dictionary": [
 608               {
 609                 "name": "srvc1",
 610                 "sff-sf-data-plane-locator":
 611                 {
 612                     "sf-dpl-name" : "openflow:3",
 613                     "sff-dpl-name" : "Ingress"
 614                 }
 615               }
 616             ]
 617           },
 618           {
 619             "name": "openflow:4",
 620             "service-node": "OVSDB3",
 621             "sff-data-plane-locator": [
 622               {
 623                 "name": "Egress",
 624                 "data-plane-locator":
 625                 {
 626                     "vlan-id": 200,
 627                     "mac": "44:44:44:44:44:44",
 628                     "transport": "service-locator:mac"
 629                 },
 630                 "service-function-forwarder-ofs:ofs-port":
 631                 {
 632                     "port-id" : "3"
 633                 }
 634               }
 635             ],
 636             "service-function-dictionary": [
 637               {
 638                 "name": "srvc1",
 639                 "sff-sf-data-plane-locator":
 640                 {
 641                     "sf-dpl-name" : "openflow:4",
 642                     "sff-dpl-name" : "Egress"
 643                 }
 644               }
 645             ]
 646           }
 647         ]
 648       }
 649     }' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/
 650
 651 CLI Command
 652 '''''''''''
 653
 654 To provision the network for the two hosts (h1 and h5).
 655
 656 Demonstrates the redirect action with service name srvc1.
 657
 658 ::
 659
 660     intent:add -f <SOURCE_MAC> -t <DESTINATION_MAC> -a REDIRECT -s <SERVICE_NAME>
 661
 662 Example:
 663
 664 ::
 665
 666     intent:add -f 32:bc:ec:65:a7:d1 -t c2:80:1f:77:41:ed -a REDIRECT -s srvc1
 667
 668 Verification
 669 ''''''''''''
 670
 671 -  As we have applied action type redirect now ping should happen
 672    between hosts h1 and h5.
 673
 674 ::
 675
 676      mininet> h1 ping h5
 677      PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
 678      64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=201 ms
 679      64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=200 ms
 680      64 bytes from 10.0.0.5: icmp_seq=4 ttl=64 time=200 ms
 681
 682 The redirect functionality can be verified by the time taken by the ping
 683 operation (200ms). The service srvc1 configured using SFC introduces
 684 200ms delay. As the traffic from h1 to h5 is redirected via the srvc1,
 685 the time taken by the traffic from h1 to h5 will take about 200ms.
 686
 687 -  Flow entries added to nodes for the redirect action.
 688
 689 ::
 690
 691      mininet> dpctl dump-flows
 692      *** s1 ------------------------------------------------------------------------
 693      NXST_FLOW reply (xid=0x4):
 694      cookie=0x0, duration=9.406s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=1,dl_src=32:bc:ec:65:a7:d1, dl_dst=c2:80:1f:77:41:ed actions=output:4
 695      cookie=0x0, duration=9.475s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=3,dl_src=c2:80:1f:77:41:ed, dl_dst=32:bc:ec:65:a7:d1 actions=output:1
 696      cookie=0x1, duration=362.315s, table=0, n_packets=144, n_bytes=12240, idle_age=4, priority=9500,dl_type=0x88cc actions=CONTROLLER:65535
 697      cookie=0x1, duration=362.324s, table=0, n_packets=4, n_bytes=168, idle_age=3, priority=10000,arp actions=CONTROLLER:65535,NORMAL
 698      *** s2 ------------------------------------------------------------------------
 699      NXST_FLOW reply (xid=0x4):
 700      cookie=0x0, duration=9.503s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=3,dl_src=c2:80:1f:77:41:ed, dl_dst=32:bc:ec:65:a7:d1 actions=output:4
 701      cookie=0x0, duration=9.437s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=5,dl_src=32:bc:ec:65:a7:d1, dl_dst=c2:80:1f:77:41:ed actions=output:3
 702      cookie=0x3, duration=362.317s, table=0, n_packets=144, n_bytes=12240, idle_age=4, priority=9500,dl_type=0x88cc actions=CONTROLLER:65535
 703      cookie=0x3, duration=362.32s, table=0, n_packets=4, n_bytes=168, idle_age=3, priority=10000,arp actions=CONTROLLER:65535,NORMAL
 704      *** s3 ------------------------------------------------------------------------
 705      NXST_FLOW reply (xid=0x4):
 706      cookie=0x0, duration=9.41s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=2,dl_src=32:bc:ec:65:a7:d1, dl_dst=c2:80:1f:77:41:ed actions=output:3
 707      *** s4 ------------------------------------------------------------------------
 708      NXST_FLOW reply (xid=0x4):
 709      cookie=0x0, duration=9.486s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=3,dl_src=32:bc:ec:65:a7:d1, dl_dst=c2:80:1f:77:41:ed actions=output:1
 710
 711 How to configure QoS Attribute Mapping
 712 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 713
 714 This section explains how to provision QoS attribute mapping constraint
 715 using NIC OF-Renderer.
 716
 717 The QoS attribute mapping currently supports DiffServ. It uses a 6-bit
 718 differentiated services code point (DSCP) in the 8-bit differentiated
 719 services field (DS field) in the IP header.
 720
 721 +----------------+-----------------------------------------------------------+
 722 | Action         | Function                                                  |
 723 +================+===========================================================+
 724 | Allow          | Permits the packet to be forwarded normally, but allows   |
 725 |                | for packet header fields, e.g., DSCP, to be modified.     |
 726 +----------------+-----------------------------------------------------------+
 727
 728 The following steps explain QoS Attribute Mapping function:
 729
 730 -  Initially configure the QoS profile which contains profile name and
 731    DSCP value.
 732
 733 -  When a packet is transferred from a source to destination, the flow
 734    builder evaluates whether the transferred packet matches the
 735    condition such as action, endpoints in the flow.
 736
 737 -  If the packet matches the endpoints, the flow builder applies the
 738    flow matching action and DSCP value.
 739
 740 Requirement
 741 ^^^^^^^^^^^
 742
 743 -  Before execute the following steps, please, use the default
 744    requirements. See section `Default
 745    Requirements <#_default_requirements>`__.
 746
 747 Configuration
 748 ^^^^^^^^^^^^^
 749
 750 Please execute the following CLI commands to test network intent using
 751 mininet:
 752
 753 -  To apply the QoS constraint, configure the QoS profile.
 754
 755 ::
 756
 757     intent:qosConfig -p <qos_profile_name> -d <valid_dscp_value>
 758
 759 Example:
 760
 761 ::
 762
 763     intent:qosConfig -p High_Quality -d 46
 764
 765 .. note::
 766
 767     Valid DSCP value ranges from 0-63.
 768
 769 -  To provision the network for the two hosts (h1 and h3), add intents
 770    that allows traffic in both directions by execute the following CLI
 771    command.
 772
 773 Demonstrates the ALLOW action with constraint QoS and QoS profile name.
 774
 775 ::
 776
 777     intent:add -a ALLOW -t <DESTINATION_MAC> -f <SOURCE_MAC> -q QOS -p <qos_profile_name>
 778
 779 Example:
 780
 781 ::
 782
 783     intent:add -a ALLOW -t 00:00:00:00:00:03 -f 00:00:00:00:00:01 -q QOS -p High_Quality
 784     intent:add -a ALLOW -t 00:00:00:00:00:01 -f 00:00:00:00:00:03 -q QOS -p High_Quality
 785
 786 Verification
 787 ''''''''''''
 788
 789 -  As we have applied action type ALLOW now ping should happen between
 790    hosts h1 and h3.
 791
 792 ::
 793
 794      mininet> h1 ping h3
 795      PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
 796      64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=0.984 ms
 797      64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.110 ms
 798      64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.098 ms
 799
 800 -  Verification of the flow entry and ensuring the mod\_nw\_tos is part
 801    of actions.
 802
 803 ::
 804
 805      mininet> dpctl dump-flows
 806      *** s1 ------------------------------------------------------------------------
 807      NXST_FLOW reply (xid=0x4):
 808      cookie=0x0, duration=21.873s, table=0, n_packets=3, n_bytes=294, idle_age=21, priority=9000,dl_src=00:00:00:00:00:03,dl_dst=00:00:00:00:00:01 actions=NORMAL,mod_nw_tos:184
 809      cookie=0x0, duration=41.252s, table=0, n_packets=3, n_bytes=294, idle_age=41, priority=9000,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:03 actions=NORMAL,mod_nw_tos:184
 810
 811 Requirement
 812 ~~~~~~~~~~~
 813
 814 -  Before execute the follow steps, please, use default requirements.
 815    See section `Default Requirements <#_default_requirements>`__.
 816
 817 How to configure Log Action
 818 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 819
 820 This section demonstrates log action in OF Renderer. This demonstration
 821 aims at enabling communication between two hosts and logging the flow
 822 statistics details of the particular traffic.
 823
 824 Configuration
 825 ^^^^^^^^^^^^^
 826
 827 Please execute the following CLI commands to test network intent using
 828 mininet:
 829
 830 -  To provision the network for the two hosts (h1 and h3), add intents
 831    that allows traffic in both directions by execute the following CLI
 832    command.
 833
 834 ::
 835
 836     intent:add –a ALLOW -t <DESTINATION_MAC> -f <SOURCE_MAC>
 837
 838 Example:
 839
 840 ::
 841
 842     intent:add -a ALLOW -t 00:00:00:00:00:03 -f 00:00:00:00:00:01
 843     intent:add -a ALLOW -t 00:00:00:00:00:01 -f 00:00:00:00:00:03
 844
 845 -  To log the flow statistics details of the particular traffic.
 846
 847 ::
 848
 849     intent:add –a LOG -t <DESTINATION_MAC> -f <SOURCE_MAC>
 850
 851 Example:
 852
 853 ::
 854
 855     intent:add -a LOG -t 00:00:00:00:00:03 -f 00:00:00:00:00:01
 856
 857 Verification
 858 ''''''''''''
 859
 860 -  As we have applied action type ALLOW now ping should happen between
 861    hosts h1 and h3.
 862
 863 ::
 864
 865      mininet> h1 ping h3
 866      PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
 867      64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=0.984 ms
 868      64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.110 ms
 869      64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.098 ms
 870
 871 -  To view the flow statistics log details such as, byte count, packet
 872    count and duration, check the karaf.log.
 873
 874 ::
 875
 876     2015-12-15 22:56:20,256 | INFO | lt-dispatcher-23 | IntentFlowManager | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Creating block intent for endpoints: source00:00:00:00:00:01 destination 00:00:00:00:00:03
 877     2015-12-15 22:56:20,252 | INFO | lt-dispatcher-29 | FlowStatisticsListener | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Flow Statistics gathering for Byte Count:Counter64 [_value=238]
 878     2015-12-15 22:56:20,252 | INFO | lt-dispatcher-29 | FlowStatisticsListener | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Flow Statistics gathering for Packet Count:Counter64 [_value=3]
 879     2015-12-15 22:56:20,252 | INFO | lt-dispatcher-29 | FlowStatisticsListener | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Flow Statistics gathering for Duration in Nano second:Counter32 [_value=678000000]
 880     2015-12-15 22:56:20,252 | INFO | lt-dispatcher-29 | FlowStatisticsListener | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Flow Statistics gathering for Duration in Second:Counter32 [_value=49]
 881