Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]
Behcet Sarikaya <behcetsarikaya@yahoo.com> Tue, 26 April 2011 17:01 UTC
Return-Path: <behcetsarikaya@yahoo.com>
X-Original-To: 6lowpan@ietfa.amsl.com
Delivered-To: 6lowpan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AF6E076E for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 10:01:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.689
X-Spam-Level:
X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv6tk4NVZGs2 for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 10:01:11 -0700 (PDT)
Received: from nm26-vm1.bullet.mail.sp2.yahoo.com (nm26-vm1.bullet.mail.sp2.yahoo.com [98.139.91.231]) by ietfa.amsl.com (Postfix) with SMTP id 5E332E07BB for <6lowpan@ietf.org>; Tue, 26 Apr 2011 10:01:06 -0700 (PDT)
Received: from [98.139.91.67] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 26 Apr 2011 17:01:03 -0000
Received: from [98.139.91.27] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 26 Apr 2011 17:01:03 -0000
Received: from [127.0.0.1] by omp1027.mail.sp2.yahoo.com with NNFMP; 26 Apr 2011 17:01:03 -0000
X-Yahoo-Newman-Property: ymail-5
X-Yahoo-Newman-Id: 594967.77437.bm@omp1027.mail.sp2.yahoo.com
Received: (qmail 11117 invoked by uid 60001); 26 Apr 2011 17:01:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1303837263; bh=uNENozqii04nE6fk5ce0WYfvVW/lUbkj3fr3F++1LX0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=J3L1nXDgaimqDGtu1YebjuGDyAJOhnK5d/r7YAd7UoqcnaVJfKZJ0FB4IdwrLy/Wn8BYo59hmtimE9pWVAdnFsvYaUVWgAN7D+yQKlkV3xSag0ZK/f5mCuhciW14bidmzQ8ZSnThxg8V8a0N2Uk8gbfkIxeyNdSlCiHdSf0M5UI=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5/9rpqRaMGfIvam9/oY8Krg7HQqt/75rpxy93sM+ppScFdiUpO65u6IWaKUosTGtMlHPFtneifxN6HdV4De9XFOl7CwZBplKIVjxOKUo5XCn+RqI8yNbT6KJFYVUIERz3HLVxPvNNnEdoJUecWvihy4W9cN0Zji1/Pn6hmqV660=;
Message-ID: <205310.2728.qm@web111414.mail.gq1.yahoo.com>
X-YMail-OSG: eu0gA1cVM1kd5cGOYQGdGjTY9zgHtLGyCrWW31_WahnIteV fDD2yfOgbgEBosl..5_bErGvzRQFtsTzoMVTeDZwPNinx.oA6hp7wmXjIZBX qsIEgyLJy.SHB_Eg0bUeOSwg234oLlt381FCjfdFBI9q3NiU2VJhIbqLrGcr ll5tEZMao.kfT4MgymZ8m9ZOYh_yj9GcTo4PjyjPLKAIqHW0DOssVrpd1oWw ay.rtJiRjlShPZh2wp7lRYBT9lZ2Dh2DDjbQuSNFKjAnCY2fL6Fn1Qvqa.Ea XmqYHVJMzKezQ9sKffXJMkpxaHE5jcMD2qyvwRZRm7IvXhTYbb8GAKOmA2Kj J3ReUXYZK6AgLNqtxNHyI_w_A5MxLuaat7SQnNRbL0f1PuvcoXFWywg.3yID s8ldicAHoPnAq_w--
Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Tue, 26 Apr 2011 10:01:03 PDT
X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900
References: <OF05FC8EC8.E2C545F7-ONC1257878.002DC800-C1257878.002DE486@Schneider-Electric.com> <4DAF6B38.7000604@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D046502D9@XMB-AMS-107.cisco.com> <1303400445.1671.1576.camel@d430> <6A2A459175DABE4BB11DE2026AA50A5D0470FA00@XMB-AMS-107.cisco.com> <1303414920.1671.1849.camel@d430>
Date: Tue, 26 Apr 2011 10:01:03 -0700
From: Behcet Sarikaya <behcetsarikaya@yahoo.com>
To: Geoff Mulligan <geoff@proto6.com>
In-Reply-To: <1303414920.1671.1849.camel@d430>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya <sarikaya@ieee.org>
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Apr 2011 17:01:13 -0000
I also think that we must move on. We must move on and start looking into securing 6lowpan ND? Regards, Behcet > Pascal, > I couple of people supporting the TID is not group consensus. We have > had many presentations and discussions about multiple LBRs, backbone > LBRs and more and none have met with the support of the working group. > > In your opinions we are crashing, but I fail to see that this is the > opinion of the working group. > > If there are other in the working group that strongly advocate this TID > idea or the work on multiple and backbone LBRs then they need to speak > up now en masse or we must move on. > > geoff > > > On Thu, 2011-04-21 at 21:32 +0200, Pascal Thubert (pthubert) wrote: > > Geoff: > > > > There is twice as much support for restoring the TID than there is for not >doing it. > > Before we drop the TID, I'd like to see a proposal that allows a 6LoWPAN ND >subnet to scale with multiple LBRs, allows nodes to move from a router to the >next, and that does not need a TID. > > Otherwise, we are not speeding towards the wall, we're already crashing. > > > > Pascal > > http://www.xtranormal.com/watch/7011357/ > > > > > -----Original Message----- > > > From: Geoff Mulligan [mailto:geoff.ietf@mulligan.com] > > > Sent: Thursday, April 21, 2011 5:41 PM > > > To: Pascal Thubert (pthubert) > > > Cc: Erik Nordmark; nicolas.riou@schneider-electric.com; 6lowpan@ietf.org > > > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > > > ARO] > > > > > > Pascal, > > > We need to close on this discussion. > > > > > > Back in Hiroshima the Working Group decided that Backbone router stuff and > > > "address defense" across backbone routers was not going to be part of ND > > > draft. It appeared that the draft was getting way to complicated and the > > > Working Group decided to simplify things. > > > > > > I have not seen much support on the list for making these changes to >include > > > the TID in ND. > > > > > > We need to get this draft completed. If there is a large "unheard from" > > > support group for these changes, please speak up or we shall move forward > > > with the draft as it is. > > > > > > geoff > > > > > > > > > > > > > > > On Thu, 2011-04-21 at 09:27 +0200, Pascal Thubert (pthubert) wrote: > > > > Hi Erik > > > > > > > > The TID is not a strong coupling between the H2R and the R2R operations, > > > and it is not a coupling with a RPL version explicitly. > > > > It is an abstract information that if defined properly can be used by >many > > > forms or R2R interactions. > > > > As demonstrated by older versions of the ND spec (Backbone Router), RPL, > > > and MIP. > > > > > > > > 6LoWPAN ND cannot scale if the node needs to register to all LBRs. > > > 6LoWPAN ND does not define anymore any LBR interaction. > > > > IOW, 6LoPWAN ND lost the capability to scale when the backbone router > > > piece was removed from the draft. > > > > Which means that it lost its capability to apply in the domains I'm >looking at > > > (industrial and metering). > > > > > > > > With the TID, we know that we can restore scalability in the future, and >we > > > know how. I do not know of a plan B. > > > > > > > > Pascal > > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > > > > > > -----Original Message----- > > > > > From: Erik Nordmark [mailto:nordmark@acm.org] > > > > > Sent: Thursday, April 21, 2011 1:25 AM > > > > > To: nicolas.riou@schneider-electric.com > > > > > Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dijk, Esko > > > > > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" > > > > > flag in ARO] > > > > > > > > > > On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote: > > > > > > > > > > > > Dear Pascal and al, > > > > > > > > > > > > I support the idea of reviving the TID in ARO and DAR/DAC. > > > > > > Supporting a TID directly in the node initiating the initial NS > > > > > > appears much simpler than time stamping in the parent router. > > > > > > > > > > How would you make this work if the protocol between the routers is > > > > > not RPLv1, but some future version of RPL or a completely different > > > > > routing protocol? > > > > > > > > > > The decoupling of the host-router interaction from router-router > > > > > interaction has served us well in the history of the Internet. > > > > > > > > > > Erik > > > > > > > > > > > A simple and efficient method to detect mobility of hosts along a > > > > > > backbone of Edge Routers is an important feature to deploy > > > > > > backbones of Edge Routers in Buildings and should be clarified > > > > > > before closing 6LoWPAN WG. > > > > > > > > > > > > Cheers, > > > > > > Nicolas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *"Pascal Thubert (pthubert)" <pthubert@cisco.com>* Envoyé par : > > > > > > 6lowpan-bounces@ietf.org > > > > > > > > > > > > 18/04/2011 10:37 > > > > > > > > > > > > > > > > > > A > > > > > > "Dijk, Esko" <esko.dijk@philips.com>, "Erik Nordmark" > > > > > > <nordmark@acm.org> cc > > > > > > 6lowpan@ietf.org > > > > > > Objet > > > > > > Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > > > > > ARO] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Esko, Erik > > > > > > > > > > > > The discussion on RPL and hosts should happen on the RPL list > > > > > > under a different topic. The point being discussed here is this: > > > > > > > > > > > > The reality is also that those (LLN) networks will need to scale > > > > > > to large subnets in plants, building, etc... (see the requirement > > > > > > drafts in ROLL). Registering to all LBRS is totally impractical. > > > > > > 6LoWPAN ND requires a coordination between LBRs but does not say > > > how it happens. > > > > > > This problem was discussed in 6LoWPAN; the answer was in > > > > > > ND-01to07; and it requires a TID, for the same reason as RPL. > > > > > > Removing the backbone operation and the TID from the draft is >ostrich > > > policy. > > > > > > > > > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all > > > > > > other registrations do when strict ordering is not guaranteed (MIP > > > > > > being an example). Say that due to some config, a node registers a > > > > > > lifetime of X, then deregisters (lifetime 0), then reregisters > > > > > > (lifetime X) in a rapid sequence, but does not get an answer yet. > > > > > > Then it finally gets 2 AROs back, lifetime X and 0. What's the final >state > > > in the router? > > > > > > > > > > > > I'd like to hear what others think. > > > > > > > > > > > > Pascal > > > > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: > > > > > > Monday, April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal > > > > > > Thubert > > > > > > (pthubert) > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] FW: > > > > > > TID in ARO [was: "Advertize on Behalf" flag in > ARO] > > Hello > > > > > > Erik, > > > > > > > > taking the definition you quoted: > > > > > > > 'host' refers to an LLN device that can generate but does not > > > > > > forward > RPL traffic > > the question may arise what is "RPL > > > > > > traffic"? It is not defined in the RPL draft > it seems. Pascal > > > > > > clarified to me it is traffic associated to a RPL instance, not > > > > > > > necessarily RPL protocol messages. This means that a host could > > > > > > generate > RPL traffic without being aware of the existence of > > > > > > RPL at all. So, _not_ all > hosts have to speak RPL? > > > > > > > The RPL draft does not explicitly state if "hosts" in a RPL > > > > > > network always > speak RPL, never speak RPL, or can be mixed > > > > > > RPL/non-RPL speakers. > > > > > > > > > > > > > > Taking the definition of 'node' in the RPL draft: > > > > > > > 'node' refers to any RPL device, either a host or a router > > > > > > > > rules out (?) the option that all "hosts" are non-RPL speakers, > > > > > > since there > may be a "RPL device" (i.e. RPL-speaking device, I > > > > > > assume) that is also a host. > > > > > > > > > > > > > > I communicated these perceived unclarities to Pascal and the > > > > > > RFC editor 2 > weeks ago. Once this is clear I think the present > > > > > > discussion can continue. > > > > > > > And then there is the related discussion of ND support for > > > > > > sleepy devices, > the original topic of Anders ;) > > best > > > > > > regards, > > Esko > > > > -----Original Message----- > From: > > > > > > 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > > > > > > Behalf Of Erik Nordmark > Sent: Friday 15 April 2011 18:39 > To: > > > > > > Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re: > > > > > > [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > > > > > > > ARO] > > > > > > > > On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: > > > > > > > > > > > > > > > RPL can do what all classical IGPs can do WRT hosts. That is > > > > > > as long > > as the host address belongs to the router's prefix > > > > > > and stays attached > > to that router. > > > > > > > > > > > > > > I just realized that we might be talking about a different > > > > > > definition of "host". > > > > > > > What I mean by "host" is a node which does not participate in a > > > > > > routing > protocol, and does not forward packets (except packets > > > > > > explicitly addressed > to itself using e.g., a routing header). > > > > > > > > > > > > > > However, RPL has a different definition: > > > > > > > 'host' refers to an LLN device that can generate but does not > > > > > > forward > RPL traffic > > Basically per the RPL definition > > > > > > there is no such thing as a node which does > not participate in > > > > > > the RPL protocol. > > > > > > > IMHO what is in RPL should have been defined as a > > > > > > non-forwarding node, so > that we can have a sane discussion > > > > > > without getting entangled in terminology > issues. > > > > > > > > > > > > > > Which definition of "host" are you using above? > > > > > > > > > > > > > > Per the RPL definition there is no need for 6lowpan-nd, since > > > > > > all nodes will > speak RPL. This is rather confusing, don't you >think? > > > > > > > > > > > > > > Erik > > > > > > > > > > > > > > > When the topology becomes multilink subnet and mobility is > > > > > > required > > then it is a new problem entirely, and NO, 4861 is > > > > > > not a suitable > > interaction with the router to allow the > > > > > > router to redistribute a host route. > > > > > > > > Because the neighbor cache that 4861 builds is not a of the > > > > > > same > > > > > > > > nature as the binding table that 6LoWPAN ND builds. Another > > > > > > > > thing > > > > > > that > > 6LoWPAN ND fails to express correctly. I proposed text > > > > > > to explain that > > (attached) but it was not considered, > > > > > > contributing to the illusion > > that a cache is a table. > > > > > > > > > > > > > > > > The reality is also that those networks will need to scale to > > > > > > large > > subnets in plants, building, etc... (see the > > > > > > requirement drafts in > > ROLL). Registering to all LBRS is >totally > > > impractical. > > > > > > 6LoWPAN ND > > requires a coordination between LBRs but does not > > > > > > say how it happens. > > > > > > > > This problem was discussed in 6LoWPAN; the answer was in > > > > > > ND-01to07; > > and it requires a TID, for the same reason as RPL. > > > > > > Removing the > > backbone operation and the TID from the draft is > > > > > > ostrich > > > > > policy. > > > > > > > > > > > > > > > > RPL already adapted to the new reality of large multilink > > > > > > subnet with > > inner mobility. Placing the blame on RPL is > > > > > > another illusionist trick. > > > > > > > > And this is not RPL last call. > > > > > > > > > > > > > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as > > > > > > all other > > registrations do when strict ordering is not > > > > > > guaranteed (MIP being an > > example). Say that due to some > > > > > > config, a node registers a lifetime of > > X, then deregisters > > > > > > (lifetime 0), then reregisters (lifetime X) in a > > rapid > > > > > > sequence, but does not get an answer yet. Then it finally gets > > > > > > 2 > > > > > > > > AROs back, lifetime X and 0. What's the final state in the >router? > > > > > > > > > > > > > > > > It seems we can never agree on any of this. I'd like to hear > > > > > > what > > > > > > > > others think. > > > > > > > > > > > > > > > > Pascal > > > > > > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > > > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan- > > > > > bounces@ietf.org] > > > > > > On > >> Behalf Of Erik Nordmark > >> Sent: Friday, April 15, > > > > > > 2011 > > > > > > 1:30 AM > >> To: 6lo>> '6lowpan' > > > > > > > >> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag > > > > > > in ARO > >> > >> > >> On 4/13/11 12:53 AM, Pascal Thubert > > > > > > (pthubert) > > > > > > wrote: > > > > > > > >>> Hi Erik: > > > > > > > >>> > > > > > > > >>> The RPL (DAO) sequence number allows the node to increment > > > > > > rapidly > >>> in case of rapid changes and then lazily when the > > > > > > situation is > >>> stable and DAO are scarce. The increase is > > > > > > strictly monotonous which > > > >>> is critical to us. > > > > > > > >>> > > > > > > > >>> A time stamp imposes a synchronization between the routers. > > > > > > We do > >>> not have such mechanism in RPL. A time unit (a > > > > > > granularity) must be > >>> agreed upon. Within that unit, > > > > > > movements go undetected so the time > >>> unit must be thin >grained > > > to cover rapid changes. > > > > > > Yet, depending on > >>> the medium, the time unit, and the size > > > > > > of the network, it is not > >>> necessarily easy/possible to > > > > > > guarantee a strictly monotonous value > >>> with a thin grained > > > > > > time unit. And we have limited space (2 > > > > > > octets) > > > > > > > >>> and have to deal with wrap around, which divides the space > > > > > > by at > > least 3. > > > > > > > >>> > > > > > > > >>> So RPL went for a sequence number. > > > > > > > >> > > > > > > > >> But the unstated assumption that RPL made is that all > > > > > > host-to-router > >> protocols have to now be RPL aware. That > > > > > > doesn't sound like good > > design. > > > > > > > >> A host isn't aware of whether the routers speak IS-IS or > > > > > > OSPF, so why > >> do the hosts need to be aware of RPL by passing > > > > > > some TID around? > > > > > > > >> > > > > > > > >>> I think ND has the same need as MIP for a TID == Sequence # >. > > > > > > We > >>> know of MIP; We know of RPL. We know of the backbone > > > > > > router > > > > > > > >>> operation. We know we'll need the TID and we know exactly > > > > > > > >>> why. I think we should have it in the 6LowPAN ND spec right > > > > > > > >>> away to > > > > > > avoid > >>> interop issues when we add RPL and BR operations. > > > > > > > >> > > > > > > > >> I don't see a need in 6lowpan-nd for a TID; the protocol > > > > > > works fine > > without it. > > > > > > > >> I think RPL needs to be improved to deal with reality. Isn't > > > > > > there a > >> desire for RPL to handle 4861 hosts? Those would > > > > > > never know about a > > TID. > > > > > > > >> > > > > > > > >> Erik > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> 6lowpan mailing list > > > > > > > >> 6lowpan@ietf.org > > > > > > > >> https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > _______________________________________________ > > > > > > > > 6lowpan mailing list > > > > > > > > 6lowpan@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 6lowpan mailing list > > > > > > > 6lowpan@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > > > 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. > > > > > > > > > > > > _______________________________________________ > > > > > > 6lowpan mailing list > > > > > > 6lowpan@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > > > > > > > > > __________________________________________________________ > > > > > ____________ > > > > > > This email has been scanned by the MessageLabs Email Security > > > System. > > > > > > > > > > > > > > __________________________________________________________ > > > > > ____________ > > > > > > > > > > > > > > _______________________________________________ > > > > 6lowpan mailing list > > > > 6lowpan@ietf.org > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >
- [6lowpan] FW: TID in ARO [was: "Advertize on Beha… Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Erik Nordmark
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Erik Nordmark
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Erik Nordmark
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … nicolas.riou
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Geoff Mulligan
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Geoff Mulligan
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Erik Nordmark
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Erik Nordmark
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Erik Nordmark
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Wassim Haddad
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pete St. Pierre
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Basavaraj.Patil
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Behcet Sarikaya