In this article, I will present the software network architecture and will deep dive into the concept of virtual networks and the network hypervisor. Before we go there, let’s review some history or sequence of events that drove the evolution of network protocols over the years.

In the early days, the network broadcast domain became very big and the ARP flooding in the network became unmanageable so we broke the network into multiple broadcast domains or VLANs, then we needed the VLAN to span multiple switches so we encoded the VLAN number in L2 ethernet via dot1q trunk encapsulation, then we needed redundant links in the network but we need to prevent looping and that’s what spanning tree protocol solved at L2.

IP addressing (N.H.H.H) added another problem where we would have low number of networks that support many hosts so the solution was sub-netting so I can take a 10.0.0.8/8 network and subnet it into 2 networks (10.0.0.0/9 and 10.128.0.0/9). With classful routing protocols such as RIPv1, routers don’t advertise subnet masks and that’s what classless routing protocols such as RIPv2, EIGRP and OSPF provided; then we wanted to create a tunnel between 2 autonomous systems over MPLS circuit and here the label routing solved big problem in the forwarding table by injecting labels between L2 and L3.

MPLS by itself is plain, the most important are the services on top such as MPLS VPN, traffic engineering & QOS. With MPLS VPN, the PE router have VRF per customer and this offers multi-tenancy or multiple VLANs on the same MPLS network i.e. the router in this case have global routing table as well as VRF tables (one per customer) and each VRF has its own CEF table; MPLS added overhead to the packet (each label with 32 bits) and it became the main requirement to support Jumbo frames of more than 1500MTU. Since the PE router connects multiple customers and each customer with different VRF table, we ran into BGP routing problem (for example, if one customer is using the same IP as another customer) and here the Route Distinguisher RD solved the problem and added 64 bits to the packets. And finally, with the shortage of IPv4 addresses, we needed to adopt IPv6 in service provider network and so we added extension to the TCP/IP software stack.

So what’s the problem with networking today! Why are we moving to Software defined networking?

1^st we need to get out of the closed box in networking, we need to create an operating system for networking with the resource management scheduling, all the nice abstraction APIs, user groups, permissions and multiple administrative domains. The OS have processes that are built on Linux name spaces and the main problem with Linux container architecture is the application packaging which requires more work to be ready for the network evolution.

2^nd, many of the network functions like SSL, TLS, LB, etc. are composed of multiple processes so we need to have a network hypervisor that can not only support that but also be aware of the multiple slices in the network and control what kind of information can be moved between 1 slice and another.

3^rd with the hybrid cloud model, confidentiality and integrity become more challenging. You’d have 2 apps for example, one is written in Java and another one is written in Erlang, that share the same network. For confidentiality, we need to secure that one app don’t leak packets to another app ; and for integrity, we need to make sure that one application can’t generate packets that would impact the network behavior.

4^th we need to solve the traffic engineering problem. The protocols used today work just fine; In the WAN for example, BGP works perfectly fine. The problem raises when you start doing traffic engineering using MPLS and here SDN perhaps solve the problem by applying logic that affects forwarding so the SDN controller does the TE and tells the switches what should be the TE FIB.

5^th with the proliferation of cloud applications, we’ll have islands of SDNs where each island has different performance and security requirements. For this case, we’ll have different SDN controllers & accordingly will need a controller of controllers and here’s where SDN federation comes to the picture.