• No results found

Is the future of networking software defined?

N/A
N/A
Protected

Academic year: 2021

Share "Is the future of networking software defined?"

Copied!
6
0
0

Loading.... (view fulltext now)

Full text

(1)

Is the future of networking

software defined?

A Dimension Data perspective

Software-defined networking (SDN)

has become a much-hyped and

misunderstood technology shift,

with many vendors delivering a

real glimpse of what the promise

of SDN holds. Others however, are

riding the bandwagon and are ‘SDN

washing’ their existing products.

If SDN has you baffled, don’t feel bad about it. According to Network World, only 10% of 450 IT practitioners who attended a recent event raised their hands when asked if they understood it.

It would be easy to ignore SDN as yet another passing fad, but according to new research by Plexxi, SDNCentral and Lightspeed Venture Partners, the SDN market is expected to surpass $35 billion in the next five years. There must be substance to the story.

If SDN lives up to its promise to redefine networking as we know it - centralising

and simplifying control, making them more agile and programmable and creating opportunities for policy-driven supervision and more automation – it’s too important to ignore.

In short, SDN will help networks keep up with the speed of change made possible by virtualisation, convergence and cloud.

In this paper, Dimension Data offers a vendor-independent and pragmatic view of the emerging technology, the impact its likely to have and opportunities it will create. But in order to understand the promise of SDN, we need to start with a short history lesson as we look at the evolution of the network over the last six decades and the factors driving the current change in the networking landscape.

(2)

01

The three ages of networking

1. Mainframe and proprietary

protocols

The first age of networking started in the 1950s and was dominated by the mainframe. This era was characterised by proprietary protocols such as systems network architecture, in which organisations invested trillions of dollars in the building of mainframe-based applications and expanding the reach of their green screen terminals into branch and regional offices.

2. The golden age: personal

and client-server computing

By the mid-1980s frustration grew with the inflexibility of the mainframe model with its long development cycles and rigid communications architectures. The introduction of the personal computer (PC), with client-server computing which enabled a single user device to connect to multiple and distributed applications, disrupted the computing status quo.

The adoption of TCP/IP as the universally accepted communications protocol heralded the birth of the golden age of networking. The next 30 years would be all about building the Internet and establishing it as a global communications medium. Today’s fixed and mobile telecommunications networks, broadcast network and the vast majority of all communications traffic are over TCP/IP- based networks.

3. Mobiility, virtualisation

and cloud

With striking parallels to the disruptive change experienced in the 1980s, the same criticisms of networks are surfacing again today. Mobility and cloud have fundamentally changed computing models, with server virtualisation providing huge increases in compute density and efficiency.

End-user computing has also changed with combinations of PCs, laptops, smartphones, tablets and special purpose devices connecting to applications that could reside anywhere in the world.

The programmability of the network infrastructure is crucial for this transition, as these trends demand a network that’s able to respond quickly to changing demands. The abstraction of the control plane of the network from the physical data plane enables two key capabilities:

it enables the network infrastructure to be protocol-ignorant and it extends the democratisation of information and communications technology (ICT) to network application programmes, features and functionality.

Definition

Software-defined networking is an architectural approach to networking that separates the data, control and application planes. This enables the intelligence of the device to be split from the packet-forwarding engine and controlled centrally, while data transport is distributed.

In addition, it allows for applications to programmatically interface to the network for improved control, automation and orchestration over network behaviour.

As we move into the era of mobility, virtualisation and cloud, applications require an environment where they are freed from having to be aware of specific details of network topology, like IP addresses and ports. Network nirvana would see the network be truly responsive to the needs of the application, users and the organisation.

This evolution positions us firmly in the third age of networking, which the remainder of this paper will discuss.

Figure 1: SDN architecture approach

Application

Plane

Control Plane

Data Plane

OS Switch

Hardware

pSwitch vSwitch

Hypervisor

Orchestration Applications

Controller

(3)

A vision of a more

flexible network

Networks have always consisted of many technical building blocks that are complex and highly sophisticated in their own right, but when properly combined form a fully functioning system. The downside, however, is that networks often have an exponential level of complexity to deploy, manage and operate as their size grows.

Network engineers have become ‘masters of complexity’ – they are able to keep networks operational through sheer depth of technical understanding.

This situation has become increasingly untenable and more difficult to manage due to the dynamic nature of the infrastructure running on top of the network, which is the biggest bottleneck to evolving computing models. Virtualisation, consolidation, mobility, growth in

connected devices and associated network traffic have resulted in network teams that are overwhelmed by the rate of change, scale, and complexity. Networks are starting to do the opposite of what they were originally intended to do… They’re holding business back. Long delays, huge complexity and scale – where every device in the network needs to be reconfigured for small changes in applications or computing workloads – and the high costs associated with the people, processes and tools required for management – have forced a change in the networking industry.

