1. IP Multicast over Avaya Fabric Connect
Ed Koehler
Director – WW DSE
Distinguished Engineer
Welcome to the technical overview for Avaya’s Native IP Multicast over Shortest Path Bridging.
I’m Ed Koehler and I will be your host for this session

2. The Need for Multicast Support
Well known Applications
Video Surveillance
TV, Video Distribution
PC Image Distribution
Financial Info Distribution (Trading)
New Applications
Data Center IP overlay models such as
VXLAN, NVGRE,...
Traditional approaches can take seconds to minutes to converge
What are its use cases? Literally any service that would have used traditional mautlicast in the past can strongly benefit from native multicast over SPB. Applications like video surveillance, TV and video distribution are a couple of obvious examples, but there are many upcoming data center focused technologies that depend on IP multicast functionality such as VMWare’s VXLAN. Due to its very nature isolation and security are of paramount importance. Avaya’s Virtual Services Fabric resolves this requirement easily by the use of native multicast within the L3 VSN environment. This approach allows for performance and scale but also provide for complete and total separation from the rest of the network environment.
As a result a customer could use native SPB multicast to deliver video and UC services out to the wider core and also use it to provide VXLAN inter- connect between data centers without being concerned about the accidental or intentional crossing of services such as those that might be attempted in a DOS or spoofing attack. There is simply no other technology available today that can provide these services is such an optimal fashion.
Thank you very much for your attention! As you can see native IP multicast over Avaya’s Virtual Services Fabric truly sets a new bar for virtualized multicast services. With it, IP multicast is finally ready for the cloud.

3. Nortel Corporate Presentation
Multicast Components
IP dest =
enet dest = E-0A-08-05
IP source = IP unicast
enet source = mac addr
receivers
Source
Multicast stream
source = origin of multicast stream
multicast address = an IP address in the Class D range ( – ), used to refer to multiple recipients. A multicast address is also called a multicast group or channel. Class D address must never be a source address.
multicast stream = stream of IP packets with multicast address for IP destination address.
(S,G) = (source, group) reference
receiver(s) = recipient(s) of multicast stream
© 2004 Nortel

4. So, what’s wrong with today’s multicast networks?
Today’s multicast networks are built on a protocol overlay model
Typically PIM on top of OSPF
Protocol Independent Multicast (PIM) Needs a unicast routing protocol
PIM builds its service distribution tree by referencing the unicast routing table
Required to prevent looping, part of Reverse Path Forwarding
Additional configuration required for Rendezvous Points and Bootstrap routing Protocol
This approach leads to strong dependencies on timers and creates an environment where any network topology changes create a disruption of the service.
We have had IP multicast for quite some time now. Why the sudden need for a change?
First, IP multicast has take on a more central role in the way appplications work. Not only in the delivery of media to multiple viewers but for critical data center functions as well.
This has put a spotlight on the fact that the traditional approach of protocol overlays is grossly inefficient and this tends to limit the scale and resiliency of the service.
This is all due to the fact that at the lowest level. The Ethernet forwarding or Data Link/MAC layer, the environment works on a stateless flood and learn model. While no one can argue the utility of this tried and true method for end system mobility, on one also will argue that the requirement for flooding in the core is something of a nessecary evil and if possible should be avoided.
As a result, we dice up the network topology with layer three networks and introduce routers to creates the sense of an end to end network path. Additionally, for IP multicast services we typically overlay yet another protocol such as Protocol Independent Multicast or PIM. Which enables for the registration of multicast sources and solicitation or joining to a service by recevier subscription.
All of this leads to an environment with strong dependancies between the protocols and where any network topology change will create a distruption of the service. Sometimes this distruption is on the order to 20 to 30 seconds, but usually they will extend to minutes in duration.

5. Which would you rather do?
Nortel Corporate Presentation
Which would you rather do?
Tradition
Disruption
Signal after convergence
Compute
Spanning Tree
IGP
IGP
BGP
IGP
Unicast FIB
Unicast & Multicast FIB ?
GVRP
PIM-SM
mLDP
Multicast FIB
© 2004 Nortel 5

