Subject: Re: [Mobopts] New ID: Multicast Mobility in MIPv6: Problem Statement]

From: Thomas C Schmidt <[email-masked]>
Date: Fri, 02 Mar 2007 14:37:22 +0100

Hi Zhigang,

many thanks for the review!

Andy Huang wrote:

> I reviewed your draft and it's really a good job, especially you 
> referred to a great number of references. Here ars some comments.
> 
> Section 2.3.1
>   "For application transparency the logical node identifier,
>   commonly the HoA, must be presented as packet's source address to the
>   socket layer at the receiver side."
> 
> I doubt about it. For the receivers using ASM, it's possible that they 
> need not care about the IP source address.
>
Yes, you are right. Actually, this is application dependent. There are 
UDP applications, which do not care about source addresses. However, 
many do, especially if they use RTP-Stacks (IP Source is part of the RTP 
session definition). A couple years ago we tested quite a number of 
applications regarding their behaviour on source address changes: most 
of them did react sensitive, some with error messges, some with real 
application errors.

So that's why we stated that a network multicast service should preserve 
address transparency, even if UDP sockets allow for address changes in 
general.

> Section 4.1
> "triangular routing"
> This term is introduced in MIPv4, to describe data flow path between MN 
> and CN. The data packets from CN to MN must pass through HA but data 
> packets from MN to CN can be forwarded directly. It forms a triangle. 
> It's not like this in multicast cases. I suggest using other words such 
> as inefficient routing to replace it. But it's not a big problem.
> 
:-), that's a minor formulation thing: some people (like us) call 
routing triangular, if it is not direct (an open triangle) ... some, 
linke in MIPv4, have a closed triangle in mind.
Anyway, it's clear though, I guess ....

> See you in Prague.

Yes: looking forward to further discussions

Thomas

>> -------- Original Message --------
>> Subject: [Mobopts] New ID: Multicast Mobility in MIPv6: Problem Statement
>> Date: Thu, 01 Mar 2007 22:32:21 +0100
>> From: Thomas C Schmidt <[email-masked]>
>> Reply-To: [email-masked]
>> To: mobopts <[email-masked]>,  [email-masked], Mip6 <[email-masked]>,
>>  [email-masked],  [email-masked]
>>
>> Hi all,
>>
>> we submitted an updated version of the problem statement
>> draft on extending Multicast to Mobility.
>>
>> It should be in the ID directory soon and can immediatly be downloaded
>> under:
>>
>> http://www.realmv6.org/papers/draft-schmidt-mobopts-mmcastv6-ps-02.txt
>>
>> Details:
>>
>>
>>               Multicast Mobility in MIPv6: Problem Statement
>>                   <draft-schmidt-mobopts-mmcastv6-ps-02.txt>
>>
>> Abstract
>>
>>     In this document we discuss mobility extensions to current IP layer
>>    multicast solutions. Problems arising from mobile group communication
>>    in general, in the case of multicast listener mobility and for mobile
>>    Any Source Multicast as well as Source Specific Multicast senders are
>>    documented. Characteristic aspects of multicast routing and
>>    deployment issues are summarized. The principal approaches to the
>>    multicast mobility problems are outlined subsequently.
>>
>>
>> The new document contains a number of clarification & language fixes and
>> has been extended to include
>>
>>  o further routing issues, especially bi-directional PIM;
>>  o additional approaches to a solution of mobile multicast tasks;
>>  o further references;
>>  o all major comments from reviewers.
>>
>>
>> As it seems desirable to advance on the subject, we'd like to emphasize
>> solicitation of comments & reviews ...
>>
>> Looking forward to your discussions!
>>
>> See you in Prague,
>>
>> thomas
>>
>>
>>
>>
>>
>> -- 
>>
>> ° Prof. Dr. Thomas Schmidt
>> ° HAW Hamburg, Dept. Informatik
>> ° University of Applied Sciences
>> ° Berliner Tor 7, D 20099 Hamburg
>> ° Germany, Fon: +49-40-42875-8157
>> ° http://www.informatik.haw-hamburg.de/~schmidt
>>
> 
> 

_______________________________________________
Mobopts mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts

---

From: Thomas C Schmidt <[email-masked]>
Date: Sun, 18 Mar 2007 20:34:52 +0100

Hi Kevin,

thanks a lot for the comments:

Kevin C Almeroth wrote:
> Okay, I took a brief look...  so other than some work on the
> grammar (which I can help with if you need it), 

mhmm, we should be able to fix this ... but are very grateful for any 
pointer or hint.

> I think the
> major improvement would be to strengthen what you/we/mobopts
> thinks are the major things that need to be considered in
> designing a mobile multicast solution.
> 

Yes, you're right: there is no roadmap or working perspective, yet.
This is what we should discuss in the meeting next week: up until now we 
tried to identify/describe the problem and the solution space as clearly 
as possible, no conclusions from that.

> Some additional thoughts:
> 
> 1.  Multicast, as it turns out, has been tremendously successful.
> Not as a ubiquitous, public Internet IP service, but as a 
> private, enterprise-based service.   What this says is that
> individual wireless/mobile networks will need to provide wireless,
> but the need to connect to a global infrastructure may be somewhat
> limited.
> 
Yes and perhaps, I'd like to state ;) Interdomain ASM suffers from 
technical complexity and there is reasonable anxiety to promote DDOS by 
offering ASM beyond site limits. This may change with SSM and there are 
many attempts to establish group distribution services on the 
application layer ... so there is a need.

> 2.  One of the problems why mobile multicast hasn't taken off is
> that there isn't a need...  yet.  Furthermore, there really isn't
> really mobile networking taking place, at least not with seamless
> handovers.  Do you have any experience with anyone running a
> real MIPv6 deployment?  If such a deployment doesn't exist and
> seamless handovers don't exist, what is the need for seamless
> multicast handover?  

Yes, this is a hen/egg problem. But we are all optimistic to see 
seamless (F/M-)MIPv6 services spread ...
... but you're right: just returned from Cebit I saw tunnel-based 
mobility proposals/prototypes aiming just to avoid mobile IP.

> Maybe we should start with something
> simple, which is just a multicast solution that works in 
> wireless networks.  Sure, existing protocols work, but are
> there things that should be changed to better support multicast?
>

D'accord - this most likely is the attempt of a deployment-centric step 
following the problem statement.

> I'm sorry I won't be in Prague to see the presentation...  I
> think there is a real opportunity to do something valuable here
> (as opposed to a solution that looks good on paper but no one
> cares about or deploys).
> 

Thanks - we'll try our best ...

See you in Copenhagen then

thomas