Re: Use of SAP in a PIM SSM Network

[Marshall Eubanks <tme@21rst-century.com>]

Mike Luby wrote:
> 
> Actually, I don't fully understand the last question about choosing SSM
> multicast addresses uniquely.  Since with SSM the address (channel) that the
> client sends an IGMPv3 join to is a (S,G) pair, where S is the origin server
> IP address and G is easily chosen to be unique among all G's that S is
> sourcing, it would seem that the problem of finding a globally unique
> address is not a problem.  However, there is still the issue of how the
> (S,G) address is mapped to a shorter address by some hardware environments
> like Ethernet, and maybe the question is how to make sure that this is
> unique with high probability?  It would be good to clarify this question so
> that there aren't misunderstandings and so that the weakness of the current
> solutions can be potentially fixed in the future.
> -Mike
> 

Dear Mike;

   I think that the biggest issue here is MAC address collision at layer
2. 
I think that it is a good idea to avoid this if possible. What we plan 
to do with our SSM broadcasts (starting next month) is to map our GLOP space
from  233/8  into the 232/8 SSM address range, and use that. If everyone does
this, then it is pretty straight-forward to avoid MAC collisions. Of course,
then, if you have more than 256 multicast groups, you have to worry about
collisions, but at least you can manage that yourself (or acquire access
to another ASN).

   The basic thing here is that broadcasters are going to want static
Class D addresses. (We, for example, have been up (doing ISM) since
early 
October with about 30 seconds of down time, and certainly want constant
addresses.) 
SSM will not change that. Whether these addresses are assigned by GLOP
type mechanisms or by other means such as MALLOC/ MADCAP doesn't really
matter that much, as long
as collisions can be avoided. It would be nice, however, if a Global SSM
allocation mechanism could be set up in the near future, before too many
people's choices get set in stone.

                                  Marshall

> -----Original Message-----
> From: Kevin C. Almeroth [mailto:almeroth@cs.ucsb.edu]
> Sent: Wednesday, November 22, 2000 7:41 AM
> To: Scott.Millington@edt.ericsson.se; ssm-interest@external.cisco.com
> Subject: RE: Use of SAP in a PIM SSM Network
> 
> >>Ericsson has very little problem with multicast in Campus environmnets &
> LAN's...It is the WAN that "generates" all the problems (link speed, load on
> existing links, business critical traffic "at risk", and redundancy).  Add
> to this that My division is responsible, but doesn't have control over
> different "islands" it also becomes a political mess.
> 
> I hate to bring up an oft repeated argument:  "How do you deal with
> this for unicast?"
> 
> When peering between domains, every single issue you mention is
> both an issue for unicast and multicast.
> 
> >>I have been kicking away for 2 years to try and motivate folks /
> organisations to open their eyes to the necessity of multicast.  Until
> September there was very little interest.  NOW everyone & their brother
> wants everything to work 6 months ago.  Perhaps it is the globality of
> organisations that the Ericsson Global IT Services Provides for...Am I the
> only one with this dilemma??
> 
> Nope...  and everyone is struggling.  The solution seems to be to
> get these folks thinking the right way about multicast.
> 
> >>SSM would be wonderful if we can get it up & running with support for
> different applications.
> 
> Do you have content and applications lined up?
> 
> >>I have an organisational question but it can easily be SSM / PIM-SM
> related.  Is there anyone out there that has an application (Platform &
> Application independant) for the dynamic assignment of multicast addresses
> GGG.GGG.GGG.GGG:port where folks can book a randomized multicast group in
> the same way as one would book a conference room??  A bonus feature would be
> that this application could handle & mediate conflicts (someone "keeping" an
> assignment, or making their own assignments).
> 
> Again, this is perception.  Tell your folks if they feel like they
> are likely to see a conflict, they should go buy a lottery ticket.
> Same odds.
> 
> -Kevin


-- 




   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 201
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : tme@on-the-i.com     http://www.on-the-i.com