SDN is an innovative and evolutionary approach to network architecture based on the ability to programmatically, and in an automated fashion, interface to network devices to modify their behaviour. There’s growing evidence and a great deal of optimism that SDN will make networks more flexible, dynamic, and cost-efficient, while dramatically simplifying operational complexity.

The basic premise is that an external application, network management tool or orchestration software can interface to the network, which enables the network to be connected directly to the business service layer to:

Extract greater intelligence from the network. Management tools or

Adjust the way the network operates programmatically, enabling much higher levels of automation. When an application needs additional capacity and new instances of the application are provisioned in virtual machines (VMs), the network could be automatically provisioned along with the new VM to ensure that it’s available on the same network, has appropriate security and performance policies, and is added into a load-balancing pool. Another example could be an event initiated in the business application: for example, business transactions have slowed down so the application configures the network to increase the amount of network resources available to that specific application.

Different methods to interface

to a network programmatically

There are multiple ways to interface to the network to achieve the goal of a flexible and ‘software-defined’ network, and currently there’s no single method that appears to be better than others.

The approach needs to evolve further and it is likely that the choice of method will be use-case specific. The average network will run multiple methods at the same time.

The main ways to programme a network include:

• Vendor-specific application programming interfaces (APIs).

A network equipment vendor publishes an API that enables external tools, software or applications to communicate with the network infrastructure. Some vendors argue that this is their preferred method to programme the network as they have full control over the API and its access to their hardware, and are therefore able to expose more functionality. This may be a good option to consider if the network has been built using a single vendor or where the functionality provided in the other methods don’t support the use case. A good example of a vendor API is Cisco’s onePK (Open Network Environment Platform Kit), which forms part of the Cisco ONE framework.

• Standard-based protocols (e.g.

OpenFlow). There’s been a groundswell of support for an industry standard protocol for communication between the data and control plane in network equipment, resulting in the formation of the Open Network Foundation (ONF) in 2011. The ONF consists of a board of directors representing some of the largest telecommunications operators:

Verizon, Deutsche Telecom, NTT, Google, Microsoft, Facebook and Yahoo are also represented, as are more than 90 member organisations that represent many of the largest software and equipment manufacturers in the market.

Together, this group has defined a standard protocol called OpenFlow. The ONF isn’t a traditional standards body and OpenFlow isn’t a standard driven by the well-known standards bodies in the ICT industry such as the International Telecommunications Union (ITU) or Institute of Electrical and Electronics Engineers (IEEE). However, OpenFlow has the broadest industry support so it’s likely to be one of the leading contenders in SDN standards adopted by most organisations. Many network equipment vendors have announced support for OpenFlow, including Cisco, Arista, HP, NEC, Juniper and Brocade.

Virtual network overlays. A virtual network is a logical separation or overlay on a physical network infrastructure. These overlays typically partition the physical network into isolated logical networks that can be individually programmed to deliver a specific requirement. The method used to achieve this is typically a network overlay protocol to configure tunnels on top of network hardware.

There are a number of methods available to implement network virtualisation using tunnels, including VXLAN and NVGRE, that are widely supported across the industry vendors. There are also a number of emerging proprietary methods gaining visibility, the most prominent being Nicira following their USD 1.2 billion acquisition by VMware. Each of the networks can have different configurations, and can be moved anywhere within a data centre or between data centres without disrupting the virtual view, thereby giving networks

(4)

03

Figure 2: Different methods to interface to a network programmatically

Application

Plane

Control

Plane

Data

Plane

SDN Controller SDN Controller

Network Virtualisation

Switch

OS

Switch

Switch OS

OS

Hypervisor

Hardware

Hypervisor

Hypervisor Hardware

Hardware

pSwitch vSwitch pSwitch vSwitch pSwitch vSwitch

Northbound API

Northbound API Northbound API

Southbound API

Southbound API Southbound API

Orchestration Applications Applications

What about network

management?

The management of the network becomes a specific point of discussion when considering programmable networks. The method of programming the network will in many ways dictate how it’s managed, with vendor-specific management tools required for both the vendor API-method and the virtual network overlay-methods.

The ONF describes an SDN controller that uses OpenFlow to manage the network;

this concept has evolved and is being used in various ways by the vendor community.

Some start-up vendors have based their business model on developing SDN controllers that support OpenFlow only, while others support OpenFlow and virtual overlay networks, and some vendors are talking about having a network controller that can do all of this in addition to being able to manage their own hardware through their own API.

To realise the value of automation and dynamic networking, these management tools also need to communicate, through APIs, to other management tools, such as:

Orchestration tools: the true magic of virtual environments and automation is delivered when complete ICT environments work together to deliver a business outcome. Some of this is achieved through the use of orchestration and cloud management systems. Now that the network can be automatically provisioned and managed, it needs to be controlled by the

orchestration policy and tool set.

Other SDN controllers: it’s highly likely that organisations will deploy different methods of programming the network as well as different SDN controllers across different elements of the network, or across different geographies. These SDN controllers will need to communicate with each other through an API or other interface.

