Subject: RE: [16ng] Assumption of the Acess Router knows all on-link addresses

From: "Johnston, Dj" <[email-masked]>
Date: Tue, 25 Jul 2006 11:45:29 -0700

The generic link state notification standard in 802 is 802.21. It's just
gone through its first letter ballot.

DJ

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pars MUTAF
Sent: Tuesday, July 25, 2006 11:24 AM
To: Erik Nordmark
Cc: [email-masked]; [email-masked]
Subject: Re: [16ng] Assumption of the Acess Router knows all on-link
addresses

Hi,

Selon Erik Nordmark <[email-masked]>:

> Syam Madanapalli wrote:
> > Hi,
> >
> >> From the 16ng minutes:
> >
> >    Dave Thaler: On IP*CS, the assumption that the router knows all
on-link
> >    addresses based on DAD does not hold in the IPv6
architecture/protocol.
> >    There are at least 4 reasons, probably more, why this is a faulty
> >     assumption.
> >
> >
> > The current WiMAX solution is based on this assumption, so will you
please
> > provide reasons why this assumption is faulty?
> >
> > Learning addresses in use using DAD is one mechanism. The AR can
also
> > learn from MLD and may be from 802.16 MAC connection establishment
etc.
> > And in case the AR does not know about the address, an MS may not be
> > able to
> > communicate using that address.
>
> The DAD and MLD approaches to learning might not be completely
reliable,
> especially if we are concerned about the AR crashing and rebooting.

We should be concerned IMO. It will happen sooner or later. And the
consequences would be really serious if everybody becomes unreachable.
In addition, the probability of crash (or temporary power cut etc.)
is not avoidable in some countries. These contries will prefer
IP because it is the cheapest, easiest solution (I guess).

Another motivation is disaster (disaster->powercut->reboot).

IP can easily recover from loss of state (normally). It was designed for
this (no?).

>
> But learning the IPv6 address(es) of the MS from 802.16 signaling
(such
> as the connection establishment) seems to be a reliable option. If the
> AR crashes one would assume that all the MAC connections would be
> dropped, which means the hosts would have to re-establish the MAC
> connections, hence the AR would find out about the IPv6 addresses
again.

I think there should be a notification that the MAC connection is not
available
(lost) and the host must re-establish it. Otherwise idle hosts that
expect
incoming sessions (using e.g. MIPv6) would become unreachable without
knowing
it.

Does 802.16 have such notification signaling?

If not, there are two choices IMHO:

1. Using standard neighbor discovery. Upon incoming session, the access
router
would broadcast a neighbor solicitation over the subnet. The destination
host
would re-establish its MAC connection and receive the packet. Is this
possible
over 802.16? If we can broadcast router advertisements, why we can't
broadcast
a neighbor solication?

2. If the AR needs all MAC connections and all IP addresses in the
subnet
at the same time (for some reason that I don't understand), then
it can broadcast an "alert: MAC connections are lost!" message. Upon
receipt of
this message, every host would re-establish its MAC connection
proactively.

The first one is of course better (more resource efficient in terms of
bandwidth, energy and access router CPU). It is on demand.

>
> But we need to make sure that the above works when the host is using
> multiple IPv6 addresses on the 802.16 network interface. Would the
host
> have a separate MAC connection for each IPv6 address? Or is there a
way
> for the host to add an IPv6 address to an existing MAC connection?
> (It seems like those capabilties would be required even without the
> learning on the AR, since the AR would need to know which IPv6 address
> should be sent to which CID AFAICT.)

Thanks,
pars

>
>     Erik
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng