History|of|WAN circuits

I still remember the mid to late 1990s and my first interactions with the Internet. At that time I had my Pentium personal computer for around a year and Windows 95 was all the rage. And while Solitaire and Minesweeper were fun enough, that Broadcom 56kbps modem really opened a whole new world for me. I remember the nights spent in front of the computer chatting with people from all over the world on ICQ and IRC. There was no YouTube or Google or social media, but we still found ways of sharing music, finding content and interacting with each other online.

Some of you might be too young to know that in the 90s we were using phone lines and dial-up technologies to connect to the Internet.

Those were the days, the early slow days that is! The phone companies even had cheaper rates at night for their dial-up customers and that's all the encouragement I needed. With a dedicated and limited budget for the dial-up connections I had to make the most out of the time spent online as every minute was counted and cost money. Those early days put me on the path that in the end determined my career and shaped my entire life.

The WAN circuits and technologies in those days were quite a bit different, but set the foundation for the ones we have today. Fiber optics were still in their infancy and SONET/SDH was used to aggregate and transport those 56kbps (DS0) circuits. The SONET/SDH technology was so robust and scaleable that it is used even today, 20 years later. ATM, frame relay and ISDN were in vogue and especially frame relay managed to survive long enough to even be a subject on my CCIE lab exam in 2014.

Anyone remember ATM and the premise of having it implemented in the LAN? It was a nice dream to have a technology used both in the LAN and WAN, but unfortunately it didn't last too long and never became a reality, mostly because of the overhead and the fixed cell size. ISDN (which in some circles stands for It Still Does Nothing) has never caught on and proved to be a nice promise on paper, but too complicated to be adopted by users.

The pair of copper wires, that was used for more than a hundred years to provide voice services and recently data services, reached its limit in most parts of the world. A new dedicated network was needed for the Internet of tomorrow and this resulted in a whole new industry coming to life overnight: Internet service providers. The telephone companies that adapted to this new reality and embraced change still exist and thrive and the ones that did not, well let's just say they do not exist anymore. A new breed of companies emerged, dedicated to providing Internet services to users. Using and renting phone lines or deploying their own networks, they started to influence the technologies and Internet protocols that were developed.

While fiber optic technologies and transceivers became capable of transporting more and more data at a faster rate, there were advancements on the protocol side, too. Out of the limitations and lessons learned with ATM and frame relay, a new protocol emerged: MPLS (Multi Protocol Label Switching). MPLS was embraced as an all encompassing technology, as it could transport pretty much any lower level protocol, had traffic engineering capabilities, and additional services could be developed on top of it (i.e. L3VPNs, L2VPNs; etc.). Everybody was happy: ISPs could use the same physical infrastructure to carve out dedicated virtual circuits for their customers, and extend their network using L2 and L3 VPNs, and also add services (data backup, voice over IP; etc.).  At the same time, customers got seamless connectivity between sites and services that were not available to them in the world of the old. There was only one drawback: cost. MPLS circuits are usually expensive.

With the advent of 4G and soon to become reality, 5G networks, as well as the pervasiveness of cheaper broadband Internet connections (either Fiber To The Home, Fiber To The Curb, or DSL) users and businesses want to take advantage of this and lower their costs. It's great to have one or more dedicated MPLS circuits to all your branches but in some cases a best effort Internet connection via a DSL modem is good enough, and much cheaper in most cases.

The challenge in this situation is to load balance and optimize traffic when multiple WAN circuits are available. Cisco developed Performance Routing (PfR) technologies for this purpose, that eventually were integrated into the Cisco iWAN offering. And while this technology is ground-breaking and extremely powerful with all the options and knobs that you can configure, this actually turned out to be a drawback. The configuration and implementation of PfR resulted in some cases in complicated and time consuming setups. A new, simpler approach was needed. With the acquisition of Viptela technology this is exactly what was accomplished: a transport-independent, secure, service-friendly, cloud-managed SD-WAN fabric. Cisco iWAN features, together with Viptela simplicity, will bring the best of both worlds to our partners and customers.

What is SD-WAN?

