Subject: [mobile-ip] Movement Detection Optimizations draft (01) submitted.

From: Greg Daley <[email-masked]>
Date: Mon, 12 May 2003 12:36:40 +1000

Hi,

JinHyeock Choi and I have been working on a draft
which provides information about state of the art
in Movement Detection for MIPv6.
We've just submitted the -01 version, and it has reached
the internet-drafts archive.

Currently, there are two significant parts to this draft.

First is an overview of how movement detection may be
used to gain unambiguous knowledge of movement
(this is in addition to the presentation in the latest
version of the MIPv6 draft).

Secondly, a comparison of available Movement Detection
optimizations and their application is provided.

The draft has been growing organically as knowledge of
MD has been maturing, which may explain the two foci.

If you are interested in MD issues, please read the draft,
and provide some feedback.

The draft is available at:

http://www.ietf.org/internet-drafts/draft-daley-mobileip-movedetect-01.txt

Yours Faithfully,

Greg Daley

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 13 May 2003 17:53:29 -0700

Greg & JinHyeock -

I took a quick look at this draft, thanks, it captures a lot of good
information and reads well. I will go through it in detail when I finally
implement MN generic movement detection (later this month).

I agree with your optimized probing strategy, i.e. send a single probe to
the current default router after a L2 handover and wait for some delay to
get the solicited NA response before resorting to Router Discovery. Also,
the suggestion to probe the global scope (R) bit router address when
available is a good one.

Thanks again,
- Ed

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Greg Daley
> Sent: Sunday, May 11, 2003 7:37 PM
> To: Mobile-IP
> Cc: JinHyeock Choi
> Subject: [mobile-ip] Movement Detection Optimizations draft (01)
> submitted.
>
>
> Hi,
>

---

From: Greg Daley <[email-masked]>
Date: Wed, 14 May 2003 13:20:02 +1000

Hi Ed,

Thanks for reading the draft,

Since there are a lot of ideas of the WG's
distilled in the document, I'm not sure which
ideas are JinHyeock's and Mine and which other
people have come up with.  JinHyeock may know better,
since he wrote a lot of the text in that section.

I think that the idea is a good one, especially if you were
going to do an RS anyway.  I still think that there
may be issues with unsolicited RA reception in that
all Prefix Information Options may not be present.

Realistically, we want the MN to have to track as few
Prefixes, Router IDs or other data as possible.
Certainly they shouldn't have to worry about prefixes
for which they don't have a CoA.

If yourself and other people have better ideas,
then we can incorporate them into the draft, or reference
them at your discretion (as we have done for FastRA/FRD &etc).
I think that our current idea is that Movement Detection
work within the WG will still need a focus after the
freezing of MIPv6 text, so some document is needed to capture
those ideas (even though it is not a WG document).

Thanks again for your comments,

Greg

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 13 May 2003 19:54:51 -0700

Ed Remmell wrote:

> get the solicited NA response before resorting to Router Discovery. 

this is what I was violently arguing for a week back:) doing a NS/NA
probe, then router discovery in case of a weak hint. good that it is
in the form of a draft now. I hope we can move this draft quickly.

 > Also,

I havent read the draft yet. this is a good idea.

Vijay

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 28 May 2003 12:24:58 -0700

Greg & JinHyeock -

OK, I finally found time to go through this entire draft (thanks again for
writing it, it was very helpful to see all of this information organized
like this). Here is some feedback:

I did research eager cell switching a bit, as well as other algorithms such
as lazy cell switching, etc. Eager cell switching is trying to do all of the
movement detection at L3. The actual state of the link is known by L2 & the
MAC layer. So, if L2 triggers are available, movement detection can be very
responsive without the need for frequent RA beacons.

The Intersil PRISM 2.5 chipset that we recently developed a device driver
for for our embedded TCP/IP stack product supports notification in the LAN
chip interrupt service routine of L2 and MAC layer events such as change in
access point (link status), access point in range after being out of range,
association/reassociation events (association status). This is very fast
notification of link movement.

Eager cell switching (ECS) makes some assumptions (i.e. straight-line
movement, typically only one router per link, etc.), and probably won't work
optimally in some deployment scenarios. However, for some deployment
scenarios, ECS is definitely the best way to go. For example, a deployment
scenario where PPP is used as the link-layer, there is only a single router
on any given PPP link, and the network detects that a MN has moved by a PPP
link-up event and then immediately sends a unsolicted RA to the MN to force
MN detecton of L3 handover - this is an example of a deployment scenario in
which I think ECS would be the best solution. Another good deployment
scenario for ECS is when all (or the large majority) of the handoffs are
directed and/or coordinated by the network (again with the restriction of
only a single router per link), I think that "Fast Handovers for Mobile
IPv6" may fit this scenario.