6. Legacy IP Multicast Protocol Overlay Model
1st Media
Delivery Path
Source
Register
Complex
& Touchy!!!!
PIM Multicast Overlay RP
RPT
Join
IGMP
Snooping
IGMP
Join
IGMP
Snooping
RPT
Prune DR DR
SPT Join
Source
begins to
send media
IGMP
Join
media
(2nd)Shortest Media
Delivery Path
Source
Receiver
OSPF Unicast Overlay R
Now lets add in multicast. As you can see, things get even more complex. Protocol Independent Multicast requires a complex set of protocol functionality to provide for the registration of the source via Rendezvous Point registration and the solicitation of interest via IGMP at the edge.
Note how PIM runs on top of and is directly dependent on the unicast routing protocol that it rides on. In this case OSPF.
At the lowest level we have the traditional stateless Ethernet forwarding environment.
If any changes occur in either of these lower layers, the delivery of multicast services are distrupted.
This lends to an environment which is complex and touchy. Network topology changes and expansion are overly complex and intrusive.
Also note that this is for one routing environment. In multi-tenent networks this has to be replicated for every tenent that requires IP multicast services! This creates an environment where the number of software state machines becomes prohibitive and begins to effect the performance of the overall network. L2 R R L2
Ethernet Switching Infrastructure
(Stateless)

7. Why SPB with Multicast? Complexity Scalability Convergence
With today‘s legacy protocols (PIM) it is very complicated to build and operate an IP Multicast routed network
Scalability
PIM networks don‘t scale to the levels the new apps are requiring it to.
Convergence
Multicast convergence in case of failure in a PIM network is in the 10s of seconds or even minutes and not sub-second as L2 network protocols
“Multi-tenancy”
For multi-tenant applications new scalable IP-MC model was required
Dependancy on Unicast Routing Table
This model does not optimal for convergence and design reasons.
So what is the end result to the customer?
The complexity is removed… this reduces OP/EX and increases services up time.
Scalability is drastically increased to levels where PIM is simply incapable
Failure convergence times now happen in sub-second versus the seconds or even minuts required for PIM
Multi-tenancy is inherent in the way Avaya’s Virtual Services Fabric works. This means that we can support multi-tenancy without the typical processing overhead that traditional approaches require
And we remove the overlay dependancy that traditional appoaches require. This simplifies the technology and makes the enhanced convegence times feasible.

8. Always-On Video Surveillance
Integrated Surveillance with 10x better scale and 3x better performance
Competition: PIM Overlay
Avaya: Multicast over Fabric Connect
Stressed switch CPU warrants video overlay
Slow recovery times means lost content
Limited scale; more cameras you add – slower the recovery
Complex to deploy and troubleshoot
VLAN
Video-on-Demand Receiver Screens
Separate
Video
Overlay
L3VSN
Video Recorders
Advantage Avaya:
Cost-effective: one converged network, as opposed to a surveillance-specific overlay
Always-on: sub-second recovery times (<100msec) protects applications, as opposed to minutes
Scalable: tens of thousands of cameras as opposed to low thousands.
Performance: faster recovery times ,as opposed to slower recovery times ,as the number of cameras increase
Simple: single protocol, as opposed to complex protocol overlays
Ease of deployment: single command configuration, as opposed to complex network-wide configuration
Trade-off between scale and performance – unicast only scaling issue
Multicast – registration unstable and complex / 2000 – scale; no performance once you have scale.
Time and complexity (100 x improvement); unicast design is easy;
4.5 hours versus xx of days
“I just finished cutting over the County of Santa Clara network to Avaya running  multicast over Fabric Connect.  The results were astounding. Not only did the performance of the Endura Video system increase in efficiency and camera population time, but the Traffic management system is reporting a three fold increase in performance.
- Darren Giamoni, Lead Architect, Pelco

