Re: [CARD Technical Issue] Dropping FMIPv6 piggybacking

James,

it's not a complex negotiation using specific protocol messages,
its discovery by means of setting a flag to indicate to
communication peers the sender's capability to convey CARD signaling
with the FMIP protocol sequence between MN and AR. Now, this indication
is needed for MNs and ARs to learn about whether or not CARD message
options can be appended to RtSolPr and PrRtAdv messages.

Performing CARD, the MN knows already in advance if subsequent 
CARD signaling messages can be appended to FMIP signaling, so, no
explicit discovery of piggybacking capability is required.

To keep FMIP operation in mind when designing the CARD protocol
was advice from the beginning. Now, to not restrict CARD to
FMIP was also discussed here, which is a reasonable design goal.
Why not keeping this flexible and use CARD with FMIP if supported,
otherwise use CARD protocol operation stand-alone by means of
appending the CARD signaling to the specified CARD main header.
Btw., latter approach should be the default operation.

marco
 



James Kempf wrote:

>Section 4.5 describes a negotiation between the MN and AR to determine
>whether CARD is piggybacked on FMIPv6. This negotation seems complex and
>unnecessary. For simplicity, I think we should do one or the other. Though I
>favor piggybacking because it simplifies the entire handover across both
>protocols, requiring the MN to negotiate whether to use FMIPv6 makes the
>handover more complex. Since the DT and WG don't seem to agree, I believe we
>should drop FMIPv6 piggy backing.
>
>            jak
>
>
>_______________________________________________
>Seamoby mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/seamoby
>  
>