RE: RE: [nemo] multiple CoAs registration

Soliman Hesham <[email protected]> Fri, 25 Jul 2003 04:07:24 -0400
Newsgroups gmane.ietf.mobileip
Message-ID <[email protected]>
 > >  > 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
 > 
 > 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