All things related to multicast

[Bill Nickless <>]

I am involved in a project ( http://www.startap.net/starlight/ ) which I 
hope to include, as one of its features, an inter-Autonomous System IPv4 
multicast exchange point.  Following is a survey of the various options for 
the layer-2/3 exchange point architecture I have considered, with pros and 
cons of each.  I would be grateful for comments, corrections or suggestions 
to flesh out these options and considerations--or any alternatives that I 
have not considered.

SHARED MEDIUM
=============
This is the traditional multicast exchange point architecture, which 
consists of a shared medium for all participants.  (e.g. FDDI, unbridged 
Ethernet, Token Ring.)

Benefits:  - trivial to implement

Drawbacks: - all participants see all the multicast traffic, whether
             or not they care to see it.
           - May cause packet duplication.  Consider four peers, A, B, C,
             and D.  A sends an (S,G) join to B.  C sends an identical
             (S,G) join to D.   B and D each send the (S,G) traffic to
             the exchange point.  A and C receive duplicate (S,G)
             traffic, one copy each from B and D.
           - Total exchange point bandwidth limited to that available
             from the shared medium.

IGMPv2 SNOOPING HARDWARE
========================
The current plan for the exchange point is to have many of the ASes peer 
across a Gigabit/10-Gigabit Ethernet switch fabric.  It's not unlikely that 
this switch fabric could be configured with IGMPv2 snooping.  The bad news 
is that IGMPv2 snooping generally floods all traffic to all known router 
ports.  Thus, using IGMPv2 snooping hardware devolves to being equivalent 
to the shared media option.

SEPARATE VLAN FOR EACH PAIR OF PEERS
====================================
One could isolate multicast traffic to interested peers by defining 
separate VLANs for each pair of peers to use.  This would be logically 
equivalent to the current ATM peering model in use at the Chicago NAP 
(STARTAP/NGIX/MREN/etc) today.

Benefits:  - Isolates traffic to those peers interested in it.
           - Allows peers to choose RPF individually for any (S,G).

Drawbacks: - Requires N^2 VLAN definitions (N=number of peers) in the
             exchange point switching infrastructure
           - Requires peers to support a trunking protocol (ISL, 802.1q)
           - Requires peers to do packet replication for each
             interested peer, duplicating traffic outbound on the
             link towards the exchange point.

(Alternatively, s/a trunking protocol/MPLS/g and s/VLAN/MPLS tunnel/g)

EXCHANGE POINT MULTICAST ROUTER
===============================
Many Gigabit/10-Gigabit Ethernet switches include the capability of running 
M-BGP, MSDP, and PIM-SM.  One could set up the exchange point switch in its 
own Autonomous System and run M-BGP, MSDP, and PIM-SM with each peer.

Benefits:  - Isolates traffic to those peers interested
           - Requires only N VLAN definitions (N=number of peers)
             which is likely to be a tractable number
           - Each peer only sends one copy of outgoing packets to
             the exchange point; the exchange point replicates packets

Drawbacks: - Requires the exchange point operator to operate an
             Autonomous System with everything that entails (a routing
             policy, M-BGP, MSDP, etc.)  All peers would have to agree
             on the exchange point routing policy, as the exchange
             point would be choosing the RPF for any (S,G) requested
             by any peer.
           - Requires peers to support a trunking protocol (ISL, 802.1q)
             or to have two exchange point connections (unicast, mcast).
           - Complicates peer BGP routing policy, because the exchange
             point AS would have to be preferred by the peers over
             direct peerings, in spite of the shorter AS path that may
             be available elsewhere.

RGMP
====
"RGMP constrains multicast traffic that exits the [Ethernet] switch through 
ports to which only disinterested multicast routers are 
connected."  Supported on Cisco switches (see 
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_6_2/confg_gd/multi.htm#xtocid2897139 
for more information.)

Benefits:  - Peers don't get traffic for groups they don't care about.

Drawbacks: - Requires each peer (who wants the benefit) to use RGMP.
           - May cause packet duplication.  Consider four peers, A, B, C,
             and D.  A sends an (S,G) join to B.  C sends an identical
             (S,G) join to D.   B and D each send the (S,G) traffic to
             the exchange point.  RGMP operates on a (*,G) basis, so A
             and C receive duplicate (S,G) traffic, one copy each from
             B and D.

Fact:      - Would require the use of Cisco hardware in the exchange
             point and by each peer, because RGMP is apparently a
             Cisco-proprietary protocol.

IGMPv3 SNOOPING
===============
Two cases, each with fatal flaws.  If PIM-SM is involved, it's likely that 
the IGMPv3 snooping will merely flood all group traffic to all router ports 
(see RGMP section above.)  IGMPv3 can't be used as the signaling mechanism 
between peers because IGMPv3 doesn't specify *which* router should 
originate the traffic; one of the peers would end up the Designated Router 
for the whole exchange point (pity the poor peer that gets elected as DR!)

Maybe we could consider an extension to IGMPv3 where Reports could be sent 
to the IP/MAC addresses of specific routers rather than 01-00-5e-00-00-16 
(224.0.0.22, see 
http://search.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-07.txt 
section 4.2.13.).  This might even be an alternative to PIM-SM for 
autonomous systems to request (S,G)s from peers.

PIM-SM SNOOPING/SPOOFING ETHERNET SWITCH
========================================
Consider a Gigabit/10-Gigabit Ethernet switch that is PIM aware.  It could 
set up appropriate hardware forwarding based on the PIM Joins sent between 
pairs.  Note that the hardware forwarding would have to maintain separate 
(S,G) packet replication states for each peer that has been asked for data 
by some other peer.  That is, the exchange point switch won't get to pick 
an RPF towards each (S,G), so it will have to maintain separate 
(S,G,RPF-port) states with distinct output interface lists.

Benefits:  - Peers get traffic only for (S,G)s they care about
           - Peers send only one copy of traffic for (S,G)s and
             the exchange point does the packet replication.
           - Peers get to choose (by their own policy) the best
             RPF for a given (S,G).

Drawbacks: - Not yet available in the marketplace (to my knowledge).

At this time I'm leaning towards setting up an exchange point router living 
in its own autonomous system, because it's the most tractable option--it's 
harder to configure but it *can* be configured.

Thank you for considering these issues.

===
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