Re: SSM, RTCP, SAP

[Lorenzo Vicisano <lorenzo@cisco.com>]

For RTCP, the idea floating around was to unicast the RRs back to
the source and having the source echoing them back in the multicast
session (either the report themselves or some digested summary of them).
I don't know if this was ever specified 'though.

I don't know of anything similar for SAP, but I don't think we should
re-invent an ad-hoc routing protocol just for this. We should either
use the existing ASM multicast service, if present, or SSM + application
modifications (e.g. a set of relays that accept unicast SAP messages and
remulticast them. Relays will have all to listen to each other
announcements .. ect.. there are scalability concerns but seems feasible).

	Lorenzo

> What's the current thinking about handling RTP apps with
> SSM; RTP apps are intrinsically multi-sender (==> Receiver Reports)?
> 
> Similarly, what about (global) SAP?
> 
> Given that SAP comes under the category of "bootstrap" (I guess), wouldn't
> it be an idea to RPF flood SAP (minus the prune), and not incur any state
> for that flood? Such a flood would result in SAP announcements flowing
> over redundant paths, but a) they're infrequent, b) all SDRs want them
> within the flood (mcast) scope, c) they're bootstrap so they fit within
> a flood model.
> 
> So, how to prevent (s,g) state for SAPs? Define a ToS bit pattern that tells
> routers not to create fwd state for this packet??
> 
> I'm not suggesting doing the same for RTCP RRs, since they don't
> fall under bootstrap, and require sender/member-constrained distribution.
> 
> thoughts?
> 
> Tony
>