Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- Phase CT

From: James Kempf <[email-masked]>
Date: Wed, 11 Jul 2001 08:47:03 -0700 (PDT)

Hi Pat,

>well, the IESG has already stated that their desire was to NOT tie 
>CTP to MIP (and if memory serves, that was your position until just
>recently too). There are other mobility management protocols out there,
>and I'd hate to see them have to ignore CTP just because it is part of
>the MIP baggage. 
>
>Further, what are the benefits? Sending a single packet, as opposed to two?
>Where's the benefit there? I can have two threads work separately in
>transmitting the MIP and CT packets. That would reduce the number of locks
>required, and introduces modularity. Great benefits IMHO.
>

I think there may be some benefits to linking CT with the handover
messaging. 

If you send the context and the mobility protocol handover messaging in separate 
packets, you generate a synchronization problem on the new AR. Furthermore,
you increase the risk that a packet could be delayed or lost, disrupting
the handover. Suppose that the packets arrive out of order, that is, the CT 
packet arrives before the handover messaging. The AR must then arrange to buffer 
and potentially drop the CT packet if no handover messaging arrives within
a certain interval. The resulting implementation on the AR becomes more
complex, and thus subject to potential failure in more places.

Note here that I've said "the mobility protocol", not MIP. I think it
should be possible to define the CT messaging so that it is independent
of MIP but still can be added to a mobility protocol as an  extention,
with a binding to that particular mobility protocol. I can easily see
how it might work with the network assisted FMIP extensions, and potentially
also with (excuse my language) GPRS, as much as I know about it. 

		jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 11 Jul 2001 11:15:47 -0700

Hello,

I agree that there is much to gain from doing CT _with_ handover signaling. In
fact, I have raised this issue of potential state inconsistency (what James calls
synchronization problem below) a *few times* already in the mailing list. However,
the value of CT should not be tied to MIP handovers alone. So, the way to make use
of CT for MIP handovers is to separate the feature contexts from the actual
signaling messages. This is outlined in draft-koodli-seamoby-ctv6-00.txt.

Regards,

-Rajeev

---

From: "Kulwinder Atwal" <[email-masked]>
Date: Thu, 12 Jul 2001 03:21:37 -0400

Also, depending on round trip times between parentAR and oldAR/newAR, the
oldAR may not need to forward packets for the MN (FMIP).

If the signalling delay is a few microseconds or milliseconds, the parentAR
may switch the forwarding path first, followed by the oldAR/newAR/MN
performing CT.

I think we need to allow for this by not linking CT to IP level handover of
a particular mobility solution.  The establishment of the new forwarding
path by the parentAR could be used as a Trigger to start CT.

- Kulwinder.

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 11, 2001 2:15 PM
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu
lti- Phase CT

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 13 Jul 2001 12:32:40 -0700

> signaling messages. This is outlined in draft-koodli-seamoby-ctv6-00.txt.

ok, finally got around to reading it. This is interesting because it
doesn't require CT to be tied to MIP, but allows it to be carried in
the same packet. I wonder, though, what the IESG would think about
the use of ICMP for CT. I know that they *really* frown upon UDP for
CT, so I wonder what their thoughts would be.

PatC

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 13 Jul 2001 16:11:05 -0700

Hello Pat,

> CT, so I wonder what their thoughts would be.

Rajeev: We describe carrying contexts in ICMP because HI/HAck are ICMP messages. One of
the principles outlined in the draft is to separate a context defintion (and its
subsequent packet format) from the signal that carries it. We have shown how it can be
done for FMIPv6. We think that the context packets could be carried in other forms of
messages as well.

Thanks for the comments.

-Rajeev