Subject: [Ieprep] multicast

From: Ken Carlberg <[email-masked]>
Date: Mon, 01 Apr 2002 21:07:13 +0100

so, at the risk of giving Fred some indigestion, i'll put forth these
thoughts about multicast and emergency services.

push-to-talk is an existing capability in public safety wireless
networks (PSWN) that would be complimented/supported quite well
with multicast in cases where one wants to migrate push-to-talk
into the IP world.  having said that, multicast in this case is
predominantly within a single subnet.  this can be expected to
possibly span to a 'few' other stub subnets if we assume a model 
where police,fire, ambulance have their own IP subnets and yet need to 
communicate with each other.  (note: this cross-agency requirement
exists today and goverment agencies of the US have procurements to 
achieve this in the very near future in the telco/PSWN world).

with the above scenario, and keeping in mind Fred's previous comment
about multicast (and the use of SSM and IGMPv3), i don't see big 
stumbling blocks in supporting multicast.  and i'm not thrilled about 
statically reserving class D address blocks.  as an example, one can go 
back to RFC1700 to see class D block assignments that never saw light 
of day.

also, if one were to consider associating an emergency with a specific
class D address, i would expect to see some specific comments about 
MALLOC's role in this.  the only arguement that I can think of for having 
a Class D address be attributed for emergency, is to allow it to bypass 
management controls such as rate limiting, which is what we used for the 
old Mbone. the downside to this, though, is that this may contribute to 
increasing the short term problem of congestion (ie, i'm shooting myself 
in the foot).  the only other thought that i can dream up is getting past 
middleware boxes (for example firewalls) that by default stop all mcast
traffic from getting through.  but at this point i'm reaching in the role
of devil's advocate.

so, perhaps we can put this thread to rest until someone puts forth
an I-D that has some specifics, and addresses the issues/concerns
stated so far.

-ken

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep