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

> >
> > Issue#17: Preferences/Requirements sub-option - One
> > of them is sufficient?
> > ---------------------------------------------------
> > Proposal is to keep both, since this implies just the definition of a
> > further sub-option type, which indicates
> > that only Attributes without any Data field will follow
> > in case of receiving a Preferences sub-option.
> > The Requirements parameter sub-option will carry then a
> > list of Attribute-Value pairs, the Preferences parameter
> > carries a list of Attributes (just the AVP Code and
> > Length, no Lifetime, no Data).
>
>
> one has to still implement both, right?
>
> I still think one of them is enough. I suggest removing the Requirements
> Sub-Option.
> it causes more harm than benefit. here is one example.
>
> lets assume none of the CARs were able to meet the MN's requirements.
> the CARD
> Reply returns empty. because of the MN's strict requirements, it loses
> connectivity.
> isnt that worse than picking a CAR with less capabilities? a local
> decision at the
> MN is better than the MN not getting any CARs.
>

Vijay,

The MN does not lose connectivity necessarily in the case you described.
It depends on the timing of the CARD Request/Reply in the handoff process.
If the requirements are something the MN can have flexibility on such as
bandwidth, the MN should send the query much earlier before the MN's old
link gets too weak.

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.

Filtering out CARs based on supported link types is an obvious example
showing the benefit of the Requirements sub-option.

Regards,

Eunsoo