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

From: Mukul Goyal <[email-masked]>
Date: Thu, 3 Mar 2011 07:07:41 -0600 (CST)

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" <[email-masked]>
To: "Anders Brandt" <[email-masked]>
Cc: "6lowpan" <[email-masked]>
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" <[email-masked]>
To: [email-masked], "6lowpan" <[email-masked]>
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: [email-masked] [mailto:[email-masked]] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Mar 2011 04:13:30 -0700

On 3/3/11 5:07 AM, Mukul Goyal wrote:
> 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 didn't see anybody else comment, so let me try.

I don't know what assumptions RPL makes in particular, but if we are 
talking about a general case of a routing protocol, I don't see why 
there would be a need to tell a difference between a host sending an ARO 
and a router (which might be initializing and haven't yet enabled 
routing and forwarding) sending an ARO.

In both cases I'd assume that the unicast address that is registered is 
something that should be reachable, hence it makes sense advertising 
reachability to that address.

If this isn't the case, then a routing protocol would typically find out 
about its neighboring routers IP addresses, and from that it can decide 
to treat those IP addresses differently than the addresses assigned to 
hosts.

    Erik

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 29 Mar 2011 14:55:48 +0200

Hello,

as far as I understand RPL reachability is indeed advertised to both 6LR/6LNs, the only distinction is that a 6LN (host) would operate as a RPL leaf node (as in section 8.5 of rpl-19). So a 6LR does not have to 'detect' first whether another node is 6LR or 6LN.

best regards,
Esko Dijk

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Tuesday 29 March 2011 13:14
To: Mukul Goyal
Cc: 6lowpan
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO

    Erik

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Mar 2011 15:14:34 +0200

On Mar 29, 2011, at 14:55, Dijk, Esko wrote:

> RPL reachability is indeed advertised to both 6LR/6LNs, the only distinction is that a 6LN (host) would operate as a RPL leaf node

Hosts don't take part in routing protocols, so I don't understand this sequence.
The only source of information about reachability and network configuration a host has is ND (and DHCP for some of the latter, if present).

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 29 Mar 2011 18:25:37 +0200

Hi Erik:

RPL does not have an assumption on this ND operation in particular nor
on 4861. But then, the interworking of ND and RPL is left to further
work.
I hope this work happens somewhere someday. In particular, RPL is
prepared to redistribute external routes and that could include host
routes learnt from registration.
But then, RPL, like the backbone router draft operation, needs the TID
that is now gone from ND, to recognize the update from the stale when
the LBR states are distributed and clean up.

Cheers;

Pascal
http://www.xtranormal.com/watch/7011357/

> Behalf Of Erik Nordmark
> Sent: Tuesday, March 29, 2011 1:14 PM
> To: Mukul Goyal
> Cc: 6lowpan
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?
> >
"Advertize
> > on behalf" flag when it sends an ARO inside a unicast NS message,
> > whereas a 6LR wont.
> >
talking
> about a general case of a routing protocol, I don't see why there
would be a
> need to tell a difference between a host sending an ARO and a router
(which
> might be initializing and haven't yet enabled routing and forwarding)
sending
> an ARO.
> If this isn't the case, then a routing protocol would typically find
out about its
> neighboring routers IP addresses, and from that it can decide to treat
those
> IP addresses differently than the addresses assigned to hosts.
> 
>     Erik

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Mar 2011 19:20:23 +0200

> But then, RPL, like the backbone router draft operation, needs the TID

Can you explain why RPL needs a sequence number here?

Gruesse, Carsten

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 29 Mar 2011 19:32:04 -0500 (CDT)

Hi Erik

Thanks for clarification. This seems like an issue that falls in the 'no man's land" betwen RPL and 6lowpan.

A router running RPL would not always know which of its registered neighbors are themselves RPL routers. This is because an RPL node must ignore any DIOs received from neighbors with higher (in numerical value) "rank". Also, a DAG parent may not receive    
a DAO from its child (In non-storing mode operation, it WON'T receive any DAO at all unless it is the DAG root and in storing mode, the child may decide not to send its DAO to this parent).

Now, we have 2 options:

1) Define an "Advertize on Behalf" flag in ARO as Anders proposed and have hosts set this flag when they send ARO inside a unicast NS to a 6LR. If the host later decides to become a 6LR, it can resend the ARO with this flag not set.

2) Lets write a "how to run RPL on a 6lowpan" document (as Pascal has suggested) that will specify how a received DIO/DAO from a neighbor can be used to mark that neighbor as a router in the registered neighbor cache.

Thanks
Mukul
 
----- Original Message -----
From: "Erik Nordmark" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "Anders Brandt" <[email-masked]>, "6lowpan" <[email-masked]>
Sent: Tuesday, March 29, 2011 6:13:30 AM
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO

    Erik

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 29 Mar 2011 19:39:44 -0500 (CDT)

Hi Esko

In RPL, a node can advertise reachability (in DAO messages) to its hosts and addresses in its sub-DAG. A node should (must?) not advertise reachability to any other addresses.

Also, a 6LN (host) need not know any thing about RPL at all. It can simply attach to a RPL router as a host. Any node that runs RPL is a router. An RPL leaf node is also a router.

Thanks
Mukul  

----- Original Message -----
From: "Esko Dijk" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>, "Mukul Goyal" <[email-masked]>
Cc: "6lowpan" <[email-masked]>
Sent: Tuesday, March 29, 2011 7:55:48 AM
Subject: RE: [6lowpan] "Advertize on Behalf" flag in ARO

Hello,

best regards,
Esko Dijk

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Tuesday 29 March 2011 13:14
To: Mukul Goyal
Cc: 6lowpan
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO

    Erik

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 29 Mar 2011 19:47:26 -0500 (CDT)

Hi Carsten

>Hosts don't take part in routing protocols

I agree absolutely.

>The only source of information about reachability and network configuration a host has is ND (and DHCP for some of the latter, if present).

I agree. That's why I think 6lowpan ND should provide a mechanism to clearly identify a registered neighbor as a 6lowpan host or a 6lowpan router.

Thanks
Mukul 

----- Original Message -----
From: "Carsten Bormann" <[email-masked]>
To: "Esko Dijk" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>, "Mukul Goyal" <[email-masked]>, "6lowpan" <[email-masked]>
Sent: Tuesday, March 29, 2011 8:14:34 AM
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO

Gruesse, Carsten

---

From: "Anders Brandt" <[email-masked]>
Date: Wed, 30 Mar 2011 08:00:19 +0200

(maybe not so surprising, )
I would like to support Mukul.
 
RPL is one routing protocol, but 6LoWPAN may run under any routing protocol - or none at all.

In all cases, a sleeping node can benefit from asking a neighbor router to provide connectivity to that node.
To me this definitely sounds like a feature that belongs to the 6LoWPAN ND toolbox.
 
Thanks,
  Anders

________________________________

Fra: [email-masked] på vegne af Mukul Goyal
Sendt: ti 29-03-2011 18:47
Til: Carsten Bormann
Cc: 6lowpan
Emne: Re: [6lowpan] "Advertize on Behalf" flag in ARO

Hi Carsten

I agree absolutely.

Thanks
Mukul

----- Original Message -----
From: "Carsten Bormann" <[email-masked]>
To: "Esko Dijk" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>, "Mukul Goyal" <[email-masked]>, "6lowpan" <[email-masked]>
Sent: Tuesday, March 29, 2011 8:14:34 AM
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO

Gruesse, Carsten

---

From: "Anders Brandt" <[email-masked]>
Date: Wed, 30 Mar 2011 08:08:19 +0200

OK, so now I can send this "Advertize on Behalf" flag.
 
As mentioned yesterday, there is a distinction between Frequently Listening (a.k.a duty cycled nodes) and
what I call call-back nodes, i.e. nodes that depend on a router holding a mailbox for that node.
Whether that mailbox feature is provided by any router, a few specialiezed routers or the border router
is a network implementation decision.
But how is that information conveyed to the sleeping node?
 
In the RA? 
By asking the default router with some new message?
Whereever this mailbox feature is offered in the network, this is where I will be sending 
my "Advertize on Behalf" flag if I am a call-back node.
 
Forgive me if this is obvious. I think I am getting close to a "detail overload" ;-)
 
Thanks,
  Anders

Hi Carsten

I agree absolutely.

Thanks
Mukul

----- Original Message -----
From: "Carsten Bormann" <[email-masked]>
To: "Esko Dijk" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>, "Mukul Goyal" <[email-masked]>, "6lowpan" <[email-masked]>
Sent: Tuesday, March 29, 2011 8:14:34 AM
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO

Gruesse, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 30 Mar 2011 10:22:00 +0200

Thanks Mukul, 

I realized indeed that the case I had in mind is a special case, in which all nodes are routers. (e.g. as in ad-hoc networks with uniform stack on all nodes)

best regards
Esko

-----Original Message-----
From: Mukul Goyal [mailto:[email-masked]] 
Sent: Wednesday 30 March 2011 2:40
To: Dijk, Esko
Cc: 6lowpan; Erik Nordmark
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO

Hi Esko

Thanks
Mukul  

----- Original Message -----
From: "Esko Dijk" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>, "Mukul Goyal" <[email-masked]>
Cc: "6lowpan" <[email-masked]>
Sent: Tuesday, March 29, 2011 7:55:48 AM
Subject: RE: [6lowpan] "Advertize on Behalf" flag in ARO

Hello,

best regards,
Esko Dijk

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Tuesday 29 March 2011 13:14
To: Mukul Goyal
Cc: 6lowpan
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 30 Mar 2011 10:30:09 +0200

Hi Carsten:

RPL recognizes a movement when a DAO information has a stale
DAOSequence. The DAOSequence is an information that the owner of the
advertised target increments.
If we define an interaction whereby we redistribute ND-15 into RPL, then
(probably) the RPL router will inject a host route on behalf of the
host.
When the RPL router injects such a route and then maintains that route,
it still has has to provide an idea of the freshness of the information
that it is injecting in a DAOSequence.
When the host moves to an alternate router, it would have to provide
something so that the new router sets an updated DAOSequence that the
routing update percolates up the DODAG.
IOW, without a TID, a host cannot efficiently move from a router to the
next.

People can find more on TID interactions with RPL and ND in
http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-02 .
I'll see what I do with that draft; probably propose it to ROLL.

Pascal

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Tuesday, March 29, 2011 7:20 PM
> To: Pascal Thubert (pthubert)
> Cc: Erik Nordmark; Mukul Goyal; 6lowpan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 30 Mar 2011 10:50:20 +0200

Hi Anders and Mukul:

For RPL, we probably need more than one bit. RPL needs a TID, and an instance ID will help quite a bit in some cases if the app is aware of it.

Other routing protocols might benefit from other information to improve their operation.

Once we figure what the abstract information is, then we'll probably have to define a way to carry that information from the host to the router.

Might be ND, but other people have already started a packetBB / RPL interwork, so at this point I do not know.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anders Brandt
Sent: Wednesday, March 30, 2011 8:00 AM
To: Mukul Goyal; Carsten Bormann
Cc: 6lowpan
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO

Thanks,

  Anders

Hi Carsten

I agree absolutely.

Thanks
Mukul

----- Original Message -----
From: "Carsten Bormann" <[email-masked]>
To: "Esko Dijk" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>, "Mukul Goyal" <[email-masked]>, "6lowpan" <[email-masked]>
Sent: Tuesday, March 29, 2011 8:14:34 AM
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO

Gruesse, Carsten

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 30 Mar 2011 08:53:51 -0400

> Date: Wed, 30 Mar 2011 08:08:19 +0200
> As mentioned yesterday, there is a distinction between Frequently
> Listening (a.k.a duty cycled nodes) and what I call call-back nodes,
> i.e. nodes that depend on a router holding a mailbox for that node.
> Whether that mailbox feature is provided by any router, a few
> specialiezed routers or the border router is a network implementation
> decision.

As you point out, there are lots of ways to do this.  No one
solution is going to work for everyone.  At one extreme this
can all be handled by the link layer.  It shouldn't matter
to the higher layers if a message is polled for, transmitted
according to some known schedule, or unicast immediately.

At the other end of the spectrum, it can all be handled at
the application layer, with the application polling to some
centralized mailbox which may be anywhere.

The middle ground, where ND and/or routing get involved,
seems dangerous to me, exactly because so many different
approaches are possible.
                                  -Richard Kelsey

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 30 Mar 2011 15:03:25 +0200

> seems dangerous to me, exactly because so many different

+1

