Re: Preferences and Requirements Options (was Re: Proposal to resolve remaining CARD issues)

> > The MN does not lose connectivity necessarily in the case you described.
>
> what I meant, if there are no candidate ARs, the MN loses connectivity
> eventually.
>

If there is no candidate ARs supporting any link type available for the MN,
certainly the MN will lose connectivity. It is the case regardless of CARD
Request/Reply or the Requirements sub-option.
If the Requirements sub-option is used by the MN, the MN should consider
what it will do in the case the Reply is empty.

> > However, if the requirements are something in which there is no
flexibility
> > with the MN such as link type, the empty reply means there is no access
> > network supporting the link type. In the case, losing connectivity may
not
> > be unavoidable if the MN keeps moving far from the old access point/base
> > station.
>
> let the MN make the decision, if no CARs can satisfy its requirements.
> and you have the preferences options for the MN to tell the current AR
> what it wants.
>

Sending a Requirements sub-option is upto the MN, that is, the MN's
decision. It is not the current AR that decides the target AR even if the
Requirements sub-option is used. Certainly the Requirements should be
explicit and clear.
The need of Requirements sub-option arises because there could be many CARs
in the area. In the case, the CARD Reply may contain much information that
is not useful for the MN at all. It is waste of bandwidth and resources of
the MN.
The Preferences sub-option is used to specify what attributes of CARs should
be included in the CARD Reply while the Requirements sub-option is used to
specify what CARs should be included in the CARD Reply. So the two
sub-options have different roles.
Please let me stress that sending a Requirements sub-option is OPTIONAL to
the MN. The MN does not even have to support it if the developer decides so.

Eunsoo