Re: Re: CARD: Storing sequence numbers in ARs' CAR table?

Henrik,

My comments are inline.

> > > There is a similar problem is in the MN-AR protocol, with the ordering
of
> > > solicited and unsolicited replies. A new field in the MN-AR CARD
message
> > > header is _probably_ needed for sequence number, if strict ordering is
a
> > > requirement.
> > >
> > [eunsoo] There is already the sequence number field in the headers of
CARD
> > Request and Reply. Do you suggest any other field?
>
> Actually the problem in MN was more complex than I had thought: MN can get
> unsolicited CARD replies from multiple ARs and the information in ARs
> about CARs is not synchronized.

In most cases, a MN will have a single current AR and therefore it will
receive CAR info only from the current AR. But in multi-homing cases, a MN
can have multiple "current ARs", in which case, your point is right.

> It seems that a per-CAR sequence number /
> timestamp is needed in AR-MN reply for ordering to work.
>
This problem occurs because there can be multiple information distribution
channels and scenarios. For example, one attribute value can be updated
between two ARs using Request/Reply while another attribute value can be
updated via the Unsolicited Reply.To enforce strictive synchornization or
ordering of information, we would need timestamp for each attribute
including the IP address and MAC address. This seems creating lots overhead.

> A potential solution is to include the original sequence number from the
> AR-AR CARD reply message header (not reply option) in some field for each
> CAR, e.g. in the capability container suboption, in the MN-AR CARD reply.
> Provided that the CAR increases the sequence number for every AR-AR CARD
> message it sends, this should work. The sequence number handling might
> need to work with wrap around, though.
>

As mentioned in the above. just copying the original sequence number may not
work because the original sequence numbers for Solicited Reply and
Unsolicited Reply would be relevant. Again, every Reply should have a
timestamp(or sequence number) of the (Reply) sender and it should be copied
for each attribute value separately for strict ordering.

I'd like to suggest a very simple approach instead of the strict information
synchronization or ordering.
How about letting the MN use the following simple policy?
1) First, it takes Unsolicited Reply only from the default router (one of
the multiple current ARs in the case of multihoming).
2) Second, it gives higher priority on the more recent information if it is
from the same sender (not the original source) --- In this case, the order
is determined by the sequence number for Unsolicited Replies. If the MN
receives Unsolicited Reply and Solicited Reply from the default router, it
takes more recently received information.
3) Third, if the MN sent inquiry (Request) to multiple ARs, it takes the
most recently received information (Reply).

Certainly this approach opens a (little) chance that the MN may NOT get the
most up-to-date information. However, since we don't make sure the ARs
synchronize their information in hard real-time, such a chance exists
anyway. So inserting timestamp for every attribute value may not be
justified by the gain compared to its cost.

What do you think?

Eunsoo