I can see why ECS is attractive to those who want to see broader support for
MIPv6, because it requires fewer changes to the kernel, and does not take
advantage of L2 triggers so requires no special integration with L2, the
device driver, etc. However, please let's not assume that the entire world
will convert over to some form of embedded Linux - proprietary RTOS is not
dead (I know of a very successful manufacturer of a large family of
networked laser printers who still uses their own proprietary RTOS in those
products, with our embedded networking stack I might add), and there is
still a need for our sort of embedded protocol solutions which are faster
(with latency characteristics suitable for hard real-time applications),
smaller (easily an order of magnitude smaller than the smallest embedded
Linux both w/ respect to ROM and RAM usage), and independent of RTOS,
packaged for easy integration with a customer's preemptive/non-preemptive
proprietary RTOS (as well as support many off-the-shelf RTOS'es as well as
being able to run w/out any RTOS).

Some specific comments on your draft:
p. 6, figure 2 "MN sees two access routers on the same subnet" but
accessible through different APs. What you are saying (I think) is that
there are two access routers broadcasting the same on-link prefix, yet they
are on different physical links. Is this a valid deployment scenario? I find
it pretty confusing.

p. 6, figure 3 "Two Access routers on the same subnet"
I believe the caption should say instead: "Two Access routers on the same
link".
subnet => link

bottom of p. 8, section 2.3.3 "Checking the validity of the current CoA":
"The MN sends a unicast RA to current AR. When a solicited RA with all
options arrives, ..."
I think this is pretty misleading. Per RFC-2461, even if the MN sends a RS
specifying its local address as the source address (i.e. not the unspecified
address), it will likely receive a multicast RA in response not a
solicited/unicast RA to its local address, and then there is no guarantee
that the information in the RA will be complete (i.e. it is possible that
the RA is not answering the RS, but it could be a RA beacon that was sent
around the same time, etc.).

p. 9, secton 2.3.4 "Discovering a new AR", last sentence of 4th paragraph:
"We can say though, if we don't receive a RA in time, it's highly probably
that the current AR is not reachable."
highly probably => likely

It is possible that packets are dropped. Wireless QoS is generally not that
great, packets will be dropped even if in many cases L2 and the MAC layer do
retransmit. Also, the likelihood of a multicast RA being dropped is higher
(at least with 802.11) than if it was unicast. Because of RFC-2461, it will
likely be a multicast RA, even when it is a response to a RA sent with the
source address set to the MN's local address. So, please reword to say
"likely" instead of "highly probable".

Page 13, 3rd paragraph:
"Even if default router lifetimes are rounded up to the nearest second,
nodes which assume MaxRtrAdvInterval is at [RFC-2461] values could be
confused about the lifetime of their default router."
I don't understand this. Why would a MN be confused, when it should use the
router lifetime discovered in the RA? MaxRtrAdvInterval is a configuration
parameter for the router, the host should not be aware of this parameter,
and in any case it should be unrelated to the router lifetime. If a MN
doesn't use the lifetime discovered in the RA as the router lifetime, then
it doesn't implement part of IPv6 Router Discovery, and is non-compliant
with RFC-2461.

This paragraph is confusing, I think it is wrong. It makes the assumption
that AdvDefaultLifetime and MaxRtrAdvInterval are related w/ respect to the
parameters that the MN discovers and uses - IMO they are not related on the
MN. The advertised router lifetime should be completely independent from the
frequency at which RAs are beacon'ed (i.e. the advertisement interval). The
requirement you mention in RFC-2461 w/ regards to the minimum value for
AdvDefaultLifetime only applies to the router - it makes sense that the
router lifetime advertised in the RA should not be less than the
advertisement interval, otherwise it might happen (especially if a multicast
RA is dropped and not received by the MN) that the MN periodically times-out
its default router and then doesn't have any default router to use while it
is still on-link and hasn't actually moved.

p. 15, 2nd paragraph has a typo:
"If it receives an RA from a previously... it may be useful to confirm
bidirectional reachability with this outer, ..."
outer => router

Section 4.1 "Effects of Solicitation Delays"
You given the example of a train moving, and multiple simultaneous handoffs.
It is probably more likely that ECS will have this problem (since it is
triggered by receiving a multicast RA, which will be essentially a
simultaneous event for all of the MNs on the train), and need the randomized
solicitation delay, whereas a mechanism that doesn't use ESC or receipt of a
RA to trigger handoff (for example L2 triggers) will not have this problem
(in general) and therefore does not need the randomized solicitation delay.
I believe this to be true, because the MNs will have slightly different
MAC-layer performance characteristics due to position in space, fading,
obstacles, etc. so when multiple MNs handoff due to a L2 trigger event,
these different MAC layer characteristics will provide sufficient
randomization that no additional randomized solicitation delay should be
needed.

I had some more input about the use of the R-bit Prefix Information Option:
in our MN implementation, we will implement a form of ECS, disabled by
default but it can be enabled at run time. When our ECS is enabled, and we
receive a RA which has one or more R-bit Prefix Information Options, if we
haven't already discovered any of those prefixes as a on-link prefix, then
we treat this as an indication of L3 handover (per ECS, we would then switch
to that router). This seems like a sure indication of L3 handover, since a
requirement was added in draft 22 of MIPv6 that says that if the routers
sends one or more R-bit Prefix Information Option in a RA, then at least one
of those R-bit options SHOULD be advertised in every RA that the router
sends (including beacon RAs).

Thanks.
- Ed

> [mailto:[email-masked]]On Behalf Of Ed Remmell
> Sent: Tuesday, May 13, 2003 5:53 PM
> To: [email-masked]; Mobile-IP
> Cc: JinHyeock Choi
> Subject: RE: [mobile-ip] Movement Detection Optimizations draft (01)
> submitted.
>
>
> Greg & JinHyeock -
>
> Greg Daley

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.481 / Virus Database: 277 - Release Date: 5/13/03

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.481 / Virus Database: 277 - Release Date: 5/13/03

---

From: "JinHyeock Choi" <[email-masked]>
Date: Thu, 29 May 2003 09:42:47 +0900

Hi Ed

Thanks for your thorough and helpful feedback. 

> IPv6" may fit this scenario.

Yes, ECM doesn't work well for the case of multiple routers per a link. 
We implemented ECS and it broke down in that situation. Can we assume 
(or impose) the condition of a single router per a link? 

I also worried about the the case of MN with multiple connection. For 
example, assume a MN has both 802. 11 b interface and CDMA interface. 
Then even though each link has only one router, ECM may result in continual 
BUs. 
 
> are on different physical links. Is this a valid deployment scenario? I find

I agree that this is complicated. What we had in mind is that two routers 
on a same link, not in wireless link but in wired link. For example they
are connected to the same border router. 
 
I think the below figure describe a valid deployment.

______
| Border|
| Router|________________________________________
|______|                        |                                   |
                                 __|____                       __ |____
                                | Access|                       | Access|
                                | Router |                       | Router |
                                |___1__|                       |___2__|                 
                                     |                                     |
                           A::      |                                    |      A::  
             ____________|__________________ |__________                                   

Then is the below valid deployment?       

______
| Border|
| Router|________________________________________
|______|                        |                                   |
                                 __|____                       __ |____
                                | Access|                       | Access|
                                | Router |                       | Router |
                                |___1__|                       |___2__|                 
                                     |                                     |
                           A::      |                                    |      A::  
                                 __|____                       __ |____
                                | Access|                       | Access|
                                | Point   |                       | Point   |
                                |___1__|                       |___2__|   

I am not sure but, IMHO, we'd better not to deploy like above. It gave us 
lots of problems. I am thinking about the condition on which two interfaces 
of routers (whether they belong to one router or two routers separately) can 
advertise the same prefix as on-link one. 

Wireless link is not as clear cut as wired one, hence complication. 

> I believe the caption should say instead: "Two Access routers on the same

Thanks for correction.  

> around the same time, etc.).

According to RFC 2461 6.2.3, 

                                     However, when responding to a
   Router Solicitation or while sending the first few initial
   unsolicited advertisements, a router SHOULD include all options so
   that all information (e.g., prefixes) is propagated quickly during
   system initialization.

I interpreted the above like this. "When a router replies a RS, it sends a RA 
with all options, whether it sends unicast RA or multicast RA." 

So I think that we can assume a solicited RA has all the information. The problem 
is that MN has no way to be sure of that. But MN can say that its 'highly probable'.   

> "likely" instead of "highly probable".

I see. It makes sense. 

Thanks for your thorough feedback. 

Best regards.

JinHyeock.

---

From: Greg Daley <[email-masked]>
Date: Thu, 29 May 2003 12:31:44 +1000

Hi Ed,

Thanks for your post and detailed review.

> notification of link movement.
Indeed, the MN's L2 hardware is aware of the link-layer
identity of the base-station it is connected to, and when
that connection is established.
The difficulty is in describing a robust system which
handles the situation where:

L2 change !-> L3 change.

We have implemented equivalent triggering systems here.
They are very useful, but unless Paul Tan's or
other mechanisms for embedding L3 link identity are
available to L3 (through an API?), they don't provide
robust movement detection.

Today, we can't say that this is available in general
or even in a standardized manner on some networks.

We've tried to capture what is available in today's
networks, or in internet drafts. Does this need to be
stated more explicitly at the start of the document?

> being able to run w/out any RTOS).

I know that Eager-Cell-Switching is available in most
existing implementations, basically through a lack
of standardized (even within the same O/S) L2 triggering
mechanisms.

We have deliberately tried to indicate reasonable
scenarios where ECS will not provide good movement detection.
It is worth noting here that L2 Triggering does not
completely overcome these issues, although section 3.4
describes a heuristic where the MN becomes eager after
receiving an L2-UP (association?) trigger.

This will give the MN good movement detection performance
but may cause spurious handovers if the MN detects another router
from the link it already has an address configured from.

Do you think that it needs to be moved into the discussion
of current movement detection, rather than as an optimization?

It may be worth revisiting this, and describing the applicability
of ECS in (for example) guaranteed single router links like PPP.

> are on different physical links. Is this a valid deployment scenario? I find

Actually, this one didn't have the effect which we desired.

The idea was to convey that the back (fixed network) is
joined, so RAs from both routers are received on both
wireless cells.

I know that email is not a good medium for ascii diagrams,
please tell me if you can read this diagram and if it
improves the clarity of the network design.
A new caption is also attached.

            -------     -------
            | AR1 |     | AR2 |
            -------     -------
          A::1 |           | A::2
               |           |
           -----------------------
            |                 |
            |                 |
          /-------------\     |
         /               \    |
        /         /-------\-------\
        \        /         \       \
         \      /          /        \
Cell 1   \     \         / ------   \
Coverage  \-----\-------/  | MN |   /
                  \         ------  /  Cell 2
                   \---------------/ Coverage

Figure 2.  MN sees two access routers on the same link

    In Figure 2, AR1 and AR2 are routers on the same wired link.
    Each advertise a prefix A:: to hosts.  When the MN moves from
    AP1 to AP2, it changes AP and AR but remains in same IP subnet.

> I believe the caption should say instead: "Two Access routers on the same

Correct. We'll update this.

> around the same time, etc.).

I think I see your point, but reception of an RA without that CoA's
prefix (but from the same router) does not indicate that the
prefix is invalid, only the prefix lifetime can modify this.

Reception of a unicast RA implies a solicited response, but this
is not important if there the received RA advertises the prefix
used by the MN for CoA configuration.

Would it be better to change the text in the following way?:

"
Hence MN also has to confirm the validity of the current CoA by
checking on-link prefixes.  The MN sends a unicast RA to current AR.
After sending an RS, when an RA with arrives, the MN checks whether
it contains the prefix of current CoA in any of its Prefix
Information Options.

It is possible that a received RA directed to the multicast address
is not a solicited RA. In this case it may not contain all Prefixes
on the link.  Therefore reception of a multicast RA can not imply
prefix unavailability through absence of the MN's configured prefix.
Conversely, reception of an on-link prefix in an RA always implies
its validity.
"

> "likely" instead of "highly probable".

Thanks for that. I agree with your assessment about the QoS.
I'm not sure about the eventual deployment of RAs being
unicast or multicast, but we're looking at today's situation.

> is still on-link and hasn't actually moved.

I'm sorry that the paragraph is confusing.

There is an error in the description of the AdvDefault
What we're describing here is not the MN case, it is for
existing fixed (RFC-2461 only) hosts.  MN's are capable of
understanding the new rates of advertisement, since
they know the rates can go down to MaxRtrAdvInterval=70ms.

Since RFC-2461 Section 6.1.2 describes that Router Lifetime is
typically specified using AdvDefaultLifetime, and that this
is minimum 3 * MaxRtrAdvInterval, this is still under a second
with MIPv6 advertising Intervals.

Non-MIPv6 nodes could get confused if they see that the
Router Lifetime set below those legal in RFC-2461.
MIPv6 is new and should interoperate with existing
deployed protocols, so this draft is advising routers
not to advertise lifetimes below the original minimum values
specified in RFC-2461.

I know that 'radvd' had some difficulties calculating
Router Lifetimes when we put advertisement intervals to MIPv6
levels. I think that there is some danger for existing nodes,
if their (draft) standards based assumptions are undermined.

Does this description clarify things?

If it does, I'll try to come up with alternative text which
conveys the issue appropriately.

> bidirectional reachability with this outer, ..."

Oops!

> randomization that no additional randomized solicitation delay should be

It is also likely that the MNs are synchronized on the same event,
that is the last received beacon packet from the old L2 AP.
Even if the link association access procedures provide some 
serialization, they may be insufficient to avoid multicast
bombing if nodes are configured to send RS on L2-UP (which
we consider likely in some environments).

The simultaneous RA reception issue is mentioned in the third
paragraph of Page 17.  The issue is not principally with ECS,
it is with nodes autoconfiguring addresses based on any
received RA.  Initial tests here with around up to 100 simulated
nodes seem to indicate that there is increased risk of packet loss
when many nodes simultaneously transmit (in this case due
to address configuration, without MIPv6) on a WLAN.

It is worth noting (and is not in the draft) that there
is little or no difference to 802.11 MAC whether the packets
from the MNs are multicast RS (at 1Mbps) or unicast NS(at 11Mbps),
when many nodes simultaneously attempt to transmit.
The chance that there is a collision in any particular slot
goes up dramatically with the number of nodes attempting to
transmit.  It may take a shorter time, but packets are still
likely to be lost.

Therefore, it may be necessary to delay unicast NS messages
to previous access routers in the same fashion on this MAC
(which would slow movement detection even further).

