Re: How to describe SSM sessions in SDP?

[bob quinn <rcq@sockets.com>]

At 02:16 AM 11/21/00 , Toerless Eckert wrote:
>> I've forgotten - does "draft-ietf-mmusic-sdp-srcfilter-00.txt" describe our 
>> current consensus for how SSM sessions are described in SDP - e.g.,
>>          c=IN IP4 232.3.4.5/127
>>          a=incl:IN IP4 232.3.4.5 192.168.9.10
>> ?
>
>It seems to describe that, yes. It is a bit sad though, that it, like IGMPv3
>tries to provide just an adequate solution for ISM (normal multicast) in
>the first place, even though most likely most users of both IGMPv3 and
>such an SDDP extension will want to use it for SSM.
>
>Problem is: There is nothing in this extened session description telling you
>if the filtering is just voluntarily - which is what filtering is for ISM,
>or if this is rather a necessary provisioning of the source address for
>the benefit of SSM.

Isn't the need for a source address (aka, a "filter") implicit 
to the *Source Specific* Multicast address range?  

>So an upgraded application that can recognize this extension can not 
>differentiate if this is a SSM session, so it can not warn the user that
>he won't see traffic in case that there's just insufficient stack below -
>like only IGMPv2 or the like. Sure, the IGMPv3 API doesn't provide 
>sufficient information either, but that just makes it worse.

Current Multicast protocols and APIs are no better.  When you
join any ISM group, there's no feedback from local routers or
APIs to notify an application when they won't receive anything
(e.g., when the local router isn't forwarding multicast traffic).

So, if we're going to improve the API and IGMP for SSM, why not 
improve it for ISM too, while we're at it?  A new API and IGMP
message for both would be very nice.  Something that would actually
query the local router(s) for IGMP version and an indication of
whether they have a multicast routing protocol enabled would be
much appreciated by multicast application developers (and their 
users).

>So an application that would like to learn if that's an SSM session, or
>if it can optionally express the filtering needs more attributes than
>just the list of sources. It would need at least another binary bit
>"Must include" or the like. Could rather call it "SSM" anyhow.

That still seems hit-or-miss without a feedback mechanism from
the local infrastructure and API.

regards,
bob quinn