Subject: [MBONED] New Version Notification for draft-tsou-multrans-addr-acquisition-00.txt for the 2nd item "Multicast Source Discovery" of the interim meeting

From: Tina TSOU <[email-masked]>
Date: Mon, 12 Dec 2011 02:27:54 +0000

Dear all,
Here is a new draft to work from for the 2nd item "Multicast Source Discovery" of the interim meeting.
http://datatracker.ietf.org/doc/draft-tsou-multrans-addr-acquisition/

Title:
Address Acquisition for Multicast Content When Source and Receiver Support Differing IP Versions
Creation date:	 2011-12-11
Number of pages: 9

Abstract:
   In a typical IP television (IPTV) system, the receiver acquires
   information about available program content, the subscriber selects a
   program to watch, and the receiver signals to the network to begin
   receiving the program in the form of multicast content.  The program
   content information is typically XML-encoded, can be transmitted in
   multiple segments, possibly over multiple channels, but includes
   media stream descriptions for the individual program descriptions
   that may also be XML-encoded or may use the Session Description
   Protocol (SDP, RFC 4566).  The media stream descriptions provide
   multicast group and unicast source addresses that are used in the
   subsequent signalling to the network.

   During the transition from IPv4 to IPv6, scenarios can occur where
   the IP version supported by the receiver differs from that supported
   by the source.  This memo examines and evaluates alternative
   strategies for allowing the receiver to acquire addresses in such
   scenarios in the version it supports.

>> 2. Multicast address discovery by the receiver (2 hours)
>>
>> How does the receiver learn the multicast addresses corresponding 
>> to specific programs, in the IP version that the receiver understands?
>
> We might want to call this Multicast Source Discovery. The following are a few interesting questions:
>
> - How are multicast sources identified?
> - How dynamic is the Source Discovery Mechanism? Does it simple discover and announce every multicast stream in the network or is registration required?
> - How do we ensure that the scope of the Source discovery mechanism is the same as the scope of the multicast network?
> - Can the Source Discovery mechanism be crafted from existing protocols?
>
> Again, it would be great if we had a draft to work from.

Specially, would like to thank Dave Thaler, for raising the problem, and inspiring the idea and giving technical advice; and valuable technical suggestions from Ron Bonica, Marshall Eubanks and Greg Shepherd.

Best Regards,
Tina

---

From: Mike McBride <[email-masked]>
Date: Fri, 16 Dec 2011 14:04:44 -0800

Tina,

Good summary and problem description. I'm getting a head a bit but my
preference is that we keep the solutions as simple as possible (a vote
for your administrative strategy). And use existing mechanisms where
possible. SDP includes IP4/IP6 in media descriptions. SDP can use SAP
(no please), SIP, RTSP, HTTP...for transport. All are v4/v6 worthy.
ICE/STUN can be used for nat traversal. The end device uses the
address it understands and then relies upon the forthcoming multrans
solutions for the E2E connectivity.

If we want to go down the road of new session announcement
functionality, perhaps a new session announcement mapping server, then
we should review draft-ietf-mboned-session-announcement (authors
should revive draft) for mcast session announcement requirements.

It should probably also be documented (with all multrans drafts?) how
this works with those having the luxury of dual stack environments.

Will the interim, to discuss this further, likely be in January?

mike

On Sun, Dec 11, 2011 at 6:27 PM, Tina TSOU <[email-masked]> wrote:
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Tina TSOU <[email-masked]>
Date: Fri, 16 Dec 2011 22:35:10 +0000

Mike,
Thank you for the comments.
I believe the interim would be in January, but it is up to the powers that be.

Tina

-----Original Message-----
From: Mike McBride [mailto:[email-masked]] 
Sent: Friday, December 16, 2011 2:05 PM
To: Tina TSOU
Cc: [email-masked]; MBONED WG
Subject: Re: [MBONED] New Version Notification for draft-tsou-multrans-addr-acquisition-00.txt for the 2nd item "Multicast Source Discovery" of the interim meeting

