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

Brian:

 

My e-mail was not an answer to Albert, sorry for that, 

 

It is an idea regarding the BEHAVE Internet Draft and how the multicast NAPT can allow outside multicast routers to uniquely identify different multicast SSM channels (S,G) coming from inside interfaces in the case two inside interfaces use the same multicast group.

 

In the BEHAVE draft, REQ-4, if there is a host on the inside interface sending UDP packets to a multicast group, the NAPT can change the source address and the port but not the multicast group address. In this way, I think the outside routers can not differentiate the two channels because they have the same source (the public interface) and the same multicast group address.

 

Allowing the NAPT to change the multicast group address in the case two sender behind the NAPT use the same group address in a similar way the NATP changes a UDP port is a possible solution. There are other possibilities.

 

Regards


Alvaro


________________________________

De: Brian Haberman [mailto:[email protected]]
Enviado el: mié 06/06/2007 16:06
Para: Alvaro Fernandez
CC: Manfredi, Albert E; [email protected]; [email protected]; [email protected]
Asunto: Re: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt



Alvaro,
     I am not sure what problem this solves.  Alfred's comments had to
do with receivers behind the NAPT sending Report and Done messages that
had to be aggregated at the NAPT in order to avoid having the external
router stop the multicast stream.  What you describe *appears* to put
the senders behind the NAPT.  Could you elaborate on what your concern is?

Regards,
Brian


Alvaro Fernandez wrote:
> 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.
>
> 
>
> 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.
>
> 
>
> Best Regards
>
> 
>
> Alvaro
>
>
> ------------------------------------------------------------------------
> *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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> magma mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/magma

_______________________________________________
magma mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/magma