Subject: RE: [Monami6] flow bindings are not for NEMO

From: "Benjamin Lim" <[email-masked]>
Date: Thu, 16 Nov 2006 15:08:50 +0800

Hi, 

> -----Original Message-----
> From: Andy Huang [mailto:[email-masked]]
> Sent: Thursday, November 16, 2006 1:55 PM
> To: Monami6 WG
> Subject: Re: [Monami6] flow bindings are not for NEMO
> 
> Hi, all
> 
> I think the problem should be considered separately in different 
> situations.
> The first one is the mobile network where there is the only MR which 
> has multiple paths to its HA, another one is the mobile network where 
> there is multiple MRs which have the only path to their HAs(HA).

[Ben] Unless I'm missing something, the only diference between the first and
second situation is that the second has an addition portion of default
router selection. By advertising egress info, it will definitely help in the
path selection for MNN in both situation. Multiple MRs can also be logcially
seen as a MR with mutiple paths to the Internet. Is there a reason for them
to be consider them separately?

Regards,
Benajmin Lim

I don't want to be involved in 
> the argument of the former situation, but as to the latter situation, 
> for example, imagining the scenario of (n,1,n) in 
> draft-ietf-nemo-multihoming-issues, MNNs could not decide which 
> address is more suitable for the specific service because of lack of 
> those MRs egress interface information.
> Even if there is a mechanism which allows MN to exchange preferences 
> with HA, VMN in such mobile network could not use the mechanism 
> because they don't know the corresponding wireless technology of these 
> CoAs at all. Considering this point, it is necessary for MR to 
> advertise egress interface information to MNN, at least it can help 
> VMNs to decide which CoA should be binded with flows or services. 
> What's more, as draft-ietf-nemo-multihoming-issues described, these 
> interface information can help default router selection and path 
> selection .
> 
> Any comments?
> 
> Best regards
> Zhigang Huang

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

---

From: Andy Huang <[email-masked]>
Date: Thu, 16 Nov 2006 16:13:58 +0800

Hi, Ben:

You are right. The difference is default route selection and source address 
selection.

The reason I want to separate them is that I don't know if it's so necessary 
to advertise MR egress information to MNNs in the first case. Considering 
the case of (1,1,1), even if mobile router has the different wireless path 
to HA, it's not clear to me if MNNs need to know these information. Perhaps 
MR can decide to use what kind of path for different data flow of MNNs by 
itself. However, in some cases, perhaps there is such a requirement for MNN 
to ask MR to use the specific wireless access technology to transport the 
MNN's data traffic, and MR could not perfrom flow binding with its HA for 
whole mobile network prefix. I don't know for sure now, perhaps it's a 
deployment issue.  And I think this is the point that Alex argued.

Anyway, it's useful to advertise the information in the second case. I think 
we have the same opinion on this point.

Best regards
Zhigang Huang

---

From: "Benjamin Lim" <[email-masked]>
Date: Thu, 16 Nov 2006 17:17:13 +0800

Hi Andy,

> Sent: Thursday, November 16, 2006 4:14 PM
> To: [email-masked]; Monami6 WG
> You are right. The difference is default route selection and 
> source address selection.
> 
> The reason I want to separate them is that I don't know if 
> it's so necessary to advertise MR egress information to MNNs 
> in the first case. Considering the case of (1,1,1), even if 
> mobile router has the different wireless path to HA, it's not 
> clear to me if MNNs need to know these information. 
[Ben] Well, if they are different access characteristics (E.g 802.11b and
802.11g), its good to let MNN know so as to allow it to know that MR can
support different throughput.

> Perhaps MR can decide to use what kind of path for different data 
> flow of MNNs by itself. 
[Ben] Yes, but that means that MNN cannot perform flow binding in the mobile
network as flow path.

> However, in some cases, perhaps there 
> is such a requirement for MNN to ask MR to use the specific 
> wireless access technology to transport the MNN's data 
> traffic, and MR could not perfrom flow binding with its HA 
> for whole mobile network prefix.
[Ben] Well, one solution I see is for a MR to perform flow binding for a
whole MNP, is that it can partition the MNP into smaller prefixes of smaller
address range and map each of them to the various egress path of MR.

> I don't know for sure now, 
> perhaps it's a deployment issue.  And I think this is the 
> point that Alex argued.
> 
> Anyway, it's useful to advertise the information in the 
> second case. I think we have the same opinion on this point.
[Ben] Yes, but I also feel its useful in the first case.

