Subject: [6lowpan] draft-ietf-6lowpan-nd-14 submitted

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 26 Oct 2010 15:51:32 -0700

Hello All,

ND-14 version has been submitted after addressing the comments from working
group LC.

We expect to have one more update with editorial changes right after IETF.

Major changes from draft version ND-13 to ND-14 are:

     o Introduced the new DAR and DAC ICMPv6 message types for multihop

       DAD to avoid relying on the Length=4 checks for the ARO.  This

       simplifies implementing the hop limit check.

      o Clarified the hop limit values for the multihop DAD messages by

      introducing the MULTIHOP_HOPLIMIT constant set to 64.

      o Clarified when a host should de-register from a router.

      o Added a section on next-hop determination for routers.

      o Removed the infinite lifetime from 6CO.

      o Increased MIN_CONTEXT_CHANGE_DELAY to 300 seconds.

      O Added a guideline section for feature deployment/implementation

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-14.txt

-        Zach, Erik and Samita

---

From: "Anders Brandt" <[email-masked]>
Date: Wed, 27 Oct 2010 14:56:42 +0200

Hi 

> ND-14 version has been submitted after addressing the comments from
working group LC. 

Having just managed to get through -13 I have a rather basic question:
 
Is the NS+ARO message sent with multicast when I do registration the
first time?
In that case, what happens if this message reaches 50 different 6LRs
within direct range?
I suppose something prevents me from getting flooding?
 
Thanks,
  Anders

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Oct 2010 15:18:28 +0200

On Oct 27, 2010, at 14:56, Anders Brandt wrote:

> Is the NS+ARO message sent with multicast when I do registration the first time?

One of the problems with specifying 6LoWPAN-ND as a delta to 4861 is that it more than doubles the effective size of the spec (6LoWPAN-ND is 59 pages, 4861 is 97 pages).  4861 says:

4.3.  Neighbor Solicitation Message Format

... Neighbor Solicitations are multicast when the node needs
   to resolve an address and unicast when the node seeks to verify the
   reachability of a neighbor.

Well, we don't need to resolve an address, so it should be unicast.

I think the general rule is:

-- Hosts only ever multicast RS (link-local, which is just radio-range for Route-Over!)
-- Routers MAY multicast RAs, but generally unicast them
-- NS and NA (as well as DAR/DAC) are never multicast.

I think it couldn't hurt to say this succinctly somewhere.  
But the answer to your specific question is in there:

5.1.  Forbidden Actions

   A host would never multicast a Neighbor Solicitation message.

5.2.  Interface Initialization

   ...nobody multicasts Neighbor Solicitations in this type of network

See also section 3:
   The most important part of the optimizations is the evolved host-to-
   router interaction that allows for sleeping nodes and avoids using
   multicast Neighbor Discovery messages except for the case of a host
   finding an initial set of default routers, and redoing such
   determination when that set of routers have become unreachable.

But then there is some weird text in 6.5.5:

   Optionally Routers can use multicast Neighbor Solicitations as in
   [RFC4861] to resolve each others link-layer addresses.  Thus Routers
   MAY multicast Neighbor Solicitations for other routers, for example
   as a result of receiving some routing protocol update.  Routers MUST
   respond to multicast Neighbor Solicitations.  This implies that
   Routers MUST join the Solicited-node multicast addresses as specified
   in [RFC4861].

Rationale is not given and unknown to me; I don't think one should implement either of these MUSTs.

Gruesse, Carsten

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 28 Oct 2010 10:34:04 +0200

Carsten,

first time?

> Well, we don't need to resolve an address, so it should be unicast.

This is under the assumption that I know where to register the very
first time.
Is it obvious that I know that? (how?)

Thanks,
  Anders

> -----Original Message-----
> From: Carsten Bormann [mailto:[email-masked]] 
> Sent: Wednesday, October 27, 2010 15:18
> To: Anders Brandt
> Cc: [email-masked]
> Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time
> 
> One of the problems with specifying 6LoWPAN-ND as a delta to 
> 4861 is that it more than doubles the effective size of the 
> spec (6LoWPAN-ND is 59 pages, 4861 is 97 pages).  4861 says:
> 

working group LC. 
first time?
within direct range?

---

From: Zach Shelby <[email-masked]>
Date: Thu, 28 Oct 2010 11:43:24 +0300

Hi Anders,

> Is it obvious that I know that? (how?)

You discover the possible routers by performing an RS/RA exchange. The RS is typically sent to the IPv6 all-routers multicast address (see Section 5.3). However, if e.g. your L2 technology already gives you a hint about where a routers is (e.g. the coordinator), the RS could then be sent unicast. I am not sure if that is the case with z-wave. 

After this you perform NS+ARO registration unicast with one or more routers (see Section 5.5). 

Also see the example host bootstrap sequence in Section 10.2. 

Hope that helps,
Zach   

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 28 Oct 2010 10:53:33 +0200

OK, thanks.

