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

"Leymann, Nicolai" <[email protected]> Fri, 8 Jun 2007 11:44:43 +0200
Newsgroups gmane.ietf.mboned,gmane.ietf.nat.behave,gmane.ietf.magma
Message-ID <1E4CCB2441C5C0409AD8A929482A09F302AF4E46@S4DE9JSAAIG.ost.t-com.de>
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
	


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