Home
Vendor
Project
  Phase I
Press
  Phase I
About
You Are Using IPv4 To Access This Site
Your IP Address is: 38.103.63.61

[>>> SPAM <<<] - [moonv6] Good MIPv6 Deployment Analysis via Masters Thesis - Email found in subject

New Message Reply Date view Thread view Subject view Attachment view

From: Ed Remmell (eremmell@treck.com)
Date: 01/14/05


moonv6 post from "Ed Remmell" <eremmell@treck.com> Rodolfo -

> -How a handover affects a communication if I'm downloading a
> file with FTP.

Yes, this is important to understand. There are some enhancements for wireless TCP (look at WAP 2.0 profiled TCP) that can help. We modified our TCP implementation so that when our MN comes back on link, the first thing it does is to send 3 duplicate TCP ACKs for each TCP session it is maintaining, to cause the peer to start TCP Fast Retransmits to more quickly recover from TCP packet loss. Also, look at the handover latency, measured starting when the MN comes back on link to when it has finished updated its mobility bindings with the HA and CNs (Binding Update/Binding Acknowedgement exchange). Also, does LIVSIX support any form of optimized Duplicate Address Detection to help reduce the handover latency, or are you always stuck with at least 1 second of waiting on DAD to complete after every handover before your MN can register its new binding with the HA (assuming that you don't disable DAD, since then you wouldn't be RFC-compliant)?

The TAHI test suite for MN focuses a lot on the "MN return to home" scenario (deregistration with HA and CNs from home link). This is another interesting area of MN functionality to investigate. What is the latency of your "MN return to home", before it is completely deregistered? How does this affect existing TCP sessions (i.e. downloading a file with FTP)?

> -Finding a new route after a handover is done. I think this
> could be necessary because in IPv6 we don't have packet fragmentation.

Discovering a new router (i.e. receiving a Router Advertisement) is how the MN finds a new route. What does this have to do with packet fragmentation?

>
> Now, I can do all this stuff with my port.

Awesome!

> > Approximately how long does your prototype take to boot all
> of the way
> > up, to the point where all of the uCLinux and LIVSIX services are
> > running and you can actually use the chat application over MIPv6?
>
> I'll send you the exact information later. To boot up,
> uClinux takes less than 20 secs. After that I have to set the
> IP interface by hand and the load the LIVSIX module (it is
> detailed in the document).

Yes, I thought it was something like 20 seconds. If you ask me, that's a long time for an end-user to wait for the system to become available, but then if the MN device is always on (i.e. like a cell phone that you keep recharging), it probably isn't that big of a deal. Anyways, it is an indication of the software complexity of your implementation - our implementation is much thinner. BTW, we do provide a complete set of BSD-compliant socket APIs (with the notable exception of sendmsg/recvmsg) including RFC-2553 for dual stack, so application code that uses BSD sockets will port directly to our embedded TCP stack.

> I don't understand why you sell the HA implementation with
> the CN option.

A HA is a CN, with additional functionality. Both maintain the mobility bindings, that associate the MN's home address with its Care-of Address. Both must process Binding Update messages from the MN, and respond with Binding Acknowledgement messages.

> Also, I assume the MN has the capability of being a CN as
> well (it has the capability of communicating to another MN).

Yes, it is possible to enable both our CN and MN options at the same time. Or, you could just enable the MN option. In any case, this is done at compile-time via macros. Route optimization is intrinsic to CN, but it is optional with MN. A MN implementation could always tunnel packets through the HA (triangular routing), which is the case when you enable our MN option but disable route optimization.  

> So, when you say a "CN option", is it for a non-mobile node?

Yes, it is typically for a non-mobile server that communicates with MNs.  

> Maybe a very small implementation for somebody who just want
> to communicate with a MN using Route Optimization.

Smaller. Definitely not as complex as MN. But, not trivial.

> > If you are interested/curious, I can email you a copy of our
> > MIPv6 user documentation (most of it is MN). It has some
> > example code showing how to use our MIPv6 MN and Ipsec/IKE
> > APIs.
>
> Actually I'm more interested in touching/programming my
> protocol rather than just using somebody else's protocol. Thank you.

Fair enough. I was hoping I could get you interested in evaluating our products! Also, I'm kind of proud of the flexibility and power of our MN APIs, since I had a lot of involvement in the design of that product.

Thanks.
- Ed 

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.12 - Release Date: 1/14/2005
 


---
Treck, Inc. -  Confidentiality Notice
 
This electronic transmission may contain information that is proprietary or confidential.  You are hereby notified that any dissemination, distribution or duplication of this electronic transmission to some other entity, without the expressed written consent of Treck, Inc.  is strictly prohibited, unless the contents of this electronic transmission specifically authorizes you to do so.  If your receipt of this electronic transmission is in error, please notify the corporate offices of Treck, Inc.  immediately by  calling (513) 528-5732, or by reply to this transmission.
New Message Reply Date view Thread view Subject view Attachment view

This archive was generated by hypermail 2.1.7 : 12/01/06 EST