This issue contains the movement detection & router reachability issue, orginally raisued in the IESG review and handled as a part of issue #281, but now allocated a separate issue number. --------------------- Erik Nordmark writes as a part of his IESG review: - In addition to the intro, I'm concerned that the changes in the movement detection section (which I think talks about looking at the source link-layer address of packets to determine that the default router is still sending packets to the MN) is unnecessary since it doesn't solve any problem. If there is only one router on the link then NUD will tell the MN that the router is dead, in addition to the MN being able to detect that it has moved to a different link. But when there are multiple routers on the link the MN just needs to assume that the all the routers can reach the MN (i.e. no hidden terminal problem). Thus it probably makes sense simplifying the movement detection section. (And I believe there are some Connectathon comments above movement detection as well.) --------------------- Gabriel Montenegro writes: The issue now that I think about it is with this particular mechanism: "Since the router sends periodic unsolicited multicast Router Advertisements, the mobile node will have an opportunity to check if it is still reachable from its default router, even in the absence of other packets to it from the router." This may not guarantee symmetric reachability to the router, even if there's only one router on that link. In real life, it has been observed that if there not all nodes are using the same 802.11 speed, 802.11 broadcast packets (which may carry the unsolicited RA multicast by the router) will be transmitted at the lowest speed of 1 or 2 Mbps, whereas the unidirectional traffic from a given MN to the router (or access point) may be transmitted at 11Mbps, for example. So broadcast traffic has been seen to reach much beyond what unicast traffic reaches. This has been observed to cause all sorts of problems with AODV in experimental setups. The fix to those has been to have tests for liveness. Only this will guarantee that the link is symmetric. So I'm beginning to think we should delete the text about this funky mechanism and only leave stuff that is known to work. Once we do that and we leave only mechanisms (NUD) that guarantee this, we will be consistent with 2461. > I think I agree that the draft doesn't solve that problem. I'm > just trying to see what needs to change to make you Erik and Gabriel > happy. Should I delete the section 2 claim? But it does not say > it solves the complete problem, it says "with its default router". > And yes, we are using this only for movement detection. Perhaps we > should add a note somewhere that the spec does not prevent the > problem Erik mentions above from occurring? Again, I think the claim is consistent with 2461. What should be deleted is the mechanism whereby the MN concludes that the link is symmetric by virtue of just hearing traffic from the access router (even if this judgement is based on multicast packets). --------------------- --------------------- --------------------- Jari Arkko writes: This is the one remaining issue from Erik's original IESG comments. I need to ask your advice, because at the moment I don't see how to easily take care of this. Erik wrote: > - In addition to the intro, I'm concerned that the changes in the > movement detection section (which I think talks about looking at the > source link-layer address of packets to determine that the default > router is still sending packets to the MN) is unnecessary since it > doesn't solve any problem. If there is only one router on the link > then NUD will tell the MN that the router is dead, in addition to > the MN being able to detect that it has moved to a different link. Gabriel wrote: > The issue now that I think about it is with this particular mechanism: > > "Since the router sends periodic unsolicited multicast Router Advertisements, > the mobile node will have an opportunity to check if it is still reachable > from its default router, even in the absence of other packets to it from > the router." > > This may not guarantee symmetric reachability to the > router, even if there's only one router on that link. In real life, > it has been observed that if there not all nodes are using > the same 802.11 speed, 802.11 broadcast packets (which may carry > the unsolicited RA multicast by the router) will be transmitted at > the lowest speed of 1 or 2 Mbps, whereas the unidirectional traffic > from a given MN to the router (or access point) may be > transmitted at 11Mbps, for example. So broadcast traffic has > been seen to reach much beyond what unicast traffic reaches. > This has been observed to cause all sorts of problems with > AODV in experimental setups. The fix to those has been to have > tests for liveness. Only this will guarantee that the link is > symmetric. > > So I'm beginning to think we should delete the text about this > funky mechanism and only leave stuff that is known to work. > Once we do that and we leave only mechanisms (NUD) that > guarantee this, we will be consistent with 2461. So, in conclusion the current text in the movement detection section states that we can take the reception of any packet from the router as an indication of the routing being able to reach this node. The issue in this is that this may not work always, and may fail in an important case. Namely, on link with nodes supporting different speeds, it can apparently happen that e.g. WLAN broadcast packets are sent on a lower speed than specific unicast traffic. This may result in the mobile node being able to hear multicast RAs, but not actually be able to receive traffic. I think this is a real problem (though I have a question on it later). But why is it hard to follow Gabriel's suggestion of taking this funky scheme out of the spec? Here's what we have current for detecting router reachability: 1. Track all packets, not just those sent with router source address 1b. As a special case of this, talk about the RAs whose period is known 1c. You could even make the interface promiscuous and do the above 2. Finally, you can do NUD First of all, I'm not sure whether Gabriel's suggestion was to take out all of #1, or just #1b. Secondly, I don't know e.g. WLAN radio behaviour well enough to understand one aspect of the multi-speed problem. If the link layer is capable of multiple speeds, why are the router and the host using a "too high" speed for their unicast communications? It would seem to me that the right thing for the link layer would be to choose the speed that still reaches the host. Thirdly, I worry about the impacts of disabling 1b. The trouble with NUD is that it works more or less perfectly when there's traffic from the mobile node. However, if a number of idle mobile nodes need to track the reachability of their router using NUD, this will result in frequent NS/NA messages on the link. This is undesireable. OTOH, this is a general problem with IPv6 and wireless links, and not something that MIPv6 specifically brings out. Nevertheless, I'm not sure what I should do, given an apparent problem in the way that the current specification is written, and a possibly serious efficiency problem if I rewrite it the other way. Any suggestions? --------------------- Charlie Perkins writes: My vote: fix it to be as clear as possible, so that people can build the best systems possible. Please ignore requests to delete useful techniques just because they are not perfect, especially when the alternative (unresponsive system) is more harmful. --------------------- Jari Arkko responds to Charlie Perkins: This is precisely why I have taken up this dicussion and not taken the easy delete-the-paragraph-that-iesg-requests-me-to path. But the next question is how to make the description better. I don't think we have been mistaken to take the reception of packets from the router as a proof that the router can receive packets from us. We are talking only about the router being able to reach the mobile node. The specific concern about was about this scheme only. Can we say something more specific about the situation where the problem may occur? Better yet, can we refute the claim that reception of some multicast packets does not imply reception of all packets? --------------------- Charlie Perkins responds to Jari Arkko: Under IP rules, reception of any packet whatsoever does not imply receiving the next packet. The more specific case about disparate power levels may exaggerate the frequencies, but not (typically, in my opinion) the correct protocol response, since all IP signaling has to be viewed as either expensive or else unreliable. Do you want the router to know whether it can reach the mobile node, or do you want the mobile node to know whether the router can reach it with data? This problem is approximately as hard as the "neighborhood discovery" problem in [manet], and without any additional assumptions is either expensive to solve or else nobody knows the right way to do it yet. If we assume TCP is ongoing, we get some more help on the second part. If we assume the mobile node is sending data, then the router can believe that the mobile node is getting data from the router otherwise the mobile node might get tired. If the mobile node is only sending UDP, and never expecting any data back from the router, then I don't know of any clever solutions except ping or some layer-2 equivalent (oops that wasn't clever). --------------------- Ed Remmel responds to Jari Arkko: Executive Summary: Gabriel's concerns about 802.11 link speed switching appear to be unwarranted - 802.11 MAC/PHYS is responsible for ensuring that unicast packets are received correctly by the peer, and if/when they aren't (since they must by ACK'ed by the peer's 802.11 MAC), they are retransmitted, until finally (w/ regards to Gabriel's scenario) the access point decides to downshift the link speed used with that specific MN so that they are received correctly. Receipt of RAs from the default router can still be used by the MN in this scenario to determine "reachability from the router". Also, the mechanisms used by the MN to determine "reachability from the router" should not be removed from the MIPv6 specification - this is important functionality that is not duplicated by NUD. Details: I spent a couple of hours researching this with another engineer here (Jason Schmidlapp) who has a bit more experience with 802.11 than I do, we looked at the IEEE 802.11 specification together and decided that the 802.11 link speed issue that Gabriel has reported is a non-issue. As you say: > Secondly, I don't know e.g. WLAN radio behaviour well enough to understand > one aspect of the multi-speed problem. If the link layer is capable of > multiple speeds, why are the router and the host using a "too high" speed > for their unicast communications? It would seem to me that the right thing > for the link layer would be to choose the speed that still reaches the > host. 802.11 does exactly that. The IEEE 802.11 specification discusses link speed switching in section 9.6 "Multirate Support". It is left up to implementors as far as when to downshift the link speed being used with a specific peer, however it is clear that the intent is for a 802.11 access point to monitor the state of MAC-layer (re)transmissions to a specific MN, and when it becomes apparent that the MN isn't receiving the unicast packets/frames that the access point sends it, then the access point will try to improve performance of the link, one way it can do that being to downshift the link speed. So, this is all handled by the 802.11 MAC/PHYS layer. Per section 9.7 "Frame exchange sequences", unicast data frames "Directed MSDU or MMPDU" require acnkowledgement "Last ACK" by the peer. Also, refer to section 9.2.5.3 "Recovery procedures and retransmit limits" of the IEEE 802.11 specification. Also (somewhat unrelated), the MN at the 802.11 MAC/PHYS layer can make its own determination of receive signal strength and signal quality (for example, the Intersil PRISM chipset passes this information up to the host interface for every received frame), and based on that can make the appropriate roaming decisions. This would be a L2 move event initiated by the 802.11 MAC layer. To clarify, the problem that Gabriel reports w/ regards to 802.11 using different link speeds for broadcast/multicast packets versus for unicast packets, as I read it, it only has to do with the access point transmitting to the MN: i.e. since the router uses a faster link speed (i.e. with less range) for the unicast packets that it sends to the MN than for multicast RSs (i.e. with more range), then there is the potential for the MN to be able to receive the RSs from the router, but not the unicast packets from the same router - and this means that the fact that the MN is able to receive RSs from its router is not a good indication of being reachable from its router w/ respect to unicast. However, as I've said above, this is really a non-issue - it is all handled correctly by the 802.11 MAC/PHYS. Note that "reachable from its router" is not the same as NUD bi-directional reachability - that was always clear to me from reading the MIPv6 specification, perhaps you need to add some clarification to the spec about that. "Reachable from its router" only means that the MN can receive packets from the router, which says nothing about whether or not the router can receive packets from the MN. I disagree with Erik: > - In addition to the intro, I'm concerned that the changes in the > movement detection section (which I think talks about looking at the > source link-layer address of packets to determine that the default > router is still sending packets to the MN) is unnecessary since it > doesn't solve any problem. If there is only one router on the link > then NUD will tell the MN that the router is dead, in addition to > the MN being able to detect that it has moved to a different link. It is still important for the MN to keep track of reachability from the router. NUD probing of the router is only used when the MN has data to send through the router. Otherwise, if the MN isn't actively sending any data, it won't be actively probing the router. If it doesn't keep track of "reachability from the router" by either listening for RA beacons (Advertisement Interval) or some other means such as putting the interface into promiscuous receive move and listening for any frames sent by the default router (matching on source link-layer address; and note that these are likely frames sent do a different host on the same link, not to this MN), then it is possible that the MN goes off link without ever realizing it (especially if L2 doesn't give MIPv6 the appropriate link-movement triggers), and then the MN is no longer reachable from the network. Unless the MN has data to send through the default router, it will not initiate NUD probing of the default router so it will not detect this reachability failure in this case. That's why it is important to have some other mechanism that the MN uses to check for its "reachability from the router". > I think this is a real problem (though I have a question on it later). > But why is it hard to follow Gabriel's suggestion of taking this funky > scheme out of the spec? Here's what we have current for detecting > router reachability: > > 1. Track all packets, not just those sent with router source address > 1b. As a special case of this, talk about the RAs whose period > is known > 1c. You could even make the interface promiscuous and do the above > 2. Finally, you can do NUD > > First of all, I'm not sure whether Gabriel's suggestion was to take out > all of #1, or just #1b. Gabriel, as I read his comments, is talking about removing #1 entirely. I'm completely against that change - first the 802.11b link speed switching issue is really a non-issue (I've explained why above), secondly it is necessary for the MN to monitor reachability from its default router especially if it doesn't have sufficient L2 triggers to notify it of link movement. You could snip #1c from the specification, but IMHO that is useful information for implementors so I'd leave it (even though it is optional functionality). #2 NUD on its own is not sufficient, because the MN doesn't initiate NUD probing until it actually has data to send through the router. > Thirdly, I worry about the impacts of disabling 1b. The trouble with > NUD is that it works more or less perfectly when there's traffic from the > mobile node. However, if a number of idle mobile nodes need to track the > reachability of their router using NUD, this will result in frequent NS/NA > messages on the link. This is undesireable. NUD probing only occurs when: 1) the MN is sending data through the router 2) reachability is suspect TCP should be refreshing the reachability state of the Neighbor Cache entry for the router periodically (as the MN gets reachability confirmation, for example a TCP ACK received via the router that acknowledges some new data sent previously by the MN), so that will elminate or reduce the need for NUD probing in many cases when the MN is actually sending data through the router. If the MN isn't actively sending data through the router, no NUD probing of the router should be occurring. So, your concerns about frequent NS/NA messages appear to be unwarranted. --------------------- Erik Nordmark responds to Jari Arkko: 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. --------------------- Ed Remmel responds to Erik Nordmark: >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 OK. I agree that some issues introduced by wireless can't be solved by MIPv6, that seems reasonable. > 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. 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. > 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. 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. > 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. 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. --------------------- Jari Arkko writes: 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. for NUD, which 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. --------------------- James Kempf responds to Ed Remmel: 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. --------------------- Ed Remmel responds to Jari Arkko: 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. > 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. Yes. > 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. Agreed. > 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? 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." > 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." Perhaps you should also reference "hidden terminal problem", as in: This is commonly known as the "hidden terminal problem". > 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: 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). > 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 ...". Looks good. > 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. Yes. > 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. OK. > 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? 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. > 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. 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." > 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. 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. --------------------- Erik Nordmark responds to Jari Arkko: 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. > 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. 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. > 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. 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 > would improve performance particularly if there are a lot > of silent nodes on the same link. I don't understand this since NUD probes only occur when needed. > 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. 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 > in promiscious mode. 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. --------------------- Jari Arkko responds to Erik Nordmark: > 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. Yes, I noticed this too yesterday. The "but" has been removed now. > 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. Yes. > Note however that the current text says the logical opposite; that NUD can be > avoided as long as the MN hears the default router. It needs to get fixed then ;-) I'll work on it. >> 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. > > > I think you should say "Does not effect when NUD is needed; might trigger > movement detection earlier than NUD by itself." Ok. >> Solution 3. As above, but make put the interface >> in promiscious mode. > > > 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. 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? --------------------- Ed Remmel responds to Jari Arkko: 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. --------------------- Erik Nordmark responds to Jari Arkko: > 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? 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. --------------------- JinHyeock Choi responds to Jari Arkko: > Has someone measured the movement detection times with and without > payload traffic tracking? I analyzed 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 > can't learn anything before a RA arrives anyway. If yes, should > we probe with NS/NA or RS/RA? Ed wrote > 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. But Erik wrote > 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. 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. --------------------- Ed Remmel responds to Erik Nordmark: > 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. 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. > 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? 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. > As long as it can hear the current router (at L2 or L3) it has little > need to switch. Agreed. > 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. 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. --------------------- Ed Remmel responds to JinHyeock Choi: 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. --------------------- Jari Arkko responds to Ed Remmel: 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. --------------------- Erik Nordmark responds to Ed Remmel: > 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. 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... --------------------- Ed Remmel responds to Erik Nordmark: >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. --------------------- James Kempf responds to Erik Nordmark: > 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? --------------------- JinHyeock Choi responds to Jari Arkko: 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. --------------------- Ed Remmel responds to JinHyeock Choi: > 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. 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. > Currently Movement Detection process is > Step 1) Hint > Step 2) NUD with current AR > 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). > How about change 2) and 3) like this? > Step 1) Hint > Step 2) Router Discovery with all routers > Step 3) NUD with new AR I do it this way for L3 move processing. > 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). 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). > 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. I'm OK with this. > 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. I'm OK with this. > 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). Yes. > 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. 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. --------------------- JinHyeock Choi responds to Ed Remmel: > 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. Then MN needs another time to discover new router. Roughly 0.75 sec. > > 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. 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 > 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). 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). > 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. 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. --------------------- Ed Remmel responds to JinHyeock Choi: 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. --------------------- JinHyeock Choi responds to Ed Remmel: Thanks for your thorough feedback. It helps to clarify my thoughts. > 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 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) > 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 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. > 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 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? --------------------- Ed Remmel responds to JinHyeock Choi: 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. --------------------- JinHyeock Choi responds to Ed Remmel: > 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. 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. > 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. 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. --------------------- Jari Arkko writes: 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. 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. --------------------- Ed Remmell responds to Jari Arkko: This works for me, thanks. --------------------- James Kempf responds to Jari Arkko: Agree. --------------------- JinHyeock Choi responds to Jari Arkko: It works for me. But I have some comments on RS/ RA usage. Kindly see my in-line comments. > I very much agree that we shouldn't keep on optimizing or modifying > the base MIPv6 movement detection for ever Definitely > 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. Agree. > 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.) Agree > 3) Leave it open what messages are actually being used > 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 > WGs. Agree --------------------- Jari Arkko responds to JinHyeock Choi: > 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 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 ;-) --------------------- JinHyeock Choi responds to Jari Arkko: > 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. 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. > Regarding RS/RA, I would expect both a timeout and maybe multiple > 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. > 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. 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. --------------------- Erik Nordmark responds to Jari Arkko: > 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 ;-( Aren't most of those other means optional? > 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. Agreed in the case when there is no movement hint coming up from L2. > 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. (d) have the minimal text that describes when movement has and has not been detected (e.g. capturing the fact that the router link-local address being identical doesn't mean the MN has not moved; that the R-bit is useful; that prefixes are useful when there is no R-bit; that multiple routers on the link advertising the same prefix shouldn't be misinterpreted as movement). That should be sufficient for this document. Then the optimized movement detection work can worry about whether NUD is tweaked (to verify the old router is still reachable) and/oror some fast RS/RA exchange is launched when a movement is suspected, etc, etc. --------------------- Ed Remmell responds to Jari Arkko: > 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, 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). --------------------- Ed Remmell responds to JinHyeock Choi: > 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. 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. --------------------- Basavaraj Patil responds to Ed Remmell and Jari Arkko: > > 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, > > 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). I agree with the above approach as well. Leave the details for now out of the base specification. Since one of the things we have discussed and agreed is that movement detection is a piece of the puzzle that can be worked on independently, there is no need to have a great deal of emphasis in this I-D. --------------------- Basavaraj Patil writes: > 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. I think RS should not be the preferred method for probing anyway. NS is preferred. So would it be sufficient to have text that highlights the problem of probing based on RS/NS and recommend the use of L2/L3 indications while leaving any details of these out. > 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. How does the MN really know if he is causing trouble? Hence it is better to handle all these problems separately and only have minimal movement detection mechanism specified in the base spec. Hopefully implementation and interop experience will enable this to be better specified in the near term in a separate I-D. I think we have consensus on this issue. So, maybe Jari can close this one. --------------------- James Kempf responds to Basavaraj Patil: > I think RS should not be the preferred method for probing anyway. NS > is preferred. > So would it be sufficient to have text that highlights the problem of > probing based on RS/NS and recommend the use of L2/L3 indications > while leaving any details of these out. I'm not clear that the direction in this choice is so clear cut. I'd prefer something more general, to say that a node should minimize traffic involved in MD probing. I think it is still an open question exactly how this should be done, something for the new MD WG. --------------------- Vijay Devarapalli responds to Jari Arkko: > 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 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. --------------------- Basavaraj Patil writes: But in order to close the current issue for the base spec, I think the minimalist approach of providing some guidelines for probing and leaving the larger part for implementations should be sufficient. Additionally a warning about causing excessive traffic on the link as a result of unwarranted probing should be highlighted. --------------------- James Kempf responds to Basavaraj Patil: I'm comfortable with guidelines, what I'd advise against is saying "here's a protocol for probing". Jari's proposed solution, with Erik's modification, sounded fine. --------------------- JinHyeock Choi responds to Vijay Devarapalli: > 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 will be good if we present implementators *one* way of probing. But I am afraid it will delay MIPv6 I-D further to build consensus on *one* way. If we can produce *one* way promptly, it's O.K. for me. (I even agree to use NS probing for the *one* way :-)) If not, I doubt it's worthwhile the delay. > 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. I agree that NS is better if the reachability of current AR is the only thing MN have to check. If MN moves, MN have to discover new Router too, hence can't avoid RS/ RA exchange. And when MN uses NS probing, how will it determine that it has moved? Will it use 3 NS probes which take 3 secs? In some scenarios, I think it makes more sense to use RS. But these are the details which, I suggest, we'd better deal with later. --------------------- JinHyeock Choi writes: Text proposal: "A node (should) use probing to figure out if the default router is reachable. A node (should) minimize traffic involved in MD probing." --------------------- Vijay Devarapalli responds to JinHyeock Choi: You didnt get my point. the problem with this kind of text is some implementors will just use NUD to do the probing. whenever they get a "hint" of movement detection they would start NUD. this is something we should avoid. it is good to suggest one mechanism to probe the default router. --------------------- Vijay Devarapalli responds to JinHyeock Choi: > It will be good if we present implementators *one* way of > probing. But I am afraid it will delay MIPv6 I-D further to > build consensus on *one* way. this is FUD. sending NS and waiting for an NA is a very easy mechanism. you are the only one who wants to use an RS. and IMO, RS/RA mechanism is a bad idea without fastRA. --------------------- Hesham Soliman writes: Well, I must admit I haven't read all emails on the topic but I want to stress one important point: This section is _educational_. I.e. it does not and could not mandate anything. Having said that, you don't need to use the "NUD procedure" with all its timeouts ...etc. You can simply use an NS/NA exchange. These messages are always available. In the presence of fasr RA, I would prefer that to NS/NA, but for now, why not use NS/NA without having to follow NUD. And BTW, we don't have to call this use of NS/NA, NUD. --------------------- Jari Arkko writes: I'm still working on a version of the movement detection section which would be formulated around hints about movement (and non- movement). I should be able to post that this weekend. However, what we have discussed most is the probing part. It seems like most people in the WG would like to have generic text about probing. Vijay and maybe Hesham wanted to have more specific text on how to do NS/NA probing. Erik seems happiest with no text on probing at all. Let me try to suggest a brief guidelines or educational text for the probing part: ... To detect when its default router becomes unreachable, a mobile node SHOULD use Neighbor Unreachability Detection. Neighbor Unreachability Detection is applied only when the mobile node has packets to send. In order to be able to receive incoming packets when the mobile node has nothing to send, it is also important for the mobile node to keep track of whether the current default router can reach the mobile node. If the router can not reach the mobile node, the mobile node SHOULD switch to a new default router and potentially to a new primary care-of address. The following indications can give the mobile node some assurance that the default router can still reach it: o (List of hints) The lack of such indications can mean either that reachability has been lost, or simply that there was no traffic on the link. This can happen, for instance, if the advertisement interval on the link is large, there are no indications from the link layer, and no other traffic exists on the link. In this situation it may be necessary to probe the router in order to test for reachability, but specific methods for such probing are outside the scope of this specification. In order to avoid congesting the link, probing should only be done if the mobile node has already attempted to determine reachability indications according to the list above. Alternatives to this text would include adding specific words about the use of NS/NA, or striking the whole text. --------------------- Hesham Soliman responds to Jari Arkko: I'm fine with this. --------------------- James Kempf responds to Jari Arkko: I favor Erik's position about not mentioning anything, but if we must mention something, then the text you've provided is best. I would oppose anything more specific at this point, given our current state of knowledge. --------------------- Ed Remmell responds to Jari Arkko: This works for me. --------------------- Vijay Devarapalli responds to Jari Arkko: (grumbling) go ahead and close the issue. --------------------- JinHyeock Choi responds to Jari Arkko: It looks reasonable to me. Thanks for nice work. --------------------- Erik Nordmark responds to Jari Arkko: Can you send out what all of the movement detection section would look like with this change? It isn't clear to me all of what you are deleting. > Let me try to suggest a brief guidelines or educational > text approach for the probing part: > > ... To detect when its default router becomes unreachable, a > mobile node SHOULD use Neighbor Unreachability Detection. > > Neighbor Unreachability Detection is applied only when the mobile > node has packets to send. In order to be able to receive incoming > packets when the mobile node has nothing to send, it is also > important for the mobile node to keep track of whether the current > default router can reach the mobile node. If the router can not > reach the mobile node, the mobile node SHOULD switch to a new > default router and potentially to a new primary care-of address. The above is potentially misleading since switching to a different default router only helps when the new default router is advertising a different set of prefixes. > The following indications can give the mobile node some assurance > that the default router can still reach it: > > o (List of hints) > > The lack of such indications can mean either that reachability has > been lost, or simply that there was no traffic on the link. It would be better to say that the lack of such indications mean that the reachability status from the default router to the mobile node is unknown. > This > can happen, for instance, if the advertisement interval on the > link is large, there are no indications from the link layer, and > no other traffic exists on the link. s/traffic on the link/traffic from the default router/ > In this situation it may be > necessary to probe the router in order to test for reachability, > but specific methods for such probing are outside the scope of this > specification. In order to avoid congesting the link, probing > should only be done if the mobile node has already attempted to > determine reachability indications according to the list above. > > Alternatives to this text would include adding specific > words about the use of NS/NA, or striking the last paragraph. > But I think this is a good compromise. The last paragraph could use a warning about not constantly probing the default router when there is no traffic. --------------------- Jari Arkko responds to Erik Nordmark: Here's the full text for the movement detection section. I have tried to address your concerns. 11.5.1 Movement Detection The primary movement detection mechanism for Mobile IPv6 defined in this section uses the facilities of IPv6 Neighbor Discovery, including Router Discovery and Neighbor Unreachability Detection. The mobile node SHOULD supplement this mechanism with other information whenever it is available to the mobile node (e.g., from lower protocol layers). The description here is based on the conceptual model of the organization and data structures defined by Neighbor Discovery [12]. Mobile nodes SHOULD use Router Discovery to discover new routers and on-link subnet prefixes; a mobile node MAY send Router Solicitations, or MAY wait for unsolicited (periodic) multicast Router Advertisements, as specified for Router Discovery [12]. Based on received Router Advertisements, a mobile node maintains an entry in its Default Router List for each router, and an entry in its Prefix List for each subnet prefix that it currently considers to be on-link. Each entry in these lists has an associated invalidation timer value. While away from home, a mobile node typically selects one default router and one subnet prefix to use as the subnet prefix in its primary care-of address. A mobile node MAY also have associated additional care-of addresses, using other subnet prefixes from its Prefix List. The method by which a mobile node selects and forms a care-of address from the available subnet prefixes is described in Section 11.5.2. The mobile node registers its primary care-of address with its home agent, as described in Section 11.7.1. In addition, the mobile node should consider the following events as indications that it may have moved: o With some types of networks, indications about link-layer mobility might be obtained from lower layer protocols or device driver software within the mobile node. However, all link-layer mobility indications do not necessarily indicate a movement of the mobile node to a new link, such that the mobile node would need to switch to a new default router and primary care-of address. For example, movement of a mobile node from one cell to another in many wireless LANs can be made transparent to the IP level through use of a link-layer "roaming" protocol, as long as the different wireless LAN cells all operate as part of the same IP link with the same subnet prefix. Therefore, link-layer indications do not guarantee that a movement has occurred. Upon receiving an indication of link-layer mobility, the mobile node SHOULD send Router Solicitations to discover the routers and prefixes on the new link. The mobile node SHOULD also mark its link-local address as tentative, and follow standard Duplicate Address Detection procedures [13]. o If Router Advertisements that the mobile node receives include an Advertisement Interval option, the mobile node MAY use its Advertisement Interval field as an indication of the frequency with which it SHOULD expect to continue to receive future Advertisements from that router. This field specifies the minimum rate (the maximum amount of time between successive Advertisements) that the mobile node SHOULD expect. If this amount of time elapses without the mobile node receiving any Advertisement from this router, the mobile node can be sure that at least one Advertisement sent by the router has been lost. It is thus possible for the mobile node to implement its own policy for determining the number of Advertisements from its current default router it is willing to tolerate losing before it SHOULD switch to a different router from which it may currently be correctly receiving Advertisements. o In Router Discovery it is possible, even if improbable, that two routers on different links happen to be using the same link-local addresses. Therefore, tracking the source address of Router Advertisements may not always be sufficient. However, if the Router Advertisement sent by the current default router contains a modified Prefix Information option with the Router Address (R) bit set, and with the On-Link (L) flag set to indicate an on-link prefix, then the mobile node SHOULD check all subsequent Router Advertisements received from the same link-local address. In this check, some of the Prefix Information options received in the new Advertisement should indicate the same global router address which was indicated earlier. If they do not contain the same address even if the Advertisement was sent from the same link-local address, this is an indication that a movement may have occurred. In this case the mobile node SHOULD switch to a different router, such as the one from which it just received the Advertisement. o When the mobile node is sending packets, it is important to quickly detect when the default router becomes unreachable. To detect when its default router becomes unreachable, a mobile node SHOULD use Neighbor Unreachability Detection. In Neighbor Unreachability Detection indicates that the current default router is unreachable, the mobile node SHOULD switch to a new default router and potentially to a new primary care-of address. Neighbor Unreachability Detection is applied only when the mobile node has packets to send. In order to be able to receive incoming packets when the mobile node has nothing to send, it is also important for the mobile node to keep track of whether the current default router can reach the mobile node. If the router can not reach the mobile node, the mobile node SHOULD switch to a new default router and, if possible, a new care-of address with a prefix other than those advertised by the current default router. The following indications can give the mobile node some assurance that the default router can still reach it: o With some types of networks, lower layer protocols in the mobile node may be able to indicate that a connection still exists with the current default router. o When a mobile node receives any IPv6 packets from the link-layer address of its current default router (irrespective of the source IPv6 address) it SHOULD use that as an indication that it is still reachable from the router. o Since the router sends periodic unsolicited multicast Router Advertisements, the mobile node will have an opportunity to check if it is still reachable from its default router, even in the absence of other packets to it from the router. o On some types of network interfaces, the mobile node MAY also supplement this monitoring of Router Advertisements, by setting its network interface into "promiscuous" receive mode, so that it is able to receive all packets on the link, including those not addressed to it at the link layer (i.e., disabling link-level address filtering). The mobile node will then be able to detect any packets sent by the router, in order to detect reachability from the router. This use of promiscuous mode may be useful on very low bandwidth (e.g., wireless) links. If this mode is supported, its use MUST be configurable, since it is likely to consume additional energy resources. The lack of such indications means that the reachability status from the default router to the mobile node is unknown. This can happen, for instance, if the advertisement interval on the link is large, there are no indications from the link layer, and no traffic from the default router. In this situation it may be necessary to probe the router in order to test for reachability. Specific methods for probing are outside the scope of this specification. However, such probing can cause unnecessary congestion on the link when there are many nodes with no packets to send. In order to avoid congesting the link, probing should only be done if the mobile node has already attempted to determine reachability indications according to the list above. Indications from lower protocol layers may also be useful to a mobile node in deciding to switch its primary care-of address to one of the other care-of addresses it has formed on this link. For example, a mobile node MAY use signal strength or signal quality information (with suitable hysteresis) for its link with the available routers to decide when to switch to a new primary care-of address using that router rather than its current default router (and current primary care-of address). Even though the mobile node's current default router may still be reachable in terms of Neighbor Unreachability Detection, the mobile node MAY use such lower-layer information to determine that switching to a new default router would provide a better connection. --------------------- JinHyeock Choi responds to Jari Arkko: Kindly find in line comments. >> 11.5.1 Movement Detection >> >> The primary movement detection mechanism for Mobile IPv6 defined in >> this section uses the facilities of IPv6 Neighbor Discovery, >> including Router Discovery and Neighbor Unreachability Detection. >> The mobile node SHOULD supplement this mechanism with other >> information whenever it is available to the mobile node (e.g., from >> lower protocol layers). The description here is based on the >> conceptual model of the organization and data structures defined by >> Neighbor Discovery [12]. >> >> Mobile nodes SHOULD use Router Discovery to discover new routers and >> on-link subnet prefixes; a mobile node MAY send Router Solicitations, >> or MAY wait for unsolicited (periodic) multicast Router >> Advertisements, as specified for Router Discovery [12]. Based on >> received Router Advertisements, a mobile node maintains an entry in >> its Default Router List for each router, and an entry in its Prefix >> List for each subnet prefix that it currently considers to be >> on-link. Each entry in these lists has an associated invalidation >> timer value. While away from home, a mobile node typically selects >> one default router and one subnet prefix to use as the subnet prefix >> in its primary care-of address. A mobile node MAY also have >> associated additional care-of addresses, using other subnet prefixes >> from its Prefix List. The method by which a mobile node selects and >> forms a care-of address from the available subnet prefixes is >> described in Section 11.5.2. The mobile node registers its primary >> care-of address with its home agent, as described in Section 11.7.1. >> >> In addition, the mobile node should consider the following events as >> indications that it may have moved: >> >> o With some types of networks, indications about link-layer mobility >> might be obtained from lower layer protocols or device driver >> software within the mobile node. However, all link-layer mobility >> indications do not necessarily indicate a movement of the mobile >> node to a new link, such that the mobile node would need to switch >> to a new default router and primary care-of address. For example, >> movement of a mobile node from one cell to another in many >> wireless LANs can be made transparent to the IP level through use >> of a link-layer "roaming" protocol, as long as the different >> wireless LAN cells all operate as part of the same IP link with >> the same subnet prefix. Therefore, link-layer indications do not >> guarantee that a movement has occurred. >> >> Upon receiving an indication of link-layer mobility, the mobile >> node SHOULD send Router Solicitations to discover the routers and I think we'd better substitute 'SHOULD' with 'MAY'. Because MN may not send RS even after it received link-layer indication. For example, assume that only link-layer (and not IP subnet ) change happens and MN receives L2 trigger. MN can send NS to check the reachability of its current AR. If the current AR replies with solicited NA, MN has no need to send RS. >> prefixes on the new link. The mobile node SHOULD also mark its >> link-local address as tentative, and follow standard Duplicate >> Address Detection procedures [13]. >> >> o If Router Advertisements that the mobile node receives include an >> Advertisement Interval option, the mobile node MAY use its >> Advertisement Interval field as an indication of the frequency >> with which it SHOULD expect to continue to receive future >> Advertisements from that router. This field specifies the minimum >> rate (the maximum amount of time between successive >> Advertisements) that the mobile node SHOULD expect. If this >> amount of time elapses without the mobile node receiving any >> Advertisement from this router, the mobile node can be sure that >> at least one Advertisement sent by the router has been lost. It >> is thus possible for the mobile node to implement its own policy >> for determining the number of Advertisements from its current >> default router it is willing to tolerate losing before it SHOULD >> switch to a different router from which it may currently be >> correctly receiving Advertisements. >> >> o In Router Discovery it is possible, even if improbable, that two >> routers on different links happen to be using the same link-local >> addresses. Therefore, tracking the source address of Router >> Advertisements may not always be sufficient. However, if the >> Router Advertisement sent by the current default router contains a >> modified Prefix Information option with the Router Address (R) bit >> set, and with the On-Link (L) flag set to indicate an on-link >> prefix, then the mobile node SHOULD check all subsequent Router >> Advertisements received from the same link-local address. In this >> check, some of the Prefix Information options received in the new >> Advertisement should indicate the same global router address which >> was indicated earlier. >> >> If they do not contain the same address even if the Advertisement >> was sent from the same link-local address, this is an indication >> that a movement may have occurred. In this case the mobile node >> SHOULD switch to a different router, such as the one from which it >> just received the Advertisement. >> >> o When the mobile node is sending packets, it is important to >> quickly detect when the default router becomes unreachable. To >> detect when its default router becomes unreachable, a mobile node >> SHOULD use Neighbor Unreachability Detection. >> >> In Neighbor Unreachability Detection indicates that the current >> default router is unreachable, the mobile node SHOULD switch to a >> new default router and potentially to a new primary care-of >> address. In above, there are 4 events of movement indication. It seems to me that the last item is different with the previous ones. Does the last item describes the event which can be considered as indication of movement? I doubt. --------------------- Jari Arkko responds to JinHyeock Choi: Your proposed changes sound reasonable, thanks. --------------------- Vijay Devarapalli responds to JinHyeock Choi: a better idea would be to do both simultaneously. if the current AR replies with a neighbor advertisement, the MN need not do anything. otherwise it should configure a new CoA and default router when it hears a router advertisement from a new router. SHOULD is the right word. otherwise RS/RA exchange will be delayed until the probing completes. JinHyeock, the NS/NA probe was to used when there is no mechanism available for detecting movement and the MN hasnt heard from its default router in a long time. it shouldnt be the default mechanism. --------------------- James Kempf responds to Vijay Devarapalli: I agree with Vjay. --------------------- Jari Arkko responds to James Kempf: Well, I changed the MAY back to a SHOULD then... --------------------- (A lengthy discussion omitted.) --------------------- Final text proposed by Ed, commented by many others: 11.5.1 Movement Detection The primary goal of movement detection is to detect L3 handovers. This section does not attempt to specify a fast movement detection algorithm which will function optimally for all types of applications, link-layers and deployment scenarios; instead, it describes a generic method that uses the facilities of IPv6 Neighbor Discovery, including Router Discovery and Neighbor Unreachability Detection. At the time of this writing, this method is considered well enough understood to recommend for standardization, however it is expected that future versions of this specification or other specifications may contain updated versions of the movement detection algorithm that have better performance. Generic movement detection uses Neighbor Unreachability Detection to detect when the default router is no longer bi-directionally reachable, in which case the mobile node must discover a new default router (usually on a new link). However, this detection only occurs when the mobile node has packets to send, and in the absence of frequent Router Advertisements or indications from the link-layer, the mobile node might become unaware of an L3 handover that occurred. Therefore, the mobile node should supplement this method with other information whenever it is available to the mobile node (e.g., from lower protocol layers). When the mobile node detects an L3 handover, it performs Duplicate Address Detection [13] on its link-local address, selects a new default router as a consequence of Router Discovery, and then performs Prefix Discovery with that new router to form new care-of address(es) as described in Section 11.5.2. It then registers its new primary care-of address with its home agent as described in Section 11.7.1. After updating its home registration, the mobile node then updates associated mobility bindings in correspondent nodes that it is performing route optimization with as specified in Section 11.7.2. Due to the temporary packet flow disruption and signaling overhead involved in updating mobility bindings, the mobile node should avoid performing an L3 handover until it is strictly necessary. Specifically, when the mobile node receives a Router Advertisement from a new router that contains a different set of on-link prefixes, if the mobile node detects that the currently selected default router on the old link is still bi-directionally reachable, it should generally continue to use the old router on the old link rather than switch away from it to use a new default router. Mobile nodes can use the information in received Router Advertisements to detect L3 handovers. In doing so the mobile node needs to consider the following issues: o There might be multiple routers on the same link, thus hearing a new router does not necessarily constitute an L3 handover. o When there are multiple routers on the same link they might advertise different prefixes. Thus even hearing a new router with a new prefix might not be a reliable indication of an L3 handover. o The link-local addresses of routers are not globally unique, hence after completing an L3 handover the mobile node might continue to receive Router Advertisements with the same link-local source address. This might be common if routers use the same link-local address on multiple interfaces. This issue can be avoided when routers use the Router Address (R) bit, since that provides a global address of the router. In addition, the mobile node should consider the following events as indications that an L3 handover may have occurred. Upon receiving such indications, the mobile node needs to send Router Solicitations to discover routers and prefixes on the new link. o If Router Advertisements that the mobile node receives include an Advertisement Interval option, the mobile node may use its Advertisement Interval field as an indication of the frequency with which it should expect to continue to receive future Advertisements from that router. This field specifies the minimum rate (the maximum amount of time between successive Advertisements) that the mobile node should expect. If this amount of time elapses without the mobile node receiving any Advertisement from this router, the mobile node can be sure that at least one Advertisement sent by the router has been lost. The mobile node can then implement its own policy to determine how many lost Advertisements from its current default router constitute an L3 handover indication. o Neighbor Unreachability Detection determines that the default router is no longer reachable. o With some types of networks, notification that an L2 handover has occurred might be obtained from lower layer protocols or device driver software within the mobile node. However, for some wireless technologies and deployment scenarios, an L2 handover may not always require an L3 handover, for example, if both the old link and the new link share the same access router and thus the same on-link prefixes. Therefore, link-layer indications do not guarantee that an L3 handover has occurred. For this reason mobile nodes should limit the rate at which they send Router Solicitations based on link-layer indications. --------------------- Jari Arkko writes: Here's the final (I hope) text on Movement Detection. Basically Ed's version + Erik's L2 + some wordsmithing from me. 11.5.1 Movement Detection The primary goal of movement detection is to detect L3 handovers. This section does not attempt to specify a fast movement detection algorithm which will function optimally for all types of applications, link-layers and deployment scenarios; instead, it describes a generic method that uses the facilities of IPv6 Neighbor Discovery, including Router Discovery and Neighbor Unreachability Detection. At the time of this writing, this method is considered well enough understood to recommend for standardization, however it is expected that future versions of this specification or other specifications may contain updated versions of the movement detection algorithm that have better performance. Generic movement detection uses Neighbor Unreachability Detection to detect when the default router is no longer bi-directionally reachable, in which case the mobile node must discover a new default router (usually on a new link). However, this detection only occurs when the mobile node has packets to send, and in the absence of frequent Router Advertisements or indications from the link-layer, the mobile node might become unaware of an L3 handover that occurred. Therefore, the mobile node should supplement this method with other information whenever it is available to the mobile node (e.g., from lower protocol layers). When the mobile node detects an L3 handover, it performs Duplicate Address Detection [13] on its link-local address, selects a new default router as a consequence of Router Discovery, and then performs Prefix Discovery with that new router to form new care-of address(es) as described in Section 11.5.2. It then registers its new primary care-of address with its home agent as described in Section 11.7.1. After updating its home registration, the mobile node then updates associated mobility bindings in correspondent nodes that it is performing route optimization with as specified in Section 11.7.2. Due to the temporary packet flow disruption and signaling overhead involved in updating mobility bindings, the mobile node should avoid performing an L3 handover until it is strictly necessary. Specifically, when the mobile node receives a Router Advertisement from a new router that contains a different set of on-link prefixes, if the mobile node detects that the currently selected default router on the old link is still bi-directionally reachable, it should generally continue to use the old router on the old link rather than switch away from it to use a new default router. Mobile nodes can use the information in received Router Advertisements to detect L3 handovers. In doing so the mobile node needs to consider the following issues: o There might be multiple routers on the same link, thus hearing a new router does not necessarily constitute an L3 handover. o When there are multiple routers on the same link they might advertise different prefixes. Thus even hearing a new router with a new prefix might not be a reliable indication of an L3 handover. o The link-local addresses of routers are not globally unique, hence after completing an L3 handover the mobile node might continue to receive Router Advertisements with the same link-local source address. This might be common if routers use the same link-local address on multiple interfaces. This issue can be avoided when routers use the Router Address (R) bit, since that provides a global address of the router. In addition, the mobile node should consider the following events as indications that an L3 handover may have occurred. Upon receiving such indications, the mobile node needs to perform Router Discovery to discover routers and prefixes on the new link, as described in Section 6.3.7 of RFC 2461 [12]. o If Router Advertisements that the mobile node receives include an Advertisement Interval option, the mobile node may use its Advertisement Interval field as an indication of the frequency with which it should expect to continue to receive future Advertisements from that router. This field specifies the minimum rate (the maximum amount of time between successive Advertisements) that the mobile node should expect. If this amount of time elapses without the mobile node receiving any Advertisement from this router, the mobile node can be sure that at least one Advertisement sent by the router has been lost. The mobile node can then implement its own policy to determine how many lost Advertisements from its current default router constitute an L3 handover indication. o Neighbor Unreachability Detection determines that the default router is no longer reachable. o With some types of networks, notification that an L2 handover has occurred might be obtained from lower layer protocols or device driver software within the mobile node. While further details around handling L2 indications as movement hints is an item for further study, at the time of writing this specification the following is considered reasonable: An L2 handover indication may or may not imply L2 movement and L2 movement may or may not imply L3 movement; the correlations might be a function of the type of L2 but might also be a function of actual deployment of the wireless topology. Unless it is well-known that an L2 handover indication is likely to imply L3 movement, instead of immediately multicasting a router solicitation it may be better to attempt to verify whether the default router is still bi-directionally reachable. This can be accomplished by sending a unicast Neighbor Solicitation and waiting for a Neighbor Advertisement with the solicited flag set. Note that this is similar to Neighbor Unreachability detection but it does not have the same state machine, such as the STALE state. If the default router does not respond to the Neighbor Solicitation it makes sense to proceed to multicasting a Router Solicitation. --------------------- Basavaraj Patil writes: This the final version of the MD text. Any further discussion on this topic will not impact the text in the MIPv6 base specification.