CARD: Proposal on remaining issues

Based on today's telephone conference and discussion about
remaining technical issues, we found and agreed on the
following solutions taken as a proposal to the WG.
Please find the summarized proposal below. If you have
any concerns or comments, please indicate.

Issue: "Handling of sequence numbers"
The proposal is to use the same sequence numbers for 
resent CARD Request messages, increase the sequence number
for new requests. Assumed a solicited CARD Reply is lost
on its way back to the requesting MN, a MN's current AR
must send the same CARD Reply again in case it receives 
a CARD Request carrying the same sequence number as the
previous request.

Issue: "Timeout and retransmission of signaling messages"
The following values have been agreed on for the proposal:

MN_AR_CARD_TIMEOUT: 1 sec.
MN_AR_CARD_RETRIES: 5
AR_AR_CARD_TIMEOUT: 300 ms
AR_AR_CARD_RETRIES: 2

Furthermore:
Change CARD_RETRANSMISSION_INTERVAL (current draft) to
CARD_REQUEST_RATE and set the value to 1 request/sec.
Drop CARD_MAX_RETRIES (as specified in the current draft).

Issue: "Storing Sequence numbers in AR's CAR tables"
Add a paragraph in section "Conceptual data structures",
which indicates, that MNs and ARs must maintain entries
for sequence numbers of latest received unsolicited
CARD Reply messages. 

Furthermore, MNs and ARs, in case of receiving both solicited
and unsolicited CARD Reply messages, should always consider the
latest/newest info received as valid info.

Issue: "Preferences and Requirements sub-option"
Keep both sub-options and use the recently proposed rule
to fill preferred capabilities' attributes into the Preferences
sub-option.

Issue: "Request IANA for L2 type IDs"
Change example types to be included with the CARD spec to
IEEE802.11a, IEEE802.11b, IEEE802.11g. Other technologies'
types should be requested in the future outside the scope
of the CARD spec, but controlled by IANA and dedicated experts.

Issue: "Address length in L2-ID sub-options"
Here, two opinions exist: Either, use the L2-type to 
specify the length of the subsequent L2-ID, or add a
further length field to the sub-option, which indicates
the real length of the subsequent L2-ID (more flexible, but
will have 2 length fields in the sub-option; one for the
entire option including padding bytes, another one for the 
L2-ID only).


Comments?  
 

marco