Re: Local Group Addresses

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>, Eric Fleischman writes:
>                      A Question about "Local" group addresses
> 
> Dear CIDRites,				(cc: Rem-Conf mailing list)
> 
> [I realize that the following topic is not directly relevant to CIDR, but
> the recent "address wars" on this list has encouraged me to believe that
> you all would provide me with valuable feedback on this topic.]
> 
> Several of my coworkers and I have been discussing our plans (dreams)
> to eventually deploy production-ready application services relying upon 
> multicast technology.  When we begin to consider scheduling and
> capacity issues involved with these types of services we quickly became 
> concerned about collisions between internally used group IP addresses 
> and externally used group IP addresses.
> 
> That is, let's say we had scheduled event X to use a group address Y
> at a given time and a public Internet event also coincidentally decided
> to use group address Y at an overlapping time.  Since our internal multicast
> network would be Internet connected, this implied to us that there would
> be collisions between the two sessions even though our TTL broadcast value 
> would be very low.  In our minds, such collisions would be a Very Bad 
> Thing and would signify that the technology is not viable for production 
> environments.
> 
> In our discussions we could well imagine "race conditions" to occur for all
> group address allocation approaches except for approaches which segmented 
> the Class D address space into "public" (Internet-wide) and "local" 
> (non-unique) domains.  This implies to us the need to subdivide the Class 
> D space to diminish the possibility of a public venue interfering with a 
> private "event"  -- and to provide additional assurance that the private 
> session would not "leak out" into public (e.g., all local ranges could 
> be filtered at the firewall).
> 
> Since we are novices in this type of consideration, I am wondering whether
> a more viable solution to this problem has been proposed?  If so, I would 
> be grateful to know what it was.  Also, if no solution currently exists, 
> I would be appreciative for feedback concerning our idea to divide the 
> Class D space into public and local address ranges.
> 
> Sincerely yours,
> 
> --Eric Fleischman



Novices?  How modest.  Anyway, here are some ideas that may be as
uninformed as anything ever posted on rem-conf.

Multicast is obviously quite different from unicast.  With multicast,
the equivalent of RFC1597 is unquestionably very useful for local
multicast groups.

There are already scoping levels in the multicast framework (the
current mbone).  Right now these are enforced using TTL, which may not
be a good thing since connectivity may not be transitive within a
given TTL (a can talk to b at ttl x and b can talk to c at ttl x
doesn't mean a can talk to c at ttl x, though the mbone is configured
with the intent to make this true).  Regardless of how it is
implemented, there is scoping.

Within any scope, there can be shared sessions and private sessions.
There are sessions at higher scope for all but the top level scope
(which I'll call "global").  The important thing is there is only one
split that needs to be made at any scoping level.  All of the
individual more local scopes can use the same address range that is
considered private at the scoping level under consideration.

I'm not sure how to explain this clearly.  Maybe an example is the
easiest way.

At the top level (global scope), there is a public range, and a
private range.  You will proably also want to leave a good portion
unassigned in case you don't want to commit too much space up front
(or later want to accommodate a scope higher than global :).  If the
next scope in continental, all of the continents will use the same
address range.  Each can subdivide that address range differently
between public and private.

In a given (n)th scope, the space is subdivided into public and
private (and maybe unassigned) and each (n+1)th scope can subdivide
private as they see fit.

On a related topic, I think multicast tunneling may be with us forever
to accomplish scaling.  The reason for this is that there is no way
that every cross country 3 way conference call can be implemented
using a multicast at a very high geographicly based scope.  More
likely, the very local private scopes would be in effect bridged,
attempting to allocate a multicast group that was unused in both
private scopes, but only passing that one multicast group through the
tunnel.  If the hierarchical assignment of private an public is truly
independent, then the multicast group number may even have to be
changed within the tunnel, since there is a chance that the private
scopes involved don't have a numeric overlap.

Curtis