In A study on Software Defined Network from Allied Telesis says that ethernet networks have been developed on a self-organizing model. Sets of independent forwarding devices cooperate to create reliable end-to-end forwarding paths. This model has been very successful for many years. It is a very good example of a reliable self-organising system.
A set of switches are configured with rules that map out a network structurewhich ports belong to which VLANs; which subnets are attached to which VLANs; a loop-protection mechanism to block redundant links; a routing protocol to distribute subnet information; possibly even dynamic VLAN allocation rules at
the edge. The switches are connected together; each applies its rules independently, and shares appropriate information with its neighbors and a system that can reliably transport data between thousands of individual end-points comes to life.
Such networks are resilient to failures of links and switching nodesthe loop protection and routing protocols reconverge onto a new forwarding topology, and data continues to flow. Congestion bottlenecks can be dealt with reasonably effectively Quality of Service (QoS) rules prioritize real-time and critical
data; selective packet dropping can slow TCP sessions down to a rate appropriate to the current traffic conditions; pause control requests end-points to back off for a while.
However, in the highly dynamic, throughput driven, latency critical environment of the large data center, the self-organizing model of Ethernet networking is proving to be a limiting factor.
In data centers:
?? Large blocks of virtual end-points can quickly change their physical location
?? Users are expecting extremely quick responses to their online queries and transactions
?? Strong competition is driving the need to squeeze every ounce of performance out of the massive investments that have been made in switching infrastructure
Instead, these networks are adopting the Software Defined Networking model, in which a central controller, with an overview of the whole network, determines the forwarding paths, and tells switches what entries to put in their forwarding tables. A model in which the individual switches within the network cooperatively create forwarding paths on a best-effort basis is no longer sufficient for this environment. For example, when a large number of virtual servers are being migrated to new locations in the data center, the central controller can be informed of this. They can then update the switch forwarding tables with MAC, ARP, and route entries that reflect the new locations of these servers. Thereby, the network reacts to the server move more quickly than it would by the traditional method of the switches relearning MAC entries from packets, using ARP requests to update ARP tables, and routing protocol signaling to update route tables.
Similarly, the central controller can monitor the utilization of all the links in the network. When new data flows are initiated, the controller is informed, and can choose a path for those flows that will avoid highly utilized links. Rather than leaving the switches to forward the data on the shortest path, the central controller can manipulate switch forwarding tables. It can route flows along less-direct paths that make use of lower-utilized links.
Add new comment