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.

Related Articles:

Let’s Talk about the Modern Business Ecosystem: Why We Need to Open Up

Forty years ago, technology vendors had it all figured out. They would differentiate themselves by continually bringing new proprietary solutions to market—a recipe for success in an age of a closed hardware dependent architecture. By exclusively building their own product portfolio under patent or trade-secret protection, companies could easily secure long-term revenue. This proprietary race fueled business for decades, and it still does today. Consider proprietary software solutions from Apple, which have licensing terms that limit usage to only Apple hardware (for example, Mac OS X).

A proprietary model offers several perks, yet not enough in today’s era of digital transformation. Intelligent, connected technologies like IoT, AI and machine learning have ushered enterprises into a new era of any-to-any communication, one filled with seemingly limitless collaboration and CX possibilities. As companies worked to keep up with the rapid pace of innovation, they came to realize that proprietary solutions stifled their efforts to grow and evolve, and they could no longer rely on one or multiple vendor or their life cycle timelines to develop the next-gen CX and/or vertical-specific services they needed.

A Big Change in a Small Amount of Time

Over the course of just a few short years, we saw a massive paradigm shift in which companies began seeking niche vendors to drive revenue and competitiveness. They turned to cloud-based businesses that were born in the digital era. They looked to startups that specialized in vertical-specific strategies. It wasn’t long before the average organization had created a unique, multi-vendor ecosystem in which various solutions were integrated to meet specific customer and vertical requirements. Case in point: the average business now leverages up to six different cloud solutions.

As every market filled with competing vendors, it seemed the most influential players were those that offered engaged, open ecosystems. These vendors allowed customers to freely modify original source code for virtually any purpose, versus retaining copyrights. With so many companies operating complex, multi-vendor ecosystems, open architecture that enabled collaborative app development became ideal for driving desired customer outcomes. We even see customers now acquire their own technology to accelerate the digitization of their business. You can’t do that in a proprietary and rigid architecture.

Multi-vendor Ecosystem vs. Open Ecosystem

This rise of niche vendors isn’t expected to slow down anytime soon. In fact, Gartner predicts that startups will overtake leaders like Amazon, Google, IBM and Microsoft in markets like AI by 2019. If not properly supported, however, a multi-vendor environment can create infinitely more harm than good.

For starters, companies must secure their multi-vendor ecosystems. Research shows that the average organization’s network is accessed by 89 different vendors and partners per week, a number that should send chills down your spine from a security perspective. If that’s not shocking enough, one-third of companies admit they don’t know how many vendors access their systems at any given time. Despite this, over 70% believe their number of third-party vendors will increase by 2018.

In addition to this is the inherent challenge of seamlessly leveraging multiple different vendor solutions. You see, if these solutions aren’t properly integrated, they don’t represent a truly open ecosystem. To build targeted solutions that continually improve outcomes, companies must be able to seamlessly collect, track, share and use the data that exists across all vendor platforms and knowledge bases. None of these systems can be siloed from one another.

Consider the benefits of an open ecosystem within the transportation industry. Picture this scenario: administrators have taken notice that the 7:45 a.m. train fills up every morning to the point where passengers must wait for the next train. In a truly open ecosystem, management can leverage data collected across various integrated solutions (i.e., ticketing platforms, video surveillance systems, Wi-Fi/carrier grade services, mobile app systems, movement sensors, etc.) to identify the root cause of the issue and begin driving better customer outcomes. Data from the ticketing platform, for instance, may show that tickets purchased for 7:45 a.m. exceed the train’s maximum capacity by 15%.

At this point, management can leverage data in various ways to determine the best solution to the problem. For example, they may want to build a sophisticated level of automation to dynamically change the train schedule, monitoring it for continual improvement. They may choose to send automated SMS messages informing customers of anticipated congestion times and suggested alternatives for work travel while displaying updated information in real time on their digital signage systems. They could incentivize daily commuters by offering 15% off monthly passes if used for an earlier or later train time. Regardless of how the experience is enhanced, the entire technology ecosystem should be actively working together to make it happen. As I say, dealing with congestions on highways by constantly rebuilding the roads with more lanes is not exactly the smartest approach. Maximizing and optimizing its usage through smart traffic distribution and management can be proven to be way more effective while meeting the citizen’s experience.

The Future of the Customer Experience Relies on Open, Extensible Architecture

The more open a business ecosystem, the more seamlessly data can be leveraged to drive desired customer and citizen outcomes. The ability to track, collect and share data across dispersed systems is what allows companies to create custom solutions that target exact customer requirements. This open, extensible nature is vital within a next-generation platform.

