Subject: Proposal to change aspects of Neighbor Discovery

From: Basavaraj Patil <[email-masked]>
Date: Mon, 07 Aug 2006 22:33:17 -0500

Hello,

The I-D: 
http://www.ietf.org/internet-drafts/draft-madanapalli-ipv6-periodic-rtr-advt
s-00.txt

proposes several changes to ND procedures and parameters.

Pls review and comment.

-Raj

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

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 8 Aug 2006 08:37:02 +0200 (CEST)

> proposes several changes to ND procedures and parameters.

Can you justify with power consumptions this proposal?
- In avarage how much energy do you need to send out a router solicitation 
message?
- In avarage how much energy do you need to maintain cellular conection 
while you are moving  - let say in an office?

Thanks,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Aug 2006 12:37:49 +0200

In your previous mail you wrote:

   The I-D: 
   draft-madanapalli-ipv6-periodic-rtr-advts-00.txt
   proposes several changes to ND procedures and parameters.
   
=> I strongly object not about the document itself but about its
principle because IMHO the link-layer should adapt, not the network layer.

Regards

[email-masked]

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 08 Aug 2006 14:18:52 +0200

Hello,

> principle because IMHO the link-layer should adapt, not the network layer.

I agree with you of course. But I was thinking of this issue, 
i.e. "how the link layer could adapt?"... It's not that easy.

