[SAM] SAM Overlay Protocol

[John Buford]

Hi Matthias,

On Wed, Apr 30, 2008 at 3:48 AM, Matthias Waehlisch <waehlisch at ieee.org>
wrote:

> Hi John,
>
> On Tue, 29 Apr 2008, John Buford wrote:
>
> > Isn't "overlay group address" somewhat circular?
> >
>  why? There is an underlay and overlay group address. And there are
> overlay PeerIds ... Overlay address seems to me a bit unspecified in the
> context of multicast.


Well, because we would be defining Group ID as a group address.

"overlay address" is any value in the address space of the overlay.


>
>
> > Could you explain in more detail the problem with the current
> > text?  Are you saying there are instances where the groupId isn't
> > the root of the tree?
> >
>  Yes, one example for this is CAN multicast. The group address in CAN is
> used to address the bootstrap peer. Based on this, the mini CAN will be
> constructed. However, data distribution is based on flooding the mini CAN.
> As far as I understand: Each member of the mini CAN may be inherently a
> source.
>
>  Another approach is the bidirectional shared distribution tree, which we
> sketched in Chicago
> http://www.ietf.org/proceedings/07jul/slides/SAMRG-3.pdf (for the paper
> cf. http://www.realmv6.org/bib/ws-buode-07.html) and elaborate at the
> moment.
>


I was trying to avoid rendezvous schemes where a rendezvous server manages
the tree, since I don't think it scales.  That is why I focused on
the group address being the root address of the tree.

We could say that GroupId represents the address in the overlay
to which join messages are propagated.  This includes models
where the GroupID is the root of the tree, or is a bootstrap
or rendezvous point.

In reviewing the slides on the shared distribution tree, I guess you
are refering to the IMG ids.  I don't see that these are equivalent
to GroupIds since a given tree could have multiple IMG ids,
one for each network domain it has receivers/senders on.
If I understand the slides correctly.

Also are you thinking about making your scheme overlay
agnostic?

Do you have any other suggestions for changes to this document?


John


>
>
> Thanks
>   matthias
>
> --
> Matthias Waehlisch
> :. HAW Hamburg, Dept. Informatik       :. link-lab
> :. Berliner Tor 7, 20099 Hamburg       :. Hoenower Str. 35, 10318 Berlin
> :. Germany, mailto:waehlisch at ieee.org  :. Germany, mailto:mw at link-lab.net
> :. http://home.fhtw-berlin.de/~mw      :. http://www.link-lab.net
> :.
> :. FU Berlin, Inst. Informatik, Berlin, Germany http://www.mi.fu-berlin.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ietf.org/pipermail/sam/attachments/20080501/244a0f72/attachment.htm