Re: RE: [nemo] multiple CoAs registration

Soliman Hesham wrote:

> > >  > 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.
>
This is what we use in our draft.
An entry is identified by the HoA plus the associated filter of the flow 
(which is a port number and/or CN address)
This entry gives the CoA to use. No need to have an interface ID. By 
this way, we can either filter flows or perform redirection between 
interfaces.

Nicolas

>
> > 
> > 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
>  
>