Subject: How to describe SSM sessions in SDP?

From: Ross Finlayson <[email-masked]>
Date: Mon, 20 Nov 2000 22:52:52 -0800

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
?

I remember that this was discussed in one of the meetings in Pittsburgh 
(and that I was the only person in the room who would have preferred to 
have everything specified in the "c=" line :-), but I forget what approach 
we ended up with (if it's different from that described in 
"draft-ietf-mmusic-sdp-srcfilter-00.txt")?

         Ross.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 20 Nov 2000 23:16:51 -0800 (PST)

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

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.

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.

My 2cents.

Cheers
	Toerless

---

From: bob quinn <[email-masked]>
Date: Tue, 21 Nov 2000 06:16:47 -0500

>or if this is rather a necessary provisioning of the source address for

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

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

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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 21 Nov 2000 13:23:44 -0800 (PST)

> to the *Source Specific* Multicast address range?  

Right, but so far i am not persuaded that everyone agress that 
all future applications, stacks and protocols should just hardcode
232/8 to be SSM and only that range to SSM. And of couorse we already
have customers who ask for multicast outside this range to (ab)use
scoping for access control.

So i guess as of today we don't know if a group is SSM or not by just
looking on the group address, and as long as we have this, it owuld
really be help full if we could try to convey this information a bit
better than we try to do it now (like we convey it not).

> (e.g., when the local router isn't forwarding multicast traffic).

True, but with SSM we're adding another layer of uncertainty, which is
about the source address being option or not.

> much appreciated by multicast application developers (and their 

Well as far as ISM is concerned, the host stack does already know if
there's a router and which version the router has. It's just the API 
that never wanted to deliver this information to the host. As long as there
was only ISM, i think the mayority of reasons was in favor of not doing
this signalling, but today i'm concerned about applications that may
for example get two session announcements, one which is low-bandwidth
ISM, and the other is high-bandwidth SSM and then i'd like the application
to be able to differentiate a bit better if a session is one or the other.

Cheers
	Toerless