Ideally, the dormant host's receiver circuit would be synchronized with 
the router's periodic RAs. The receiver circuit would be switched ON 
exactly when the RA arrives. But unfortunately, between the AR and the
host, there is an access point. The RA messages may be queued and
delayed at the access point (mixed up with other link layer frames).
This queuing delay may foil our dormant mode synchronization, and the
host may miss the RA messages :-(

This means that, perfect dormant mode synchronization can be more easily
achieved between the host and the access point (i.e. at the link layer).
In this case, however, the router's RAs will awaken the dormant host. 
(unless the L2 access point recognizes the RA packets and forwards them
at the right time, i.e. when the host's receiver is ON). 

Difficult issue.

Regards!
pars

---

From: "Syam Madanapalli" <[email-masked]>
Date: Tue, 8 Aug 2006 18:41:44 +0530

> principle because IMHO the link-layer should adapt, not the network layer.

Will you please clarify this?

If the network layer is sending some packets to the MN, how can the
link layer adapts in this case. The link layer either can drop/delay the
packets but purpose of sending an RAs to the hosts is lost.

The draft aims to reduce the dependency on the periodic RAs for the
mobile nodes, and hence the benifits of power and bandwidth saving.

Regards,
Syam

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Aug 2006 15:50:21 +0200

=> is it not clear enough? The problem is a link one so the solution
should be found in link device, not by changing IPv6.

=> IMHO the best idea to solve this class of issues is in
draft-ietf-dna-frd-01.txt (i.e., cache the last RA in the AP).

=> this is a problem of the link dormant mode facility so it should
*not* be solved by changing the network protocol.
   
Regards

---

From: "Syam Madanapalli" <[email-masked]>
Date: Tue, 8 Aug 2006 20:54:37 +0530

> should be found in link device, not by changing IPv6.

We are not solving a link layer problem here. It is network layer
problem. Problems are the short interval between periodic multicast
RAs and an MN currently does not solicit for RAs rather depends on
periodic RS to update the default router lifetime.

Nonetheless, you can argue that the current specified values for
these are good enough, which can be debated.

> draft-ietf-dna-frd-01.txt (i.e., cache the last RA in the AP).

I am one of the contributors for this draft; and I think FRD
is unrelated to our context. FRD expedite the RA acquisition
and does not deal with periodic multicast RAs.

> *not* be solved by changing the network protocol.

Link layers are already dealing with dormant mode, but network layer
may be disturbing this mode; so the draft is proposing few changes to
the network layer.

Thanks,
Syam

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 08 Aug 2006 17:54:20 +0200

Hello,

>From your draft:

   |Routers that implement the current recommendations would send the
   |periodic multicast router advertisements every 30 minutes, which can
   |be a significant problem in mobile/cellular network environments.

Why do you think 1 multicast RA per 30 minutes is a significant problem
for a host? Personally, I would think that 1 RA per 30 mins has a
negligible impact on energy cost. 30 minutes is really longtime IMHO. 

In addition this may be useful: 
Every 30 minutes (or less), my host will wake up, look around i.e.
receive the RA, thus make sure that the access router is *still* 
with me, and sleep again.

What's wrong with that?

Thanks
pars

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 08 Aug 2006 11:40:05 -0500

Inline:

> negligible impact on energy cost. 30 minutes is really longtime IMHO.

So if you consider for example a GGSN which may have several hundred
thousand hosts attached to it (GGSN the AR for all these hosts), having to
send a periodic RA to all these hosts is an expense with no real benefit.
In order to deliver the RA, the host has to be paged, radio resources
allocated and a traffic channel established to deliver the RA.

So what is the benefit of doing this operation? I agree that waking up a
host every 30 minutes to deliver an RA is not a significant drain on the
battery, but it is a factor. Additionally the fact that you have to deliver
the RA as a unicast message to a very large number of hosts is a waste of
the radio resources. Having a host establish a traffic channel only for the
purpose of receiving the periodic RA is sub-optimal. Why have a specific
interval (MAX) of 30 minutes only? Why not let it be 180 mins or 240 mins?
30 Mins is a value IMO which is as random as choosing 180, 240 or something
else.   

> with me, and sleep again.

If the host wants to make sure whenever it wakes up (not periodically just
for receiving an RA), it can just as well send a RTR solicitation to confirm
that it still is connected to the AR and be happy.

-Raj

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Aug 2006 18:42:59 +0200

We are not solving a link layer problem here.

=> I disagree as the dormant mode support is at the link layer.

   Problems are the short interval between periodic multicast
                    ^^^^^
   RAs and an MN currently does not solicit for RAs rather depends on
   periodic RS to update the default router lifetime.
   
=> the interval should not be considered as (too) short without the
dormant mode, so the issue is the dormant mode and not the interval.

=> this is exactly I'd like to argue!

   
=> the solution I propose is to cache the last RA in the AP and
to send it to the node when it wakes up. This is place to wake up
it for each RA when it sleeps. So this is not exactly FRD but
it is very close.

=> what I strongly suggest is to fix the dormant mode instead.   
   
Regards

PS for Basavaraj: direct messages are blocked by a stupid RBL issue,
have you an alternate e-mail address?

---

From: "James Kempf" <[email-masked]>
Date: Tue, 8 Aug 2006 11:13:40 -0700

Francis,

Are you also proposing that cellular-type protocols, such as 802.16 should 
disable their power saving narrowband signaling channels and be forced to 
work like 802.11?

            jak

---

From: Pars MUTAF <[email-masked]>
Date: Tue, 8 Aug 2006 20:45:08 +0200

> 30 Mins is a value IMO which is as random as choosing 180, 240 or something

OK. Flooding the network with RA messages unicasted to
several hundred thousands hosts (wow!) "at the same time"
is a significant problem.

But, I think you will agree, the problem is not the period
of RAs. 30 or 180 minutes later you will have the same
serious problem.

Your subnet is too large IMHO.

Regards,
pars

> >> proposes several changes to ND procedures and parameters.

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Aug 2006 23:02:33 +0200

=> no, I've said the space where to find a solution is the dormant
mode of the link layer, not the network layer. And about my idea
it is based on the fact the dormant node doesn't need to know what
happens until it wakes up.
BTW the narrowband signaling channel is nice but I am afraid it
works better in a connection oriented context.

Regards

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 08 Aug 2006 18:06:35 -0500

Francis,

I am not sure I understand your argument that the issue of sending periodic
RAs should be handled at the link-layer.
If the network layer is going to send the periodic RA, how do you expect the
link layer to deal with it? This would break the behavior.

> happens until it wakes up.

So if a host expects a periodic RA every 1800 secs, how do you solve the
problem? You are saying that the dormant node does not need to know anything
until it wakes up, right? But it is only the radio part of the host that is
dormant... So you need to deal with such a situation. Your proposal is very
vague and I am not sure if it applies.

-Raj

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 09 Aug 2006 00:00:46 -0700

Syam Madanapalli wrote:
eady dealing with dormant mode, but network layer
> may be disturbing this mode; so the draft is proposing few changes to

Syam,
Is the link layer on the Access point/Base station aware of when a host 
goes dormant and when it wakes up?

If it is, then it could apply the FRD technique when the host wakes up.

That would be more efficient than having all the hosts (that are not 
dormant) send periodic RS messages to get new RAs.

This assumes that the Access point/Base station can filter out packets 
that should cause the host to be paged/woken up, but that doesn't sound 
too hard.

    Erik

---

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 9 Aug 2006 19:14:53 +0530

Hello Erik,

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2006 12:31 PM
> To: Syam Madanapalli
> Cc: Francis Dupont; [email-masked]

I am not sure if this works.
Let us say the router lifetime is X seconds
and the host wakes up every Y seconds to retrieve
any packets from the AP/BS.
If Y > X then we are not solving the problem.
Even if we want use FRD, it still useful to increase
the router lifetime hence the periodic RA's interval.

This way I see the FRD is orthogonal to the changes
that we are proposing.

> dormant) send periodic RS messages to get new RAs.

There are no periodic RSs, host explicitly solicits if
it does not get an RA to update the parameters which are
expiring.

> that should cause the host to be paged/woken up, but that

It may not be a good idea to filter the RAs, a router
may be sending a multicast RA with new information.

The easiest way to solve the problem is to have a fix at
the root. I think it is easier to relax the some of the ND
parameters.

Thank you,
Syam

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 09 Aug 2006 09:58:32 -0500

Erik,

> goes dormant and when it wakes up?

The AP/Base station is not aware of the host state. This information is
maintained at other nodes in the access network.

-Raj

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Aug 2006 14:29:58 +0200

=> I don't understand how my argument was translated in this one too (:-).

=> my argument is that "to adapt the network layer to solve possible issues
from the periodic sending of RAs" is a bad idea and these issues should
be handled at the link-layer support for dormant nodes.
   
   > happens until it wakes up.
   
   But it is only the radio part of the host that is dormant...

=> this is clearly wrong: anything relying on the radio access should
be dormant too (*).

   Your proposal is very vague.

=> it is more a way where to look up for solutions.
   
Regards

PS (*): in fact IMHO timers should be classified into hard timers which
have to run in all cases and loose timers which should be delayed
during the dormant phase plus a grace period.

---

From: Pars Mutaf <[email-masked]>
Date: Thu, 10 Aug 2006 15:52:16 +0200

Hello, 

I'm still trying to understand the problem :-) 
Unless I missed an episode, the context is 
connection-oriented cellular networks under IP
(whatever that means) 

You say that the RA packets (unicasted) will wake up
90% of hosts in the subnet. Because roughly %90 of 
hosts are dormant, in general. 

I still believe that 30 minutes is longtime. Thus
the problem is not energy consumption perhaps 
(without justification).

But there is a problem if you link-layer page 
many many hosts simultaneously to deliver an 
RA. The paging channels may be saturated. From L2 
perspective, this would be similar to a situation 
where many many cellular users are called
simultaneously, resulting in call setup delays.
Personally, I suspect that this may be a much more
serious problem than energy consumption. 

But, firstly, your draft doesn't make it clear, 
and secondly, I couldn't see how your draft solved 
this problem. 

The real solution, imho, is to distribute the 
unicast RAs over time. For example, if there are 
5 hosts in the subnet and the RA period is 5 minutes, 
then

start:
Min1 - send the 1st RA
Min2 - send the 2nd RA
...
Min5 - send the 5th RA

and goto start.

This makes sense? Sorry if this is already specified
somewhere. 

Otherwise, you may want to filter the RAs at 
the paging agent.

pars

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 10 Aug 2006 10:29:59 -0500

Inline:

> the problem is not energy consumption perhaps

30 minutes is a long time. But if you have to go through the process of
waking a host to simply deliver an RA, which in most instances has no value
for the host, it is a waste of resources which include power, radio and
possibly causing congestion as well.
>From a power consumption perspective:
The host will wake up when paged and have to establish a traffic channel
which requires it to request allocation of resources from the network. There
is power that is consumed. Now if you argue that doing this every 30 minutes
is not a problem...... I cant really argue against that. But my point is
that why do you need to do this every 30 minutes in networks where you know
that the host is not going to change the AR and the RA has no value to the
host.

> serious problem than energy consumption.

True. Paging a large number of dormant hosts simultaneously will be a
serious issue for operators and people who do network planning don't like
such broadcasts. So I agree that congesting the paging channel may be a more
serious concern than power consumed by the host.
Additionally you have to note that in order to deliver the RA you have to
establish a traffic channel in most cases. Establishing this for a large
number of hosts every 30 minutes just to deliver an RA is an overhead and
waste of resources.

> and secondly, I couldn't see how your draft solved

Solution is fairly simple as stated in the I-D:
1. Transmission of periodic RAs should be optional - It is a configurable
parameter and the RA will indicate this to the host when it first attaches
or solicits an RA. 
2. Interval between periodic RAs should be flexible, i.e > 1800 secs. It is
up to the deployment to determine what is an optimal interval. 1800 secs is
just as random a value as 600 seconds or 5400 secs.

And if a host needs an RA for some reason, it can always solicit it from the
AR.

> 5 hosts in the subnet and the RA period is 5 minutes,

Staggered tranmission of RAs is one solution. There are others as well.

> Otherwise, you may want to filter the RAs at

Thanks for your comment.

-Raj

---

From: Pars MUTAF <[email-masked]>
Date: Thu, 10 Aug 2006 19:38:06 +0200

> And if a host needs an RA for some reason, it can always solicit it from the

This is the only point that needs clarification IMveryHO:

     Are the periodic RAs useless for those cellular hosts?

A periodic RA can periodically show me that the paging
subsystem still works, for example. I can sleep better.

This makes sense in your context? (I'm not a
connection-oriented specialist).

> Staggered tranmission of RAs is one solution. There are others as well.

I'm curious what are the others? (if/when you have time)

Thanks!
pars

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 10 Aug 2006 11:37:34 -0700

> If Y > X then we are not solving the problem.

I think you need to explain what would fail in that case.

In my simple view of the word, when the host wakes up the software is 
told (or notices by watching the clock tick) that it has been sleep for 
4 hours.
It then notices that the router lifetime expired one hour ago.
Instead of just removing the router from the default router list and 
doing nothing else it invokes DNA (which in its simplest form is to send 
a RS and wait for a RA). FRD can help shorten the time to get the RA 
assuming the AP/BS knows from L2 when the host wakes up.

Thus the host would just apply a bit of slack time after it has woken up 
before it starts timing out state (that would normally have timed out 
while the host was sleeping.)

This doesn't change any protocol; for IP on the access router it looks 
like the host disconnected and reconnected.

> the router lifetime hence the periodic RA's interval.

Sure. Increasing the periodic RA interval wouldn't hurt, especially if 
the host can detect when it might be connecting to a different AR (using 
DNA).

    Erik

---

From: "Syam Madanapalli" <[email-masked]>
Date: Fri, 11 Aug 2006 01:01:49 +0530

Hello Erik,

> I think you need to explain what would fail in that case.

Sure, DNA helps, I did not thought about it earlier.
But it would be better if the lifetime of the default router
is greater than the sleep time, which could avoid the
DNA operation.

> the host can detect when it might be connecting to a different AR (using

Yes.

Thanks,
Syam

---

From: "Syam Madanapalli" <[email-masked]>
Date: Fri, 11 Aug 2006 01:18:24 +0530

Hello Erik,

FRD may help snding an RA when the host wakes up and filters
all multicast RAs. This is problem for hosts that are active,
because FRD will not be able to send RAs to the active hosts.
Or the AP/BS can do the selective filtering for the hosts that are
sleeping?

And by the way, will the expiry of the default router lifetime tigger
the DNA? Is it specified in the DNA Spec?

Thanks,
Syam

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 10 Aug 2006 15:45:34 -0500

Hello Pars, 

Response inline:

>      Are the periodic RAs useless for those cellular hosts?

Ignoring cellular hosts for a moment, how are periodic RAs useful for any
host? RAs can be used as a means for detecting network attachment status or
to detect movement (prefix change). In the case of a stationary host (as an
example), periodic RAs really are of no benefit to the host (IMO).
In certain cellular networks (GPRS/UMTS) the host does not change the AR
(GGSN) that it is attached to frequently. In such cases there is no benefit
of receiving the periodic RA.

A cellular host such as a mobile phone does not need periodic Ras. However
any laptop can also be considered as a cellular host when it connects to the
cellular network. Hence you cannot generalize what a cellular host means. If
you agree that movement detection and network attachment are not of serious
concern in certain environments, what other reasons are there which makes
the reception of the periodic RA critical?

> subsystem still works, for example. I can sleep better.

You don't verify today at regular intervals if the paging subsystem works
and I am sure that is not causing any sleeplessness ;)

So why would you worry about whether the system works or not? This is not
required. Not at the IP layer at least.

-Raj

---

From: Pars Mutaf <[email-masked]>
Date: Fri, 11 Aug 2006 13:56:15 +0200

Hi Raj,

> the reception of the periodic RA critical?

I would see the periodic RAs as a heartbeat signaling. 
There may be other information as well, in the RA.

But I don't know what the cellular operator wants!
(I'm actually wondering if they know for sure what 
they want ;-)

> required. Not at the IP layer at least.

Again, I don't know what the cellular operator wants.
All I know is that IPv6 takes care of its hosts ;-) 