Other important considerations are the security associated with network management, which management or orchestration tools have authority to make network configuration changes, and how far to take the notion of network programmability. Without enough thought and planning, two business applications could make conflicting network

configuration changes, thereby automating a network failure.

The concept of programmable networks is still new and this technology is far from mature, so it follows that management is presently immature. The majority of early SDN controller–user interfaces are not user- friendly and there’s a lot of work to do on the APIs to round out required functionality.

(5)

Market adoption and use cases

It’s envisaged that programmable networks will have the biggest early impact in areas of the network that are most affected by dynamic workloads, i.e. the data centre, but there is also a growing need for more agile wide-area and campus networks. This seems to indicate that the organisations that will adopt this technology in the short term will be cloud service providers, carriers with large data centres, and companies with large-scale data centres.

These organisations tend to be leaders in the adoption of most innovative and new technologies and SDN will be no exception.

It’s highly likely that organisations looking to deploy SDN will start small, testing the concept in a specific part of their infrastructure to prove applicability and success before making larger investments and deploying more broadly across their network infrastructure.

Some of the more common use cases that have been described for programmable networks include:

• The data centre: to manage the high degree of change necessary on the network to support virtual workloads, and to reduce the complexity of network in the data centre and allow for automation and orchestration of network configurations.

• The campus network: to provide context-based unified wired and wireless access for improved management of the connected users and improved security posture.

• The wide area network: to provide dynamic virtual private network

connections on demand, which could be used for a variety of purposes, including a cloud connector that dynamically connects to a cloud provider on demand

• Custom routing on business requirements: for example, secure versus non-secure route, based on the type of business traffic that flows over the network

Much improved access to data created by the network: for example, network usage information could be more easily extracted for charge-back purposes, or real-time performance metrics could be made available to business applications to enable faster transaction processing times.

The list above is not exhaustive, but provides a glimpse into the identified benefit this new approach enables. It’s certain that many more compelling use cases will be highlighted over time.

Recommended approach to SDN

There should be no doubt that programmable networks and SDN represent important paradigm shifts that will enable future networks to be more flexible; however, they must be approached with care. These technology breakthroughs are still nascent and haven’t yet reached any sort of mass recognition or adoption which would lead to further maturity. Only the very early adopters have deployed SDN, and they have done so only in small segments of their networks so that they can test the promised benefits.

Dimension Data believes that organisations should:

Start to understand what SDN can offer them, but keeping an open mind about the different approaches to SDN and not limiting thinking to a single approach.

Do the up front planning to get an understanding what devices and applications live on your network, what you need the network to do in the next 2, 5 and 7 years and what you might need to add on top of it. Use this information to explore different use cases and options.

Look before you leap: Network equipment vendors are doing significant new development to ensure their products remain relevant in the new paradigm, while many start-ups are pushing innovation to new levels. Because of its marketing value however, SDN is being applied to many existing technologies to give them fresh appeal – these technologies need to be sifted through and understood for what they are. We can expect to see further consolidation in the market as some start-ups are acquired, which we believe could introduce

additional organisational risk. Additionally, there’s much work to be done regarding SDN standards and many standards bodies have working groups looking at various aspects of the technology.

Understand the operational impact:

Think about the need to support your network on an ongoing basis. SDN will impact your support models as the environment changes and evolves.

Work with a vendor-independent partner with a thorough understanding of networking, network architectures and protocols. Additionally, they should have a solid grasp of virtualised infrastructures and the nature of cloud computing workloads, and how these impact the network. This combined knowledge will guide pragmatic and practical SDN choices that fit the overarching network architecture, and ensure that the network platform continues to support ICT and business objectives.

(6)

South Africa Tanzania · Uganda

United Arab Emirates · Zambia

For contact details in your region please visit www.dimensiondata.com/globalpresence

References

Related documents

Field experiments were conducted at Ebonyi State University Research Farm during 2009 and 2010 farming seasons to evaluate the effect of intercropping maize with

Al-Hazemi (2000) suggested that vocabulary is more vulnerable to attrition than grammar in advanced L2 learners who had acquired the language in a natural setting and similar

Passed time until complete analysis result was obtained with regard to 4 separate isolation and identification methods which are discussed under this study is as

The total coliform count from this study range between 25cfu/100ml in Joju and too numerous to count (TNTC) in Oju-Ore, Sango, Okede and Ijamido HH water samples as

The proposed indexing that uses Generalized Hash Tree (GHT) expedites projection and selection operations on encrypted medical XML records stored in WORM storage.. We implemented

The scattergram represents the distribution with age of 69 determinations of concentration of potassium in serum of 39 premature infants with respiratory distress syndrome (Table

19% serve a county. Fourteen per cent of the centers provide service for adjoining states in addition to the states in which they are located; usually these adjoining states have

Significant increases of the serum globulin, total bilirubin (except the decrease in total bilirubin of the 95-day exposure group) and direct bilirubin concentrations