Subject: RE: FW: [mobile-ip] Times for Low-Latency IPv6 Handoff

From: James Kempf <[email-masked]>
Date: Wed, 16 May 2001 09:36:32 -0700 (PDT)

Hi Raj,

>If the traffic is real-time data, the traffic channel consists of
>signaling and RT bearer simultaneously. So at the transport layer
>(DCH) consists of 3.4 Kbps for signaling as well as 12.4 for AMR (max
>data rate). So the MIP signaling should be carried over the 3.4 kbps
>channel and as a result will not interrupt the traffic. So if you
>look at section 6.2.1 (Harri's book) at paragraphs 1 & 2, you will
>realize that.
>

Interesting, thanx. Looks like it is possible to multiplex signalling
and real time data on a single logical channel that maps to multiple
physical channels. However, it is still not clear from  this whether the 
signalling is restricted to NBAP/wCDMA signalling or whether IP
signalling would work. In principle, I think it *could* be done if
it isn't currently. Of course, there would need to be some way to distinguish
which IP packets were signalling and which not (probably by port number?).

>>If it were possible to do the MIP signalling on a signalling channel,
>>one could get the kind of parallelism described here, 
>
>You actually can get that parallelism via the multiplexing feature of
>DCH. 

Agreed.

>The current draft does allow this. What I mean is that the MN can
>continue to use it's old COA at the new AP, if it did not receive an
>ACK from the handoff signaling.
>

Section 5.2 on pg. 33 of draft-ietf-mobileip-fast-mipv6-01.txt talks about a 
unidirectional tunnel from old AR to new AR but nothing about a reverse tunnel. 
If there is no reverse tunnel in place, new AR can drop MN's packets
with the old CoA because old CoA is not topologically correct
in new AR's subnet, if egress filtering is on (as I would expect
it to be, to prevent bogus MN from establishing service). Consequently,
old AR forwards packets to new AR, who buffers them, but the real time
stream still stalls because MN can't get any packets out. 

Also, it is furthermore unclear whether new AR is allowed to send packets
to MN prior to MN sending a Neighbor Advertisement or Fast Neighbor
Advertisment to new AR. Exactly how and when NA or F-NA is used seemed
also somewhat murky to me. It is not shown on the timing diagrams
for the protocol, for example, though it is discussed in Section 5.3.

		jak

---

From: Michael Thomas <[email-masked]>
Date: Thu, 17 May 2001 09:02:10 -0700 (PDT)

> which IP packets were signalling and which not (probably by port number?).

Er, uh, why couldn't this be done with normal IP
and L2'ism?  If the L2 provided a transport
vehicle for IP datagrams, all of the normal ways
of building an interface would apply, I'd
think. In fact, I can't imagine why you'd want to
distinguish "signaling" packets. You'd want to use
normal QoS mechanisms (diff/intserv), I'd think,
and let the application decide what it wants to
prioritize, and the gateway decides how to police.

		Mike