Subject: [MMUSIC] RE: Test FLUTE for Service/Session Announcement for Multicast Apps

From: [email-masked]
Date: Thu, 18 Dec 2003 11:00:28 +0200

Hi Sami

Could you describe the main features of the announcement protocol you're developing please?

(and a comparison with SAP would be helpful)

Cheers, Rod.

> -----Original Message-----
> From: ext Sami Peltotalo [mailto:[email-masked]]
> Sent: Thursday, December 18, 2003 8:40 AM
> To: Mmusic
> Subject: Test FLUTE for Service/Session Announcement for 
> Multicast Apps
> 
> 
> Hi all,
> 
> Does anyone want to transport multicast session announcements 
> with another
> protocol than SAP?
> I have used FLUTE for this purpose. You can also test how it 
> works with an
> open source implementation,
> see http://www.atm.tut.fi/mad.
> 
> Cheers, Sami
> 
> ps. (there is a short discussion below about this topic)
> 
> >
> > Hi,
> >
> > I am currently working with topic, which handles service and
> > session announcements for multicast applications. SAP/SDP doesn't
> > suit very well for describing services, which could be
> > categorized to different groups, for example sports, news etc. So
> > that the receiver could build some kind of service hierarchy from
> > the announcements, and the user is able to browse the services
> > from categories he or she is interested. At least I have chosen
> > another protocols than SAP/SDP in my work. RMT working group's
> > FLUTE protocol seems to be very good choise for the transmission
> > of service descriptions, so I am using it. I can't use SAP
> > because it has limited payload size and payload can't be
> > segmented to different packets (my service and session
> > descriptions are much larger than for example one SDP
> > description). I am using XML in my service and session
> > descriptions so it was nice to notice that SDPng has now again
> > XML-Schema. Has anyone else considered to use FLUTE for
> > transmission of session announcements?
> >
> > Cheers, Sami
> >
> > >
> > > Does anyone have a problem with a new and better announcement
> > > protocol than SAP?
> > >
> > > We need a few things which SAP doesn't handle too well, which is
> > > one of the things covered by the Internet Media Guide effort in
> > > MMUSIC:
> > > 
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-00.txt
> >
> > I guess anyone involved in applications/services over multicast
> > could be interested, especially where point-to-point isn't desirable.
> >
> > I wanted to get an idea of any strong opinions before I stick out
> > head and propose a real protocol task for MMUSIC next month.
> >
> > Cheers, Rod.
> >

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Sami Peltotalo" <[email-masked]>
Date: Thu, 18 Dec 2003 15:33:59 +0200

Hi Rod,

FLUTE suits well for transporting service announcements in unidirectional
multicast environment. It can
transport SDP files or any other file-based metadata, for example SMIL or
other XML syntax. FLUTE has
important functionalities to the transport: massive scalability,
reliability/robustness, congestion
control, segmentation of payload and independence of payload format. All of
these features are poorly
supported in the SAP protocol (Experimental RFC 2974).

There is also other problems with SAP: the bandwidth limiting algorithm
neither scales nor enables
priority announcements; also SAP depends on Any Source Multicast (ASM) model
so that in Source Specific
Multicast (SSM) networks initial access to the announcement channel requires
a different method.

An important feature for service announcements is the channelisation of the
announcements. This enables
priorisation of the announcements. Several channels could be used (low
priority, high priority etc.).
Channelisation is an optinal feature that is supported in FLUTE.

One issue is how to discover the initial announcement channel. SAP has a
well known (IANA registered)
group address, however this limits the scalability and inter-domain
feasibility. With FLUTE it is possible
to use for example hard-coded configuration or query from a web page.

All the announcement can be provided on the initial announcement channel or
metadata in this channel can
describe other announcement channel(s) and the receiver can join to those
and possibly leave the initial
channel.

Cheers, Sami

---

From: Stig Venaas <[email-masked]>
Date: Thu, 18 Dec 2003 14:47:47 +0100

On Thu, Dec 18, 2003 at 03:33:59PM +0200, Sami Peltotalo wrote:
[...]
> Multicast (SSM) networks initial access to the announcement channel requires

Also SAP won't work for IPv6, at least not globally, the way it's defined.
There's no inter-domain solution, and having a single RP in the internet
for the global SAP group won't work.

[...]
> and possibly leave the initial

I'm not sure, but this might be at least one possible solution,

Stig