OpenFlow allows a controller to request port statistics from the a switch using a message, and the controller in return receives a reply with the statistics.
For example, in Ryu we can use ryu.ofproto.ofproto_v1_3_parser.OFPPortStatsRequest for this purpose.
Is there a way to get the port statistics from a switch without issuing a request message from the controller, but possibly as an action by the switch on receipt of a particular type of packet?
Related
I just finished reading sections 1-6.2 of the OpenFlow specification here.
Section 6.1.2 says:
Packet-in events can be configured to buffer packets. For packet-in generated by an output action in
a flow entries or group bucket, it can be specified individually in the output action itself (see 7.2.6.1),
for other packet-in it can be configured in the switch configuration (see 7.3.2). If the packet-in event is
configured to buffer packets and the switch has sufficient memory to buffer them, the packet-in event
contains only some fraction of the packet header and a buffer ID to be used by a controller when it
is ready for the switch to forward the packet. Switches that do not support internal buffering, are
configured to not buffer packets for the packet-in event, or have run out of internal buffering, must
send the full packet to controllers as part of the event. Buffered packets will usually be processed via a
Packet-out or Flow-mod message from a controller, or automatically expired after some time
This makes it sound like for every packet that hits the OpenFlow switch, an asynchronous message must be sent to the controller to make a forwarding decision. However Chapter 5 makes it sound like a switch has a set of OpenFlow flows and at the end of that generates an action set which determines what should be done with a packet and the packet is only forwarded to the controller when there is a flow table miss.
Under what conditions is a packet sent to the controller for a decision? Is it always? Or is it only circumstantial?
Packets will be sent to the OpenFlow controller any time the out port is set to be the controller.
PACKET_IN events occur when a flow wasn't matched on the switch and are then sent to the controller. Otherwise no event is created - the switch simply forwards the packet according to the flow rules and the controller is none the wiser.
According to described here
http://flowgrammable.org/sdn/openflow/message-layer/flowmod/
and in the OpenFlow switch specifications, the flow_mod message is not acknowledgeable.
Is there any way for the controller (POX, ODL, or any other) to receive a confirmation for installed flow match or to retrieve the installed flows in the switch's flow table?
Thank you
There is a concept in openflow called "barrier" where the controller
can send a barrier request to have the switch acknowledge the flow_mod.
In OpenDaylight, the default openflowplugin stats collection will poll
the connected switches and will store the config (including the flow table)
in OpenDaylight's operational store.
On reading about usb protocol in
http://www.beyondlogic.org/usbnutshell/usb4.shtml
It is said that interrupt endpoint is unidirectional and periodic.
Yet, I see in the description for IN interrupt endpoint, that host initiate the IN token and then data packet is send from device to host.
"If an interrupt has been queued by the device, the function will send
a data packet containing data relevant to the interrupt when it
receives the IN Token."
So, If the data packet is sent on this IN endpoint from device to host, doesn't it mean that the same endpoint is used both the transmit and receive ?
I believe the terminology "unidirectional" is meant for only data and not for token and handshake packets. So "IN" endpoint is for reading data and "OUT" endpoint is for writing data. That's why its called unidirectional.
But control endpoint is bidirectional because you can read or write data using the control endpoint. Check the standard USB commands like "Get Descriptor" and "Set Descriptor".
Suppose I have a topology like < host1--switch1--switch2--switch3--controller>. So, the physical path between switch1 and the controller consist of switch2 and switch3. Does the control traffic from switch1 to the controller goes from switch2 and switch3? I mean the openflow traffics between switch1 and the controller go to switch2 at first and then go to switch3 until it reach to the controller. Am I right?
Openflow switches have seperate management ports to connect to the controller. If you use outofband connection (direct connection to controller via management port) switch communicates with controller directly. In a such case, for data flows, you can still use the topology you mentioned.
But, if there is no management connection between switch 1 and controller, then it comes to "inband" connection. In a such case, switch 1 sends openflow messages via data port, switch 2 encapsulates this message and send to the controller.
From OpenFlow documentation:
The speci cation of the networks used for the OpenFlow channels is
outside the scope of the present speci cation. It may be a separate
dedicated network, or the OpenFlow channel may use the network managed
by the OpenFlow switch (in-band controller connection). The only
requirement is that it should provide TCP/IP connectivity.
Dedicated network means outofband connection.
To learn some details about inband you can look this documentation:
Important part is:
In this setup, control traffic sent by switch A will be seen by
switch B, which will send it to the controller as part of an
OFPT_PACKET_IN message. Switch A will then see the OFPT_PACKET_IN
message's packet, re-encapsulate it in another OFPT_PACKET_IN, and
send it to the controller. Switch B will then see that
OFPT_PACKET_IN, and so on in an infinite loop.
When two peers are using WebRTC transmission with TURN as a relay server we've noticed that from time to time the data inside Send Indication or Channel Data is actually a valid STUN Binding Request message (type 0x0001). The other peer responds in the same way with a valid Binding Request Response (type 0x0101). It happens repeatedly during the whole conversation. Both peers are forced to use TURN server. What is the purpose of encapsulating typical STUN message inside data attribute of TURN transmission frame? Is it described in any document?
Here is an example of Channel Data frame:
[0x40,0x00,0x00,0x70,0x00,0x01,0x00,0x5c,0x21,0x12,0xa4,0x42,0x71,0x75,0x6d,0x6a,0x6f,0x66,0x69,0x6f...]
0x40,0x00 - channel number
0x00,0x70 - length of data
0x00,0x01,0x00,0x5c,0x21,0x12... - data, that can be parsed to a Binding Request
This is ICE (described in RFC 5245) connectivity checks running via TURN as well as consent checks described in RFC 7675.