Simplifying Device Deployments In Diverse Topologies

amit

The complexity involved with today’s network deployments is manifold. SDN controllers are invented and deployed to abstract some of the complexity away from the network administrator, but Day 0 simplification is still considered an Opex burden due to the fact that deployment of devices is not automated or they cannot be deployed across divergent topologies.

The complexity seems more pronounced in countries like India which are challenged by a multitude of other issues. Some locations  where network devices are installed are in harsh or very remote environments. In such scenarios any new install or upgrade is a deterrent. In such places even installing fiber cable for connectivity is a problem. Some of the network transport is therefore wireless, be it VSAT, EDGE, 3G or High Speed Packet Access (HSPA).

However this forms a complexity which is much more difficult to deal with. Any wireless link firstly has limited bandwidth and secondly the quality of the signal is dependent on how many SP RAN towers/Base Transceiver Station’s (BTS) are present in the area, the landscape, reflections and refractions of the signals etc. However, even though more complex, wireless allows connectivity to reach where it was deemed unthinkable even a few years back.

This has allowed user traffic to surge making India  one of the largest user bases for mobile in the world. Network manufacturers are also using this as a stepping stone to add interfaces for network devices which can operate without any wired connection, still due to the cost and time required to install and enable network services customers try and leverage the devices they have rather than upgrade. In many scenarios these devices are single points of failure, and if something goes wrong the area itself goes out of connectivity. This again leads to an opex burden for the service provider, in terms of revenue as well as downtime, not to mention customer satisfaction. Examples would be not just cell phone towers/Telecoms, but bank ATMs or internet kiosks which are littered across the country in every nook and corner.

A bigger problem to the above scenario is security. A zero touch deployment scenario has to take into account that a device being shipped to a location can be identified and authenticated, and would be authorized to join only certain networks. And this needs to happen without configuration as a zero touch deployment solution mandates no pre-provisioning of the devices. To simplify this consider  if you have a house and would like to automate opening the front door. When you do that, you would want the door to open only for people that have access to your house. If they don’t have access, they need to convince you that they can enter via many authentication and authorization protocols. But that is a Day N problem, after the door has been automated and all the fail-safes installed.

But what about Day 0? Can you trust the installer? In Day 0, or during the install process a backdoor can be installed, or keys can be stolen, but the question is how would you know about it unless the system itself tells you that something has gone amiss? Today there is no mechanism to solve this problem. A true secure boot-up of a device is still a pipe dream for many. So a common baseline would be required, where the operator may allow a few untrusted transactions to go through before doing a complete lockdown, the question however remains as to what are those and what are the mitigation plans if something indeed goes wrong?

Device and Feature Licensing: Licensing of devices is another pain point in today’s deployments which break the zero touch requirement of a deployment. Networking devices need to be licensed based on their place in network. An access device definitely does not have the same service set requirements as a distribution device or a core device would have. However today licensing models are not integrated as part of the device deployment and are manual in nature. For large scale deployments at day zero there is a need for automation as part of the onboarding process, this is definitely not a operators headache. Also if licensing is part of the onboarding process, the traceability of the device is much more visible, a device if stolen or spoofed can easily be recognized if the licensing information is strictly adhered to.

Device Discovery: The way a network is planned, the device always discovers a server, but there are no mechanisms where the server discovers the devices. For security to prevail, a bi-directional flow is required, otherwise any end of this chain can be spoofed and the onboarding of the device can be compromised. In any operator environment, a device when deployed takes anything between 0 to 30 days to pop up on the Network Management Station of the customer to be managed. What is the device doing for that amount of time is anybody’s guess. This does add to the opex of the customer, and if the operator is deploying thousands of devices the cost shoots up.

What we need: A SDN controller or a robust NMS is in a prime position to help this type of scenarios. The controller/management system should be able to discover devices across any topology or transport, authorize and authenticate the device, push licensing information and create reachability to the device for operators to start pushing actual device configurations and images, all without configuration being actually added to the device in the first place. It should also allow for the bi-directional security to work. And all of this needs to be at Day 0. Yes, a tall order for sure, but a necessary one.

The networking industry itself is going through a paradigm shift, and it’s logical that the way we deploy and operate our devices will change as well. Complexity is good for tuning the network, but not for repetitive large scale tasks which can and should be automated. If Indian operators have such a solution then the proliferation of devices will increase allowing for larger and larger of the geography to be connected, as they would be free of the burden at Day 0, and presumably Day N.