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
New Message Reply Date view Thread view Subject view Attachment view

From: Kohn Rodolfo-ARK025 (rodolfo.kohn@motorola.com)
Date: 01/14/05


moonv6 post from Kohn Rodolfo-ARK025 <rodolfo.kohn@motorola.com> Ed,
My answers are below.

Thanks,
Rodolfo.

> -----Original Message-----
> From: Ed Remmell [mailto:eremmell@treck.com]
> Sent: Thursday, January 13, 2005 3:20 PM
> To: Kohn Rodolfo-ARK025; 'Bound, Jim'; nav6tf@ipv6forum.com;
> moonv6@io.iol.unh.edu
> Cc: Atoosa Rezai
> Subject: [>>> SPAM <<<] - RE: [>>> SPAM <<<] - [moonv6] Good
> MIPv6 Deployment Analysis via Masters Thesis - Email found in
> subject - Email found in subject
>
>
> Rodolfo -
>
> I saw in your masters thesis that this was affiliated with
> Motorola/Freescale? We have a partnership with them,
> specifically with the team doing the NE64 processor. The
> Coldfire processor is a good target for our protocols to run
> on, we recently integrated Treck protocols with Quadros RTXC
> to run on that processor (for example).
>

Actually I'm working at Motorola, as software engineer, in a Software Center, CMM level 5, in Argentina. I have almost no contact with Freescale or its teams (other than a few questions through the customer service).

>
> I'm looking forward to seeing the .map file. I expect your
> ROM footprint is pretty big, i.e. megabytes. We can easily
> fit all of the Treck MIPv6 MN functionality, including Treck
> Ipsec and IKE, with route optimization and some room left
> over for applications, in less than 200K bytes of ROM, and at
> run-time this configuration would require approximately 100K
> bytes of RAM.
>
> So, I'd expect to see an order-of-magnitude difference in
> both RAM and ROM usage between our implementation (smaller)
> and your prototype (bigger) using uCLinux and LIVSIX.
>

You're right at some points, the LIVSIX stack is compiled as a module and loaded with "insmod". I need to have a chunk between 200K and 300K of contiguoug memory in order to load the module, also we have to add the dinamically allocated memory. Also the IPsec part is not totally implemented, as you can see in the document. Give me some time to look for the .map file (currently I'm upgrading my PC and my Linux kernel version and I have a mess in my Linux environment) but what I know at this moment is that the complete image with the operating system, a ROM FS, the module and the application is around 600K (+-50K).

> I'm just curious, from a competitive standpoint. Treck
> protocols are designed specifically for embedded systems, so
> of course they do support hard real-time since we have very
> short critical sections throughout our code (it is part of
> our coding standard that all of our products must comply
> with, designed in from the beginning). I'd expect that your
> prototype cannot support hard-real time, since large and
> variable interrupt latency is a characteristic of Linux
> (Linux wasn't designed for embedded systems).
>

uClinux is not a real-time OS (like VxWorks or Montavista, for instance). I've been working with kernel version 2.4.19. I haven't paid attention to the improvements in kernel 2.6.x, though. So, I wouldn't expect a better interrupt latency than in your implementation. I'll send you this information later (no less than a month).

Actually, at this moment, I'm not interested in the real time capabilities of my system but in specific protocol characteristics and possibilities like: 

-How a handover affects a communication if I'm downloading a file with FTP.
-Making a vertical handover without affecting a connection.
-Modifying the router advertisements for the MN to have more information (cost, load, services) to choose to which network I want to connect.
-Finding a new route after a handover is done. I think this could be necessary because in IPv6 we don't have packet fragmentation.

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

> 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).

>
> We have an implementation of MIPv6 HA that we used for
> testing, but it wasn't designed to be a product. We sell it
> with our MIPv6 CN option. We also sell a MIPv6 MN option. We

I don't understand why you sell the HA implementation with the CN option. It is necessary with the MN implementation. Also, I assume the MN has the capability of being a CN as well (it has the capability of communicating to another MN). So, when you say a "CN option", is it for a non-mobile node? Maybe a very small implementation for somebody who just want to communicate with a MN using Route Optimization.

> have full implementation of both IPv4 and IPv6 packet
> forwarding/routing, however we only have RIPv4 listener, we
> don't have many routing protocols.
>

OK, I would like to add some routing protocols (OSPF or just RIP) to my stuff. LIVSIX provides the basic functionality at level 3 (RAs).

> 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.

This same example code is part of our Treck Win32 dual
> stack demo, which has our MIPv6 MN functionality (you need to
> use it with a MIPv6 HA that supports DHAAD, the Cisco HA
> didn't when we participated in the phase 1 MoonV6 testing).
> Our Treck Win32 dual stack demo is available here:
>
> http://www.treck.com/TreckDemo.zip
>

Thank you, I'll look at it.

Thanks,
Rodolfo.

New Message Reply Date view Thread view Subject view Attachment view

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