9. Enabling IP Multicast for Surveillance Before and After
Before Avaya Fabric Connect
After Avaya Fabric Connect
Complex:
Multiple protocols (PIM over OSPF)
Complex to operate and troubleshoot (proprietary tools)
Network wide configuration (boot strap routers, rendezvous points)
Recovery from failures seconds even minutes
Limited scale (100’s of streams)
Simple:
Single protocol (IS-IS)
Easy to operate and troubleshoot (IEEE ag extensions)
Single command end point configuration
Sub second recovery from failures
Massive scaling (10’s of thousands of streams)
“Avaya is changing the way multicast is delivered. When testing this functionality I didn’t have enough resources in my lab to even stress the Avaya solution”
Darren Giacomini, lead architecture for video surveillance at Pelco

10. Flexible Network Services
Trill and Fabricpath can only do L2
SPB enables all service types
Mapping of a Layer 2 VLAN into a Virtual Service Network delivering seamless Layer 2 extensions
Layer 2 Virtual Service Network
Virtual Service Network
Multicast Snooping
Multicast Routing
Multicast Routing
Native IP routing across the Virtual Service Fabric without the need for Virtual Service Networks or any additional IGP
VLAN
IP Shortcuts
Multicast Routing
Mapping of a Layer 3 VRF into a Virtual Service Network delivering seamless Layer 3 extensions
Layer 3 Virtual Service Network
Virtual Service Network
Multicast Routing
Enhancing 802.1aq by offering a policy-based Layer 3 internetworking capability of multiple Virtual Service Networks
Virtual Service Network
Inter-VSN Routing
2010 Avaya Inc. All rights reserved.

11. Nortel Corporate Presentation
By the way… why not enable IP Multicast Integrated routing with optimized forwarding
SPB automatically creates the most efficient P2MP Ethernet multicast trees.
No extra provisioning needed, just turn it on
Each tree is guaranteed to be loop free and follow the shortest path based on the link state protocol.
Since based on SPF, replication happens at optimal points
Each tree is calculated from each source to each receiver.
Allowing for multiple sources in different locations to have their own optimal tree
Providing the best possible delivery for IP multicast natively on Ethernet.
Makes SPB IS-IS an optimized IP Multicast Routing protocol with integrated forwarding
Multicast trees are calculated based on the IS-IS link state database
Src:
Grp:
ISID - 20
Receiver
Receiver
Channel bundle instrumentation controlled
Less moving parts, same simple protocol reused
Converged in sub-50 msec A
SPB
Routed Interfaces
Receiver
EndNodes’s don’t receive M’cast traffic for ISID’s they are uninterested in
Receiver
IGMP used to learn receivers
© 2004 Nortel

12. L2VSN Constrained Multicast IGMP Snooping L2VSN
Multicast traffic is confined to the L2VSN
All SENDERs and RECEIVERs are part of the same L2VSN
Automatic when IGMP SNOOPING is enabled on the L2VSN on the BEBs.
If another QUERIER is detected on the L2VSN when IGMP SNOOPING is enabled, it will be logged as a network configuration error.
IP Configuration is NOT necessary.

13. IGMP EDGE Supports L2VSN and L3VSN IGMP is used at the EDGE. No PIM
Redundancy at the EDGE is provided using SMLT.
Fully implemented as part of the initial support for IP Multicast over SPB.