Both extremes were represented at the mic yesterday and there were certainly concerns with the middle ground approach.  In some cases, I think it will be a combination of both extremes.  The link layer knows best how to contact a duty-cycled node, while the application layer specifies the policy of what to do with packets that experience long communication latencies.  Having another mechanism in the middle would only add complexity in having to combine the particular link layer properties and application layer policies.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 31 Mar 2011 10:28:55 +0200

> > As you point out, there are lots of ways to do this.  No one
solution
> > is going to work for everyone.  At one extreme this can all be
handled
> > by the link layer.  It shouldn't matter to the higher layers if a
> > message is polled for, transmitted according to some known schedule,
> > or unicast immediately.
> >
> > At the other end of the spectrum, it can all be handled at the
> > application layer, with the application polling to some centralized
> > mailbox which may be anywhere.
> >
> > The middle ground, where ND and/or routing get involved, seems
> > dangerous to me, exactly because so many different approaches are
> > possible.
> 
> +1
> 
> Both extremes were represented at the mic yesterday and there were
> certainly concerns with the middle ground approach.  In some cases, I
think it
> will be a combination of both extremes.  The link layer knows best how
to
> contact a duty-cycled node, while the application layer specifies the
policy of
> what to do with packets that experience long communication latencies.
> Having another mechanism in the middle would only add complexity in
> having to combine the particular link layer properties and application
layer
> policies.
+1

Considering only the one-hop problem of sleeping nodes seems to be the
recipe for uncontrolled congestion at - or close to - the sink. What we
really need is a congestion control operation that protects the network,
and that cannot be a one-hop operation.
Sleeping hops introduce latencies that need to be absorbed in outgoing
queues; something constrained devices do not exactly have aplenty.
Selective drops might help by intermediate nodes lack information for
doing that intelligently; in particular, dropping fragments actually
augments the load of the network.

ISA100.11a acknowledges that sleeping periods introduce latencies that
may be unusual in the classical internet, and mandates RFC 2988 for
calculating the retry timer-out interval (RTO). 
ISA100.11a supports ECN, and refers to RFC3168. ECN is always enabled:
it CANNOT be turned off. ECN is set by L2 over the LoWPAN and stamped
into the IPv6 header when HC is uncompressed.
ISA100.11a also tags the packets with a Discard Eligible indication -
mostly for buffered unidirectional publication. This indication is set
by the application for use of the L2 as part of congestion control.
For queued bidirectional communication (R/W, RMI) ISA100.11a is
consistent with the behavior described at the mic above (and Core). Acks
are app layer Acks over UDP, they may carry data, and they are sensitive
to ECN.

What this boils down to is:
- ISA100 has identified a need for congestion control in the LLN. The
congestion control has to be an interaction between the LLN and the
transport/app level. It is unclear how ECN can work with 6LoWPAN
fragments.
- Classical ECN that is designed in conjunction with TCP does not
address properly congestions due to sensor data publication over UDP.
There is a need for an additional mechanism that is not described in
6LoWPAN.

I hope that this can all be addressed in core, though I'm not fully sure
the charter allows that. 
 
Cheers,

Pascal

---

From: "Noriyuki SATO" <[email-masked]>
Date: Thu, 31 Mar 2011 21:13:02 +0900

+1 
A mailbox mechanism for the sleeping node described in this thread should be
treated in the link layer as Jonathan indicated. The IEEE802.15.4e treats
what low energy mode is enabled, how long duty cycle is etc. and also
current IEEE802.15.4 has mode of operation direct transmission and indirect
transmission. If another L2 protocol addresses sleeping nodes, it should
also address such kind of mechanism in the L2 layer.
But a buffer (aka queue) as implemented in a normal router may be
implemented also in 6LR or 6LBR. Pascal indicated about ECN but we can
implement RED and it can work also for UDP for an easy solution.
I'm not sure the CORE WG is appropriate place to discuss a congestion
control mechanism to solve the issue in LLN since I'm afraid that it should
be discussed some place in transport area.

---
OKI Electric Industry Co., Ltd.
Noriyuki Sato ([email-masked])
Tel +81-6-6260-0700
Fax +81-6-6260-0770

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Pascal Thubert (pthubert)
> Sent: Thursday, March 31, 2011 5:29 PM
> To: Jonathan Hui; Richard Kelsey
> Cc: [email-masked]; [email-masked]
> Subject: Re: [6lowpan] How to find the mailbox? (related to"Advertizeon
> Behalf")
>