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

[Mike McBride <[e-mail]>]

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 <[e-mail]> wrote:
> 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
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned