Subject: [nemo] Dynamic Routing Protocol Operation on MR

From: Koshiro MITSUYA <[email-masked]>
Date: Thu, 06 Nov 2003 01:16:58 +0900

Hello,

Dose anyone have a good idea how to operate or implement Dynamic
Routing Protocl Support on MR?

The specification said, 

7. Support for Dynamic Routing Protocols

   <skip>

   When the Mobile Router is attached to the home link, it runs a
   routing protocol by sending routing updates through its egress
   interface.  When the mobile router moves and attaches to a visited
   network, it MUST stop sending routing updates on the interface with
   which it attaches to the visited link.  This is very important so
   that IPv6 prefixes specific to the Mobile Network do not leak into
   the visited network.  The Mobile Router then starts sending routing
   protocol messages through the bi-directional tunnel towards the Home
   Agent.  Most routing protocols use link local addresses as source
   addresses for the routing information messages.  The Mobile Router is
   allowed to use link local addresses for the inner IPv6 header of an
   encapsulated packet.  But these messages after decapsulation MUST NOT
   be forwarded to another link by either the Mobile Router or the Home
   Agent.

   <skip>

My problem is, how the routing daemon on MR stop the advertisement?
how to change the advertised interface between the egress interface
and bi-directional tunnel?

I remember a solution (maybe Pascal said on the ML). MR has a virtual
interface like vif0 which pointing the bi-directional tunnel. When MR
move to foreign from home, MR change the configuration of routing
daemon like eth0 to vif0 and restart the routing daemon.

Is this the best way? If there is another method, please teach me.

thank you,
Koshiro

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Nov 2003 12:19:00 -0800

> Is this the best way? If there is another method, please teach me.

it is totally implementation dependent.

in some implementations there is one instance of routing protocol
per interface. in this case, it is matter of stopping the instance
on the egress interface and starting it for the tunnel interface.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Nov 2003 12:19:00 -0800

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 06 Nov 2003 00:22:52 +0100

>> Routing Protocl Support on MR?

Ideas plenty, but what you call a good idea...

>> The specification said, 7. Support for Dynamic Routing Protocols
>> 
>> <skip>
>> 
>> protocol messages through the bi-directional tunnel towards the
>> Home Agent.  Most routing protocols use link local addresses as 
>> source addresses for the routing information messages.  The Mobile 
>> Router is allowed to use link local addresses for the inner IPv6 
>> header of an encapsulated packet.  But these messages after 
>> decapsulation MUST NOT be forwarded to another link by either the 
>> Mobile Router or the Home Agent.
>> 
>> <skip>
>> 
>>  how to change the advertised interface between the egress 
>> interface and bi-directional tunnel?
>> 
>> I remember a solution (maybe Pascal said on the ML). MR has a 
>> virtual interface like vif0 which pointing the bi-directional 
>> tunnel. When MR move to foreign from home, MR change the 
>> configuration of routing daemon like eth0 to vif0 and restart the 
>> routing daemon.

Re-starting the routing daemon?  What happens to all entries that
existed in the app-level rt table entries when the MR was at home?  They
get lost when the MR moves away from home and re-get introduced when the
MR talks back to the HA?

> it is totally implementation dependent.

it is more or less implementation dependent.

> in some implementations there is one instance of routing protocol per
>  interface. in this case, it is matter of stopping the instance on 
> the egress interface and starting it for the tunnel interface.

It is hardly doable to stop and start that instance, when this trigger
supposedly comes from the kernel space (where stacks run traditionally)
to the userland (where rt daemons run traditionally).

A possible way to implement dynamic routing protocol over the MR-HA
tunnel is not to have the bidir tunnel as an interface (virtual or
other).  Instead, the encapsulation happens according to searches in the
rt table and in the bc.  When HA routes a packet towards MR, it searches
a corresponding entry in its bc and if found then encapsulate.

This logic does not apply similarly at the MR of course since that 
hasn't a bc. So the MR needs to 'flag' its entries in its rt that 
correspond to the real interface that connects to the home link, (named 
egress interface, or name it mobile interface).

When MR moves away from home, it moves all its rt entries corresponding
to its mobile interface to a new table.  Modify the kernel ctls that are
called by the rt daemon such as instead of reading/writing in the normal
rt table, r/w into this new table, when referring to that interface.

In this way, the rt protocol instance runs as before, over the same
interface visible in the userspace.  But it magically maintains the
kernel routes in this new table instead of in the normal kernel rt table.

This also allows for the same rt protocol application to run another
instance over the egress interface but directly towards the access
system, since the relevant entries for home were declared when it moved.
  Routing interactions with the access system are not addressed by NEMO
(but in other contexts this _is_ interesting, for example look at OSPF
wireless interfaces).

Now there was a sort of discussion about dynamic rt protocol over the
MR-HA tunnel very early in the DT, together with indications about
how we (Mot) did it late last year.  I would qualify that discussion as
public and non IPR'ed only if the NEMO WG considers that the NEMO basic
solution should be non-IPR'ed; if the NEMO WG considers that the basic
NEMO solution could be IPR'ed - a plausible reason I could imagine to
see being that  NEMO would in itself be not a "base" but rather an
"extension" of Mobile IPv6, and with the attached IETF licensing scheme,
open source licensing, RAND and such - then I qualify that DT discussion
as secret and our source code also as secret and very difficult to
discuss about until my employer gets a publicly-visible patent (read
visible w/o a fee on the uspto site, even though EU and JP patents show
to paying subscribers in other places earlier) for it as well as an IETF
IPR declaration along the lines of rfc2026 and along the lines of what
the IPR WG currently suggests.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 06 Nov 2003 00:22:52 +0100

Alex
GBU