14. Native Multicast over Shortest Path Bridging
IEEE 802.1aq “Shortest Path Bridging” provides a dramatic evolution to the Ethernet Forwarding Control Plane.
Stateful Topology
Use of IS-IS L2PDU and extended Type,Length,Value fields
Universal Forwarding Label
IEEE 802.1ah “MAC-in-MAC” encapsulation (B-MAC)
Provisioned Service Paths
Individual Service Identifiers (I-SID)
These three component technologies at a high level comprise the major evolution offered by SPBM.
The end result is a very stateful and deterministic forwarding plane for Next Generation Ethernet
IP Shortcuts builds upon this foundation to provide native routing features over those controlled paths
So what is it about Shortest Path Bridging that makes it so superior?
Well, the technology can be broken down into three major components.
First, the fabric works on a stateful topology and this topology is supported by IS-IS which is a very extensible protocol that works on the use of Type, Length, Value fields or TLV’s. RFC 6329 provides for the required TLV’s to support IEEE 802.1aq and IETF Draft Unbehagen provides for the TLV’s to support L3 virtualization or IP Shortcuts and L3 IP VPN’s. Recent research and development has resulted in the creation of new TLV’s to support end to end IP multicast. This new feature set which has just been made available by software upgrade version 7.2 on the ERS 8800 platform will become avialable on a wider array of Avaya shortest path bridging products throughout the 2013 timeframe. These new TLV’s will also be submitted to the IETF in the interest of open standards foundations and framework.
Second, the fabric uses a universal forwarding label provided by an earlier IEEE standard known as 802.1aq. This encapsulation method provides areas for information that when used in conjunction with IS-IS provides for the vast array of virtualized services offered within Avaya Virtual Services Fabric.
Third, the fabric uses a new level of abstraction for virtualized services. These provisioned services paths are termed as I-SID’s or Individual Services Identifiers. These elements are a new method for services abstraction within IEEE 802.1aq and as we shall see they provide an important role in the delivery of native IP mulitcast on SPB.

15. SPBM Multicast Theory of Operation
SPBM Multicast utilizes high order I-SID’s (>16M) to establish shortest path distribution trees thereby providing for the ability to distribute IP L3 multicast service offerings.
1). A multicast source is ‘registered’ into the SPBM network by the dynamic creation of a high order I-SID and its ‘advertisement’ by the use of specific IS-IS TLV’s
TLV 185 VSN “Constrained” Services
TLV 186 GRT
2). The I-SID is extended out dynamically based on the solicitation of interest by multicast receivers (IGMP)
3). The I-SID is extended out based on this edge signalling process.
As such, SPBM multicast is essentially a BEB UNI feature.
Allowing ANY SPBM capable node to act as a BCB

16. IP Multicast Routing over SPBm – Functional Reference
4).High order I-SID (>16M) is built out and video is sent over it
Source
Receiver
BEB
BCB
BEB
1). Video is sent into the UNI
3). IGMP join request is received into the UNI
2). IS-IS announces the S,G to all SPBM nodes with a high order I-SID for the mcast grp for forwarding
BEB

17. Avaya VENA Fabric Connect: Video Surveillance
Video Surveillance is transitioning from digital to IP
Relies both on unicast and evolving toward more multicast
Traditional multicast (based on PIM) is complex and unscalable
Traditional multicast takes seconds even minutes to reconverge
Avaya Fabric Connect offers scalable, efficient and resilient multicast support

18. Avaya: Multicast over Fabric Connect
Better Multicast with Fabric Connect Integrated Full Featured IP Multicast Support
IP Multicast Routing
IPVPN Multicast Routing
MVPN Virtualized Support
IGMP Snooping
Sub 100ms Convergence
Interoperable with IGMP
Avaya: Multicast over Fabric Connect
VLAN
Video-on-Demand Receiver Screens
L3VSN
Video Recorders
Advantage Avaya:
Cost-effective: one converged network, as opposed to a surveillance-specific overlay
Always-on: sub-second recovery times (<100msec) protects applications, as opposed to minutes
Scalable: tens of thousands of cameras as opposed to low thousands.
Performance: faster delivery times as the number of receivers increase
Simple: single protocol, as opposed to complex protocol overlays
Ease of deployment: single command configuration, as opposed to complex network-wide configuration

19. Thank You!
Ed Koehler
You Tube Channel -
Blog –

20. Be sure to tweet your feedback on this presentation
BEST OF ATF SPEAKER AND TEAM AWARD
Be sure to tweet your feedback on this presentation
#AvayaATF
Winners will be announced at closing of event