Subject: Re: [MOBILE-IP] QoS [diff-serv or int-serv/RSVP], and Windows MIP implementation

From: Foo Chun Choong <[email-masked]>
Date: Thu, 2 Sep 1999 14:55:23 +0800

Hi Xinhua,

On Tue, 31 Aug 1999, Xinhua Zhao wrote:

> Foo Chun,
>
> I have a few comments on the support for mobile routers using MIP.
>
> I believe that RFC2002-compliant MIP implementations should be able
> to support mobile networks without protocol changes. See below.

I do not agree with this comment. An MIP implementation that is just
RFC2002-compliant may not necessarily be able to support mobile networks.
Minor changes will be needed with regards to the processing done at the MN
and the agents in order to support this functionality, depending on the
method that is used to provide mobile networks support under MIP.

For instance, we used two independent methods to support mobile networks
under MIP (ie the MN able to act as a router). The first method is by
making the MN an NAT/IP masquerading router. All packets from nodes
belonging to the mobile network will appear to originate from the MN
itself. Enjoys from benefits of using NAT such as ability to support the
use of private addresses within the mobile network, but suffers also from
the disadvantages of using NAT eg processing bottleneck at MN, not able to
support recursive use of MIP (ie MN1 moves to the mobile network supported
by the mobile-router enabled MN2 and foreign agents within the mobile
network. MN1's HA is HA1, while MN2's HA is HA2. HA1 and HA2 are somewhere in
the net outside of the mobile network.), nodes within the network not able
to act as ftp, web servers due to use of private addresses, etc.

The second method is to augment/enhance the MIP processing done at the MIP
entities. In this case, the HA is enhanced to also tunnel packets to the
MN's COA if the next-hop gateway of the packet is the MN. (RFC2002 HA only
tunnel packets to the MN's COA if the destination address of the packet is
to the MN). Further issues such as reverse tunnelling and ip ttl, proper
handling of broadcast and multicast packets have to be resolved in order
to support the use of dynamic routing.

> Foo Chun Choong wrote:
> > Regarding mobile routers support using MIP, what are the implementations
> > of MIP that you have tested so far that can support this feature?
> >
> > I've actually hacked our NUS MIPv4 Linux code to support mobile networks
> > using MIP.
> > We used two methods (which work independently of each other) to provide
> > support for mobile networks under MIP. One method used was to make the MN
> > NAT/IP masq-enabled. The other method that we used was to augment the MIP
> > protocol,
>
> I think the Mobile IP protocol itself actually doesn't need to be augmented
> at all.

I need to clarify further what I mean by an augmented MIP protocol. An
augmented MIP protocol does not necessarily mean changes to the message
formats (registration packets and agent adverts) used by MIP, it could also
be in terms of the processing done when packets are received by the MIP
entities.

> If we treat the whole network behind the mobile router (which is a mobile
> host) just like any other static network at the mobile router's home network
> and advertise its reachability through this mobile router at the mobile
> router's home network, there isn't really any need for special support.
> The only difference between a "mobile network" and any other normal network
> is that the router to this particular network happens to be mobile. So,
> instead of using regular IP to forward packets to a regular host in order
> to reach a normal network, we need to use MIP to forward packets to the
> mobile router first.

RFC2002 HA performs tunnelling based on the destination IP address of the
packet, ie if the packet's final destination is the MN and the MN is in a
foreign network, then the HA will tunnel the packet to the care-of-address
(COA). But, a packet sent to a node in the mobile network is not destined
to the MN, it is destined to that node instead. Rather, when the packet
arrives at the home network/HA, the MN is the next-hop gateway, and what
the HA should do is to tunnel any packets whose next-hop gateway is the MN
to the care-of-address.

(This is required irrespective of whether an FA or co-located COA is
used, if you want to use method (2)).

An RFC2002 HA that does not have this extra processing will not be able to
support mobile networks under method (2).

Other issues are also involved when you want to support mobile networks
under MIP, for instance the proper handling of broadcast and multicast
packets (which are used by the dynamic routing protocols OSPF and RIP) is
required if you want to support dynamic routing.

Reverse tunnelling and also IP ttl issues also comes into consideration.

> Therefore, it is still a question of how to reach a mobile node rather
> than a whole "mobile network". Supporting "mobile network" is really an
> issue of supporting mobile router. I don't see a need to expose to the
> outside world the fact that the network is mobile other than the fact
> that the router to it is actually mobile.
>
> Of course, the above model still supports that the nodes within the
> network behind the mobile router can be mobile. Again, no special
> changes are required here. The fact that the care-of address is in a
> "mobile network" just makes no difference.

Depends on the method that you use to provide mobile router support.
Method (1) may not be able to support the recursive use of MIP.

The interesting thing is that the changes required to RFC2002 MIP
entities to support mobile networks is very little only.

Vision of an IP-based cellular network (where different groups of cells
may represent different IP subnets and hence be under the control of
different FAs). MIP-enabled car, bus, ship, tank, etc supporting Internet
connectivity for multiple users, with no special software required at the
users side.

Each of these cars, ships, etc represent a mobile network, with the
gateway to the outside world being the "mobile-router enabled" MN situated
inside the car, etc.

> My view is that current MIP implementations that are RFC 2002 compliant
> should be able to support mobile routers, hence "mobile networks".
> The only tricky thing is in the mobile node implementation. It should
> enable a mobile node to act as a regular node (maintaining regular
> routing table etc.) for certain traffic instead of simply behaving as a
> host away from home which then blindly forwards all packets through an FA.
> This support of duality for mobile nodes has actually been a focus of
> MosquitoNet Mobile IP implementation we have been experimenting here,
> though not specifically geared towards supporting mobile networks.

Another additional thing that MIP implementations that want to support
mobile networks should be aware of is the proper handling of ARP on
the multiple interfaces of a mobile node (MN). As you know, the MN is
not allowed to ARP to any other entities other than the FA when it is in a
foreign network. In the case of an MN having more than one network
interface, ARP must be allowed on the non-MIP interface, ie the link that
connects to the mobile network. In the case of an MN having only one
network interface (ie a one-arm router), ARP must be allowed if it is
between nodes belonging to the mobile network.

We observed this situation while implementing the mobile networks support
in NUS MIP.

Chun Choong

> Best regards,
>
> Xinhua
>
> ===========================================================
> Xinhua Zhao              MosquitoNet Mobile Computing Group
> Room 416, Gates Building 4A            [email-masked]
> Stanford University                    phone: (650)723-9427
> Stanford, CA 94305                     fax:   (650)725-2588
>
>
> > the main idea is that the HA will now additionally tunnel any
> > packets to the FA if it's next hop gateway is the MN. Each of the methods has
> > its own advantages and disadvantages, for example the first method
> > supports private addresses, while the second method supports the recursive use
> > of MIP. (Am actually hoping to write an ID to elaborate further on this if
> > time permits).
> > The code will be included in version 3.1 of Linux NUS MIPv4, which we are
> > planning to officially release at the end of this year.
> >
> > We at NUS would also greatly welcome others in the MIP community who are
> > interested in joining to help in the NUS MIP project. Extra help is always
> > welcome 8-).
> >
> > Foo Chun Choong,
> > The NUS Mobile IP Project, http://mip.ee.nus.edu.sg
> > National University of Singapore
> >
> > On Mon, 23 Aug 1999, Rob Goode wrote:
> >
> > > Dear Foo Chun Choong,
> > >
> > > We at NC3A have a testbed looking at emerging internet technologies,
> > > specifically mobile IP, QoS and IPv6 and I would be interested
> > > in some open source for these technologies on the Windows platform
> > > as that is the most widely deployed platform in our organisation.
> > >
> > > I would have a high interest in MIP on windows, especially in
> > > source form, as my interest is in mobile routers (or mobile
> > > hosts with two interfaces and IP forwarding enabled) which I
> > > find tends not to be a standard function of most implementations,
> > > and hence tends to require (small) source code modifications. Our
> > > current interest is in MIP for IPv4, until MIPv6 becomes more
> > > widely implemented.
> > >
> > > Cheers,
> > >
> > > Rob Goode
> > > Principal Scientist
> > > Communications Techniques Branch,
> > > Communications Systems Division,
> > > NC3A
> > > PO Box 2501 CD
> > > The Hague
> > > The Netherlands
> > >
> > >
> > > > MIME-Version: 1.0
> > > > Date: Sat, 21 Aug 1999 21:51:24 +0800
> > > > From: Foo Chun Choong <[email-masked]>
> > > > Subject: [MOBILE-IP] QoS [diff-serv or int-serv/RSVP], and Windows MIP
> > > implementation
> > > > X-To: [email-masked]
> > > > X-cc: [email-masked], [email-masked]
> > > > To: [email-masked]
> > > >
> > > > Hi Guilhem,
> > > >
> > > > We at NUS have done some work regarding MIPv4 and RSVP/int-serv
> > > > integration. Some documents regarding this can be obtained from
> > > > http://mip.ee.nus.edu.sg/slcchua.ps.gz , slcfoo.ps.gz , and slcloh.ps.gz
> > > > The source code for the prototype implementation that we've developed here
> > > > at NUS to support MIP/RSVP/int-serv integration can be obtained from
> > > > http://mip.ee.nus.edu.sg/v3.0beta
> > > >
> > > > BTW, we would also like to gauge the interest of the MIP community regarding
> > > an
> > > > implementation of MIP on Windows. We have developed a prototype implementation
> > > > of MN on Win95, and the agents on NT, and are contemplating an open-source
> > > > release of the source code for these if there's a big enough demand for it.
> > > >
> > > > Regards,
> > > > Foo Chun Choong,
> > > > NUS Mobile IP project, http://mip.ee.nus.edu.sg
> > > > National University of Singapore
> > >
>

---

From: Xinhua Zhao <[email-masked]>
Date: Fri, 3 Sep 1999 17:51:37 -0700

Foo Chun,

As you have observed, little change is required in RFC 2002-compliant
MIP entities to support the MH as a mobile router. We both seem to
agree on this. I think it is more of an implementation issue than a
protocol change. In essence, tunneling is used to get packets from
the HA to the MH away from home. Whether the MH is the ultimate
destination or the MH is just an intermediate node makes no difference.
Restricting tunneling of packets to strictly when the MH is the
destination is unnecessary, and can be easily loosened. That explains
why the required change is so little.

Between the two approaches you described to support mobile networks,
I like the second approach better. My main concern with the first
approach (NAT/IP masquerading at MH) is that it renders the nodes
in the mobile network no longer the end points of communication
and this can result in many hairy issues (such as the well-known
problem that applications encode their host addresses in messages).
While the second approach is no more complex, it supports a more
natural networking model, i.e. the nodes in the mobile network
are truly end points.

Regards,

Xinhua