All things related to multicast

[Bill Nickless <>]

And now for something completely different: a more completely developed 
argument against IGMP snooping.

One of the reasons that unicast IP has been so successful is that it runs 
over many media.  In other words, it can LEVERAGE existing infrastructure 
without change or modification:

  o An RS-232C modem can be used to connect a teletype to a host
    -OR- allow two hosts to exchange SLIP-encapsulated IP datagrams.

  o A T1 CSU/DSU can be used to connect two PBX voice switches
    -OR- allow two hosts to exchange HDLC-encapsulated IP datagrams.

  o A DS-3 CSU/DSU can be used to trunk long-distance phone calls
    -OR- allow two hosts to exchange HDLC-encapsulated IP datagrams.

  o A Frame Relay VC can be used to carry IBM SNA traffic
    -OR- allow two hosts to exchange HDLC-encapsulated IP datagrams.

  o An ATM VC can be used to carry AAL4-encapsulated video
    -OR- allow two hosts to exchange AAL5-encapsulated IP datagrams.

  o An OC-192 SONET circuit can be used to carry 200,000+ phone calls
    -OR- allow two hosts to exchange PPP-encapsulated IP datagrams.

  o A Fibre Channel network can be used to attach disks to hosts
    -OR- allow hosts to exchange FC-encapsulated IP datagrams.

  o An Ethernet switch can be used by hosts to exchange IPX datagrams
    -OR- allow hosts to exchange SNAP-encapsulated IP datagrams.

But throw multicast IP into the mix, and you lose.  The same Ethernet 
switch that handles IPX, Apple Ethertalk, IPv4 unicast, IPv6 unicast, 
DECNet, and any number of other Ethernet-encapsulated protocols 
simultaneously will fall over and twitch pitifully when it's hit with IPv4 
multicast traffic.  Even media that can do point-to-multipoint natively 
(like ATM SVCs) rarely are leveraged to do IP multicast efficiently.

Why?  Because the IP multicast community collectively has the hubris to 
require Ethernet switch vendors to become IPv4 IGMPv2 and now IGMPv3 
aware.  Otherwise, Bad Things happen on that infrastructure.  Global 
flooding, switch processor overload, etc.

In lieu of anything better out there, I have to continue to push for IGMPv2 
snooping support in Ethernet switches in order to meet the needs of my 
customers.  But can I hold my breath for IGMPv3 deployment?  That's where 
my optimism ends.

IETF would be better off working on an IGMP that would support the use of 
GARP/GMRP on Ethernet, as GARP/GMRP can (and is!) implemented in Ethernet 
switches without requiring them to understand IPv4 or IPv6 at all.

More generally, IGMPng should be media-independent, allowing for network 
elements (hosts, routers) to signal to the media in whatever way makes 
sense for that media.

Until we get there, I think intra-domain multicast users should be prepared 
to run something like Finlayson's CastGate, enhanced to handle SSM-style 
(S,G) semantics.  Just as IPv6-over-IPv4 is being used to stitch together 
an IPv6 community while waiting on native IPv6 deployment, we should 
provide ways to do multicast-over-unicast until multicast is deployed widely.

The difference between IPv6-over-IPv4 and multicast-over-unicast is that 
the core of the native multicast network is already in place and 
operational, whereas the IPv6 default-free core has only recently come on 
line.  In the multicast case it's the edges that need work (local area 
networks and hosts).
===

Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7