Regards,
Benjamin Lim

---

From: Andy Huang <[email-masked]>
Date: Thu, 16 Nov 2006 19:25:07 +0800

Please see my comments below.

Best regards
Zhigang Huang

----- Original Message ----- 
From: "Benjamin Lim" <[email-masked]>
To: "'Andy Huang'" <[email-masked]>
Cc: "'Monami6 WG'" <[email-masked]>
Sent: Thursday, November 16, 2006 5:17 PM
Subject: RE: [Monami6] flow bindings are not for NEMO

> [Ben] Yes, but that means that MNN cannot perform flow binding in the 

There is a problem here.
Consideration the mobile router which has multiple wireless interfaces to
access the network:
In case of (1,1,1), VMN has only CoA so there is no flow binding at all.
In case of (1,1,n) or (1,n,n), it's useless for VMN to send flow binding to
its HA though VMN has multiple CoAs, because these CoAs may not correspond
to MR's different wireless interface. Even if MR has advertised the egress
interface information to VMN, VMN don't know how to prefrom flow binding
still.

So the point here is not how VMN performs flow binding, but how MR performs
flow binding. If there is such a requirement that VMN or LFN really need to
specify the wireless technology for specific flow, maybe MR can use
Destination Address field to define filter rules and set the Destination
Address to the CoA of VMN or address of LFN. Definitely, such requirement
need MR advertising the egress interface information.

---

From: "Benjamin Lim" <[email-masked]>
Date: Fri, 17 Nov 2006 10:01:01 +0800

Hi Andy, 

[/snip]
> > [Ben] Yes, but that means that MNN cannot perform flow 
> binding in the 
> > mobile
> > network as flow path.
> 
> There is a problem here.
[Ben] As I mention in the previous mail, since MR has n MNPs, its possible
to map each MNP to a different interface of MR. Then in addition to MR
advertisng egress info, MR can also advertise these mapped MNPs so as to
allow VMN to perform flow filtering. If VMN wants a flow to go through a
particualar MR's interface, it can use the chosen mapped MNP to configure a
CoA and bind this CoA with its HA for flow filtering.

Regards,
Benjamin Lim
 
> > whole MNP, is that it can partition the MNP into smaller 
> prefixes of 
> > smaller

---

From: Andy Huang <[email-masked]>
Date: Fri, 17 Nov 2006 10:46:59 +0800

Hi, Ben

I understand what you mean, and now our discussion has got to the specific 
scenario.

I think what you said is one of the deployment cases. In fact, it's possible 
that MR has multiple different wireless interfaces but has not multiple 
MNPs. Even if MR has multiple MNPs, it doesn't mean that MR MUST map these 
MNPs to different egress interfaces. MNP is used for ingress interface, not 
for egress interface.

So the requirement of advertising egress information should be considered in 
different scenarios. I guess it's not totally necessary in some cases.

Best regards
Zhigang Huang

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 19 Nov 2006 11:00:18 +0100

Benjamin Lim wrote:
> Hi Andy,
> 
> [/snip]
>>>> Perhaps MR can decide to use what kind of path for different 
>>>> data flow of MNNs by itself.
>>> mobile network as flow path.
>> There is a problem here. Consideration the mobile router which 
>> has multiple wireless interfaces to access the network: In case 
>> of (1,1,1), VMN has only CoA so there is no flow binding at all.
>>  In case of (1,1,n) or (1,n,n), it's useless for VMN to send flow
>>  binding to its HA though VMN has multiple CoAs, because these 
>> CoAs may not correspond to MR's different wireless interface. 
>> Even if MR has advertised the egress interface information to 
>> VMN, VMN don't know how to prefrom flow binding still.
>> 
> [Ben] As I mention in the previous mail, since MR has n MNPs, its 
> possible to map each MNP to a different interface of MR. Then in 
> addition to MR advertisng egress info, MR can also advertise these 
> mapped MNPs so as to allow VMN to perform flow filtering. If VMN 
> wants a flow to go through a particualar MR's interface, it can use
>  the chosen mapped MNP to configure a CoA and bind this CoA with
> its HA for flow filtering.

Makes sense, partially: VMN chooisng to autoconf an address from an
MNP that corresponds to an MR egress interface the VMN may prefer.
Not sure though the VMN's HA flow bindings make much sense, because
the MR's HA flow bindings will take precedence (MR's HA encapsulation
comes over VMN's HA encapsulation.  There'd still be a need for
MR to be somehow auth'zed for applications that run on VMN.

Alex