Subject: RE: Proposal to change aspects of Neighbor Discovery

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 1 Sep 2006 03:00:37 -0700

> > 3) The current ND specs have an upper limit of 30 minutes on the
 > >   interval between router advertisements. That should be 
 > changed, to
 > >   allow deployments to use a higher value. (that is the
 > >   assertion/problem.)
 > >
 > 
 > This is certainly possible and one could do it, but at some 
 > point one must 
 > ask what is the point of having the multicast RA if the 
 > timeout is something 
 > like 2 days. If the point of the multicast RA is to allow 
 > softstate to time 
 > out to preserve memory, then a very lengthy interval will 
 > certainly decrease 
 > the effectiveness of that. Also, FWIW, it won't please the 
 > cellular guys, 

=> Honestly, James, please don't make these blanket statements about
such a 
large group of people. As a "cellular guy" I'm quite happy with anything
between 1 to
2 hrs and I'm not hurting too much with the 30 minute limit either. None
of the cellular
guys I know complained too much about the 30 minute limit when I told
them. Of course if it's
one hour they'll be happier but to say they don't want anything at all
is outlandish. oops, 
I'm starting to generalise! Better stop now.

Thanks,
Hesham

 > because what they have right now doesn't ever require a 
 > traffic channel to 
 > come up unless there is traffic specifically for that 
 > terminal (i.e. either 
 > unicast or for a global multicast address that the terminal 
 > has subscribed 
 > to).
 > 
 > > What makes this all not as easy as it sounds is that 
 > periodic RAs are
 > > a simple protocol. Send them periodically (and somewhat 
 > frequently) so
 > > that if one or two get lost, hosts continue operating and nothing
 > > breaks. Even if they miss two, they'll receive a third one soon
 > > enough.  That works pretty well when the periodic interval is
 > > short. It doesn't really work at all, when the periodic interval is
 > > hours apart. Unless the RAs are delivered with a high degree of
 > > reliability.
 > >
 > 
 > Most simple and elegant. If the last hop is wired, it's 
 > about perfect.
 > 
 > > How reliably will the periodic RAs  be delivered in the networks at
 > > issue here? Are they essentially reliable link layers?
 > >
 > 
 > The cellular networks typically have extensive ARQ support 
 > (something like a 
 > maximum of 8 for wcdma I think) to ensure that the packet 
 > gets across. They 
 > also have lots of support in the network for radio resource 
 > management, so 
 > it is almost never the case that the link will get 
 > congested. If a terminal 
 > tries to claim more bandwidth then it is subscribed for, it 
 > just doesn't get 
 > it. This isn't true for 802.11. The ARQ support is pretty 
 > good, but if the 
 > link gets congested, the backoff time tends to increase, 
 > especially with CBR 
 > traffic like VoIP. The apps then tend to time out. So it's 
 > possible that a 
 > multicast RA would be dropped, unless it was somehow given 
 > higher priority 
 > and the wireless link was running 802.11e.
 > 
 >               jak 
 > 
 > 
 > --------------------------------------------------------------------
 > IETF IPv6 working group mailing list
 > [email-masked]
 > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
 > --------------------------------------------------------------------
 > 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pars Mutaf <[email-masked]>
Date: Fri, 01 Sep 2006 14:14:32 +0200

Hello, 

In addition to the previous remarks:

Imagine that you have a friend who calls you to 
check if you are still reachable, say every 
15 minutes. And imagine that you don't need to 
answer!

The periodic RAs are that friend. 

This is frankly excellent. They periodically 
simulate an incoming call, show me that the system 
is capable of delivering incoming calls.

If there is a problem, I can move to another
operator's subnet! 

And please note that RS/RA doesn't check the 
paging system nor the paging channels. The only 
true system check procedure is using the 
unsolicited multicast RAs. 

Multicast periodic RAs check the paging system,
the paging channels, and also the traffic channels.
If you have received a periodic RA, this means
that the whole system is working smoothly.

RS/RA does NOT check the paging system nor the 
paging channels. It is not a good test.

cheers,
pars

PS: Why the cellular network would stop working
normally? I don't know. Because of power cut?
sabotage? DoS attack? 

For DoS attacks on paging channels please 
see the new Wise'06 paper: 

http://ipmon.sprint.com/publications/uploads/wise06_paging.pdf

There are real measurement results.

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 05 Sep 2006 11:45:55 +0200

Hello, 

On Thu, 2006-08-31 at 15:45 -0400, Thomas Narten wrote:

> RAs aren't used for reachability we have
> ND/NUD for that. 

NUD (RS-RA) becomes useless when the host is in dormant mode and 
reachable via a paging channel.

To initiate NUD, the host needs to wake up and send RS. The router's
answer (unicast RA) will be received via a traffic channel. It won't be
received via a paging channel, because the host is NOT in dormant mode.
That is, the paging channel is not tested with NUD. 

After the NUD procedure, the host will re-enter dormant mode. 
But, the host doesn't know if it is reachable. Because the 
paging channel wasn't tested.

With unsolicited RAs:

The unsolicited RAs can be received by dormant mode hosts. That is,
they can check the paging channels. Here is the procedure:

1. Router sends an unsolicited periodic RA to a host.
2. The host is in dormant mode, therefore the RA triggers 
   link-layer paging.
3. Host receives a link-layer paging message via a paging channel, 
   and wakes up.
4. Host acquires a traffic channel.
5. Host receives the unsolicited RA via the traffic channel. 

If the host successfully received an unsolicited RA, this means 
that the traffic channel and also the paging channel worked 
smoothly. 

pars

---

From: Thomas Narten <[email-masked]>
Date: Tue, 05 Sep 2006 09:35:23 -0400

> > RAs aren't used for reachability we have

Once again, NUD (as I understand it, and the way it is defined in
2461) is not based on RS/RA exchanges. It is based on NS/NA
exchanges. Thus, I do not at all understand the rest of your note.

Further, based on what you wrote below, I think you should start by
defining the problem statement - what it is you are trying to
solve. Your combination of messages sent via a paging channel and one
(and apparently only one message) sent via the normal data channel
doesn't implement NUD as I understand it.

Finally, why do you care about NUD if the node is in dormant mode? If
the node is dormant, having its NUD state kept up-to-date seems like
an odd thing to require (especially since NUD state is short-lived, on
the order of minutes).

> that the traffic channel and also the paging channel worked 

Not as I understand it. It only means that the data channel was shown
to work in one direction -- NUD explicitely verifies that a channel is
working in _both_ directions. Are you assuming that if one can send
data via the paging channel, that is good enough to conclude that the
data channel also works? Is that a valid assumption?

Thomas

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 05 Sep 2006 16:52:31 +0200

> an odd thing to require (especially since NUD state is short-lived, on

OK (but see below please)

> data channel also works? Is that a valid assumption?

I wasn't assuming this. 

NUD checks the traffic channel in both directions. That's OK. 
But after the NUD procedure, the host enters dormant mode and 
becomes reachable via another channel: the paging channel that 
wasn't tested.

Consequently, the following scenario is possible:

1. Host performs NUD. Result is OK.
2. Host enters dormant mode.
3. There is an incoming call, but the paging channel is down.
4. The host can't be reached.

NUD reported good reachability, but the host missed the call.
Because NUD didn't test the paging channel (it can't).

IMHO, the following may make sense:

1/ Using NUD for checking the traffic channel (in both directions).
2/ Using unsolicited periodic RAs, for checking the paging channel.

In conclusion, all I'm saying is that unsolicited periodic RAs
are very useful. They shouldn't be removed. On the contrary, 
I believe that the RA interval shouldn't be more than 5 minutes
when there is paging channel.

(what's that? incoming flames! :-)

If you have missed 2 or 3 unsolicited RAs, you can suspect
a problem. You can move to another network, for example.

This has a cost, I agree. But reliability has a cost in general.
Security also has a cost. Note also that, we can always reduce 
the subnet size to reduce the signaling cost of periodic RAs.

I think we will still have a very good battery optimization
(less optimal, but more reliable and secure). Battery technology
is evolving at a high speed. I'm proposing that we profit from
that for having some reliability. 

This makes sense?

pars

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 5 Sep 2006 08:22:39 -0700

> Because NUD didn't test the paging channel (it can't).

=> As you say above, "it can't (test the paging channel)". I don't think
it's the responsibility of the IP layer to test signalling channels
really. The paging channel is not a different physical medium and its
failure (given the reachability on traffic channels) is not due to
physical unreachability. Therefore, IMHO it is the responsibility of the
link layer to work this out. 

Hesham

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 05 Sep 2006 18:12:20 +0200

> link layer to work this out. 

Hello, 
I couldn't understand why NUD is the responsibility of IP, 
but the other is not.

So, why NUD isn't the link-layer's responsibility?

Thanks,
pars

---

From: "James Kempf" <[email-masked]>
Date: Tue, 5 Sep 2006 10:24:25 -0700

Let me be more specific. It will not convince 3GPP and Wimax Forum that 
periodic, multicast RAs should be deployed in their network. 3GPP2 already 
does not use RA beacons for Mobile IPv4.

            jak

