Avaya Software-Defined Networking 1.0 — Doing it differently

Avaya Software-Defined Networking 1.0 — Doing it Differently

Let’s start with a few figures that explicitly demonstrate the unparalleled scale and diversity of devices to the Internet of Things:

  • Number of connected devices worldwide in 2016: 5 billion
  • Projected number of connected devices in 2020: 50-75 billion
  • Expected economic impact of IoT by 2025: $10-12 trillion

What’s not so apparent within these statistics is the monumental challenge to security. This is the challenge for every industry vertical, from healthcare to building construction, from FDA-approved medical devices connecting to the network to smarter-connected kitchens: How can they reliably and securely send control and network traffic into the cloud or within an enterprise without being compromised?

Securing the growing number of connected devices used in business—particularly in healthcare—is the focus of the Avaya SDN Fx Healthcare solution. First presented this year at HIMSS, a global healthcare technology conference, the solution is built around open source technologies to protect sensitive medical devices from would be hackers who could use the devices as entry points to the rest of the hospital network and introduce potentially malicious traffic originating on physically compromised devices.

At Avaya, we get it! Every good solution begins with key questions that capture the challenge. Simply put, we started with these three:

  • How can we help businesses address IoT without worrying about network deployment complexities, downtimes, upgrades and patching?
  • How can we provide the same or better level of security, availability and reliability of our customers’ systems as they grow with IoT?
  • How can we enable customers to get these done in a simple manner without massive forklifting or impacting their day to day operations?

Our strategy to overcome these challenges took a multi-prong approach, an open, extensible architecture and an eye toward the end users.

How Avaya Does SDN Differently

First, we implemented a controller-based architecture that creates secure service paths based on the profile of IoT devices connecting. Service profile is a container that encapsulates a network profile which is determined by who is accessing the network and a security profile determined by what is being accessed. This is called an access-context. This access-context-based service enablement ensures on-demand provisioning, putting critical security and compute resources where they are needed the most. The Dial-home feature of our smart IoT gateway device—the Avaya Open Network Adapter—helps ensure that it always connects to the controller to declare itself. Moreover, a combination of certificate, TLS-based authentication allows secure communication between the Open Network Adapter and the controller for safe, reliable control traffic exchange.

The next task was to drive a solution that addresses the potential for and likelihood of human error and system failure. Our underlying strategy therefore focused on insulating critical customer IoT devices and applications from these failure scenarios and delivering millisecond recovery with minimal down time. The Avaya Open Network Adapter—our IoT gateway device—can operate uninterrupted to provide secure connectivity for medical devices even when the connection to the SDN controller is lost or has experienced a failover. This guarantees continuous, secure availability of network resources for mission-critical business workflows.

To further augment our strong belief in availability and reliability, the controller plane architecture embraces a hybrid model of Active-Active and Active-Standby systems. The Active-Active model allows data and resource replications that are critical for southbound control operations. It is important to note that data implies user, application and context along with network details. This is done at a higher layer called the Clustering Engine layer using distributed main-memory database and Advanced Messaging Queuing Protocol (AMQP) bus. AMQP implemented using RabbitMQ allows controller to perform large number of transactions close to 1 million per second. Main memory databases using Mnesia allows distributed, fault tolerant DBMS implementation. Tables can be replicated on different compute nodes with system that guarantees location transparency. Therefore, the application accessing the data requires no knowledge of where the different tables reside. This allows sub-second response time, extremely fast data replication with smaller CPU cycles to execute, which are critical for control operations, high volume data analytics. Linearly scaling cluster implementation allows critical data to be replicated without being shared and thereby improving the overall availability of the data. Active-Standby implementation enabled preservation of singleton data (data that should not be replicated across system) such as licensing details, etc.

The architecture involves Master nodes (>=1) that actively replicate data to ensure guaranteed availability, a leader node that is elected from among master nodes to provide a unique northbound IP interface and host singleton data and a slave nodes (>=0) performing lower level control operations.

The embedded load balancer allows control traffic to be evenly distributed in the cluster comprising of N-nodes (where N<=255), supporting more than 30,000 transactions per second. This allows the controller to cater to any surge in control traffic and handle network storms. Moreover, it facilitates a single virtual IP addressing at the southbound data interface for the IoT devices connecting to the controller and thereby providing a single-system view to the outside world.

To ensure that systems can recover from failed state and that data integrity can be maintained without any compromise after recovery, we implemented a fault-tolerant model that uses a supervisor tree theory. Supervisor tree theory is a hierarchical model and notation that defines what needs to be monitored, remedied within active system. Supervisory tree has leaf nodes that act as independent supervisors looking at their own assigned set of resources and reporting to their parent node. Loosely coupled architecture ensures each leaf supervisory node to act on its behalf making independent decisions based on the operating conditions or from reports from its child nodes and configuration parameters. Remediation typically involves retries and migration of resources.

Last but not least, to ensure complexities don’t precipitate to the application layer, we have implemented a three-tier SDN architecture that is simple to deploy, use and most importantly allows customers to focus on their day to day operations without having worry about infrastructure. Installation is greatly simplified by our zero touch deployment which is unique in the industry. With just three simple commands per node user can deploy the full two-node cluster.

Northbound APIs allow customers, partners and developers to create secure network and connectivity services for their applications without requiring any advanced knowledge of the underlying infrastructure, SDN controller complexities. Application registration and authorization process using OAuth framework extends security to user and application space.

With an average of 12 connected devices per hospital bed and upwards of 100,000 connected devices in a given hospital system, it’s easy to see the need for an architectural model like this to push the accepted limits of the tools openly available. It’s also easy to see the importance of vendors like Avaya being champions for the standardization of these solutions rather than just opportunistically offering up professional services to overwhelmed IT organizations or leaving them to deal with the aftermath of breaches. Securing the diverse array of Things connected to the network and doing so at unprecedented scale is about more than just innovation. It’s a matter of solving the real-world problems faced by our customers in these rapidly changing times.