The Future of IT: How to Prepare for SDN and M2M

In this article, we demystify SDN and M2M and discuss the role of IP address management and automation in preparing your network and IT staff for an SDN and M2M-enabled future.

Software Defined Networking

If you’ve been spending too much time maintaining your networking devices so you can dive deeply into new technologies such as Software Defined Networking (SDN), you may have serious apprehensions about what it could mean to you over the next several years.  Thankfully, the features that have been implemented into the SDN design from the get-go overcome the limitations of existing networking infrastructures and allow you to prepare for SDN quite easily.

First, let’s demystify SDN.

As you may know, there are two functional components of network devices:

Control Plane:  Where to send packets to or whether or not to drop the packets, based on routes and rules.  Static routing tables, and routing protocols such as RIP, OSPF, EIGRP all work in the Control Plane.

Data Plane:  The actual movement of the data packets, according to the rules and routes of the Control Plane.

An easy analogy is that the Control Plane is Air Traffic Control, and the Data Plane is represented by the actual airplanes flying around in the sky.

Currently, both of these planes reside on the same physical unit.  So, to modify the Control Plane, by adding/removing static routes, etc. you would have to log into each physical unit along the network path.  Also, different device vendors have different interfaces and syntax to make these changes which adds difficulty and complication.  What SDN does is move the Control Plane off of the physical units, to a centralized server.  The existing networking devices are left to exclusively perform the actual movement of the packets on the Data Plane.

This gives us several advantages:

• Offload processing requirements from the networking devices, lowering cost and maintenance
• Unified interface and syntax. You will no longer need to try to figure out the Cisco equivalent of a Juniper command or vice versa. One single command in the SDN interface will translate to both systems.
• Changes are programmable and schedulable. Because the SDN controller interfaces are designed to be programmable, changes can be scheduled and automated.
• SDN gives you a real-time high-level view of the network. This allows you to virtualize the entire network for in-depth testing.

To elaborate on the last point, the physical location of certain devices, such as firewalls, contributes to the behaviour of the network.  If a firewall is placed on one end of a network path, its behaviour will be drastically different than if it were placed on the other end.  With SDN, the physical location of each device no longer matters as firewall-type tasks can be given to any or all of the network devices.  SDN Controllers communicate back and forth with networking devices which allows you to gain a high level view of the traffic flow and network behaviour.  You can take this ‘picture’ of the network and separate it from the physical topology of the network.  This brings down a barrier to moving to the cloud as the network ‘picture’ can be deployed to the network devices on the cloud, be they physical or virtual.

If you are familiar with the benefits of BlueCat products, SDN has similar benefits.  

The unified interface and syntax is another significant advantage.  If you are familiar with the benefits of BlueCat products, SDN has similar benefits.  Much like BlueCat Address Manager allows you to control BlueCat DNS/DHCP Servers and Windows DNS/DHCP Servers using the same interface, SDN allows operators to control devices from different vendors using the same interface, and to control multiple network devices seamlessly.

Now the question is what one needs to do to prepare for all of these fundamental network changes. While a full level implementation document is beyond the scope of this post, the primary requirement is to ensure that your networking devices support SDN protocols such as OpenFlow.  Many vendors are already including OpenFlow support in their networking devices.  Beyond that, taking the time to learn the technology is the best way to prepare for SDN.

M2M (Machine to Machine)

The term M2M simply refers to the various technologies that allow end devices to communicate without human interaction (or interference in some situations). M2M devices need to be able to not only gather data and process knowledge, but also to send that data and process knowledge to all other systems. Unless you are going to be responsible for the engineering and design of M2M capable systems, your preparations will be centered on enabling streamlined deployment of the M2M capable devices.

….given the extreme number of devices that will be involved  within the M2M ecosystem, manual provisioning and addressing  of all of these devices by users would be next to impossible.

With the focus on lack of human interaction, automation is an extremely important part of M2M.  Devices need to be able to automatically discover each other, validate each other’s security compliance, and negotiate communications.  Furthermore, given the extreme number of devices that will be involved within the M2M ecosystem, manual provisioning and addressing of all of these devices by users would be next to impossible.  Tools that integrate and automate the deployment and connecting of these M2M devices will be invaluable.

IPv6 addressing is going to be an absolute requirement for these M2M devices given how quickly the number of devices will be increasing.  The automated assignment of addresses to newly deployed M2M capable devices is realistically the only sensible way of handling the workload.  DHCPv6 will allow these devices to connect to the network with zero human interaction.

On a level higher than the IPv6 addressing, automation workflows can be used with Software Defined Networking to automatically provision additional networks as utilization increases.  As M2M often requires zero delay or data loss, it is critically important that Quality of Service be maintained.

Given the obvious security concerns of huge multitudes of devices interacting and transferring data between each other, there must be tools that can validate the security compliance of the end devices.  They need to be scanned for viruses and malicious code before being allowed to interact with other devices.  This is quite similar to how current BYOD solutions can be used to enforce corporate security policy prior to allowing end user mobile devices to connect to the corporate network.  The same must be done, without human interaction, for the M2M devices.

Summing Up

In conclusion, with M2M, we are providing end devices with the ability to gather and share data and processes without human interaction.  With SDN, we are enabling users (and machines) to easily create and remove the pathways over which the data and processes are shared.  This will set the stage for a Future of IT where the machines themselves will be able to control their own environment, and possibly us as well.