Tina,

mike

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 27 Dec 2011 11:21:19 -0500

Tina,

In order to make this document more readable, you might want to add text like the following to the introduction:

In order to receive desired content, the receiver must signal Data Items A, B and C to the network. The sender is capable providing Data Item A, B and D. Therefore, the problem is to transform data items A, B and C into Data Items A, B and D.

In your document, you identify the IP multicast address as being one of those data items that might require transformation. Are there others?

Also, it isn't impossible to decide how the transformation should be done until we have agreed on the mapping strategy.

                                                         Ron
                                                         /speaking as individual contributor

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tina TSOU
> Sent: Sunday, December 11, 2011 9:28 PM
> To: [email-masked]; MBONED WG
> Subject: [multrans] New Version Notification for draft-tsou-multrans-
> addr-acquisition-00.txt for the 2nd item "Multicast Source Discovery"
> of the interim meeting
> 
> Dear all,
> > - How dynamic is the Source Discovery Mechanism? Does it simple
> discover and announce every multicast stream in the network or is
> registration required?
> > - How do we ensure that the scope of the Source discovery mechanism
> is the same as the scope of the multicast network?
> Specially, would like to thank Dave Thaler, for raising the problem,
> and inspiring the idea and giving technical advice; and valuable
> technical suggestions from Ron Bonica, Marshall Eubanks and Greg
> Shepherd.
> 
> 
> Best Regards,
> Tina
> multrans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multrans

---

From: Tom Taylor <[email-masked]>
Date: Tue, 27 Dec 2011 14:55:11 -0500

Comments below, marked by [PTT].

On 27/12/2011 11:21 AM, Ronald Bonica wrote:
> Tina,
>
> In order to make this document more readable, you might want to add
> text like the following to the introduction:
>
> In order to receive desired content, the receiver must signal Data
> Items A, B and C to the network. The sender is capable providing Data
> Item A, B and D. Therefore, the problem is to transform data items A,
> B and C into Data Items A, B and D.
>
> In your document, you identify the IP multicast address as being one
> of those data items that might require transformation. Are there
> others?

[PTT] As I see it, the wording you are looking for is this:

"To request a program instance that has been selected by the user, the 
receiver must signal the corresponding multicast group address and, 
depending on the deployment, unicast source address. In the IPTV case, 
it acquires these addresses from an electronic program guide supplied by 
the provider. During the transition from IPv4 to IPv6, it may happen 
that the IP version supported by the source network differs from that 
supported by the receiver. As a result, if the receiver and/or the 
electronic program guide is unchanged, the receiver will be unable to 
find addresses it recognizes and can use for signalling in the 
electornic program guide.

"In cases other than IPTV, the receiver may receive the addresses it 
needs for signalling in a SAP (Session Announcement Protocol, RFCxxxx) 
announcement or directly through session-level signalling. For purposes 
of the analysis in this document the SAP announcement is the equivalent 
of the electronic program guide, since both are essentially a matter of 
acquisition of static data prior to the actual usage of that data. The 
strategy for dealing with the transition issues presented by 
session-level signalling may differ because of the latter's more dynamic 
nature."
>
> Also, it isn't impossible to decide how the transformation should be
> done until we have agreed on the mapping strategy.

[PTT] It's not as if the document comes to any conclusion as yet.
>
> Ron /speaking as individual contributor
>
...

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 27 Dec 2011 15:45:04 -0500

Hi Tom,

Response inline.....

> electornic program guide.

Yes, this is a good approximation.

> session-level signalling may differ because of the latter's more

I'm not sure what this paragraph adds. 

                              Ron

---

From: Tom Taylor <[email-masked]>
Date: Tue, 27 Dec 2011 18:29:16 -0500

I'm happy to drop the second paragraph. It was there because I was 
trying to guess at your intentions for the scope.