----- Original Message ----- 
From: "Soliman, Hesham" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Thomas Narten" 
<[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; <[email-masked]>; "ext Pars 
MUTAF" <[email-masked]>
Sent: Friday, September 01, 2006 3:00 AM
Subject: RE: Proposal to change aspects of Neighbor Discovery

Thanks,
Hesham

---

From: "James Kempf" <[email-masked]>
Date: Tue, 5 Sep 2006 11:22:40 -0700

Pars,

3GPP2, which deploys Mobile IPv4, has declined to use periodic RAs as 
beacons for their FAs. In general, the problem is that cellular operators 
don't want to use traffic channels for IP signaling that they don't think 
they need. They pay lots of money for the spectrum, and they charge their 
customers alot to use it too. The network operators know at the radio level 
whether the paging channel is working or not, they don't need to send IP 
messages out to figure that out. Cellular protocols contain lots of control 
traffic between the network and the mobile terminal at the link level for 
things like power control, and it is more efficient to let that take care of 
these kinds of functions.

            jak

----- Original Message ----- 
From: "Pars Mutaf" <[email-masked]>
To: "Thomas Narten" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "Erik Nordmark" 
<[email-masked]>; "Basavaraj Patil" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, September 05, 2006 7:52 AM
Subject: Re: Proposal to change aspects of Neighbor Discovery

---

From: "James Kempf" <[email-masked]>
Date: Tue, 5 Sep 2006 12:54:35 -0700

Erik,

Couple points.

Most cellular networks don't have more than one active last hop router, so 
the issue of multiple routers doesn't apply.

Regarding the number of packets, the question is over what period of time 
are the packets sent. If the router needs to emulate multicast, then the M*N 
unicast RAs either need to be spread out over some period or you'd end up 
with congestion. It's true that the number of packets is more if explicit 
solicitation is done, but is that such an issue given the bandwidth 
available on modern wired and wireless links? Again also, the RS/RAs could 
be spread over a longer time period to reduce the possibility of congestion.

Regarding filtering for dormant mode hosts, having the BS filter out the 
multicast RAs is certainly an option, since the BSs will know which hosts 
are in dormant mode. This would not require any special protocol to tell the 
last hop router which hosts are in dormant mode or not, if the BSs are IP 
devices. In current 3G networks, they aren't, but in Wimax they will be. 
However, at least one cellular SDO (3GPP2) has declined to specify beacon 
RAs for MIPv4 movement detection, I believe primarily because of dormant 
mode (Kuntal can correct me if I am wrong here). So I suspect if IETF does 
nothing on this, the cellular SDOs will simply ignore the IETF 
recommendation because it doesn't apply to their networks, and will specify 
that multicast RAs are not done, because most of the people active in Wimax 
Forum are 3GPP2 people so they are familiar with the way 3GPP2 does it. Of 
course, maybe IETF doesn't care in the end whether or not this gets deployed 
in cellular networks, in which case, leaving it as it is in RFC 2461 and 
saying "if you feel this is an issue for dormant mode hosts, then have the 
BS filter"  is fine.

            jak

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Basavaraj Patil" <[email-masked]>; <[email-masked]>; "ext 
Pars MUTAF" <[email-masked]>
Sent: Thursday, August 31, 2006 5:17 PM
Subject: Re: Proposal to change aspects of Neighbor Discovery

> James Kempf wrote:
>
>> I think the proposal was not to keep the router information until it was 
>> explicitly invalidated but rather that the host could individually 
>> solicit prior to the expiration of the lifetime. The router information 
>> state is still soft state, its just that the renewal is different. 2641 
>> explicitly prohibits solicitation except for 5 specific cases, and 
>> renewing a router table entry is not one of them.
>>
>> For some types of wireless links, multicast unsolicited router 
>> advertisements are not really that helpful in determining router 
>> reachability, because the host may be able to hear the router, but not 
>> transmit. If the host depends on a multicast unsolicited router 
>> advertisement, it could end up with a lengthy NUD procedure before it 
>> determined that it couldn't really use the router. That's one reason why 
>> an RS-RA exchange would be more useful. Another is the issue of dormant 
>> mode hosts, which is I think what prompted the original posting on this 
>> thread.
>
> But the cost of solicited advertisement in terms of load on the network is 
> higher than unsolicited.
>
> Assume there are N routers on the link, and M hosts.
>
> With unsolicted multicast advertisements we get N multicast RAs per time 
> period. If we assume the the link layer emulates multicast with repeated 
> unicast, that would end up bring M*N unicast RAs per time period.
>
> With solicited RAs, presumbly we'd want the RS to be unicast instead of 
> sent to all-routers, right? (Otherwise we'd have a ton of multicast RSs to 
> handle.)
> Thus each host would need to unicast at least one RS per time period. But 
> with N routers providing potentially different information it would seem 
> each host needing to unicast an RS to each one each time period. Thus we'd 
> end up with N*M RSs plus N*M RAs in response; twice the number of packets!
>
> Note that is addition to sending more packets, such an approach can not 
> robustly deal with a replacement of a router.
> When a new router comes up it initially multicasts a few rapid RAs. But 
> all those could be lost. The fact that the new router (as well as others) 
> keep on multicasting RAs periodically means that even if the initial RAs 
> were lost, the hosts would sooner or later receive an RA. Without this, we 
> can easily get into states where the new router is introduced, and a day 
> later the old router is turned off, yet there might be hosts which do not 
> know there is a new router.
> Thus you'd need to have the hosts fall back to sending *multicast* RSs to 
> compensate for the lack of periodic RAs.
>
> To me the dormant host seems like a red herring.
> For a dormant node there is a filter somewhere which determines what 
> packets will make it wake up. I guess this filter could be either in the 
> NIC/radio on the host, or in the network. If it is in the network, then a 
> match on the filter would make the network send the "wakeup" signal to the 
> host.
>
> Given this, we can get the desired behavior of not having the host wakeup 
> due to periodic RAs if the wakeup filter blocks (doesn't wake up) from a 
> RA.
> This means that when the host wakes up it might find that its default 
> routers and/or prefixes have timed out. But we need to deal with that in 
> the solicited RA case as well (presumably we don't want to have the host 
> wake up every time period to send the RS/RSs.)
> And dealing with that case can be done by just invoking the DNA 
> procedures - send a unicast RS to a known router and wait for an RA in 
> response.
>
> Thus I don't see an alternative to periodic RAs that is more attractive; 
> the alternative seems to cause more packets and be less robust.
>
>    Erik
>

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 5 Sep 2006 21:48:32 -0700

> So, why NUD isn't the link-layer's responsibility?

=> Because of two reasons:
- Some link layers fon't have this connection-oriented service and
therefore do not do NUD. 
- NUD tests reachability of the IP peer not the link layer peer. Since
there can be multiple link layers between two peers, relying on link
layers in not useful to IP. 

But I certainly don't expect NUD to test every channel within a link
layer, it's not a useful mechanism anyway because testing the traffic
channels does test general reachability of the physical media. 

Hesham

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 5 Sep 2006 21:51:40 -0700

> periodic, multicast RAs should be deployed in their network. 

=> Well, I don't think that's specific, but obviously you do. 3GPP
*already* defined the use of IPv6 and already recommends setting the
lifetime to a max. So please tell us if there are any official
statememnts or documents from 3GPP to indicate concerns about this.
Otherwise what you say is your opinion, which is fine, but if that's the
case you shouldn't speak on behalf of 3GPP.

 > 3GPP2 already 

=> Completely different issue. ND is not a MIP function and is certainly
not a "beacon" and we're not trying to make it one. A message every 30
mins is not a beacon.

Hesham

 >  > Administrative Requests: 
 > https://www1.ietf.org/mailman/listinfo/ipv6
 >  >

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 06 Sep 2006 11:15:13 +0200

> channels does test general reachability of the physical media. 

Thanks. But I still believe that a host should be able to test 
if it is reachable in dormant mode (reachable, or reachable within
reasonable delay). This is good for dormant mode security.

Using unsolicited RAs is one possibility. There may be others.

(this means that I'm neutral in this discussion, and  
the commercial operator doesn't really care :-)

pars

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 6 Sep 2006 02:29:07 -0700

> reasonable delay). This is good for dormant mode security.

=> I'm not sure that you appreciate the fact that these are *logical*
channels, where *logical* means that they're essentially different slots
on the same frequency (e.g. in FDD systems). What you're suggesting is
equivalent to saying that you want to test whether a particular field in
a frame can be set to a specific value. It seems very strange to me in
the context of reachability detection.

Hesham

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 06 Sep 2006 12:17:00 +0200

> the context of reachability detection.

The paging channel is not dedicated to one terminal, it serves 
all terminals (there are thousands of terminals in a paging area). 
Paging channels can be overloaded (naturally or maliciously). In 
this case, an incoming session may be missed. 

For paging, a different, special and stateful protocol is 
used. It is not just a link. It has an architecture and 
protocol. Failure is possible. 

How the dormant host detects these problems? 

Periodically generating an RA and delivering it to the dormant
host, looked like a good test to me. 

pars

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 6 Sep 2006 04:30:36 -0700

> this case, an incoming session may be missed. 

=> This is completely orthogonal to this mailing list and pretty much to
IETF. This is a standard likn layer design issue that I don't think we
need to solve here. I don't see the relationship to this thread.

 > How the dormant host detects these problems? 

=> You should pose the question to a link layer designer. There is
nothing we need to do here for this problem.

 > host, looked like a good test to me. 

=> You mean "wake up the host periodically" That's how you want to test
the pagin channel. 
I don't agree with it, but I don't think it's a discussion for this list
anyway. 

Hesham

---

From: Thomas Narten <[email-masked]>
Date: Wed, 06 Sep 2006 08:25:40 -0400

> reasonable delay). This is good for dormant mode security.

Why? This is a problem statement you are asserting. Rather than
discuss possible solutions, I think it is important to first establish
whether this is an actual problem people think we need to solve.

Personally, I'm skeptical. If a node is dormant, why does it want to
expend resources (like waking up) if the link (at the IP layer) isn't
working -- given that it is dormant? It's far from clear that a
dormant node should monitor link status with the same aggressiveness
it would if it was awake, especially if that has impact on battery
life.

It may well be that it wants to maintain the liveness of the paging
channel when it is in dormant mode, but my initial reaction would be
that that would be an L2 issues exclusively, and not something that
needs to be visible to IP.

Thomas

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 06 Sep 2006 19:50:23 +0200

Hello,

> whether this is an actual problem people think we need to solve.

OK.

When the host is dormant, it is reachable through a different 
set of links. Because, the dormant mode state must be checked 
somewhere in the system, etc. There is also the paging channel.
(different, and time-slotted). Paging has a complex architecture.
It is more complicated than active mode support. An IP-layer 
solution can check all of these and detect failure: From AR
to the host, everything between the two will be tested.

IMHO, we should not assume that the cellular system is perfectly
managed. (Take the municipal networks, for example, think of 
WiMax, it supports paging).

In addition, there is a performance/security problem with 
paging and dormant mode in general (for which the commercial 
operator does not have a solution). The paging system is easily 
congested. There are two potential reasons:

1/ Flash crowd: Many hosts are called simultaneously. The 
incoming packets trigger link-layer paging. Paging messages, 
hence the IP packets are queued in the system. This is a 
well-known problem. There is no solution. If the paging 
system is congested, you should wait. The call setup delay 
may be very long. 

Nobody tells you that (at the link layer). 

2/ Attack: Attacker (anywhere in the Internet) sends many 
packets to different mobile hosts in the same area. Most of 
the hosts are dormant. Consequently, the above scenario is 
artificially created. The results can be more serious than 
a flash crowd.

You may want to take a look at:
ipmon.sprint.com/publications/uploads/wise06_paging.pdf
(Wireless Security Workshop, with Mobicom'06, Sept. 29, 2006)

In both cases, 1/ and 2/,  the problem is the same:
IP packets don't reach the hosts. They are delayed or lost. 
The loss is *not* caused by increased BER (bit error rate). 
The physical conditions may be perfect. The problem is that 
the link is congested. IP packets are waiting or being lost 
somewhere (between the AR and the hosts). 

The host can detect these problems at the IP layer and employ 
an IP-layer solution: The IP-layer can be told to move to 
another (parallel) subnet. This is the only solution.

> it would if it was awake, especially if that has impact on battery

I'm not sure if the host needs to be aggressive. The test 
interval can be set longer (than active mode NUD). 

Or, the host can check its dormant mode reachability before 
entering dormant mode. 

This has an additional energy cost, yes I agree. This is the
cost of reliability. NUD (standard) also a has a cost. But it 
is necessary. 

pars

---

From: Pars MUTAF <[email-masked]>
Date: Thu, 7 Sep 2006 21:39:03 +0200

Hi all,

I would like to thank Thomas for asking me an explanation
of my point of view (from the previous discussion
Re: Proposal to change aspects of Neighbor Discovery)).

But, I wasn't really hoping an IPv6 WG action on this
issue, in fact. Not because I think it is an L2 problem
(Hesham doesn't agree). Because the problem is too
difficult to solve before we actually see it.

Thanks,
pars

> > needs to be visible to IP.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: Pars Mutaf <[email-masked]>
Date: Mon, 11 Sep 2006 20:02:48 +0200

Hello, 

The issue was raised again in 16ng, so I'm trying to help
moving forward on this issue. (I dropped out my dormant mode
reliability concerns for future work, but I hope this has
complemented the discussion.)

I have a couple of comments on the signaling analysis made
by Erik and James:

IMHO the comparison of RS/RA signaling vs unsolicited/periodic
RA is incomplete. At the IP layer, the cost RS/RA is clearly
twice the cost of unsolicited/periodic RA. I agree. This
doubles the load on the AR's interface (if I understand 
correctly).

However, at the link layer the situation is inversed 
(especially on wireless links). Most of the unsolicited RAs 
trigger paging (say 90% of them). This means that most of 
the unsolicited/periodic RAs trigger N paging messages, plus 
the paging protocol exchange messages, plus the RA. In addition, 
the resource being consumed is the paging channel, which is 
scarce. But I ignore the exact paging packet sizes.

As for the RA filtering possibility:

Filtering at the base stations may not be enough. Filtering should 
be done at link-layer paging agents (I'm using the generic term).
Otherwise, the paging agent will unnecessarily generate N messages 
(per RA), which will later be dropped by the base stations. Filtering
should also be made at the base stations. Because some of the RAs 
will trigger paging, the others won't.

In addition to other comments, my personal suggestion to the 
authors would be: not only focusing on the energy cost but also 
the paging cost, and resubmitting the draft. The solution is also
unclear. The RAs should be turned OFF, or the RA interval should 
be increased? Which one? If they are not necessarily turned OFF, 
they should be spread over time to avoid paging channel congestion. 
This argument also applies to the current maximum period (30min). 
But precisely how they are spread? 

My two cents.

pars

ps: On more point. If the proposal is made for 16ng, the number of 
hosts in the subnet reported by Raj, which was several hundred 
thousands (in the context of 3GPP) does not apply probably. In 
16ng, there will probably be only one paging area under the AR (not 
sure yet). In this case, if filtering is considered as the best
solution, it can work at the BS. Because the AR is the paging agent.

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 20 Sep 2006 11:25:09 +0200

> will trigger paging, the others won't.

hi,

While talking with a colleague, we have realized that paging by 
the BS isn't possible in fact (I don't remember who proposed it, 
it looked like an anonymous magic solution). 
Because, when the BS receives a link-layer paging message, it 
cannot figure out whether: 

1/ The paging message was triggered by an incoming session, or 
2/ The paging message was triggered by a periodic RA. 

In conclusion, if filtering of the periodic RAs is considered as 
the best solution (not my argument), it should be done at the
paging agent. This is not only more optimal (as I argued above),
this is the only solution. 

The BS can of course filter the RA after paging, but it's too 
late. The host is woken up, the paging bandwidth is consumed.

(UIMS, this point also applies to 16ng, and when paging agent = AR.)

pars

---

From: "James Kempf" <[email-masked]>
Date: Wed, 20 Sep 2006 09:04:56 -0700

Why can't the BS simply filter the RA? It looks at the IP packet header, if 
the packet was sent to All Hosts Multicast and it's ICMP RA it drops that 
packet for those mobile nodes that are dormant.

            jak

---

From: Pars MUTAF <[email-masked]>
Date: Wed, 20 Sep 2006 19:16:33 +0200

> packet for those mobile nodes that are dormant.

Because by the time the BS received the RA, the host was already paged
and woken up.

Here is the protocol:

AR: access router
RA: router advertisement
MH: mobile host
BS: base station

1. The AR generates a unicast periodic unsolicited RA destined for MH.
2. The host is dormant, then the RA is forwarded to the L2 paging subsystem.
3. The paging subsystem pages the host in its current L2 paging area.
4. All BSs in the paging area, alert the MH.
5. The MH wakes up in its current cell, and brings up a traffic channel.
6. The system forwards the periodic unsolicited RA to the host.

You are proposing to filter the RA in the final step (step 6).
This is useless. The host was already paged and woken up.

The RA should be filtered by the paging subsystem. I.e. it should be filtered
before the host is paged and woken up.

The goal of the I-D by Raj and Syam was turning-off the periodic RAs and avoid
paging and waking up the host. If you wish to do the same through "filtering"
(i.e. without modifying the AR impl.), then you need to filter the RA before
the host is paged.

(Otherwise the BS wakes up the MH, before it receives the RA.)

Greets,
pars

---

From: "James Kempf" <[email-masked]>
Date: Wed, 20 Sep 2006 11:41:14 -0700

There is an assumption here that the "L2 paging system" is run off the AR. 
This is not necesarily the case. It won't be for Wimax, for example.

            jak

----- Original Message ----- 
From: "Pars MUTAF" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 20, 2006 10:16 AM
Subject: Re: Proposal to change aspects of Neighbor Discovery

>> >> > Most cellular networks don't have more than one active last hop 
>> >> > router,
>> >> > so
>> >> > unicast RAs either need to be spread out over some period or you'd 
>> >> > end
>> >> > up
>> >> > last hop router which hosts are in dormant mode or not, if the BSs 
>> >> > are
>> >> > IP
>> >> > mode (Kuntal can correct me if I am wrong here). So I suspect if 
>> >> > IETF
>> >> > does
>> >> > that multicast RAs are not done, because most of the people active 
>> >> > in
>> >> > Wimax
>> >> > Forum are 3GPP2 people so they are familiar with the way 3GPP2 does 
>> >> > it.
>> >> > Of
>> >> > saying "if you feel this is an issue for dormant mode hosts, then 
>> >> > have
>> >> > the
>> >> > BS filter"  is fine.
>> >> >
>> >> >             jak
>> >> >
>> >> > >> I think the proposal was not to keep the router information until 
>> >> > >> it
>> >> > >> was
>> >> > >> state is still soft state, its just that the renewal is 
>> >> > >> different.
>> >> > >> 2641
>> >> > >> reachability, because the host may be able to hear the router, 
>> >> > >> but
>> >> > >> not
>> >> > >> advertisement, it could end up with a lengthy NUD procedure 
>> >> > >> before
>> >> > >> it
>> >> > >> determined that it couldn't really use the router. That's one 
>> >> > >> reason
>> >> > >> why
>> >> > >> mode hosts, which is I think what prompted the original posting 
>> >> > >> on
>> >> > >> this
>> >> > >> thread.
>> >> > >
>> >> > > With unsolicted multicast advertisements we get N multicast RAs 
>> >> > > per
>> >> > > time
>> >> > > With solicited RAs, presumbly we'd want the RS to be unicast 
>> >> > > instead
>> >> > > of
>> >> > > sent to all-routers, right? (Otherwise we'd have a ton of 
>> >> > > multicast
>> >> > > RSs to
>> >> > > handle.)
>> >> > > Thus each host would need to unicast at least one RS per time 
>> >> > > period.
>> >> > > But
>> >> > > with N routers providing potentially different information it 
>> >> > > would
>> >> > > seem
>> >> > > each host needing to unicast an RS to each one each time period. 
>> >> > > Thus
>> >> > > we'd
>> >> > > Note that is addition to sending more packets, such an approach 
>> >> > > can
>> >> > > not
>> >> > > When a new router comes up it initially multicasts a few rapid 
>> >> > > RAs.
>> >> > > But
>> >> > > keep on multicasting RAs periodically means that even if the 
>> >> > > initial
>> >> > > RAs
>> >> > > can easily get into states where the new router is introduced, and 
>> >> > > a
>> >> > > day
>> >> > > later the old router is turned off, yet there might be hosts which 
>> >> > > do
>> >> > > not
>> >> > > packets will make it wake up. I guess this filter could be either 
>> >> > > in
>> >> > > the
>> >> > > match on the filter would make the network send the "wakeup" 
>> >> > > signal
>> >> > > to the
>> >> > > host.
>> >> > >
>> >> > > routers and/or prefixes have timed out. But we need to deal with 
>> >> > > that
>> >> > > in
>> >> > > the solicited RA case as well (presumably we don't want to have 
>> >> > > the
>> >> > > host
>> >> > > procedures - send a unicast RS to a known router and wait for an 
>> >> > > RA
>> >> > > in
>> >> > > response.
>> >> > >

---

From: Pars MUTAF <[email-masked]>
Date: Wed, 20 Sep 2006 21:49:54 +0200

> This is not necesarily the case. It won't be for Wimax, for example.

Hello,
OK. The discussion about Wimax now ;-)

But this should be orthogonal to our problem. In paging, in general,
the system (AR in this case) doesn't know where the dormant host is
located. The mobile host is "asked" to report its exact location,
i.e. cell. (This is what is meant by "paging").

*The BSs don't know anything about the dormant host*. The host is paged
in all cells of the paging area. That's why wireless bandwidth needs to be
consumed for paging in all cells of the paging area. (This is a well-known
problem of paging. 100s of research papers attempted to reduce this
bandwidth cost.)

Then, the host hears the paging message while sleeping in one of
the cells, wakes up, and a location update is sent.

The AR has now learned the current BS of the host. The packet that
triggered paging is forwarded to the current BS of the host.

Filtering of the RA by the BS is too late. Because the host was
already paged in all cells and woken up.

pars

---

From: "James Kempf" <[email-masked]>
Date: Wed, 20 Sep 2006 13:02:31 -0700

So here's a counter example.

Suppose there is an IP based but wireless link layer specific protocol that 
lets BSes communicate about dormant mode hosts. When a host goes into 
dormant mode, all BSes in the paging area learn about it via the protocol. 
When paging happens, this protocol is used by the BS where the mobile node 
originally went into dormant mode to notify other BSes to page. Etc. That 
should take care of filtering.

Right now, paging is handled by L2 specific mechanisms. In 3GPP, I think it 
even depends on the MSC, i.e. the circuit switched part of the network. 
Bottom line is, other SDOs get to say how it works, not the IETF.

            jak

----- Original Message ----- 
From: "Pars MUTAF" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 20, 2006 12:49 PM
Subject: Re: Proposal to change aspects of Neighbor Discovery

>> >> Why can't the BS simply filter the RA? It looks at the IP packet 
>> >> header,
>> >> if
>> > The goal of the I-D by Raj and Syam was turning-off the periodic RAs 
>> > and
>> > avoid
>> >> >> > Regarding the number of packets, the question is over what period 
>> >> >> > of
>> >> >> > time
>> >> >> > are the packets sent. If the router needs to emulate multicast, 
>> >> >> > then
>> >> >> > the M*N
>> >> >> > available on modern wired and wireless links? Again also, the 
>> >> >> > RS/RAs
>> >> >> > could
>> >> >> > Regarding filtering for dormant mode hosts, having the BS filter 
>> >> >> > out
>> >> >> > the
>> >> >> > multicast RAs is certainly an option, since the BSs will know 
>> >> >> > which
>> >> >> > hosts
>> >> >> > are in dormant mode. This would not require any special protocol 
>> >> >> > to
>> >> >> > tell the
>> >> >> > devices. In current 3G networks, they aren't, but in Wimax they 
>> >> >> > will
>> >> >> > be.
>> >> >> > However, at least one cellular SDO (3GPP2) has declined to 
>> >> >> > specify
>> >> >> > beacon
>> >> >> > recommendation because it doesn't apply to their networks, and 
>> >> >> > will
>> >> >> > specify
>> >> >> > course, maybe IETF doesn't care in the end whether or not this 
>> >> >> > gets
>> >> >> > deployed
>> >> >> > in cellular networks, in which case, leaving it as it is in RFC 
>> >> >> > 2461
>> >> >> > and
>> >> >> > Cc: "Basavaraj Patil" <[email-masked]>; 
>> >> >> > <[email-masked]>;
>> >> >> > "ext
>> >> >> > >> an RS-RA exchange would be more useful. Another is the issue 
>> >> >> > >> of
>> >> >> > >> dormant
>> >> >> > > end up with N*M RSs plus N*M RAs in response; twice the number 
>> >> >> > > of
>> >> >> > > packets!
>> >> >> > >
>> >> >> > > all those could be lost. The fact that the new router (as well 
>> >> >> > > as
>> >> >> > > others)
>> >> >> > > were lost, the hosts would sooner or later receive an RA. 
>> >> >> > > Without
>> >> >> > > this, we
>> >> >> > > Thus you'd need to have the hosts fall back to sending 
>> >> >> > > *multicast*
>> >> >> > > RSs to
>> >> >> > > NIC/radio on the host, or in the network. If it is in the 
>> >> >> > > network,
>> >> >> > > then a
>> >> >> > > Given this, we can get the desired behavior of not having the 
>> >> >> > > host
>> >> >> > > wakeup
>> >> >> > > due to periodic RAs if the wakeup filter blocks (doesn't wake 
>> >> >> > > up)
>> >> >> > > from a
>> >> >> > > RA.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 20 Sep 2006 16:17:22 -0400

I think Pars' point is not restricted to L2 mechanisms, though. No
matter what layer has to wake up a dormant host, bandwidth will be
consumed at multiple base stations to achieve this?

Bert

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]] 
> Sent: Wednesday, September 20, 2006 3:03 PM
> To: Pars MUTAF
> Cc: Erik Nordmark; [email-masked]
> >> There is an assumption here that the "L2 paging system" is 
> run off the 
> >> AR.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 20 Sep 2006 13:29:50 -0700

Right, but that's not my point.

My point is that it's possible to concieve of link specifric mechanisms that 
make filtering work.

Furthermore, this is all hypothetical. The other SDOs are going to do it 
however they want to anyway, and they, ultimately, are the ones who control 
how paging works. If they think unsolicited RAs are going to screw up their 
paging, they'll write it into their specs that unsolicited RAs aren't sent, 
regardless of what IETF does. IETT really can't make a big case about how 
that is going to present a serious problem, as was done for addressing or 
security during 3G development

There's really nothing we can do at the IP layer except modify how and 
whether unsolicited RAs are sent. And every time the topic comes up, people 
in IETF push back on it for various reasons. So let's just not waste any 
more bandwidth on discussing it.

            jak

----- Original Message ----- 
From: "Manfredi, Albert E" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 20, 2006 1:17 PM
Subject: RE: Proposal to change aspects of Neighbor Discovery

Bert

---

From: Pars MUTAF <[email-masked]>
Date: Wed, 20 Sep 2006 22:34:23 +0200

Selon James Kempf <[email-masked]>:

> originally went into dormant mode to notify other BSes to page.

Such a protocol doesn't exist today.
You have transformed the BS into a paging agent, in fact.
This is very new to this discussion (and it's not my role to
comment on it).

> Etc. That

I'm not sure if this part of your mail is for me.
You were suggesting IETF to recommend RA filtering by the BSs.

pars

---

From: Pars MUTAF <[email-masked]>
Date: Wed, 20 Sep 2006 22:37:34 +0200

> consumed at multiple base stations to achieve this?

Yes that's right. Thanks!
pars