Page History

...

Support for LAG is not present in the ONOS at the moment, it is to be implemented.

Traffic Engineering

Controller should have a mechanism by which it is able to choose and setup best available intents for a specific traffic type. To achieve this controller should be able to determine:

• Quality of Link in terms of latency and bandwidth – With the known latency and bandwidth properties controller should be able to determine which intents (more than one) to deploy for a specific traffic types(traffic types like live audio, video, logging are identified by vlan in most cases) with their priorities (in case of failure priority helps to choose for next intent) i.e. For a real time audio stream, latency of path is crucial than its bandwidth (for sure there should be minimum bandwidth available to carry voice stream), for a normal video file play latency may not be crucial and it can take longer path, for a HD video file transfer high bandwidth can be important.
• Stream Switching latency – Time required to switch a stream from different sources.

Solution

To calculate latency :

1. Controller need to discover possible links(more than one intents) between two hosts comprise of flows which have a unique matching criteria so that it is impossible to match this criterion with real network traffic.
2. Then send a packet (e.g. UDP packet, which matches the unique matching criteria) from controller to the port connecting source host and redirect to controller as soon as it reaches the destination port i.e. the port where destination host is connected. Time difference between sending and receiving the packet can be considered as latency. This latency also contains the time between controller and switches to be more accurate, a P4 program or experimenters implementation in OF can be used to notify controller about the time when this special packet entered source port and got out from destination port.  

Real time bandwidth usage is available in ONOS which can be used in combination with port capacity can be used to know the actual available BW.

Stream Switching Latency is to be less than 5ms. as described in stream switching section, still this is important to log and monitor the latency on each stream switch. A P4 program which reads the time difference of the last packet before stream switch and the first packet from new frame can notify controller about stream switch latency. Actually, the P4 code or experimenter used in Seamless switching can further be modified to have this latency notification function.

Switching of RTP streams

This is another important requirement to have in Broad-cast controller. Switching of RTP streams can occur in various scenarios like:

...

Actually, it is to be switched within 0.000001991 sec. to ensure 0 packet loss, otherwise buffering of incoming packets will be required until the flow is deployed. And at high scale buffering is not efficient as switching devices have really small buffers another is, a delay is always added to a stream on each switch.

Solution

[1] RTP packet must be processed and marker bit should be identified and only then the new flow should be active independent of when they were created how much time did it take to be deployed in data plane.

...

The actual processing of the RTP packets is to be done in HW, Controller should be able to deploy this packet processing logic on switch i.e. this packet processing can be done using P4 and experimenters in switch, in either case ONOS can deploy the logic on switch using P4Runtime or Extension framework.

Latency and bandwidth monitoring

Following Latency and Bandwidth information is to be available for user for monitoring purpose:

• Quality of Link in terms of latency and bandwidth – Controller should be able to suggest available links (more than one intent) with their quality i.e. latency and bandwidth. Latency is time delta between receiving a packet on a host and sent out from another. Similarly, total bandwidth available for these intents based on current traffic and port capacity.
• Stream Switching latency – Time required to switch a stream from different sources.

Solution

Link latency can be accounted by calculating time between sending a packet from a host and receiving it at another host over that link, to achieve this, controller need to identify possible links(more than one intents) between two hosts comprise of flows which have a unique matching criteria so that it is impossible to match this criterion with real network traffic. Then send a packet (e.g. UDP packet, which matches the unique matching criteria) from controller to the port connecting source host and redirect to controller as soon as it reaches the destination port i.e. the port where destination host is connected. A P4 program or experimenters implementation can be used to notify controller about the time when this special packet entered source port and got out from destination port for latency calculation.  

Real time bandwidth usage is available in ONOS which can be used in combination with port capacity can be used to know the actual available BW.

...

.

QOS & Metering Support

Apply QOS and Metering on Ports.

...