Subject: [nemo] multiple CoAs registration

From: Nicolas Montavont <[email-masked]>
Date: Thu, 17 Jul 2003 10:41:45 +0200

Hi Ryuji,

I read your draft on multiple CoAs registration and I also think that we 
really need to define a solution to use MIPv6 with a multiple interfaces 
MN.

Here are some comments on your draft:

   - Why do you introduce the interface identification (IFID) ? It could 
be sufficient to only register a CoA with the associated priority. 
Therefore, when the MN has to choose the destination address for a HoA, 
it can take the most preferred CoA, which is bound to the most preferred 
interface of the MN.

Anyway you use a one-to-one mapping between a CoA and a IFID, therefore 
you don't need both, or I missed a point ?

IMO, this is easier than all the mechanism to manage the IFID 
(generation, maintenance...)

   - If I well understand your draft, when the MN registers a CoA with a 
CN, the MN has to first register the primary CoA. Then it can send a 
Binding Update (after the RR procedure) to regsiter other CoA(s), with 
the associated priority. However, you say that the lowest priority is 
the preferred CoA/IF, and that the primary CoA has the priority 0. 
Therefore, each CN will use the primary CoA with the MN. Then, you are 
not able to perform load balancing, aren't you ?

   - Last point: If you return home with your primary interface (you 
connect to your home network with P-IF), do you have to de-register all 
CoA (P-CoA and NP-CoA) with both your HA and CNs (see section 7.8) ?

Regards,
Nicolas

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Jul 2003 19:31:43 +0100

> >Priority can be changed by some reason during communication, but IFID
> >can not be changed until MN want to change it.
> >
> Ok, I understand that. But what I mean is that I don't see the
> requirement to have the IFID... In the Binding Cache, an entry could
be
> identified by both the Home address and the CoA. It is sufficient to
> distinguish tow different entries. The priority field is then used to
> choose the CoA, i.e. the interface. No need to have the IFID I guess.

I believe we talked about that a lot already; there seems to be a
consensus on using the home address to identify uniquely a registration,
for checking and cleanup purposes. The IFID should not be used to that
purpose, and a registration should be able to migrate interface on the
MR side. If we do not find a valid usage for ifid (I have none in mind
at the moment) then it should be dropped, shouldn't it?

Pascal

---

From: Soliman Hesham <[email-masked]>
Date: Fri, 25 Jul 2003 03:30:09 -0400

> I don't think we have consensus on using the HoA to identify 
 > a binding.

=> We have a MIPv6 (RFC now!) that says that the HoA
is used to identify a binding in the binding cache.
So I'd say we have concensus on that.

 > There are advantages to use single HoA per MN and MR. 
 > Multiple HoAs allow nodes inside a mobile network to use 
 > multiple interfaces, but not MR.

=> Why not MR? 

Hesham

---

From: Soliman Hesham <[email-masked]>
Date: Fri, 25 Jul 2003 03:43:11 -0400

> I am talking about the case when multiple CoAs are bounded to a HoA.
 > When two bindings have same HoA, how do you identify each 
 > binding with same HoA?

=> By other attributes of that binding: CoA, CN's address, port nos, 
flow label ...etc

Hesham

---

From: Soliman Hesham <[email-masked]>
Date: Fri, 25 Jul 2003 04:07:24 -0400

> CoA can not be used to identify binding, because it is changed. 

=> That's why you need to send a new BU when you change CoA.
Just to be clear, we're talking about a sub-binding here. 
So whenever the attributes change, just like a normal binding, 
you send a new BU. You have to do that anyway when your
address changes.

 > I wrote some comments before (I replied to Nicolas)
 > 
 > maybe by filter information, but you can not identify two bindings if
 > MN does not have filter information. Filter information is not always
 > mandatory information. There are several approaches to maintain
 > filter information.

=> What do you mean by "filter information"? You mean
flow identifiers? 
I don't understand the problem you're trying to solve
I guess. The problem _I think_ we're solving here is how
to direct one or more connections to a particular interface.
So, to me, the obvious approach would be to map the connection
identifiers to a CoA which is directly mapped to an interface. 
This is good because all the information is contained in the 
packet, so a HA/CN can directly tunnel to the right
CoA. 
If you are discussing how the HA looks up that filtering
information and map it to the packet that is about to be
tunnelled to the MN, then this is an implementation issue
and is already done in routers today that do flow-based
traffic engineering. One way of doing this is to hash
the filter information and compare it with the information
in the received packet.

 > 
 > I prefer using ID to identify bindings and may associate filter
 > information with the IFID somewhere (maybe binding cache, maybe not).
 > This approach gives space for policy management and its
 > implementation.

=> The id can be used locally within the MN to allow
applications to pick an interface according to the
interface's attributes, instead of picking it based on 
a meaningless address. But I'm not sure I see the value 
of exchanging that over the wire.

Hesham