networking ICT
PEOPLE SPEAK OF “disruptive technologies” as if they were an explosive force, but the disruption can also happen slowly over time. The enterprise network might seem more cohesive than disruptive – but look at what has happened over the years.
It began as a network of cables linking departments and workers to increase business efficiency. Instead of circulating hard copy, necessary data came straight to your desk, saving time and increasing productivity. But that ready availability meant that there was less need for the worker to be tied to one desk or office, leading to a more fluid “mobile worker” environment that was accelerated by the addition of wireless.
Meanwhile people’s expectations were being raised, and consumer products were developed to meet the demand for “information anywhere”. The traditional fixed structure of the enterprise is now not only becoming fluid with mobile workers but also permeated with a fast evolving ecosystem of BYO Devices.
From another angle, the ubiquity and efficiency of the network makes it the obvious choice for converging a diversity of other site functions – such as security, access control, fire alarms, environmental and process control systems.
The result today is that the enterprise network, originally conceived as a fixed infrastructure to serve a relatively static business environment, is increasingly forced to contend with the conflicting demands of a very diverse set of services that fluctuate in real time. This puts enormous strain on those who manage the system. Worst of all, the virtualization trend further accelerates this dynamism by imposing the mobility of virtual machines across the network, introducing changes at machine speeds.
The way to solve this incongruous situation, and relive the strain on the IT department, is surely to virtualise the network itself – allowing it to grow less rigid, more responsive and flexible to meet evolving business demands.
Software Defined Networking provides a means to do this, because it provides a central network controller operating via a separate control plane. These allow data to be gathered and major changes to be rolled out across the network in real time, instead of via manual configuration of individual switches or via the limited capabilities of SNMP.
Public/priv ate data centres and their needs We’ve focused so far on the challenges in the enterprise, and the most discussed problems today tend to revolve around mobility, BYOD and the resulting security issues.
Important data is being requested by an application for someone with the name and password of a member of staff – but they are not inside the building and physically connected, and they are using an unfamiliar new smartphone. Can this be allowed?
Today’s security applications are limited by the data available to them – MAC or IP addresses, names and passwords. But SDN’s separate control plane opens up the field for innovation with a new breed of “content rich” APIs. Tomorrow’s access policies will be more specific:
asking not only who is using the network, but also what that person is allowed, where they can access it and at what time. A short-term contractor, for example, might only be granted access when in a certain office and for the duration of their contract.
Virtualization opens up a further can of worms. There may be good reason for a VM to be moved to a faster server in another data centre, but what if the network there is more congested? Or, if the gain in processing speed is offset by greater distance from the data storage? These are issues that could be anticipated by an SDN controller and traffic management applications created to optimize the movement of VMs and to reconfigure the network automatically.
Similar challenges face the service provider but, for the public data centre, they are overshadowed by the questions of scale – how to scale massively to add virtual networks. Current approaches, such as VLAN with its 4,000 limitations, cannot cope with 10, 20 thousand or more users – so the industry is looking to SDN to provide segmentation and provide security to keep user networks distinct.
The move to providing value added services – SaaS, PaaS and IaaS – also requires massive scaling to accommodate sufficient storage and VMs. The attraction to customers of these services lies in their ability to sign up and change services on demand to meet business need, and that translates into a high level of dynamism imposed on the physical network – more than can ever be achieved manually. SDN offers the potential to manage these changes and policy updates automatically from a central controller.
The same applies to a lesser extent in the enterprise – a department requires a new service and it must be accommodated on the network quickly and without excessive teething problems. So the differences between the public and private data centre needs are more differences of emphasis.
The SDN model
In place of distributed control across each network device, current SDN practice simplifies the switch to function as a data plane monitored and managed by a separate control layer directed from a central controller. This central controller has a helicopter view of the entire network – both what is required of it and also how it is performing.
So, for example, an application might require a specific data flow, but the current configuration cannot support that level of traffic. Then we need a central controller with sufficient intelligence to recognise this discrepancy and automatically re-configure the network to support that data flow – rather than just sound an alert and require operator intervention.
SDN provides the architecture to enable this to happen, and a standard API such as OpenFlow is designed to communicate the necessary data and control signals, but the actual intelligence must be provided by an appropriate application. This is the opportunity SDN offers to a new breed of network application vendors: to build bespoke applications to meet specific network operator’s needs and, what’s more, to recognize common needs and provide “off-the- shelf” network apps supported by a recognized standard such as OpenFlow.
February 2014 I
www.dcseurope.info 43
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52