SD-WAN or Software Defined -Wide Area Network, brings the advantages of SDN (Software Defined Networking) to the Wide Area Network. Just like in SDN, the main idea behind SD-WAN is de-coupling the control and data planes and re-architecting how we build networks and services on top of them. WAN circuits connecting networks over large distances and the routers that we have deployed until recently have had a common architecture. These devices are made up usually of at least a supervisor card, or ideally two for redundancy purposes, which are the brains of the device and process control plane traffic and I/O modules of different capacities, and with different features that perform the actual routing of the data traffic. These cards are connected by a switching backplane that is extremely fast and virtually error free and all of these components are enclosed in a physical chassis or a box. For the longest time this is how routing architectures were built: control plane, data plane and switching backplane all enclosed and communicating with each other in the same chassis.

The premise with SDN architecture is to split apart the control and data plane and move them out of a single device. In the case of SD-WAN, the control plane is a software component usually running centrally in a cloud environment, the data plane representing the I/O modules are the edge devices deployed at branches and the switching backplane is represented by the actual WAN circuits themselves.

While the advantages of this type of architecture might not be immediately visible to everyone, let's just say that going from updating the routing tables of 6,000 routers all of them running an individual control plane and data plane, to updating 4 control plane nodes in the SD-WAN architecture that control the same 6000 sites, is indeed order of magnitudes faster. Much faster convergence of control plane is just one advantage of the SD-WAN solution, and mentioning only this would mean selling the whole solution way short. I would like to also mention the fact that the solution is transport independent, end-to-end application QoE can finally be enforced throughout the whole fabric from one central management pane of glass, built in security all across the fabric with IPSEC tunnels connecting all branches out of the box, unprecedented flexibility in segmenting traffic and chaining services like firewalls and VPNs.

DevNet Resources

This week we are launching a new DevNet DevCenter dedicated to SD-WAN!
developer.cisco.com/sdwan/

What this means is that we have a lot of resources for you to get you started with Cisco SD-WAN, or if you are already familiar with it to help you develop applications and integrations on top of it.

First, make some time for our brand new video course:
https://developer.cisco.com/sdwan/video

In 13 videos, my colleague Vinay Prabhu and I demonstrate:

• What is SD-WAN?
• What are the components of the Cisco SD-WAN solution and how do they interact with each other?
• What is vManage?
• How do you access the vManage REST API and the documentation?
• How do you use Postman to interact with the API and generate Python code?
• How do you build a Python application from scratch?

You can download the application from DevNet's Code Exchange https://developer.cisco.com/codeexchange/#search=SD-WAN
and follow along if you wish.

In it, we interact with the API and get a list of all the devices and configuration templates in the fabric, we get a list of all devices attached to a specific template and attach and detach a specific template to a device.

We also have NEW learning materials for you:
https://developer.cisco.com/sdwan/learn

Find guided learning labs that take you step by step from learning about SD-WAN, to interacting with the vManage REST API, to developing your first application. You can also find links to the DevNet SD-WAN sandboxes on this page. There is an always on shared sandbox available 24/7 that you can start interacting with right away or you can take advantage of a reservable sandbox that is dedicated to you.

From the main DevCenter site you can find the link to ecosystem exchange:
https://developer.cisco.com/ecosystem/sdwan
and explore how Cisco's partners are taking advantage of the SD-WAN platform to bring value add services to their customers.

You can find a link to the vManage REST API documentation and also to our blogs that cover everything developer related from Cisco. If for some reason you still need inspiration, we will soon have a link to a sample application we developed and made available to our Cisco MSP (Managed Service Providers) partners that are using Cisco SD-WAN. This web-based application provides a one pane glass to MSPs that deploy several single tenant SD-WAN environments, and need a central location to monitor all their customers.

More great content regarding Cisco SD-WAN will be made available to our DevNet community in the following months, so make sure you keep an eye on social media (#DevNet) and developer.cisco.com.

P.S. I find it a bit ironic, but while writing this blog, I've just received a mail notification that one of the ISPs servicing the area I live in will install next week a fiber optic connection in my apartment. 56kbps to 1Gbps in only 20 years!

We'd love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel