dp_desc represents the human readable description of a given datapath
and is provided by an OpenFlow switch when it connects to the controller
in the response to the OFPMP_DESC request. ONOS already has access to
this information when the OpenFlowSwitch object is constructed (accessed
via sw.datapathDescription()) but it does not save it or propagate it in
any way. dp_desc, unlike the dp_id which is "random", works like a switch
label. Accessing this information from the controller app layer is
important so that different business logic can be applied according to
the provided "marking". Thus, save the value into the Device Annotations
if available.
Change-Id: Ifaa715a0440e99ce31fdd8d4753c2e892385e33b
Process OF messages through 8 queues. Output queue for messages
controlled per OF Agent with help of message classifiers.
Queues can be configured through component configuration mechanism
for "org.onosproject.openflow.controller.impl.OpenFlowControllerImpl"
component.
Classifiers can be configured through NetworkConfig API in the following
form:
{
"devices": {
"of:0000000000000001": {
"classifiers": [{
"ethernet-type":"LLDP",
"target-queue":0
},{
"ethernet-type":"BDDP",
"target-queue":0
},{
"ethernet-type":"0x1234",
"target-queue":1
}]
}
}
}
Where "target_queue" is queue number from 0 to 7 (7 is default queue),
"ethernet_type" is a type of a packet either in "0xFFFF" from or enum
name as defined in the "org.onlab.packet.EthType.EtherType" enum.
Change-Id: I0512ef653d90c36f00289014872170c1a8aa5204
- extended interface with default method implementation
- modified DeviceManager to exploit the new provider feature
- refactored a number of device providers to use the new method
instead of relying on indirect DEVICE_REMOVED events
Change-Id: Ib315357ef06463012fcf26bbe937c8cdccbf3a94
reconnect in support of ONOS-7645 (device driver change)
- added device listener to OpenFlowDeviceProvider to properly disconnect switch
- removed device listener from OpenFlowControllerImpl
- augmented DriverManager to consult NetworkConfigService as a primary source
Change-Id: I1aa8e9cc7e81ff3af7a72145f4e51f3e32022806
Nothing stops an OF agent to return zero for lambda values and ONOS
probably ought to not crash then.
One use case for this is when only one direction is supported on a port,
for example tx. Unfortunately, the openflow specification does not
separate the directions into different properties, so the agent
implementation has to return some frequency value for rx in this case
even if only the tx direction is supported. However, anything non-zero
would probably be untruthful as it would indicate valid reading to the
end user.
Even zero will be problematic for unsupported power reading in a
direction as 0 dBm is a valid value, but not sure how to deal with any
better.
Change-Id: I2597bd7d577d9c2e1a3b44421fe505b8b3b6cc92
- OFPortDesc cache managed by AbstractOpenFlowSwitch was not always maintained properly.
reorganized data structure to maintain per OFPortDesc, last known instance
Change-Id: I1b26d7ca284e44bf9744c30374394c581653d78f
