All things related to multicast

[Toerless Eckert <>]

Some comments,

   Point to Point peering is certainly the one model in which you
   can most easily replicate all the experience from the unicast world into
   the multicast world. Of course, this doesn't scale all that well because
   you need to replicate your streams for each downstream receiver peer.

   We have some good experience with exchange points that are just based
   on a single switched (100/1000)ethernet with or without RGMP and this
   is certainly a nice simple model, although as you started to point out,
   there is the generic issue that a single traffic stream may be available
   from multiple upstream peers:

     If a single stream is available from multiple upstream peers, you 
     do not get duplicates! Duplicate suppression is handled nicely by
     PIM assert mechanisms. This also works when RGMP is enabled on the VLAN
     (at least in IOS images where CSCdr04333 is resolved). What happens
     instead is that just one of the two upstream peers will forward the
     traffic stream into the VLAN, and while this looks nice on the outset,
     it may not actually suffice the potentially twisted policy requirements 
of
     the connected peers:

       Let's say A and B can forward a stream into the MIX and C and D want
       to receive it. Now C actually wants to get the traffic from A because
       he has got a contract with A and D wants to do the same with B. 
       In result A and B need to agree upon which of them is to forward the
       traffic, because only one can send the traffic into a single VLAN
       (determined by the unicast route preferences set in routers A and B).

       So, how does this continue, A and B determine that A forwards and
       A and B cash in the money from their downstream peers independently ?
       Well, that will work as long as A provides the same bang for the buck
       (let's say with respect to packet loss and jitter) as B does. What
       happens if A's transit network sucks and D complains with B ?
       Well, then B will probably want to forward, but having learned that
       A sucks, he probably doesn't like the idea that C, paying to A
       also now get's his better quality...
  
   Right now i do not see this issue popping up in practice because we
   do not really see interesting cases of competing upstream transit
   providers with such differing policies or quality, but certainly on
   the long haul, this is something that needs to be considered.

   So, let me propose what i think is the correct way to set up a MIX
   when you need to have a better per-to-peer forwarding control than
   possible with PIM asserts:

     Multi-VLAN/Multicast MIX setup model:
     -------------------------------------
     For each party in the MIX there is one Multicast VLAN. The party
     who owns the VLAN has an MBGP/MSDP speaker on this VLAN and announces
     his prefixes/sources out this router (let's call it the owner-peer).
     This owner-peer does ignore all prefix/source announcements that he
     may receive from peerings established across this VLAN.
     
     In addition, the operator of the MIX will ensure
     by mean of intra-VLAN L2 packet filtering, that only the port connected
     to the owner-router of this VLAN will be able to source ip multicast
     traffic into this VLAN. All other ports are only allowed to receive ip
     multicast data traffic and to send PIM/IGMP/RGMP control messages
     onto the VLAN. If possible, TCP connections across this VLAN should
     also be filtered so that one end of the TCP connection must always
     be on the port connected to the owner-router of this VLAN (this will
     inhibit MBGP/MSDP connections between two non-owner peers on this VLAN).
     
     Whenever some other peer in the MIX wants to receive ip multicast
     traffic across one of the other paries peers, he has to connect his
     router to the VLAN of that party and establish a MSDP/MBGP peering to it.
     He should suppress actually sending out prefixes/soures on this
     peering, but this is just an optimization, because the owner-router will
     not accept them anyhow (see above).

     To optimize receiver efficiency, RGMP may be used.

     So, in effect you have a model which is like Point-to-Point peering
     with respect to each downstream peers ability to determine solely
     by his own policies from which upstream peer it wants to receive
     a certain traffic stream: If a certain prefix/source is announced
     by multiple upstream peers (each one on that peers party VLAN), then the
     downstream router can use his normal  unicast policy decisions to
     determine which upstream peer to choose.

     On the other hand, this model also avoids the unnecessary replication
     of multicast traffic: A single traffic stream will only be sent once
     across the MIX (on the VLAN of the sourcing peer)!. Only in the case
     that a single stream is available from multiple upstream peers
     AND multiple downstream peers that have different preferences whom
     to get the traffic from will a single stream be transmitted multiple
     times. But: As explained aboe, this may very well be advantageous,
     because different upstream peers may have actually different
     policies/characteristics on the stream.


Cheers
        Toerless

P.S.: We actually think about publishing RGMP to allow others to use it.

On Sun, Jun 10, 2001 at 07:23:10PM -0500, Bill Nickless wrote:
> 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     
> 
> 

-- 
   Toerless Eckert
   Cisco IOS - Gone Yellow!