Subject: [mobile-ip] closing issue #281 (erik's and steven's technical comments on base)

From: Jari Arkko <[email-masked]>
Date: Sun, 20 Apr 2003 18:55:19 +0300

Hello,

I'm trying to close issue #281, which consisted of the technical comments
Erik Nordmark and Steven Bellovin made on the Mobile IPv6 base specification
some weeks ago. This e-mail proposes fixes to all the raised issues,
except one that I'm still discussing with Erik and Gabriel (more on that later).

 > 11.3.5 Should some sort of timeout be associated with the fact that
 >        a certain destination address can't accept Mobility Headers?

Yes. Change the text in 11.3.5 to the following:

    If the mobile node receives such an ICMP error message in response
    to a return routability procedure or Binding Update, it SHOULD
    record in its Binding Update List that future Binding Updates
    SHOULD NOT be sent to this destination. Such Binding Update List
    entries SHOULD be removed after a period of time, in order to allow
    for retrying route optimization.

 > 11.7.2 Same comment about sequence number processing

The current sequence number processing between mobile nodes and
correspondent nodes does not require storing sequence numbers for a
long a time. The sequence number information can be safely deleted
upon deleting the binding. For a detailed discussion of this, see
Section 5.2.8 of the base specification.

 > It makes sense to make it more clear that the specification doesn't
 > prevent a MN from having multiple home addresses.

I added "Mobile nodes can have multiple home addresses, such as when
there are multiple home prefixes on the home link." to the definition
of a home address. I also changed "home agent" to "home agent for a
given home address" in the definition of a care-of address.

 > Section 2:
 >
 >    o The movement detection mechanism in Mobile IPv6 provides
 >      bidirectional confirmation of a mobile node's ability to
 >      communicate with its default router in its current location.
 >
 >   But this is not sufficient when there are more than one router
 >   on the visited link.

If there is packets coming back to the mobile node through multiple
routers, and if there's no bidirectional connectivity to all of them,
some packets may be dropped. This has been discussed on the list, and
James Kempf proposed a network design which avoids this problem. But
I'd like to note that this isn't an issue that is introduced by Mobile
IPv6 as such.  In fact, the problem appears even with stationary hosts
connected over wireless links to multiple routers. In my mind, the
right thing to do is to warn people of this problem in the
document. Sounds like solutions (beyond taking this into account in
network design) need more work though, and have to consider not just
MIPv6 but IPv6 and wireless links in general. Here's the proposed
addition to the end of 11.5.1:

     Note that while symmetric reachability to the default router is
     necessary, it may not always guarantee that all inbound packets
     reach the mobile node. If there are multiple routers on the link
     with the same advertised prefixes, inbound packets may be routed
     through any of these routers, and neither IPv6 Neighbor Discovery
     for stationary hosts or Mobile IPv6 can guarantee that all these
     routers can reach the host. One way to avoid this situation is to
     design wireless networks in a manner where either the routers use
     distinct prefixes, or all routers communicate through the same
     wireless transmitters.

Finally, we should stick to RFC 2481 terminology. I changed
"bidirectional confirmation" to "symmetric reachability".

 > I haven't seen any discussion of the duplicate address detection
 > changes in section 7.6 in the IPv6 WG.
 > While these changes seem harmless I'm concerned about them being

After a discussion with Erik, I think we have agreed that Section 7.6
isn't really about changes to DAD. However, it would be useful to
explicitly ask the IPv6 WG for an opinion about the specified way to
use DAD. I will send an e-mail to the ipv6 WG mailing list about this.

 > 7.5 Those advertisement frequencies scare me -- they're quite high.
 >     Worse yet, the most likely place they're needed -- microcells --
 >     have limited bandwidth.

These frequencies are the highest ones allowed by our limits. They are
not defaults. In Section 7.5 it says "Systems where these values are
available MUST NOT default to them, and SHOULD default to values
specified in RFC 2461. Knowledge of the type of network interface and
operating environment SHOULD be taken into account in configuring
these limits for each network interface. This is important with some
wireless links, where increasing the frequency of multicast beacons
can cause considerable overhead." I think this adequately warns the
reader about the default use of the highest possible frequencies.

Moreover, most people would agree that some L2 knowledge should be
employed to implement efficient movement detection. Solutions in that
space are coming, I'm sure, for instance on the type of technology
that would find it difficult to do L3 advertisement frequently.

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 22 Apr 2003 01:46:32 +0200 (CEST)

> addition to the end of 11.5.1:

The problem I have is 
1) the document claims to solve this problem for traffic to/from the routers
   when in fact it does not
2) Section 11.5.1 introduces unneeded complexity (observing which packets
   arrive from the router presumably by inspecting the source link-layer
   address of all packets) in its failed attempt to solve this problem.
   I think that complexity should just be deleted.

Thus deleting things from 11.5.1 is better than adding.
The 4th paragraph in 11.5.1 doesn't seem to be needed.
Same for the 6th paragraph (which spans a page break).
Detecting that the MN  is reachable from the router isn't useful when 
the the router isn't reachable from the MN.
Same for 7th paragraph - switching to RS probing just because the router
doesn't send packets isn't useful unless the MN has reason to believe that
packets are dropped. NUD already performs this function.

  Erik

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 21 Apr 2003 18:41:37 -0700

Erik -

> 1) the document claims to solve this problem for traffic to/from

OK. I agree that some issues introduced by wireless can't be solved by
MIPv6, that seems reasonable.

>    I think that complexity should just be deleted.

I'm almost OK with deleting the stuff about the optional use of promiscuous
receive mode to sniff for any and all packets sent on the link by the
default router (even to other nodes),
*** BUT the MN detecting reachability from the router is important, so I
still feel pretty strongly that it needs to be discussed in this spec (i.e.
you need to keep things like the Advertisement Interval being used by the MN
to detect some number of RAs dropped in sequence, etc.). You want to avoid
the following scenario (which NUD by itself cannot detect):

1) MN is not actively sending any packets, but registers a mobility binding
with the home agent with a fairly long (i.e. 3 hours or more) lifetime.

2) MN moves to a new link, but the link-layer doesn't notify MIPv6 of
movement.

3) Since MN is not actively sending any packets through the default router
(on the old link), the MN doesn't start NUD probing of that router (note
there was no L2 trigger to notify the MN of link movement), therefore the MN
doesn't realize that it is no longer reachable from the default router. The
MN is now blissfully unaware that it is actually on a new link, and it is no
longer reachable from its router.

4) CN sends packet to MN's home address, which HA tunnels to MN's primary
CoA on old link. MN is no longer there to receive this packet. This is a
permanent loss of network connectivity for the MN, at least until it
initiates sending a packet through the default router.

So, the current specification text for why this is needed isn't completely
accurate, because it isn't the real reason (in my mind, at least) why
checking for reachability from the default router is needed:

"For a mobile node to detect when it has become unreachable from its
   default router, the mobile node cannot efficiently rely on Neighbor
   Unreachability Detection alone, since the network overhead would be
   prohibitively high in many cases."

Nope, it isn't just a matter of reducing network overhead. Let's say that
the MN above was a cell phone, MIPv6-enabled. Now, as a previous cell phone
user/owner, I can say for sure that if I'm not actively using my phone to
make calls but I have it turned on, I certainly want to still be able to
receive calls and/or connection requests on it initiated from the network,
even if I move and take it with me somewhere else (i.e. move to a new link).
If you remove the functionality of the MN checking for reachability from its
default router, w/out L2 triggers to notify MIPv6 of link movement you will
very easily create the scenario described above, and then my cell phone
won't be able to receive network-initiated calls after I've travelled a mile
or so away from home.

> the the router isn't reachable from the MN.

This seems to make sense on the surface, but it is wrong. You really need
both. Either you need a reliable L2 trigger to inform MIPv6 of link movement
so it can immediately start probing its default router to see if it has in
fact moved (likely NUD probing in this case), or you need the MN to support
being able to detect that it is still reachable from its default router.
Then, you MAY also need NUD, to confirm that the other direction (router is
reachable from the MN) is also working, but this is really only needed if
the MN is actually trying to send data through the default router.
Generally, the MN will also be sending data through the router at the same
time as it is receiving data from the network, so generally you will need
both mechanisms. However, if for a period of time (i.e. a couple of hours)
the MN doesn't need to send data through the router, but instead receives
data from the network during that same period (i.e. UDP multicast, etc.),
then it doesn't matter that the router is reachable from the MN, only that
the MN is reachable from the router. Note that once the MN starts trying to
transmit data through the router, the Neighbor Cache entry for the router
transitions from the STALE to the DELAY_1ST_PROBE state, then after a 5
second delay the MN will start active NUD probing of the default router.

> packets are dropped. NUD already performs this function.

Actually, the 7th paragraph says the MN probes using NS, not RS. This is
exactly NUD probing. Essentially, what this says is if the MN believes that
link movement has occurred, it immediately skips the NUD DELAY_1ST_PROBE
state, immediately sends the first NUD NS probe, and then transitions into
the NUD PROBE state w/ regards to actively probing the default router with
NS. The fact that the MN is no longer reachable from the router is enough
reason to initiate this NUD NS probing. This functionality is really
necessary, if the MN does not have dependable L2 triggers to notify it of
all link movement events. Please do not consider removing it, unless you
also want to state in this specification that all MIPv6 MNs MUST have
completely reliable L2 triggers that notify the MN of all potential link
movement events.

Thanks.
- Ed Remmell
Elmic Systems, USA

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Apr 2003 16:17:25 +0300

I'm trying to summarize the discussion. Here's what I think was
Erik's original problem:

   1) Section 2 states "The movement detection mechanism in Mobile
      IPv6 assures symmetric reachability between the mobile node
      and its default router in the current location." Strictly
      speaking, this is incorrect. Only NUD provides assurance of
      symmetric reachability. What is described in the movement
      detection section is something else, one-way reachability
      (more on that below). Of course, we also use NUD, but the
      Section 2 text is written as if it wasn't about NUD.

   2) There's a "hidden terminal" problem with inbound traffic
      and multiple routers. Mobile IPv6 does not solve this,
      and it shouldn't attempt to.

   3) There's a mechanism for detecting "one-way reachability"
      in the movement detection section. This mechanism
      may have the following problems (I wasn't quite sure
      Erik which ones you had in mind):

         3a) The text confusingly claims this provides
             symmetric reachability (it does not provide
             it).
         3b) The mechanism works only for the default
             router, and hence can't really prove
             even one-way reachability if there are
             multiple routers.
         3c) Lack of payload traffic is not a proof
             of a lack of reachability; maybe there
             just was no traffic.
         3d) Tracking the RAs is sufficient, no need
             for tracking other packets.
         3e) How can we track packets with link-layer
             source address being the default router,
             if the default router happens to use
             multiple interface cards?
         3f) This is a real issue, but we need to
             solve it in a general way for IPv6.

How do we move forward? I think we can easily agree on
how to fix Erik's problems 1 and 2. In problem 1, the
text in Section 2 should be reformulated to "IPv6 Neighbor
Unreachability Detection assures...". In problem 2, we
can change the first bullet item from Section 1 into
"Handling links with unidirectional connectivity or
partial reachability, such as hosts hidden from only
some of the routers on the link."

Problem 3 is trickier. As Ed noted, showing one-way
reachability is valuable at the times the mobile node
is not sending anything. IF you can show that the
router can reach you, then there's no need for the mobile
node to send any packets e.g. in NUD. This of course
would improve performance particularly if there are a lot
of silent nodes on the same link. Still, we'll have
to deal with 3a-3f. Here are the possibilities:

Judging from the various e-mails that have been sent,
I think we agree with Erik that we should keep at least the
tracking of RAs and advertisement lifetimes. The question
is what else should be kept, and how to respond to 3a-3f.

   Solution 1. Just keep track of RAs + NUD when necessary.
   Solution 2. Keep track of RAs, and also track
               all packets with the link-layer
               source = default router. Do NUD when
               necessary.
   Solution 3. As above, but make put the interface
               in promiscious mode.

My personal preference is Solution 2, but I'm willing to
accept Solution 1 if necessary. In the following I'll
make a tentative attempt to seeing how we could respond
to the issues 3a-3f for Solution 2:

         3a) Just fix the text. Maybe start the 4th
             paragraph with "For a mobile node to detect
             when it has become unreachable from its
             default router at times when it is not sending
             any packets itself, the mobile node cannot
             efficiently rely on ..." And then later in
             paragraph 7th, replace the current NS/NA
             text simply with "... SHOULD use NUD to ...".

         3b) Yes, we didn't fix this problem but as
             described above we can explain this in
             Section 1. Lets solve this in an orthogonal
             way somewhere else.

         3c) Lack of traffic leads to the unless clause
             in paragraph 7, i.e. use NUD. If there is
             traffic, then we can confirm one-way
             reachability even without NUD.

         3d) Tracking RAs produces around ~100 ms delay
             for detecting possible movement if you assume
             at most one RA may be lost. If you track
             other traffic on the link, you can detect
             a possible move earlier. But in any case,
             after detecting a possible move you
             need to use NUD (which has long timers)
             and Router Discovery (which might take time
             to complete). So I'm not quite sure what
             the final time to complete movement will
             be in the different alternatives. Has someone
             measured the movement detection times with
             and without payload traffic tracking?

         3e) We can't track all packets from the router
             if it uses multiple link-layer addresses.
             However, remember that the tracking provides
             only a positive proof, and if there's no
             packets then we use NUD per paragraph 7.

         3f) I don't have a good answer to this. Maybe
             the answer depends on how well MIPv6 behaves
             without this tracking. I'm pretty sure that
             without RA tracking its unusable. But we're
             not discussing that. If it performs reasonably
             well, then we can take the time to do a general
             solution for IPv6. If the performance is really
             bad in terms of typical MIPv6 applications,
             then I'd rather have a solution in the current
             spec.

Jari

P.S. I moved this part of the issue (the one-way reachability)
under issue #297 to keep it separate from the rest of the
stuff in #281 which I think was solved.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 22 Apr 2003 08:36:36 -0700

Ed,

I hesitate to wade in on this discussion because there seem to be some
strongly held opinions around, but I think this problem is primarily
one of proper network configuration, and I don't see the necessity of
complicating the protocol spec by including text that compensates for
people who what to configure their networks in ways that are less than
optimal. In general, IETF protocols don't have to include support to
prevent people from misconfiguration, that's left up to the network
operator. If some set of configuration parameters seems better than
others, a Best Current Practices (BCP) document is the recommended
approach. BCPs go through the same level of IESG review as Proposed
Standards and have the same weight. A BCP for the particular case
you're describing would therefore be a possibility, or perhaps even
something more comprehensive, covering good wireless network
configuration in general.

            jak

----- Original Message -----
From: "Ed Remmell" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>; "Jari Arkko"
<[email-masked]>
Cc: "Thomas Narten" <[email-masked]>; "Mobile IPv6 mailling list"
<[email-masked]>; "Gabriel Montenegro" <[email-masked]>
Sent: Monday, April 21, 2003 6:41 PM
Subject: RE: [mobile-ip] Re: closing issue #281 (erik's and steven's
technical comments on base)

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 22 Apr 2003 09:55:29 -0700

FWIW, I strongly agree with Ed here.

Vijay

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 22 Apr 2003 09:38:22 -0700

James -

Yes, I completely agree with you on this. The "hidden terminal problem" is a
problem with network configuration, not any issue that MIPv6 should try to
solve.

Thanks.
- Ed

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Tuesday, April 22, 2003 8:37 AM
> To: Ed Remmell; Erik Nordmark; Jari Arkko
> Cc: Thomas Narten; Mobile IPv6 mailling list; Gabriel Montenegro
> Subject: Re: [mobile-ip] Re: closing issue #281 (erik's and steven's

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 22 Apr 2003 09:36:03 -0700

Jari -

Awesome job. Thanks for paying attention and resolving all of the
conflicting input. I know this one is a difficult one to get right.

Please see my comments inline below.

Thanks.
- Ed

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jari Arkko
> Sent: Tuesday, April 22, 2003 6:17 AM
> To: Ed Remmell; Erik Nordmark
> Cc: Mobile IPv6 mailling list; Gabriel Montenegro
> Subject: Re: [mobile-ip] Re: closing issue #297 (erik's and steven's

Yes.

>       and it shouldn't attempt to.

Agreed.

>              multiple interface cards?

I don't mind if you entirely remove the optional "sniffing" functionality of
the MN checking other received packets besides RAs to see if they were sent
by the default router. However, I think it (and the extra option of using
promiscuous mode for the same purpose) is useful information to help
implementors understand MIPv6 generic movement detection better. That
doesn't necessarily mean that they implement any of this optional
functionality. Personally, the only part that we are implementing in our MN
is looking at RAs, and then only per the Advertisement Interval and we don't
actually check for any match on the source link-layer address only the
source IPv6 address of the RA.

Just FYI, we have (for now) decided not to implement the following in our
generic embedded systems MN:
   "Instead, when a mobile node
   receives any IPv6 packets from its current default router at all,
   irrespective of the source IPv6 address, it SHOULD use that as an
   indication that it is still reachable from the router."

Instead, we leave this up to the user as described by this footnote in our
MIPv6 requirements spec (the tfNg APIs are our public APIs that support both
IPv4 and IPv6, also our IPv6 Router Discovery will callback the user with
the link-local scope IPv6 address of the current default router):
"4.	This does not provide confirmation of bi-directional reachability, which
is what NUD is for. The user could implement this functionality in their
device driver and application. If they want to start active NUD probing of
the current IPv6 default router, they could call tfNgPingOpenStart to ping
the IPv6 default router, which will accomplish the same thing. They can call
tfNgGetArpEntryByIpAddr to get the link-layer address of the IPv6 default
router, if they know its IPv6 address, and then examine received frame
headers in their device driver receive ISR to see if there is a match, in
which case they could set a flag to indicate that the mobile node is
reachable from the default router. They can obtain the IPv6 address of the
current IPv6 default router by registering a notification function for the
Mobile Node event TM_6_MNE_SET_NEW_RTR when they call tf6MnStartMobileIp."

> some of the routers on the link."

Perhaps you should also reference "hidden terminal problem", as in:
	This is commonly known as the "hidden terminal problem".

> to the issues 3a-3f for Solution 2:

I'm OK with any of these. I think that the additions in #2 and #3 contain
useful information to help MN implementors understand what their different
options are, so generally I think all of this text should be kept (including
the note about the option of using promiscuous mode). However, as mentioned
above, currently we only implement #1 in our generic MN (i.e. montoring for
received RAs from the default router per the Advertisement Interval).

>              text simply with "... SHOULD use NUD to ...".

Looks good.

>              Section 1. Lets solve this in an orthogonal

Yes.

>              reachability even without NUD.

OK.

>              and without payload traffic tracking?

You skip the NUD DELAY_1ST_PROBE 5 second delay, and immediately enter the
NUD PROBE state, sending the first NUD NS probe as you do so. The, per the
defaults, it takes 3 seconds (sending 3 NS probes, plus waiting 1 second for
each to see if you receive the solicited NA) to determine that the router is
unreachable and remove the Neighbor Cache entry. I agree this is slow,
however TCP sockets will survive such a move. Also, if you want better
handover performance, implement L2 triggers for move detection.

>              packets then we use NUD per paragraph 7.

Yeah, I'm not to happy about checking received packets for a match on the
router's link-layer address myself, that's mainly why we didn't implement
this and instead we left that functionality up to the user. However, as I
said above it is still useful information for implementors, since on some
network types this will be a good move detection mechanism to use. Perhaps
it shouldn't be a SHOULD but instead should become a MAY requirement, i.e.:

   "Instead, when a mobile node
   receives any IPv6 packets from its current default router at all,
   irrespective of the source IPv6 address, it MAY use that as an
   indication that it is still reachable from the router."

>              then I'd rather have a solution in the current

If you have good L2 triggers, then you really don't even need the MIPv6 RA
tracking. You get a L2 trigger notifying MIPv6 that a potential link
movement event occurred (either L2 move or L3 move), MIPv6 can then
immediately start actively probing the default router using NUD.

Thanks.
- Ed

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 23 Apr 2003 03:20:10 +0200 (CEST)

> I'm trying to summarize the discussion. Here's what I think was

You didn't list section 1 saying:
   o  Handling links with partial reachability, or unidirectional
      connectivity, such as are often found in wireless networks (but
      see Section 11.5.1).
The "but ..." seems to imply that 11.5.1 solves a subset of this
problem when in fact it does not.

>              solve it in a general way for IPv6.

What I've said is a combination of 3a, 3d, and 3f and also
that it isn't useful to track one-way reachability since the MN needs
bidirectional reachability in order for higher level protocols to function.

But Ed pointed out something I hadn't though of.
If the application traffic is such that (at least for periods of time)
the MN is only receiving packets there might be a performance optimization
to be able to detect loss of inbound reachability quicker than detecting
loss of outbound reachability.
With this traffic pattern the MN might be happy to continue to use a router 
as long as it is receiving packets from the router and only invoke NUD
when it is trying to send packets.
(In fact, NUD is only invoked when a node is trying to send packets.)

What I think this translates to is the observation that when no packets are
seen from the default router the MN might suspect loss of inbound reachability
before NUD would detect loss of bidirectional reachability.
I think that is a reasonable optimization.
Note however that the current text says the logical opposite; that NUD can be 
avoided as long as the MN hears the default router.

> node to send any packets e.g. in NUD. 

WAIT. NUD doesn't send any probes unless there are data packets to be
sent.
And your logic is backwards per above. You must do the NUD otherwise
outbound packets will be dropped on the floor when there is a loss
of outbound (from MN to R) reachability.

> This of course
> of silent nodes on the same link.

I don't understand this since NUD probes only occur when needed.

> Still, we'll have

I think you should say "Does not effect when NUD is needed; might trigger 
movement detection earlier than NUD by itself."

>    Solution 3. As above, but make put the interface

I don't have any preference between 1, 2, and 3 as long as 2 and 3 are
fixed so that they don't modify when NUD is applied and only serve as an
early movement hint.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Apr 2003 17:22:01 +0300

> problem when in fact it does not.

Yes, I noticed this too yesterday. The "but" has been removed now.

Yes.

> avoided as long as the MN hears the default router.

It needs to get fixed then ;-) I'll work on it.

> movement detection earlier than NUD by itself."

Ok.

> fixed so that they don't modify when NUD is applied and only serve as an

Perhaps its best then that we keep the current set of tracked things,
but modify the text according to your suggestion. There's a set
of things from layer 2 and layer 3 that can act as a hint that
a movement may have occurred.

I do have a question though. Current text says that even if you
don't have packets to send, you will send NS/NA probes to the router
if the inbound reachability is suspect. So, is "triggering
movement detection" to you only observing the received RAs and
making a decision, or can it include an active probe as well?
If no, tracking the data packets isn't very useful since we
can't learn anything before a RA arrives anyway. If yes, should
we probe with NS/NA or RS/RA?

Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 25 Apr 2003 09:53:08 -0700

> we probe with NS/NA or RS/RA?

IMO, you should probe with NS/NA, per NUD. Unless something like Fast RA is
implemented, there will be a delay before you get the answering RA to your
RS probe, and then you can't tell that it was the answer to your
solicitation since in many cases it will be to a multicast destination. If
you probe with NUD, you get an immediate confirmation of bi-directional
reachability, which is what you really want.

Thanks.
- Ed

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 25 Apr 2003 21:32:36 +0200 (CEST)

> we probe with NS/NA or RS/RA?

Sending NS/NA probes when things are silent might be a very bad idea
since it is likely to create a background load of, perhaps useless,
chatter.

An interesting case here is when there
are two (or more) routers which the MN can hear (and they advertise
different prefixes). When and how does the MN decide to move
if it has no data to send?

As long as it can hear the current router (at L2 or L3) it has little
need to switch. Does this imply that, when there is no usable L2
indication of "can hear" available to L3, that frequent L3
RAs are needed? I think so unless you want the background chatter
from the MNs.

  Erik

---

From: "JinHyeock Choi" <[email-masked]>
Date: Sat, 26 Apr 2003 11:41:54 +0900

Jari Arkko wrote 
 
>              and without payload traffic tracking?

I anlyzed the current Movement Detection process and time in below, correct me 
if wrong. (We assume that MN has actually moved to a new link and AR.)  

I define the Movement Detection time as the time required to check 
1) The reachability of current AR
2) The validity of current (primary) CoA

Step1) Hint
There is a set of hints that can indicate that an L3 movement has occurred. The hints 
can be L2 trigger, or the receipt of a new RA. This hint itself doesn't indicate L3 movement.

The time for this varies. With L2 trigger support, it can be done instantly. Without L2 
trigger, it depends on the frequency of Router Advertisement interval. 

With payload traffic tracking, we may get a hint earlier. MN may implement its own 
policy to determining 'the interval of idle time with no traffic' which it will interprets as 
hint for possible movement. 

Step2) NUD with the current AR
MN checks whether current AR is still reachable by NS/ NA exchange. 

This will take 3 seconds to detect that the current AR is not reachable as Ed wrote 
(sending 3 NS probes, plus waiting 1 second for each).  

With NUD, you can detect 'something (Router or Host) is there' very fast. But it takes 
substantial time (3 Sec) to detect 'something is NOT there'. IMHO, this is problem for 
handoff delay.

Step3) The Router Discovery with new AR.
MN performs Router Discovery with a new AR using RS/ RA exchange. MN sends 
a RA and ,when a solicited RA with all options arrives, MN can confirm the validity of 
current CoA. 

Without an optimization scheme (i.e. Fast RA), this will take 0.75 sec average 
(1 sec random delay before sending RS and 0.5 sec random delay before replying RA)

There still remain ambiguities on Movement detection process and time. 

For example, for the below 
 
>> we probe with NS/NA or RS/RA?

Ed wrote

> reachability, which is what you really want.

But Erik wrote

> since it is likely to create a background load of, perhaps useless,

So should we use RS/ RA or NS/ NA for probing? Or is it up to implementation? 

I agree with Erik that the less is better than more for MD in MIPv6 basic. For 
optimization, I guess we need a separate draft. 

But, at least, I wish we present basic (without optimization) Movement Detection
process in clear and unambiguous way.

JinHyeock

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 25 Apr 2003 20:20:32 -0700

Erik -

Your comments are reasonable. Please see my opinions below.

Thanks.
- Ed

> [mailto:[email-masked]]On Behalf Of Erik Nordmark
> Sent: Friday, April 25, 2003 12:33 PM
> To: Jari Arkko
> Cc: Erik Nordmark; Ed Remmell; Mobile IPv6 mailling list

I agree with this. However, I don't think we need to be too explicit in the
MIPv6 base spec about this, perhaps this is a guideline for implementors or
a best practice?

There should be some L2 triggers available to indicate potential link
movement. If there isn't that mechanism, then RA beacons should be used.
Otherwise I agree with you that there could be too frequent NUD probing when
things are silent to confirm that we haven't moved.

> if it has no data to send?

A mobile node could decide (in L2, i.e. not a MIPv6 decision) to perform an
"undirected hop" to force switching to a different default router, even when
the current default router is still bi-directionally reachable, if it has
some information that the signal quality/etc. on the new link that it is
moving to is better than the signal quality on the old link. I'd think that
this could be implemented in L2 w/out MIPv6 being aware of anything besides
the fact that after the L2 move the current default router is no longer
reachable - additionally, L2 should notify MIPv6 of link movement in this
case using a L2 trigger to notify MIPv6 of either a change of link (L2 move)
or a change of subnet (L3 move). A L3 move notification would result in a
faster handover, because MIPv6 would then immediately assume that the
current default router is no longer reachable and will start soliciting (RS)
for a new current default router.

> need to switch.

Agreed.

> Does this imply that, when there is no usable L2
> RAs are needed?

I think so. To avoid the background chatter of frequent NUD probing w/out
having any packets to send.

> I think so unless you want the background chatter
> from the MNs.

Yes, I agree with you on this. But, I think it should be a guideline for
implementors or a best practice, rather than a hard requirement. Some of
this depends on the type of network. If the link won't have many mobile
nodes operating on it at any given time, then the extra overhead of the NUD
probing may be tolerable, and it works to detect movement in the absence of
RA beacons or L2 triggers.

Thanks.
- Ed

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 25 Apr 2003 20:23:40 -0700

I can go either way on this.

I agree that it isn't a good practice to do frequent NUD probing of the
default router when you have no data to send, however mobile nodes that
operate on links where there aren't frequent RA beacons and which don't get
link movement indications via L2 triggers may have no other good option
available to them (besides NUD probing) to quickly detect link movement.

Thanks.
- Ed

> [mailto:[email-masked]]On Behalf Of JinHyeock Choi
> Sent: Friday, April 25, 2003 7:42 PM
> To: Jari Arkko; Ed Remmell; Erik Nordmark
> Subject: Current Movement Detection Process and Time (Re: [mobile-ip]
> Re: closing issue #297 (erik's and steven's technical comments on base))
>
>
> Jari Arkko wrote
>

---

From: Jari Arkko <[email-masked]>
Date: Sun, 27 Apr 2003 15:40:23 +0300

> available to them (besides NUD probing) to quickly detect link movement.

At the very least, any probing MUST NOT be done unless the mobile node
has exhausted the other means listed in the section, such as listening
on all traffic. Otherwise it could easily congest traffic which is
flowing on the link simply because it didn't bother to check that
there's packets coming from the router ;-(

Secondly, it looks like the NUD timers are too long to
be useful in this case; the mobile node would be better off by
making a decision based on the lack of RAs, if we intend to provide
a faster scheme than that based reasonable advertisement intervals.

But as you say, its a problem if the current router does not provide
"reasonable advertisement intervals" (whatever they are) AND we
don't have layer 2 information. Basically, we enter a situation which
is not recoverable until the mobile node tries to send something.

So should we (a) require L2 triggers if mobile nodes don't want to
get into this situation (b) declare that this is an unfortunate
situation that we simply have to live with, or (c) provide a
(constrained) mechanism to do probing? Based on my notes above,
a constrained mechanism could ensure, for instance, that the
probes are not used if there's any traffic from the given router
on that link.

Jari

---

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 28 Apr 2003 20:37:58 +0900

Jari Arkko wrote

> probes are not used if there's any traffic from the given router

I agree that NUD takes too long for handoff. But, as Erik said, if we use 
RS/ RA exchange efficiently, we may perform NUD after handoff like below. 

Currently Movement Detection process is 
Step 1) Hint
Step 2) NUD with current AR
Step 3) Router Discovery with new AR

How about change 2) and 3) like this?
Step 1) Hint
Step 2) Router Discovery with all routers
Step 3) NUD with new AR

The rational is like this.  

Step1) Hint
There is a set of hints that can indicate that an L3 movement has occurred.  

Step2) Router Discovery with AR 
Instead of performing NUD with current AR, MN sends RS to the All-Routers 
multicast address.    

If current AR is still reachable, MN will receive a RA with all options within 
roughly 1.5 secs (RS random delay 1 sec and RA random delay 0.5 sec). 

We can't say that current AR is reachable if we receive a RA. But we can 
say that, if we don't receive a RA in time, it's highly probable that current 
AR is not reachable. 

If a RA arrives from current AR, MN can determine that it has not moved. 

If no RA arrives from current AR (after certain time) but MN receives several 
RAs from new ARs, MN chooses a new default AR. 

Though MN can't confirm reachability of new AR, the status is stale, so MN 
can start sending packets. Hence MN can perform further operations (forming 
CoA and sending BU).

Step3) NUD with AR
After IP configuration and BU signaling, MN can perform NUD with new 
AR to confirm the reachability in leisure. 

Though we have to elaborate how MN can deal with the inconsistency of  
RA information, I think the above works. 

JinHyeock

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 27 Apr 2003 05:09:29 +0200 (CEST)

> RA beacons or L2 triggers.

While in principle I don't have a problem with nodes doing a packet exchange
with the router to see if it is still reachable when the node has
some reason to suspect it might not be reachable (with strong advice
to avoid constant background chatter),
I think it might be confusing to call this NUD.
The reason for this is that NUD as defined in RFC 2461 is more than
a NS/NA exchange - it is also a state machine with e.g. a STALE state
and timers that default to 30 seconds before moving out of REACHABLE state.

This has impact on implementations. An implementation which does what
RFC 2461 says would need to have that code be tweaked if the node thinks
it is mobile.

I don't have a good idea how to resolve this...

  Erik

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 28 Apr 2003 09:32:36 -0700

Erik -

> I don't have a good idea how to resolve this...

NUD has states for the Neighbor Cache entries. What I'm proposing (and how
I've implemented it) is that the MN send a NS probe, and immediately
transition the Neighbor Cache entry for the default router to the PROBE
state, skipping the DELAY_1ST_PROBE state. Then, the way NUD works is it
will probe 3 times, delaying 1 second after each NS to receive the solicited
NA. So, that involves a 3 second delay to determine that the router is
unreachable.

Mobile IPv6 has an impact on mobile node stack implementations, there is no
easy way around it. For example, the routing lookup - the mobile node needs
to check the source address of outgoing packets to see if it is a registered
home address (it might be a CoA on the foreign link, and not a home
address), and then if so, see if the CN we are sending the packet to has an
active binding by looking at the BUL entries. This is all done before the
standard routing lookup. That is a significant modification to in IP-layer
routing. There is a similar modification on the CN. On the MN, there are
also MIPv6-specific modifications to the processing of ICMPv6 errors,
specifically ICMPv6 Parameter Problem error code 1 indicating that the
Mobility Header protocol is not supported - this requires a change to the
internals of ICMPv6.

Also, additional modifications are needed to MIPv6 MN to get it to
invalidate prefixes and CoAs that were discovered on the old link after
confirming successful movement to a new link.

MN return to home processing also has some interesting hacks to Neighbor
Discovery and IPv6 Address Resolution to support the case where the home
agent is still defending the MN's home address, including the derived
link-local scope address (home registration BU has L=1, link-local
compatibility bit set).

Making it possible for the MN to bypass NUD DELAY_1ST_PROBE to immediately
send the first probe and enter the PROBE state does not seem like a very
significant tweak to RFC-2461 behavior, considering all of the other
modifications to core IPv6 protocol behavior that MIPv6 MN requires.

But, see my reply to JinHyeock's email. I agree with him that RS/RA may be a
better recommendation.

Thanks.
- Ed

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 28 Apr 2003 09:56:29 -0700

JinHyeock -

> RS/ RA exchange efficiently, we may perform NUD after handoff like below.

If the MN immediately enters the PROBE state after sending the 1st NS probe,
then NUD takes 3 seconds to determine that the neighbor is unreachable.

> Step 3) Router Discovery with new AR

I do it this way for L2 move processing, when I don't know for sure that
there has been subnet movement but I suspect possible link movement (note:
it could be changing the access point w/out any change in subnet).

> Step 2) Router Discovery with all routers

I do it this way for L3 move processing.

> roughly 1.5 secs (RS random delay 1 sec and RA random delay 0.5 sec).

That is pretty slow. Considering that the NUD solution, if the MN optimizes
NUD as described above, only takes 3 seconds to confirm that the neighbor is
unreachabe. Also, the RS/RA method is not as guaranteed as NUD, since the
answering RA is multicast (in most cases) and therefore is not a
confirmation of bi-directional reachability (i.e. can't be confirmed to be
the solicited response to our RS).

> say that, if we don't receive a RA in time, it's highly probable

I'm OK with this.

> RAs from new ARs, MN chooses a new default AR.

I'm OK with this.

Yes.

> RA information, I think the above works.

So, you treat all link movement as a potential L3 move. I think using
optimized NUD (per above - immediately start probing) when no actual subnet
movement has occurred will be more efficient. But, what you are proposing
will work OK.

Thanks.
- Ed

---

From: "James Kempf" <[email-masked]>
Date: Mon, 28 Apr 2003 10:17:00 -0700

Erik,

> I don't have a good idea how to resolve this...

The state machine you describe is in Section 7.3.2 of RFC 2461 and it
seems designed primarily for hosts, where the node is sending a packet
to the IP address of the node.

However, Section 7.3.1  Paragraph 2 does say this about reachability
of routers:

        "For off-link destiations, forward progress implies that the
first-hop router is reachable"

Paragraph 3 goes on to state that probing using unicast Neighbor
Solicitation messages to verify that the forward path is still working
should be used if no upper layer hints are available, as would be the
case for a router.

Presumably, a node that wants to probe the reachability of a router
would have to obey the same state machine, by probing the router's
link local address from the RA, as you state, even though, typically,
the node doesn't actually send packets to that IP address.

Actually, I think this is a gap in RFC 2461, since these procedures
aren't well suited to routers. Ed's suggestion of watching for the
periodic RA is one possibility, there are others.

Perhaps this could be put into the charter for the new "movement
detection" working group?

            jak

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 29 Apr 2003 08:58:32 +0900

Ed 

> then NUD takes 3 seconds to determine that the neighbor is unreachable.

Then MN needs another time to discover new router. Roughly 0.75 sec.

> unreachabe. 

Even though we use NS/ NA exchange, in case of movement, MN should 
perform RS/ RA exchange subsequently for Router Discovery. 

And it's up to implementation how long MN will wait a RA (from current AR) 
before it assumes movement. If we adapt an optimization scheme like FastRA, 
it's reasonable to assume MN has moved after only 100ms waiting. 

> Also, the RS/RA method is not as guaranteed as NUD, since the

I agree. But in this case, RS/ RA exchange is intended to confirm not 
bi-directional reachability but uni-directional reachability, in other words, 
establishing 'stale' state with a router (whether old or new). 
 
> movement has occurred will be more efficient. But, what you are proposing

Yes, I treat all link movement as a potential L3 move. I agree that it may 
be more efficient to use optimized NUD in case of only L2 movement. 

But the problem is that MN has difficulty discerning whether it is undergoing 
L2 movement or L3 movement. And even for the case of only L2 movement, 
it's make sense to use RS/ RA exchange. 

Assume the change of access point without any change in subnet. If MN sends 
RS to the All-Routers multicast address, it will receive a RA from current AR 
very soon. Moreover, if we use FastRA, a RA will arrive immediately. 

So I think it's better to assume L3 movement and use RS/ RA exchange. 

Regards

JinHyeock

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 28 Apr 2003 17:13:09 -0700

JinHyeock -

I'm generally OK with all you propose. However, if upon receiving a RA from
a different router after sending a RS, you use that to decide that your
previous default router is no longer reachable and thus switch to the new
default router, there are some holes in that design - unless you are
careful, it won't work well in some scenarios. The current method proposed
in the base spec of first determining the reachability (or unreachability)
of your default router before initiating RS and subsequent switching to a
new default router is more bullet-proof, in general, and easier to
understand, although I agree it probably isn't the fastest movement
mechanism in some cases.

I'm in favor of leaving the base spec the way it is currently w/ regards to
the MN probing with NS first, before deciding the default router is
unreachable and then soliciting for a new router, only because it is a
little more straight-forward although perhaps not as optimal as what you
suggest in the case where actual L3 movement has occurred. I do not think
you should ever switch away from a current default router that is still
bi-directionally reachable and therefore usable - there is too much overhead
involved in forming a new primary CoA, registering it with the home agent,
updating your CN bindings with new primary CoA, etc. It is preferable to
avoid that additional overhead, even if it means that sometimes your link
movement is a little slower because you have some hysteresis built into the
movement detection mechanism causing the MN to continue trying to use the
current default router a bit longer (i.e. until it has confirmed it is
really unreachable) before switching away from it.

Thanks.
- Ed

> Sent: Monday, April 28, 2003 4:59 PM
> To: Ed Remmell; Jari Arkko
> Cc: Erik Nordmark; Mobile IPv6 mailling list
> Subject: Re: Current Movement Detection Process and Time (Re:
> [mobile-ip] Re: closing issue #297 (erik's and steven's technical
> comments on base))
>
>
> Ed
>

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 29 Apr 2003 09:37:01 +0900

Ed

Thanks for your thorough feedback. It helps to clarify my thoughts.

> careful, it won't work well in some scenarios. The current method proposed

I think there is some misunderstanding here. 

In my proposal, after sending a RS, MN doesn't assume that it's current router 
is no longer reachable when a RA from a different router arrives. If so, we will 
have serious problem in case of multiple routers in a link.

Instead, after sending a RS, MN assume that it's current router is no longer 
reachable if MN receives no RA from current AR after certain amount of time. 
(whether it receives a RA from a new AR or not)

> unreachable and then soliciting for a new router, only because it is a

I agree that it makes sense to first determine the reachability of current router. 
But I am afraid that it may be inefficient to use 3 NS probes for that purpose. 
I wonder it's more efficient to use RS/ RA exchange and timeout to determine 
the (partial) reachability of current AR. 

> avoid that additional overhead, even if it means that sometimes your link

I agree. It makes sense to keep using current AR unless handoff is imminent. 
But do we have to use only NS/ NA for that? Can we use RS/ RA exchange 
to determine (partial) reachability of current AR as I proposed?  

Thanks 

JinHyeock

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 28 Apr 2003 17:58:46 -0700

JinHyeock -

Your method could be more distruptive in the case where no actual link
movement occurred, or a L2 move occurred but a L3 move did not occur. That
is because NUD probing in this case will complete quickly, indicating that
the current default router is still reachable.

The fact that it takes all of 3 seconds for NUD probing (once NUD sends the
first probe and transitions to the PROBE state) to determine that the
current default router is actually no longer reachable (this being an
indication of a L3 move), this extra hysteresis that causes the MN to
continue trying to use the current default router as long as possible is
probably a good thing, IMHO, because the alternative is to switch default
routers too frequently which is definitely a bad thing due to the extra
overhead involved in forming a new primary CoA, updating the home
registration with the new primary CoA, updating CN bindings with the new
primary CoA, etc.

However, if there is only a single router per link, then your way of using
RS w/out NUD probing is perhaps more optimal, especially in the case where
something like Fast RA is implemented in the network.

I'd prefer to leave the base spec the way it is, especially since we are
past WG last call and IETF last call. The base spec says to probe to
determine router reachability using NS, which is essentially NUD. NUD is the
mechanism that is intended to be used to determine the reachability of
neighbors, the current default router being just another neighbor on the
link.

Thanks.
- Ed

> From: JinHyeock Choi [mailto:[email-masked]]
> Sent: Monday, April 28, 2003 5:37 PM

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 29 Apr 2003 13:35:59 +0900

Ed 

> the current default router is still reachable.

Yes. While RS/ RA exchange requires two random delay interval, NS/ NA 
exchange can be done immediately. We may overcome this obstacle using 
an optimization scheme like FastRA.  

> neighbors, the current default router being just another neighbor on the

I agree with your opinion on base spec. IMHO, MD optimization is too 
complicated to be incorporated into basic draft, especially at this late stage. 
I see few points in writing more about MD in a base draft. We'd better 
leave MIPv6 draft as it is (maybe with a few proper comments) and 
investigate MD optimization in a separate I-D.  

Regards

JinHyeock

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Apr 2003 17:43:41 +0300

I very much agree that we shouldn't keep on optimizing or modifying
the base MIPv6 movement detection for ever ;-)

However, I'm not sure we've yet addressed Erik's concern that it
is confusing to call the probing mechanism NUD. Ed's reply looks
reasonable, but you could also argue that we should simply make
a clear distinction between the two. If we do that, then we are
also free of the limitations set by the NUD timers. When you
talk about 3 seconds I don't get a feeling that this is very
efficient, even if only necessary when the routers don't do AI
and L2 doesn't give you a hint...

So here's my suggestion: 1) keep the current scheme of L2 and
L3 hints. Then allow the mobile node to probe the router
if and only if it has taken all L3 hints (no recent RAs,
no packets from router, nothing on promiscuous mode) and
still thinks it doesn't hear the router. This would avoid
bad implementations that probe the router just in case,
and cause unnecessary traffic on the link.

2) Make it very clear that whatever probing is going on,
we do not call it NUD, nor do we mandate it modifies NUD
state machine. (Note: looking at the wire, I'm pretty sure
I can't tell whether Ed's implementation is a part of the
NUD state machine or an independent process.)

3) Leave it open what messages are actually being used
for the probing. This would allow both RS/RA or NS/NA.

4) Further optimizations are in the scope of the future MIP
WGs.

--Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 29 Apr 2003 08:44:52 -0700

Jari -

This works for me, thanks.

Thanks.
- Ed

> Sent: Tuesday, April 29, 2003 7:44 AM
> To: JinHyeock Choi; Ed Remmell

---

From: "James Kempf" <[email-masked]>
Date: Tue, 29 Apr 2003 10:37:10 -0700

Agree.

            jak

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: "JinHyeock Choi" <[email-masked]>; "Ed Remmell"
<[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; "Mobile IPv6 mailling
list" <[email-masked]>
Sent: Tuesday, April 29, 2003 7:43 AM
Subject: Re: Current Movement Detection Process and Time (Re:
[mobile-ip] Re: closing issue #297 (erik's and steven's technical
comments on base))

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 30 Apr 2003 08:17:22 +0900

Jari 

It works for me. But I have some comments on RS/ RA usage. 
Kindly see my in-line comments. 
 
> the base MIPv6 movement detection for ever ;-)

Definitely :-)  

Agree.  

> NUD state machine or an independent process.)

Agree 

> for the probing. This would allow both RS/RA or NS/NA.

I agree to allow both RS/ RA and NS/ NA probing. 

But we may clarify how MN uses RS/RA probing for movement 
detection. 

For NS/ NA probing, after 3 NS without NA reply, MN assumes 
the current AR isn't reachable.  

How does MN detect movement when it uses RS/ RA probing? 
Should MN send 3 RSs or can it use RS/ RA exchange with timeout 
as I suggested?   

Will we clarify this or leave it open?   

> 4) Further optimizations are in the scope of the future MIP
 
Agree

Thanks  

JinHyeock

---

From: Jari Arkko <[email-masked]>
Date: Wed, 30 Apr 2003 10:01:32 +0300

> Will we clarify this or leave it open?   

Good questions! Lets discuss the details first and then I'll get
back to the question of whether we should talk about them in
the spec.

Regarding NS/NA, if we don't call this probing NUD or claim any
conformance or modification to the NUD state machine, then we are
free to select the probing timers and counters in an implementation
dependent basis. For instance, you could use past RTT as a guideline
in how fast you should expect answers from probes.

Regarding RS/RA, I would expect both a timeout and maybe multiple
RSes being used. Obviously router discovery rate limitations and
timers would have to be obeyed as well.

Should we add these details to the specification? Hmm.... after
reading Erik's e-mails today I'm getting a sense that it would be easier
for us to advance this document if it didn't get into the details,
may even have to skip all discussion of probing. Moreover,
any details it will have will likely be replaced later
by optimized procedures for FastRA. Would the lack of details
cause a problem for implementations - yes and no. No, because we
are not suggesting any modifications of the router's behaviour.
Mobile node implementations can choose the strategy they wish
to. Yes, because implementors will still have to figure this
out. OTOH, they apparently can figure this out, and have even
different techniques that may be suitable in different
circumstances ;-)

--Jari

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 30 Apr 2003 18:36:01 +0900

Jari 

> in how fast you should expect answers from probes.

I agree. We may implement MN to wait just 2 * RTT after sending NS 
and assume movement. If we use NS/ NA exchange, we don't have to 
worry about Random Delay. 

I think that the Pro of NS/ NA probing are  
1) There is no Random Delay.
2) There is a S bit to confirm bi-directional reachability.  

By the way, the Pro of RS/ RA probing is
1) With only RS/ RA exchange, MN can check the reachability 
    of current AR and receive all necessary informations from 
    new AR.

> RSes being used. Obviously router discovery rate limitations and

I wonder it's a good idea to use multiple RSes. I am afraid it will cause 
too many broadcast packets. But this is the detail we can investigate 
more thoroughly later.  

> are not suggesting any modifications of the router's behaviour.

Yes, I agree with Erik that the less about MD is the better. We'd better 
present just the basic guide line. 

The only thing I feel uneasy about is that, because of lack of detail, 
people may implement MN to send excessive RS or NS message 
to overflow network. 

We may state that
1) For movement detection, MN may use either RS/ RA or NS/ NA 
    in a manner suitable for the situation. 
2) But this probing should not overflow the network.   

Thanks 

JinHyeock

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 30 Apr 2003 08:53:07 -0700

> for us to advance this document if it didn't get into the details,

Yes, please do not descend into the details of how to probe the router for
reachability in this document. You are correct that implementors can and
will figure out a good way to do it (there are a number of alternatives -
ping'ing the router may even work for some). IMO it is sufficient to state
that there is a potential problem having to do with the MN no longer being
reachable by the network to receive connection requests initiated by the
network, and that this is why the MN needs to track reachability from the
router (not the same as NUD bi-directional reachability).

Thanks.
- Ed

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 30 Apr 2003 09:06:32 -0700

> 2) But this probing should not overflow the network.

If you are going to be that specific in your recommendations, then you might
as well include ICMPv6 ping of the current default router as yet another
alternative. I'd prefer that this text not contain any requirements language
(i.e. "MAY, SHOULD NOT" => "may, should not") and instead just mention some
possible mechanisms for probing. W/ regards to this probing not overflowing
the network, hmmm... that is a bit problematic if we aren't getting into the
specifics of how this probing is done. There are a number of rate-limiting
requirements in the MIPv6 spec already, perhaps we can reuse one of those as
follows:

"Whatever the probing mechanism used to confirm reachability from the
current default router, the mobile node MUST NOT probe the router more often
than MAX_UPDATE_RATE times within a second."

MAX_UPDATE_RATE is already used in this manner to rate limit the frequency
at which mobile nodes can send Mobility Header protocol messages. In this
case, I would make this a hard requirement.

Thanks.
- Ed

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 30 Apr 2003 11:51:03 -0700

> different techniques that may be suitable in different

I disagree, Jari. I think we should describe how to probe
the default router in the base spec. just mention one way 
of doing it. and also say that this is *one* way of doing 
it and implementations are free to choose any mechanism
to probe the default router. but, we have to emphasize on 
the above point so that implementors dont start thinking 
that this the only way of doing it. if we dont specify 
anything, I am not sure every implementor will figure out 
how to do the probe. they might end up doing NUD whenever 
they get a "hint" of movement.

I prefer the NS/NA probe to figure out if the default 
router is reachable. RS/RA has way too many timers 
governing when a solicitation or an advertisement can be 
sent. using RS/RA is a bad idea. ofcourse once we have 
the fastRA mechanism, it can be used.

Vijay