> You discover the possible routers by performing an RS/RA 
> exchange. The RS is typically sent to the IPv6 all-routers 
> multicast address (see Section 5.3).

within direct range?
>>I suppose something prevents me from getting flooding?

IOW: Do I have do some random arbitration of Router Advertisements in
response to
multicasted Router Solicitations in a lowPan?

;-)

> From: Zach Shelby [mailto:[email-masked]] 
> Sent: Thursday, October 28, 2010 10:43
> To: Anders Brandt
> Cc: [email-masked] 6lowpan
> You discover the possible routers by performing an RS/RA 
> exchange. The RS is typically sent to the IPv6 all-routers 
> multicast address (see Section 5.3). However, if e.g. your L2 
> technology already gives you a hint about where a routers is 
> (e.g. the coordinator), the RS could then be sent unicast. I 
> am not sure if that is the case with z-wave. 
>

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Oct 2010 15:14:09 -0700

> multicasted Router Solicitations in a lowPan?

RFC 4861 specifies some random delay for the RAs. If I don't misremember 
it is random between zero and .5 seconds.

    Erik

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Fri, 29 Oct 2010 07:09:46 +0200

Hi,

I have expressed a similar concern in the past.
Find below the correspondence.

Best regards,
Yoav

-------------------------
Start of correspondence
-------------------------
Thanks Colin,

Your points below indeed cover my concerns.

Regards,
Yoav

From: Colin O'Flynn [mailto:[email-masked]]
Sent: Sunday, September 26, 2010 6:00 PM
To: 'Yoav Ben-Yehezkel'; [email-masked]
Cc: '6lowpan'
Subject: RE: [6lowpan] congestion of responses to multicast RS query from
an ND host

Hi Yoav,

This depends greatly on the L2 characteristics. As the RA is sent unicast
you could rely on L2 delivery, for example 802.15.4 ACKs.

For the 6lowpan-ND you don't need to receive every reply anyway though.
You just need one router that connects to the prefix you want, so in a
dense network you may have more collisions, but you should also have
enough successes that it doesn't matter.

Note that in 6lowpan-nd-13 MAX_RA_DELAY_TIME is redefined to 2 seconds by
default, which in terms of most link layers a very long time!

I think it's best to leave the random delay granularity as define in
RFC4861: something implementation defined. There is an unknown processing
delay between receiving the RS and internally generating/queuing the RA.
Thus even if you use a random granularity that matches the L2 packet
length, you could still have collisions. And if two nodes have both sent a
RA this again all goes out the window.

And I don't think anything would stop an extension of 6lowpan-ND being
added in the future using for example something like the trickle timer for
sending RA's, where if nodes see a lot of other routers advertising it
doesn't send its own RA. Or adjusting power of sending RS to solicit fewer
responses, etc. But I think these should remain optimizations that can be
explored only if required in dense networks, and keep 6lowpan-nd as simple
as possible.

Regards,

  -Colin

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yoav Ben-Yehezkel
Sent: September 26, 2010 5:32 PM
To: [email-masked]
Cc: 6lowpan
Subject: Re: [6lowpan] congestion of responses to multicast RS query from
an ND host

Thanks Robert,

I am guessing you are referring to the MAX_RA_DELAY_TIME  .5 seconds?

The problem I am thinking about goes a little beyond this randomization.

The way I see it, in LLNs hidden nodes are a common case, so if two
responding routers are not within direct connectivity, their packets will
collide if randomization resolution is too small. Unless the randomization
resolution is not in the order of magnitude of L2 frame transmissions
(including overheads such as preambles, backoffs, etc.) their packets are
very likely to collide.

This is why I am concerned with the value of 0.5 seconds being a little
small, and also wonder whether defining the resolution of the
randomization is important for 6LoWPAN-ND.

Trying to illustrate below.

Consider the following topology:

R1 --> H <-- R2

        +----+
Query:  | RS |
        +----+

               +--------+
R1 Resp:       |   RA1   |
               +--------+

                 +---------+
R2 Resp:         |   RA2   |
                 +---------+

        ---------------------------------->t

Above you see the responses collide, even though R1 and R2 randomized a
different value, because their L2 could not separate their transmissions
(as they cannot hear each other).

Had the randomization was using resolution at least the size of the
response packet and R1 and R2 randomized two different values, the
collision would have been avoided.

Of course in realistic large and dense networks, you're likely to see more
than two routers respond, which may escalate the problem.

I hope this better clarifies my concern.

Thanks,
Yoav

From: Robert Cragie [mailto:[email-masked]]
Sent: Sunday, September 26, 2010 4:45 PM
To: Yoav Ben-Yehezkel
Cc: 6lowpan
Subject: Re: [6lowpan] congestion of responses to multicast RS query from
an ND host

Hi Yoav,

There is already a mechanism specified in rfc4861 to randomize the
transmission of RAs - see section 6.2.6. This would apply to 6lowpan-nd as
well. The downside of this approach is the lengthening of the whole RS/RA
procedure.

