Warakorn - Fotolia
Access networking layer ready for software-defined reboot
After years of stagnation, the access-layer network is in need of a makeover. Implementing software-defined configurations is perhaps a good place to start.
In the world of campus access networking, change has always come slowly. The protocols and paradigms of routing and switching at what we used to call the core and distribution layers -- as well as the wider network interconnects -- haven't seen many changes, either. But those changes have been more obvious.
The anecdotal and incremental changes to access networking have mostly involved gradual speed increases. Sure, the medium of delivery has changed from coax to twisted pair and eventually to wireless. Other than that, though, you might not have noticed much else.
Even more striking has been the lack of change in the behind-the-scenes delivery of the access layer. We've bounced between various ideas, like segmentation and virtual LANs, but virtual routing and forwarding was favored in some quarters -- at least for a while. Additionally, we toyed with quality-of-service paradigms as voice over IP took hold. And many methods for easing 802.1x deployments have also become popular.
However, only recently have we started to shift our thinking toward access delivery and what we need from it. After years of stagnation, everyone has seemingly decided we need to catch up -- and quickly.
Access networking gets software-defined
Once upon a time, you could throw an "i" in front of anything -- iPhone, iPod, iPad -- and add some slick packaging and sell it, regardless of quality or utility. The equivalent paradigm in the IT world has been software-defined whatever. Toss that term in front of anything, and you can sell a lot of widgets.
Up until recently, however, the access layer of the networking stack has been mostly immune to the software-defined label. That changed with the advent of software-defined access (SDA).
Marketing tactics aside, the current crop of SDA tools and platforms reflects the possibility of sensible technology with solid use cases lurking under the surface. To understand why the products are useful -- and peddled by so many vendors -- requires an understanding of what we mean by software-defined access. What do these products try to accomplish, and what problems do they purport to solve?
At a high level, SDA can mean access switches that are configured and controlled not by onboard software primarily, but by some type of central controller software. So, software residing on hardware -- the switches -- is now controlled by other software residing on other hardware. That might sound like semantics, but the SDA approach has real differences that make it a useful paradigm to apply to many of our modern policy challenges.
Rethink access networking with unified approach
Networks of the last 20 years have been robust, well-built and understood -- and entirely plodding in the face of change. These days, when we talk about agility, speed to resolution and flexibility, networks don't exactly meet these demands.
The following examples highlight this network stagnation:
- Wireless and wired policies have been seen as separate things, even when considering the same user on the same device.
- The provisioning of new gear has been slow in the initial configuration and integration to current deployments.
- Change management has been fraught.
- Quality of service has been nearly impossible to get right or to change once in place.
All these scenarios are done manually, meaning we perform our tasks one device at a time and hope we don't fat-finger our configuration and break the network. Our networks have worked well, then, in the same way buggies worked well before the advent of the automobile.
By moving the logic of the network to a separate controller -- the brain to a different body, basically -- we allow for some abstraction and scale to occur and potentially fix the aforementioned problems. In other words, we can develop our policies for the network instead of the device.
The result is a more intuitive approach when we consider the enablement of our users as a primary concern instead of a necessary evil. Our network can now become a unified entity. Our access, audit, security and service policies can work together to support network traffic's real raison d'être: cat videos, internet memes and the occasional business traffic.
Editor's note: In the second article of this two-part series on software-defined access networking, we'll explore some of the pros and cons of SDA.
