Traffic Engineering (TE) generally means analyzing network traffic and optimizing traffic flow and resource allocation in order to enhance the performance of an operational network. TE has been widely exploited in data networks, from past ATM (Asynchronous Transfer Mode) networks to current IP/MPLS networks. However, current networking paradigms and the TE solutions implemented for them are unfavorable for the future generations of networks due to two main reasons:

• First, they don’t meet the requirements of today’s Internet applications in term of real time reaction, and support of large amount of traffic. The underlying network should be able to classify a variety of traffic types and to provide a suitable service for each traffic type in real time (i.e., order of ms).
• Second, the massive growth of large scale data centers, with significant bandwidth requirements -as the needs for cloud computing, multimedia contents, and big data analysis are increasing- urgently requires new, intelligent and more efficient traffic engineering mechanisms to assure optimal resource utilization and performance.

Due to their unique features, SDNs provide huge incentive for new TE techniques that exploit the global network view, monitoring capabilities, and programmability available for better traffic control and management. More specifically, SDN provides:

• Centralized view that enables deploying scalable measurement and monitoring mechanisms. The SDN controller collects and stores the entire network information, including the network topology, the network status, and global application requirements such as QoS and security requirements.
• Global programmability.The network operator leverages the SDN controller to dynamically program the forwarding layer devices to optimize the allocation of network resources.
• OpennessThe interface between the controller and forwarding equipment is unified across vendors (OpenFlow).

There are four axes of traffic engineering in SDN: flow management, fault tolerance, topology update, and traffic analysis.

First, according to the basic operation of flow management in SDNs, when a flow arriving at the switch does not match any rules in the flow table, it will be processed as follows:

• The first packet of the flow is sent by the ingress switch to the controller.
• The controller computes the forwarding path for the flow.
• The controller sends the corresponding forwarding rules to install in the flow tables at each switch along the computed path.
• Finally, all subsequent packets in the flow are forwarded in the data plane along the installed path.

To balance the load across multiple paths, the SDN controller can leverage OpenFlow to program multiple switches to carry the same flow. However, in this operation, if the aggregated traffic consists of high number of new flows, the resulting latency overhead from installing large numbers of forwarding rules can be yielded at both the control plane and data plane. Hence, the traffic engineering mechanisms must address the tradeoffs between latency and load-balance.

Second, whenever a failure occurs (switch, link or controller failure), the SDN should be able to recover rapidly, transparently and gracefully to ensure the network reliability. A single failure must be recovered within 50 ms in carrier grade networks [1]. In OF v1.1+, a fast failover mechanism is introduced in which an alternative port and path can be specified, enabling the switch to switch to an alternate forwarding path without requiring a round trip to the controller. However, the failure recovery still needs to consider the limited memory and flow table resources at switches.

Third, the key challenge in topology update is how the SDN controller can efficiently update the network with required consistency in (near) real time. The topology discovery and update process is more complex in large SDN network, where switches are controlled by clusters of controllers and mostly through in-band control traffic. My co-authors and I have designed a real time topology discovery mechanism that requires minimal exchange of control packets, and hence, minimal overhead.

Finally,the traffic analysis mechanisms should include:

• traffic/network monitoring tools which are the most important prerequisite for all other traffic analysis tasks.
• network invariant checking mechanisms
• programming error debugging software
• flow/state data collection
• analytics/ mining of patterns/characteristics
• etc ..

Final note

Many SDN architectures use the existing flow based monitoring tools from traditional IP networks, which can lead to high monitoring overhead for the switch. With the release of OpenFlow v1.3, more advanced flow metering mechanisms were introduced, hence the need to design more advance monitoring tools to take advantage of it, while keeping a low complexity design, low measurement overhead and a high measurement accuracy.

References

[1]: B. Niven-Jenkins, D. Brungard, M. Betts, N. Sprecher, S. Ueno, Requirements of an MPLS Transport Profile, RFC 5654, Tech. Rep., September 2009.

[2]: Azzouni, Abdelhadi, et al. “sOFTDP: Secure and efficient OpenFlow topology discovery protocol.” NOMS 2018–2018 IEEE/IFIP Network Operations and Management Symposium. IEEE, 2018.