Avaya, alongside Leeds Beckett University, will look at a better way to build the smart campus and ready it for the agility and security demands placed upon it by the IoT. Can vastly reducing the number of protocols required to build a campus network lead to reduction in complexity and simultaneously increase security, agility, resilience and performance?
2. Infrastructure
and core hardware
HARDWARE & INFRASTRUCTURE
1.0
Value-added services &
apps built on top
of a data from
connected devices
3.0
SERVICES2.0
DEVICES
OPERATING SYSTEM
Connected devices
running on an
operating system
“Intranet of Things” to the “Internet of Things”
INTRANET OF THINGS INTERNET OF THINGS
4. 4
The Benefits ofVirtualization
Server Virtualization
Allows aggregation of multiple
independent virtual servers to exist
on a physical server
Network Virtualization
Decouples the physical infrastructure
from the connectivity services making
the network adaptive and dynamic
with simple one-touch provisioning
NetworkVirtualization enabled via Shortest Path Bridging
Compute
Access
Data
Center
Core
Campus
Core
Distribution
Layer
Access
Layer
5. Multiple Segments
Multiple Protocols
Multiple Resiliency constructs
Hop by hop configuration
Manual device configuration
Todays Networks
Status Quo
6. Complexity Agility
Today’s networks are based on too many protocols causing instability, slowing down recovery times and ability to
troubleshoot issues
“Protocols are killing us. Protocols are like
the never-ending bottle of pills, each one
prescribed to remedy the problems
introduced by the previous medication.”
- Ethan Banks – Host of Packet Pushers, and a network
engineer
http://packetpushers.net/does-trill-stand-a-chance-at-wide-
adoption/#disqus_thread
STP
RIP
OSPF
BGP
PIM
MPLS
One wrong move ….and the stack collapses!
7. 7
Shortest Path Bridging - Fabric
» Important Properties
› Shortest path based on link metrics with no blocked
paths
› Reverse Path Forwarding Check (RPFC) eliminates loops
› Symmetric data path between any two nodes provides
ability to leverage Ethernet based OAM CFM/Y.1731
standards
› Unicast path calculated from every node to every other
node
› Ability to calculate service specific multicast delivery
trees
› No IP configuration required inside the Fabric
› Network becomes aVirtual Switched Fabric
ISIS
ISIS ISIS
ISISISIS
ISIS
ISIS
ISIS ISIS
ISIS
ISIS
Unified
Management
IS-IS forms adjacencies to neighbouring nodes, discovers the core network topology and then
automatically calculates shortest paths from itself to every other node in the network.
IS-IS programs forwarding entries (FIB) in the Backbone VLANs (BVIDs)
8. One Network
One Protocol
One active-active
resiliency model
Automatic core
configuration
Automatic device
Configuration
SDN(fx)
Multiple Segments
Multiple Protocols
Multiple Resiliency
constructs
Hop by hop
configuration
Manual device
configuration
Status Quo
Today’s Network is Inconsistent and Complex
There is a BetterWay…
9. How It Works
Today, each network switch is its
own island of control
Packet processing is
end-to-end
1. Only FabricConnect
header read
2. Sent to next
shortest hop
Packet contents Concealed
Packet processing is
box-by-box
1. Packet contents
inspected
2. Compared against
manual routing tables
3. Routing rules determine
next hop
4. Segmentation occurs at
each box
Packet contents exposed
With SDN(fx), the control function is abstracted from each box
into one virtual distributed control plane
10. What It Delivers
True Core Automation
Automated Core
with Fabric Connect
11x
FASTER
Implementation
Time
7x
FASTER
Troubleshooting
Time
7x
FASTER
Configuration
Time
2,553x
FASTER
Failover
Time
100%
IMPROVEMENT
Outages Due
to Human Error
Core automatically
configures isolated
paths for:
New Services
New Applications
Security
Segmentation
Multi-Tenants
QoS Discrimination
One Active-Active
resiliency model
Network Services simply
delegated to the fabric
No human touch in the
network core
11. Game-Changing Functionality
The case for SPB
Fast
Flexible
Secure
• Provision at the “edge”
• One Configuration Command
• Optimized Link State Protocol
• Fast to Converge, heal,& add, delete, move services
• Extend services anywhere seamlessly
• True service virtualization with ease
• L2, L3, Multicast, VRFs…
• As much service isolation as needed
• Carrier type virtualization, zero complexity
• Network Invisibility to users
13. 13
AvayaTechnology Forum 2016
» ATF promises a rich learning
experience to grow your
knowledge of the latest
technologies
» WHY INVESTTHE TIME?
Through in-depth technical
sessions and tailored expert
engagement, ATF is focused
on helping you make the
most informed decisions
possible about designing,
implementing or migrating
to a truly integrated Digital
Organisation
» Please ask for more
information on Avaya
Stand 37
3/22/2016
14. Want to know more?
»Visit us on stand 37
@AvayaNetworking
Editor's Notes
CONCEPT OF HOUSE OF CARDS SLIDE ALONE
ANIMATION
DIAGRAM OF PROTOCOLS
FAILOVER
BOOKS
SPB DIAGRAM ON SIDE
SHOW IMPACT
As business environments have increasingly gained greater agility over the past years. Organizations have flattened, unified communications have become rich, and application development has become more dynamic. These applications, fueled by the emerging mega trends of big data, mobile, cloud and social, are moving the efficiency of companies forward in a big way.
However, there seems to be an elephant in the room. Behind closed doors business leaders and telling us (and research is backing this up) that the network is not keeping up. The static architecture of conventional networks are ill-suited to these dynamic computing requirements. The result is an increasing gap between the agility required for a successful business and that provided by the Networking foundation supporting the business.
We have been running most of the same protocols for over 25 years, so, the question is, “how do we close the agility gap?” What we hear, and likely you hear, is that IT professionals are looking at SDN as the way to close the gap.
4
Status Quo vs. Fabric Content
Multiple networks running different protocols
Here is a typical physical view of a network today. And here is the body of protocols that are used at the most fundamental level to run the network. To prevent Layer 2 loops, Spanning Tree must be employed; for Layer 3 Routing, OSPF is run, and for IP Multicast you implement PIM and its host of supporting components. Depending upon your needs you may also use: Static Routes, BGP, DVRMP, MPLS, or OTV.
There are two big problems with the legacy model. First, working with multiple interworking protocols becomes complex for implementation, maintenance, and troubleshooting. Second, when the network re-converges all the protocols must converge in sequence – this costs valuable time. Again, with thousands of cameras and Multicast streams, you are not just dropping VoIP and video sessions, but you are now losing video footage… and likely when you need it the most
Now look what happens when those legacy protocols are replaced with a single next-generation enterprise-wide protocol called, Fabric Connect. It is much simpler and much more powerful. Now cameras and devices are provisioned to the Fabric via the first Switch on the Edge of the network. The Fabric automatically takes care of the rest.
Customer Proof Points
We have been touting the benefits of a fabric-based network for some time now, and we felt that we wanted to quantify the benefits of the technology. So, we engaged a research company called, Dynamic Markets, to reach out to our current customer base of Fabric Connect users to measure and quantify the benefits of Fabric Connect. Each customer was interviewed and asked to report performance of their network before Fabric Connect and the performance afterward.
The bottom line is that we were thrilled with the results. Customers reported that implementing the network was 11 times faster and that configuring and troubleshooting was 7 times faster. Let’s put this into perspective. If every time that you needed to configure a service, it took you nearly 5 days, but now you could do it in less than 1 day, could you think of something cool that you could do with an extra 4 days for every service that you roll out?
If it takes you on average nearly 40 hours to troubleshoot issues, but you were able to drop that down to 6 hours, do you think you could find something productive do with the 34 hours of savings for every issue?
Now, the next stat was particularly interesting to us. The average failover time for Fabric Connect was 320 milliseconds. Honestly, that number wasn’t surprising to us, but the “before” number was. Before implementing Fabric Connect, customers reported an average failover time of nearly 14 minutes. At first we questioned the results, then after validating with the research company we started understand what was happening. If a network is taking 30, to 60 or more seconds to recover, applications start to fail. Not only do the likely 4-6 legacy protocols have to converge together, but the applications now have to recover in order too. To keep applications up, network recoveries need to be undetectable.
Now, since with Fabric Connect, you don’t have to configure the network core, we also asked about outages due to human errors. The average came out at 100% improvement with a prior average of 3 outages per year. So, full disclosure, the average time since implementation was approximately one year, so things could still happen, but nonetheless, we like the direction of the results.
We have made this report public on Avaya.com; so please take a deeper read.
So, hopefully, you are convinced of the value of an automated core, let’s talk about an open ecosystem.
Why we wait? Complexity! Today’s networks are based on protocol overlays which cause instability, slow recovery times and delay the ability to effectively troubleshoot network issues. A great analogy is comparing today’s protocol stack to a house of cards. As the number protocols gets larger - the more complex and unstable the network gets – just like a card tower. The other major problem is that in an overlay model each layer is reliant on the layer below to reconverge before it can reconverge. That’s why multicast (or PIM) which sits at the top of the protocol stack takes so long to recover.. Because it needs to wait for all the protocols below it before it can re-establish connectivity.
If you think about Avaya’s strategic direction relative to the competitions – it is really around eliminating complexity by eliminating the need for all these protocols – whereas the competition actually wants to add protocols –BGP, OTV, MPLS - to make their next generation solutions work. (see quote)
7
Status Quo vs. Fabric Content
Multiple networks running different protocols
Here is a typical physical view of a network today. And here is the body of protocols that are used at the most fundamental level to run the network. To prevent Layer 2 loops, Spanning Tree must be employed; for Layer 3 Routing, OSPF is run, and for IP Multicast you implement PIM and its host of supporting components. Depending upon your needs you may also use: Static Routes, BGP, DVRMP, MPLS, or OTV.
There are two big problems with the legacy model. First, working with multiple interworking protocols becomes complex for implementation, maintenance, and troubleshooting. Second, when the network re-converges all the protocols must converge in sequence – this costs valuable time. Again, with thousands of cameras and Multicast streams, you are not just dropping VoIP and video sessions, but you are now losing video footage… and likely when you need it the most
Now look what happens when those legacy protocols are replaced with a single next-generation enterprise-wide protocol called, Fabric Connect. It is much simpler and much more powerful. Now cameras and devices are provisioned to the Fabric via the first Switch on the Edge of the network. The Fabric automatically takes care of the rest.
Customer Proof Points
We have been touting the benefits of a fabric-based network for some time now, and we felt that we wanted to quantify the benefits of the technology. So, we engaged a research company called, Dynamic Markets, to reach out to our current customer base of Fabric Connect users to measure and quantify the benefits of Fabric Connect. Each customer was interviewed and asked to report performance of their network before Fabric Connect and the performance afterward.
The bottom line is that we were thrilled with the results. Customers reported that implementing the network was 11 times faster and that configuring and troubleshooting was 7 times faster. Let’s put this into perspective. If every time that you needed to configure a service, it took you nearly 5 days, but now you could do it in less than 1 day, could you think of something cool that you could do with an extra 4 days for every service that you roll out?
If it takes you on average nearly 40 hours to troubleshoot issues, but you were able to drop that down to 6 hours, do you think you could find something productive do with the 34 hours of savings for every issue?
Now, the next stat was particularly interesting to us. The average failover time for Fabric Connect was 320 milliseconds. Honestly, that number wasn’t surprising to us, but the “before” number was. Before implementing Fabric Connect, customers reported an average failover time of nearly 14 minutes. At first we questioned the results, then after validating with the research company we started understand what was happening. If a network is taking 30, to 60 or more seconds to recover, applications start to fail. Not only do the likely 4-6 legacy protocols have to converge together, but the applications now have to recover in order too. To keep applications up, network recoveries need to be undetectable.
Now, since with Fabric Connect, you don’t have to configure the network core, we also asked about outages due to human errors. The average came out at 100% improvement with a prior average of 3 outages per year. So, full disclosure, the average time since implementation was approximately one year, so things could still happen, but nonetheless, we like the direction of the results.
We have made this report public on Avaya.com; so please take a deeper read.
So, hopefully, you are convinced of the value of an automated core, let’s talk about an open ecosystem.
Today, each network switch is its own island of control. Each switch contains exhaustive routing tables, so that when it inspects a packet can best determine the next switch to send it to. At the next switch the process continues.
With Fabric Connect, based off the Shortest Path Bridging protocol, the control function is abstracted from individual switches into one virtual distributed control plane. This means that in place of routing tables, all switches simply know where each other is. Packets are encapsulated with a Fabric Connect wrapper and given the end destination node. Packets are sent across the network and switches only read the Fabric Connect wrapper and do not open the packet. This ensures complete security across the network.
Builds itself