>From IP point of view, the following may make sense. In 
the context of this discussion, there are 3 different 
paths between a router and a host:

1. AR ---> MH when the mobile host is active
2. MH ---> AR when the mobile host is active
3. AR ---> MH when the mobile host is 'dormant'

The state of the 3th type (i.e. up or down) can 
only be checked using periodic RAs. Or, I missed
something.

My two cents!

pars

---

From: "James Kempf" <[email-masked]>
Date: Tue, 15 Aug 2006 10:41:59 -0700

I don't think the issue is so much the lifetime of the RA as the need to 
wake up a dormant mode host when an unsolcited RA is multicast. I assume a 
dormant mode host coming out of dormant mode will have some amount of work 
to do to get its IP traffic channel in shape. This will naturally include 
using DNA to solicit an RA, since the host may have moved to a different 
subnet while it was in dormant mode. Am I missing something?

            jak

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Aug 2006 17:25:43 -0700

> example), periodic RAs really are of no benefit to the host (IMO).

A design principle for many Internet protocols is known as "soft state".
I wonder if that might have something to do with the periodic RAs ;-)

If the hosts would keep the information received until it being 
explicitly invalidated we would probably end up with a more complex 
and/or more fragile approach to handle the stale state. Hence the soft 
state approach.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Aug 2006 17:24:14 -0700

> the DNA? Is it specified in the DNA Spec?

I don't think that is in the DNA specification.
DNA is triggered by L2 events notifications - 'link up'.

    Erik

---

From: "James Kempf" <[email-masked]>
Date: Thu, 31 Aug 2006 09:12:08 -0700

Erik,

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.

I suspect this was originally done to avoid packet storms when the lifetime 
expired. But that could be avoided by specifying that the host needs to pick 
a random time prior to the expiration time over some interval.

            jak

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

> If the hosts would keep the information received until it being explicitly 
> invalidated we would probably end up with a more complex and/or more 
> fragile approach to handle the stale state. Hence the soft state approach.
>
>    Erik
>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 31 Aug 2006 15:45:24 -0400

Having just gone through this entire thread, some questions.

1) Is there an issue with multicast RAs vs. unicast RAs? I.e., would
   it help if the RAs were unicast rather than multicast? (Or is there
   no true unicast in the networks we are talking about). My
   assumption is that use of IP multicast is not an issue here, since
   no one has suggested this.

2) What I'm clearing hearing is that it will be common to have devices
   in "dormant" mode for long periods of time, i.e., hours. The desire
   is that they not be bothered with RAs during that time (if that is
   the only only traffic they would be getting, i.e., no other packets
   are being sent their way). 

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.)

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.

How reliably will the periodic RAs  be delivered in the networks at
issue here? Are they essentially reliable link layers?

> table entry is not one of them.

The current wording in 2461 is a bit narrow, not really making it
clear that there may be other times when it is appropriate to send an
RS. IMO, a device that has been dormant a long time should be allowed
to send an RS. But this is very similar ground to what DNA is
covering. Maybe DNA should explicitely cover the case of nodes that
switch from dormant to active mode?

Note that when 2461 was written, we really didn't have the notion of
dormant nodes. So we probably do need to think about how to accomodate
them.

> transmit.

2461 takes the same view. RAs aren't used for reachability we have
ND/NUD for that. So I'm not sure why you raise this issue here (in the
context of RAs)

> 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.

See above.

> a random time prior to the expiration time over some interval.

No. The assumption is that long before the default router expires, you
receive fresh RAs. What is being proposed here is to break that
assumption, namely (effectively), to ignore (by not receiving) RAs
while in dormant mode. Right?

Thomas

---

From: "James Kempf" <[email-masked]>
Date: Thu, 31 Aug 2006 13:26:33 -0700

>   no one has suggested this.

I assume you mean "no true multicast" and not unicast.

No, the issue isn't with lack of multicast support, IFICT.

>   are being sent their way).

Yes, that's the basic problem. A subsidiary problem is the one I mentioned 
about lack of bidirectional connectivity. This doesn't occur in cellular 
networks, but it could occur in other networks. I don't know about 802.11, 
I've been told that it could happen there, but I haven't checked that 
assertion in detail.

>   allow deployments to use a higher value. (that is the

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, 
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).

> hours apart. Unless the RAs are delivered with a high degree of

Most simple and elegant. If the last hop is wired, it's about perfect.

> 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

---

From: Thomas Narten <[email-masked]>
Date: Thu, 31 Aug 2006 16:11:03 -0400

Basavaraj Patil <[email-masked]> writes:

> host?

They are part of the basic RS/RA reliability mechanism. Instead of
having hosts periodically poll routers, routers periodically send out
RAs. You need one or the other (or both).

You seem to be assuming that all RAs are sent reliably. If so, then I
agree that the above model is not really ideal. But pretty much none
of the basic IP protocols assume reliability at this level.

Is that really a safe assumption to be made in the types of networks
being discussed here?

Thomas

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 31 Aug 2006 17:17:04 -0700

James Kempf wrote:

> 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.
> 
> 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