|
List Info
Thread: FW: WGLC: draft-ietf-behave-multicast-06.txt
|
|
| FW: WGLC:
draft-ietf-behave-multicast-06.txt |
 
United States |
2007-06-06 09:06:29 |
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:albert.e.manfredi boeing.com]
> *Enviado el mar
05/06/2007 16:02
> *Para behaveietf.org;
mbonedietf.org; magmaietf.org
> *Asunto [magma] RE:
[MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt
>
>> -----Original Message-----
>> From: Dan Wing [mailto:dwingcisco.com]
>> Sent: Monday, June 04, 2007 7:38 PM
>> To: mbonedietf.org; magmaietf.org
>> 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 behaveietf.org. Thanks!
>
> ietf.org
> https://
www1.ietf.org/mailman/listinfo/magma
>
>
>
------------------------------------------------------------
------------
>
> _______________________________________________
> magma mailing list
> magmaietf.org
> https://
www1.ietf.org/mailman/listinfo/magma
_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave
|
|
| FW: WGLC:
draft-ietf-behave-multicast-06.txt |
 
Spain |
2007-06-06 09:59:15 |
|
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:brianinnovationslab.net]
Enviado el: mié 06/06/2007 16:06
Para: Alvaro Fernandez
CC: Manfredi, Albert E; behaveietf.org; mbonedietf.org; magmaietf.org
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 [ albert.e.manfrediboeing.com">mailto:albert.e.manfrediboeing.com]
> *Enviado el mar 05/06/2007 16:02
> *Para behaveietf.org; mbonedietf.org; magmaietf.org
> *Asunto [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt
>
>;> -----Original Message-----
>> From: Dan Wing [ dwingcisco.com">mailto:dwingcisco.com]
>> Sent: Monday, June 04, 2007 7:38 PM
>>; To: mbonedietf.org; magmaietf.org
>> 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 behaveietf.org. 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
> magmaietf.org
> https://www1.ietf.org/mailman/listinfo/magma
>
>;
> ------------------------------------------------------------------------
>;
> _______________________________________________
> magma mailing list
> magmaietf.org
> https://www1.ietf.org/mailman/listinfo/magma
|
[1-2]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|