Differentiating oneself is no longer as simple as rolling out a new proprietary solution. To drive desired outcomes and deliver true value, organizations must be open, agile, integrated and future proof. As the world continues transitioning to an open ecosystem, we become that much closer to eliminating a longstanding dependency on legacy hardware and hierarchal architecture.

So far, I’ve discussed four of five critical components that organizations must start looking at within a next-generation platform: next-gen IT, IoT, AI and open ecosystem. Up next, we’ll take a deep dive into the final and most significant of these: the customer (or citizens) experience. Stay tuned.

Benefits of Deploying the Avaya Surge™ Solution for Any IP Network

The Avaya Surge™ Solution is designed to work in an SDN Fx fabric environment. But many companies don’t have the luxury of deploying a full Ethernet fabric before they deploy their IoT-based applications. Avaya Surge release 1.0.1 (November 2016) added support for non-fabric IP networks.

The Surge IoT Controller works essentially the same way as in the SDN Fx fabric deployment, except the Open vSwitch on the Open Networking Adapter can’t automate network provisioning. Therefore, the VLANs must be configured manually on the network. The solution still provides centralized inventory, white list profiles, flow filtering, and a single pane-of-glass status for all Open Networking Adapter-enabled IoT devices. Without the SDN Fx fabric infrastructure, segmentation is limited to VLANs that aren’t stealthy and mobility requires manual network service set-up and tear-down. For environments where devices are static, the IP-only version of Avaya Surge may suffice until a full fabric can be deployed.

The risk profile of IoT doesn’t lend itself to “good enough” solutions for long. When a company’s network and data are compromised, less than best practices will be criticized in the media, in the court room, and, as in the Yahoo case, impact executive pay. Avaya Surge Release 2.0, scheduled for the second quarter of 2017, adds IPSec encryption and tunneling to an IP-only deployment. (IPSec will be available for SDN Fx deployments as well.)

A HyperSec gateway is deployed to coordinate the IPSec functionality with the Open Networking Adapters. The HyperSec gateway terminates the IPSec connection from the Adapters and directs the data to the correct VLAN to reach the target application server. Return data is encrypted and sent to the appropriate Adapter, which terminates and forwards the data to the IoT device. The addition of the HyperSec gateway adds encryption to the data on the network, while adding mobility to the solution. The Adapter is able to dynamically create the IPSec tunnel to the HyperSec gateway, reducing manual network management.

The HyperSec gateway is deployed as an active/standby pair. Each Adapter will be set up with primary/secondary tunnels. If the primary is not available, the Adapter will communicate over the secondary tunnel to the HyperSec gateway. The HyperSec cluster is headless. Configuration information is maintained in the Surge IoT Controller. This greatly simplifies scale-out clustering of the HyperSec gateway.

I will blog more about the HyperSec solution closer to availability. Keep in mind that you can get started with Avaya Surge on an IP network today and add IPSec when it becomes available. Also, it is not an all-or-nothing solution. Critical IoT components and services go through the HyperSec gateway and less critical and stationary workloads are deployed with IP and VLANs. Furthermore, SDN Fx fabric can be incrementally added to portions of the IoT portfolio to gain the value of hyper-segmentation, native stealth, and automatic elasticity.

Look at all of this through a different lens. I was talking to a friend, an intellectual property rights attorney, about the exposure that companies face from data breaches. It was one of those conversations where he wanted to know more about the technology and I was curious about his perspective as someone who makes money from a company’s problems. He was especially interested because legal firms are getting $500K to $2.5M for a simple breach defense. When looking at these numbers, I think that even if a company isn’t found culpable in a data breach, they could spend a lot of money in defense. So, it’s probably best to invest in the infrastructure to deploy IoT projects in a safe and sane manner.

In my recent blogs about the IoT, I’ve looked at how the IoT enables Digital Transformation and examined a business-first approach to IoT technology adoption. Then I looked at how Avaya’s SDN FxTM provides a foundation for a safe and sane IoT deployment. Finally, I introduced the Avaya Surge™ Solution, which extends network fabric to IoT devices and provides centralized device management, protection, and flow filtering.

Avaya Surge™ Solution Makes Securing the IoT Easy for All Devices

Let’s explore how you can manage thousands of IoT devices while protecting your network and data from unnecessary risk. Often, we think newer devices will be more secure than older ones that were network-enabled before the current threat profile. However, Gartner predicts devices will remain unsecured for quite some time. The Avaya Surge™ Solution makes securing the IoT easy for all devices.

Avaya Surge, recently named a 2017 Gold Edison Award winner, consists of an IoT controller and an Open Networking Adapter, which is a proxy for IoT endpoints and provides the programmable security for insecure devices.