Robert
Robert Cragie (Pacific Gas & Electric)
Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

On 26/09/2010 1:32 PM, Yoav Ben-Yehezkel wrote:
Hi,

I have a question on 6LoWPAN-ND. I tried looking for this issue in the
mailing list, but couldn't find anything on this.

Does the WG see a need for some kind of regulation of RA responses to host
multicast of a RS query in 6LoWPAN-ND? Unless regulated, in a large and
dense networks, this could cause excessive traffic for a meaningful period
of time.

Best regards,
Yoav

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Erik Nordmark
Sent: Friday, October 29, 2010 12:14 AM
To: Anders Brandt
Cc: [email-masked]
Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time

    Erik
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 29 Oct 2010 08:36:11 +0200

Yoav, Erik,

Thanks!
This makes sense.

Guess I have to skim 4861 again :-!

- Anders 

> From: Yoav Ben-Yehezkel [mailto:[email-masked]] 
> Sent: Friday, October 29, 2010 07:10
> To: Erik Nordmark; Anders Brandt
> Cc: [email-masked]
> Subject: [!! SPAM] RE: [6lowpan] ND: Sending NS+ARO message 
> for the first time
> 
> Hi,
> 
> Subject: RE: [6lowpan] congestion of responses to multicast 
> RS query from an ND host
> 
> Hi Yoav,
> 
> This depends greatly on the L2 characteristics. As the RA is 
> sent unicast you could rely on L2 delivery, for example 802.15.4 ACKs.
> 
> You just need one router that connects to the prefix you 
> want, so in a dense network you may have more collisions, but 
> you should also have enough successes that it doesn't matter.
> 
> Note that in 6lowpan-nd-13 MAX_RA_DELAY_TIME is redefined to 
> 2 seconds by default, which in terms of most link layers a 
> very long time!
> 
> RFC4861: something implementation defined. There is an 
> unknown processing delay between receiving the RS and 
> internally generating/queuing the RA.
> Thus even if you use a random granularity that matches the L2 
> packet length, you could still have collisions. And if two 
> nodes have both sent a RA this again all goes out the window.
> 
> And I don't think anything would stop an extension of 
> 6lowpan-ND being added in the future using for example 
> something like the trickle timer for sending RA's, where if 
> nodes see a lot of other routers advertising it doesn't send 
> its own RA. Or adjusting power of sending RS to solicit fewer 
> responses, etc. But I think these should remain optimizations 
> that can be explored only if required in dense networks, and 
> keep 6lowpan-nd as simple as possible.
> 
> Regards,
> 
>   -Colin
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Yoav Ben-Yehezkel
> Subject: Re: [6lowpan] congestion of responses to multicast 
> RS query from an ND host
> 
> Thanks Robert,
> 
> The way I see it, in LLNs hidden nodes are a common case, so 
> if two responding routers are not within direct connectivity, 
> their packets will collide if randomization resolution is too 
> small. Unless the randomization resolution is not in the 
> order of magnitude of L2 frame transmissions (including 
> overheads such as preambles, backoffs, etc.) their packets 
> are very likely to collide.
> 
> This is why I am concerned with the value of 0.5 seconds 
> being a little small, and also wonder whether defining the 
> resolution of the randomization is important for 6LoWPAN-ND.
> 
> Above you see the responses collide, even though R1 and R2 
> randomized a different value, because their L2 could not 
> separate their transmissions (as they cannot hear each other).
> 
> Had the randomization was using resolution at least the size 
> of the response packet and R1 and R2 randomized two different 
> values, the collision would have been avoided.
> 
> Of course in realistic large and dense networks, you're 
> likely to see more than two routers respond, which may 
> escalate the problem.
> 
> Subject: Re: [6lowpan] congestion of responses to multicast 
> RS query from an ND host
> 
> Hi Yoav,
> 
> There is already a mechanism specified in rfc4861 to 
> randomize the transmission of RAs - see section 6.2.6. This 
> would apply to 6lowpan-nd as well. The downside of this 
> approach is the lengthening of the whole RS/RA procedure.
> 
> Robert
> I have a question on 6LoWPAN-ND. I tried looking for this 
> issue in the mailing list, but couldn't find anything on this.
> 
> Does the WG see a need for some kind of regulation of RA 
> responses to host multicast of a RS query in 6LoWPAN-ND? 
> Unless regulated, in a large and dense networks, this could 
> cause excessive traffic for a meaningful period of time.
> 
> Best regards,
> Yoav
> 
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Erik Nordmark
> >> You discover the possible routers by performing an RS/RA exchange. 
> >> The RS is typically sent to the IPv6 all-routers multicast address 
> >> (see Section 5.3).
> >
> > response to multicasted Router Solicitations in a lowPan?
> 
> RFC 4861 specifies some random delay for the RAs. If I don't 
> misremember it is random between zero and .5 seconds.
> 
>     Erik