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