Key Attributes of Avaya Surge

  • Automated onboarding of IoT devices
  • Inventory reporting, including real-time status
  • MAC-based device security
  • Traffic flow filtering
  • Tight integration with Avaya SDN Fx (but works with any IP network)
  • IPSec encryption and tunneling in release 2.0 (coming in the second half of 2017)

How Avaya Surge Works

  1. An Open Networking Adapter is paired with an IoT device on the IoT controller by matching the serial number of Adapter (or QR code) to the MAC address of the IoT device. The IoT Controller sees the Adapter/IoT device as an inseparable pair and manages the IoT device through the Adapter.
  2. The IoT device is connected to the Adapter which is connected to the edge switch (plug RJ45 connectors together).
  3. The Adapter uses DHCP and DNS to locate the IoT Controller. The Adapter negotiates security keys with the IoT Controller and the onboarding process begins.
  4. The IoT Controller looks up the profile identified for the device type connected to the Adapter and down loads it to the Adapter. The profile contains network configuration, service requirements and allowable flows.
  5. The IoT device establishes connection to its application server and the Adapter begins monitoring network traffic.

Key Operational Benefits of Avaya Surge

  • The Adapter doesn’t retain profile information through a power cycle. If an Adapter is disconnected from the network or loses power, data in memory is lost. When power is returned, the Adapter must connect to the IoT controller to get its profile to function. Avaya Surge will indicate the Adapter/IoT device has lost network connectivity. Without a valid registration, the Adapter does nothing. Network or profile information can’t be learned from a stolen Adapter.
  • The Adapter is based on white list security. When the Adapter boots, it doesn’t allow traffic from the IoT device. The profile provides a white list of approved devices and flows. For instance, if the only IP addresses that an IoT device is supposed to contact are its application server and network services (DHCP, DNS, etc.), the Adapter will block all other traffic. This prevents a compromised device from infecting its peers.
  • The Adapter has a learning mode. A profile can be complex to create. Therefore, the Adapter can be set to accept all traffic and mirror it to the IoT controller. The IoT device operates normally with Avaya Surge cataloging the traffic. This allows the IoT device to operate normally under the supervision of IT staff. When adequate time has passed (dependent on device operation), the captured traffic is converted to a reusable profile that becomes the standard for all like devices. The Adapter is taken out of learning mode, updated with the new profile, and a new device has been added to the network—safely and sanely. Under normal circumstances, the IoT Controller receives reports only from the Adapter and isn’t in the data path.
  • The profile stops MAC spoofing. If all the Adapter did was lock down a MAC address, an antagonist could disconnect the IoT device and connect a computer with the same MAC address. Technically, the Adapter will allow this to happen. However, as soon at the antagonist tries to do something that the IoT device isn’t normally allowed to do, the Adapter will block the traffic and report an abnormal flow attempt to the IoT Controller. One of the issues with IoT is many devices can’t be physically secured and are susceptible to tampering. Avaya Surge addresses this challenge.
  • The inventory addresses all use cases. IoT devices will be deployed within an organization across many use cases and application stacks. For example, a facility may have point-of-sale terminals: CCTV cameras, HVAC sensors and controls, security key pads and door controllers, medical devices, robots, assembly stations, and more. Each of these is deployed with its own application servers with device status monitoring and inventory management. Avaya Surge provides network IT with a single pane status for all IoT devices that are secured with Adapters within the infrastructure.
  • Avaya Surge supports device mobility. Devices can be automatically moved from one network port to another. The Adapter contains OVS 2.4 code, including support for Auto-attach (IEEE 802.1Qcj). Auto-attach provides the ability for the Adapter to signal Avaya Fabric Attach to create the required services on the edge switch, such as VLAN and ISID mapping. If a device needs to be moved, a technician would simply unplug the Adapter from the switch, move the device and Adapter to the new location, and plug the Adapter into the new port. When the Adapter is unplugged, the Adapter loses its profile and the SDN Fx network disables the services to the old port. When the Adapter is reconnected, it contacts the IoT Controller to get its profile and the OVS requests the services be provisioned on the new port. Within a couple of minutes, the IoT device is functioning in its new location and the move has been done safely, sanely and without Networking IT involved. Note that networking IT would have been notified when the Adapter was disconnected and reconnected through the Avaya Surge dashboard.

In my recent blogs about the IoT, I’ve looked at how the IoT enables Digital Transformation and examined a business-first approach to IoT technology adoption. Then I looked at how Avaya’s SDN FxTM provides a foundation for a safe and sane IoT deployment. Next in this blog series, I’ll explore deploying Avaya Surge in a non-SDN Fx IP network.