Futuristic view on networking and SDN

The future of SDN might be a generic platform on which the network application would be written and create a new industry of network application service. We may expect different network applications to be released, which all tend to add intelligence to the network and get integrated with other applications and software. Many services are changing to some kind of anycast that requires an intelligent network to decide which client's request must be directed to which server. Some of these services are available now, for example the new NAS servers with anycast support integration with OpenFlow to the SDN network (products from Coho Data).

Similar to a computer operating system that delivers computing resources to an application, an SDN network operating system might be able to deliver packets to the application. The application decides how they would like to use the services.

With popularity of VMware and OpenStack as well as cloud services such as Amazon AWS and Azure, we expect that the SDN platforms in the future will support such integration natively. SDN platforms will be able to extend the local networks toward the AWS cloud virtual network and provide a seamless network from user premises to the cloud. They will handle all type of API integrations and creation of the required overlay or VPNs between sites and manage the packet delivery (a.k.a. routing in the legacy world).

SDN as it stands for Software-Defined Network, will get more visibility on applications. SDN platform will be able to understand the applications by integration with other platforms. SDN will know a Hadoop HDFS replication running between servers, and knows what priority it has and how to deal with it to ensure the application performance, while at the same time deals with a telepresence call between multiple parties and manages the real-time traffic and ensures no disruption on real-time traffic.

We have been using the IP addressing schema for many years. IP subnets are always used for grouping the networks and hosts and they are the key for routing decisions. All routing protocols exchange the subnets and prefixes to perform routing and build their routing tables. In an SDN enabled network there is no routing and this may change the way we used to perform IP address assignments. In a legacy network we understand the layer 2 broadcast very well. A host with an IP address of 192.168.1.1/24 will be able to reach another host with the IP address of 192.168.1.2/24 on the same network. The host sends an ARP request, the legacy switch broadcasts the ARP and destination replied back the ARP with its MAC address and finally the communication happens as both hosts find out the MAC addresses of each other.

Our defined rules of hosts on the same subnets or in different subnets doesn't apply in an SDN network. The SDN controller is the god of the network and decides which hosts shall be able to communicate with each other, regardless of their IP address or subnet mask. For example, imagine two hosts with IP details as follows:

• Host A: 192.168.1.1/24
• Host B: 192.168.2.2/24

Normally if host A needs to communicate with host B, it needs to send its traffic to its default gateway and default gateways should perform a routing to reach the destination network.

In the SDN platform, the SDN controller knows where both host A and host B are connected. Once host A needs to send a packet to host B, it's the SDN controllers job to cheat and reply back the ARP request of host A, and enable a direct communication between host A and host B although they are not in the same subnet.

This may sound freaky as SDN can destroy all the rules and laws of networking, but remember that you should compare the SDN with a chassis-based switch. SDN has a domain and out of that domain it follows the legacy network rules and protocols. In a chassis based switch when a packet enters from port 1 on line card 3 and the destination is a host connected to port 2 on line card 2, the switch management module as well as the FIB memory on line cards has visibility on where the destination is connected, similar to SDN the switch may just forward the packet out of its port 2 on line card 2 where it is required.

It is highly likely that all of the aforementioned imaginations and scenarios will occur to some degree, but it will be mainly depending on business cases, vendors, and how customers demand such services from vendors.