1 Network Intent Composition (NIC) User Guide
2 ===========================================
7 Network Intent Composition (NIC) is an interface that allows clients to
8 express a desired state in an implementation-neutral form that will be
9 enforced via modification of available resources under the control of
10 the OpenDaylight system.
12 This description is purposely abstract as an intent interface might
13 encompass network services, virtual devices, storage, etc.
15 The intent interface is meant to be a controller-agnostic interface so
16 that "intents" are portable across implementations, such as OpenDaylight
17 and ONOS. Thus an intent specification should not contain implementation
18 or technology specifics.
20 The intent specification will be implemented by decomposing the intent
21 and augmenting it with implementation specifics that are driven by local
22 implementation rules, policies, and/or settings.
24 Network Intent Composition (NIC) Architecture
25 ---------------------------------------------
27 The core of the NIC architecture is the intent model, which specifies
28 the details of the desired state. It is the responsibility of the NIC
29 implementation transforms this desired state to the resources under the
30 control of OpenDaylight. The component that transforms the intent to the
31 implementation is typically referred to as a renderer.
33 For the Boron release, multiple, simultaneous renderers will not be
34 supported. Instead either the VTN or GBP renderer feature can be
35 installed, but not both.
37 For the Boron release, the only actions supported are "ALLOW" and
38 "BLOCK". The "ALLOW" action indicates that traffic can flow between the
39 source and destination end points, while "BLOCK" prevents that flow;
40 although it is possible that an given implementation may augment the
41 available actions with additional actions.
43 Besides transforming a desired state to an actual state it is the
44 responsibility of a renderer to update the operational state tree for
45 the NIC data model in OpenDaylight to reflect the intent which the
48 Configuring Network Intent Composition (NIC)
49 --------------------------------------------
51 For the Boron release there is no default implementation of a renderer,
52 thus without an additional module installed the NIC will not function.
54 Administering or Managing Network Intent Composition (NIC)
55 ----------------------------------------------------------
57 There is no additional administration of management capabilities related
58 to the Network Intent Composition features.
63 A user can interact with the Network Intent Composition (NIC) either
64 through the RESTful interface using standard RESTCONF operations and
65 syntax or via the Karaf console CLI.
73 The Network Intent Composition (NIC) feature supports the following REST
74 operations against the configuration data store.
76 - POST - creates a new instance of an intent in the configuration
77 store, which will trigger the realization of that intent. An ID
78 *must* be specified as part of this request as an attribute of the
81 - GET - fetches a list of all configured intents or a specific
84 - DELETE - removes a configured intent from the configuration store,
85 which triggers the removal of the intent from the network.
90 The Network Intent Composition (NIC) feature supports the following REST
91 operations against the operational data store.
93 - GET - fetches a list of all operational intents or a specific
99 This feature provides karaf console CLI command to manipulate the intent
100 data model. The CLI essentailly invokes the equivalent data operations.
105 Creates a new intent in the configuration data tree
112 Adds an intent to the controller.
114 Examples: --actions [ALLOW] --from <subject> --to <subject>
115 --actions [BLOCK] --from <subject>
122 Action to be performed.
123 -a / --actions BLOCK/ALLOW
124 (defaults to [BLOCK])
126 Display this help message
133 -f / --from <subject>
139 Removes an existing intent from the system
146 Removes an intent from the controller.
157 Lists all the intents in the system
164 Lists all intents in the controller.
167 intent:list [options]
171 List Configuration Data (optional).
172 -c / --config <ENTER>
174 Display this help message
179 Displayes the details of a single intent
186 Shows detailed information about an intent.
197 List/Add/Delete current state from/to the mapping service.
204 List/Add/Delete current state from/to the mapping service.
209 Examples: --list, -l [ENTER], to retrieve all keys.
210 --add-key <key> [ENTER], to add a new key with empty contents.
211 --del-key <key> [ENTER], to remove a key with it's values."
212 --add-key <key> --value [<value 1>, <value 2>, ...] [ENTER],
213 to add a new key with some values (json format).
216 Display this help message
218 List values associated with a particular key.
219 -l / --filter <regular expression> [ENTER]
221 Adds a new key to the mapping service.
222 --add-key <key name> [ENTER]
224 Specifies which value should be added/delete from the mapping service.
225 --value "key=>value"... --value "key=>value" [ENTER]
228 Deletes a key from the mapping service.
229 --del-key <key name> [ENTER]
237 Start mininet, and create three switches (s1, s2, and s3) and four hosts
238 (h1, h2, h3, and h4) in it.
240 Replace <Controller IP> based on your environment.
244 $ sudo mn --mac --topo single,2 --controller=remote,ip=<Controller IP>
253 s1 lo: s1-eth1:s2-eth3 s1-eth2:s3-eth3
254 s2 lo: s2-eth1:h1-eth0 s2-eth2:h2-eth0 s2-eth3:s1-eth1
255 s3 lo: s3-eth1:h3-eth0 s3-eth2:h4-eth0 s3-eth3:s1-eth2
257 Downloading and deploy Karaf distribution
258 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
260 - Get the Boron distribution.
262 - Unzip the downloaded zip distribution.
270 - Once the console is up, type as below to install feature.
274 feature:install odl-nic-core-mdsal odl-nic-console odl-nic-listeners
276 Simple Mininet topology
277 -----------------------
283 from mininet.topo import Topo
285 class SimpleTopology( Topo ):
286 "Simple topology example."
288 def __init__( self ):
289 "Create custom topo."
292 Topo.__init__( self )
295 Switch1 = self.addSwitch( 's1' )
296 Switch2 = self.addSwitch( 's2' )
297 Switch3 = self.addSwitch( 's3' )
298 Switch4 = self.addSwitch( 's4' )
299 Host11 = self.addHost( 'h1' )
300 Host12 = self.addHost( 'h2' )
301 Host21 = self.addHost( 'h3' )
302 Host22 = self.addHost( 'h4' )
303 Host23 = self.addHost( 'h5' )
304 Service1 = self.addHost( 'srvc1' )
307 self.addLink( Host11, Switch1 )
308 self.addLink( Host12, Switch1 )
309 self.addLink( Host21, Switch2 )
310 self.addLink( Host22, Switch2 )
311 self.addLink( Host23, Switch2 )
312 self.addLink( Switch1, Switch2 )
313 self.addLink( Switch2, Switch4 )
314 self.addLink( Switch4, Switch3 )
315 self.addLink( Switch3, Switch1 )
316 self.addLink( Switch3, Service1 )
317 self.addLink( Switch4, Service1 )
320 topos = { 'simpletopology': ( lambda: SimpleTopology() ) }
322 - Initialize topology
324 - Add hosts and switches
326 - Host used to represent the service
330 Source: https://gist.github.com/vinothgithub15/315d0a427d5afc39f2d7
332 How to configure VTN Renderer
333 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
335 The section demonstrates allow or block packets of the traffic within a
336 VTN Renderer, according to the specified flow conditions.
338 The table below lists the actions to be applied when a packet matches
341 +----------------+-----------------------------------------------------------+
342 | Action | Function |
343 +================+===========================================================+
344 | Allow | Permits the packet to be forwarded normally. |
345 +----------------+-----------------------------------------------------------+
346 | Block | Discards the packet preventing it from being forwarded. |
347 +----------------+-----------------------------------------------------------+
352 - Before execute the follow steps, please, use default requirements.
353 See section `Default Requirements <#_default_requirements>`__.
358 Please execute the following curl commands to test network intent using
364 To provision the network for the two hosts(h1 and h2) and demonstrates
369 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"}} ] } }'
371 To provision the network for the two hosts(h2 and h3) and demonstrates
376 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"}} ] } }'
381 As we have applied action type allow now ping should happen between
382 hosts (h1 and h2) and (h2 and h3).
387 Ping: testing ping reachability
396 To provision block action that indicates traffic is not allowed between
401 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"}} ] } }'
406 As we have applied action type block now ping should not happen between
412 Ping: testing ping reachability
420 Old actions and hosts are replaced by the new action and hosts.
425 Respective intent and the traffics will be deleted.
429 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
434 Deletion of intent and flow.
439 Ping: testing ping reachability
447 Ping between two hosts can also be done using MAC Address
449 To provision the network for the two hosts(h1 MAC address and h2 MAC
454 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"}} ] } }'
456 How to configure Redirect Action
457 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
459 The section explains the redirect action supported in NIC. The redirect
460 functionality supports forwarding (to redirect) the traffic to a service
461 configured in SFC before forwarding it to the destination.
463 .. figure:: ./images/nic/Service_Chaining.png
464 :alt: REDIRECT SERVICE
468 Following steps explain Redirect action function:
470 - Configure the service in SFC using the SFC APIs.
472 - Configure the intent with redirect action and the service information
473 where the traffic needs to be redirected.
475 - The flows are computed as below
477 1. First flow entry between the source host connected node and the
478 ingress node of the configured service.
480 2. Second flow entry between the egress Node id the configured
481 service and the ID and destination host connected host.
483 3. Third flow entry between the destination host node and the source
489 - Save the mininet `Simple Mininet
490 topology <#_simple_mininet_topology>`__ script as redirect\_test.py
492 - Start mininet, and create switches in it.
494 Replace <Controller IP> based on your environment.
498 sudo mn --controller=remote,ip=<Controller IP>--custom redirect_test.py --topo mytopo2
508 srvc1 srvc1-eth0:s3-eth3 srvc1-eth1:s4-eth3
509 s1 lo: s1-eth1:h1-eth0 s1-eth2:h2-eth0 s1-eth3:s2-eth4 s1-eth4:s3-eth2
510 s2 lo: s2-eth1:h3-eth0 s2-eth2:h4-eth0 s2-eth3:h5-eth0 s2-eth4:s1-eth3 s2-eth5:s4-eth1
511 s3 lo: s3-eth1:s4-eth2 s3-eth2:s1-eth4 s3-eth3:srvc1-eth0
512 s4 lo: s4-eth1:s2-eth5 s4-eth2:s3-eth1 s4-eth3:srvc1-eth1
518 - Before execute the following steps, please, use the default
519 requirements. See section `Downloading and deploy Karaf
520 distribution <#_default_requirements>`__.
528 .. figure:: ./images/nic/Redirect_flow.png
529 :alt: CONFIGURATION THE NETWORK IN MININET
531 CONFIGURATION THE NETWORK IN MININET
533 - Configure srvc1 as service node in the mininet environment.
535 Please execute the following commands in the mininet console (where
536 mininet script is executed).
540 srvc1 ip addr del 10.0.0.6/8 dev srvc1-eth0
541 srvc1 brctl addbr br0
542 srvc1 brctl addif br0 srvc1-eth0
543 srvc1 brctl addif br0 srvc1-eth1
544 srvc1 ifconfig br0 up
545 srvc1 tc qdisc add dev srvc1-eth1 root netem delay 200ms
547 Configure service in SFC
548 ''''''''''''''''''''''''
550 The service (srvc1) is configured using SFC REST API. As part of the
551 configuration the ingress and egress node connected the service is
556 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '{
557 "service-functions": {
558 "service-function": [
561 "sf-data-plane-locator": [
564 "service-function-forwarder": "openflow:4"
568 "service-function-forwarder": "openflow:3"
576 }' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function:service-functions/
578 **SFF RESTCONF Request**
580 Configuring switch and port information for the service functions.
584 curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '{
585 "service-function-forwarders": {
586 "service-function-forwarder": [
588 "name": "openflow:3",
589 "service-node": "OVSDB2",
590 "sff-data-plane-locator": [
593 "data-plane-locator":
596 "mac": "11:11:11:11:11:11",
597 "transport": "service-locator:mac"
599 "service-function-forwarder-ofs:ofs-port":
605 "service-function-dictionary": [
608 "sff-sf-data-plane-locator":
610 "sf-dpl-name" : "openflow:3",
611 "sff-dpl-name" : "Ingress"
617 "name": "openflow:4",
618 "service-node": "OVSDB3",
619 "sff-data-plane-locator": [
622 "data-plane-locator":
625 "mac": "44:44:44:44:44:44",
626 "transport": "service-locator:mac"
628 "service-function-forwarder-ofs:ofs-port":
634 "service-function-dictionary": [
637 "sff-sf-data-plane-locator":
639 "sf-dpl-name" : "openflow:4",
640 "sff-dpl-name" : "Egress"
647 }' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/
652 To provision the network for the two hosts (h1 and h5).
654 Demonstrates the redirect action with service name srvc1.
658 intent:add -f <SOURCE_MAC> -t <DESTINATION_MAC> -a REDIRECT -s <SERVICE_NAME>
664 intent:add -f 32:bc:ec:65:a7:d1 -t c2:80:1f:77:41:ed -a REDIRECT -s srvc1
669 - As we have applied action type redirect now ping should happen
670 between hosts h1 and h5.
675 PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
676 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=201 ms
677 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=200 ms
678 64 bytes from 10.0.0.5: icmp_seq=4 ttl=64 time=200 ms
680 The redirect functionality can be verified by the time taken by the ping
681 operation (200ms). The service srvc1 configured using SFC introduces
682 200ms delay. As the traffic from h1 to h5 is redirected via the srvc1,
683 the time taken by the traffic from h1 to h5 will take about 200ms.
685 - Flow entries added to nodes for the redirect action.
689 mininet> dpctl dump-flows
690 *** s1 ------------------------------------------------------------------------
691 NXST_FLOW reply (xid=0x4):
692 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
693 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
694 cookie=0x1, duration=362.315s, table=0, n_packets=144, n_bytes=12240, idle_age=4, priority=9500,dl_type=0x88cc actions=CONTROLLER:65535
695 cookie=0x1, duration=362.324s, table=0, n_packets=4, n_bytes=168, idle_age=3, priority=10000,arp actions=CONTROLLER:65535,NORMAL
696 *** s2 ------------------------------------------------------------------------
697 NXST_FLOW reply (xid=0x4):
698 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
699 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
700 cookie=0x3, duration=362.317s, table=0, n_packets=144, n_bytes=12240, idle_age=4, priority=9500,dl_type=0x88cc actions=CONTROLLER:65535
701 cookie=0x3, duration=362.32s, table=0, n_packets=4, n_bytes=168, idle_age=3, priority=10000,arp actions=CONTROLLER:65535,NORMAL
702 *** s3 ------------------------------------------------------------------------
703 NXST_FLOW reply (xid=0x4):
704 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
705 *** s4 ------------------------------------------------------------------------
706 NXST_FLOW reply (xid=0x4):
707 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
709 How to configure QoS Attribute Mapping
710 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
712 This section explains how to provision QoS attribute mapping constraint
713 using NIC OF-Renderer.
715 The QoS attribute mapping currently supports DiffServ. It uses a 6-bit
716 differentiated services code point (DSCP) in the 8-bit differentiated
717 services field (DS field) in the IP header.
719 +----------------+-----------------------------------------------------------+
720 | Action | Function |
721 +================+===========================================================+
722 | Allow | Permits the packet to be forwarded normally, but allows |
723 | | for packet header fields, e.g., DSCP, to be modified. |
724 +----------------+-----------------------------------------------------------+
726 The following steps explain QoS Attribute Mapping function:
728 - Initially configure the QoS profile which contains profile name and
731 - When a packet is transferred from a source to destination, the flow
732 builder evaluates whether the transferred packet matches the
733 condition such as action, endpoints in the flow.
735 - If the packet matches the endpoints, the flow builder applies the
736 flow matching action and DSCP value.
741 - Before execute the following steps, please, use the default
742 requirements. See section `Default
743 Requirements <#_default_requirements>`__.
748 Please execute the following CLI commands to test network intent using
751 - To apply the QoS constraint, configure the QoS profile.
755 intent:qosConfig -p <qos_profile_name> -d <valid_dscp_value>
761 intent:qosConfig -p High_Quality -d 46
765 Valid DSCP value ranges from 0-63.
767 - To provision the network for the two hosts (h1 and h3), add intents
768 that allows traffic in both directions by execute the following CLI
771 Demonstrates the ALLOW action with constraint QoS and QoS profile name.
775 intent:add -a ALLOW -t <DESTINATION_MAC> -f <SOURCE_MAC> -q QOS -p <qos_profile_name>
781 intent:add -a ALLOW -t 00:00:00:00:00:03 -f 00:00:00:00:00:01 -q QOS -p High_Quality
782 intent:add -a ALLOW -t 00:00:00:00:00:01 -f 00:00:00:00:00:03 -q QOS -p High_Quality
787 - As we have applied action type ALLOW now ping should happen between
793 PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
794 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=0.984 ms
795 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.110 ms
796 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.098 ms
798 - Verification of the flow entry and ensuring the mod\_nw\_tos is part
803 mininet> dpctl dump-flows
804 *** s1 ------------------------------------------------------------------------
805 NXST_FLOW reply (xid=0x4):
806 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
807 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
812 - Before execute the follow steps, please, use default requirements.
813 See section `Default Requirements <#_default_requirements>`__.
815 How to configure Log Action
816 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
818 This section demonstrates log action in OF Renderer. This demonstration
819 aims at enabling communication between two hosts and logging the flow
820 statistics details of the particular traffic.
825 Please execute the following CLI commands to test network intent using
828 - To provision the network for the two hosts (h1 and h3), add intents
829 that allows traffic in both directions by execute the following CLI
834 intent:add –a ALLOW -t <DESTINATION_MAC> -f <SOURCE_MAC>
840 intent:add -a ALLOW -t 00:00:00:00:00:03 -f 00:00:00:00:00:01
841 intent:add -a ALLOW -t 00:00:00:00:00:01 -f 00:00:00:00:00:03
843 - To log the flow statistics details of the particular traffic.
847 intent:add –a LOG -t <DESTINATION_MAC> -f <SOURCE_MAC>
853 intent:add -a LOG -t 00:00:00:00:00:03 -f 00:00:00:00:00:01
858 - As we have applied action type ALLOW now ping should happen between
864 PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
865 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=0.984 ms
866 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.110 ms
867 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.098 ms
869 - To view the flow statistics log details such as, byte count, packet
870 count and duration, check the karaf.log.
874 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
875 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]
876 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]
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 Duration in Nano second:Counter32 [_value=678000000]
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 Duration in Second:Counter32 [_value=49]