List Info

Thread: FW: WGLC: draft-ietf-behave-multicast-06.txt
FW: WGLC: draft-ietf-behave-multicast-06.txt
country flaguser name
Spain		 2007-06-06 12:23:54 

  


  

    



Brian:


 


1. How prevalent do people expect the scenario of a SSM sender being
located behind a NAPT?


 


People like to upload content: wikipedia, youtube, blogs, P2P, … Actually they can not upload multimedia content in real time.


 


I think that if people can upload multicast data in real time they will do it. For example: Mobile + camera + multicast = personal IPTV 


 


2. Is it possible for the NAPT to have multiple external addresses to use as source addresses?


 


The external source address is only one. What I suggest is to change the multicast group address so each multicast channel is unique.


 


We can make a reservation of SSM multicast addresses for this purpose. If the NAPT detects that a multicast group in this range is used the NAPT understands that it can changes the multicast address to be unique if it is necessary.


 


3. From the global perspective, how does a receiver outside the NAPT know the (S,G) combination to join?


 


This is the problem.


 


P2P programs have a similar problem when locating “peers” behind NATs and there are solutions that we can imitate: DHT (dynamic hash tables), “superpeersR21;, “torrent” files, …


 


Another solution can be to identify each channel with some metadata including description of the content and use “multicast search engines221; to access the desired channel in a similar way of how we actually access websites. 


 


It’s a problem but there are solutions. I think we can leave the solution of this problem to the specific application that uses the multicast channel data. 


 


Regards


 


Alvaro






De: Brian Haberman [mailto:brianinnovationslab.net]
Enviado el: mié 06/06/2007 18:22
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 Fernandez wrote:
>; 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.
>;

How prevalent do people expect the scenario of a SSM sender being
located behind a NAPT?

>; 
>;
> 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.
>

Is it possible for the NAPT to have multiple external addresses to use
as source addresses?

> ;
>
> 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.

From the global perspective, how does a receiver outside the NAPT know
the (S,G) combination to join?

Regards,
Brian


  

  
  
   
     
    






 [1]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )