[6lowpan] "Advertize on Behalf" flag in ARO

[Mukul Goyal <[e-mail]>]

Hi all

Recently Anders pointed out the need for the "Advertize on Behalf" flag in an Address Registration Option (ARO).

We would not have needed this flag if only a host could send a unicast NS containing an ARO. However, the way I read Section 6.5.5 in nd-15, a 6lowpan router (6LR) can also send a unicast NS to another 6lowpan router. This means that a registered neighbor cache entry (NCE) in a 6LR could refer to either a host or another 6LR. So, how does a 6LR know that a registered NCE belongs to an attached host and it should advertize reachability to this host in the routing protocol, such as RPL, it is running?

The proposed flag will solve this problem. A host would set "Advertize on behalf" flag when it sends an ARO inside a unicast NS message, whereas a 6LR wont. 

I was wondering if ND authors could comment on this.

Thanks
Mukul


----- Original Message -----
From: "Mukul Goyal" <[e-mail]>
To: "Anders Brandt" <[e-mail]>
Cc: "6lowpan" <[e-mail]>
Sent: Tuesday, March 1, 2011 1:03:43 AM
Subject: Re: [6lowpan] -nd-15: Battery host support seems to be incomplete

Hi Anders

>If an originating node (keyfob or remote control) has lost all its
>working routes to a FLN, it must re-discover a source route to the FLN.
>But the FLN is sleeping.
>I would like a flag in the ARO: "advertise on behalf".
>If set, a default router may use the neighbor information to respond
>to discovery requests. The actual response format obviously depends
>on the actual routing protocol. RPL-P2P is just my actual example.
>Thus, how the default router uses the information is out of scope of
>the ND spec.

A very good point.

Normally, a 6lowpan host would use the ARO in NS/NA messages to register its address with one or more 6LRs. But, section 6.5.5 in nd-15 draft allows two 6LRs to learn each other's link layer addresses using the ARO mechanism. So, it seems that a registered NCE in a 6LR does not necessarily refer to a 6lowpan host and this 6LR, if it is running RPL, can not advertize this NCE address in its DAO or respond to RPL-P2P route discovery messages listing this NCE address as the target.

The ARO flag you mentioned will solve this problem. The 6lowpan hosts would set this flag in the AROs they send, whereas the 6LRs wont.

Thanks
Mukul

----- Original Message -----
From: "Anders Brandt" <[e-mail]>
To: [e-mail], "6lowpan" <[e-mail]>
Sent: Friday, February 25, 2011 4:42:12 AM
Subject: [6lowpan] -nd-15: Battery host support seems to be incomplete

Having read the doc carefully, I have a comment:

Section 5.8 addresses sleeping nodes.
While I agree with the text in this section it seems to me that the
description does not cover an important battery host category:

* The frequently listening node (FLN)

In a non-storing routing environment like the one we are specifying in
RPL-P2P in the ROLL WG, we have the option of issuing a reactive
discovery request when needing to get in touch with a host on short
notice. This is a major requirement for real users in home control and
building automation.

The abovementioned FLN is a battery powered
host that can be reached with semi-low latency. The typical use is
installations where wires would be hard to install without affecting
the architectural appearance. Examples include wireless window drape
controllers and electronic door locks.
802.15.4 and Z-Wave have different link-layer solutions for this but
the user experience is the same: Reaction within a second or less.

If an originating node (keyfob or remote control) has lost all its
working routes to a FLN, it must re-discover a source route to the FLN.
But the FLN is sleeping.
I would like a flag in the ARO: "advertise on behalf".
If set, a default router may use the neighbor information to respond
to discovery requests. The actual response format obviously depends
on the actual routing protocol. RPL-P2P is just my actual example.
Thus, how the default router uses the information is out of scope of
the ND spec.

Thanks,
  Anders

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Carsten Bormann
Sent: 17. februar 2011 16:58
To: 6lowpan
Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15

In September/October, we had the first WGLC on 6LoWPAN-ND, which
resulted in a number of detailed comments and two resulting
fine-tuning iterations of the draft.

draft-ietf-6lowpan-nd-15.txt has been out for two months now.
I understand it has taken part in several interops with multiple
implementations in this period; no issues came up.

We now start the Working Group Last Call on:

   http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15

The document is planned to be submitted by this Working Group to the
IESG for publication as a Standards-Track Document.

This is a two-week Working-Group Last-Call, ending on Thursday,
2011-03-03 at 2359 UTC.

Please review the changes to the document carefully once more, and
send your comments to the 6lowpan list.  Please also do indicate to
the list if you are all-OK with the document.

Gruesse, Carsten

_______________________________________________
6lowpan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan