Subject: [Seamoby] [CARD Technical Issue] Dropping FMIPv6 piggybacking

From: "James Kempf" <[email-masked]>
Date: Tue, 1 Jul 2003 14:32:57 -0700

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-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 02 Jul 2003 12:44:08 +0200

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Jul 2003 08:45:47 -0700

Marco,

What I specifically had in mind by "complex" was this.

Suppose CARD was defined to just work with FMIP. Then there would be no need
for setting the flag and sending an initial CARD Request/CARD Reply to
determine if piggybacking was supported. The MN would simply use FMIP, and
if the AR didn't return anything, it would know that the AR is not CARD
capable. This is very simple.

Now, suppose that piggybacking was not supported. The MN sends CARD Request
and if it gets a CARD Reply it knows that CARD is supported, it can use the
CARD protocol. This is also very simple (though more complex than the FMIP
case because there are two protocols instead of one).

With the current design, the MN must negotiate and choose which to use.
Perhaps "complex" was too strong a word, but it is an extra bit of protocol
that could be simplified.

            jak

PS: I still believe that interoperability with FMIP is desirable, but I
think its more important now to simplify things to reduce the chances of the
draft getting caught in the IESG's lint filter. I would like to see this
draft sail through the IESG.

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 02 Jul 2003 18:08:42 +0200

James,

I see, but I am not sure if a "try-and-error" mechanism for discovery is
much better, in particular since this procedure needs to be performed
with each AR the MN attaches to, right?
This is simpler with the current mechanism, since the MN knows in advance
if it will suceed with performing CARD via FMIP or not with its next AR.
If not, then the MN can use the stand-alone CARD mechanism. In your example
it should be distinguished between "piggybacking capable" and "CARD capable"
nodes. Only the first support can be identified with the P-flag.

marco

James Kempf wrote:

>>>unnecessary. For simplicity, I think we should do one or the other.
>>>      
>>>
>Though I
>  
>
>>>handover more complex. Since the DT and WG don't seem to agree, I believe
>>>      
>>>
>we
>  
>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Jul 2003 15:11:21 -0700

> nodes. Only the first support can be identified with the P-flag.

OK, I think I see your point.

We've decided not to allow piggybacking in CTP, though it might be useful
later. It would be good if we could at least have *some* consistency between
the two protocols (after all, they are coming out of the same WG).

I still think it would be good to leave it out, for simplicity. Maybe we
could put a statement in saying "Whether or not to piggyback CARD on other
protocols should be allowed is a research question open for experiment." I
think there will be some amount of experimentation and consolidation when we
finish with CARD, to establish good interoperability with other protocols.
This is not likely to be the only place where better interoperability is
required.

            jak