All things related to multicast

[ken lindahl <>]

On Thu, 5 Aug 1999, 

 (Kevin C. Almeroth) wrote:
>We should develop a strategy and pseudo-officially approve it.  Since
>there isn't really a mechanism in place I guess I/we get to define one.
>I'll try and develop this to be discussed by at least the Seattle
>I2 meeting.

this seems like a good lead-in to send a message that i've been mulling
over for the past week or so. i have a nearly immediate need for an answer
to this issue.

the UCB academic semester begins august 17 (yep, just around the corner).
the Berkeley Multimedia, Interfaces, and Graphics (MiG) Seminar, produced
by Larry Rowe's Berkeley Multimedia Research Center (BMRC), will commence
weekly multicast seminars Wednesdays 13:10-14:30 shortly after, depending
on when Larry can get presenters lined up for the early timeslots.

Larry is planning a smorgasbord of offerings for the MiG seminar:

LBR-1:  a low-bitrate (<200 kbps) vic/vat-based multicast intended
        to reach the entire global multicast internet, including
        the DVMRP MBone (*);

MBR-1:  a medium-bitrate (200-2000 kbps) vic/vat-based multicast
        intended to reach only vBNS and Abilene connected sites,
        excluding the DVMRP MBone (*);

MBR-2:  a medium-bitrate (400 Kbps) SureStream-based multicast
        intended to reach only vBNS and Abilene connected sites;

other:  some unicast RealVideo streams that are outside the scope
        of this message (since they are not multicast).

(*) by "DVMRP MBone" i mean the sites whose multicast connectivity
    to Abilene and vBNS is via AS10888 (MIX).

the restriction of MBR-1 and MBR-2 is motivated purely by bandwidth
considerations, it has nothing to do with content.

a question is: what multicast addresses to use for the multicast offerings
(LBR-1, MBR-1, MBR-2) listed above. based on the discussion on this list a
few weeks ago, i have two straw-proposals and will appreciate feedback.
i should explain that all of UCB's external multicast connectivity
is via calren2, vBNS, and Abilene; using PIM-SM, MBGP, MSDP; we take
mcast default from vBNS in MBGP, so our path to the DVRMP MBone is via
the vBNS connection to AS10888.

proposal A: (UCB is AS 25)
   LBR-1: assign an address in 233.0.25.0/24;
   MBR-1: assign an address in 233.0.25.0/24;
   MBR-2: assign an address in 233.0.25.0/24;
   in accordance with draft-ietf-mboned-static-allocation-00.txt; then
   request that any sites that feed into the DVMRP MBone use admin scoping
   to restrict MBR-1 and MBR-2, in particular this includes vBNS and Abilene.

proposal B:
   LBR-1: assign an address in 233.0.25.0/24;
   MBR-1: assign an address in 239.0.25.0/24;
   MBR-2: assign an address in 239.0.25.0/24;
   and reconfigure UCB's border router (and the calren2 routers) to "leak"
   MBR-1 and MBR-2 into vBNS and Abilene. this is consistent with dave meyer's
   most recent proposal to this list, but it would require vBNS and Abilene
   and connected sites to reconfigure their admin scope boundaries in order
   to get the MBR-1 and MBR-2 sessions.

it seems likely that i'll need to choose between these two proposals
pretty soon; probably before the seattle meeting in early october.

another notion (for which i don't have a concrete proposal at this time)
would be to designate 2 bits in the second octet to indicate the bandwidth
of the session, e.g.:

     239.[b00??????].*.* => low bitrate sessions (<200 Kbps, say)
     239.[b01??????].*.* => low-medium bitrate sessions (200-2000 Kbps, say)
     239.[b10??????].*.* => high-medim bitrate sessions (2-10 Mbps, say)
     239.[b11??????].*.* => high bitrate sessions (>10 Mbps, say)

(where the second octet is represented in binary, with '?' indicating "don't
care"). to anyone about to object that carrying this information in the
group address is ugly and wrong, i completely agree, but is there any other
alternative available now? my intent in suggesting this is to have a scheme
whereby network managers can use admin scoping to prevent higher bandwidth
sessions (from any source, not just UCB) from reaching parts of their
networks where it might be problematic, such as those old shared 10Mbps
ethernets that i suspect exist at other places not just here at UCB. :-}

this suggestion is not compatible with dave meyer's proposal since his
proposal uses octets 2 and 3 to represent the AS, and my suggestion grabs
two bits from that space. the 2 bits could be taken from octet 4, but
that would restrict the number of groups from any site to no more than
64, per bandwidth classification. that's probably a large enough number
right now, but for how long?

thanks for any and all feedback.

ken