Subject: private multicast groups

From: [email-masked] (199175000-V.ARORA)
Date: Thu, 28 Aug 1997 14:25:09 -0400

Hi:

I am looking at ways to implement a  "private" multicast capability which 
would allow an organization to use native multicast for private
multicast sessions between multiple sites connected to the same 
ISP. More specifically the ability to use addresses from the 
Organization Local Scope 239.192.0.0/14 (or some other reserved address 
space not conflicting with the public mbone usage) across an ISP's backbone.    

Currently the options available for private multicast groups include 
interconnecting sites belonging  to the organization via tunnels but this
is usually (>2 sites) sub-optimal vs native multicast so there is an 
incentive to use  native multicast. Another option is to use  encryption
over the  public MBONE, but off-the-shelf  multicast apps.  don't seem to have
adequate encryption support and also the preference is  not to send/receive
any multicast packets from the public MBONE for private sessions if possible.  
So I thought of some other alternatives and  wanted opinion on whether they
are feasible and of any value-

Since there are multiple organization on the same backbone, some way of
ensuring each can use multicast group addresses without conflicting with other
users is required. I thought of two ways of achieving this. Assume that 
239.192.0.0/14 has been designated for private multicast groups. 

1. Allocate non-overlapping chunks of address space to each organization for 
their private multicast groups. Ofcourse an efficient scheme for allocating/
reclaiming addresses has to be used because the number of addresses is limited. 

Then use access control lists at ingress ports to  limit multicast traffic 
to only the address ranges allocated to that particular organization. e.g 
an org.  which has been assigned address ranges - Addr-1/Mask-1  and 
Addr-2/Mask-2 will have acls on the the following lines-
 permit Addr-1 Mask-1                selectively allow assigned range 
 permit Addr-2 Mask-2                selectively allow assigned range 
 deny   239.0.0.0 0.255.255.255      block all other admin scope groups   
 permit 224.0.0.0 15.255.255.255     allow all other multicast groups 

These kind of access lists can be provisioned at least on  Cisco routers.
But in some  cases sites connect  via DVMRP tunnels to wkstations running mrouted.
Currently mrouted only has a "[boundary (<boundname>|<scoped-addr>/<mask-len>)]"
for specifying  administratively scoped boundaries. This  command is not flexible
enough to easily specify the acls in the required manner(doesn't have permit
clause equivalent). Could  hack it to be more general. Is anyone aware of
software for unix wkstations which could be used for setting up acls for
multicast groups as I have described it? 

2. Allow each organization to use the entire designated address space
(239.192.0.0/14).  Since obviously now there are going to be address conflicts
we need some mechanism to limit the multicast sessions to their respective
organizational domains. The advantage of this scheme is that it  imposes
no restrictions on address use  and multicast address exhaustion is not a problem. 
 
But the only ways I can think of how this could possibly be implemented are highly 
non-standard.  One idea is to allocate a  few multicast group addresses per org. 
like in scheme 1, over which the organization can use "multicast tunneling" (i.e. 
encapsulate org. scope packets in one of the allocated multicast addr.). 
This requires some support from boundary routers.  Another method would be to
"tag" the multicast packets to distinguish different org. routing domains.
Would reqire multicast forwarding logic to use "group-address, src, tag"  
instead of just "group-address, src".Clearly this doesn't look feasible anytime soon. 

I need some feedback on whether the private multicast capability 
as described is of any value vs.  existing methods. 

Thanks

-Vivek Arora