Let's look at how the standard switch or router performs a frame forwarding. For our understanding we will look at a generic layer 3 switch (1G or 10G) from any vendor:
An Ethernet switch is a very simple device, it's just a silicon chipset, which is from one of the large silicon manufacturers such as Broadcom or Marvel, a CPU (which is either a x86 or a low power ARM-based processor), which runs the vendor's software (vendor here is referring to switch vendor such as Cisco or Juniper or Arista, and so on.):
The switch silicon is like a comparison table. It maps the frames to ports. When a switch receives a packet, it looks into its content-addressable memory (CAM) table to find out what needs to be done to this frame received on port X. The CAM table, which is already programmed and filled by the switch software, will have an entry to tell the switch silicon what needs to be done on that frame. For example, send it out of port Y and change the destination MAC to switch burned in MAC. Or any other decision such as sending it to the switch CPU for processing (if it's a routing protocol packet, for example an OSPF LSA).
So in simple terms, in standard switches the CAM table of a switch is filled by entries that are programmed and controlled by switch CPU or switch software.
In SDN, we have a slightly different scenario, you can imagine that the SDN controller will control the CAM table of all switches. The terms are changed slightly and it is called a flow table. A flow table is nothing but the same CAM entries in the switch, but it's called a flow table and each entry is called a flow entry.
SDN controller programs each switch CAM table via a protocol that is called southbound protocol. There are multiple southbound protocols where the most famous and standard one is OpenFlow; however, the others such as NETCONF and OVSDB also exist in standard protocol groups. Cisco's OpFlex (https://tools.ietf.org/html/draft-smith-opflex-03) is also an open source protocol which is a southbound protocol between Cisco APIC controller and Cisco Nexus switches. OpFlex is also supported on OpenDaylight.
OpenFlow is a protocol that allows SDN controller to program each switch in the SDN network. Please remember that the OpenFlow is a piece of software, it's a protocol. The OpenFlow agent runs on each switch and starts communicating with the OpenFlow server piece on SDN controller.
You may have heard about overlays. Especially if you have heard about the SD-WAN, which is completely based on overlay networking. An overlay is a network built on top of an underlay network. Seems complex? Let me provide a more familiar example. An SSL VPN tunnel is an overlay on top of a IP network. In SSL VPN, the underlay is IP, and an overlay is an SSL.
The real packets are encapsulated as new payload inside the SSL packets. You can make more examples of overlays, GRE, IPSEC, and also the new overlays such as VXLAN and NVGRE:
Overlays are also considered as part of the SDN family. Yes, they are software defined. They are created and managed by software. Overlays are not dependent on the underlay IP network; therefore deploying an overlay network is much easier than deploying a full SDN with SDN controller and switches. In data center overlay networks there are two main protocols used for encapsulation: VXLAN and NVGRE.
VXLAN is a UDP packet, which encapsulates the whole IP packet as a UDP payload and sends over the other end. VXLAN endpoints are called Virtual Tunnel End Points (VTEP). VTEPs create virtual tunnels between each other and transmit the UDP packets that are all having the packets encapsulated inside the UDP payload.
VXLAN uses an identification number for networks called virtual network ID (VNID), which identifies which packet belongs to which virtual network.
VXLAN is very common between most of the vendors and are very well supported.
Network Virtualization using GRE (NVGRE) is another protocol similar to VXLAN, but it is not very popular. Microsoft is one of the promoters of NVGRE on their SONIC switch operating system.
The most important overlay solution on the market is VMware NSX.
Now we have learned very briefly about SDN and overlays, let's have a comparison between these two technologies:
| Direct fabric programming | Overlay | |
|
Can work in co-existance with existing underlay IP network |
Yes or No depending on switch type. |
Yes |
| Requires to use an encapsulation protocol such as VXLAN, NVGRE | No | Yes |
| Scalable | Yes | Yes |
In summary, SDN and overlays are somehow completing each other, but they are different. Some people don't consider overlays as SDN, and some do.
OpenDaylight is an SDN controller, it is not an overlay.
