Subject: [nemo] Re: [Monami6] flow bindings are not for NEMO

From: Andy Huang <[email-masked]>
Date: Wed, 15 Nov 2006 10:46:48 +0800

Hi all:

The problem is interesting, but I think it is not only for MR which has 
multiple paths to HA, but for the 'simple' MR which has just one paths to 
HA. Let's suppose there are multiple MRs in the mobile network and every MR 
uses the different wireless interface. It's also important for MR to inform 
MNNs of egress interface information. These information will help MNNs to 
decide default router selection and source address selection, consequently 
decide uplink and downlink path selection. On this point, maybe this problem 
is more NEMO-sepcific.

Best regards

----- Original Message ----- 
From: "RYUJI WAKIKAWA" <[email-masked]>
To: "Monami6 WG" <[email-masked]>
Cc: "Soliman, Hesham" <[email-masked]>
Sent: Wednesday, November 15, 2006 9:40 AM
Subject: Re: [Monami6] flow bindings are not for NEMO

> Hi George and All
>
> The problem here is important one for the scope of flow distribution.  It 
> is not related only to flow binding.
>
> In MIP6, the mobile node has multiple interfaces and can distribute  flow 
> to multiple paths.
> However, in the NEMO case, intermediate node (i.e. MR) has multiple  paths 
> to HA.
> Since this is NEMO, end node is not aware of multiple paths between 
> MR-HA. (No RO and intermediate router, MR).
>
> Therefore, it is no way for LFN/MNN to know what kind of paths which  MR 
> manages.
> As a result, there is no way for LFN/MNN to tell the preference to MR 
> (since LFN cannot know the paths condition of MR).
>
> If Monami6 wants to support end-end policy exchange in general, NEMO  is 
> very special scenario.
> We need additional schemes such as:
> - MR advertises the egress interfaces info.
> - LFN updates its preference to MR.
>
> Of course, we have to consider some race condition of filter in MR,  if 
> large number of LFN update their preference.
> I mean all the LFN may request WiMAX for all traffic instead of using  3G. 
> This is not desirable scenario.
>
> To me, these feature needs a lot of work.
> Within the current charter, we should stick to the static case for NEMO.
> Then, we may think of above feature when the Monami6 finish the  current 
> charter items.
>
> regards,
> ryuji
>
>
>
>
>
>
>
> On 2006/11/15, at 2:37, Alexandru Petrescu wrote:
>
>> Tsirtsis, George wrote:
>>> Alex,
>>> Based on the discussion below we should be able to agree on the 
>>> following:
>>> Flow Binding works for NEMO as long as the MR can control the
>>> process e.g., based on generic or LFN/MNN specific configuration in
>>> the MR. There is additional work that may need to be done if one
>>> wants an MNN/LFN to dynamically request certain behavior from the
>>> MR.
>>> Is this a fair statement?
>>
>> Yes.
>>
>> Alex
>>
>>> George
>>>> -----Original Message----- From: Alexandru Petrescu
>>>> [mailto:[email-masked]] Sent: Tuesday, November
>>>> 14, 2006 11:02 AM To: Monami6 WG Cc: Soliman, Hesham Subject: Re:
>>>> [Monami6] flow bindings are not for NEMO
>>>> Tsirtsis, George wrote:
>>>>> But Alex, this happens already in the internet. Routers load  balance 
>>>>> traffic on behalf of end nodes every day and the end
>>>>> nodes are not involved.
>>>> This is fixed end nodes, not mobiles, with homogeneous links -
>>>> almost always stable.
>>>> It is also a model where ISP routers load balance traffic, and 
>>>> subscribers pay for higher quality of service.  In smallest NEMO 
>>>> contexts (PAN) there wouldn't be such relationships between MR
>>>> and LFN - both would be owned by same person.
>>>>> In a lot of NEMO applications this is still likely to be  sufficient.
>>>> Ok.
>>>>> What you are arguing for is a *new* thing, with which an end
>>>>> node can instruct a router on how to route its traffic.
>>>> Best effort routing should happen without end host involvement.
>>>> But appreciative routing (load balancing, traffic shaping,

>>>> whatever) are for end host.
>>>>> I would argue that this is separate and thus out of scope of
>>>>> the basic functionality needed for MHs/MRs for flow bindings.
>>>> You seem to say not only out of scope, but also MRs have the
>>>> right to load-balance regardless of LFNs' preferences; and you
>>>> seem to agree NEMO already does that for the prefix.
>>>> I agree out of scope.
>>>> I don't agree MRs should ever load balance on behalf of LFNs
>>>> without proper authorization.
>>>> I don't agree MR does anything insecure for MNP (HA prohibits it)
>>>> and hence it shouldn't be allowed to do anything insecure for
>>>> flows
>>> either.
>>>> We may turn in circles :-)
>>>> Let's look at the looping problem: what do MH's preferences
>>>> become when connecting to a MR?  If a WimAx-WiFi MH prefers WiFi
>>>> for http and the WiMax-WiFi MR prefers WiMax instead, and MH
>>>> connects through WiFi to MR doesn't this translate into MH using
>>>> WiMax for http, despite its preference being WiFi?
>>>> I think we should not claim flow bindings are for NEMO.
>>>> Alex
>>>> _______________________________________________ Monami6 mailing
>>>> list [email-masked] https://www1.ietf.org/mailman/listinfo/monami6
>>> _______________________________________________ Monami6 mailing
>>> list [email-masked] https://www1.ietf.org/mailman/listinfo/monami6
>>
>>
>> _______________________________________________
>> Monami6 mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/monami6
>
>
> _______________________________________________
> Monami6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/monami6
>