RE: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt

Leyman:

 

One possible solution ( out of the scope of the draft)

 

1. The sender behind the  NAPT sends the channel (Si,Gj) using a random Gj inside the multicast SSS range

2. Logically the sender expects that some one will be interested in the data, so the sender sends a unicast message (for example http)  to a "multicast index portal" describing the content and the channel (Si,Gj)

3. The NAPT changes the internal Si into a IP public in both cases: the unicast data and the multicast data using the same IP public.

4. The multicast portal knows the IP public and tries to connect with the multicast channel ( IP public, Gj)

If the multicast portal connects with ( IP public, Gj) there is no Gj collision and the portal shows the channel (IP public, Gj) in its index. Everybody can connect.

5. If after a few seconds the channel don't appears in the index, the senders understands that there is a multicast Group collision and changes the Gj into another randomly selected Gk.

 

Another business for the search engines.

 

Regards


Alvaro


________________________________

De: Leymann, Nicolai [mailto:[email protected]]
Enviado el: vie 08/06/2007 11:44
Para: Alvaro Fernandez; [email protected]; [email protected]; [email protected]; [email protected]
Asunto: AW: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt



Hi Everybody,

> Hi all.
> If you have two sources from two different inside interfaces
> sending multicast data to the outside interface and both
> sources use the same multicast address (G1) then outside
> routers, using for example PIM-SM, will consider that there
> is only one multicast channel and will send all the traffic.
> Also hosts receiving all the traffic need to separate it.
Right. This is from my point of view not the solution you want.
The reason for SSM is to have different senders (source) using
the same group and to be able to route based on (S,G) information.

> One solution is to reserve an IP address range inside SSM range
> ( for example 232.0.0.0 to 232.0.255.255) and let the NAPT change,
> not only the source address of the sender, but also the multicast
> address of the sender to be unique in this range. In this way
> outside routers ( and receivers ) will consider traffic as coming
> from different channels (IP public ,G2) and ( IP public, G3) with
> G2 and G3 inside the said range.
The main problem is how to signal either the (S,G) channel or the
multicast group if this information is changed by a NAPT device.

E.g. in a typical IPTV scenario the signalling of the group or
channel information is done out-bband using servers providing
information about the IPTV channels. Clients are receiving this
information from the server (http/xml) to join the appropriate
IPTV channels.

If a sender (S1) sends multicast traffic to a group (G1) the receiver
joins (S1,G1) due to the information it got from the server. If the
NAPT device changes this to (S2,G1) or (S1,G2) the receiver is not
going to receive any traffic.

I'm not sure if this problem can be solved without making to many
assumptions about the applications deploying IP-Multicast.

  Regards

     Nic

________________________________

        De: Manfredi, Albert E [mailto:[email protected]]
        Enviado el: mar 05/06/2007 16:02
        Para: [email protected]; [email protected]; [email protected]
        Asunto: [magma] RE: [MBONED] FW: WGLC:
draft-ietf-behave-multicast-06.txt
       
       

        > -----Original Message-----
        > From: Dan Wing [mailto:[email protected]]
        > Sent: Monday, June 04, 2007 7:38 PM
        > To: [email protected]; [email protected]
        > Cc: 'Behave WG'
        > Subject: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt
        >
        > The BEHAVE working group concluded its WGLC of
        > draft-ietf-behave-multicast-06 with no comments received.  I
        > would like
        > MBONED and MAGMA to please take a look at this draft prior to
        > its submission
        > to IESG.
        >
        > Please send replies to [email protected].  Thanks!
       
       
http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-06.txt:
       
        What if the NAPT or NAT device just passed IGMP queries and
reports
        through, changing only the source address of the reports, and
let the
        multicast router outside do all the hard work? I'm wondering
whether the
        IGMP aggregation function is mandatory in NAT/NATP.
       
        Bert
       
        _______________________________________________
        magma mailing list
        [email protected]
        https://www1.ietf.org/mailman/listinfo/magma