When I have something to publish on this, I'll tell you,
but I don't think that we'll change this section yet
(We'll keep it monitored though).

> sends (including beacon RAs).

This is valuable, if there's not disjoint sets of addresses
in RAs advertised by different routers on the link (as is
explicitly allowed in RFC-2461).
We actually explored this issue ourselves, but it will
cause N handovers for each of N routers advertising a different
prefix with R-bit on a network (especially if there is no
overlap between any of the prefixes).

Brett, JinHyeock and I have a proposal which addresses this
issue generally which should be out in a draft by the end of
the week.

Please stay tuned.

Greg

---

From: Greg Daley <[email-masked]>
Date: Thu, 29 May 2003 13:01:02 +1000

Hi JinHyeock & Ed.

JinHyeock Choi wrote:
[most of Ed's email cut]
> (or impose) the condition of a single router per a link? 

I guess not, but we can possibly describe the situations above where
ECS is valid (single router topologies).

> Then even though each link has only one router, ECM may result in continual 

This is easier to handle:

Different interfaces are treated individually.
It becomes a preference choice for hierarchical handoffs
between technologies, or provides redundancy for
two interfaces of the same preference.

We can put a statement in about detecting movement
with a second (redundant?) interface though.

> | Router|________________________________________

I think that the essential issue here is that no-matter where you
attach on the bus/link, you will receive RAs from both routers.

When the bus also L2 WLAN access points/bridges attached to it
all the nodes connected to these cells also receive both RAs
--> they are the same link.

> | Router|________________________________________

I agree, multilink subnets are horrible.
We'll probably have a look at this if people actually
start deploying them, I think it would over complicate things
to introduce them today.

Do you agree?

Greg

---

From: "James Kempf" <[email-masked]>
Date: Thu, 29 May 2003 08:41:03 -0700

What about a bridged subnet?

        jak

----- Original Message -----
From: "Greg Daley" <[email-masked]>
To: "JinHyeock Choi" <[email-masked]>
Cc: "Ed Remmell" <[email-masked]>; "Mobile-IP"
<[email-masked]>
Sent: Wednesday, May 28, 2003 8:01 PM
Subject: Re: [mobile-ip] Movement Detection Optimizations draft (01)
submitted.

> > |______|                        |
|
> >                                  __|____                       __
|____
> >                                 | Access|                       |
Access|
> >                                 | Router |                       |
Router |
> >                                 |___1__|
|___2__|
> >                                      |
|
> >                            A::      |
|      A::
> > |______|                        |
|
> >                                  __|____                       __
|____
> >                                 | Access|                       |
Access|
> >                                 | Router |                       |
Router |
> >                                 |___1__|
|___2__|
> >                                      |
|
> >                            A::      |
|      A::
> >                                  __|____                       __
|____
> >                                 | Access|                       |
Access|
> >                                 | Point   |
| Point   |
> >                                 |___1__|
|___2__|

---

From: Greg Daley <[email-masked]>
Date: Fri, 30 May 2003 08:29:47 +1000

Hi James,

> What about a bridged subnet?

I don't really see that there will be any problems
with bridged subnets.

Bridges are uninterested in the type of traffic given
to them and will transfer unicast or multicast
anywhere in the domain covered by the spanning tree
(all nodes on the link).  This results in a logical
bus network.

It works just fine with switched ethernet
(the most common bridging technology today).

There are wireless point-to-point bridges,
but these have the same general characteristics
as wired bridges (except packet loss and (in the
old days - late 1990s) narrower bandwidth).

Current 802.11 APs are bridges, but they are
assymetric (unless the WDS is in use), and do not
transit packets between cells using the wireless link.

If the WDS is in use, then we have a Wireless link,
with a logical point-to-point bridge tucked behind it.
I'll check if there are any unusual issues with this,
but it shouldn't cause major hassle.

Greg

>>>Yes, ECM doesn't work well for the case of multiple routers per a
>>
> link.
> 
>>>We implemented ECS and it broke down in that situation. Can we
>>
> assume
> 
>>>I also worried about the the case of MN with multiple connection.
>>
> For
> 
>>>example, assume a MN has both 802. 11 b interface and CDMA
>>
> interface.
> 
>>>Then even though each link has only one router, ECM may result in
>>
> continual
> 
>>>BUs.
>>
>>>>I can see why ECS is attractive to those who want to see broader
>>>
> support for
> 
>>>>MIPv6, because it requires fewer changes to the kernel, and does
>>>
> not take
> 
>>>>advantage of L2 triggers so requires no special integration with
>>>
> L2, the
> 
>>>>device driver, etc. However, please let's not assume that the
>>>
> entire world
> 
>>>>will convert over to some form of embedded Linux - proprietary
>>>
> RTOS is not
> 
>>>>dead (I know of a very successful manufacturer of a large family
>>>
> of
> 
>>>>networked laser printers who still uses their own proprietary RTOS
>>>
> in those
> 
>>>>products, with our embedded networking stack I might add), and
>>>
> there is
> 
>>>>still a need for our sort of embedded protocol solutions which are
>>>
> faster
> 
>>>>(with latency characteristics suitable for hard real-time
>>>
> applications),
> 
>>>>smaller (easily an order of magnitude smaller than the smallest
>>>
> embedded
> 
>>>>Linux both w/ respect to ROM and RAM usage), and independent of
>>>
> RTOS,
> 
>>>>packaged for easy integration with a customer's
>>>
> preemptive/non-preemptive
> 
>>>>proprietary RTOS (as well as support many off-the-shelf RTOS'es as
>>>
> well as
> 
>>>>accessible through different APs. What you are saying (I think) is
>>>
> that
> 
>>>>there are two access routers broadcasting the same on-link prefix,
>>>
> yet they
> 
>>>>are on different physical links. Is this a valid deployment
>>>
> scenario? I find
> 
>>>>it pretty confusing.
>>>
>>>
>>>I agree that this is complicated. What we had in mind is that two
>>
> routers
> 
>>>on a same link, not in wireless link but in wired link. For
>>
> example they
> 
>>>I am not sure but, IMHO, we'd better not to deploy like above. It
>>
> gave us
> 
>>>lots of problems. I am thinking about the condition on which two
>>
> interfaces
> 
>>>of routers (whether they belong to one router or two routers
>>
> separately) can
> 
>>>Wireless link is not as clear cut as wired one, hence
>>
> complication.
>

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 30 May 2003 09:22:29 -0700

Greg -

> ECS is valid (single router topologies).

Please do so, given that it seems like ECS will be a very popular movement
detection algorithm (it is the default mode for MIPL, since it doesn't
require any kernel hacks but can be performed entirely at L3 w/out any L2
triggers).

> two interfaces of the same preference.

Yup, I totally agree. In our MN implementation, the user appplication is
responsible for telling the MN which interface is currently being used as
the "mobile interface" to perform Router Discovery on, we will not discover
or use a default router on any other interface.

> > are connected to the same border router.

OK, I follow now. Yes, this is a valid deployment scenario. I can see these
routers as originally being wired, and made wireless by connecting a LinkSys
WET11 to their Ethernet cards, which means that they each have their own
wireless access point even though originally they were on the same wired
link.

Thanks.
- Ed

---