Re: SSM, RTCP, SAP

[Colin Perkins <csp@isi.edu>]

--> Lorenzo Vicisano writes:
>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.

There was some discussion of this in AVT at the last IETF - see
draft-chesterfield-avt-rtcpssm-00.txt

Colin



>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
>> 
>
>