Category: Goals to be achieved by this use case: Roles <To make it very general use actors>: Needs (Preconditions): Context (Triggers) - Optional: Usage Scenarios: <Add steps to each usage scenario> Postconditions - Optional: We put together all the use cases and then classify them in terms of priority and/or life-term. And hopefully that should also help us identify the functional requirements / components Here is a sample that I prepared Use Case: Intermittent Data acquisition from a LowPAN device Category(s): Healthcare Goals to be achieved by this use case: Obtain data for monitoring at the client machine in the local network. Summary of the data acquired maybe stored. The Profile of the LowPAN device is fixed. Roles <To make it very general use actors>: Andy � responsible for setting up and managing the client machine. Roy � Installs the LowPAN device and is responsible for its functioning Amin � LowPAN device is devoted to Amin Malin � Unauthorized entity trying to get into the network Dr Brad � Entity that specifies the policies and profile for LowPAN device and Amin. Also recipient of summary of data acquired. Needs (Preconditions): the device is operational and ready to be used Context (Triggers) - Optional: Usage Scenarios: - Identifying Amin and Preparing Amin - Setting up the LowPAN device for data acquisition- preparing the policies - Authorized Data acquisition and control - Unauthorized data acquisition and control - Device Tracking - Device maintenance Post conditions - Optional: We should have a master pool of Categories and Roles � so that all the use cases have a common basis. Other use cases could be - Large scale deployment of LowPAN devices (real-time monitoring) - LowPAN device as a Utility (such as Gas, Electricity) Usage Monitor (Command / Response driven � Profile is being pushed) - LowPAN device being used in Home Network Monitoring (Mobile home owner can access theis LowPAN device in his home) - Touch less access control system at a Building Abhijit Ron Strich <ronstrich@earthlink.net> wrote: Geoff, I agree that "use case" is a better term than architecture, especially considering the historical issues that Carsten has raised. But I also believe that the incorporation of very small devices into a 6lowpan "use case" is important to the adoption of 6lowpan. Cost is also important consideration for 6lowpan adoption. An extra $0.01 in cost imposed by 6lowpan, has a potential $100 million annual impact to the adoption of wireless communications to the micro controller industry at today's production rates. Ron -----Original Message----- From: Geoff Mulligan [mailto:geoff@mulligan.com] Sent: Friday, November 03, 2006 12:36 AM To: Ron Strich Cc: '6lowpan' Subject: Re: [6lowpan] 6lowpan Architecture Questions Ron, These are excellent points. I would like to hear from other on the list about the idea of supporting extremely small devices (4K) (smaller than the extremely small devices that we have been targeting (32K)). I would not like to choose to miss a potential market segment (potentially large market segment), but is it reasonable to got after a 4k device which probably could not possibly ever accept a 1280 byte (minimum size ipv6) packet. I think question 2 is going to be critical as we move to the next phase of this working group. Hopefully we will finish the format document and start on rechartering. One of the top areas that I think we need to look at is the idea of utilizing Manet and how the design will impact 6lowpan (memory, power, other costs). And whether or not we choose to use the manet approach and protocols, should we down select to a single protocol or some small set and if so what is the criteria for this selection. Please consider what criteria you think we should use to evaluate the available mesh protocols. While the IETF doesn't appear to embrace architecture docs, it is critical for us to agree on some set of use-cases so that we can focus our efforts on providing real solutions. So again, please consider for our rechartering and new work items, should we generate a set of use-cases? What is the format for this? Should we support extremely small devices? And finally what criteria should we use to determine the selection/evaluation of mesh routing protocols (which probably begs for a use-case analysis.) Folks, please start to participate in these discussions. It is only with your input that we will have a successful working group and will create a standard that is useful in the market. geoff On Fri, 2006-10-27 at 09:07 -0500, Ron Strich wrote: > 1. Many sensor and control devices will be too small to support a full > mesh/ip adaptation implementation. Some of these devices may be as small as > 4K of flash and 100s of bytes of RAM and may only be used in a point to > point (P2P), simple star, or very simple mesh implementation (please see the > attached pdf drawing). Incorporation of these very small devices, I > believe, is important to the broad adoption of 6lowpan. > > Should we consider how to support these extremely limited devices? Should > we make it easy for these simple protocol implementations at this level to > adapt to 6lowpan? If we want to include these small devices, should we > consider a more constrained design (limited payload, P2P/star only) that > would simplify the adaptation layer? > > 2. How will the group evaluate what mesh, P2P or star protocols should be > supported? As David pointed out, we may not be allowing for future > capabilities in the current structure of the adaptation layer should we want > to support multiple types of L2 protocols. > > 3. Related to the pending mesh protocol evaluation, is the evaluation of any > functionality related to the "cost" of those technical choices in terms of > power, code size, complexity, RAM, instructions executed, etc? > > 4. As was mentioned on the list a while ago, neither the Problem Statement > nor the Format documents discuss the overall 6LoWPAN architecture. As we > move forward with our next working group items, shouldn't we create a > document to describe the high level architecture which might well encompass > the criteria for evaluation of the protocols and costs mentioned above? > > Ron Strich > Mobile: 228.369.4332 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --------------------------------- Get your email and see which of your friends are online - Right on the new Yahoo.com --0-1576852506-1162639807=:79281 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit <div> </div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Geoff,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Here is one format for preapring the Use Cases.<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial"> <o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Use Case: <Title><o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Category:<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Goals to be achieved by this use case:<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Roles <To make it very general use actors>:<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Needs (Preconditions):<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Context (Triggers) - Optional:<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Usage Scenarios: <Add steps to each usage scenario><o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Postconditions - Optional:<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial"> <o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">We put together all the use cases and then classify them in terms of priority and/or life-term. And hopefully that should also help us identify the functional requirements / components<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial"> <o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Here is a sample that I prepared<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial"> <o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Use Case:<SPAN style="mso-spacerun: yes"> </SPAN>Intermittent Data acquisition from a LowPAN device<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Category(s): Healthcare<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Goals to be achieved by this use case: Obtain data for monitoring at the client machine in the local network. Summary of the data acquired maybe stored. The Profile of the LowPAN device is fixed.<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Roles <To make it very general use actors>: Andy � responsible for setting up and managing the client machine.<o:p></o:p></SPAN></div> <div><?xml:namespace prefix = u1 /><u1:City u2:st="on"><u1:place u2:st="on"><?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:City w:st="on"><st1:place w:st="on"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Roy</SPAN></st1:place></st1:City></u1:place></u1:City><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial"> � Installs the LowPAN device and is responsible for its functioning<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Amin � LowPAN device is devoted to Amin<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Malin � Unauthorized entity trying to get into the network<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Dr Brad � Entity that specifies the policies and profile for LowPAN device and Amin. Also recipient of summary of data acquired.<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Needs (Preconditions): the device is operational and ready to be used<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Context (Triggers) - Optional: <o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Usage Scenarios: <o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">- Identifying Amin and Preparing Amin<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">- Setting up the LowPAN device for data acquisition- preparing the policies<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">- Authorized Data acquisition and control<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">- Unauthorized data acquisition and control<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">- Device Tracking<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">- Device maintenance<o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Post conditions - Optional:<o:p></o:p></SPAN></div> <div class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"><o:p> </o:p></SPAN></div> <div class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">We should have a master pool of Categories and Roles � so that all the use cases have a common basis.<o:p></o:p></SPAN></div> <div class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"><o:p> </o:p></SPAN></div> <div class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Other use cases could be<o:p></o:p></SPAN></div> <div class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in; TEXT-INDENT: -0.25in; tab-stops: list .5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-fareast-font-family: 'Times New Roman'">- </SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Large<SPAN style="mso-spacerun: yes"> </SPAN>scale deployment of LowPAN devices (real-time monitoring)<o:p></o:p></SPAN></div> <div class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in; TEXT-INDENT: -0.25in; tab-stops: list .5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-fareast-font-family: 'Times New Roman'">- </SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">LowPAN device as a Utility (such as Gas, Electricity) Usage Monitor (Command / Response driven � Profile is being pushed)<o:p></o:p></SPAN></div> <div class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in; TEXT-INDENT: -0.25in; tab-stops: list .5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-fareast-font-family: 'Times New Roman'">- </SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">LowPAN device being used in Home Network Monitoring (Mobile home owner can access theis LowPAN device in his home)<o:p></o:p></SPAN></div> <div class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in; TEXT-INDENT: -0.25in; tab-stops: list .5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-fareast-font-family: 'Times New Roman'">- </SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Touch less access control system at a Building <o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial"> <o:p></o:p></SPAN></div> <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Abhijit<o:p></o:p></SPAN></div> <div class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1; tab-stops: list .5in"><FONT face="Times New Roman"></FONT><BR><B><I>Ron Strich <ronstrich@earthlink.net></I></B> wrote:</div> <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Geoff,<BR><BR>I agree that "use case" is a better term than architecture, especially<BR>considering the historical issues that Carsten has raised. But I also<BR>believe that the incorporation of very small devices into a 6lowpan "use<BR>case" is important to the adoption of 6lowpan. Cost is also important<BR>consideration for 6lowpan adoption. An extra $0.01 in cost imposed by<BR>6lowpan, has a potential $100 million annual impact to the adoption of<BR>wireless communications to the micro controller industry at today's<BR>production rates.<BR><BR>Ron<BR><BR>-----Original Message-----<BR>From: Geoff Mulligan [mailto:geoff@mulligan.com] <BR>Sent: Friday, November 03, 2006 12:36 AM<BR>To: Ron Strich<BR>Cc: '6lowpan'<BR>Subject: Re: [6lowpan] 6lowpan Architecture Questions<BR><BR>Ron,<BR>These are excellent points.<BR><BR>I would like to hear from other on the list about the idea of supporting<BR>extremely small devices (4K) (smaller than the extremely small devices<BR>that we have been targeting (32K)). I would not like to choose to miss<BR>a potential market segment (potentially large market segment), but is it<BR>reasonable to got after a 4k device which probably could not possibly<BR>ever accept a 1280 byte (minimum size ipv6) packet. <BR><BR>I think question 2 is going to be critical as we move to the next phase<BR>of this working group. Hopefully we will finish the format document and<BR>start on rechartering. One of the top areas that I think we need to<BR>look at is the idea of utilizing Manet and how the design will impact<BR>6lowpan (memory, power, other costs). And whether or not we choose to<BR>use the manet approach and protocols, should we down select to a single<BR>protocol or some small set and if so what is the criteria for this<BR>selection.<BR><BR>Please consider what criteria you think we should use to evaluate the<BR>available mesh protocols.<BR><BR>While the IETF doesn't appear to embrace architecture docs, it is<BR>critical for us to agree on some set of use-cases so that we can focus<BR>our efforts on providing real solutions.<BR><BR>So again, please consider for our rechartering and new work items,<BR>should we generate a set of use-cases? What is the format for this?<BR>Should we support extremely small devices? And finally what criteria<BR>should we use to determine the selection/evaluation of mesh routing<BR>protocols (which probably begs for a use-case analysis.)<BR><BR>Folks, please start to participate in these discussions. It is only<BR>with your input that we will have a successful working group and will<BR>create a standard that is useful in the market.<BR><BR>geoff<BR><BR><BR><BR>On Fri, 2006-10-27 at 09:07 -0500, Ron Strich wrote:<BR>> 1. Many sensor and control devices will be too small to support a full<BR>> mesh/ip adaptation implementation. Some of these devices may be as small<BR>as<BR>> 4K of flash and 100s of bytes of RAM and may only be used in a point to<BR>> point (P2P), simple star, or very simple mesh implementation (please see<BR>the<BR>> attached pdf drawing). Incorporation of these very small devices, I<BR>> believe, is important to the broad adoption of 6lowpan.<BR>> <BR>> Should we consider how to support these extremely limited devices? Should<BR>> we make it easy for these simple protocol implementations at this level to<BR>> adapt to 6lowpan? If we want to include these small devices, should we<BR>> consider a more constrained design (limited payload, P2P/star only) that<BR>> would simplify the adaptation layer?<BR>> <BR>> 2. How will the group evaluate what mesh, P2P or star protocols should be<BR>> supported? As David pointed out, we may not be allowing for future<BR>> capabilities in the current structure of the adaptation layer should we<BR>want<BR>> to support multiple types of L2 protocols.<BR>> <BR>> 3. Related to the pending mesh protocol evaluation, is the evaluation of<BR>any<BR>> functionality related to the "cost" of those technical choices in terms of<BR>> power, code size, complexity, RAM, instructions executed, etc?<BR>> <BR>> 4. As was mentioned on the list a while ago, neither the Problem Statement<BR>> nor the Format documents discuss the overall 6LoWPAN architecture. As we<BR>> move forward with our next working group items, shouldn't we create a<BR>> document to describe the high level architecture which might well<BR>encompass<BR>> the criteria for evaluation of the protocols and costs mentioned above?<BR>> <BR>> Ron Strich<BR>> Mobile: 228.369.4332<BR>> _______________________________________________<BR>> 6lowpan mailing list<BR>> 6lowpan@ietf.org<BR>> https://www1.ietf.org/mailman/listinfo/6lowpan<BR><BR><BR>_______________________________________________<BR>6lowpan mailing list<BR>6lowpan@ietf.org<BR>https://www1.ietf.org/mailman/listinfo/6lowpan<BR></BLOCKQUOTE><BR><p> <hr size=1>Get your email and see which of your friends are online - Right on the <a href="http://us.rd.yahoo.com/evt=42973/*http://www.yahoo.com/preview"> new Yahoo.com</a> --0-1576852506-1162639807=:79281-- --===============0888170210== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0888170210==-- From 6lowpan-bounces@ietf.org Sat Nov 04 13:33:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgQKr-0008B8-3V; Sat, 04 Nov 2006 13:33:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgQKp-0008AW-Ld for 6lowpan@ietf.org; Sat, 04 Nov 2006 13:33:39 -0500 Received: from web81908.mail.mud.yahoo.com ([68.142.207.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GgQKo-0007Vt-VI for 6lowpan@ietf.org; Sat, 04 Nov 2006 13:33:39 -0500 Received: (qmail 27380 invoked by uid 60001); 4 Nov 2006 18:33:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=3SjQgcibmXHifcek6dGRSIxSlFb16hQde1cahr33s+G9tWBQvUf4xYIBUG8GFCFp/98mEb9rZpfr7lcWPLWc8SroepCfGdvDuZcyRmmRSxfZxLtUFLx2THiwZAbnUTIXFfcD3PnDMQNJm0AHYx2IMHSUbbfMzXun6FxEohKGzzM= ; Message-ID: <20061104183338.27378.qmail@web81908.mail.mud.yahoo.com> Received: from [24.16.14.130] by web81908.mail.mud.yahoo.com via HTTP; Sat, 04 Nov 2006 10:33:38 PST Date: Sat, 4 Nov 2006 10:33:38 -0800 (PST) From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com> To: 6lowpan@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Subject: [6lowpan] Fw: any comments on the proposal from Arch Rock X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0817707659==" Errors-To: 6lowpan-bounces@ietf.org --===============0817707659== Content-Type: multipart/alternative; boundary="0-2108329824-1162665218=:27050" --0-2108329824-1162665218=:27050 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Hi,=0A=0AA few of us had a chance to look at this proposal earlier in the w= eek. The message below=0Ahas comments from Carles Gomez, Mario Mao and myse= lf.=0A=0ASince it may be of interest to the group, I'm forwarding with perm= ission from Carles and Mario.=0A=0A-gabriel=0A=0A=0A----- Forwarded Message= ----=0AFrom: Mario Mao <mariomao@gmail.com>=0ATo: Carles Gomez <carlesgo@m= at.upc.edu>; Geoff Mulligan <geoff@mulligan.com>=0ACc: gabriel montenegro <= gabriel_montenegro_2000@yahoo.com>; Ki-Hyung Kim <kkim86@gmail.com>; Daniel= Park <soohong.park@samsung.com>; Carsten Bormann <cabo@tzi.de>; Christian = Schumacher <schumacher@danfoss.com>=0ASent: Friday, November 3, 2006 5:21:4= 0 AM=0ASubject: Re: any comments on the proposal from Arch Rock=0A=0A=0AHi = All,=0A=0AI would propose my opinions from the view of implementation, than= ks.=0A=0AFirst, I would say the new format is clear and supply more expansi= bility (just like IPv6 extension header).=0A=0AFor my concern, the multicas= t ability. For the most important reason of changing original byte-alignmen= t format to current one is to add B bit and supply way of distinguishing se= qno, how about that in new format? I don't see how does it work for this si= tuation. Have I missed the critical point, thanks if author could give some= hint.=0A=0AAbout the hops left, I also agree the 15 hops would enough for = most cases. In our environment, more than 10 hops would cause a surprising = lag (beacon interval set to 1s). However, it is always right to save space = for further development, we should figure out a good method to balance them= .=0A=0AAt last, simple to implement. By our experience, new format may not = bring convenience. We still have more than 3 headers/extensions to handle, = equal to previous one (may more complex...). But the new format do bring be= nefits beyond that. For our tests show the original format affords enough a= bility for common IPv6 application over WSN, if the new one could follow th= e function exactly and not bring conflict, I vote for the hard packet forma= t changing.=0A=0ARegards,=0A=0AMario Mao=0AMarioMao@Gmail.com=0A=0A=0A-----= Original Message ----- =0AFrom: "Carles Gomez" <carlesgo@mat.upc.edu>=0ATo= : "Geoff Mulligan" <geoff@mulligan.com>=0ACc: "gabriel montenegro" <gabriel= _montenegro_2000@yahoo.com>; "Ki-Hyung Kim" <kkim86@gmail.com>; "Daniel Par= k" <soohong.park@samsung.com>; "Carsten Bormann" <cabo@tzi.de>; "Christian = Schumacher" <schumacher@danfoss.com>; <mariomao@gmail.com>=0ASent: Friday, = November 03, 2006 6:47 PM=0ASubject: Re: any comments on the proposal from = Arch Rock=0A=0A=0A> Dear all,=0A> =0A> We believe the proposed new format i= s clearer and allows development of =0A> extensions and addition of new opt= ions in an easier way, which is relevant =0A> from the point of view of imp= lementation.=0A> =0A> In general, the new format allows for byte savings in= most cases. However, =0A> just to keep a fair comparison (it seems like th= e slides try to represent the =0A> most favorable case for ArchRock proposa= l) it must be noted that when =0A> fragmentation is needed, an offset field= with a size equal to one byte must be =0A> added to fragments other than t= he first one. Hence, in some cases as in slide =0A> 9, "Multihop > 14 hops"= , 7 bytes would be needed with the new format for =0A> fragments other than= the first one, which is one byte more than that needed =0A> with the curre= nt 6lowpan proposal. Anyway, the overall result seems to be a =0A> clearer = format with roughly the same size (in some cases smaller, in some =0A> othe= rs the same as, and in some others greater than that of the current =0A> 6l= owpan proposal).=0A> =0A> Regarding the number of hops, I agree that 15 hop= s should be enough in most =0A> cases. =0A> =0A> Best regards,=0A> =0A> Car= les Gomez=0A> Technical University of Catalonia=0A> =0A> Quoting Geoff Mull= igan <geoff@mulligan.com>:=0A> =0A> > Gabriel,=0A> > Thanks for the quick= review. I think that David and Jonathan had the=0A> > same idea about usi= ng all ones as a mechanism to allow other proto=0A> > types.=0A> > =0A> > I= agree that the idea of 256 hops is probably overkill, i think that=0A> > s= ome folks might think 15 hops is too small, but I think probably=0A> > appr= opriate for 90% of applications.=0A> > =0A> > Also thanks for include Carlo= s.=0A> > =0A> > Everyone, please weigh-in on this quickly.=0A> > =0A> > geo= ff=0A> > =0A> > On Thu, 2006-11-02 at 23:51 -0800, gabriel montenegro wrote= :=0A> > > [I took the liberty of forwarding the slides and the email thread= to=0A> > > the folks at=0A> > > Universidad Politecnica de Catalunya as th= ey have also been involved=0A> > > in implementation=0A> > > work and would= have valuable input. I'm cc-ing Carles to include them=0A> > > in the loop= .]=0A> > > =0A> > > Folks,=0A> > > =0A> > > I have just now looked at the= slides, and my first impression is that=0A> > > the format looks quite=0A>= > > nice and definitely worth sending out to the list. One minor detail is= =0A> > > that the dispatch=0A> > > field is smaller than the current prot_t= ype, but we could just reserve=0A> > > the value=0A> > > of all 1's and use= that to signal a subsequent extended dispatch field=0A> > > (like we used= =0A> > > to have, and like they've done with hops). =0A> > > =0A> > > Slid= es 9 and 10 illustrate the potential gains. I don't think the=0A> > > large= hop functionality=0A> > > is very real (the packet drop rate will probably= make such long paths=0A> > > pointless). The=0A> > > extensibility, I thin= k we already have (just define more protocol_type=0A> > > values). What I= =0A> > > see in the fourth packet figure in slide 12 is more akin to=0A> > = > "piggybacking". This is also=0A> > > possible in IPv6, of course, but is = not always a good idea as it can=0A> > > get complex real soon.=0A> > > But= having the chance of doing piggybacking (several protocols within=0A> > > = one packet) could be=0A> > > useful, yes. In summary, I'm more cautious abo= ut jumping into=0A> > > piggybacking or deep-hopping=0A> > > than I am abou= t the stacking approach itself.=0A> > > =0A> > > Other than that, I'd real= ly like to defer to the folks who've engaged=0A> > > in implementation=0A> = > > of the current format draft.=0A> > > =0A> > > -gabriel --0-2108329824-1162665218=:27050 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:courier, monaco, monospace, sans-serif;f= ont-size:12pt"><DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco,= monospace, sans-serif">Hi,</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAM= ILY: courier, monaco, monospace, sans-serif"> </DIV>=0A<DIV style=3D"F= ONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">A few = of us had a chance to look at this proposal earlier in the week. The messag= e below</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco= , monospace, sans-serif">has comments from Carles Gomez, Mario Mao and myse= lf.</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, mo= nospace, sans-serif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAM= ILY: courier, monaco, monospace, sans-serif">Since it may be of interest to= the group, I'm forwarding with permission from Carles and Mario.</DIV>=0A<= DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans= -serif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier,= monaco, monospace, sans-serif">-gabriel<BR><BR></DIV>=0A<DIV style=3D"FONT= -SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Fo= rwarded Message ----<BR>From: Mario Mao <mariomao@gmail.com><BR>To: C= arles Gomez <carlesgo@mat.upc.edu>; Geoff Mulligan <geoff@mulligan= .com><BR>Cc: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>= ;; Ki-Hyung Kim <kkim86@gmail.com>; Daniel Park <soohong.park@sams= ung.com>; Carsten Bormann <cabo@tzi.de>; Christian Schumacher <= schumacher@danfoss.com><BR>Sent: Friday, November 3, 2006 5:21:40 AM<BR>= Subject: Re: any comments on the proposal from Arch Rock<BR><BR>=0A<DIV>Hi = All,<BR><BR>I would propose my opinions from the view of implementation, th= anks.<BR><BR>First, I would say the new format is clear and supply more exp= ansibility (just like IPv6 extension header).<BR><BR>For my concern, the mu= lticast ability. For the most important reason of changing original byte-al= ignment format to current one is to add B bit and supply way of distinguish= ing seqno, how about that in new format? I don't see how does it work for t= his situation. Have I missed the critical point, thanks if author could giv= e some hint.<BR><BR>About the hops left, I also agree the 15 hops would eno= ugh for most cases. In our environment, more than 10 hops would cause a sur= prising lag (beacon interval set to 1s). However, it is always right to sav= e space for further development, we should figure out a good method to bala= nce them.<BR><BR>At last, simple to implement. By our experience, new forma= t may not bring convenience. We still have more than 3 headers/extensions t= o handle, equal to previous one (may more complex...). But the new format do= bring benefits beyond that. For our tests show the original format affords= enough ability for common IPv6 application over WSN, if the new one could = follow the function exactly and not bring conflict, I vote for the hard pac= ket format changing.<BR><BR>Regards,<BR><BR>Mario Mao<BR>MarioMao@Gmail.com= <BR><BR><BR>----- Original Message ----- <BR>From: "Carles Gomez" <carle= sgo@mat.upc.edu><BR>To: "Geoff Mulligan" <geoff@mulligan.com><BR>C= c: "gabriel montenegro" <gabriel_montenegro_2000@yahoo.com>; "Ki-Hyun= g Kim" <kkim86@gmail.com>; "Daniel Park" <soohong.park@samsung.com= >; "Carsten Bormann" <cabo@tzi.de>; "Christian Schumacher" <sch= umacher@danfoss.com>; <mariomao@gmail.com><BR>Sent: Friday, Novemb= er 03, 2006 6:47 PM<BR>Subject: Re: any comments on the proposal from Arch = Rock<BR><BR><BR>> Dear all,<BR>> <BR>> We believe the proposed new= format is clearer and allows development of <BR>> extensions and addition of new = options in an easier way, which is relevant <BR>> from the point of view= of implementation.<BR>> <BR>> In general, the new format allows for = byte savings in most cases. However, <BR>> just to keep a fair compariso= n (it seems like the slides try to represent the <BR>> most favorable ca= se for ArchRock proposal) it must be noted that when <BR>> fragmentation= is needed, an offset field with a size equal to one byte must be <BR>> = added to fragments other than the first one. Hence, in some cases as in sli= de <BR>> 9, "Multihop > 14 hops", 7 bytes would be needed with the ne= w format for <BR>> fragments other than the first one, which is one byte= more than that needed <BR>> with the current 6lowpan proposal. Anyway, = the overall result seems to be a <BR>> clearer format with roughly the s= ame size (in some cases smaller, in some <BR>> others the same as, and i= n some others greater than that of the current <BR>> 6lowpan proposal).<BR>> <BR>&= gt; Regarding the number of hops, I agree that 15 hops should be enough in = most <BR>> cases. <BR>> <BR>> Best regards,<BR>> <BR>> Carle= s Gomez<BR>> Technical University of Catalonia<BR>> <BR>> Quoting = Geoff Mulligan <geoff@mulligan.com>:<BR>> <BR>> > Gabriel,<B= R>> > Thanks for the quick review. I think tha= t David and Jonathan had the<BR>> > same idea about using all ones as= a mechanism to allow other proto<BR>> > types.<BR>> > <BR>>= > I agree that the idea of 256 hops is probably overkill, i think that<= BR>> > some folks might think 15 hops is too small, but I think proba= bly<BR>> > appropriate for 90% of applications.<BR>> > <BR>>= > Also thanks for include Carlos.<BR>> > <BR>> > Everyone, = please weigh-in on this quickly.<BR>> > <BR>> > geoff<BR>> &= gt; <BR>> > On Thu, 2006-11-02 at 23:51 -0800, gabriel montenegro wrote:<BR>> = > > [I took the liberty of forwarding the slides and the email thread= to<BR>> > > the folks at<BR>> > > Universidad Politecnic= a de Catalunya as they have also been involved<BR>> > > in impleme= ntation<BR>> > > work and would have valuable input. I'm cc-ing Ca= rles to include them<BR>> > > in the loop.]<BR>> > > = ; <BR>> > > Folks,<BR>> > > <BR>> >= > I have just now looked at the slides, and my first impression is that= <BR>> > > the format looks quite<BR>> > > nice and defini= tely worth sending out to the list. One minor detail is<BR>> > > t= hat the dispatch<BR>> > > field is smaller than the current prot_t= ype, but we could just reserve<BR>> > > the value<BR>> > >= ; of all 1's and use that to signal a subsequent extended dispatch field<BR= >> > > (like we used<BR>> > > to have, and like they've done with h= ops). <BR>> > > <BR>> > > Slides 9 and 10 illu= strate the potential gains. I don't think the<BR>> > > large hop f= unctionality<BR>> > > is very real (the packet drop rate will prob= ably make such long paths<BR>> > > pointless). The<BR>> > &g= t; extensibility, I think we already have (just define more protocol_type<B= R>> > > values). What I<BR>> > > see in the fourth packet= figure in slide 12 is more akin to<BR>> > > "piggybacking". This = is also<BR>> > > possible in IPv6, of course, but is not always a = good idea as it can<BR>> > > get complex real soon.<BR>> > &= gt; But having the chance of doing piggybacking (several protocols within<B= R>> > > one packet) could be<BR>> > > useful, yes. In sum= mary, I'm more cautious about jumping into<BR>> > > piggybacking o= r deep-hopping<BR>> > > than I am about the stacking approach itsel= f.<BR>> > > <BR>> > > Other than that, I'd rea= lly like to defer to the folks who've engaged<BR>> > > in implemen= tation<BR>> > > of the current format draft.<BR>> > > <BR= >> > > -gabriel<BR></DIV></DIV></div></body></html> --0-2108329824-1162665218=:27050-- --===============0817707659== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0817707659==-- From 6lowpan-bounces@ietf.org Sat Nov 04 14:15:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgQzX-0003Bp-80; Sat, 04 Nov 2006 14:15:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgQzW-0003Bk-Kx for 6lowpan@ietf.org; Sat, 04 Nov 2006 14:15:42 -0500 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgQzW-0004xj-2I for 6lowpan@ietf.org; Sat, 04 Nov 2006 14:15:42 -0500 Received: by secure.archedrock.com (Postfix, from userid 101) id 81A0C16B0002; Sat, 4 Nov 2006 11:15:39 -0800 (PST) Received: from [127.0.0.1] (adsl-71-142-86-178.dsl.pltn13.pacbell.net [71.142.86.178]) by secure.archedrock.com (Postfix) with ESMTP id 196C916B0001; Sat, 4 Nov 2006 11:15:36 -0800 (PST) Message-ID: <454CE6D7.9000500@archrock.com> Date: Sat, 04 Nov 2006 11:15:35 -0800 From: Jonathan Hui <jhui@archrock.com> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com> Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock References: <20061104183338.27378.qmail@web81908.mail.mud.yahoo.com> In-Reply-To: <20061104183338.27378.qmail@web81908.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.0.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Errors-To: 6lowpan-bounces@ietf.org In response to Mario's concerns about the B-bit for multicast meshing, we would argue that this functionality can be fairly represented by assigning a new dispatch type to creating a new extension header. This header does require two bytes (1 for the dispatch and 1 for the sequence number) vs. 1 extra byte in the current proposal. However, it is not clear to us whether an 8-bit sequence number field is sufficient for current and possibly future protocols that may implement multicast meshing. What the dispatch byte allows is support for not only a header that includes a single 8-bit sequence number, but also room for other future headers that may require more than that. We feel that adding the extra dispatch byte to allow support for multiple protocols is well worth it. Note that adding new extension headers is useful for any meshing protocol (both unicast and multicast). In response to Carles' concerns about the byte counts, we believe we are doing the comparison fairly. In the case with fragmentation, you are correct that the offset byte must be added. However, the upper-layer protocol dispatch byte is only needed in the first fragment. This is analogous to the current 6lowpan format replacing the prot_type bits with the dgram_offset bits. However, we feel that our proposal is conceptually cleaner because the concepts of prot_type and dgram_offset are kept separate in orthogonal headers. Our fault for not making that clear in the slides, thanks for pointing that out. -- Jonathan Hui jhui@archrock.com gabriel montenegro wrote: > Hi, > > A few of us had a chance to look at this proposal earlier in the week. > The message below > has comments from Carles Gomez, Mario Mao and myself. > > Since it may be of interest to the group, I'm forwarding with permission > from Carles and Mario. > > -gabriel > > ----- Forwarded Message ---- > From: Mario Mao <mariomao@gmail.com> > To: Carles Gomez <carlesgo@mat.upc.edu>; Geoff Mulligan <geoff@mulligan.com> > Cc: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>; Ki-Hyung Kim > <kkim86@gmail.com>; Daniel Park <soohong.park@samsung.com>; Carsten > Bormann <cabo@tzi.de>; Christian Schumacher <schumacher@danfoss.com> > Sent: Friday, November 3, 2006 5:21:40 AM > Subject: Re: any comments on the proposal from Arch Rock > > Hi All, > > I would propose my opinions from the view of implementation, thanks. > > First, I would say the new format is clear and supply more expansibility > (just like IPv6 extension header). > > For my concern, the multicast ability. For the most important reason of > changing original byte-alignment format to current one is to add B bit > and supply way of distinguishing seqno, how about that in new format? I > don't see how does it work for this situation. Have I missed the > critical point, thanks if author could give some hint. > > About the hops left, I also agree the 15 hops would enough for most > cases. In our environment, more than 10 hops would cause a surprising > lag (beacon interval set to 1s). However, it is always right to save > space for further development, we should figure out a good method to > balance them. > > At last, simple to implement. By our experience, new format may not > bring convenience. We still have more than 3 headers/extensions to > handle, equal to previous one (may more complex...). But the new format > do bring benefits beyond that. For our tests show the original format > affords enough ability for common IPv6 application over WSN, if the new > one could follow the function exactly and not bring conflict, I vote for > the hard packet format changing. > > Regards, > > Mario Mao > MarioMao@Gmail.com > > > ----- Original Message ----- > From: "Carles Gomez" <carlesgo@mat.upc.edu> > To: "Geoff Mulligan" <geoff@mulligan.com> > Cc: "gabriel montenegro" <gabriel_montenegro_2000@yahoo.com>; "Ki-Hyung > Kim" <kkim86@gmail.com>; "Daniel Park" <soohong.park@samsung.com>; > "Carsten Bormann" <cabo@tzi.de>; "Christian Schumacher" > <schumacher@danfoss.com>; <mariomao@gmail.com> > Sent: Friday, November 03, 2006 6:47 PM > Subject: Re: any comments on the proposal from Arch Rock > > > > Dear all, > > > > We believe the proposed new format is clearer and allows development of > > extensions and addition of new options in an easier way, which is > relevant > > from the point of view of implementation. > > > > In general, the new format allows for byte savings in most cases. > However, > > just to keep a fair comparison (it seems like the slides try to > represent the > > most favorable case for ArchRock proposal) it must be noted that when > > fragmentation is needed, an offset field with a size equal to one > byte must be > > added to fragments other than the first one. Hence, in some cases as > in slide > > 9, "Multihop > 14 hops", 7 bytes would be needed with the new format for > > fragments other than the first one, which is one byte more than that > needed > > with the current 6lowpan proposal. Anyway, the overall result seems > to be a > > clearer format with roughly the same size (in some cases smaller, in > some > > others the same as, and in some others greater than that of the current > > 6lowpan proposal). > > > > Regarding the number of hops, I agree that 15 hops should be enough > in most > > cases. > > > > Best regards, > > > > Carles Gomez > > Technical University of Catalonia > > > > Quoting Geoff Mulligan <geoff@mulligan.com>: > > > > > Gabriel, > > > Thanks for the quick review. I think that David and Jonathan had the > > > same idea about using all ones as a mechanism to allow other proto > > > types. > > > > > > I agree that the idea of 256 hops is probably overkill, i think that > > > some folks might think 15 hops is too small, but I think probably > > > appropriate for 90% of applications. > > > > > > Also thanks for include Carlos. > > > > > > Everyone, please weigh-in on this quickly. > > > > > > geoff > > > > > > On Thu, 2006-11-02 at 23:51 -0800, gabriel montenegro wrote: > > > > [I took the liberty of forwarding the slides and the email thread to > > > > the folks at > > > > Universidad Politecnica de Catalunya as they have also been involved > > > > in implementation > > > > work and would have valuable input. I'm cc-ing Carles to include them > > > > in the loop.] > > > > > > > > Folks, > > > > > > > > I have just now looked at the slides, and my first impression is that > > > > the format looks quite > > > > nice and definitely worth sending out to the list. One minor > detail is > > > > that the dispatch > > > > field is smaller than the current prot_type, but we could just > reserve > > > > the value > > > > of all 1's and use that to signal a subsequent extended dispatch > field > > > > (like we used > > > > to have, and like they've done with hops). > > > > > > > > Slides 9 and 10 illustrate the potential gains. I don't think the > > > > large hop functionality > > > > is very real (the packet drop rate will probably make such long paths > > > > pointless). The > > > > extensibility, I think we already have (just define more > protocol_type > > > > values). What I > > > > see in the fourth packet figure in slide 12 is more akin to > > > > "piggybacking". This is also > > > > possible in IPv6, of course, but is not always a good idea as it can > > > > get complex real soon. > > > > But having the chance of doing piggybacking (several protocols within > > > > one packet) could be > > > > useful, yes. In summary, I'm more cautious about jumping into > > > > piggybacking or deep-hopping > > > > than I am about the stacking approach itself. > > > > > > > > Other than that, I'd really like to defer to the folks who've engaged > > > > in implementation > > > > of the current format draft. > > > > > > > > -gabriel > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 04 15:07:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgRnJ-00089Y-EB; Sat, 04 Nov 2006 15:07:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgRnI-00089B-G7 for 6lowpan@ietf.org; Sat, 04 Nov 2006 15:07:08 -0500 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgRnF-0004Kr-TZ for 6lowpan@ietf.org; Sat, 04 Nov 2006 15:07:08 -0500 Received: by secure.archedrock.com (Postfix, from userid 101) id 62CA516B0002; Sat, 4 Nov 2006 12:07:05 -0800 (PST) Received: from [127.0.0.1] (adsl-71-142-86-178.dsl.pltn13.pacbell.net [71.142.86.178]) by secure.archedrock.com (Postfix) with ESMTP id 14B4E16B0001; Sat, 4 Nov 2006 12:07:03 -0800 (PST) Message-ID: <454CF2E5.1030906@archrock.com> Date: Sat, 04 Nov 2006 12:07:01 -0800 From: Jonathan Hui <jhui@archrock.com> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com> Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock References: <20061104183338.27378.qmail@web81908.mail.mud.yahoo.com> In-Reply-To: <20061104183338.27378.qmail@web81908.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.0.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Errors-To: 6lowpan-bounces@ietf.org Hi Gabriel, thanks for your feedback as well. In the current 6lowpan proposal, the prot_type field disappears in packets that are subsequent fragments. Thus, the prot_type field in the current proposal only allows extensibility in upper layer protocols and possibly in packets that do not require fragmentation. In the current 6lowpan proposal it wasn't clear to us how a new mesh protocol that wanted to add a field to the header would do so in a clean way. Also, what we were trying to convey with the "piggybacking" capability with the stacked headers was that it was possible, not that we should promote it. Overall, what we are trying to promote is a header format that is extensible and flexible so that we can cleanly adapt when new ideas or unforeseen issues arise in the future. This also applies with the hops extension for deep mesh networks. A few people have already mentioned that 15 hops is fine in most cases. But we wanted show that we could support essentially all of the current functionality in the 6lowpan proposal (which includes support for >15 hops) rather than showing reduced functionality. -- Jonathan Hui jhui@archrock.com gabriel montenegro wrote: > Hi, > > A few of us had a chance to look at this proposal earlier in the week. > The message below > has comments from Carles Gomez, Mario Mao and myself. > > Since it may be of interest to the group, I'm forwarding with permission > from Carles and Mario. > > -gabriel > > ----- Forwarded Message ---- > From: Mario Mao <mariomao@gmail.com> > To: Carles Gomez <carlesgo@mat.upc.edu>; Geoff Mulligan <geoff@mulligan.com> > Cc: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>; Ki-Hyung Kim > <kkim86@gmail.com>; Daniel Park <soohong.park@samsung.com>; Carsten > Bormann <cabo@tzi.de>; Christian Schumacher <schumacher@danfoss.com> > Sent: Friday, November 3, 2006 5:21:40 AM > Subject: Re: any comments on the proposal from Arch Rock > > Hi All, > > I would propose my opinions from the view of implementation, thanks. > > First, I would say the new format is clear and supply more expansibility > (just like IPv6 extension header). > > For my concern, the multicast ability. For the most important reason of > changing original byte-alignment format to current one is to add B bit > and supply way of distinguishing seqno, how about that in new format? I > don't see how does it work for this situation. Have I missed the > critical point, thanks if author could give some hint. > > About the hops left, I also agree the 15 hops would enough for most > cases. In our environment, more than 10 hops would cause a surprising > lag (beacon interval set to 1s). However, it is always right to save > space for further development, we should figure out a good method to > balance them. > > At last, simple to implement. By our experience, new format may not > bring convenience. We still have more than 3 headers/extensions to > handle, equal to previous one (may more complex...). But the new format > do bring benefits beyond that. For our tests show the original format > affords enough ability for common IPv6 application over WSN, if the new > one could follow the function exactly and not bring conflict, I vote for > the hard packet format changing. > > Regards, > > Mario Mao > MarioMao@Gmail.com > > > ----- Original Message ----- > From: "Carles Gomez" <carlesgo@mat.upc.edu> > To: "Geoff Mulligan" <geoff@mulligan.com> > Cc: "gabriel montenegro" <gabriel_montenegro_2000@yahoo.com>; "Ki-Hyung > Kim" <kkim86@gmail.com>; "Daniel Park" <soohong.park@samsung.com>; > "Carsten Bormann" <cabo@tzi.de>; "Christian Schumacher" > <schumacher@danfoss.com>; <mariomao@gmail.com> > Sent: Friday, November 03, 2006 6:47 PM > Subject: Re: any comments on the proposal from Arch Rock > > > > Dear all, > > > > We believe the proposed new format is clearer and allows development of > > extensions and addition of new options in an easier way, which is > relevant > > from the point of view of implementation. > > > > In general, the new format allows for byte savings in most cases. > However, > > just to keep a fair comparison (it seems like the slides try to > represent the > > most favorable case for ArchRock proposal) it must be noted that when > > fragmentation is needed, an offset field with a size equal to one > byte must be > > added to fragments other than the first one. Hence, in some cases as > in slide > > 9, "Multihop > 14 hops", 7 bytes would be needed with the new format for > > fragments other than the first one, which is one byte more than that > needed > > with the current 6lowpan proposal. Anyway, the overall result seems > to be a > > clearer format with roughly the same size (in some cases smaller, in > some > > others the same as, and in some others greater than that of the current > > 6lowpan proposal). > > > > Regarding the number of hops, I agree that 15 hops should be enough > in most > > cases. > > > > Best regards, > > > > Carles Gomez > > Technical University of Catalonia > > > > Quoting Geoff Mulligan <geoff@mulligan.com>: > > > > > Gabriel, > > > Thanks for the quick review. I think that David and Jonathan had the > > > same idea about using all ones as a mechanism to allow other proto > > > types. > > > > > > I agree that the idea of 256 hops is probably overkill, i think that > > > some folks might think 15 hops is too small, but I think probably > > > appropriate for 90% of applications. > > > > > > Also thanks for include Carlos. > > > > > > Everyone, please weigh-in on this quickly. > > > > > > geoff > > > > > > On Thu, 2006-11-02 at 23:51 -0800, gabriel montenegro wrote: > > > > [I took the liberty of forwarding the slides and the email thread to > > > > the folks at > > > > Universidad Politecnica de Catalunya as they have also been involved > > > > in implementation > > > > work and would have valuable input. I'm cc-ing Carles to include them > > > > in the loop.] > > > > > > > > Folks, > > > > > > > > I have just now looked at the slides, and my first impression is that > > > > the format looks quite > > > > nice and definitely worth sending out to the list. One minor > detail is > > > > that the dispatch > > > > field is smaller than the current prot_type, but we could just > reserve > > > > the value > > > > of all 1's and use that to signal a subsequent extended dispatch > field > > > > (like we used > > > > to have, and like they've done with hops). > > > > > > > > Slides 9 and 10 illustrate the potential gains. I don't think the > > > > large hop functionality > > > > is very real (the packet drop rate will probably make such long paths > > > > pointless). The > > > > extensibility, I think we already have (just define more > protocol_type > > > > values). What I > > > > see in the fourth packet figure in slide 12 is more akin to > > > > "piggybacking". This is also > > > > possible in IPv6, of course, but is not always a good idea as it can > > > > get complex real soon. > > > > But having the chance of doing piggybacking (several protocols within > > > > one packet) could be > > > > useful, yes. In summary, I'm more cautious about jumping into > > > > piggybacking or deep-hopping > > > > than I am about the stacking approach itself. > > > > > > > > Other than that, I'd really like to defer to the folks who've engaged > > > > in implementation > > > > of the current format draft. > > > > > > > > -gabriel > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Nov 05 11:59:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglL6-0002hH-GR; Sun, 05 Nov 2006 11:59:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglL4-0002h9-U3 for 6lowpan@ietf.org; Sun, 05 Nov 2006 11:59:18 -0500 Received: from web81910.mail.mud.yahoo.com ([68.142.207.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GglL2-0001vA-F7 for 6lowpan@ietf.org; Sun, 05 Nov 2006 11:59:18 -0500 Received: (qmail 16152 invoked by uid 60001); 5 Nov 2006 16:59:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=rXG3zZaMj6Z/tC94rekpTs/vhPIYFtZTWdOTiLnJf7sCUC2eeHsTixFz8LkpowGrcZ48LXHURxRp0arn7xK3ZKqRU4VNBiqlWTFynsAWQYGcW/LNblb6fVMigDfCkl7myRGbs10gst5V34sDKFNllKV9h7x02wyJdGdXRcmwgBw= ; Message-ID: <20061105165900.16105.qmail@web81910.mail.mud.yahoo.com> Received: from [24.16.14.130] by web81910.mail.mud.yahoo.com via HTTP; Sun, 05 Nov 2006 08:58:59 PST Date: Sun, 5 Nov 2006 08:58:58 -0800 (PST) From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com> Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock To: Jonathan Hui <jhui@archrock.com> MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1158795150==" Errors-To: 6lowpan-bounces@ietf.org --===============1158795150== Content-Type: multipart/alternative; boundary="0-460982252-1162745939=:16043" --0-460982252-1162745939=:16043 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Jonathan,=0A=0A=0AI'm confused by your paragraph below. I'm not sure what y= ou mean by=0Athis. The prot_type field disappearing in subsequent packets h= as no =0Abearing on extensibility as I understand it. For example, if you w= ere=0Ato in the future decide to carry, say, RNP ("random network protocol"= )=0Aover the current lowpan encapsulation, you'd have a prot_type value =0A= assigned for RNP. This would allow you to send RNP over lowpan even if=0Ayo= u had a mesh configuration underneath (the mesh delivery header being=0Aa g= eneral lowpan layer service), or if your RNP packets were large=0A(by using= the fragmentation service, again a general lowpan layer=0Aservice). If a r= eceiving station were to receive, say, a fragment=0Afor an packet, it might= not be able to know that it is RNP until=0Amore fragments arrive. But it w= ouldn't be able to do anything until=0Athe entire RNP packet arrives anyway= s. Just like in IPv4 or v6 fragmentation.=0A=0AOr did you have something el= se in mind?=0A=0Atnx,=0A=0A-gabriel=0A=0A----- Original Message ----=0AIn t= he current 6lowpan proposal, the prot_type field disappears in =0Apackets t= hat are subsequent fragments. Thus, the prot_type field in the =0Acurrent p= roposal only allows extensibility in upper layer protocols and =0Apossibly = in packets that do not require fragmentation. In the current =0A6lowpan pro= posal it wasn't clear to us how a new mesh protocol that =0Awanted to add a= field to the header would do so in a clean way. Also, =0Awhat we were tryi= ng to convey with the "piggybacking" capability with =0Athe stacked headers= was that it was possible, not that we should promote =0Ait. --0-460982252-1162745939=:16043 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:courier, monaco, monospace, sans-serif;f= ont-size:12pt"><DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco,= monospace, sans-serif">Jonathan,</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FO= NT-FAMILY: courier, monaco, monospace, sans-serif"> </DIV>=0A<DIV styl= e=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">= <BR>I'm confused by your paragraph below. I'm not sure what you mean by</DI= V>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace= , sans-serif">this. The prot_type field disappearing in subsequent packets = has no </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco= , monospace, sans-serif">bearing on extensibility as I understand it. For e= xample, if you were</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: cou= rier, monaco, monospace, sans-serif">to in the future decide to carry, say,= RNP ("random network protocol")</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FON= T-FAMILY: courier, monaco, monospace, sans-serif">over the current lowpan e= ncapsulation, you'd have a prot_type value </DIV>=0A<DIV style=3D"FONT-SIZE= : 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">assigned for R= NP. This would allow you to send RNP over lowpan even if</DIV>=0A<DIV style= =3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">y= ou had a mesh configuration underneath (the mesh delivery header being</DIV= >=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace,= sans-serif">a general lowpan layer service), or if your RNP packets were l= arge</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, m= onospace, sans-serif">(by using the fragmentation service, again a general = lowpan layer</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, m= onaco, monospace, sans-serif">service). If a receiving station were to rece= ive, say, a fragment</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: co= urier, monaco, monospace, sans-serif">for an packet, it might not be able t= o know that it is RNP until</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAM= ILY: courier, monaco, monospace, sans-serif">more fragments arrive. But it = wouldn't be able to do anything until</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt= ; FONT-FAMILY: courier, monaco, monospace, sans-serif">the entire RNP packe= t arrives anyways. Just like in IPv4 or v6 fragmentation.</DIV>=0A<DIV styl= e=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">= </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco,= monospace, sans-serif">Or did you have something else in mind?</DIV>=0A<DI= V style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-s= erif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, m= onaco, monospace, sans-serif">tnx,</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; F= ONT-FAMILY: courier, monaco, monospace, sans-serif"> </DIV>=0A<DIV sty= le=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif"= >-gabriel<BR></DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new= roman, new york, times, serif">----- Original Message ----<BR>In the curre= nt 6lowpan proposal, the prot_type field disappears in <BR>packets that are= subsequent fragments. Thus, the prot_type field in the <BR>current proposa= l only allows extensibility in upper layer protocols and <BR>possibly in pa= ckets that do not require fragmentation. In the current <BR>6lowpan proposa= l it wasn't clear to us how a new mesh protocol that <BR>wanted to add a fi= eld to the header would do so in a clean way. Also, <BR>what we were trying= to convey with the "piggybacking" capability with <BR>the stacked headers = was that it was possible, not that we should promote <BR>it.<BR></DIV></div= ></body></html> --0-460982252-1162745939=:16043-- --===============1158795150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1158795150==-- From 6lowpan-bounces@ietf.org Sun Nov 05 12:41:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggm05-0001Ea-8L; Sun, 05 Nov 2006 12:41:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggm03-00019f-Ik for 6lowpan@ietf.org; Sun, 05 Nov 2006 12:41:39 -0500 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gglzy-0006Io-6H for 6lowpan@ietf.org; Sun, 05 Nov 2006 12:41:37 -0500 Received: by secure.archedrock.com (Postfix, from userid 101) id 9F4F916B0002; Sun, 5 Nov 2006 09:41:15 -0800 (PST) Received: from [127.0.0.1] (adsl-71-142-86-178.dsl.pltn13.pacbell.net [71.142.86.178]) by secure.archedrock.com (Postfix) with ESMTP id CDFD716B0001; Sun, 5 Nov 2006 09:41:14 -0800 (PST) Message-ID: <454E2238.7000002@archrock.com> Date: Sun, 05 Nov 2006 09:41:12 -0800 From: Jonathan Hui <jhui@archrock.com> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com> Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock References: <20061105165900.16105.qmail@web81910.mail.mud.yahoo.com> In-Reply-To: <20061105165900.16105.qmail@web81910.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.0.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Errors-To: 6lowpan-bounces@ietf.org Gabriel, You are correct that you can use prot_type to allow extensibility above both the mesh and fragmentation layer. However, I was trying to get at extensibility at layers between the mesh and fragmentation. IPv6 suggests that hop-by-hop options (e.g. a sequence number for broadcast/multicast) and routing headers (for source route) should come after addressing but before fragmentation. If these hop-by-hop/routing headers help determine how a packet is routed, then this allows individual fragments to be routed without having to do any form a reassembly at each hop and without requiring nodes to keep state for a stream of IP packet fragments. This advantage could be especially useful for mesh networks with memory constrained devices. It was unclear to us how you would support such functionality cleanly in the current 6lowpan format because the prot_type field turns into the datagram_offset field in subsequent fragments. Does that clear things up a bit? -- Jonathan Hui jhui@archrock.com gabriel montenegro wrote: > Jonathan, > > > I'm confused by your paragraph below. I'm not sure what you mean by > this. The prot_type field disappearing in subsequent packets has no > bearing on extensibility as I understand it. For example, if you were > to in the future decide to carry, say, RNP ("random network protocol") > over the current lowpan encapsulation, you'd have a prot_type value > assigned for RNP. This would allow you to send RNP over lowpan even if > you had a mesh configuration underneath (the mesh delivery header being > a general lowpan layer service), or if your RNP packets were large > (by using the fragmentation service, again a general lowpan layer > service). If a receiving station were to receive, say, a fragment > for an packet, it might not be able to know that it is RNP until > more fragments arrive. But it wouldn't be able to do anything until > the entire RNP packet arrives anyways. Just like in IPv4 or v6 > fragmentation. > > Or did you have something else in mind? > > tnx, > > -gabriel > ----- Original Message ---- > In the current 6lowpan proposal, the prot_type field disappears in > packets that are subsequent fragments. Thus, the prot_type field in the > current proposal only allows extensibility in upper layer protocols and > possibly in packets that do not require fragmentation. In the current > 6lowpan proposal it wasn't clear to us how a new mesh protocol that > wanted to add a field to the header would do so in a clean way. Also, > what we were trying to convey with the "piggybacking" capability with > the stacked headers was that it was possible, not that we should promote > it. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Nov 05 13:45:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggmzx-0001AB-Pm; Sun, 05 Nov 2006 13:45:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggmzw-0001A5-Q5 for 6lowpan@ietf.org; Sun, 05 Nov 2006 13:45:36 -0500 Received: from web81907.mail.mud.yahoo.com ([68.142.207.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ggmzv-0001pG-87 for 6lowpan@ietf.org; Sun, 05 Nov 2006 13:45:36 -0500 Received: (qmail 26035 invoked by uid 60001); 5 Nov 2006 18:45:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=PfeaAO9/UMy6p2Esqq5/QlBh6+vWbLT0APgTBzOJKIGgnkIV9WtGDsMBybRM9GXoR8Eqj3fRQ35L716gmUF7YeFPcRnZE8BUW548ErDgiVFtUcKKTGKOYh266V9StEwFZu0oWnx7mWHqm0hIlCz2Iz9nE5Zwkidc88MsdW3mXx0= ; Message-ID: <20061105184534.26033.qmail@web81907.mail.mud.yahoo.com> Received: from [24.16.14.130] by web81907.mail.mud.yahoo.com via HTTP; Sun, 05 Nov 2006 10:45:34 PST Date: Sun, 5 Nov 2006 10:45:34 -0800 (PST) From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com> Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock To: Jonathan Hui <jhui@archrock.com> MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0226194166==" Errors-To: 6lowpan-bounces@ietf.org --===============0226194166== Content-Type: multipart/alternative; boundary="0-1413705422-1162752334=:24982" --0-1413705422-1162752334=:24982 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Each fragment is routed independently of each other by virtue of the mesh h= eader, right?=0AEach node forwards each individual fragment according to it= s routing table, exactly the same=0Aas for any unfragmented packet, so ther= e is no additional state for fragments as compared to=0Anon-fragments. The = only node that keeps fragments around for reassembly is the end-node, as it= =0Ais an e2e reassembly procedure (as in IPv6).=0A=0AWhat you're pointing o= ut, I think, is not a lack of extensibility per se, but a lack of=0Asupport= for source routing at the mesh header, which was a conscious decision, yes= . =0A=0AAdding support for source routing does not require one to carry the= prot_type field in=0Aeach fragment. It would require modifying the mesh de= livery header to include source routes,=0Anot just mesh origin and mesh des= tination address. =0A=0AI now see that you're doing this a bit differently.= Instead of the lowpan adaptation layer=0Ahandling source routes, you wish = to handle it as different protocol itself. =0A=0A-gabriel=0A=0A=0A----- Ori= ginal Message ----=0AFrom: Jonathan Hui <jhui@archrock.com>=0ATo: gabriel m= ontenegro <gabriel_montenegro_2000@yahoo.com>=0ACc: 6lowpan@ietf.org=0ASent= : Sunday, November 5, 2006 9:41:12 AM=0ASubject: Re: [6lowpan] Fw: any comm= ents on the proposal from Arch Rock=0A=0A=0AGabriel,=0A=0AYou are correct t= hat you can use prot_type to allow extensibility above =0Aboth the mesh and= fragmentation layer. However, I was trying to get at =0Aextensibility at l= ayers between the mesh and fragmentation. IPv6 =0Asuggests that hop-by-hop = options (e.g. a sequence number for =0Abroadcast/multicast) and routing hea= ders (for source route) should come =0Aafter addressing but before fragment= ation. If these hop-by-hop/routing =0Aheaders help determine how a packet i= s routed, then this allows =0Aindividual fragments to be routed without hav= ing to do any form a =0Areassembly at each hop and without requiring nodes = to keep state for a =0Astream of IP packet fragments. This advantage could = be especially useful =0Afor mesh networks with memory constrained devices. = It was unclear to us =0Ahow you would support such functionality cleanly in= the current 6lowpan =0Aformat because the prot_type field turns into the d= atagram_offset field =0Ain subsequent fragments.=0A=0ADoes that clear thing= s up a bit?=0A=0A--=0AJonathan Hui=0Ajhui@archrock.com=0A=0A=0Agabriel mont= enegro wrote:=0A> Jonathan,=0A> =0A> =0A> I'm confused by your paragraph b= elow. I'm not sure what you mean by=0A> this. The prot_type field disappear= ing in subsequent packets has no=0A> bearing on extensibility as I understa= nd it. For example, if you were=0A> to in the future decide to carry, say, = RNP ("random network protocol")=0A> over the current lowpan encapsulation, = you'd have a prot_type value=0A> assigned for RNP. This would allow you to = send RNP over lowpan even if=0A> you had a mesh configuration underneath (t= he mesh delivery header being=0A> a general lowpan layer service), or if yo= ur RNP packets were large=0A> (by using the fragmentation service, again a = general lowpan layer=0A> service). If a receiving station were to receive, = say, a fragment=0A> for an packet, it might not be able to know that it is = RNP until=0A> more fragments arrive. But it wouldn't be able to do anything= until=0A> the entire RNP packet arrives anyways. Just like in IPv4 or v6 = =0A> fragmentation.=0A> =0A> Or did you have something else in mind?=0A> = =0A> tnx,=0A> =0A> -gabriel=0A> ----- Original Message ----=0A> In the cur= rent 6lowpan proposal, the prot_type field disappears in=0A> packets that a= re subsequent fragments. Thus, the prot_type field in the=0A> current propo= sal only allows extensibility in upper layer protocols and=0A> possibly in = packets that do not require fragmentation. In the current=0A> 6lowpan propo= sal it wasn't clear to us how a new mesh protocol that=0A> wanted to add a = field to the header would do so in a clean way. Also,=0A> what we were tryi= ng to convey with the "piggybacking" capability with=0A> the stacked header= s was that it was possible, not that we should promote=0A> it. --0-1413705422-1162752334=:24982 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:courier, monaco, monospace, sans-serif;f= ont-size:12pt"><DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco,= monospace, sans-serif">Each fragment is routed independently of each other= by virtue of the mesh header, right?</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt= ; FONT-FAMILY: courier, monaco, monospace, sans-serif">Each node forwards e= ach individual fragment according to its routing table, exactly the same</D= IV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospac= e, sans-serif">as for any unfragmented packet, so there is no additional st= ate for fragments as compared to</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FON= T-FAMILY: courier, monaco, monospace, sans-serif">non-fragments. The only n= ode that keeps fragments around for reassembly is the end-node, as it</DIV>= =0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, = sans-serif">is an e2e reassembly procedure (as in IPv6).</DIV>=0A<DIV style= =3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">&= nbsp;</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, = monospace, sans-serif">What you're pointing out, I think, is not a lack of = extensibility per se, but a lack of</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; = FONT-FAMILY: courier, monaco, monospace, sans-serif">support for source rou= ting at the mesh header, which was a conscious decision, yes. </DIV>=0A<DIV= style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-se= rif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, mo= naco, monospace, sans-serif">Adding support for source routing does not req= uire one to carry the prot_type field in</DIV>=0A<DIV style=3D"FONT-SIZE: 1= 2pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">each fragment. It= would require modifying the mesh delivery header to include source routes,= </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monos= pace, sans-serif">not just mesh origin and mesh destination address. </DIV>= =0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, = sans-serif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: cour= ier, monaco, monospace, sans-serif">I now see that you're doing this a bit = differently. Instead of the lowpan adaptation layer</DIV>=0A<DIV style=3D"F= ONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">handli= ng source routes, you wish to handle it as different protocol itself. </DIV= >=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace,= sans-serif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: cou= rier, monaco, monospace, sans-serif">-gabriel<BR><BR></DIV>=0A<DIV style=3D= "FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">---= -- Original Message ----<BR>From: Jonathan Hui <jhui@archrock.com><BR= >To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com><BR>Cc: 6l= owpan@ietf.org<BR>Sent: Sunday, November 5, 2006 9:41:12 AM<BR>Subject: Re:= [6lowpan] Fw: any comments on the proposal from Arch Rock<BR><BR>=0A<DIV>G= abriel,<BR><BR>You are correct that you can use prot_type to allow extensib= ility above <BR>both the mesh and fragmentation layer. However, I was tryin= g to get at <BR>extensibility at layers between the mesh and fragmentation.= IPv6 <BR>suggests that hop-by-hop options (e.g. a sequence number for <BR>= broadcast/multicast) and routing headers (for source route) should come <BR= >after addressing but before fragmentation. If these hop-by-hop/routing <BR= >headers help determine how a packet is routed, then this allows <BR>indivi= dual fragments to be routed without having to do any form a <BR>reassembly = at each hop and without requiring nodes to keep state for a <BR>stream of I= P packet fragments. This advantage could be especially useful <BR>for mesh = networks with memory constrained devices. It was unclear to us <BR>how you = would support such functionality cleanly in the current 6lowpan <BR>format = because the prot_type field turns into the datagram_offset field <BR>in sub= sequent fragments.<BR><BR>Does that clear things up a bit?<BR><BR>--<BR>Jonathan H= ui<BR>jhui@archrock.com<BR><BR><BR>gabriel montenegro wrote:<BR>> Jonath= an,<BR>> <BR>> <BR>> I'm confused by your paragraph bel= ow. I'm not sure what you mean by<BR>> this. The prot_type field disappe= aring in subsequent packets has no<BR>> bearing on extensibility as I un= derstand it. For example, if you were<BR>> to in the future decide to ca= rry, say, RNP ("random network protocol")<BR>> over the current lowpan e= ncapsulation, you'd have a prot_type value<BR>> assigned for RNP. This w= ould allow you to send RNP over lowpan even if<BR>> you had a mesh confi= guration underneath (the mesh delivery header being<BR>> a general lowpa= n layer service), or if your RNP packets were large<BR>> (by using the f= ragmentation service, again a general lowpan layer<BR>> service). If a r= eceiving station were to receive, say, a fragment<BR>> for an packet, it= might not be able to know that it is RNP until<BR>> more fragments arrive. But it wo= uldn't be able to do anything until<BR>> the entire RNP packet arrives a= nyways. Just like in IPv4 or v6 <BR>> fragmentation.<BR>> = <BR>> Or did you have something else in mind?<BR>> <BR>>= ; tnx,<BR>> <BR>> -gabriel<BR>> ----- Original Message = ----<BR>> In the current 6lowpan proposal, the prot_type field disappear= s in<BR>> packets that are subsequent fragments. Thus, the prot_type fie= ld in the<BR>> current proposal only allows extensibility in upper layer= protocols and<BR>> possibly in packets that do not require fragmentatio= n. In the current<BR>> 6lowpan proposal it wasn't clear to us how a new = mesh protocol that<BR>> wanted to add a field to the header would do so = in a clean way. Also,<BR>> what we were trying to convey with the "piggy= backing" capability with<BR>> the stacked headers was that it was possib= le, not that we should promote<BR>> it.</DIV></DIV>=0A<DIV style=3D"FONT-SIZE: 12pt;= FONT-FAMILY: courier, monaco, monospace, sans-serif"><BR></DIV></div></bod= y></html> --0-1413705422-1162752334=:24982-- --===============0226194166== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0226194166==-- From 6lowpan-bounces@ietf.org Sun Nov 05 15:45:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgosQ-00030Q-1f; Sun, 05 Nov 2006 15:45:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgosO-00030D-Eq for 6lowpan@ietf.org; Sun, 05 Nov 2006 15:45:56 -0500 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgosM-00074c-WB for 6lowpan@ietf.org; Sun, 05 Nov 2006 15:45:56 -0500 Received: by secure.archedrock.com (Postfix, from userid 101) id 6E6F616B0001; Sun, 5 Nov 2006 12:45:52 -0800 (PST) Received: from [127.0.0.1] (adsl-71-142-86-178.dsl.pltn13.pacbell.net [71.142.86.178]) by secure.archedrock.com (Postfix) with ESMTP id 7646A16B0001; Sun, 5 Nov 2006 12:45:51 -0800 (PST) Message-ID: <454E4D7E.4030307@archrock.com> Date: Sun, 05 Nov 2006 12:45:50 -0800 From: Jonathan Hui <jhui@archrock.com> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com> Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock References: <20061105184534.26033.qmail@web81907.mail.mud.yahoo.com> In-Reply-To: <20061105184534.26033.qmail@web81907.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.0.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Errors-To: 6lowpan-bounces@ietf.org What I'm arguing is that there are times where only addressing is not enough. This was made clear by the addition of the B-bit in the 6lowpan adaptation header, which required changing the 6lowpan adaptation header for subsequent fragments because there were no additional reserved bits. My argument is that the current adaptation header is relatively unforgiving if for some unforseen reason that the 8-bit additional field given by setting the B-bit is not enough. Specifically for broadcast/multicast protocols, it restricts them to using an 8-bit field for whatever extra information they might need. I'm not comfortable with making such a bold statement, maybe others are. But once the 6lowpan header format has been standardized and adopted widely, it becomes very difficult for us to simply modify the header again. In my view, having the ability to specify header stacks provides a clean way of extending the header, whether or not you view the entire header stack as an adaptation header or as a set of separate protocols below the IP layer. -- Jonathan Hui jhui@archrock.com gabriel montenegro wrote: > Each fragment is routed independently of each other by virtue of the > mesh header, right? > Each node forwards each individual fragment according to its routing > table, exactly the same > as for any unfragmented packet, so there is no additional state for > fragments as compared to > non-fragments. The only node that keeps fragments around for reassembly > is the end-node, as it > is an e2e reassembly procedure (as in IPv6). > > What you're pointing out, I think, is not a lack of extensibility per > se, but a lack of > support for source routing at the mesh header, which was a conscious > decision, yes. > > Adding support for source routing does not require one to carry the > prot_type field in > each fragment. It would require modifying the mesh delivery header to > include source routes, > not just mesh origin and mesh destination address. > > I now see that you're doing this a bit differently. Instead of the > lowpan adaptation layer > handling source routes, you wish to handle it as different protocol itself. > > -gabriel > > ----- Original Message ---- > From: Jonathan Hui <jhui@archrock.com> > To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com> > Cc: 6lowpan@ietf.org > Sent: Sunday, November 5, 2006 9:41:12 AM > Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock > > Gabriel, > > You are correct that you can use prot_type to allow extensibility above > both the mesh and fragmentation layer. However, I was trying to get at > extensibility at layers between the mesh and fragmentation. IPv6 > suggests that hop-by-hop options (e.g. a sequence number for > broadcast/multicast) and routing headers (for source route) should come > after addressing but before fragmentation. If these hop-by-hop/routing > headers help determine how a packet is routed, then this allows > individual fragments to be routed without having to do any form a > reassembly at each hop and without requiring nodes to keep state for a > stream of IP packet fragments. This advantage could be especially useful > for mesh networks with memory constrained devices. It was unclear to us > how you would support such functionality cleanly in the current 6lowpan > format because the prot_type field turns into the datagram_offset field > in subsequent fragments. > > Does that clear things up a bit? > > -- > Jonathan Hui > jhui@archrock.com > > > gabriel montenegro wrote: > > Jonathan, > > > > > > I'm confused by your paragraph below. I'm not sure what you mean by > > this. The prot_type field disappearing in subsequent packets has no > > bearing on extensibility as I understand it. For example, if you were > > to in the future decide to carry, say, RNP ("random network protocol") > > over the current lowpan encapsulation, you'd have a prot_type value > > assigned for RNP. This would allow you to send RNP over lowpan even if > > you had a mesh configuration underneath (the mesh delivery header being > > a general lowpan layer service), or if your RNP packets were large > > (by using the fragmentation service, again a general lowpan layer > > service). If a receiving station were to receive, say, a fragment > > for an packet, it might not be able to know that it is RNP until > > more fragments arrive. But it wouldn't be able to do anything until > > the entire RNP packet arrives anyways. Just like in IPv4 or v6 > > fragmentation. > > > > Or did you have something else in mind? > > > > tnx, > > > > -gabriel > > ----- Original Message ---- > > In the current 6lowpan proposal, the prot_type field disappears in > > packets that are subsequent fragments. Thus, the prot_type field in the > > current proposal only allows extensibility in upper layer protocols and > > possibly in packets that do not require fragmentation. In the current > > 6lowpan proposal it wasn't clear to us how a new mesh protocol that > > wanted to add a field to the header would do so in a clean way. Also, > > what we were trying to convey with the "piggybacking" capability with > > the stacked headers was that it was possible, not that we should promote > > it. > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Nov 05 18:09:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggr7L-0003BK-I5; Sun, 05 Nov 2006 18:09:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggr7K-0003BF-L0 for 6lowpan@ietf.org; Sun, 05 Nov 2006 18:09:30 -0500 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggr7H-0007iU-Os for 6lowpan@ietf.org; Sun, 05 Nov 2006 18:09:30 -0500 Received: by nf-out-0910.google.com with SMTP id n29so1093831nfc for <6lowpan@ietf.org>; Sun, 05 Nov 2006 15:09:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bbIQz/P10/Bieg2zHfD+mt/NF4VjJs9PD37q2ZlCly5tZo6xKmFethT7BHuyHuge8pKLJie2k6jh7OR4tCfp7zFSNaXjDqX9WtGZAQkwOmACuPYkepYDSYIgO1Eg0Mw2SUiTYwB4218zLv61U6eBwK07i/OYlDa6UlB4phOXwjk= Received: by 10.82.147.6 with SMTP id u6mr612812bud.1162768166367; Sun, 05 Nov 2006 15:09:26 -0800 (PST) Received: by 10.82.182.18 with HTTP; Sun, 5 Nov 2006 15:09:26 -0800 (PST) Message-ID: <43b91d370611051509u3dd8d25bi30f51d2b5a522fbf@mail.gmail.com> Date: Sun, 5 Nov 2006 15:09:26 -0800 From: "Samita Chakrabarti" <samitac2@gmail.com> To: "Mario Mao" <mariomao@gmail.com> Subject: Re: [6LoWPAN] Router Dynamic Advertisement Algorithm (RDA) In-Reply-To: <015501c6fbef$5582aa60$7fc0a8c0@netlab.cs.ecnu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <015501c6fbef$5582aa60$7fc0a8c0@netlab.cs.ecnu.edu.cn> X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Errors-To: 6lowpan-bounces@ietf.org Hi Mario, Please see my comments below. > By confirming with Gabriel, I would update some results of our team's work > on 6LoWPAN, please take it as a reference and give any comment needed, > thanks. > Did you also have an implementation of our 6lowpan-ipv6-nd draft ? > Basically, our team's work follows drafts prompted by WG. however, we find > something should be included when implementing. Below is one of the things > beyond draft: Router Dynamic Advertisement Algorithm (RDA). > > For Chakrabarti, I know it is a really different way from the optimization > in draft 6lowpan-ipv6-nd. But when we design and implement the 6LoWPAN > stack, we did find it is effective and easier to implement. Hope the idea in > this mail could do some help, thanks. > Are you saying that you implemented RDA algorithm instead ? How did you use multicast and controlled flooding at the link-layer(802.15.4) ? Have you used a simulation or set of real sensors to implement and take measurements? The main idea of our 6lowpan-nd draft is to minimize the broadcast or all-node multicast messages to the low-powered nodes in order to save energy while maintaining the efficiency of the initiating node. Thus we optimize for unicast messaging and sometimes use the existing algorithm in IPv6 ND - so it should be simple to implement. The idea could be applicable beyond 6lowpan scenarios, i.e to any network that wants to run energy-efficient IPv6 ND protocol. Thanks, -Samita > =========================== > > Router Discovery, Prefix and Parameter Discovery need RS and RA message > defined in NDP. In LoWPAN environment, we need avoid the power consuming > caused by broadcasting these kinds of message periodically. On the other > hand, it is not a good idea to simply increase the announcement interval to > a large value. It would make the network insensitive and lead some child > nodes inaccessible before they could configure a ipv6 global address. To > balance them, Host and Router use Router Dynamic Advertisement Algorithm > (RDA) to send RS and RA. > > 1. Assumption > > In our environment, we don't conside IPv6 routers would be known by all > sensor nodes before they get their announcement explicitly. This > consideration would work for multiple sink scenario. There could be more > than one sink (router) to balance the load around sink (router). So, Host > need to send Mulitcast RS or wait for RA. > > To support IP multicast, broadcast ability in adaptation layer should be > included. We have introduced a controlled flooding mechanism to supply such > kind of requirment. You could get the mean idea in the mail before, I > remember I have sent it to mail list about 3 months ago. > > At last, there will be a little change to RFC2461 on the RA announcement > interval, not more, but do have. Will it be a big problem? Our > implementation support both the two way of RA sending algotithm in a single > Router, one for standard, one for LoWPAN. People could confiure interface to > use any of them, that means, no conflict between two different links, eg. > standard for Ethernet and RDA for IEEE 802.15.4. Our test show the Route and > Host would work fine when enable two advertising interfaces which use > different advertising algorithm. > > 2. Host > > When Host starts up, it hold the initial multicast RS until TIME_WAIT_FOR_RA > elapseed. If Host still miss the wanted RA, a multicast RS should be sent > out. For TIME_WAIT_FOR_RA, it is a random value between BASE_RA_INTERVAL and > 2*BASE_RA_INTERVAL. Another, the source address of RS should use unicast > address but not ::, that make Router could unicast the RA message back to > Host. > > For application that want immediate access to every sensor node, > TIME_WAIT_FOR_RA could use another smaller value which let RA received > quickly. However, for most WSN applications that haven't such kind of > requirement, 10 - 20 minutes wait time may acceptable. > > 3. Router > > Route would no longer use a relatively fixed interval to send Unsolicited > RA. As soon as one interface of Router is confiured as an Advertising > Interface, the interval of sending RA would be calculated by RDA. The > constants and variables maintained as follow: > > BASE_RA_INTERVAL: the basal interval of sending RA, recommended value is > 10min. > MAX_RA_FACTOR: the maxium RA factor, recommended value is 5-6. > a: RA factor. > interval: current RA interval. > timeToAdv: the time to sending next RA. > sendTimes: the times of sending RA using the same interval. > recvRSTimes: the times of receiveing RS packet between two unsolicited > RA. > > > The algorithm comes below, the basic idea is increasing the advertising > interval to long when topology is stable and decreasing to short when the > network become wavy: > > (1). When advertising interface initializes, let a = 0$B!$(Binterval = > BASE_RA_INTERVAL*2^a$B!$(BsendTimes = a+1$B!$(BrecvRSTimes = 0$B!$(BtimeToAdv = interval. > > (2). > - (a) When interval time elapsed (that means timeToAdv is decreased to 0), > send a Multicast Unsolicited RA and let recvRSTimes = 0; > - (b) If sendTimes > 0 and a < MAX_RA_FACTORIAL, substracte sendTimes by 1; > if sendTimes is decreased to 0, let a = a+1 and recalculate sendTimes with > the formula in (1); > - (c) Recalculate interval with the formula in (1), let timeToAdv = > interval, wati for sending next RA. > > (3). > - (a) If Router received a valid RS, let a = a/2, recvRSTimes = > recvRSTimes+1, sendTimes = a+1; > - (b) Recalculate current timeToAdv: if a is even before receiving RS, let > timeToAdv = timeToAdv/2^a [see annotation 1]; if it is odd, let timeToAdv = > timeToAdv/2^(a+1) [see annotation 2]; > - (c) if recvRSTimes < 3, send Unicast Solicited RA with the way defined in > RFC2461; if recvRSTimes = 3, let timeToAdv = 0, send a Multicast Solicited > RA immediately and carry out all relative operation in (2); if recvRSTimes > > 3, nothing else need to do (it is possible Router receive a new RS before > the scheduled RA sending out, so just let Hosts wait for the scheduled > Multicast RA). > > [Annotation 1] > timeToAdv = timeToAdv * (newInterval / oldInterval) > = timeToAdv * (BASE_RA_INTERVAL*2^a / > BASE_RA_INTERVAL*2^(2a) ) > = timeToAdv * 2^(-a) > = timeToAdv / 2^a > [Annotation 2] > timeToAdv = timeToAdv * (newInterval / oldInterval) > = timeToAdv * (BASE_RA_INTERVAL*2^a / > BASE_RA_INTERVAL*2^(2a+1) ) > = timeToAdv * 2^(-(a+1)) > = timeToAdv / 2^(a+1) > > > When advertising interface use RDA, Host will not send RS but wait for > possible RA when it startup. If it get nothing within TIME_WAIT_FOR_RA, a RS > would be sent out to solicit RA. This process could reduce the broadcast > flow of RS when Hosts bootstrap. Meanwhile, Router would send multicast RA > with a small interval at the begining and increase the sending interval > gradually. That could satisfy the requirement for RA from Host when 802.15.4 > nodes constructing network. For TIME_WAIT_FOR_RA is a random value between > BASE_RA_INTERVAL and 2*BASE_RA_INTERVAL, it is highly possible that most of > the Hosts needn't to send RS when nodes in the same PAN start to construct > network topology. After the topology has been stable (most of nodes have > joined into the PAN), interval of RA will increase to a large value which > alleviate the energy wastage by broadcasting RA message frequently. > > When the network become unstable (eg. some nodes lose synchronization with > beacon, they would start orphan scan and try to re-join the network. At this > time, node might need to request a new RA message for address > autoconfiguration) or new node try to join PAN, Host would send RS to > Router. Router answer the solicitation with Unicast RA and reduce RA > interval exponentially to response the change of network rapidly. If the PAN > is suffering a serious undulation (eg. a parent node with several children > or grandchildren failed, all of children need to re-join the network. The > result of this scenario is lots of RS messages appearing on the channel), > Router response this situation by sending a Multicast RA immediately as soon > as more than 3 RS received between two adjacent unsolicited RA. Now, RA > factor and RA interval have decreased to small value, Router begin to send > RA frequently and enters a fast advertising period to accommodate the change > of network. > > When network topology comes stable after gone through the wavy period, RA > interval would increase again with the RA factor. At last, it reachs a large > enough value and enters the slow advertising period. > > Below table show the change of RA interval (BASE_RA_INTERVAL = 10 > min$B!$(BMAX_RA_FACTOR = 6). RA interval will increase to 10.3h if the network > topology stays stable (it is also the character of WSN: topology wouldn't > take frequent change after the initial network organization). Such a long > interval only take little negative effect to the power consumption. > ===================================================== > a interval sendTimes Time to achieve the intvl > 0 10m 1 0 > 1 20m 2 10m > 2 40m 3 50m > 3 80m 4 2.8h > 4 160m 5 8.2h > 5 320m 6 21.5h > 6 640m 7 53.5h > ===================================================== > > > Regards, > > Mario Mao > MarioMao@Gmail.com > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Nov 05 18:26:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgrNW-0005Li-Of; Sun, 05 Nov 2006 18:26:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgrNV-0005LR-4Z for 6lowpan@lists.ietf.org; Sun, 05 Nov 2006 18:26:13 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgrNR-0001Jy-L4 for 6lowpan@lists.ietf.org; Sun, 05 Nov 2006 18:26:13 -0500 Received: by nf-out-0910.google.com with SMTP id c2so523878nfe for <6lowpan@lists.ietf.org>; Sun, 05 Nov 2006 15:26:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ogblVclwVapip5hyu3fL5cbw4x77mkcKHrnFLgwA0qLDdEZRV2TRRduqP4SD714Rb20FsCfe/xQTAbdtGRWtgunMLmVIBcdjP9mnuuetbCvPFzvzeZmuZ4H3C4fh2upY9Dt0qWOya0+tRAYp+4z8mQPRu3qBZSm+bpd6HlghvY4= Received: by 10.82.129.5 with SMTP id b5mr1173333bud.1162769167956; Sun, 05 Nov 2006 15:26:07 -0800 (PST) Received: by 10.82.182.18 with HTTP; Sun, 5 Nov 2006 15:26:07 -0800 (PST) Message-ID: <43b91d370611051526k167d3735s3e98f609ef34ae65@mail.gmail.com> Date: Sun, 5 Nov 2006 15:26:07 -0800 From: "Samita Chakrabarti" <samitac2@gmail.com> To: "Carsten Bormann" <cabo@tzi.org> Subject: Re: [6lowpan] 6lowpan Architecture Questions In-Reply-To: <FEA60A59-652E-42DA-B482-48AF7B6D1960@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <002801c6f9d1$33c16030$6501a8c0@RonStrich> <FEA60A59-652E-42DA-B482-48AF7B6D1960@tzi.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Errors-To: 6lowpan-bounces@ietf.org Hi Carsten, Ron and all: Agree, it is a good point that we did not clearly discuss the topology for 6lowpan architecture. During 6lowpan-nd discussion, we discussed and agreed on different supporting topologies for 6lowpan ( both at interim 05 and at Dallas IETF meeting). Section 4 of 6lowpan-nd draft captures that text (see below). If we decide to have a separate architecture document, then we can use these portion of the text. ---------------------------------------------------------------------------= ------------------ 4. Assumptions about Topology and Address Mapping In order to minimize the multicast packets we need to make some assumptions that tie together the L2 functional elements and the L3 functional elements. We also state our understanding of how IPv6 would map to a LowPan network: o One PAN-ID defines one LowPan Network. o Each LowPan corresponds to one IPv6 subnet as PAN-ID may be used to determine a subnet. o There is one PAN co-ordinator or PAN group leader per one LowPan. o The IPv6 router which sits in the boundary of the LowPan is a PAN co-ordinator. o There can be multiple co-ordinators in the LowPan. o When a device connects to the LowPan at layer 2, it finds out a (unicast) layer 2 address for its co-ordinator. o By recursive construction, the previous item implies that a co- ordinator knows its co-ordinator from when it connected to the LowPan, hence there is distributed knowledge of unicast addresses that lead all the way to the PAN co-ordinator. o The IPv6 router assigns addresses through prefix advertisement. o The other FFDs in the network do not act as a IPv6 router, but they generally route data packet in the L2 layer (Mesh layer routing). o Star topology assumes that each node is one hop away from the PAN co-ordinator. o This document defines a mesh topology (see diagram below). In mesh topology, each node is capable of forwarding. Thus it can be assumed as a network of full functional devices (FFDs) with one PAN co-ordinator and multiple co-ordinators. Chakrabarti & Nordmark Expires December 26, 2006 [Page 6] =0C Internet-Draft LowPan Neighbor Discovery Extensions June 2006 o FFDs may or may not be more than one hop away from the PAN co- ordinator. o We assume that the 64-bit EUI-64 addresses are used as link-layer address in the lowpan, since these addresses never change for a given node. Appendix A discusses some additional considerations should we apply this to the 16-bit addresses. This document currently supports the following topologies: 1) Star Topology PAN-C O / | \ o o o <------- RFDs or FFDs 2) Mesh Topology Example-1 Example-2 O PAN-C O <-- PAN-C / | \ o / | \ / | \ / / | \ FFD----FFD----- FFD FFD--FFD-----FFD \ |\ / \ \ | \ /| \ | \ /| o \ | \ / | \ | \ / | \ | \/ | \ | \ / | \ | /\ | \ | \ | \| / \ | \| / \ | |/ \| FFD \ | FFD FFD / | \ FFD o 0 o / \ o o <--RFDs Each FFD may act as simple co-ordinators but there is only one PAN co-ordinator in the mesh LowPan topology. ------------------------------------ Thanks, -Samita On 10/27/06, Carsten Bormann <cabo@tzi.org> wrote: > Ron, > > good input. > > Let me just pick up on one of these points: > > The IETF is quite wary about "architecture" documents. > > (The OSI reference model is the textbook example here: > ISO did an architecture ["reference model"], and then, only when > defining the protocols, found out that the architecture didn't make > sense. > But it was too late to fix the architecture, so the bad layers limped > on until OSI finally died. > The really funny thing, of course, is that, in 2006, people are > *still* citing the layers of the defunct reference model...) > > In the IETF, we tend to standardize functional components and leave > it to the market how to build "architectures" out of these. > Of course, that is not always possible. > Also, it may be necessary to have an (really: one or more) > architectures in mind when building components. > > So, I'd welcome discussion of architecture(s). I'm just not sure we > actually want to "standardize" them. > > Gruesse, Carsten > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Nov 06 01:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggy5b-0000ol-Hu; Mon, 06 Nov 2006 01:36:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggy5Z-0000nk-EC for 6lowpan@lists.ietf.org; Mon, 06 Nov 2006 01:36:09 -0500 Received: from mxmss0.kpost.com ([211.117.63.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggy08-0003JU-FI for 6lowpan@lists.ietf.org; Mon, 06 Nov 2006 01:30:38 -0500 Received: from richfafa ([124.63.25.40]) by mxmss0.kpost.com with ESMTP id <20061106063017.EJB25243.mxmss0@richfafa>; Mon, 6 Nov 2006 15:30:17 +0900 From: "Lee Jung-Hwan" <john@ibitworld.com> To: "'Geoff Mulligan'" <geoff@mulligan.com> Subject: RE: [6lowpan] Proposal for alternative 6lowpan header encoding Date: Mon, 6 Nov 2006 15:30:16 +0900 Message-ID: <01e301c7016d$06c67180$4101a8c0@richfafa> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb/ovgrgi5tdgMOQKKEOPtGGmH+jQBx8OJw In-Reply-To: <1162597742.5112.28.camel@localhost> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: '6lowpan' <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Errors-To: 6lowpan-bounces@ietf.org Folks, I am Jung-Hwan Lee working for iBIT technologies, Inc in south of korea and in charge of USN R & D. our company has being implemented and tested usn modules and gateway with 6lowpan functionality & IPv6 protocol stack. but, in progress usn modules and gateway, we have several problems. for examples, - byte alignment - 6lowpan <-> IPv6 header translation - and so on The ppt files that written by David and Jonathan is so simple and impressive from the viewpoint of implementor. Thanks for your paper. -----Original Message----- From: Geoff Mulligan [mailto:geoff@mulligan.com] Sent: Saturday, November 04, 2006 8:49 AM To: 6lowpan Subject: [6lowpan] Proposal for alternative 6lowpan header encoding Folks, Arch Rock have submitted a proposal for a different 6lowpan header encoding. David and Jonathan put together a set a slides to describe their idea to simplify the 6lowpan adaptation header. They are working on a complete proposal. I have posted the slides to the wiki at: http://6lowpan.tzi.org/FrontPage?action=AttachFile&do=get&target=6lowpan-hea der-proposal.ppt You can also get a copy (if you are wiki challenged) at: http://www.mulligan.com/6lowpan/6lowpan-header-proposal.ppt Their design seems to follow the ideas of IPv6, reduce the header size in almost all cases, allow for extensions, byte align the fields and as I've thought about coding it, it looks like less complex parsing. While a proposal such as this (ideas tend to come on their own schedule) at this late stage in our process will be disruptive, the potential value of simplifying and fixing some of the identified problems in the current design is, in my opinion, worth the time and effort and risk to our already blown schedule to evaluate and discuss within the group. Please take a look at the slides. We only a have few days before the meeting on Wednesday and if possible I would like to hear peoples thoughts. I have asked Jonathan and David to attend the WG meeting and to prepare a more in-depth presentation related to this new design. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Nov 06 03:34:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggzvq-0007Nl-Kz; Mon, 06 Nov 2006 03:34:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggzvp-0007N4-7O for 6lowpan@ietf.org; Mon, 06 Nov 2006 03:34:13 -0500 Received: from nz-out-0102.google.com ([64.233.162.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggzvn-0004wx-3T for 6lowpan@ietf.org; Mon, 06 Nov 2006 03:34:13 -0500 Received: by nz-out-0102.google.com with SMTP id 13so845667nzn for <6lowpan@ietf.org>; Mon, 06 Nov 2006 00:34:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:to:cc:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole:from; b=gxEmzWIGIXLkzZ3IkFUtEpwrqCz07OjKpdQGDoLyw5kjuWEnkiS2ECiJsKiDAqGs+Gh+V4C5xrM6Mn+tI4verYisci5TtzFsn5e5hwDo0RLROUTCv9AQ3vLmlbuoZrgoa2xCt7ROx8B6Zgi+/J2f2iOEebR1cqxFbODNLTao3SI= Received: by 10.65.84.6 with SMTP id m6mr7413600qbl.1162802050305; Mon, 06 Nov 2006 00:34:10 -0800 (PST) Received: from Maoer ( [211.144.102.60]) by mx.google.com with ESMTP id 18sm17169862nzo.2006.11.06.00.34.04; Mon, 06 Nov 2006 00:34:10 -0800 (PST) Message-ID: <006101c7017e$86299e50$7fc0a8c0@netlab.cs.ecnu.edu.cn> To: "Samita Chakrabarti" <samitac2@gmail.com> References: <015501c6fbef$5582aa60$7fc0a8c0@netlab.cs.ecnu.edu.cn> <43b91d370611051509u3dd8d25bi30f51d2b5a522fbf@mail.gmail.com> Subject: Re: [6LoWPAN] Router Dynamic Advertisement Algorithm (RDA) Date: Mon, 6 Nov 2006 16:35:19 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 From: Mario Mao <mariomao@gmail.com> X-Spam-Score: 1.2 (+) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1709829127==" Errors-To: 6lowpan-bounces@ietf.org --===============1709829127== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGkgQ2hha3JhYmFydGksDQoNClRoYW5rcyBmb3IgeW91IGZlZWRiYWNrLg0KDQo+IERpZCB5b3Ug YWxzbyBoYXZlIGFuIGltcGxlbWVudGF0aW9uIG9mIG91ciA2bG93cGFuLWlwdjYtbmQgZHJhZnQg Pw0KDQpXZSBkb24ndCBpbXBsZW1lbnQgNmxvd3Bhbi1pcHY2LW5kIGRyYWZ0LiBBY3R1YWxseSwg d2UgZGlkIGNvbnNpZGVyIHRoZSA2bG93cGFuLWlwdjYtbmQgbWV0aG9kIGNhcmVmdWxseSB3aGVu IGRlc2lnbmluZy4gSG93ZXZlciwgYWZ0ZXIgZXZhbHVhdGlvbiwgd2UgY29uc2lkZXJlZCB0aGVy ZSBhcmUgc29tZSBwcm9ibGVtIHRvIGltcGxlbWVudCBpdC4gRm9yIGV4YW1wbGUsDQoNCkNvZGUg c3BhY2UgbGltaXRhdGlvbjogdGhlIE1DVSB3ZSB1c2UgaGF2ZSBhcm91bmQgMjdrIGZyZWUgZm9y IEFkYXB0YXRpb24gTGF5ZXIsIElQdjYvTkQsIFRDUC9VRFAgYW5kIGFwcGxpY2F0aW9uLiBGdWxs IGltcGxlbWVudGF0aW9uIG9mIDZsb3dwYW4taXB2Ni1uZCAoZXNwZWNpYWwgYWRkcmVzcyByZXNv bHV0aW9uKSB3aWxsIG5lZWQgYSBsb3Qgb2YgY29kZSBzcGFjZSwgbm9ybWFsIHNlbnNvciBub2Rl IGNvdWxkbid0IGFmZm9yZCBpdC4gDQoNCkFub3RoZXIsIHRoZXJlIHN0aWxsIG5lZWRzIHNvbWUg b3RoZXIgbWVjaGFuaXNtIGJleW9uZCBkcmFmdCdzIGRlZmluaXRpb24sIGFzIGFuIGluc3RhbmNl LCBzZWUgc2VjdGlvbiA1LjEsIA0KDQoiSW4gYSBtZXNoIHRvcG9sb2d5LCB3aGVuIHN1Y2ggYSBw YWNrZXQgaXMgcmVjZWl2ZWQgYnkgYSBjby1vcmRpbmF0b3IsIGl0IHdpbGwgbG9vayBhdCB0aGUg SVB2NiBoZWFkZXIgYW5kIGlmIHRoYXQgaXMgZGVzdGluZWQgdG8gdGhlIGFsbC1yb3V0ZXJzIElQ djYgbXVsdGljYXN0IGFkZHJlc3MsIHRoZW4gaXQgd2lsbCByZWxheSB0aGF0ICBwYWNrZXQgKHdp dGhvdXQgZGVjcmVtZW50aW5nIHRoZSBJUHY2IGhvcCBsaW1pdCkgdG8gaXRzIGNvLW9yZGluYXRv ci4gVGhpcyB3aWxsIGRlbGl2ZXIgdGhlIFJTIHRvd2FyZHMgdGhlIFBBTiBjby1vcmRpbmF0b3Iu Ig0KDQpXaGVuIG1lc2ggZGVsaXZlcnksIG1lZGktbm9kZSBuZWVkIHRvIGNoZWNrIHRoZSBJUHY2 IGhlYWRlciB0byBkZWNpZGUgaG93IHRvIGZvcndhcmQgZnJhbWVzLiBUaGVyZSBtdXN0IGJlIG1v cmUgY29kZSB0byBpbXBsZW1lbnQgc3VjaCBhIGFkYXB0YXRpb24tbGF5ZXIgcm91dGUgYWxnb3Jp dGhtIGFuZCBtYWtlIGFkYXB0YXRpb24tbGF5ZXIgdG9vIGNvbXBsZXguIE1vcmVvdmVyLCBob3cg YWJvdXQgdGhlIElQdjYgaGVhZGVyIGNvbXByZXNzaW9uLCBzaG91bGQgZXZlcnkgbWVkaS1ub2Rl IGRvIHRoZSBoZWFkZXIgZGVjb21wcmVzc2lvbiBiZWZvcmUgZGVjaWRpbmcgaG93IHRvIGZvcndh cmQgYSBmcmFtZT8NCg0KQXQgbGFzdCwgdGhlcmUgYXJlIHNvbWUgYXNzdW1wdGlvbnMgbGlrZSAi UEFOIGNvLW9yZGluYXRvciBpcyBhbHNvIHRoZSBJUHY2IHJvdXRlciIsIGluIHRoZSBtYWlsIGJl Zm9yZSwgSSBkZXNjcmliZSB0aGUgcmVhc29uIHdoeSB3ZSBjYW4ndCBhY2NlcHQgaXQgKG11bHRp cGxlIHNpbmsgc2NlbmFyaW8pLiBTbywgd2UgaGF2ZSB0byBnaXZlIHVwIDZsb3dwYW4taXB2Ni1u ZCBhbmQgdHJ5IHRvIGZpbmQgYW5vdGhlciB3YXkuDQoNCj4gQXJlIHlvdSBzYXlpbmcgdGhhdCB5 b3UgaW1wbGVtZW50ZWQgUkRBIGFsZ29yaXRobSBpbnN0ZWFkID8gIEhvdyBkaWQNCj4geW91IHVz ZSBtdWx0aWNhc3QgYW5kIGNvbnRyb2xsZWQgZmxvb2RpbmcgYXQgdGhlIGxpbmstbGF5ZXIoODAy LjE1LjQpDQo+ID8gSGF2ZSB5b3UNCj4gdXNlZCBhIHNpbXVsYXRpb24gb3Igc2V0IG9mIHJlYWwg c2Vuc29ycyB0byBpbXBsZW1lbnQgYW5kIHRha2UgbWVhc3VyZW1lbnRzPw0KDQpZZXMsIHJlYWwg c2Vuc29ycyB3b3JrIGluIG91ciBlbnZpcm9ubWVudC4gVGhlIG11bHRpY2FzdCBhbmQgY29udHJv bGxlZCBmbG9vZGluZyBoYXZlIGJlZW4gZ2l2ZW4gb3V0IHNvbWUgZGF5cyBiZWZvcmUsIHRoYXQn cyBhbHNvIHRoZSByZWFzb24gd2h5IHdlIGhhdmUgdGhlICJCIiBiaXQgYXJndW1lbnQgcmVjZW50 bHkuIFBsZWFzZSBzZWUgaXQgYmVsb3csIEkgY3V0IGl0IGZyb20gdGhlIHByZXZpb3VzIG1haWwg KHRoZXJlIGFyZSBzb21lIGNoYW5nZSwgYnV0IG1haW4gaWRlYSBpcyBzdGFibGUpLiANCg0KUm91 dGVyID0gY28tb3JkaW5hdG9yDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT0NClRoZSBmbG9v ZGluZyB3YXkgaXMgc2ltcGxlOiBhbGwgSVAgcGFja2V0IHdpdGggbXVsdGljYXN0IGRlc3RpbmF0 aW9uIGFkZHJlc3Mgd2lsbA0KIGJlIGVuY2Fwc3VsZWQgaW4gYW4gYWRhcHRhdGlvbiBCcm9hZGNh c3QgRnJhbWUuIEhvd2V2ZXIsIHRoZSBmb3JtYXQgb2YgDQphZGFwdGF0aW9uIEJyb2FkY2FzdCBG cmFtZSBpcyBzb21ld2hhdCBkaWZmZXJlbnQgZnJvbSB0aGUgc3RhbmRhcmQgaGVhZGVyIA0KZm9y bWF0LiBUaGUgbW9kaWZpZWQgZm9ybWF0IHNob3dlZCBiZWxvdy4NCg0KICAgICAgICAgICAgICAg IDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogIDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogfCBMRnwgIHByb3RfdHlwZSAgICB8TXxCfCByc3YgICB8UGF5bG9hZCAob3IgTUQv QnJvYWRjYXN0IEhkcikuLi4NCiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQpBcyB0aGUgZmlndXJlIHNob3dlZCwgYSAi QiIgYml0IGlzIGFkZGVkKHJlcGxhY2luZyBvbmUgcnN2IGJpdCkuIFdoZW4gdGhlICJCIiANCmJp dCBpcyBzZXQsIGEgQnJvYWRjYXN0IEZpZWxkIHdpbGwgYmUgaW5jbHVkZWQgaW4gdGhlIGZyYW1l IGltbWVkaWF0ZWx5IGZvbGxvd2luZw0KIHRoZSBMb1dQQU4gaGVhZGVyLiBJZiB0aGVyZSBpcyBh IEJyb2FkY2FzdCBGaWVsZCwgd2Ugd2lsbCBjYWxsIHRoZSANCmFkYXB0YXRpb24gZnJhbWUgYXMg YSBCcm9hZGNhc3QgRnJhbWUuIFRoZSAiQnJvYWRjYXN0IiBmaWVsZCBpcyBkZWZpbmVkIGFzIA0K Zm9sbG93cw0KDQogICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg ICAgICAgICAgIDMNCiAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogIHxTfEJyb2FkIFJhZGl1cyB8U2Vx dWVuY2UgTnVtYmVyfFNvdXJjZSBBZGRyZXNzLCBmb2xsb3dlZCBieS4uLg0KICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K DQpTOiAwIGlmIHVzZSBFVUktNjQgYWRkcmVzcywgb3IgMSBpZiB1c2UgMTYtYml0IGFkZHJlc3Mu DQpCcm9hZCBSYWRpdXM6IEJyb2FkY2FzdCBSYWRpdXMsIDcgYml0cywgc2hvdWxkIGJlIGRlY3Jl bWVudCBieSBlYWNoIA0KYnJvYWRjYXN0IHJlbGF5IG5vZGUsIGlmIGl0IGlzIGRlY3JlbWVudGVk IHRvIDAsIGRpc2NhcmQgdGhlIGZyYW1lLg0KU2VxdWVuY2UgTnVtYmVyOiBBIDgtYml0IG51bWJl ciB0byBpZGVudGlmeSBkaWZmZXJlbnQgQnJvYWRjYXN0IEZyYW1lIGZyb20NCnRoZSBzYW1lIHNv dXJjZSBub2RlLiBUaGUgb3JpZ2luYXRvciB3aWxsIGluY3JlbWVudCB0aGUgZmllbGQgYWZ0ZXIg ZWFjaCANCnNlbmRpbmcuDQpTb3VyY2UgQWRkcmVzczogVGhlIE9yaWdpbmF0b3IncyBNQUMgYWRk cmVzcy4NCg0KV2l0aCB0aGUgc3VwcG9ydCBvZiB0aGUgIkJyb2FkY2FzdCIgZmllbGQsIGFuIG9y aWdpbmF0b3Igb3IgYSByZWxheSBub2RlIHdpbGwgDQpzZW5kIHRoZSBCcm9hZGNhc3QgRnJhbWUg bGlrZSB0aGF0OiBmaXJzdCwgZGVsaXZlciB0aGUgZnJhbWUgdG8gYWxsIFBhbiBDb29yZGluYXRv ciANCmFuZCBSb3V0ZXJzIGFyb3VuZCB1c2luZyBNQUMgYnJvYWRjYXN0KHdpdGggdGhlIE1BQyBk ZXN0aW5hdGlvbiBhZGRyZXNzDQogc2V0IHRvIDB4RkZGRiwganVzdCBuZWVkIGJyb2FkY2FzdCBv bmNlKSwgdGhlbiwgaWYgdGhlcmUgYXJlIEVuZCBEZXZpY2VzIGluIA0KdGhlIG5vZGUncyBuZWln aGJvciB0YWJsZSwgdW5pY2FzdCB0aGUgZnJhbWUgdG8gdGhlbSBvbmUgYnkgb25lLiBCZXNpZGVz LCB0byANCmF2b2lkIGJyb2FkY2FzdCBzdG9ybSwgYSBCcm9hZGNhc3QgUmVjb3JkIFRhYmxlIHdp bGwgYmUgbmVlZGVkLiBUaGUgdGFibGUgd2lsbCANCnJlY29yZCB0aGUgU291cmNlIEFkZHJlc3Mg YW5kIFNlcXVlbmNlIE51bWJlciBpbiAiQnJvYWRjYXN0IiBmaWVsZCBvZiBlYWNoIA0KcmVjZWl2 ZWQgQnJvYWRjYXN0IEZyYW1lIGFmdGVyIHJlLWJyb2FkY2FzdGluZyBpdCBmaXJzdChFbmQgRGV2 aWNlIGRvbid0IG5lZWQNCiB0byByZS1icm9hZGNhc3RpbmcpLiBTZXF1ZW50aWFsbHksIGEgQnJv YWRjYXN0IFZhbGlkIFRpbWUgd2lsbCBiZSBpbml0aWFsaXplZCBmb3IgDQp0aGUgbmV3bHkgYWRk ZWQgQnJvYWRjYXN0IFJlY29yZCBFbnRyeS4gVGhlbiwgYmVmb3JlIHRoZSBlbnRyeSBpcyB0aW1l ZCBvdXQgDQooQnJvYWRjYXN0IFZhbGlkIFRpbWUgaXMgZGVjcmVtZW50ZWQgdG8gMCksIGFsbCBC cm9hZGNhc3QgRnJhbWUgd2l0aCB0aGUgc2FtZSANClNvdXJjZSBBZGRyZXNzIGFuZCBTZXF1ZW5j ZSBOdW1iZXIgc2hvdWxkIGJlIGRpc2NhcmRlZCBidXQgbm90IHJlbGF5ZWQuDQoNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkJlc3QgUmVnYXJkcywNCg0KTWFyaW8gTWFvDQpN YXJpb01hb0BHbWFpbC5jb20NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJv bTogIlNhbWl0YSBDaGFrcmFiYXJ0aSIgPHNhbWl0YWMyQGdtYWlsLmNvbT4NClRvOiAiTWFyaW8g TWFvIiA8bWFyaW9tYW9AZ21haWwuY29tPg0KQ2M6IDw2bG93cGFuQGlldGYub3JnPg0KU2VudDog TW9uZGF5LCBOb3ZlbWJlciAwNiwgMjAwNiA3OjA5IEFNDQpTdWJqZWN0OiBSZTogWzZMb1dQQU5d IFJvdXRlciBEeW5hbWljIEFkdmVydGlzZW1lbnQgQWxnb3JpdGhtIChSREEpDQoNCg0KPiBIaSBN YXJpbywNCj4gDQo+IA0KPiBQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGJlbG93Lg0KPiANCj4gPiBC eSBjb25maXJtaW5nIHdpdGggR2FicmllbCwgSSB3b3VsZCB1cGRhdGUgc29tZSByZXN1bHRzIG9m IG91ciB0ZWFtJ3Mgd29yaw0KPiA+IG9uIDZMb1dQQU4sIHBsZWFzZSB0YWtlIGl0IGFzIGEgcmVm ZXJlbmNlIGFuZCBnaXZlIGFueSBjb21tZW50IG5lZWRlZCwNCj4gPiB0aGFua3MuDQo+ID4NCj4g DQo+IERpZCB5b3UgYWxzbyBoYXZlIGFuIGltcGxlbWVudGF0aW9uIG9mIG91ciA2bG93cGFuLWlw djYtbmQgZHJhZnQgPw0KPiANCj4gPiBCYXNpY2FsbHksIG91ciB0ZWFtJ3Mgd29yayBmb2xsb3dz IGRyYWZ0cyBwcm9tcHRlZCBieSBXRy4gaG93ZXZlciwgd2UgZmluZA0KPiA+IHNvbWV0aGluZyBz aG91bGQgYmUgaW5jbHVkZWQgd2hlbiBpbXBsZW1lbnRpbmcuIEJlbG93IGlzIG9uZSBvZiB0aGUg dGhpbmdzDQo+ID4gYmV5b25kIGRyYWZ0OiBSb3V0ZXIgRHluYW1pYyBBZHZlcnRpc2VtZW50IEFs Z29yaXRobSAoUkRBKS4NCj4gPg0KPiA+IEZvciBDaGFrcmFiYXJ0aSwgSSBrbm93IGl0IGlzIGEg cmVhbGx5IGRpZmZlcmVudCB3YXkgZnJvbSB0aGUgb3B0aW1pemF0aW9uDQo+ID4gaW4gZHJhZnQg Nmxvd3Bhbi1pcHY2LW5kLiBCdXQgd2hlbiB3ZSBkZXNpZ24gYW5kIGltcGxlbWVudCB0aGUgNkxv V1BBTg0KPiA+IHN0YWNrLCB3ZSBkaWQgZmluZCBpdCBpcyBlZmZlY3RpdmUgYW5kIGVhc2llciB0 byBpbXBsZW1lbnQuIEhvcGUgdGhlIGlkZWEgaW4NCj4gPiB0aGlzIG1haWwgY291bGQgZG8gc29t ZSBoZWxwLCB0aGFua3MuDQo+ID4NCj4gDQo+IEFyZSB5b3Ugc2F5aW5nIHRoYXQgeW91IGltcGxl bWVudGVkIFJEQSBhbGdvcml0aG0gaW5zdGVhZCA/ICBIb3cgZGlkDQo+IHlvdSB1c2UgbXVsdGlj YXN0IGFuZCBjb250cm9sbGVkIGZsb29kaW5nIGF0IHRoZSBsaW5rLWxheWVyKDgwMi4xNS40KQ0K PiA/IEhhdmUgeW91DQo+IHVzZWQgYSBzaW11bGF0aW9uIG9yIHNldCBvZiByZWFsIHNlbnNvcnMg dG8gaW1wbGVtZW50IGFuZCB0YWtlIG1lYXN1cmVtZW50cz8NCj4gDQo+IFRoZSBtYWluIGlkZWEg b2YgIG91ciA2bG93cGFuLW5kIGRyYWZ0IGlzIHRvIG1pbmltaXplIHRoZSBicm9hZGNhc3Qgb3Ig YWxsLW5vZGUNCj4gbXVsdGljYXN0IG1lc3NhZ2VzIHRvIHRoZSBsb3ctcG93ZXJlZCBub2RlcyBp biBvcmRlciB0byBzYXZlIGVuZXJneSB3aGlsZQ0KPiBtYWludGFpbmluZyB0aGUgZWZmaWNpZW5j eSBvZiB0aGUgaW5pdGlhdGluZyBub2RlLiBUaHVzIHdlIG9wdGltaXplIGZvciB1bmljYXN0DQo+ IG1lc3NhZ2luZyBhbmQgc29tZXRpbWVzIHVzZSB0aGUgZXhpc3RpbmcgYWxnb3JpdGhtIGluIElQ djYgTkQgLSBzbyBpdCBzaG91bGQNCj4gYmUgc2ltcGxlIHRvIGltcGxlbWVudC4gVGhlIGlkZWEg Y291bGQgYmUgYXBwbGljYWJsZSBiZXlvbmQgNmxvd3BhbiBzY2VuYXJpb3MsDQo+IGkuZSB0byBh bnkgbmV0d29yayB0aGF0IHdhbnRzIHRvIHJ1biBlbmVyZ3ktZWZmaWNpZW50IElQdjYgTkQgcHJv dG9jb2wuDQo+IA0KPiBUaGFua3MsDQo+IC1TYW1pdGENCj4gDQo+IA0KPiANCj4gDQo+ID4gPT09 PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4NCj4gPiBSb3V0ZXIgRGlzY292ZXJ5LCBQcmVm aXggYW5kIFBhcmFtZXRlciBEaXNjb3ZlcnkgbmVlZCBSUyBhbmQgUkEgbWVzc2FnZQ0KPiA+IGRl ZmluZWQgaW4gTkRQLiBJbiBMb1dQQU4gZW52aXJvbm1lbnQsIHdlIG5lZWQgYXZvaWQgdGhlIHBv d2VyIGNvbnN1bWluZw0KPiA+IGNhdXNlZCBieSBicm9hZGNhc3RpbmcgdGhlc2Uga2luZHMgb2Yg bWVzc2FnZSBwZXJpb2RpY2FsbHkuIE9uIHRoZSBvdGhlcg0KPiA+IGhhbmQsIGl0IGlzIG5vdCBh IGdvb2QgaWRlYSB0byBzaW1wbHkgaW5jcmVhc2UgdGhlIGFubm91bmNlbWVudCBpbnRlcnZhbCB0 bw0KPiA+IGEgbGFyZ2UgdmFsdWUuIEl0IHdvdWxkIG1ha2UgdGhlIG5ldHdvcmsgaW5zZW5zaXRp dmUgYW5kIGxlYWQgc29tZSBjaGlsZA0KPiA+IG5vZGVzIGluYWNjZXNzaWJsZSBiZWZvcmUgdGhl eSBjb3VsZCBjb25maWd1cmUgYSBpcHY2IGdsb2JhbCBhZGRyZXNzLiBUbw0KPiA+IGJhbGFuY2Ug dGhlbSwgSG9zdCBhbmQgUm91dGVyIHVzZSBSb3V0ZXIgRHluYW1pYyBBZHZlcnRpc2VtZW50IEFs Z29yaXRobQ0KPiA+IChSREEpIHRvIHNlbmQgUlMgYW5kIFJBLg0KPiA+DQo+ID4gMS4gQXNzdW1w dGlvbg0KPiA+DQo+ID4gSW4gb3VyIGVudmlyb25tZW50LCB3ZSBkb24ndCBjb25zaWRlIElQdjYg cm91dGVycyB3b3VsZCBiZSBrbm93biBieSBhbGwNCj4gPiBzZW5zb3Igbm9kZXMgYmVmb3JlIHRo ZXkgZ2V0IHRoZWlyIGFubm91bmNlbWVudCBleHBsaWNpdGx5LiBUaGlzDQo+ID4gY29uc2lkZXJh dGlvbiB3b3VsZCB3b3JrIGZvciBtdWx0aXBsZSBzaW5rIHNjZW5hcmlvLiBUaGVyZSBjb3VsZCBi ZSBtb3JlDQo+ID4gdGhhbiBvbmUgc2luayAocm91dGVyKSB0byBiYWxhbmNlIHRoZSBsb2FkIGFy b3VuZCBzaW5rIChyb3V0ZXIpLiBTbywgSG9zdA0KPiA+IG5lZWQgdG8gc2VuZCBNdWxpdGNhc3Qg UlMgb3Igd2FpdCBmb3IgUkEuDQo+ID4NCj4gPiBUbyBzdXBwb3J0IElQIG11bHRpY2FzdCwgYnJv YWRjYXN0IGFiaWxpdHkgaW4gYWRhcHRhdGlvbiBsYXllciBzaG91bGQgYmUNCj4gPiBpbmNsdWRl ZC4gV2UgaGF2ZSBpbnRyb2R1Y2VkIGEgY29udHJvbGxlZCBmbG9vZGluZyBtZWNoYW5pc20gdG8g c3VwcGx5IHN1Y2gNCj4gPiBraW5kIG9mIHJlcXVpcm1lbnQuIFlvdSBjb3VsZCBnZXQgdGhlIG1l YW4gaWRlYSBpbiB0aGUgbWFpbCBiZWZvcmUsIEkNCj4gPiByZW1lbWJlciBJIGhhdmUgc2VudCBp dCB0byBtYWlsIGxpc3QgYWJvdXQgMyBtb250aHMgYWdvLg0KPiA+DQo+ID4gQXQgbGFzdCwgdGhl cmUgd2lsbCBiZSBhIGxpdHRsZSBjaGFuZ2UgdG8gUkZDMjQ2MSBvbiB0aGUgUkEgYW5ub3VuY2Vt ZW50DQo+ID4gaW50ZXJ2YWwsIG5vdCBtb3JlLCBidXQgZG8gaGF2ZS4gV2lsbCBpdCBiZSBhIGJp ZyBwcm9ibGVtPyBPdXINCj4gPiBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0IGJvdGggdGhlIHR3byB3 YXkgb2YgUkEgc2VuZGluZyBhbGdvdGl0aG0gaW4gYSBzaW5nbGUNCj4gPiBSb3V0ZXIsIG9uZSBm b3Igc3RhbmRhcmQsIG9uZSBmb3IgTG9XUEFOLiBQZW9wbGUgY291bGQgY29uZml1cmUgaW50ZXJm YWNlIHRvDQo+ID4gdXNlIGFueSBvZiB0aGVtLCB0aGF0IG1lYW5zLCBubyBjb25mbGljdCBiZXR3 ZWVuIHR3byBkaWZmZXJlbnQgbGlua3MsIGVnLg0KPiA+IHN0YW5kYXJkIGZvciBFdGhlcm5ldCBh bmQgUkRBIGZvciBJRUVFIDgwMi4xNS40LiBPdXIgdGVzdCBzaG93IHRoZSBSb3V0ZSBhbmQNCj4g PiBIb3N0IHdvdWxkIHdvcmsgZmluZSB3aGVuIGVuYWJsZSB0d28gYWR2ZXJ0aXNpbmcgaW50ZXJm YWNlcyB3aGljaCB1c2UNCj4gPiBkaWZmZXJlbnQgYWR2ZXJ0aXNpbmcgYWxnb3JpdGhtLg0KPiA+ DQo+ID4gMi4gSG9zdA0KPiA+DQo+ID4gV2hlbiBIb3N0IHN0YXJ0cyB1cCwgaXQgaG9sZCB0aGUg aW5pdGlhbCBtdWx0aWNhc3QgUlMgdW50aWwgVElNRV9XQUlUX0ZPUl9SQQ0KPiA+IGVsYXBzZWVk LiBJZiBIb3N0IHN0aWxsIG1pc3MgdGhlIHdhbnRlZCBSQSwgYSBtdWx0aWNhc3QgUlMgc2hvdWxk IGJlIHNlbnQNCj4gPiBvdXQuIEZvciBUSU1FX1dBSVRfRk9SX1JBLCBpdCBpcyBhIHJhbmRvbSB2 YWx1ZSBiZXR3ZWVuIEJBU0VfUkFfSU5URVJWQUwgYW5kDQo+ID4gMipCQVNFX1JBX0lOVEVSVkFM LiBBbm90aGVyLCB0aGUgc291cmNlIGFkZHJlc3Mgb2YgUlMgc2hvdWxkIHVzZSB1bmljYXN0DQo+ ID4gYWRkcmVzcyBidXQgbm90IDo6LCB0aGF0IG1ha2UgUm91dGVyIGNvdWxkIHVuaWNhc3QgdGhl IFJBIG1lc3NhZ2UgYmFjayB0bw0KPiA+IEhvc3QuDQo+ID4NCj4gPiBGb3IgYXBwbGljYXRpb24g dGhhdCB3YW50IGltbWVkaWF0ZSBhY2Nlc3MgdG8gZXZlcnkgc2Vuc29yIG5vZGUsDQo+ID4gVElN RV9XQUlUX0ZPUl9SQSBjb3VsZCB1c2UgYW5vdGhlciBzbWFsbGVyIHZhbHVlIHdoaWNoIGxldCBS QSByZWNlaXZlZA0KPiA+IHF1aWNrbHkuIEhvd2V2ZXIsIGZvciBtb3N0IFdTTiBhcHBsaWNhdGlv bnMgdGhhdCBoYXZlbid0IHN1Y2gga2luZCBvZg0KPiA+IHJlcXVpcmVtZW50LCAxMCAtIDIwIG1p bnV0ZXMgd2FpdCB0aW1lIG1heSBhY2NlcHRhYmxlLg0KPiA+DQo+ID4gMy4gUm91dGVyDQo+ID4N Cj4gPiBSb3V0ZSB3b3VsZCBubyBsb25nZXIgdXNlIGEgcmVsYXRpdmVseSBmaXhlZCBpbnRlcnZh bCB0byBzZW5kIFVuc29saWNpdGVkDQo+ID4gUkEuIEFzIHNvb24gYXMgb25lIGludGVyZmFjZSBv ZiBSb3V0ZXIgaXMgY29uZml1cmVkIGFzIGFuIEFkdmVydGlzaW5nDQo+ID4gSW50ZXJmYWNlLCB0 aGUgaW50ZXJ2YWwgb2Ygc2VuZGluZyBSQSB3b3VsZCBiZSBjYWxjdWxhdGVkIGJ5IFJEQS4gVGhl DQo+ID4gY29uc3RhbnRzIGFuZCB2YXJpYWJsZXMgbWFpbnRhaW5lZCBhcyBmb2xsb3c6DQo+ID4N Cj4gPiAgICAgQkFTRV9SQV9JTlRFUlZBTDogdGhlIGJhc2FsIGludGVydmFsIG9mIHNlbmRpbmcg UkEsIHJlY29tbWVuZGVkIHZhbHVlIGlzDQo+ID4gMTBtaW4uDQo+ID4gICAgIE1BWF9SQV9GQUNU T1I6IHRoZSBtYXhpdW0gUkEgZmFjdG9yLCByZWNvbW1lbmRlZCB2YWx1ZSBpcyA1LTYuDQo+ID4g ICAgIGE6IFJBIGZhY3Rvci4NCj4gPiAgICAgaW50ZXJ2YWw6IGN1cnJlbnQgUkEgaW50ZXJ2YWwu DQo+ID4gICAgIHRpbWVUb0FkdjogdGhlIHRpbWUgdG8gc2VuZGluZyBuZXh0IFJBLg0KPiA+ICAg ICBzZW5kVGltZXM6IHRoZSB0aW1lcyBvZiBzZW5kaW5nIFJBIHVzaW5nIHRoZSBzYW1lIGludGVy dmFsLg0KPiA+ICAgICByZWN2UlNUaW1lczogdGhlIHRpbWVzIG9mIHJlY2VpdmVpbmcgUlMgcGFj a2V0IGJldHdlZW4gdHdvIHVuc29saWNpdGVkDQo+ID4gUkEuDQo+ID4NCj4gPg0KPiA+IFRoZSBh bGdvcml0aG0gY29tZXMgYmVsb3csIHRoZSBiYXNpYyBpZGVhIGlzIGluY3JlYXNpbmcgdGhlIGFk dmVydGlzaW5nDQo+ID4gaW50ZXJ2YWwgdG8gbG9uZyB3aGVuIHRvcG9sb2d5IGlzIHN0YWJsZSBh bmQgZGVjcmVhc2luZyB0byBzaG9ydCB3aGVuIHRoZQ0KPiA+IG5ldHdvcmsgYmVjb21lIHdhdnk6 DQo+ID4NCj4gPiAoMSkuIFdoZW4gYWR2ZXJ0aXNpbmcgaW50ZXJmYWNlIGluaXRpYWxpemVzLCBs ZXQgYSA9IDAsaW50ZXJ2YWwgPQ0KPiA+IEJBU0VfUkFfSU5URVJWQUwqMl5hLHNlbmRUaW1lcyA9 IGErMSxyZWN2UlNUaW1lcyA9IDAsdGltZVRvQWR2ID0gaW50ZXJ2YWwuDQo+ID4NCj4gPiAoMiku DQo+ID4gLSAoYSkgV2hlbiBpbnRlcnZhbCB0aW1lIGVsYXBzZWQgKHRoYXQgbWVhbnMgdGltZVRv QWR2IGlzIGRlY3JlYXNlZCB0byAwKSwNCj4gPiBzZW5kIGEgTXVsdGljYXN0IFVuc29saWNpdGVk IFJBIGFuZCBsZXQgcmVjdlJTVGltZXMgPSAwOw0KPiA+IC0gKGIpIElmIHNlbmRUaW1lcyA+IDAg YW5kIGEgPCBNQVhfUkFfRkFDVE9SSUFMLCBzdWJzdHJhY3RlIHNlbmRUaW1lcyBieSAxOw0KPiA+ IGlmIHNlbmRUaW1lcyBpcyBkZWNyZWFzZWQgdG8gMCwgbGV0IGEgPSBhKzEgYW5kIHJlY2FsY3Vs YXRlIHNlbmRUaW1lcyB3aXRoDQo+ID4gdGhlIGZvcm11bGEgaW4gKDEpOw0KPiA+IC0gKGMpIFJl Y2FsY3VsYXRlIGludGVydmFsIHdpdGggdGhlIGZvcm11bGEgaW4gKDEpLCBsZXQgdGltZVRvQWR2 ID0NCj4gPiBpbnRlcnZhbCwgd2F0aSBmb3Igc2VuZGluZyBuZXh0IFJBLg0KPiA+DQo+ID4gKDMp Lg0KPiA+IC0gKGEpIElmIFJvdXRlciByZWNlaXZlZCBhIHZhbGlkIFJTLCBsZXQgYSA9IGEvMiwg cmVjdlJTVGltZXMgPQ0KPiA+IHJlY3ZSU1RpbWVzKzEsIHNlbmRUaW1lcyA9IGErMTsNCj4gPiAt IChiKSBSZWNhbGN1bGF0ZSBjdXJyZW50IHRpbWVUb0FkdjogaWYgYSBpcyBldmVuIGJlZm9yZSBy ZWNlaXZpbmcgUlMsIGxldA0KPiA+IHRpbWVUb0FkdiA9IHRpbWVUb0Fkdi8yXmEgW3NlZSBhbm5v dGF0aW9uIDFdOyBpZiBpdCBpcyBvZGQsIGxldCB0aW1lVG9BZHYgPQ0KPiA+IHRpbWVUb0Fkdi8y XihhKzEpIFtzZWUgYW5ub3RhdGlvbiAyXTsNCj4gPiAtIChjKSBpZiByZWN2UlNUaW1lcyA8IDMs IHNlbmQgVW5pY2FzdCBTb2xpY2l0ZWQgUkEgd2l0aCB0aGUgd2F5IGRlZmluZWQgaW4NCj4gPiBS RkMyNDYxOyBpZiByZWN2UlNUaW1lcyA9IDMsIGxldCB0aW1lVG9BZHYgPSAwLCBzZW5kIGEgTXVs dGljYXN0IFNvbGljaXRlZA0KPiA+IFJBIGltbWVkaWF0ZWx5IGFuZCBjYXJyeSBvdXQgYWxsIHJl bGF0aXZlIG9wZXJhdGlvbiBpbiAoMik7IGlmIHJlY3ZSU1RpbWVzID4NCj4gPiAzLCBub3RoaW5n IGVsc2UgbmVlZCB0byBkbyAoaXQgaXMgcG9zc2libGUgUm91dGVyIHJlY2VpdmUgYSBuZXcgUlMg YmVmb3JlDQo+ID4gdGhlIHNjaGVkdWxlZCBSQSBzZW5kaW5nIG91dCwgc28ganVzdCBsZXQgSG9z dHMgd2FpdCBmb3IgdGhlIHNjaGVkdWxlZA0KPiA+IE11bHRpY2FzdCBSQSkuDQo+ID4NCj4gPiBb QW5ub3RhdGlvbiAxXQ0KPiA+IHRpbWVUb0FkdiA9IHRpbWVUb0FkdiAqIChuZXdJbnRlcnZhbCAv IG9sZEludGVydmFsKQ0KPiA+ICAgICAgICAgICAgICAgICA9IHRpbWVUb0FkdiAqIChCQVNFX1JB X0lOVEVSVkFMKjJeYSAvDQo+ID4gQkFTRV9SQV9JTlRFUlZBTCoyXigyYSkgKQ0KPiA+ICAgICAg ICAgICAgICAgICA9IHRpbWVUb0FkdiAqIDJeKC1hKQ0KPiA+ICAgICAgICAgICAgICAgICA9IHRp bWVUb0FkdiAvIDJeYQ0KPiA+IFtBbm5vdGF0aW9uIDJdDQo+ID4gdGltZVRvQWR2ID0gdGltZVRv QWR2ICogKG5ld0ludGVydmFsIC8gb2xkSW50ZXJ2YWwpDQo+ID4gICAgICAgICAgICAgICAgID0g dGltZVRvQWR2ICogKEJBU0VfUkFfSU5URVJWQUwqMl5hIC8NCj4gPiBCQVNFX1JBX0lOVEVSVkFM KjJeKDJhKzEpICkNCj4gPiAgICAgICAgICAgICAgICAgPSB0aW1lVG9BZHYgKiAyXigtKGErMSkp DQo+ID4gICAgICAgICAgICAgICAgID0gdGltZVRvQWR2IC8gMl4oYSsxKQ0KPiA+DQo+ID4NCj4g PiBXaGVuIGFkdmVydGlzaW5nIGludGVyZmFjZSB1c2UgUkRBLCBIb3N0IHdpbGwgbm90IHNlbmQg UlMgYnV0IHdhaXQgZm9yDQo+ID4gcG9zc2libGUgUkEgd2hlbiBpdCBzdGFydHVwLiBJZiBpdCBn ZXQgbm90aGluZyB3aXRoaW4gVElNRV9XQUlUX0ZPUl9SQSwgYSBSUw0KPiA+IHdvdWxkIGJlIHNl bnQgb3V0IHRvIHNvbGljaXQgUkEuIFRoaXMgcHJvY2VzcyBjb3VsZCByZWR1Y2UgdGhlIGJyb2Fk Y2FzdA0KPiA+IGZsb3cgb2YgUlMgd2hlbiBIb3N0cyBib290c3RyYXAuIE1lYW53aGlsZSwgUm91 dGVyIHdvdWxkIHNlbmQgbXVsdGljYXN0IFJBDQo+ID4gd2l0aCBhIHNtYWxsIGludGVydmFsIGF0 IHRoZSBiZWdpbmluZyBhbmQgaW5jcmVhc2UgdGhlIHNlbmRpbmcgaW50ZXJ2YWwNCj4gPiBncmFk dWFsbHkuIFRoYXQgY291bGQgc2F0aXNmeSB0aGUgcmVxdWlyZW1lbnQgZm9yIFJBIGZyb20gSG9z dCB3aGVuIDgwMi4xNS40DQo+ID4gbm9kZXMgY29uc3RydWN0aW5nIG5ldHdvcmsuIEZvciBUSU1F X1dBSVRfRk9SX1JBIGlzIGEgcmFuZG9tIHZhbHVlIGJldHdlZW4NCj4gPiBCQVNFX1JBX0lOVEVS VkFMIGFuZCAyKkJBU0VfUkFfSU5URVJWQUwsIGl0IGlzIGhpZ2hseSBwb3NzaWJsZSB0aGF0IG1v c3Qgb2YNCj4gPiB0aGUgSG9zdHMgbmVlZG4ndCB0byBzZW5kIFJTIHdoZW4gbm9kZXMgaW4gdGhl IHNhbWUgUEFOIHN0YXJ0IHRvIGNvbnN0cnVjdA0KPiA+IG5ldHdvcmsgdG9wb2xvZ3kuIEFmdGVy IHRoZSB0b3BvbG9neSBoYXMgYmVlbiBzdGFibGUgKG1vc3Qgb2Ygbm9kZXMgaGF2ZQ0KPiA+IGpv aW5lZCBpbnRvIHRoZSBQQU4pLCBpbnRlcnZhbCBvZiBSQSB3aWxsIGluY3JlYXNlIHRvIGEgbGFy Z2UgdmFsdWUgd2hpY2gNCj4gPiBhbGxldmlhdGUgdGhlIGVuZXJneSB3YXN0YWdlIGJ5IGJyb2Fk Y2FzdGluZyBSQSBtZXNzYWdlIGZyZXF1ZW50bHkuDQo+ID4NCj4gPiBXaGVuIHRoZSBuZXR3b3Jr IGJlY29tZSB1bnN0YWJsZSAoZWcuIHNvbWUgbm9kZXMgbG9zZSBzeW5jaHJvbml6YXRpb24gd2l0 aA0KPiA+IGJlYWNvbiwgdGhleSB3b3VsZCBzdGFydCBvcnBoYW4gc2NhbiBhbmQgdHJ5IHRvIHJl LWpvaW4gdGhlIG5ldHdvcmsuIEF0IHRoaXMNCj4gPiB0aW1lLCBub2RlIG1pZ2h0IG5lZWQgdG8g cmVxdWVzdCBhIG5ldyBSQSBtZXNzYWdlIGZvciBhZGRyZXNzDQo+ID4gYXV0b2NvbmZpZ3VyYXRp b24pIG9yIG5ldyBub2RlIHRyeSB0byBqb2luIFBBTiwgSG9zdCB3b3VsZCBzZW5kIFJTIHRvDQo+ ID4gUm91dGVyLiBSb3V0ZXIgYW5zd2VyIHRoZSBzb2xpY2l0YXRpb24gd2l0aCBVbmljYXN0IFJB IGFuZCByZWR1Y2UgUkENCj4gPiBpbnRlcnZhbCBleHBvbmVudGlhbGx5IHRvIHJlc3BvbnNlIHRo ZSBjaGFuZ2Ugb2YgbmV0d29yayByYXBpZGx5LiBJZiB0aGUgUEFODQo+ID4gaXMgc3VmZmVyaW5n IGEgc2VyaW91cyB1bmR1bGF0aW9uIChlZy4gYSBwYXJlbnQgbm9kZSB3aXRoIHNldmVyYWwgY2hp bGRyZW4NCj4gPiBvciBncmFuZGNoaWxkcmVuIGZhaWxlZCwgYWxsIG9mIGNoaWxkcmVuIG5lZWQg dG8gcmUtam9pbiB0aGUgbmV0d29yay4gVGhlDQo+ID4gcmVzdWx0IG9mIHRoaXMgc2NlbmFyaW8g aXMgbG90cyBvZiBSUyBtZXNzYWdlcyBhcHBlYXJpbmcgb24gdGhlIGNoYW5uZWwpLA0KPiA+IFJv dXRlciByZXNwb25zZSB0aGlzIHNpdHVhdGlvbiBieSBzZW5kaW5nIGEgTXVsdGljYXN0IFJBIGlt bWVkaWF0ZWx5IGFzIHNvb24NCj4gPiBhcyBtb3JlIHRoYW4gMyBSUyByZWNlaXZlZCBiZXR3ZWVu IHR3byBhZGphY2VudCB1bnNvbGljaXRlZCBSQS4gTm93LCBSQQ0KPiA+IGZhY3RvciBhbmQgUkEg aW50ZXJ2YWwgaGF2ZSBkZWNyZWFzZWQgdG8gc21hbGwgdmFsdWUsIFJvdXRlciBiZWdpbiB0byBz ZW5kDQo+ID4gUkEgZnJlcXVlbnRseSBhbmQgZW50ZXJzIGEgZmFzdCBhZHZlcnRpc2luZyBwZXJp b2QgdG8gYWNjb21tb2RhdGUgdGhlIGNoYW5nZQ0KPiA+IG9mIG5ldHdvcmsuDQo+ID4NCj4gPiBX aGVuIG5ldHdvcmsgdG9wb2xvZ3kgY29tZXMgc3RhYmxlIGFmdGVyIGdvbmUgdGhyb3VnaCB0aGUg d2F2eSBwZXJpb2QsIFJBDQo+ID4gaW50ZXJ2YWwgd291bGQgaW5jcmVhc2UgYWdhaW4gd2l0aCB0 aGUgUkEgZmFjdG9yLiBBdCBsYXN0LCBpdCByZWFjaHMgYSBsYXJnZQ0KPiA+IGVub3VnaCB2YWx1 ZSBhbmQgZW50ZXJzIHRoZSBzbG93IGFkdmVydGlzaW5nIHBlcmlvZC4NCj4gPg0KPiA+IEJlbG93 IHRhYmxlIHNob3cgdGhlIGNoYW5nZSBvZiBSQSBpbnRlcnZhbCAoQkFTRV9SQV9JTlRFUlZBTCA9 IDEwDQo+ID4gbWluLE1BWF9SQV9GQUNUT1IgPSA2KS4gUkEgaW50ZXJ2YWwgd2lsbCBpbmNyZWFz ZSB0byAxMC4zaCBpZiB0aGUgbmV0d29yaw0KPiA+IHRvcG9sb2d5IHN0YXlzIHN0YWJsZSAoaXQg aXMgYWxzbyB0aGUgY2hhcmFjdGVyIG9mIFdTTjogdG9wb2xvZ3kgd291bGRuJ3QNCj4gPiB0YWtl IGZyZXF1ZW50IGNoYW5nZSBhZnRlciB0aGUgaW5pdGlhbCBuZXR3b3JrIG9yZ2FuaXphdGlvbiku IFN1Y2ggYSBsb25nDQo+ID4gaW50ZXJ2YWwgb25seSB0YWtlIGxpdHRsZSBuZWdhdGl2ZSBlZmZl Y3QgdG8gdGhlIHBvd2VyIGNvbnN1bXB0aW9uLg0KPiA+ID09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4gYSAgICBpbnRlcnZhbCAgIHNlbmRU aW1lcyAgIFRpbWUgdG8gYWNoaWV2ZSB0aGUgaW50dmwNCj4gPiAwICAgIDEwbSAgICAgICAgICAx ICAgICAgICAgICAgICAgICAwDQo+ID4gMSAgICAyMG0gICAgICAgICAgMiAgICAgICAgICAgICAg ICAgMTBtDQo+ID4gMiAgICA0MG0gICAgICAgICAgMyAgICAgICAgICAgICAgICAgNTBtDQo+ID4g MyAgICA4MG0gICAgICAgICAgNCAgICAgICAgICAgICAgICAgMi44aA0KPiA+IDQgICAgMTYwbSAg ICAgICAgIDUgICAgICAgICAgICAgICAgIDguMmgNCj4gPiA1ICAgIDMyMG0gICAgICAgICA2ICAg ICAgICAgICAgICAgICAyMS41aA0KPiA+IDYgICAgNjQwbSAgICAgICAgIDcgICAgICAgICAgICAg ICAgIDUzLjVoDQo+ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCj4gPg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IE1hcmlvIE1hbw0K PiA+IE1hcmlvTWFvQEdtYWlsLmNvbQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA2bG93cGFuIG1haWxpbmcgbGlzdA0KPiA+IDZs b3dwYW5AaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by82bG93cGFuDQo+ID4NCj4gPg0KPiA+ --===============1709829127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1709829127==-- From 6lowpan-bounces@ietf.org Mon Nov 06 19:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEzc-0001QC-3s; Mon, 06 Nov 2006 19:39:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEzb-0001Q2-6B for 6lowpan@lists.ietf.org; Mon, 06 Nov 2006 19:39:07 -0500 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEzZ-0003nB-Hc for 6lowpan@lists.ietf.org; Mon, 06 Nov 2006 19:39:07 -0500 Received: from [127.0.0.1] (dhcp34-130.ietf67.org [130.129.34.130]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id kA70cs7x061536; Mon, 6 Nov 2006 18:39:00 -0600 (CST) (envelope-from salo@saloits.com) Message-ID: <454FD596.8020605@saloits.com> Date: Mon, 06 Nov 2006 18:38:46 -0600 From: "Timothy J. Salo" <salo@saloits.com> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: 6lowpan@lists.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: Subject: [6lowpan] Problem Statement Comments X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Errors-To: 6lowpan-bounces@ietf.org I read the Problem draft again, and therefore have some (admittedly belated) comments. Section 4.1, "IP Connectivity" If I were writing this section, I would focus on what we probably agree are our primary objectives. (I would probably also try to avoid specifying the solution in a requirements document). I might write something like: The principal motivation for this work is to seamlessly interconnect 802.15.4 networks with IPv4 and IPv6 networks, including the Internet. I don't think this statement is made clearly and directly in this document, (or the charter, the last time I looked). The current text of this section, for the most part seems to focus more on why IPv6 was chosen as the solution, rather than on a strong statement that our objective is to interconnect 802.15.4 networks with IP networks. (Yes, the _last_ of the four bullets sort of implies this, but it feels like what should be the primary message was tacked on the end of some IPv6 justifications.) Section 3. "Assumptions", Bullet 5. While it isn't politically correct to say so, I believe that there will be a device between IP networks and 802.15.4 networks that meets most reasonable definitions of a "gateway". Nonetheless, it is true that the use of the IPv6-like protocols that are being discussed make the operation of this not-really-a-gateway fairly straight-forward and transparent. Section 5. "Goals", Bullet 2. This would be a nice place to explain in a sentence or two why a stateless header compression technology is needed, and why ROHC isn't applicable. - - - - - - - - - - - A bunch of nits and diction complaints follow. "Abstract" The abstract claims that "Additional goals may be found necessary over time and may be added to this document." I don't understand how this document is going to be modified over time, particularly after it is an RFC. 1. "Introduction", First Paragraph It might make sense to include "limited computational power and limited memory" in this list. While this is (sort of) implied by low cost and low power, these limitations are so fundamental to the work of the group that it might not hurt to be explicit about them in the first paragraph. 1. "Introduction", Second Paragraph I don't understand the term "IP and IPv6". Assuming this isn't an editorial comment on IPv6, is this supposed to read "IPv4 and IPv6"? I'm not sure I like the phrase "enabling IP communications between devices in a LoWPAN" because I assume that our real interest is to enable IP communications between devices attached to 802.15.4 networks and IP devices on _other_ networks, (as well as intra- 802.15.4 communications). Have we identified any items that are not "necessarily appropriate tasks for the IETF"? The purpose of this sentence is not clear to me. Could this sentence be deleted? 2. "Overview", First Paragraph Yes, I know the 802.15.4 spec uses the term "relaxed throughput", but it still seems a bit affected to me. "Limited bandwidth" seems a bit more direct, (but I warned earlier that this is the diction section...) 2. "Overview", Sixth Bullet "Limited processing power, limited memory, etc." might read better than "low processing, low memory, etc." I might also delete the last sentence -- it doesn't really add much. 2. "Overview", Ninth Bullet This bullet seems to munge two ideas together: that connectivity may be unreliable and that devices may be be unreliable. The bullet might read better if the ideas were stated separately, or maybe if the bullet focused on connectivity rather than devices. 2. "Overview", Tenth Bullet Perhaps, "In many environments, devices connected to a LoWPAN may sleep for long periods of time in order to conserve energy, and are unable to communicate during these sleep periods." 3. "Assumptions", Bullets I might focus on the assumption that using IP technologies will simplify the interconnection of 802.15.4 networks and IP networks. This is sort of what the last paragraph says, my quibbles about the claim that a gateway won't exist notwithstanding. I don't really understand what the first bullet is trying to say. Perhaps, it would be more clear if a few examples were provided. I have some question about how applicable the fourth bullet is. Will I be able to ping a LoWPAN device? Send it an SNMP GET? (This is where I will say that it would make a lot more sense for the we-can't-call-it-a-gateway to respond to these requests for the LoWPAN device.) Section 4.2, "Topologies", Fourth Bullet The notion that many LoWPAN devices will sleep much of the time is a very important idea. I would either make this the focus of the bullet, (e.g., move this sentence to the beginning of the bullet) or add a separate bullet that mentions it. Section 4.2, "Topologies", Last Paragraph This is a very important paragraph. Many of my comments try to emphasize the idea that we want to seamlessly integrate 802.15.4 networks with IP networks. However, this idea currently seems to be buried in this discussion of topologies. Section 5, "Goals", Fourth Bullet "Ad hoc" is two words. (OK, OK, this is pretty minor, but ad hoc networks are so closely related to this work that we at least ought to spell their name correctly...) Section 5, "Goals", Seventh Bullet This is a very interesting topic. I don't know whether we want to suggest changes to verbose higher-layer protocols or simply say "don't do that". (When reviewing a specification document for a system that was going to operate in a wireless environment, I finally gave up and simply said, "just globally replace all instances of "XML good" with "XML bad".) -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Nov 06 20:28:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFku-00061J-Ue; Mon, 06 Nov 2006 20:28:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFkt-00061C-Ps for 6lowpan@lists.ietf.org; Mon, 06 Nov 2006 20:27:59 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhFkr-0001OA-AS for 6lowpan@lists.ietf.org; Mon, 06 Nov 2006 20:27:59 -0500 Received: from dhcp66-22.ietf67.org (dhcp66-22.ietf67.org [130.129.66.22]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id kA71RuM5010149; Mon, 6 Nov 2006 18:27:56 -0700 (MST) Subject: Re: [6lowpan] Problem Statement Comments From: Geoff Mulligan <geoff@mulligan.com> To: "Timothy J. Salo" <salo@saloits.com> In-Reply-To: <454FD596.8020605@saloits.com> References: <454FD596.8020605@saloits.com> Content-Type: text/plain Date: Mon, 06 Nov 2006 18:27:50 -0700 Message-Id: <1162862871.5256.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: 6lowpan@lists.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Errors-To: 6lowpan-bounces@ietf.org Timothy, The WG last call on the problem statement document has long since closed. That said, I think that a few of the editorial nits that you point out could and should be addressed, though we need input from the rest of the group as to which of your comments should be "fixed". geoff On Mon, 2006-11-06 at 18:38 -0600, Timothy J. Salo wrote: > I read the Problem draft again, and therefore have some (admittedly > belated) comments. > > Section 4.1, "IP Connectivity" > > If I were writing this section, I would focus on what we probably > agree are our primary objectives. (I would probably also try to > avoid specifying the solution in a requirements document). I might > write something like: > > The principal motivation for this work is to seamlessly > interconnect 802.15.4 networks with IPv4 and IPv6 networks, > including the Internet. > > I don't think this statement is made clearly and directly in > this document, (or the charter, the last time I looked). > > The current text of this section, for the most part seems to focus > more on why IPv6 was chosen as the solution, rather than on a > strong statement that our objective is to interconnect 802.15.4 > networks with IP networks. (Yes, the _last_ of the four bullets > sort of implies this, but it feels like what should be the primary > message was tacked on the end of some IPv6 justifications.) > > Section 3. "Assumptions", Bullet 5. > > While it isn't politically correct to say so, I believe that > there will be a device between IP networks and 802.15.4 networks > that meets most reasonable definitions of a "gateway". Nonetheless, > it is true that the use of the IPv6-like protocols that are being > discussed make the operation of this not-really-a-gateway fairly > straight-forward and transparent. > > Section 5. "Goals", Bullet 2. > > This would be a nice place to explain in a sentence or two why > a stateless header compression technology is needed, and why > ROHC isn't applicable. > > - - - - - - - - - - - > > A bunch of nits and diction complaints follow. > > "Abstract" > > The abstract claims that "Additional goals may be found necessary > over time and may be added to this document." I don't understand > how this document is going to be modified over time, particularly > after it is an RFC. > > 1. "Introduction", First Paragraph > > It might make sense to include "limited computational power and > limited memory" in this list. While this is (sort of) implied by > low cost and low power, these limitations are so fundamental to the > work of the group that it might not hurt to be explicit about them > in the first paragraph. > > 1. "Introduction", Second Paragraph > > I don't understand the term "IP and IPv6". Assuming this isn't > an editorial comment on IPv6, is this supposed to read "IPv4 and > IPv6"? > > I'm not sure I like the phrase "enabling IP communications between > devices in a LoWPAN" because I assume that our real interest is > to enable IP communications between devices attached to 802.15.4 > networks and IP devices on _other_ networks, (as well as intra- > 802.15.4 communications). > > Have we identified any items that are not "necessarily appropriate > tasks for the IETF"? The purpose of this sentence is not clear > to me. Could this sentence be deleted? > > 2. "Overview", First Paragraph > > Yes, I know the 802.15.4 spec uses the term "relaxed throughput", > but it still seems a bit affected to me. "Limited bandwidth" > seems a bit more direct, (but I warned earlier that this is the > diction section...) > > 2. "Overview", Sixth Bullet > > "Limited processing power, limited memory, etc." might read better > than "low processing, low memory, etc." I might also delete the > last sentence -- it doesn't really add much. > > 2. "Overview", Ninth Bullet > > This bullet seems to munge two ideas together: that connectivity > may be unreliable and that devices may be be unreliable. The > bullet might read better if the ideas were stated separately, > or maybe if the bullet focused on connectivity rather than devices. > > 2. "Overview", Tenth Bullet > > Perhaps, "In many environments, devices connected to a LoWPAN > may sleep for long periods of time in order to conserve energy, > and are unable to communicate during these sleep periods." > > 3. "Assumptions", Bullets > > I might focus on the assumption that using IP technologies will > simplify the interconnection of 802.15.4 networks and IP networks. > This is sort of what the last paragraph says, my quibbles about > the claim that a gateway won't exist notwithstanding. > > I don't really understand what the first bullet is trying to say. > Perhaps, it would be more clear if a few examples were provided. > > I have some question about how applicable the fourth bullet is. > Will I be able to ping a LoWPAN device? Send it an SNMP GET? > (This is where I will say that it would make a lot more sense > for the we-can't-call-it-a-gateway to respond to these requests > for the LoWPAN device.) > > Section 4.2, "Topologies", Fourth Bullet > > The notion that many LoWPAN devices will sleep much of the time > is a very important idea. I would either make this the focus of > the bullet, (e.g., move this sentence to the beginning of the > bullet) or add a separate bullet that mentions it. > > Section 4.2, "Topologies", Last Paragraph > > This is a very important paragraph. Many of my comments try to > emphasize the idea that we want to seamlessly integrate 802.15.4 > networks with IP networks. However, this idea currently seems > to be buried in this discussion of topologies. > > Section 5, "Goals", Fourth Bullet > > "Ad hoc" is two words. (OK, OK, this is pretty minor, but > ad hoc networks are so closely related to this work that we at > least ought to spell their name correctly...) > > Section 5, "Goals", Seventh Bullet > > This is a very interesting topic. I don't know whether we want > to suggest changes to verbose higher-layer protocols or simply > say "don't do that". (When reviewing a specification document > for a system that was going to operate in a wireless environment, > I finally gave up and simply said, "just globally replace all > instances of "XML good" with "XML bad".) > > -tjs > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Nov 07 04:13:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhN0o-0000uz-35; Tue, 07 Nov 2006 04:12:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhN0m-0000uY-I6 for 6lowpan@ietf.org; Tue, 07 Nov 2006 04:12:52 -0500 Received: from ee.oulu.fi ([130.231.61.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhN0k-0004VO-2s for 6lowpan@ietf.org; Tue, 07 Nov 2006 04:12:52 -0500 Received: from [10.100.11.184] (ee-gw3 [130.231.61.13]) by ee.oulu.fi (8.13.8/8.13.8) with ESMTP id kA79Cl1b007741 for <6lowpan@ietf.org>; Tue, 7 Nov 2006 11:12:47 +0200 (EET) Message-ID: <45504E40.8070407@ee.oulu.fi> Date: Tue, 07 Nov 2006 11:13:36 +0200 From: "M. Ikram Ashraf" <ikram@ee.oulu.fi> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [6lowpan] 6LoWPAN Ov IEEE 802.15.4 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Errors-To: 6lowpan-bounces@ietf.org Hi, Actually i am looking for some stuff related to 6LoWPAN over IEEE 802.15.4. Thanks. ikram _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Nov 07 22:16:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhdvL-0001g1-Sb; Tue, 07 Nov 2006 22:16:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhdvK-0001fw-Vm for 6lowpan@lists.ietf.org; Tue, 07 Nov 2006 22:16:22 -0500 Received: from web81905.mail.mud.yahoo.com ([68.142.207.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhdvC-0003ct-C3 for 6lowpan@lists.ietf.org; Tue, 07 Nov 2006 22:16:22 -0500 Received: (qmail 30329 invoked by uid 60001); 8 Nov 2006 03:16:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=BVSvg1KzZgkQWqsfuTs+O8B1OrO9CFKOUsLgm5kZHA5siPdQEI49ZPcYa8NqzAYI79vclGzqO3lHhS6nXKZxvb6bvM4/U7F4qAPdBXo+/IQelJlyDO1JIKdptT8fIMXPpJ2Q1oKic8LOrHF0yMQUYF33FrBQxGaZOmev7LcwTA8= ; Message-ID: <20061108031613.30327.qmail@web81905.mail.mud.yahoo.com> Received: from [130.129.70.150] by web81905.mail.mud.yahoo.com via HTTP; Tue, 07 Nov 2006 19:16:13 PST Date: Tue, 7 Nov 2006 19:16:13 -0800 (PST) From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com> Subject: Re: [6lowpan] Proposal for alternative 6lowpan header encoding To: Geoff Mulligan <geoff@mulligan.com>, 6lowpan <6lowpan@lists.ietf.org> MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0365186587==" Errors-To: 6lowpan-bounces@ietf.org --===============0365186587== Content-Type: multipart/alternative; boundary="0-1435905432-1162955773=:29601" --0-1435905432-1162955773=:29601 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable By the way, =0A=0AIn order to get an idea of what the format document would= look like if we decided to go=0Aahead with its adoption, the Jonathan and = David have produced a tentative version of the =0Adocument. Since this migh= t help folks better evaluate the proposal, you can get it here:=0A=0Ahttp:/= /briefcase.yahoo.com/bc/gabriel_montenegro_2000/lst?&.dir=3D/lowpan&.src=3D= bc&.view=3Dl=0A=0A=0ABTW, this version is built on version 06 (with changes= based on Geoff's review), submitted yesterday, and also available at the a= bove URL (until it gets=0Aofficially published).=0A=0A-gabriel=0A=0A----- O= riginal Message ----=0AFrom: Geoff Mulligan <geoff@mulligan.com>=0ATo: 6low= pan <6lowpan@lists.ietf.org>=0ASent: Friday, November 3, 2006 3:49:02 PM=0A= Subject: [6lowpan] Proposal for alternative 6lowpan header encoding=0A=0A= =0AFolks,=0A Arch Rock have submitted a proposal for a different 6lowpan h= eader=0Aencoding. David and Jonathan put together a set a slides to descri= be=0Atheir idea to simplify the 6lowpan adaptation header. They are workin= g=0Aon a complete proposal.=0A=0AI have posted the slides to the wiki at:= =0A=0Ahttp://6lowpan.tzi.org/FrontPage?action=3DAttachFile&do=3Dget&target= =3D6lowpan-header-proposal.ppt=0A=0AYou can also get a copy (if you are wik= i challenged) at:=0Ahttp://www.mulligan.com/6lowpan/6lowpan-header-proposal= .ppt=0A=0ATheir design seems to follow the ideas of IPv6, reduce the header= size=0Ain almost all cases, allow for extensions, byte align the fields an= d as=0AI've thought about coding it, it looks like less complex parsing.=0A= =0AWhile a proposal such as this (ideas tend to come on their own schedule)= =0Aat this late stage in our process will be disruptive, the potential=0Ava= lue of simplifying and fixing some of the identified problems in the=0Acurr= ent design is, in my opinion, worth the time and effort and risk to=0Aour a= lready blown schedule to evaluate and discuss within the group.=0A=0APlease= take a look at the slides. We only a have few days before the=0Ameeting o= n Wednesday and if possible I would like to hear peoples=0Athoughts. I hav= e asked Jonathan and David to attend the WG meeting and=0Ato prepare a more= in-depth presentation related to this new design.=0A=0A geoff=0A=0A= =0A=0A_______________________________________________=0A6lowpan mailing lis= t=0A6lowpan@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/6lowpan --0-1435905432-1162955773=:29601 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:courier, monaco, monospace, sans-serif;f= ont-size:12pt"><DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco,= monospace, sans-serif">By the way, </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt;= FONT-FAMILY: courier, monaco, monospace, sans-serif"> </DIV>=0A<DIV s= tyle=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-seri= f">In order to get an idea of what the format document would look like if w= e decided to go</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier= , monaco, monospace, sans-serif">ahead with its adoption, the Jonathan and = David have produced a tentative version of the </DIV>=0A<DIV style=3D"FONT-= SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">document. = Since this might help folks better evaluate the proposal, you can get it he= re:</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, mo= nospace, sans-serif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAM= ILY: courier, monaco, monospace, sans-serif"><A href=3D"http://briefcase.ya= hoo.com/bc/gabriel_montenegro_2000/lst?&.dir=3D/lowpan&.src=3Dbc&am= p;.view=3Dl">http://briefcase.yahoo.com/bc/gabriel_montenegro_2000/lst?&= ;.dir=3D/lowpan&.src=3Dbc&.view=3Dl</A><BR><BR>=0A<DIV style=3D"FON= T-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">BTW, th= is version is built on version 06 (with changes based on Geoff's review), s= ubmitted yesterday, and also available at the above URL (until it gets</DIV= >=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, = times, serif">officially published).</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt;= FONT-FAMILY: times new roman, new york, times, serif"> </DIV>=0A<DIV = style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, se= rif">-gabriel</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new= roman, new york, times, serif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12p= t; FONT-FAMILY: times new roman, new york, times, serif">----- Original Mes= sage ----<BR>From: Geoff Mulligan <geoff@mulligan.com><BR>To: 6lowpan= <6lowpan@lists.ietf.org><BR>Sent: Friday, November 3, 2006 3:49:02 P= M<BR>Subject: [6lowpan] Proposal for alternative 6lowpan header encoding<BR= ><BR>=0A<DIV>Folks,<BR> Arch Rock have submitted a proposal for = a different 6lowpan header<BR>encoding. David and Jonathan put t= ogether a set a slides to describe<BR>their idea to simplify the 6lowpan ad= aptation header. They are working<BR>on a complete proposal.<BR>= <BR>I have posted the slides to the wiki at:<BR><BR><A href=3D"http://6lowp= an.tzi.org/FrontPage?action=3DAttachFile&do=3Dget&target=3D6lowpan-= header-proposal.ppt" target=3D_blank>http://6lowpan.tzi.org/FrontPage?actio= n=3DAttachFile&do=3Dget&target=3D6lowpan-header-proposal.ppt</A><BR= ><BR>You can also get a copy (if you are wiki challenged) at:<BR><A href=3D= "http://www.mulligan.com/6lowpan/6lowpan-header-proposal.ppt" target=3D_bla= nk>http://www.mulligan.com/6lowpan/6lowpan-header-proposal.ppt</A><BR><BR>T= heir design seems to follow the ideas of IPv6, reduce the header size<BR>in= almost all cases, allow for extensions, byte align the fields and as<BR>I'= ve thought about coding it, it looks like less complex parsing.<BR><BR>While a proposal such as this (ideas tend to = come on their own schedule)<BR>at this late stage in our process will be di= sruptive, the potential<BR>value of simplifying and fixing some of the iden= tified problems in the<BR>current design is, in my opinion, worth the time = and effort and risk to<BR>our already blown schedule to evaluate and discus= s within the group.<BR><BR>Please take a look at the slides. We = only a have few days before the<BR>meeting on Wednesday and if possible I w= ould like to hear peoples<BR>thoughts. I have asked Jonathan and= David to attend the WG meeting and<BR>to prepare a more in-depth presentat= ion related to this new design.<BR><BR> = geoff<BR><BR><BR><BR>__________________________________________= _____<BR>6lowpan mailing list<BR>6lowpan@ietf.org<BR><A href=3D"https://www= 1.ietf.org/mailman/listinfo/6lowpan" target=3D_blank>https://www1.ietf.org/mailman/listinfo/6lowpan</A></DIV></= DIV><BR></DIV></div></body></html> --0-1435905432-1162955773=:29601-- --===============0365186587== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0365186587==-- From 6lowpan-bounces@ietf.org Wed Nov 08 02:36:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghhz9-0000oL-I0; Wed, 08 Nov 2006 02:36:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghhz7-0000ek-7B for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 02:36:33 -0500 Received: from maily.danfoss.com ([193.162.34.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghhz5-0001NV-Jp for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 02:36:33 -0500 Received: from DKDN04MX62.dkdn04.danfoss.net ([10.6.2.62]) by maily.danfoss.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 08:36:40 +0100 Received: from dkdn01mx21.danfoss.net ([10.12.129.21]) by DKDN04MX62.dkdn04.danfoss.net with InterScan Message Security Suite; Wed, 08 Nov 2006 08:36:40 +0100 Received: from DKDN01MX34.danfoss.net ([10.12.128.14]) by dkdn01mx21.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 08:36:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [6lowpan] Proposal for alternative 6lowpan header encoding Date: Wed, 8 Nov 2006 08:32:27 +0100 Message-ID: <49A38D2FE2C53946A57916AD6A1F00D7139368@DKDN01MX34.danfoss.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Proposal for alternative 6lowpan header encoding Thread-Index: AccC5PUe8SPznNZETD2Ys3Y3XNhOXgAIxWkt References: <20061108031613.30327.qmail@web81905.mail.mud.yahoo.com> From: "Schumacher Christian Peter Pii" <schumacher@danfoss.com> To: "gabriel montenegro" <gabriel_montenegro_2000@yahoo.com>, "Geoff Mulligan" <geoff@mulligan.com>, "6lowpan" <6lowpan@lists.ietf.org> X-OriginalArrivalTime: 08 Nov 2006 07:36:40.0090 (UTC) FILETIME=[A11B6FA0:01C70308] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-3.5.1048-14800.000 X-TM-AS-Result: No--21.013000-5.000000-2 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan@ietf.org> List-Help: <mailto:6lowpan-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0216770929==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0216770929== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70308.A0FFD72D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70308.A0FFD72D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gabriel. I'm having difficulty accessing the document at: http://briefcase.yahoo.com/bc/gabriel_montenegro_2000/lst?&.dir=3D/lowpan= &.src=3Dbc&.view=3Dl With Firefox I get a blank page. With Internet Explorer, it says "This folder is currently empty" What am I doing wrong? Thanks in advance -Christian -----Original Message----- From: gabriel montenegro [mailto:gabriel_montenegro_2000@yahoo.com] Sent: Wed 11/8/2006 4:16 AM To: Geoff Mulligan; 6lowpan Subject: Re: [6lowpan] Proposal for alternative 6lowpan header encoding =20 By the way,=20 In order to get an idea of what the format document would look like if = we decided to go ahead with its adoption, the Jonathan and David have produced a = tentative version of the=20 document. Since this might help folks better evaluate the proposal, you = can get it here: http://briefcase.yahoo.com/bc/gabriel_montenegro_2000/lst?&.dir=3D/lowpan= &.src=3Dbc&.view=3Dl BTW, this version is built on version 06 (with changes based on Geoff's = review), submitted yesterday, and also available at the above URL (until = it gets officially published). -gabriel ----- Original Message ---- From: Geoff Mulligan <geoff@mulligan.com> To: 6lowpan <6lowpan@lists.ietf.org> Sent: Friday, November 3, 2006 3:49:02 PM Subject: [6lowpan] Proposal for alternative 6lowpan header encoding Folks, Arch Rock have submitted a proposal for a different 6lowpan header encoding. David and Jonathan put together a set a slides to describe their idea to simplify the 6lowpan adaptation header. They are working on a complete proposal. I have posted the slides to the wiki at: http://6lowpan.tzi.org/FrontPage?action=3DAttachFile&do=3Dget&target=3D6l= owpan-header-proposal.ppt You can also get a copy (if you are wiki challenged) at: http://www.mulligan.com/6lowpan/6lowpan-header-proposal.ppt Their design seems to follow the ideas of IPv6, reduce the header size in almost all cases, allow for extensions, byte align the fields and as I've thought about coding it, it looks like less complex parsing. While a proposal such as this (ideas tend to come on their own schedule) at this late stage in our process will be disruptive, the potential value of simplifying and fixing some of the identified problems in the current design is, in my opinion, worth the time and effort and risk to our already blown schedule to evaluate and discuss within the group. Please take a look at the slides. We only a have few days before the meeting on Wednesday and if possible I would like to hear peoples thoughts. I have asked Jonathan and David to attend the WG meeting and to prepare a more in-depth presentation related to this new design. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan ------_=_NextPart_001_01C70308.A0FFD72D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7650.28"> <TITLE>RE: [6lowpan] Proposal for alternative 6lowpan header = encoding

It seemed like there was a very minor problem that = was reported in this respect,

=0A

and that very minor issue wo= uld be taken care of by Phil's suggestion of

=0A

slight reword= ing:

=0A

"If a link fragment is receiv= ed that overlaps another fragment as
identified above and di= ffers in either the size or datagram_offset of
the overlappe= d fragment..."

=0A

So I have taken that suggestion, which = basically implies adding the

=0A

part about "and differs in ei= ther the size or datagram_offset of
the overlapped fragment"= to the existing text.

=0A

-gabriel

=0A

----- Original Message ----=
From: Geoff Mulligan <geoff@mulligan.com>
To: gabriel monteneg= ro <gabriel_montenegro_2000@yahoo.com>
Cc: Philip Levis <pal@cs= .stanford.edu>; 6lowpan@ietf.org
Sent: Thursday, October 26, 2006 9:5= 9:20 PM
Subject: Re: [6lowpan] 802.15.4 behavior

=0A

Gabriel,=
  I'm wondering if the entire text around this should be elim= inated and
should the text about buffer handling?  These are i= mplementation details
and might instead be left as an exercise for the i= mplementer.

Maybe the text around overlapping fragments should read:=

If an overlapping fragment is received and that fragment is not aduplicate, this should be considered an error.

The implementation = can determine what to do with the current fragment or
the previously rec= eived fragments.

    geoff

On Thu, 2006-1= 0-26 at 14:53 -0700, gabriel montenegro wrote:
> Thanks for sharing t= his work, Phil.
> Is there anything in there that would prompt you to= suggest a change
> in the
> base format document?
>&nbs= p;
> Most of the points raised seem particularly relevant
&g= t; to the design of the routing protocols. As you know, the format
> document
> does not do this, so I'm wondering how much (if anything)= is relevant
> to it
> as opposed to the routing specifications= for lowpan (of which there
> are
> several drafts in existence= ). One could add some text calling for
> better
> feedback from= the link-layer (as the paper recommends), but I cannot
> see
>= what difference this would make on the actual protocol, as in, "bits
&g= t; in the air".
>
> I noticed that the first point = about links being bimodal leads to some
> text
> in the paper t= hat points out a potential flaw in the current fragment
> reassembly<= BR>> logic.
>
> In particular, your paper points= out some issue with this text in the
> format document:
> = ;
>    If a link fragment is received that = overlaps another fragment as
>    identified abov= e, the fragment(s) already accumulated in the
>    reas= sembly buffer SHALL be discarded.  A fresh reassembly may be
&= gt;    commenced with the most recently received link f= ragment.  Fragment
>    overlap is dete= rmined by the combination of datagram_offset from
> the
> =    encapsulation header and "Frame Length" from the 802.15.4= PPDU
> packet
>    header.
>
>= ; The text in the paper mentions an issue with duplicate fragments:
>=
>     ...if a system follows the 6lo= wpan requirements that an
> overlapping fragment
>  &= nbsp; flush all other fragments, then imperfect duplicate suppression=
> may cause a
>     receiver to flush frag= ments that were acknowledged at the data
> link layer.
> &= nbsp;
> I believe there is some confusion here. The intent is not for
> dupl= icate fragments to
> cause a flush of all previously received fragmen= ts. That case is
> actually not
> mentioned explicitly, but th= e sensible thing to do would be to simply
> ignore
> the duplic= ate fragments. These you can recognize by their datagram
> tags
&g= t; (dgram_tag), your header and the "Frame Length" from the 802.15.4
>= ; frame.
>
> The *intent* of the text is error-han= dling. If there is a
> non-duplicate fragment
> that has an ov= erlap (not a dup) over previously received fragments,
> this is an> error condition: this implies the sender laid out its IP datagram,> sliced it into
> fragments in two different ways and is sending= you fragments from
> those two
> different ways, using the sa= me datagram_tag. Very confusing.
>
> The normal oc= currence is for the sender to cut the IP datagram in only
> one given way,
&g= t; give it a datagram_tag and send those fragments out to the receiver.
= > The receiver
> will either:
>    1. r= eceive fragments with no overlap at all (they all cover
> different r= anges in
>       the original IP datag= ram), or
>    2. receive fragments which are dupl= icates (I guess one could call
> them "perfect
>  &n= bsp;    overlaps", hence the confusion above?)
> =
> I'm not sure how likely #2 is, but the format document certa= inly has
> no intention
> to mess with it.
>  <= BR>> Is this clearer? Would you suggest some text change to avoid this> confusion?
>
> thanks in advance for your co= mments or clarifications.
>
> -gabriel
>
= > ----- Original Message ----
> From: Philip Levis <pal@cs.stanford.edu&g= t;
> To: 6lowpan@ietf.org
> Sent: Thursday, October 26, 2006 7:= 21:52 AM
> Subject: [6lowpan] 802.15.4 behavior
>
> The = discussions on this list led Kannan Srinivasan, one of the
&= gt; students working with me, to submit a paper to HotNets. It was just&nbs= p;
> accepted. Given that the IETF is in two weeks, we probably= won't
> have
> the camera-ready prepared by then, = so the link below is for the
> submitted version. The tit= le of the paper is "Some Implications of
> Low-Power Wire= less to IP Routing." It examines the behavior of
> 802.15= .4 using the ChipCon 2420 radio on common sensor node
> p= latforms. The four key observations are:
>
>   o Lin= ks are predominantly bimodal for short packet bursts.
>   o= Sporadic traffic observes intermediate links, which are due to
> = SNR variations.
>   o There are ETX asymmetries, which are = larger over longer time
> intervals.
>   = o Acknowledgement failures are correlated.
>
> I thought this = community might find the paper helpful. It's 6 pages,
> s= o not a long read.
>
> http://csl.stanford.edu/~pal/pu= bs/hotnets-v-submit.pdf
>
> See you in San Diego...
>= ;
> Phil
>
>
>
> ________________________= _______________________
> 6lowpan mailing list
> 6lowpan@ietf.o= rg
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
&= gt;
> _______________________________________________
> 6lowpa= n mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listin= fo/6lowpan

=0A

--0-923374713-1162587340=:59074-- --===============0617142010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0617142010==-- From 6lowpan-bounces@ietf.org Fri Nov 03 15:59:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg68J-00007K-GT; Fri, 03 Nov 2006 15:59:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg68H-00006I-Kk for 6lowpan@lists.ietf.org; Fri, 03 Nov 2006 15:59:21 -0500 Received: from web81914.mail.mud.yahoo.com ([68.142.207.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gg68G-0002eS-8Y for 6lowpan@lists.ietf.org; Fri, 03 Nov 2006 15:59:21 -0500 Received: (qmail 4854 invoked by uid 60001); 3 Nov 2006 20:59:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=0rMGh/KEFYjCqlTBoRvab1C3P6A8dub4XkHxjyhCVH2WI8wJPbkI2BRdm/LwnpzyWSfjC5gvTwknKz/2+lA0ETZAYuTp484nYDH5tQIBVIMxt6l1tNJG3ebAawLxxKCn8VKMjBcOEB6Rmr/X7NJcZSUgz7XnwV4AEZXWEwa262s= ; Message-ID: <20061103205914.4852.qmail@web81914.mail.mud.yahoo.com> Received: from [131.107.0.103] by web81914.mail.mud.yahoo.com via HTTP; Fri, 03 Nov 2006 12:59:14 PST Date: Fri, 3 Nov 2006 12:59:14 -0800 (PST) From: gabriel montenegro Subject: Re: [6lowpan] comments on draft 5 To: Philip Levis , Geoff Mulligan MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1925162014==" Errors-To: 6lowpan-bounces@ietf.org --===============1925162014== Content-Type: multipart/alternative; boundary="0-878272963-1162587554=:1958" --0-878272963-1162587554=:1958 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Yeah, IPv6 fragment handling, for example, does deal with error conditions,= and even=0Awith conditions which may seem out of the ordinary but which sh= ouldn't be considered=0Aerrors.=0A=0A-gabriel=0A=0A=0A----- Original Messag= e ----=0AFrom: Philip Levis =0ATo: Geoff Mulligan =0ACc: 6lowpan <6lowpan@lists.ietf.org>=0ASent: Friday, Oct= ober 27, 2006 9:00:49 AM=0ASubject: Re: [6lowpan] comments on draft 5=0A=0A= =0AOn Oct 26, 2006, at 11:30 PM, Geoff Mulligan wrote:=0A=0A>=0A> For the s= ame reason and and per the discussion with Phil, I think that=0A> the next = paragraph (starting with "If a link fragment") should also be=0A> removed.= =0A=0AI'd differ on this one; it's good to describe what to do in error = =0Aconditions without constraining the implementation unduly. Otherwise = =0Aadversaries can profile your device based on its responses. That =0Abei= ng said, it's really not a big deal, and so if nobody else feels =0Astrong= ly in this direction I have no objections to removing the =0Aparagraph.=0A= =0APhil=0A=0A_______________________________________________=0A6lowpan mail= ing list=0A6lowpan@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/6lowpa= n --0-878272963-1162587554=:1958 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable

Yeah, IPv6 fragment handling, for example, does dea=
l with error conditions, and even
=0Awith conditions which ma=
y seem out of the ordinary but which shouldn't be considered
=0Aerrors.
=0A 
=0A-gabriel

=
=0A----- Original Message ----
From: Philip Levis <pal@cs.s=
tanford.edu>
To: Geoff Mulligan <geoff@mulligan.com>
Cc: 6lo=
wpan <6lowpan@lists.ietf.org>
Sent: Friday, October 27, 2006 9:00:=
49 AM
Subject: Re: [6lowpan] comments on draft 5

=0AOn Oct 2=
6, 2006, at 11:30 PM, Geoff Mulligan wrote:

>
> For the sam=
e reason and and per the discussion with Phil, I think that
> the nex=
t paragraph (starting with "If a link fragment") should also be
> rem=
oved.

I'd differ on this one; it's good to describe what to do in er=
ror  
conditions without constraining the implementation undul=
y. Otherwise  
adversaries can profile your device based on it=
s responses. That  
being said, it's really not a big deal, an=
d so if nobody else feels  
strongly in this direction I have =
no objections to removing the  
paragraph.

Phil

=
_______________________________________________
6lowpan mailing list
=
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan
=0A

--0-878272963-1162587554=:1958--


--===============1925162014==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--===============1925162014==--




From 6lowpan-bounces@ietf.org Fri Nov 03 17:52:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gg7tO-0005Vj-QB; Fri, 03 Nov 2006 17:52:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg7tN-0005Vd-4n
	for 6lowpan@lists.ietf.org; Fri, 03 Nov 2006 17:52:05 -0500
Received: from web81907.mail.mud.yahoo.com ([68.142.207.186])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gg7tM-00057X-4t
	for 6lowpan@lists.ietf.org; Fri, 03 Nov 2006 17:52:05 -0500
Received: (qmail 52752 invoked by uid 60001); 3 Nov 2006 22:52:03 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type;
	b=p0Zg75ehbU4SwaDYm/4d13V5id4SfXbojOMraRxvv3BoQ+oop1C1F2dWIF77YQDsX03aLhBpu3SzFYbAznCKe88rnikyZiIk4OSLWnFs3o/mnWSZb1QaVrSYmkuBAVzF0PAbqiEgjUVr70P0WwnUsvBWQY+/4krqclzdNqjEGog=
	; 
Message-ID: <20061103225203.52750.qmail@web81907.mail.mud.yahoo.com>
Received: from [131.107.0.103] by web81907.mail.mud.yahoo.com via HTTP;
	Fri, 03 Nov 2006 14:52:03 PST
Date: Fri, 3 Nov 2006 14:52:03 -0800 (PST)
From: gabriel montenegro 
Subject: Re: [6lowpan] comments on draft 5
To: Geoff Mulligan , 6lowpan <6lowpan@lists.ietf.org>
MIME-Version: 1.0
X-Spam-Score: 1.2 (+)
X-Scan-Signature: be922d419820e291bde1362184dc32fd
Cc: 
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0397663721=="
Errors-To: 6lowpan-bounces@ietf.org

--===============0397663721==
Content-Type: multipart/alternative; boundary="0-597177791-1162594323=:52295"

--0-597177791-1162594323=:52295
Content-Type: text/plain; charset=ascii
Content-Transfer-Encoding: quoted-printable

inline marked "gm>" =0A=0A=0A----- Original Message ----=0AFrom: Geoff Mull=
igan =0ATo: 6lowpan <6lowpan@lists.ietf.org>=0ASent: Th=
ursday, October 26, 2006 11:30:55 PM=0ASubject: [6lowpan] comments on draft=
 5=0A=0A=0AGabriel,=0A  First some editorial comments:=0A=0ASection 3 Parag=
raph 1 Line 12 - occurred should be occurring=0A=0Agm> Fixed, thanks.=0A=0A=
Section 5.1 Paragraph on datagram_size (page 8): I think that the NOTE:=0As=
hould read:=0A=0AWhile it may appear that this field does not need to be in=
 every packet,=0Aas one could send it with the first fragment and elide it =
subsequently,=0Ait is included it in every link fragment to ease the task o=
f reassembly=0Ain the event that a second (or subsequent) link fragment arr=
ives before=0Athe first. ...=0A=0Agm> I don't agree with the"it may appear"=
. It's not just appearance, one can=0Aactually elide it. I have not put in =
any change here.=0A=0ASection 5.2: Possible rewrite:=0A=0AThe recipient of =
link fragments SHALL use (1) ...=0A=0Agm> Ok, done.=0A=0AI think that the n=
ext paragraph in the text, the paragraph starting with=0A"Upon receipt" sho=
uld be removed since this is an implementation choice.=0A=0AFor the same re=
ason and and per the discussion with Phil, I think that=0Athe next paragrap=
h (starting with "If a link fragment") should also be=0Aremoved.=0A=0Agm> P=
hil and I feel like this is good info to have, but I have made some changes=
=0Ato try to soften the prescriptiveness of the text, while still leaving i=
n some=0Ainfo for implementors.=0A=0AAnd for the same reason, this is an im=
plementation detail, the paragraph=0Astarting with "Upon detection of a IEE=
E" should be removed unless there=0Ais a specific reason for the 15 second =
time out - where did 15 seconds=0Acome from?=0A=0Agm> I think we found it i=
n someone's hat. You have a point. If we look at =0Arfc 2460, IPv6 implemen=
ts a hard reassembly timeout of 60 seconds.=0ASince what we at the lowpan l=
evel may be transporting could potentially=0Abe an IPv6 fragmented packet, =
it makes no sense for us to hold on to=0Aour lower-layer reassembly process=
 longer than that. So I've changed=0Aour text to reflect the fact that we r=
ecommend some reassembly timeout =0Awhich should not exceed 60 sec.=0A=0Agm=
> Since there are several changes to this reassembly section here it is as =
it looks now after the tentative changes:=0A=0A5.2  Reassembly=0A=0A   The =
recipient of link fragments SHALL use (1) the sender's 802.15.4=0A   source=
 address (or the Originator Address if a Mesh Delivery field is=0A   presen=
t), (2) the destination's 802.15.4 address (or the Final=0A   Destination a=
ddress if a Mesh Delivery field is present), (3)=0A   datagram_size and (4)=
 datagram_tag to identify all the link fragments=0A   that belong to a give=
n datagram.=0A=0A   Upon receipt of a link fragment, the recipient starts c=
onstructing=0A   the original unfragmented packet whose size is datagram_si=
ze.  It=0A   uses the datagram_offset field to determine the location of th=
e=0A   individual fragments within the original unfragmented packet.  For=
=0A   example, it may place the data payload (except the encapsulation=0A  =
 header) within a payload datagram reassembly buffer at the location=0A   s=
pecified by datagram_offset.  The size of the reassembly buffer=0A   SHALL =
be determined from datagram_size.=0A=0A   If a link fragment is received th=
at overlaps another fragment as=0A   identified above and differs in either=
 the size or datagram_offset of=0A   the overlapped fragment, the fragment(=
s) already accumulated in the=0A   reassembly buffer SHALL be discarded.  A=
 fresh reassembly may be=0A   commenced with the most recently received lin=
k fragment.  Fragment=0A   overlap is determined by the combination of data=
gram_offset from the=0A   encapsulation header and "Frame Length" from the =
802.15.4 PPDU packet=0A   header.=0A=0A   Upon detection of a IEEE 802.15.4=
 Disassociation event, fragment=0A   recipients SHOULD discard all link fra=
gments of all partially=0A   reassembled payload datagrams, and fragment se=
nders SHOULD discard=0A   all not yet transmitted link fragments of all par=
tially transmitted=0A   payload (e.g., IPv6) datagrams.  Similarly, when a =
node first=0A   receives a fragment with a given datagram_tag, it starts a =
reassembly=0A   timer.  When this time expires, if the entire packet has no=
t been=0A   reassembled, the existing fragments SHOULD be discarded and the=
=0A   reassembly state SHOULD be flushed.  The reassembly timeout MUST be=
=0A   set to a maximum of 60 seconds (this is also the timeout in the IPv6=
=0A   reassembly procedure [RFC2460] ).=0A=0A=0ASection 6: Paragraph 2 Line=
 6: I'm not sure that the phrase=0A"concatenated with" is clear as to the o=
rdering.  I'm not sure that=0A"concatenated to" is precise (as used in the =
previous sentence).=0A=0Agm> I had added some illustration of what the resu=
lt looks like, but perhaps=0Athat is lost in the text. I've now modified to=
 more clearly show this and the=0Arelevant text now looks like this:=0A=0A =
  All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short=0A   a=
ddresses (Section 3 and Section 12) are also possible.  In these=0A   cases=
, a "pseudo 48-bit address" is formed as follows.  First, the=0A   left-mos=
t 32 bits are formed by concatenating 16 zero bits to the 16-=0A   bit PAN =
ID (alternatively, if no PAN ID is known, 16 zero bits may be=0A   used).  =
This produces a 32-bit field as follows:=0A=0A      16_bit_PAN:16_zero_bits=
=0A=0A   Then, these 32 bits are concatenated with the 16-bit short address=
.=0A   This produces a 48-bit address as follows:=0A=0A      32_bits_as_spe=
cified_previously:16_bit_short_address=0A=0A   The interface identifier is =
formed from this 48-bit address as per=0A=0ASection 10.1: I think that it s=
hould be written as:=0A=0AIt is possible to use header compression even in =
advance of setting up=0Athe customary state.  The following common IPv6 hea=
der...=0A=0Agm> Not sure about this. "in advance" implies we will eventuall=
y enter a context-building=0Aphase for header compression. But this is not =
what we do. We don't have the customary=0A(for header compression) context-=
building phase. So "in absence" describes what we do,=0AI think.=0A=0AAppen=
dix A Paragraph 1 line 18: frament should be fragment.=0A=0Agm> Ok, thanks.=
=0A=0AQuestions:=0A=0ASection 5.1 Paragraph on datagram_size (page 8): The =
datagram_size is=0Aset to 40 octets more than the  Payload Length value in =
the IPv6 header,=0Abut if the IPv6 header is compressed doesn't this lead t=
o the wrong=0Adatagram size calculation?=0A=0Agm> Ok, added "uncompressed" =
before "IPv6 header".=0A=0ASection 5.1 Encapsulation header format (meta qu=
estion): if we were to=0Aallow multiple mesh protocols under this adaptatio=
n layer do we think=0Athat this should be carried in the prot_type field or=
 should we add or=0Adefine the "rsv" field for the mesh network type, thoug=
h 3 bits would=0Aprobably suffice or should we add one more byte.  I think =
that this is=0Apartially what David was asking about.  Having this flexibil=
ity might be=0Aespecially important to allow for diagnosing the mesh layer.=
=0A=0Agm> I think we've already answered this question a while back with th=
e=0Adrafts on DyMO, LOAD, etc. These are protocols that run on top of the l=
owpan=0Alayer, just like IPv6 itself runs on the lowpan layer. In our  curr=
ent design,=0Aone runs one protocol at a time on top of the lowpan adaptati=
on layer.=0ASo one would run a mesh routing protocol of choice to set up ro=
utes=0Aand populate nodes with the appropriate topological information.=0AS=
ubsequent to that, any other protocol on top of that adaptation layer=0A(e.=
g., IPv6, appletalk, IPv4, whatever) could use the mesh delivery.=0AThe "B"=
 bit and the mesh delivery field are only used for the delivery=0Aof data o=
n a mesh. The control plane for the mesh is determined by prot_type=0Aand i=
s done with any of several mesh routing protocols.=0A=0ASection 9 about Mul=
ticast Address mapping:  Does this preclude a network=0Afrom using 64-bit a=
ddressing for multicasting?  It seems to indicate=0Athat you must use 16-bi=
t addresses for multicast addresses.=0A=0Agm> The mesh delivery header for =
multicast does not preclude that, as it also=0Aincludes the "O" and "F" bit=
s to signal 16 or 64 bit address length. So one could=0Ain the future defin=
e the mapping from IPv6 multicast to 64-bit addresses, but =0Awe're not doi=
ng that now. This could be a separate document for which I don't=0Asee much=
 urgency in current networks. =0A=0ASection 10.2 in the Length (bit 2) para=
graph:  can we really compute the=0Audp length field from the possibly comp=
ressed frame length field or the=0Adatagram_size field in a fragment header=
?  Is this a simple calculation?=0A=0Agm> The frame length is never compres=
sed. It is part of the layer 2 802.15.4=0Aheader which we do not control. T=
he value of the UDP length field is equal=0Ato the Payload Length from the =
IPv6 header, minus the length of any extension=0Aheaders present between th=
e IPv6 header and the UDP header.  I've added this=0Asentence to clarify.=
=0A=0ASection 11 - It doesn't look like we fixed the problem with the seque=
nce=0Anumber before the destination address?  Did I miss a different soluti=
on?=0A=0Agm> We added the 'B' bit. The paragraph before figure 10 now has t=
his text,=0Afor example:=0A=0A   There are two types of Mesh delivery field=
s: the "Unicast Mesh=0A   Delivery Field" (Figure 10), and the "Broadcast o=
r Multicast Mesh=0A   Delivery Field" (Figure 11).  The former is used if t=
he 'B' bit is=0A   set to zero, and the latter is used if the 'B' bit is se=
t to 1.  The=0A   'B' bit appears in all variations of the LoWPAN encapsula=
tion header=0A   (Section 5). =0A-gabriel=0A=0A=0A=0A=0A___________________=
____________________________=0A6lowpan mailing list=0A6lowpan@ietf.org=0Aht=
tps://www1.ietf.org/mailman/listinfo/6lowpan
--0-597177791-1162594323=:52295
Content-Type: text/html; charset=ascii
Content-Transfer-Encoding: quoted-printable

inline marked "gm>" 

=0A----- O=
riginal Message ----
From: Geoff Mulligan <geoff@mulligan.com>
=
To: 6lowpan <6lowpan@lists.ietf.org>
Sent: Thursday, October 26, 2=
006 11:30:55 PM
Subject: [6lowpan] comments on draft 5

=0AGa=
briel,
  First some editorial comments:

Section 3 Parag=
raph 1 Line 12 - occurred should be occurring
=0Agm> Fixed=
, thanks.
=0A
Section 5.1 Paragraph on datagram_size (page 8):=
 I think that the NOTE:
should read:

While it may appear that thi=
s field does not need to be in every packet,
as one could send it with t=
he first fragment and elide it subsequently,
it is included it in every =
link fragment to ease the task of reassembly
in the event that a second =
(or subsequent) link fragment arrives before
the first. ...
=0A=
gm> I don't agree with the"it may appear". It's not just appearance=
, one can
=0Aactually elide it. I have not put in any change here=
.
=0A
Section 5.2: Possible rewrite:

The recipient of l=
ink fragments SHALL use (1) ...
=0Agm> Ok, done.
=0A<=
DIV>
I think that the next paragraph in the text, the paragraph starting=
 with
"Upon receipt" should be removed since this is an implementation c=
hoice.

For the same reason and and per the discussion with Phil, I t=
hink that
the next paragraph (starting with "If a link fragment") should=
 also be
removed.
=0Agm> Phil and I feel like this is g=
ood info to have, but I have made some changes
=0Ato try to softe=
n the prescriptiveness of the text, while still leaving in some
=0Ainfo for implementors.
=0A
And for the same reason, this is =
an implementation detail, the paragraph
starting with "Upon detection of=
 a IEEE" should be removed unless there
is a specific reason for the 15 =
second time out - where did 15 seconds
come from?
=0A =0Agm> I think we found it in someone's hat. You have a point. I=
f we look at 
=0Arfc 2460, IPv6 implements a hard reassembly time=
out of 60 seconds.
=0ASince what we at the lowpan level may be tr=
ansporting could potentially
=0Abe an IPv6 fragmented packet, it =
makes no sense for us to hold on to
=0Aour lower-layer reassembly=
 process longer than that. So I've changed
=0Aour text to reflect=
 the fact that we recommend some reassembly timeout 
=0Awhich sho=
uld not exceed 60 sec.
=0A 
=0Agm> Since there =
are several changes to this reassembly section here it is as it looks now a=
fter the tentative changes:
=0A 
5.2  Reassembly=
=0A=0A   The recipient of link fragments SHALL use (1) the sender's 802.15.=
4=0A   source address (or the Originator Address if a Mesh Delivery field i=
s=0A   present), (2) the destination's 802.15.4 address (or the Final=0A   =
Destination address if a Mesh Delivery field is present), (3)=0A   datagram=
_size and (4) datagram_tag to identify all the link fragments=0A   that bel=
ong to a given datagram.=0A=0A   Upon receipt of a link fragment, the recip=
ient starts constructing=0A   the original unfragmented packet whose size i=
s datagram_size.  It=0A   uses the datagram_offset field to determine the l=
ocation of the=0A   individual fragments within the original unfragmented p=
acket.  For=0A   example, it may place the data payload (except the encapsu=
lation=0A   header) within a payload datagram reassembly buffer at the loca=
tion=0A   specified by datagram_offset.  The size of the reassembly buffer=
=0A   SHALL be determined from datagram_size.=0A=0A   If a link fragment is=
 received that overlaps another fragment as=0A   identified above and diffe=
rs in either the size or datagram_offset of=0A   the overlapped fragment, t=
he fragment(s) already accumulated in the=0A   reassembly buffer SHALL be d=
iscarded.  A fresh reassembly may be=0A   commenced with the most recently =
received link fragment.  Fragment=0A   overlap is determined by the combina=
tion of datagram_offset from the=0A   encapsulation header and "Frame Lengt=
h" from the 802.15.4 PPDU packet=0A   header.=0A=0A   Upon detection of a I=
EEE 802.15.4 Disassociation event, fragment=0A   recipients SHOULD discard =
all link fragments of all partially=0A   reassembled payload datagrams, and=
 fragment senders SHOULD discard=0A   all not yet transmitted link fragment=
s of all partially transmitted=0A   payload (e.g., IPv6) datagrams.  Simila=
rly, when a node first=0A   receives a fragment with a given datagram_tag, =
it starts a reassembly=0A   timer.  When this time expires, if the entire p=
acket has not been=0A   reassembled, the existing fragments SHOULD be disca=
rded and the=0A   reassembly state SHOULD be flushed.  The reassembly timeo=
ut MUST be=0A   set to a maximum of 60 seconds (this is also the timeout in=
 the IPv6=0A   reassembly procedure [RFC2460] ).=0A

Secti=
on 6: Paragraph 2 Line 6: I'm not sure that the phrase
"concatenated wit=
h" is clear as to the ordering.  I'm not sure that
"concatenat=
ed to" is precise (as used in the previous sentence).
=0Agm&g=
t; I had added some illustration of what the result looks like, but perhaps=
=0Athat is lost in the text. I've now modified to more clearly s=
how this and the
=0Arelevant text now looks like this:
=0A 
   All 802.15.4 devices have an IEEE EUI-64 address, bu=
t 16-bit short=0A   addresses (Section 3 and Section 12) are also possible.=
  In these=0A   cases, a "pseudo 48-bit address" is formed as follows.  Fir=
st, the=0A   left-most 32 bits are formed by concatenating 16 zero bits to =
the 16-=0A   bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits=
 may be=0A   used).  This produces a 32-bit field as follows:=0A=0A      16=
_bit_PAN:16_zero_bits=0A=0A   Then, these 32 bits are concatenated with the=
 16-bit short address.=0A   This produces a 48-bit address as follows:=0A=
=0A      32_bits_as_specified_previously:16_bit_short_address=0A=0A   The i=
nterface identifier is formed from this 48-bit address as per=0A=

Section 10.1: I think that it should be written as:

It is possib=
le to use header compression even in advance of setting up
the customary=
 state.  The following common IPv6 header...
=0A <=
/DIV>=0Agm> Not sure about this. "in advance" implies we will event=
ually enter a context-building
=0Aphase for header compression. B=
ut this is not what we do. We don't have the customary
=0A(for he=
ader compression) context-building phase. So "in absence" describes what we=
 do,
=0AI think.

Appendix A Paragraph 1 line 18: frament s=
hould be fragment.

gm> Ok, thanks.
=0A
Questions:
Section 5.1 Paragraph on datagram_size (page 8): The datagram_size is<=
BR>set to 40 octets more than the  Payload Length value in the IP=
v6 header,
but if the IPv6 header is compressed doesn't this lead to the=
 wrong
datagram size calculation?
=0Agm> Ok, added "unc=
ompressed" before "IPv6 header".
=0A
Section 5.1 Encapsulation=
 header format (meta question): if we were to
allow multiple mesh protoc=
ols under this adaptation layer do we think
that this should be carried =
in the prot_type field or should we add or
define the "rsv" field for th=
e mesh network type, though 3 bits would
probably suffice or should we a=
dd one more byte.  I think that this is
partially what David w=
as asking about.  Having this flexibility might be
especially =
important to allow for diagnosing the mesh layer.
=0A 
=
=0Agm> I think we've already answered this question a while back wi=
th the
=0Adrafts on DyMO, LOAD, etc. These are protocols that run=
 on top of the lowpan
=0Alayer, just like IPv6 itself runs on the=
 lowpan layer. In our  current design,
=0Aone runs one proto=
col at a time on top of the lowpan adaptation layer.
=0ASo one wo=
uld run a mesh routing protocol of choice to set up routes
=0Aand=
 populate nodes with the appropriate topological information.
=0A=
Subsequent to that, any other protocol on top of that adaptation layer=0A(e.g., IPv6, appletalk, IPv4, whatever) could use the mesh deliver=
y.
=0AThe "B" bit and the mesh delivery field are only used for t=
he delivery
=0Aof data on a mesh. The control plane for the mesh =
is determined by prot_type
=0Aand is done with any of several mes=
h routing protocols.

Section 9 about Multicast Address mapping: =
; Does this preclude a network
from using 64-bit addressing for mul=
ticasting?  It seems to indicate
that you must use 16-bit addr=
esses for multicast addresses.
=0A 
=0Agm> The =
mesh delivery header for multicast does not preclude that, as it also
=
=0Aincludes the "O" and "F" bits to signal 16 or 64 bit address length=
. So one could
=0Ain the future define the mapping from IPv6 mult=
icast to 64-bit addresses, but 
=0Awe're not doing that now. This=
 could be a separate document for which I don't
=0Asee much urgen=
cy in current networks. 

Section 10.2 in the Length (bit 2) paragrap=
h:  can we really compute the
udp length field from the possib=
ly compressed frame length field or the
datagram_size field in a fragmen=
t header?  Is this a simple calculation?
=0Agm> =
The frame length is never compressed. It is part of the layer 2 802.15.4=0Aheader which we do not control. The value of the UDP length fiel=
d is equal
=0Ato the Payload Length from the IPv6 header, minus t=
he length of any extension
=0Aheaders present between the IPv6 he=
ader and the UDP header.  I've added this
=0Asentence to cla=
rify.
=0A
Section 11 - It doesn't look like we fixed the probl=
em with the sequence
number before the destination address?  D=
id I miss a different solution?
=0Agm> We added the 'B' bi=
t. The paragraph before figure 10 now has this text,
=0Afor examp=
le:
=0A 
   There are two types of Mesh delivery f=
ields: the "Unicast Mesh=0A   Delivery Field" (Figure 10), and the "Broadca=
st or Multicast Mesh=0A   Delivery Field" (Figure 11).  The former is used =
if the 'B' bit is=0A   set to zero, and the latter is used if the 'B' bit i=
s set to 1.  The=0A   'B' bit appears in all variations of the LoWPAN encap=
sulation header=0A   (Section 5). 
=0A-gabriel=0A=




_______________________________________________
6lowpan =
mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/=
6lowpan


--0-597177791-1162594323=:52295--


--===============0397663721==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--===============0397663721==--




From 6lowpan-bounces@ietf.org Fri Nov 03 18:14:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gg8F4-00022O-JG; Fri, 03 Nov 2006 18:14:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8F3-000228-6n
	for 6lowpan@lists.ietf.org; Fri, 03 Nov 2006 18:14:29 -0500
Received: from grab.coslabs.com ([199.233.92.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg8Ey-0000br-II
	for 6lowpan@lists.ietf.org; Fri, 03 Nov 2006 18:14:27 -0500
Received: from x1.coslabs.com (x1.coslabs.com [199.233.92.20])
	by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id kA3NE566026649;
	Fri, 3 Nov 2006 16:14:05 -0700 (MST)
Subject: Re: [6lowpan] comments on draft 5
From: Geoff Mulligan 
To: gabriel montenegro 
In-Reply-To: <20061103225203.52750.qmail@web81907.mail.mud.yahoo.com>
References: <20061103225203.52750.qmail@web81907.mail.mud.yahoo.com>
Content-Type: text/plain
Date: Fri, 03 Nov 2006 16:14:00 -0700
Message-Id: <1162595640.5112.9.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.1 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df
Cc: 6lowpan <6lowpan@lists.ietf.org>
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

Excellent Gabriel.  Thanks again for taking on the load of continuing to
edit the draft for the working group!

	geoff

On Fri, 2006-11-03 at 14:52 -0800, gabriel montenegro wrote:
> inline marked "gm>" 
> 
> ----- Original Message ----
> From: Geoff Mulligan 
> To: 6lowpan <6lowpan@lists.ietf.org>
> Sent: Thursday, October 26, 2006 11:30:55 PM
> Subject: [6lowpan] comments on draft 5
> 
> Gabriel,
>   First some editorial comments:
> 
> Section 3 Paragraph 1 Line 12 - occurred should be occurring
> 
> gm> Fixed, thanks.
> 
> Section 5.1 Paragraph on datagram_size (page 8): I think that the
> NOTE:
> should read:
> 
> While it may appear that this field does not need to be in every
> packet,
> as one could send it with the first fragment and elide it
> subsequently,
> it is included it in every link fragment to ease the task of
> reassembly
> in the event that a second (or subsequent) link fragment arrives
> before
> the first. ...
> 
> gm> I don't agree with the"it may appear". It's not just appearance,
> one can
> actually elide it. I have not put in any change here.
> 
> Section 5.2: Possible rewrite:
> 
> The recipient of link fragments SHALL use (1) ...
> 
> gm> Ok, done.
> 
> I think that the next paragraph in the text, the paragraph starting
> with
> "Upon receipt" should be removed since this is an implementation
> choice.
> 
> For the same reason and and per the discussion with Phil, I think that
> the next paragraph (starting with "If a link fragment") should also be
> removed.
> 
> gm> Phil and I feel like this is good info to have, but I have made
> some changes
> to try to soften the prescriptiveness of the text, while still leaving
> in some
> info for implementors.
> 
> And for the same reason, this is an implementation detail, the
> paragraph
> starting with "Upon detection of a IEEE" should be removed unless
> there
> is a specific reason for the 15 second time out - where did 15 seconds
> come from?
>  
> gm> I think we found it in someone's hat. You have a point. If we look
> at 
> rfc 2460, IPv6 implements a hard reassembly timeout of 60 seconds.
> Since what we at the lowpan level may be transporting could
> potentially
> be an IPv6 fragmented packet, it makes no sense for us to hold on to
> our lower-layer reassembly process longer than that. So I've changed
> our text to reflect the fact that we recommend some reassembly
> timeout 
> which should not exceed 60 sec.
>  
> gm> Since there are several changes to this reassembly section here it
> is as it looks now after the tentative changes:
>  
> 5.2  Reassembly
> 
>    The recipient of link fragments SHALL use (1) the sender's 802.15.4
>    source address (or the Originator Address if a Mesh Delivery field is
>    present), (2) the destination's 802.15.4 address (or the Final
>    Destination address if a Mesh Delivery field is present), (3)
>    datagram_size and (4) datagram_tag to identify all the link fragments
>    that belong to a given datagram.
> 
>    Upon receipt of a link fragment, the recipient starts constructing
>    the original unfragmented packet whose size is datagram_size.  It
>    uses the datagram_offset field to determine the location of the
>    individual fragments within the original unfragmented packet.  For
>    example, it may place the data payload (except the encapsulation
>    header) within a payload datagram reassembly buffer at the location
>    specified by datagram_offset.  The size of the reassembly buffer
>    SHALL be determined from datagram_size.
> 
>    If a link fragment is received that overlaps another fragment as
>    identified above and differs in either the size or datagram_offset of
>    the overlapped fragment, the fragment(s) already accumulated in the
>    reassembly buffer SHALL be discarded.  A fresh reassembly may be
>    commenced with the most recently received link fragment.  Fragment
>    overlap is determined by the combination of datagram_offset from the
>    encapsulation header and "Frame Length" from the 802.15.4 PPDU packet
>    header.
> 
>    Upon detection of a IEEE 802.15.4 Disassociation event, fragment
>    recipients SHOULD discard all link fragments of all partially
>    reassembled payload datagrams, and fragment senders SHOULD discard
>    all not yet transmitted link fragments of all partially transmitted
>    payload (e.g., IPv6) datagrams.  Similarly, when a node first
>    receives a fragment with a given datagram_tag, it starts a reassembly
>    timer.  When this time expires, if the entire packet has not been
>    reassembled, the existing fragments SHOULD be discarded and the
>    reassembly state SHOULD be flushed.  The reassembly timeout MUST be
>    set to a maximum of 60 seconds (this is also the timeout in the IPv6
>    reassembly procedure [RFC2460] ).
> 
> 
> Section 6: Paragraph 2 Line 6: I'm not sure that the phrase
> "concatenated with" is clear as to the ordering.  I'm not sure that
> "concatenated to" is precise (as used in the previous sentence).
> 
> gm> I had added some illustration of what the result looks like, but
> perhaps
> that is lost in the text. I've now modified to more clearly show this
> and the
> relevant text now looks like this:
>  
>    All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short
>    addresses (Section 3 and Section 12) are also possible.  In these
>    cases, a "pseudo 48-bit address" is formed as follows.  First, the
>    left-most 32 bits are formed by concatenating 16 zero bits to the 16-
>    bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits may be
>    used).  This produces a 32-bit field as follows:
> 
>       16_bit_PAN:16_zero_bits
> 
>    Then, these 32 bits are concatenated with the 16-bit short address.
>    This produces a 48-bit address as follows:
> 
>       32_bits_as_specified_previously:16_bit_short_address
> 
>    The interface identifier is formed from this 48-bit address as per
> 
> Section 10.1: I think that it should be written as:
> 
> It is possible to use header compression even in advance of setting up
> the customary state.  The following common IPv6 header...
>  
> gm> Not sure about this. "in advance" implies we will eventually enter
> a context-building
> phase for header compression. But this is not what we do. We don't
> have the customary
> (for header compression) context-building phase. So "in absence"
> describes what we do,
> I think.
> 
> Appendix A Paragraph 1 line 18: frament should be fragment.
> 
> gm> Ok, thanks.
> 
> Questions:
> 
> Section 5.1 Paragraph on datagram_size (page 8): The datagram_size is
> set to 40 octets more than the  Payload Length value in the IPv6
> header,
> but if the IPv6 header is compressed doesn't this lead to the wrong
> datagram size calculation?
> 
> gm> Ok, added "uncompressed" before "IPv6 header".
> 
> Section 5.1 Encapsulation header format (meta question): if we were to
> allow multiple mesh protocols under this adaptation layer do we think
> that this should be carried in the prot_type field or should we add or
> define the "rsv" field for the mesh network type, though 3 bits would
> probably suffice or should we add one more byte.  I think that this is
> partially what David was asking about.  Having this flexibility might
> be
> especially important to allow for diagnosing the mesh layer.
>  
> gm> I think we've already answered this question a while back with the
> drafts on DyMO, LOAD, etc. These are protocols that run on top of the
> lowpan
> layer, just like IPv6 itself runs on the lowpan layer. In our  current
> design,
> one runs one protocol at a time on top of the lowpan adaptation layer.
> So one would run a mesh routing protocol of choice to set up routes
> and populate nodes with the appropriate topological information.
> Subsequent to that, any other protocol on top of that adaptation layer
> (e.g., IPv6, appletalk, IPv4, whatever) could use the mesh delivery.
> The "B" bit and the mesh delivery field are only used for the delivery
> of data on a mesh. The control plane for the mesh is determined by
> prot_type
> and is done with any of several mesh routing protocols.
> 
> Section 9 about Multicast Address mapping:  Does this preclude a
> network
> from using 64-bit addressing for multicasting?  It seems to indicate
> that you must use 16-bit addresses for multicast addresses.
>  
> gm> The mesh delivery header for multicast does not preclude that, as
> it also
> includes the "O" and "F" bits to signal 16 or 64 bit address length.
> So one could
> in the future define the mapping from IPv6 multicast to 64-bit
> addresses, but 
> we're not doing that now. This could be a separate document for which
> I don't
> see much urgency in current networks. 
> 
> Section 10.2 in the Length (bit 2) paragraph:  can we really compute
> the
> udp length field from the possibly compressed frame length field or
> the
> datagram_size field in a fragment header?  Is this a simple
> calculation?
> 
> gm> The frame length is never compressed. It is part of the layer 2
> 802.15.4
> header which we do not control. The value of the UDP length field is
> equal
> to the Payload Length from the IPv6 header, minus the length of any
> extension
> headers present between the IPv6 header and the UDP header.  I've
> added this
> sentence to clarify.
> 
> Section 11 - It doesn't look like we fixed the problem with the
> sequence
> number before the destination address?  Did I miss a different
> solution?
> 
> gm> We added the 'B' bit. The paragraph before figure 10 now has this
> text,
> for example:
>  
>    There are two types of Mesh delivery fields: the "Unicast Mesh
>    Delivery Field" (Figure 10), and the "Broadcast or Multicast Mesh
>    Delivery Field" (Figure 11).  The former is used if the 'B' bit is
>    set to zero, and the latter is used if the 'B' bit is set to 1.  The
>    'B' bit appears in all variations of the LoWPAN encapsulation header
>    (Section 5). 
> -gabriel 
> 
> 
> 
> 
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan
> 
> 


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Fri Nov 03 18:49:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gg8mb-0000vC-R7; Fri, 03 Nov 2006 18:49:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8mb-0000ui-0e
	for 6lowpan@lists.ietf.org; Fri, 03 Nov 2006 18:49:09 -0500
Received: from grab.coslabs.com ([199.233.92.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg8mZ-0006Vk-KY
	for 6lowpan@lists.ietf.org; Fri, 03 Nov 2006 18:49:08 -0500
Received: from x1.coslabs.com (x1.coslabs.com [199.233.92.20])
	by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id kA3Nn6Q7026784
	for <6lowpan@lists.ietf.org>; Fri, 3 Nov 2006 16:49:07 -0700 (MST)
From: Geoff Mulligan 
To: 6lowpan <6lowpan@lists.ietf.org>
Content-Type: text/plain
Date: Fri, 03 Nov 2006 16:49:02 -0700
Message-Id: <1162597742.5112.28.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.1 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: 
Subject: [6lowpan] Proposal for alternative 6lowpan header encoding
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

Folks,
  Arch Rock have submitted a proposal for a different 6lowpan header
encoding.  David and Jonathan put together a set a slides to describe
their idea to simplify the 6lowpan adaptation header.  They are working
on a complete proposal.

I have posted the slides to the wiki at:

http://6lowpan.tzi.org/FrontPage?action=AttachFile&do=get&target=6lowpan-header-proposal.ppt

You can also get a copy (if you are wiki challenged) at:
http://www.mulligan.com/6lowpan/6lowpan-header-proposal.ppt

Their design seems to follow the ideas of IPv6, reduce the header size
in almost all cases, allow for extensions, byte align the fields and as
I've thought about coding it, it looks like less complex parsing.

While a proposal such as this (ideas tend to come on their own schedule)
at this late stage in our process will be disruptive, the potential
value of simplifying and fixing some of the identified problems in the
current design is, in my opinion, worth the time and effort and risk to
our already blown schedule to evaluate and discuss within the group.
 
Please take a look at the slides.  We only a have few days before the
meeting on Wednesday and if possible I would like to hear peoples
thoughts.  I have asked Jonathan and David to attend the WG meeting and
to prepare a more in-depth presentation related to this new design.

        geoff



_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Fri Nov 03 21:19:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GgB7h-0005Pz-JI; Fri, 03 Nov 2006 21:19:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GgB7g-0005Pr-HB
	for 6lowpan@lists.ietf.org; Fri, 03 Nov 2006 21:19:04 -0500
Received: from brev.sics.se ([193.10.64.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgB7d-00024s-1g
	for 6lowpan@lists.ietf.org; Fri, 03 Nov 2006 21:19:04 -0500
Received: from www.sics.se (jenny.sics.se [193.10.64.99])
	by brev.sics.se (8.12.8/8.12.8) with ESMTP id kA42IrJl002354;
	Sat, 4 Nov 2006 03:18:53 +0100
Received: from 83.210.104.22 (SquirrelMail authenticated user adam)
	by www.sics.se with HTTP; Sat, 4 Nov 2006 03:18:53 +0100 (CET)
Message-ID: <1350.83.210.104.22.1162606733.squirrel@www.sics.se>
In-Reply-To: <1162597742.5112.28.camel@localhost>
References: <1162597742.5112.28.camel@localhost>
Date: Sat, 4 Nov 2006 03:18:53 +0100 (CET)
Subject: Re: [6lowpan] Proposal for alternative 6lowpan header encoding
From: adam@sics.se
To: "Geoff Mulligan" 
User-Agent: SquirrelMail/1.4.4-1.FC2
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: by amavisd-new
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: 6lowpan <6lowpan@lists.ietf.org>
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

I like it. From a look at the slides I think David and Jonathan's header
format looks easily understandable, simplistic, while being extensible in
the same way as the IPv6 header format is. It looks to be very
straightforward to implement which means that implementations will have
fewer bugs, different implementors are more likely to end up with
compatible impementations (even in any tricky corner cases), and that an
implementation should be easily doable even for the very smallest of
devices.

/adam

> Folks,
>   Arch Rock have submitted a proposal for a different 6lowpan header
> encoding.  David and Jonathan put together a set a slides to describe
> their idea to simplify the 6lowpan adaptation header.  They are working
> on a complete proposal.
>
> I have posted the slides to the wiki at:
>
> http://6lowpan.tzi.org/FrontPage?action=AttachFile&do=get&target=6lowpan-header-proposal.ppt
>
> You can also get a copy (if you are wiki challenged) at:
> http://www.mulligan.com/6lowpan/6lowpan-header-proposal.ppt
>
> Their design seems to follow the ideas of IPv6, reduce the header size
> in almost all cases, allow for extensions, byte align the fields and as
> I've thought about coding it, it looks like less complex parsing.
>
> While a proposal such as this (ideas tend to come on their own schedule)
> at this late stage in our process will be disruptive, the potential
> value of simplifying and fixing some of the identified problems in the
> current design is, in my opinion, worth the time and effort and risk to
> our already blown schedule to evaluate and discuss within the group.
>
> Please take a look at the slides.  We only a have few days before the
> meeting on Wednesday and if possible I would like to hear peoples
> thoughts.  I have asked Jonathan and David to attend the WG meeting and
> to prepare a more in-depth presentation related to this new design.
>
>         geoff
>
>
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan
>



_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Fri Nov 03 21:50:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GgBcI-0003Qv-QG; Fri, 03 Nov 2006 21:50:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBcH-0003Qq-Lz
	for 6lowpan@lists.ietf.org; Fri, 03 Nov 2006 21:50:41 -0500
Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBcB-0007gt-9j
	for 6lowpan@lists.ietf.org; Fri, 03 Nov 2006 21:50:41 -0500
Received: from mail.sunlabs.com ([152.70.2.186])
	by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix
	0.02 (built Aug 25 2004)) with ESMTP id
	<0J860093EQJYYG00@dps.sfvic.sunlabs.com> for
	6lowpan@lists.ietf.org; Fri, 03 Nov 2006 18:50:22 -0800 (PST)
Received: from [129.146.75.25] by mail.sunlabs.com
	(Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004))
	with ESMTPSA id <0J86009HSQJVT3K0@mail.sunlabs.com> for
	6lowpan@lists.ietf.org; Fri, 03 Nov 2006 18:50:20 -0800 (PST)
Date: Fri, 03 Nov 2006 18:50:38 -0800
From: Vipul Gupta 
Subject: Re: [6lowpan] Proposal for alternative 6lowpan header encoding
In-reply-to: <1350.83.210.104.22.1162606733.squirrel@www.sics.se>
To: 6lowpan <6lowpan@lists.ietf.org>
Message-id: 
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.2)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
X-Priority: 3 (Normal)
References: <1162597742.5112.28.camel@localhost>
	<1350.83.210.104.22.1162606733.squirrel@www.sics.se>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: 
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

I agree. The new format is not only cleaner in how it deals with
fragmentation, multiple hops and extensions; it is also easier to
implement.

vipul

On Nov 3, 2006, at 6:18 PM, adam@sics.se wrote:

> I like it. From a look at the slides I think David and Jonathan's  
> header
> format looks easily understandable, simplistic, while being  
> extensible in
> the same way as the IPv6 header format is. It looks to be very
> straightforward to implement which means that implementations will  
> have
> fewer bugs, different implementors are more likely to end up with
> compatible impementations (even in any tricky corner cases), and  
> that an
> implementation should be easily doable even for the very smallest of
> devices.
>
> /adam
>
>> Folks,
>>   Arch Rock have submitted a proposal for a different 6lowpan header
>> encoding.  David and Jonathan put together a set a slides to describe
>> their idea to simplify the 6lowpan adaptation header.  They are  
>> working
>> on a complete proposal.
>>
>> I have posted the slides to the wiki at:
>>
>> http://6lowpan.tzi.org/FrontPage? 
>> action=AttachFile&do=get&target=6lowpan-header-proposal.ppt
>>
>> You can also get a copy (if you are wiki challenged) at:
>> http://www.mulligan.com/6lowpan/6lowpan-header-proposal.ppt
>>
>> Their design seems to follow the ideas of IPv6, reduce the header  
>> size
>> in almost all cases, allow for extensions, byte align the fields  
>> and as
>> I've thought about coding it, it looks like less complex parsing.
>>
>> While a proposal such as this (ideas tend to come on their own  
>> schedule)
>> at this late stage in our process will be disruptive, the potential
>> value of simplifying and fixing some of the identified problems in  
>> the
>> current design is, in my opinion, worth the time and effort and  
>> risk to
>> our already blown schedule to evaluate and discuss within the group.
>>
>> Please take a look at the slides.  We only a have few days before the
>> meeting on Wednesday and if possible I would like to hear peoples
>> thoughts.  I have asked Jonathan and David to attend the WG  
>> meeting and
>> to prepare a more in-depth presentation related to this new design.
>>
>>         geoff
>>
>>
>>
>> _______________________________________________
>> 6lowpan mailing list
>> 6lowpan@ietf.org
>> https://www1.ietf.org/mailman/listinfo/6lowpan
>>
>
>
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Sat Nov 04 06:30:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GgJiz-0007J1-Jh; Sat, 04 Nov 2006 06:30:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GgJiy-0007IJ-MI
	for 6lowpan@lists.ietf.org; Sat, 04 Nov 2006 06:30:08 -0500
Received: from web57909.mail.re3.yahoo.com ([68.142.236.102])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GgJix-00019n-Qi
	for 6lowpan@lists.ietf.org; Sat, 04 Nov 2006 06:30:08 -0500
Received: (qmail 88091 invoked by uid 60001); 4 Nov 2006 11:30:07 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=dsX3D1av6yAbx5Y0eF46Dn5uEyoZmuyW9HoTYTsiTY92KsAdL7GtzernLBGwsJW1llzcUx229g4VUTBhjNZ28I/E6kWr8nHV4awziLlW+pmPOlGOnonY42yzDi2illtSmMUaJKC6RgPsmoazM+DTTxDp7BS6SsEyPRVY9d7IOU0=
	; 
Message-ID: <20061104113007.88089.qmail@web57909.mail.re3.yahoo.com>
Received: from [69.234.108.77] by web57909.mail.re3.yahoo.com via HTTP;
	Sat, 04 Nov 2006 03:30:07 PST
Date: Sat, 4 Nov 2006 03:30:07 -0800 (PST)
From: Abhijit Rao 
Subject: RE: [6lowpan] 6lowpan Architecture Questions
To: 'Geoff Mulligan' 
In-Reply-To: <009601c6ff49$8567b6a0$6501a8c0@RonStrich>
MIME-Version: 1.0
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Cc: '6lowpan' <6lowpan@lists.ietf.org>
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0888170210=="
Errors-To: 6lowpan-bounces@ietf.org

--===============0888170210==
Content-Type: multipart/alternative; boundary="0-1576852506-1162639807=:79281"
Content-Transfer-Encoding: 8bit

--0-1576852506-1162639807=:79281
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

 
  Geoff,
  Here is one format for preapring the Use Cases.
   
  Use Case: 
  Category:
  Goals to be achieved by this use case:
  Roles <To make it very general use actors>:
  Needs (Preconditions):
  Context (Triggers) - Optional:
  Usage Scenarios: <Add steps to each usage scenario>
  Postconditions - Optional:
   
  We put together all the use cases and then classify them in terms of priority and/or life-term. And hopefully that should also help us identify the functional requirements / components
   
  Here is a sample that I prepared
   
  Use Case:  Intermittent Data acquisition from a LowPAN device
  Category(s): Healthcare
  Goals to be achieved by this use case: Obtain data for monitoring at the client machine in the local network. Summary of the data acquired maybe stored. The Profile of the LowPAN device is fixed.
  Roles <To make it very general use actors>: Andy � responsible for setting up and managing the client machine.
  Roy � Installs the LowPAN device and is responsible for its functioning
  Amin � LowPAN device is devoted to Amin
  Malin � Unauthorized entity trying to get into the network
  Dr Brad � Entity that specifies the policies and profile for LowPAN device and Amin. Also recipient of summary of data acquired.
  Needs (Preconditions): the device is operational and ready to be used
  Context (Triggers) - Optional: 
  Usage Scenarios: 
  - Identifying Amin and Preparing Amin
  - Setting up the LowPAN device for data acquisition- preparing the policies
  - Authorized Data acquisition and control
  - Unauthorized data acquisition and control
  - Device Tracking
  - Device maintenance
  Post conditions - Optional:
   
  We should have a master pool of Categories and Roles � so that all the use cases have a common basis.
   
  Other use cases could be
  -         Large  scale deployment of LowPAN devices (real-time monitoring)
  -         LowPAN device as a Utility (such as Gas, Electricity) Usage Monitor (Command / Response driven � Profile is being pushed)
  -         LowPAN device being used in Home Network Monitoring (Mobile home owner can access theis LowPAN device in his home)
  -         Touch less access control system at a Building 
   
  Abhijit
  
Ron Strich <ronstrich@earthlink.net> wrote:
  Geoff,

I agree that "use case" is a better term than architecture, especially
considering the historical issues that Carsten has raised. But I also
believe that the incorporation of very small devices into a 6lowpan "use
case" is important to the adoption of 6lowpan. Cost is also important
consideration for 6lowpan adoption. An extra $0.01 in cost imposed by
6lowpan, has a potential $100 million annual impact to the adoption of
wireless communications to the micro controller industry at today's
production rates.

Ron

-----Original Message-----
From: Geoff Mulligan [mailto:geoff@mulligan.com] 
Sent: Friday, November 03, 2006 12:36 AM
To: Ron Strich
Cc: '6lowpan'
Subject: Re: [6lowpan] 6lowpan Architecture Questions

Ron,
These are excellent points.

I would like to hear from other on the list about the idea of supporting
extremely small devices (4K) (smaller than the extremely small devices
that we have been targeting (32K)). I would not like to choose to miss
a potential market segment (potentially large market segment), but is it
reasonable to got after a 4k device which probably could not possibly
ever accept a 1280 byte (minimum size ipv6) packet. 

I think question 2 is going to be critical as we move to the next phase
of this working group. Hopefully we will finish the format document and
start on rechartering. One of the top areas that I think we need to
look at is the idea of utilizing Manet and how the design will impact
6lowpan (memory, power, other costs). And whether or not we choose to
use the manet approach and protocols, should we down select to a single
protocol or some small set and if so what is the criteria for this
selection.

Please consider what criteria you think we should use to evaluate the
available mesh protocols.

While the IETF doesn't appear to embrace architecture docs, it is
critical for us to agree on some set of use-cases so that we can focus
our efforts on providing real solutions.

So again, please consider for our rechartering and new work items,
should we generate a set of use-cases? What is the format for this?
Should we support extremely small devices? And finally what criteria
should we use to determine the selection/evaluation of mesh routing
protocols (which probably begs for a use-case analysis.)

Folks, please start to participate in these discussions. It is only
with your input that we will have a successful working group and will
create a standard that is useful in the market.

geoff



On Fri, 2006-10-27 at 09:07 -0500, Ron Strich wrote:
> 1. Many sensor and control devices will be too small to support a full
> mesh/ip adaptation implementation. Some of these devices may be as small
as
> 4K of flash and 100s of bytes of RAM and may only be used in a point to
> point (P2P), simple star, or very simple mesh implementation (please see
the
> attached pdf drawing). Incorporation of these very small devices, I
> believe, is important to the broad adoption of 6lowpan.
> 
> Should we consider how to support these extremely limited devices? Should
> we make it easy for these simple protocol implementations at this level to
> adapt to 6lowpan? If we want to include these small devices, should we
> consider a more constrained design (limited payload, P2P/star only) that
> would simplify the adaptation layer?
> 
> 2. How will the group evaluate what mesh, P2P or star protocols should be
> supported? As David pointed out, we may not be allowing for future
> capabilities in the current structure of the adaptation layer should we
want
> to support multiple types of L2 protocols.
> 
> 3. Related to the pending mesh protocol evaluation, is the evaluation of
any
> functionality related to the "cost" of those technical choices in terms of
> power, code size, complexity, RAM, instructions executed, etc?
> 
> 4. As was mentioned on the list a while ago, neither the Problem Statement
> nor the Format documents discuss the overall 6LoWPAN architecture. As we
> move forward with our next working group items, shouldn't we create a
> document to describe the high level architecture which might well
encompass
> the criteria for evaluation of the protocols and costs mentioned above?
> 
> Ron Strich
> Mobile: 228.369.4332
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan


 
---------------------------------
Get your email and see which of your friends are online - Right on the  new Yahoo.com
--0-1576852506-1162639807=:79281
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<div> </div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Geoff,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Here is one format for preapring the Use Cases.<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial"> <o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Use Case: <Title><o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Category:<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Goals to be achieved by this use case:<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Roles
 <To make it very general use actors>:<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Needs (Preconditions):<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Context (Triggers) - Optional:<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Usage Scenarios: <Add steps to each usage scenario><o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Postconditions - Optional:<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial"> <o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">We put together all the use cases and then classify them in terms of priority and/or life-term. And hopefully that should also help
 us identify the functional requirements / components<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial"> <o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Here is a sample that I prepared<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial"> <o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Use Case:<SPAN style="mso-spacerun: yes">  </SPAN>Intermittent Data acquisition from a LowPAN device<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Category(s): Healthcare<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Goals to be achieved by this use case: Obtain data for monitoring at the client machine in
 the local network. Summary of the data acquired maybe stored. The Profile of the LowPAN device is fixed.<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Roles <To make it very general use actors>: Andy � responsible for setting up and managing the client machine.<o:p></o:p></SPAN></div>  <div><?xml:namespace prefix = u1 /><u1:City u2:st="on"><u1:place u2:st="on"><?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:City w:st="on"><st1:place w:st="on"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Roy</SPAN></st1:place></st1:City></u1:place></u1:City><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial"> � Installs the LowPAN device and is responsible for its functioning<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Amin � LowPAN device is devoted to
 Amin<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Malin � Unauthorized entity trying to get into the network<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Dr Brad � Entity that specifies the policies and profile for LowPAN device and Amin. Also recipient of summary of data acquired.<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Needs (Preconditions): the device is operational and ready to be used<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Context (Triggers) - Optional: <o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Usage Scenarios: <o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">-
 Identifying Amin and Preparing Amin<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">- Setting up the LowPAN device for data acquisition- preparing the policies<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">- Authorized Data acquisition and control<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">- Unauthorized data acquisition and control<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">- Device Tracking<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">- Device maintenance<o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Post conditions - Optional:<o:p></o:p></SPAN></div>  <div class=MsoNormal
 style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"><o:p> </o:p></SPAN></div>  <div class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">We should have a master pool of Categories and Roles � so that all the use cases have a common basis.<o:p></o:p></SPAN></div>  <div class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"><o:p> </o:p></SPAN></div>  <div class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Other use cases could be<o:p></o:p></SPAN></div>  <div class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in; TEXT-INDENT: -0.25in; tab-stops: list .5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-fareast-font-family: 'Times New Roman'">-         </SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Large<SPAN style="mso-spacerun: yes">  </SPAN>scale
 deployment of LowPAN devices (real-time monitoring)<o:p></o:p></SPAN></div>  <div class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in; TEXT-INDENT: -0.25in; tab-stops: list .5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-fareast-font-family: 'Times New Roman'">-         </SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">LowPAN device as a Utility (such as Gas, Electricity) Usage Monitor (Command / Response driven � Profile is being pushed)<o:p></o:p></SPAN></div>  <div class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in; TEXT-INDENT: -0.25in; tab-stops: list .5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-fareast-font-family: 'Times New Roman'">-         </SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">LowPAN device being used in Home Network Monitoring (Mobile home owner can access theis LowPAN device in his home)<o:p></o:p></SPAN></div>  <div
 class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in; TEXT-INDENT: -0.25in; tab-stops: list .5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-fareast-font-family: 'Times New Roman'">-         </SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Touch less access control system at a Building <o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial"> <o:p></o:p></SPAN></div>  <div><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-family: Arial">Abhijit<o:p></o:p></SPAN></div>  <div class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1; tab-stops: list .5in"><FONT face="Times New Roman"></FONT><BR><B><I>Ron Strich <ronstrich@earthlink.net></I></B> wrote:</div>  <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Geoff,<BR><BR>I agree that "use case" is
 a better term than architecture, especially<BR>considering the historical issues that Carsten has raised. But I also<BR>believe that the incorporation of very small devices into a 6lowpan "use<BR>case" is important to the adoption of 6lowpan. Cost is also important<BR>consideration for 6lowpan adoption. An extra $0.01 in cost imposed by<BR>6lowpan, has a potential $100 million annual impact to the adoption of<BR>wireless communications to the micro controller industry at today's<BR>production rates.<BR><BR>Ron<BR><BR>-----Original Message-----<BR>From: Geoff Mulligan [mailto:geoff@mulligan.com] <BR>Sent: Friday, November 03, 2006 12:36 AM<BR>To: Ron Strich<BR>Cc: '6lowpan'<BR>Subject: Re: [6lowpan] 6lowpan Architecture Questions<BR><BR>Ron,<BR>These are excellent points.<BR><BR>I would like to hear from other on the list about the idea of supporting<BR>extremely small devices (4K) (smaller than the extremely small devices<BR>that we have been targeting (32K)). I would not
 like to choose to miss<BR>a potential market segment (potentially large market segment), but is it<BR>reasonable to got after a 4k device which probably could not possibly<BR>ever accept a 1280 byte (minimum size ipv6) packet. <BR><BR>I think question 2 is going to be critical as we move to the next phase<BR>of this working group. Hopefully we will finish the format document and<BR>start on rechartering. One of the top areas that I think we need to<BR>look at is the idea of utilizing Manet and how the design will impact<BR>6lowpan (memory, power, other costs). And whether or not we choose to<BR>use the manet approach and protocols, should we down select to a single<BR>protocol or some small set and if so what is the criteria for this<BR>selection.<BR><BR>Please consider what criteria you think we should use to evaluate the<BR>available mesh protocols.<BR><BR>While the IETF doesn't appear to embrace architecture docs, it is<BR>critical for us to agree on some set of
 use-cases so that we can focus<BR>our efforts on providing real solutions.<BR><BR>So again, please consider for our rechartering and new work items,<BR>should we generate a set of use-cases? What is the format for this?<BR>Should we support extremely small devices? And finally what criteria<BR>should we use to determine the selection/evaluation of mesh routing<BR>protocols (which probably begs for a use-case analysis.)<BR><BR>Folks, please start to participate in these discussions. It is only<BR>with your input that we will have a successful working group and will<BR>create a standard that is useful in the market.<BR><BR>geoff<BR><BR><BR><BR>On Fri, 2006-10-27 at 09:07 -0500, Ron Strich wrote:<BR>> 1. Many sensor and control devices will be too small to support a full<BR>> mesh/ip adaptation implementation. Some of these devices may be as small<BR>as<BR>> 4K of flash and 100s of bytes of RAM and may only be used in a point to<BR>> point (P2P), simple star, or
 very simple mesh implementation (please see<BR>the<BR>> attached pdf drawing). Incorporation of these very small devices, I<BR>> believe, is important to the broad adoption of 6lowpan.<BR>> <BR>> Should we consider how to support these extremely limited devices? Should<BR>> we make it easy for these simple protocol implementations at this level to<BR>> adapt to 6lowpan? If we want to include these small devices, should we<BR>> consider a more constrained design (limited payload, P2P/star only) that<BR>> would simplify the adaptation layer?<BR>> <BR>> 2. How will the group evaluate what mesh, P2P or star protocols should be<BR>> supported? As David pointed out, we may not be allowing for future<BR>> capabilities in the current structure of the adaptation layer should we<BR>want<BR>> to support multiple types of L2 protocols.<BR>> <BR>> 3. Related to the pending mesh protocol evaluation, is the evaluation of<BR>any<BR>>
 functionality related to the "cost" of those technical choices in terms of<BR>> power, code size, complexity, RAM, instructions executed, etc?<BR>> <BR>> 4. As was mentioned on the list a while ago, neither the Problem Statement<BR>> nor the Format documents discuss the overall 6LoWPAN architecture. As we<BR>> move forward with our next working group items, shouldn't we create a<BR>> document to describe the high level architecture which might well<BR>encompass<BR>> the criteria for evaluation of the protocols and costs mentioned above?<BR>> <BR>> Ron Strich<BR>> Mobile: 228.369.4332<BR>> _______________________________________________<BR>> 6lowpan mailing list<BR>> 6lowpan@ietf.org<BR>> https://www1.ietf.org/mailman/listinfo/6lowpan<BR><BR><BR>_______________________________________________<BR>6lowpan mailing list<BR>6lowpan@ietf.org<BR>https://www1.ietf.org/mailman/listinfo/6lowpan<BR></BLOCKQUOTE><BR><p> 

<hr size=1>Get your email and see which of your friends are online - Right on the <a href="http://us.rd.yahoo.com/evt=42973/*http://www.yahoo.com/preview"> new Yahoo.com</a>

--0-1576852506-1162639807=:79281--


--===============0888170210==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--===============0888170210==--




From 6lowpan-bounces@ietf.org Sat Nov 04 13:33:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GgQKr-0008B8-3V; Sat, 04 Nov 2006 13:33:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GgQKp-0008AW-Ld
	for 6lowpan@ietf.org; Sat, 04 Nov 2006 13:33:39 -0500
Received: from web81908.mail.mud.yahoo.com ([68.142.207.187])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GgQKo-0007Vt-VI
	for 6lowpan@ietf.org; Sat, 04 Nov 2006 13:33:39 -0500
Received: (qmail 27380 invoked by uid 60001); 4 Nov 2006 18:33:38 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type;
	b=3SjQgcibmXHifcek6dGRSIxSlFb16hQde1cahr33s+G9tWBQvUf4xYIBUG8GFCFp/98mEb9rZpfr7lcWPLWc8SroepCfGdvDuZcyRmmRSxfZxLtUFLx2THiwZAbnUTIXFfcD3PnDMQNJm0AHYx2IMHSUbbfMzXun6FxEohKGzzM=
	; 
Message-ID: <20061104183338.27378.qmail@web81908.mail.mud.yahoo.com>
Received: from [24.16.14.130] by web81908.mail.mud.yahoo.com via HTTP;
	Sat, 04 Nov 2006 10:33:38 PST
Date: Sat, 4 Nov 2006 10:33:38 -0800 (PST)
From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
To: 6lowpan@ietf.org
MIME-Version: 1.0
X-Spam-Score: 1.4 (+)
X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26
Subject: [6lowpan] Fw: any comments on the proposal from Arch Rock
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0817707659=="
Errors-To: 6lowpan-bounces@ietf.org

--===============0817707659==
Content-Type: multipart/alternative; boundary="0-2108329824-1162665218=:27050"

--0-2108329824-1162665218=:27050
Content-Type: text/plain; charset=ascii
Content-Transfer-Encoding: quoted-printable

Hi,=0A=0AA few of us had a chance to look at this proposal earlier in the w=
eek. The message below=0Ahas comments from Carles Gomez, Mario Mao and myse=
lf.=0A=0ASince it may be of interest to the group, I'm forwarding with perm=
ission from Carles and Mario.=0A=0A-gabriel=0A=0A=0A----- Forwarded Message=
 ----=0AFrom: Mario Mao <mariomao@gmail.com>=0ATo: Carles Gomez <carlesgo@m=
at.upc.edu>; Geoff Mulligan <geoff@mulligan.com>=0ACc: gabriel montenegro <=
gabriel_montenegro_2000@yahoo.com>; Ki-Hyung Kim <kkim86@gmail.com>; Daniel=
 Park <soohong.park@samsung.com>; Carsten Bormann <cabo@tzi.de>; Christian =
Schumacher <schumacher@danfoss.com>=0ASent: Friday, November 3, 2006 5:21:4=
0 AM=0ASubject: Re: any comments on the proposal from Arch Rock=0A=0A=0AHi =
All,=0A=0AI would propose my opinions from the view of implementation, than=
ks.=0A=0AFirst, I would say the new format is clear and supply more expansi=
bility (just like IPv6 extension header).=0A=0AFor my concern, the multicas=
t ability. For the most important reason of changing original byte-alignmen=
t format to current one is to add B bit and supply way of distinguishing se=
qno, how about that in new format? I don't see how does it work for this si=
tuation. Have I missed the critical point, thanks if author could give some=
 hint.=0A=0AAbout the hops left, I also agree the 15 hops would enough for =
most cases. In our environment, more than 10 hops would cause a surprising =
lag (beacon interval set to 1s). However, it is always right to save space =
for further development, we should figure out a good method to balance them=
.=0A=0AAt last, simple to implement. By our experience, new format may not =
bring convenience. We still have more than 3 headers/extensions to handle, =
equal to previous one (may more complex...). But the new format do bring be=
nefits beyond that. For our tests show the original format affords enough a=
bility for common IPv6 application over WSN, if the new one could follow th=
e function exactly and not bring conflict, I vote for the hard packet forma=
t changing.=0A=0ARegards,=0A=0AMario Mao=0AMarioMao@Gmail.com=0A=0A=0A-----=
 Original Message ----- =0AFrom: "Carles Gomez" <carlesgo@mat.upc.edu>=0ATo=
: "Geoff Mulligan" <geoff@mulligan.com>=0ACc: "gabriel montenegro" <gabriel=
_montenegro_2000@yahoo.com>; "Ki-Hyung Kim" <kkim86@gmail.com>; "Daniel Par=
k" <soohong.park@samsung.com>; "Carsten Bormann" <cabo@tzi.de>; "Christian =
Schumacher" <schumacher@danfoss.com>; <mariomao@gmail.com>=0ASent: Friday, =
November 03, 2006 6:47 PM=0ASubject: Re: any comments on the proposal from =
Arch Rock=0A=0A=0A> Dear all,=0A> =0A> We believe the proposed new format i=
s clearer and allows development of =0A> extensions and addition of new opt=
ions in an easier way, which is relevant =0A> from the point of view of imp=
lementation.=0A> =0A> In general, the new format allows for byte savings in=
 most cases. However, =0A> just to keep a fair comparison (it seems like th=
e slides try to represent the =0A> most favorable case for ArchRock proposa=
l) it must be noted that when =0A> fragmentation is needed, an offset field=
 with a size equal to one byte must be =0A> added to fragments other than t=
he first one. Hence, in some cases as in slide =0A> 9, "Multihop > 14 hops"=
, 7 bytes would be needed with the new format for =0A> fragments other than=
 the first one, which is one byte more than that needed =0A> with the curre=
nt 6lowpan proposal. Anyway, the overall result seems to be a =0A> clearer =
format with roughly the same size (in some cases smaller, in some =0A> othe=
rs the same as, and in some others greater than that of the current =0A> 6l=
owpan proposal).=0A> =0A> Regarding the number of hops, I agree that 15 hop=
s should be enough in most =0A> cases. =0A> =0A> Best regards,=0A> =0A> Car=
les Gomez=0A> Technical University of Catalonia=0A> =0A> Quoting Geoff Mull=
igan <geoff@mulligan.com>:=0A> =0A> > Gabriel,=0A> >   Thanks for the quick=
 review.  I think that David and Jonathan had the=0A> > same idea about usi=
ng all ones as a mechanism to allow other proto=0A> > types.=0A> > =0A> > I=
 agree that the idea of 256 hops is probably overkill, i think that=0A> > s=
ome folks might think 15 hops is too small, but I think probably=0A> > appr=
opriate for 90% of applications.=0A> > =0A> > Also thanks for include Carlo=
s.=0A> > =0A> > Everyone, please weigh-in on this quickly.=0A> > =0A> > geo=
ff=0A> > =0A> > On Thu, 2006-11-02 at 23:51 -0800, gabriel montenegro wrote=
:=0A> > > [I took the liberty of forwarding the slides and the email thread=
 to=0A> > > the folks at=0A> > > Universidad Politecnica de Catalunya as th=
ey have also been involved=0A> > > in implementation=0A> > > work and would=
 have valuable input. I'm cc-ing Carles to include them=0A> > > in the loop=
.]=0A> > >  =0A> > > Folks,=0A> > >  =0A> > > I have just now looked at the=
 slides, and my first impression is that=0A> > > the format looks quite=0A>=
 > > nice and definitely worth sending out to the list. One minor detail is=
=0A> > > that the dispatch=0A> > > field is smaller than the current prot_t=
ype, but we could just reserve=0A> > > the value=0A> > > of all 1's and use=
 that to signal a subsequent extended dispatch field=0A> > > (like we used=
=0A> > > to have, and like they've done with hops). =0A> > >  =0A> > > Slid=
es 9 and 10 illustrate the potential gains. I don't think the=0A> > > large=
 hop functionality=0A> > > is very real (the packet drop rate will probably=
 make such long paths=0A> > > pointless). The=0A> > > extensibility, I thin=
k we already have (just define more protocol_type=0A> > > values). What I=
=0A> > > see in the fourth packet figure in slide 12 is more akin to=0A> > =
> "piggybacking". This is also=0A> > > possible in IPv6, of course, but is =
not always a good idea as it can=0A> > > get complex real soon.=0A> > > But=
 having the chance of doing piggybacking (several protocols within=0A> > > =
one packet) could be=0A> > > useful, yes. In summary, I'm more cautious abo=
ut jumping into=0A> > > piggybacking or deep-hopping=0A> > > than I am abou=
t the stacking approach itself.=0A> > >  =0A> > > Other than that, I'd real=
ly like to defer to the folks who've engaged=0A> > > in implementation=0A> =
> > of the current format draft.=0A> > > =0A> > > -gabriel
--0-2108329824-1162665218=:27050
Content-Type: text/html; charset=ascii
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:courier, monaco, monospace, sans-serif;f=
ont-size:12pt"><DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco,=
 monospace, sans-serif">Hi,</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAM=
ILY: courier, monaco, monospace, sans-serif"> </DIV>=0A<DIV style=3D"F=
ONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">A few =
of us had a chance to look at this proposal earlier in the week. The messag=
e below</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco=
, monospace, sans-serif">has comments from Carles Gomez, Mario Mao and myse=
lf.</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, mo=
nospace, sans-serif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAM=
ILY: courier, monaco, monospace, sans-serif">Since it may be of interest to=
 the group, I'm forwarding with permission from Carles and Mario.</DIV>=0A<=
DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans=
-serif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier,=
 monaco, monospace, sans-serif">-gabriel<BR><BR></DIV>=0A<DIV style=3D"FONT=
-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Fo=
rwarded Message ----<BR>From: Mario Mao <mariomao@gmail.com><BR>To: C=
arles Gomez <carlesgo@mat.upc.edu>; Geoff Mulligan <geoff@mulligan=
.com><BR>Cc: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>=
;; Ki-Hyung Kim <kkim86@gmail.com>; Daniel Park <soohong.park@sams=
ung.com>; Carsten Bormann <cabo@tzi.de>; Christian Schumacher <=
schumacher@danfoss.com><BR>Sent: Friday, November 3, 2006 5:21:40 AM<BR>=
Subject: Re: any comments on the proposal from Arch Rock<BR><BR>=0A<DIV>Hi =
All,<BR><BR>I would propose my opinions from the view of implementation, th=
anks.<BR><BR>First, I would say the new format is clear and supply more exp=
ansibility (just like IPv6 extension header).<BR><BR>For my concern, the mu=
lticast ability. For the most important reason of changing original byte-al=
ignment format to current one is to add B bit and supply way of distinguish=
ing seqno, how about that in new format? I don't see how does it work for t=
his situation. Have I missed the critical point, thanks if author could giv=
e some hint.<BR><BR>About the hops left, I also agree the 15 hops would eno=
ugh for most cases. In our environment, more than 10 hops would cause a sur=
prising lag (beacon interval set to 1s). However, it is always right to sav=
e space for further development, we should figure out a good method to bala=
nce them.<BR><BR>At last, simple to implement. By our experience, new forma=
t may not bring convenience. We still have more than 3 headers/extensions t=
o
 handle, equal to previous one (may more complex...). But the new format do=
 bring benefits beyond that. For our tests show the original format affords=
 enough ability for common IPv6 application over WSN, if the new one could =
follow the function exactly and not bring conflict, I vote for the hard pac=
ket format changing.<BR><BR>Regards,<BR><BR>Mario Mao<BR>MarioMao@Gmail.com=
<BR><BR><BR>----- Original Message ----- <BR>From: "Carles Gomez" <carle=
sgo@mat.upc.edu><BR>To: "Geoff Mulligan" <geoff@mulligan.com><BR>C=
c: "gabriel montenegro" <gabriel_montenegro_2000@yahoo.com>; "Ki-Hyun=
g Kim" <kkim86@gmail.com>; "Daniel Park" <soohong.park@samsung.com=
>; "Carsten Bormann" <cabo@tzi.de>; "Christian Schumacher" <sch=
umacher@danfoss.com>; <mariomao@gmail.com><BR>Sent: Friday, Novemb=
er 03, 2006 6:47 PM<BR>Subject: Re: any comments on the proposal from Arch =
Rock<BR><BR><BR>> Dear all,<BR>> <BR>> We believe the proposed new=
 format is
 clearer and allows development of <BR>> extensions and addition of new =
options in an easier way, which is relevant <BR>> from the point of view=
 of implementation.<BR>> <BR>> In general, the new format allows for =
byte savings in most cases. However, <BR>> just to keep a fair compariso=
n (it seems like the slides try to represent the <BR>> most favorable ca=
se for ArchRock proposal) it must be noted that when <BR>> fragmentation=
 is needed, an offset field with a size equal to one byte must be <BR>> =
added to fragments other than the first one. Hence, in some cases as in sli=
de <BR>> 9, "Multihop > 14 hops", 7 bytes would be needed with the ne=
w format for <BR>> fragments other than the first one, which is one byte=
 more than that needed <BR>> with the current 6lowpan proposal. Anyway, =
the overall result seems to be a <BR>> clearer format with roughly the s=
ame size (in some cases smaller, in some <BR>> others the same as, and i=
n some others
 greater than that of the current <BR>> 6lowpan proposal).<BR>> <BR>&=
gt; Regarding the number of hops, I agree that 15 hops should be enough in =
most <BR>> cases. <BR>> <BR>> Best regards,<BR>> <BR>> Carle=
s Gomez<BR>> Technical University of Catalonia<BR>> <BR>> Quoting =
Geoff Mulligan <geoff@mulligan.com>:<BR>> <BR>> > Gabriel,<B=
R>> >   Thanks for the quick review.  I think tha=
t David and Jonathan had the<BR>> > same idea about using all ones as=
 a mechanism to allow other proto<BR>> > types.<BR>> > <BR>>=
 > I agree that the idea of 256 hops is probably overkill, i think that<=
BR>> > some folks might think 15 hops is too small, but I think proba=
bly<BR>> > appropriate for 90% of applications.<BR>> > <BR>>=
 > Also thanks for include Carlos.<BR>> > <BR>> > Everyone, =
please weigh-in on this quickly.<BR>> > <BR>> > geoff<BR>> &=
gt; <BR>>
 > On Thu, 2006-11-02 at 23:51 -0800, gabriel montenegro wrote:<BR>> =
> > [I took the liberty of forwarding the slides and the email thread=
 to<BR>> > > the folks at<BR>> > > Universidad Politecnic=
a de Catalunya as they have also been involved<BR>> > > in impleme=
ntation<BR>> > > work and would have valuable input. I'm cc-ing Ca=
rles to include them<BR>> > > in the loop.]<BR>> > > =
; <BR>> > > Folks,<BR>> > >  <BR>> >=
 > I have just now looked at the slides, and my first impression is that=
<BR>> > > the format looks quite<BR>> > > nice and defini=
tely worth sending out to the list. One minor detail is<BR>> > > t=
hat the dispatch<BR>> > > field is smaller than the current prot_t=
ype, but we could just reserve<BR>> > > the value<BR>> > >=
; of all 1's and use that to signal a subsequent extended dispatch field<BR=
>> >
 > (like we used<BR>> > > to have, and like they've done with h=
ops). <BR>> > >  <BR>> > > Slides 9 and 10 illu=
strate the potential gains. I don't think the<BR>> > > large hop f=
unctionality<BR>> > > is very real (the packet drop rate will prob=
ably make such long paths<BR>> > > pointless). The<BR>> > &g=
t; extensibility, I think we already have (just define more protocol_type<B=
R>> > > values). What I<BR>> > > see in the fourth packet=
 figure in slide 12 is more akin to<BR>> > > "piggybacking". This =
is also<BR>> > > possible in IPv6, of course, but is not always a =
good idea as it can<BR>> > > get complex real soon.<BR>> > &=
gt; But having the chance of doing piggybacking (several protocols within<B=
R>> > > one packet) could be<BR>> > > useful, yes. In sum=
mary, I'm more cautious about jumping into<BR>> > > piggybacking o=
r
 deep-hopping<BR>> > > than I am about the stacking approach itsel=
f.<BR>> > >  <BR>> > > Other than that, I'd rea=
lly like to defer to the folks who've engaged<BR>> > > in implemen=
tation<BR>> > > of the current format draft.<BR>> > > <BR=
>> > > -gabriel<BR></DIV></DIV></div></body></html>
--0-2108329824-1162665218=:27050--


--===============0817707659==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--===============0817707659==--




From 6lowpan-bounces@ietf.org Sat Nov 04 14:15:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GgQzX-0003Bp-80; Sat, 04 Nov 2006 14:15:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GgQzW-0003Bk-Kx
	for 6lowpan@ietf.org; Sat, 04 Nov 2006 14:15:42 -0500
Received: from cs1.sf.archedrock.com ([64.147.171.181]
	helo=secure.archedrock.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgQzW-0004xj-2I
	for 6lowpan@ietf.org; Sat, 04 Nov 2006 14:15:42 -0500
Received: by secure.archedrock.com (Postfix, from userid 101)
	id 81A0C16B0002; Sat,  4 Nov 2006 11:15:39 -0800 (PST)
Received: from [127.0.0.1] (adsl-71-142-86-178.dsl.pltn13.pacbell.net
	[71.142.86.178])
	by secure.archedrock.com (Postfix) with ESMTP id 196C916B0001;
	Sat,  4 Nov 2006 11:15:36 -0800 (PST)
Message-ID: <454CE6D7.9000500@archrock.com>
Date: Sat, 04 Nov 2006 11:15:35 -0800
From: Jonathan Hui <jhui@archrock.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock
References: <20061104183338.27378.qmail@web81908.mail.mud.yahoo.com>
In-Reply-To: <20061104183338.27378.qmail@web81908.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on 
	cs1.sf.archedrock.com
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_SORBS_DUL autolearn=no version=3.0.6
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9
Cc: 6lowpan@ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Errors-To: 6lowpan-bounces@ietf.org


In response to Mario's concerns about the B-bit for multicast meshing, 
we would argue that this functionality can be fairly represented by 
assigning a new dispatch type to creating a new extension header. This 
header does require two bytes (1 for the dispatch and 1 for the sequence 
number) vs. 1 extra byte in the current proposal. However, it is not 
clear to us whether an 8-bit sequence number field is sufficient for 
current and possibly future protocols that may implement multicast 
meshing. What the dispatch byte allows is support for not only a header 
that includes a single 8-bit sequence number, but also room for other 
future headers that may require more than that. We feel that adding the 
extra dispatch byte to allow support for multiple protocols is well 
worth it. Note that adding new extension headers is useful for any 
meshing protocol (both unicast and multicast).

In response to Carles' concerns about the byte counts, we believe we are 
doing the comparison fairly. In the case with fragmentation, you are 
correct that the offset byte must be added. However, the upper-layer 
protocol dispatch byte is only needed in the first fragment. This is 
analogous to the current 6lowpan format replacing the prot_type bits 
with the dgram_offset bits. However, we feel that our proposal is 
conceptually cleaner because the concepts of prot_type and dgram_offset 
are kept separate in orthogonal headers. Our fault for not making that 
clear in the slides, thanks for pointing that out.

--
Jonathan Hui
jhui@archrock.com


gabriel montenegro wrote:
> Hi,
>  
> A few of us had a chance to look at this proposal earlier in the week. 
> The message below
> has comments from Carles Gomez, Mario Mao and myself.
>  
> Since it may be of interest to the group, I'm forwarding with permission 
> from Carles and Mario.
>  
> -gabriel
> 
> ----- Forwarded Message ----
> From: Mario Mao <mariomao@gmail.com>
> To: Carles Gomez <carlesgo@mat.upc.edu>; Geoff Mulligan <geoff@mulligan.com>
> Cc: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>; Ki-Hyung Kim 
> <kkim86@gmail.com>; Daniel Park <soohong.park@samsung.com>; Carsten 
> Bormann <cabo@tzi.de>; Christian Schumacher <schumacher@danfoss.com>
> Sent: Friday, November 3, 2006 5:21:40 AM
> Subject: Re: any comments on the proposal from Arch Rock
> 
> Hi All,
> 
> I would propose my opinions from the view of implementation, thanks.
> 
> First, I would say the new format is clear and supply more expansibility 
> (just like IPv6 extension header).
> 
> For my concern, the multicast ability. For the most important reason of 
> changing original byte-alignment format to current one is to add B bit 
> and supply way of distinguishing seqno, how about that in new format? I 
> don't see how does it work for this situation. Have I missed the 
> critical point, thanks if author could give some hint.
> 
> About the hops left, I also agree the 15 hops would enough for most 
> cases. In our environment, more than 10 hops would cause a surprising 
> lag (beacon interval set to 1s). However, it is always right to save 
> space for further development, we should figure out a good method to 
> balance them.
> 
> At last, simple to implement. By our experience, new format may not 
> bring convenience. We still have more than 3 headers/extensions to 
> handle, equal to previous one (may more complex...). But the new format 
> do bring benefits beyond that. For our tests show the original format 
> affords enough ability for common IPv6 application over WSN, if the new 
> one could follow the function exactly and not bring conflict, I vote for 
> the hard packet format changing.
> 
> Regards,
> 
> Mario Mao
> MarioMao@Gmail.com
> 
> 
> ----- Original Message -----
> From: "Carles Gomez" <carlesgo@mat.upc.edu>
> To: "Geoff Mulligan" <geoff@mulligan.com>
> Cc: "gabriel montenegro" <gabriel_montenegro_2000@yahoo.com>; "Ki-Hyung 
> Kim" <kkim86@gmail.com>; "Daniel Park" <soohong.park@samsung.com>; 
> "Carsten Bormann" <cabo@tzi.de>; "Christian Schumacher" 
> <schumacher@danfoss.com>; <mariomao@gmail.com>
> Sent: Friday, November 03, 2006 6:47 PM
> Subject: Re: any comments on the proposal from Arch Rock
> 
> 
>  > Dear all,
>  >
>  > We believe the proposed new format is clearer and allows development of
>  > extensions and addition of new options in an easier way, which is 
> relevant
>  > from the point of view of implementation.
>  >
>  > In general, the new format allows for byte savings in most cases. 
> However,
>  > just to keep a fair comparison (it seems like the slides try to 
> represent the
>  > most favorable case for ArchRock proposal) it must be noted that when
>  > fragmentation is needed, an offset field with a size equal to one 
> byte must be
>  > added to fragments other than the first one. Hence, in some cases as 
> in slide
>  > 9, "Multihop > 14 hops", 7 bytes would be needed with the new format for
>  > fragments other than the first one, which is one byte more than that 
> needed
>  > with the current 6lowpan proposal. Anyway, the overall result seems 
> to be a
>  > clearer format with roughly the same size (in some cases smaller, in 
> some
>  > others the same as, and in some others greater than that of the current
>  > 6lowpan proposal).
>  >
>  > Regarding the number of hops, I agree that 15 hops should be enough 
> in most
>  > cases.
>  >
>  > Best regards,
>  >
>  > Carles Gomez
>  > Technical University of Catalonia
>  >
>  > Quoting Geoff Mulligan <geoff@mulligan.com>:
>  >
>  > > Gabriel,
>  > >   Thanks for the quick review.  I think that David and Jonathan had the
>  > > same idea about using all ones as a mechanism to allow other proto
>  > > types.
>  > >
>  > > I agree that the idea of 256 hops is probably overkill, i think that
>  > > some folks might think 15 hops is too small, but I think probably
>  > > appropriate for 90% of applications.
>  > >
>  > > Also thanks for include Carlos.
>  > >
>  > > Everyone, please weigh-in on this quickly.
>  > >
>  > > geoff
>  > >
>  > > On Thu, 2006-11-02 at 23:51 -0800, gabriel montenegro wrote:
>  > > > [I took the liberty of forwarding the slides and the email thread to
>  > > > the folks at
>  > > > Universidad Politecnica de Catalunya as they have also been involved
>  > > > in implementation
>  > > > work and would have valuable input. I'm cc-ing Carles to include them
>  > > > in the loop.]
>  > > >  
>  > > > Folks,
>  > > >  
>  > > > I have just now looked at the slides, and my first impression is that
>  > > > the format looks quite
>  > > > nice and definitely worth sending out to the list. One minor 
> detail is
>  > > > that the dispatch
>  > > > field is smaller than the current prot_type, but we could just 
> reserve
>  > > > the value
>  > > > of all 1's and use that to signal a subsequent extended dispatch 
> field
>  > > > (like we used
>  > > > to have, and like they've done with hops).
>  > > >  
>  > > > Slides 9 and 10 illustrate the potential gains. I don't think the
>  > > > large hop functionality
>  > > > is very real (the packet drop rate will probably make such long paths
>  > > > pointless). The
>  > > > extensibility, I think we already have (just define more 
> protocol_type
>  > > > values). What I
>  > > > see in the fourth packet figure in slide 12 is more akin to
>  > > > "piggybacking". This is also
>  > > > possible in IPv6, of course, but is not always a good idea as it can
>  > > > get complex real soon.
>  > > > But having the chance of doing piggybacking (several protocols within
>  > > > one packet) could be
>  > > > useful, yes. In summary, I'm more cautious about jumping into
>  > > > piggybacking or deep-hopping
>  > > > than I am about the stacking approach itself.
>  > > >  
>  > > > Other than that, I'd really like to defer to the folks who've engaged
>  > > > in implementation
>  > > > of the current format draft.
>  > > >
>  > > > -gabriel
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Sat Nov 04 15:07:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GgRnJ-00089Y-EB; Sat, 04 Nov 2006 15:07:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GgRnI-00089B-G7
	for 6lowpan@ietf.org; Sat, 04 Nov 2006 15:07:08 -0500
Received: from cs1.sf.archedrock.com ([64.147.171.181]
	helo=secure.archedrock.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgRnF-0004Kr-TZ
	for 6lowpan@ietf.org; Sat, 04 Nov 2006 15:07:08 -0500
Received: by secure.archedrock.com (Postfix, from userid 101)
	id 62CA516B0002; Sat,  4 Nov 2006 12:07:05 -0800 (PST)
Received: from [127.0.0.1] (adsl-71-142-86-178.dsl.pltn13.pacbell.net
	[71.142.86.178])
	by secure.archedrock.com (Postfix) with ESMTP id 14B4E16B0001;
	Sat,  4 Nov 2006 12:07:03 -0800 (PST)
Message-ID: <454CF2E5.1030906@archrock.com>
Date: Sat, 04 Nov 2006 12:07:01 -0800
From: Jonathan Hui <jhui@archrock.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock
References: <20061104183338.27378.qmail@web81908.mail.mud.yahoo.com>
In-Reply-To: <20061104183338.27378.qmail@web81908.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on 
	cs1.sf.archedrock.com
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_SORBS_DUL autolearn=no version=3.0.6
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017
Cc: 6lowpan@ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Errors-To: 6lowpan-bounces@ietf.org


Hi Gabriel, thanks for your feedback as well.

In the current 6lowpan proposal, the prot_type field disappears in 
packets that are subsequent fragments. Thus, the prot_type field in the 
current proposal only allows extensibility in upper layer protocols and 
possibly in packets that do not require fragmentation. In the current 
6lowpan proposal it wasn't clear to us how a new mesh protocol that 
wanted to add a field to the header would do so in a clean way. Also, 
what we were trying to convey with the "piggybacking" capability with 
the stacked headers was that it was possible, not that we should promote 
it.

Overall, what we are trying to promote is a header format that is 
extensible and flexible so that we can cleanly adapt when new ideas or 
unforeseen issues arise in the future. This also applies with the hops 
extension for deep mesh networks.

A few people have already mentioned that 15 hops is fine in most cases. 
But we wanted show that we could support essentially all of the current 
functionality in the 6lowpan proposal (which includes support for >15 
hops) rather than showing reduced functionality.

--
Jonathan Hui
jhui@archrock.com


gabriel montenegro wrote:
> Hi,
>  
> A few of us had a chance to look at this proposal earlier in the week. 
> The message below
> has comments from Carles Gomez, Mario Mao and myself.
>  
> Since it may be of interest to the group, I'm forwarding with permission 
> from Carles and Mario.
>  
> -gabriel
> 
> ----- Forwarded Message ----
> From: Mario Mao <mariomao@gmail.com>
> To: Carles Gomez <carlesgo@mat.upc.edu>; Geoff Mulligan <geoff@mulligan.com>
> Cc: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>; Ki-Hyung Kim 
> <kkim86@gmail.com>; Daniel Park <soohong.park@samsung.com>; Carsten 
> Bormann <cabo@tzi.de>; Christian Schumacher <schumacher@danfoss.com>
> Sent: Friday, November 3, 2006 5:21:40 AM
> Subject: Re: any comments on the proposal from Arch Rock
> 
> Hi All,
> 
> I would propose my opinions from the view of implementation, thanks.
> 
> First, I would say the new format is clear and supply more expansibility 
> (just like IPv6 extension header).
> 
> For my concern, the multicast ability. For the most important reason of 
> changing original byte-alignment format to current one is to add B bit 
> and supply way of distinguishing seqno, how about that in new format? I 
> don't see how does it work for this situation. Have I missed the 
> critical point, thanks if author could give some hint.
> 
> About the hops left, I also agree the 15 hops would enough for most 
> cases. In our environment, more than 10 hops would cause a surprising 
> lag (beacon interval set to 1s). However, it is always right to save 
> space for further development, we should figure out a good method to 
> balance them.
> 
> At last, simple to implement. By our experience, new format may not 
> bring convenience. We still have more than 3 headers/extensions to 
> handle, equal to previous one (may more complex...). But the new format 
> do bring benefits beyond that. For our tests show the original format 
> affords enough ability for common IPv6 application over WSN, if the new 
> one could follow the function exactly and not bring conflict, I vote for 
> the hard packet format changing.
> 
> Regards,
> 
> Mario Mao
> MarioMao@Gmail.com
> 
> 
> ----- Original Message -----
> From: "Carles Gomez" <carlesgo@mat.upc.edu>
> To: "Geoff Mulligan" <geoff@mulligan.com>
> Cc: "gabriel montenegro" <gabriel_montenegro_2000@yahoo.com>; "Ki-Hyung 
> Kim" <kkim86@gmail.com>; "Daniel Park" <soohong.park@samsung.com>; 
> "Carsten Bormann" <cabo@tzi.de>; "Christian Schumacher" 
> <schumacher@danfoss.com>; <mariomao@gmail.com>
> Sent: Friday, November 03, 2006 6:47 PM
> Subject: Re: any comments on the proposal from Arch Rock
> 
> 
>  > Dear all,
>  >
>  > We believe the proposed new format is clearer and allows development of
>  > extensions and addition of new options in an easier way, which is 
> relevant
>  > from the point of view of implementation.
>  >
>  > In general, the new format allows for byte savings in most cases. 
> However,
>  > just to keep a fair comparison (it seems like the slides try to 
> represent the
>  > most favorable case for ArchRock proposal) it must be noted that when
>  > fragmentation is needed, an offset field with a size equal to one 
> byte must be
>  > added to fragments other than the first one. Hence, in some cases as 
> in slide
>  > 9, "Multihop > 14 hops", 7 bytes would be needed with the new format for
>  > fragments other than the first one, which is one byte more than that 
> needed
>  > with the current 6lowpan proposal. Anyway, the overall result seems 
> to be a
>  > clearer format with roughly the same size (in some cases smaller, in 
> some
>  > others the same as, and in some others greater than that of the current
>  > 6lowpan proposal).
>  >
>  > Regarding the number of hops, I agree that 15 hops should be enough 
> in most
>  > cases.
>  >
>  > Best regards,
>  >
>  > Carles Gomez
>  > Technical University of Catalonia
>  >
>  > Quoting Geoff Mulligan <geoff@mulligan.com>:
>  >
>  > > Gabriel,
>  > >   Thanks for the quick review.  I think that David and Jonathan had the
>  > > same idea about using all ones as a mechanism to allow other proto
>  > > types.
>  > >
>  > > I agree that the idea of 256 hops is probably overkill, i think that
>  > > some folks might think 15 hops is too small, but I think probably
>  > > appropriate for 90% of applications.
>  > >
>  > > Also thanks for include Carlos.
>  > >
>  > > Everyone, please weigh-in on this quickly.
>  > >
>  > > geoff
>  > >
>  > > On Thu, 2006-11-02 at 23:51 -0800, gabriel montenegro wrote:
>  > > > [I took the liberty of forwarding the slides and the email thread to
>  > > > the folks at
>  > > > Universidad Politecnica de Catalunya as they have also been involved
>  > > > in implementation
>  > > > work and would have valuable input. I'm cc-ing Carles to include them
>  > > > in the loop.]
>  > > >  
>  > > > Folks,
>  > > >  
>  > > > I have just now looked at the slides, and my first impression is that
>  > > > the format looks quite
>  > > > nice and definitely worth sending out to the list. One minor 
> detail is
>  > > > that the dispatch
>  > > > field is smaller than the current prot_type, but we could just 
> reserve
>  > > > the value
>  > > > of all 1's and use that to signal a subsequent extended dispatch 
> field
>  > > > (like we used
>  > > > to have, and like they've done with hops).
>  > > >  
>  > > > Slides 9 and 10 illustrate the potential gains. I don't think the
>  > > > large hop functionality
>  > > > is very real (the packet drop rate will probably make such long paths
>  > > > pointless). The
>  > > > extensibility, I think we already have (just define more 
> protocol_type
>  > > > values). What I
>  > > > see in the fourth packet figure in slide 12 is more akin to
>  > > > "piggybacking". This is also
>  > > > possible in IPv6, of course, but is not always a good idea as it can
>  > > > get complex real soon.
>  > > > But having the chance of doing piggybacking (several protocols within
>  > > > one packet) could be
>  > > > useful, yes. In summary, I'm more cautious about jumping into
>  > > > piggybacking or deep-hopping
>  > > > than I am about the stacking approach itself.
>  > > >  
>  > > > Other than that, I'd really like to defer to the folks who've engaged
>  > > > in implementation
>  > > > of the current format draft.
>  > > >
>  > > > -gabriel
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Sun Nov 05 11:59:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GglL6-0002hH-GR; Sun, 05 Nov 2006 11:59:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GglL4-0002h9-U3
	for 6lowpan@ietf.org; Sun, 05 Nov 2006 11:59:18 -0500
Received: from web81910.mail.mud.yahoo.com ([68.142.207.189])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GglL2-0001vA-F7
	for 6lowpan@ietf.org; Sun, 05 Nov 2006 11:59:18 -0500
Received: (qmail 16152 invoked by uid 60001); 5 Nov 2006 16:59:01 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=rXG3zZaMj6Z/tC94rekpTs/vhPIYFtZTWdOTiLnJf7sCUC2eeHsTixFz8LkpowGrcZ48LXHURxRp0arn7xK3ZKqRU4VNBiqlWTFynsAWQYGcW/LNblb6fVMigDfCkl7myRGbs10gst5V34sDKFNllKV9h7x02wyJdGdXRcmwgBw=
	; 
Message-ID: <20061105165900.16105.qmail@web81910.mail.mud.yahoo.com>
Received: from [24.16.14.130] by web81910.mail.mud.yahoo.com via HTTP;
	Sun, 05 Nov 2006 08:58:59 PST
Date: Sun, 5 Nov 2006 08:58:58 -0800 (PST)
From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock
To: Jonathan Hui <jhui@archrock.com>
MIME-Version: 1.0
X-Spam-Score: 1.0 (+)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: 6lowpan@ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1158795150=="
Errors-To: 6lowpan-bounces@ietf.org

--===============1158795150==
Content-Type: multipart/alternative; boundary="0-460982252-1162745939=:16043"

--0-460982252-1162745939=:16043
Content-Type: text/plain; charset=ascii
Content-Transfer-Encoding: quoted-printable

Jonathan,=0A=0A=0AI'm confused by your paragraph below. I'm not sure what y=
ou mean by=0Athis. The prot_type field disappearing in subsequent packets h=
as no =0Abearing on extensibility as I understand it. For example, if you w=
ere=0Ato in the future decide to carry, say, RNP ("random network protocol"=
)=0Aover the current lowpan encapsulation, you'd have a prot_type value =0A=
assigned for RNP. This would allow you to send RNP over lowpan even if=0Ayo=
u had a mesh configuration underneath (the mesh delivery header being=0Aa g=
eneral lowpan layer service), or if your RNP packets were large=0A(by using=
 the fragmentation service, again a general lowpan layer=0Aservice). If a r=
eceiving station were to receive, say, a fragment=0Afor an packet, it might=
 not be able to know that it is RNP until=0Amore fragments arrive. But it w=
ouldn't be able to do anything until=0Athe entire RNP packet arrives anyway=
s. Just like in IPv4 or v6 fragmentation.=0A=0AOr did you have something el=
se in mind?=0A=0Atnx,=0A=0A-gabriel=0A=0A----- Original Message ----=0AIn t=
he current 6lowpan proposal, the prot_type field disappears in =0Apackets t=
hat are subsequent fragments. Thus, the prot_type field in the =0Acurrent p=
roposal only allows extensibility in upper layer protocols and =0Apossibly =
in packets that do not require fragmentation. In the current =0A6lowpan pro=
posal it wasn't clear to us how a new mesh protocol that =0Awanted to add a=
 field to the header would do so in a clean way. Also, =0Awhat we were tryi=
ng to convey with the "piggybacking" capability with =0Athe stacked headers=
 was that it was possible, not that we should promote =0Ait.
--0-460982252-1162745939=:16043
Content-Type: text/html; charset=ascii
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:courier, monaco, monospace, sans-serif;f=
ont-size:12pt"><DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco,=
 monospace, sans-serif">Jonathan,</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FO=
NT-FAMILY: courier, monaco, monospace, sans-serif"> </DIV>=0A<DIV styl=
e=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">=
<BR>I'm confused by your paragraph below. I'm not sure what you mean by</DI=
V>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace=
, sans-serif">this. The prot_type field disappearing in subsequent packets =
has no </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco=
, monospace, sans-serif">bearing on extensibility as I understand it. For e=
xample, if you were</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: cou=
rier, monaco, monospace, sans-serif">to in the future decide to carry, say,=
 RNP ("random network protocol")</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FON=
T-FAMILY: courier, monaco, monospace, sans-serif">over the current lowpan e=
ncapsulation, you'd have a prot_type value </DIV>=0A<DIV style=3D"FONT-SIZE=
: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">assigned for R=
NP. This would allow you to send RNP over lowpan even if</DIV>=0A<DIV style=
=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">y=
ou had a mesh configuration underneath (the mesh delivery header being</DIV=
>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace,=
 sans-serif">a general lowpan layer service), or if your RNP packets were l=
arge</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, m=
onospace, sans-serif">(by using the fragmentation service, again a general =
lowpan layer</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, m=
onaco, monospace, sans-serif">service). If a receiving station were to rece=
ive, say, a fragment</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: co=
urier, monaco, monospace, sans-serif">for an packet, it might not be able t=
o know that it is RNP until</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAM=
ILY: courier, monaco, monospace, sans-serif">more fragments arrive. But it =
wouldn't be able to do anything until</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt=
; FONT-FAMILY: courier, monaco, monospace, sans-serif">the entire RNP packe=
t arrives anyways. Just like in IPv4 or v6 fragmentation.</DIV>=0A<DIV styl=
e=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">=
 </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco,=
 monospace, sans-serif">Or did you have something else in mind?</DIV>=0A<DI=
V style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-s=
erif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, m=
onaco, monospace, sans-serif">tnx,</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; F=
ONT-FAMILY: courier, monaco, monospace, sans-serif"> </DIV>=0A<DIV sty=
le=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif"=
>-gabriel<BR></DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new=
 roman, new york, times, serif">----- Original Message ----<BR>In the curre=
nt 6lowpan proposal, the prot_type field disappears in <BR>packets that are=
 subsequent fragments. Thus, the prot_type field in the <BR>current proposa=
l only allows extensibility in upper layer protocols and <BR>possibly in pa=
ckets that do not require fragmentation. In the current <BR>6lowpan proposa=
l it wasn't clear to us how a new mesh protocol that <BR>wanted to add a fi=
eld to the header would do so in a clean way. Also, <BR>what we were trying=
 to convey with the "piggybacking" capability with <BR>the stacked headers =
was that it was possible, not that we should promote <BR>it.<BR></DIV></div=
></body></html>
--0-460982252-1162745939=:16043--


--===============1158795150==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--===============1158795150==--




From 6lowpan-bounces@ietf.org Sun Nov 05 12:41:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ggm05-0001Ea-8L; Sun, 05 Nov 2006 12:41:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggm03-00019f-Ik
	for 6lowpan@ietf.org; Sun, 05 Nov 2006 12:41:39 -0500
Received: from cs1.sf.archedrock.com ([64.147.171.181]
	helo=secure.archedrock.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gglzy-0006Io-6H
	for 6lowpan@ietf.org; Sun, 05 Nov 2006 12:41:37 -0500
Received: by secure.archedrock.com (Postfix, from userid 101)
	id 9F4F916B0002; Sun,  5 Nov 2006 09:41:15 -0800 (PST)
Received: from [127.0.0.1] (adsl-71-142-86-178.dsl.pltn13.pacbell.net
	[71.142.86.178])
	by secure.archedrock.com (Postfix) with ESMTP id CDFD716B0001;
	Sun,  5 Nov 2006 09:41:14 -0800 (PST)
Message-ID: <454E2238.7000002@archrock.com>
Date: Sun, 05 Nov 2006 09:41:12 -0800
From: Jonathan Hui <jhui@archrock.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock
References: <20061105165900.16105.qmail@web81910.mail.mud.yahoo.com>
In-Reply-To: <20061105165900.16105.qmail@web81910.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on 
	cs1.sf.archedrock.com
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_SORBS_DUL autolearn=no version=3.0.6
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: 6lowpan@ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Errors-To: 6lowpan-bounces@ietf.org


Gabriel,

You are correct that you can use prot_type to allow extensibility above 
both the mesh and fragmentation layer. However, I was trying to get at 
extensibility at layers between the mesh and fragmentation. IPv6 
suggests that hop-by-hop options (e.g. a sequence number for 
broadcast/multicast) and routing headers (for source route) should come 
after addressing but before fragmentation. If these hop-by-hop/routing 
headers help determine how a packet is routed, then this allows 
individual fragments to be routed without having to do any form a 
reassembly at each hop and without requiring nodes to keep state for a 
stream of IP packet fragments. This advantage could be especially useful 
for mesh networks with memory constrained devices. It was unclear to us 
how you would support such functionality cleanly in the current 6lowpan 
format because the prot_type field turns into the datagram_offset field 
in subsequent fragments.

Does that clear things up a bit?

--
Jonathan Hui
jhui@archrock.com


gabriel montenegro wrote:
> Jonathan,
>  
> 
> I'm confused by your paragraph below. I'm not sure what you mean by
> this. The prot_type field disappearing in subsequent packets has no
> bearing on extensibility as I understand it. For example, if you were
> to in the future decide to carry, say, RNP ("random network protocol")
> over the current lowpan encapsulation, you'd have a prot_type value
> assigned for RNP. This would allow you to send RNP over lowpan even if
> you had a mesh configuration underneath (the mesh delivery header being
> a general lowpan layer service), or if your RNP packets were large
> (by using the fragmentation service, again a general lowpan layer
> service). If a receiving station were to receive, say, a fragment
> for an packet, it might not be able to know that it is RNP until
> more fragments arrive. But it wouldn't be able to do anything until
> the entire RNP packet arrives anyways. Just like in IPv4 or v6 
> fragmentation.
>  
> Or did you have something else in mind?
>  
> tnx,
>  
> -gabriel
> ----- Original Message ----
> In the current 6lowpan proposal, the prot_type field disappears in
> packets that are subsequent fragments. Thus, the prot_type field in the
> current proposal only allows extensibility in upper layer protocols and
> possibly in packets that do not require fragmentation. In the current
> 6lowpan proposal it wasn't clear to us how a new mesh protocol that
> wanted to add a field to the header would do so in a clean way. Also,
> what we were trying to convey with the "piggybacking" capability with
> the stacked headers was that it was possible, not that we should promote
> it.

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Sun Nov 05 13:45:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ggmzx-0001AB-Pm; Sun, 05 Nov 2006 13:45:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggmzw-0001A5-Q5
	for 6lowpan@ietf.org; Sun, 05 Nov 2006 13:45:36 -0500
Received: from web81907.mail.mud.yahoo.com ([68.142.207.186])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ggmzv-0001pG-87
	for 6lowpan@ietf.org; Sun, 05 Nov 2006 13:45:36 -0500
Received: (qmail 26035 invoked by uid 60001); 5 Nov 2006 18:45:34 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type;
	b=PfeaAO9/UMy6p2Esqq5/QlBh6+vWbLT0APgTBzOJKIGgnkIV9WtGDsMBybRM9GXoR8Eqj3fRQ35L716gmUF7YeFPcRnZE8BUW548ErDgiVFtUcKKTGKOYh266V9StEwFZu0oWnx7mWHqm0hIlCz2Iz9nE5Zwkidc88MsdW3mXx0=
	; 
Message-ID: <20061105184534.26033.qmail@web81907.mail.mud.yahoo.com>
Received: from [24.16.14.130] by web81907.mail.mud.yahoo.com via HTTP;
	Sun, 05 Nov 2006 10:45:34 PST
Date: Sun, 5 Nov 2006 10:45:34 -0800 (PST)
From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock
To: Jonathan Hui <jhui@archrock.com>
MIME-Version: 1.0
X-Spam-Score: 0.9 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
Cc: 6lowpan@ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0226194166=="
Errors-To: 6lowpan-bounces@ietf.org

--===============0226194166==
Content-Type: multipart/alternative; boundary="0-1413705422-1162752334=:24982"

--0-1413705422-1162752334=:24982
Content-Type: text/plain; charset=ascii
Content-Transfer-Encoding: quoted-printable

Each fragment is routed independently of each other by virtue of the mesh h=
eader, right?=0AEach node forwards each individual fragment according to it=
s routing table, exactly the same=0Aas for any unfragmented packet, so ther=
e is no additional state for fragments as compared to=0Anon-fragments. The =
only node that keeps fragments around for reassembly is the end-node, as it=
=0Ais an e2e reassembly procedure (as in IPv6).=0A=0AWhat you're pointing o=
ut, I think, is not a lack of extensibility per se, but a lack of=0Asupport=
 for source routing at the mesh header, which was a conscious decision, yes=
. =0A=0AAdding support for source routing does not require one to carry the=
 prot_type field in=0Aeach fragment. It would require modifying the mesh de=
livery header to include source routes,=0Anot just mesh origin and mesh des=
tination address. =0A=0AI now see that you're doing this a bit differently.=
 Instead of the lowpan adaptation layer=0Ahandling source routes, you wish =
to handle it as different protocol itself. =0A=0A-gabriel=0A=0A=0A----- Ori=
ginal Message ----=0AFrom: Jonathan Hui <jhui@archrock.com>=0ATo: gabriel m=
ontenegro <gabriel_montenegro_2000@yahoo.com>=0ACc: 6lowpan@ietf.org=0ASent=
: Sunday, November 5, 2006 9:41:12 AM=0ASubject: Re: [6lowpan] Fw: any comm=
ents on the proposal from Arch Rock=0A=0A=0AGabriel,=0A=0AYou are correct t=
hat you can use prot_type to allow extensibility above =0Aboth the mesh and=
 fragmentation layer. However, I was trying to get at =0Aextensibility at l=
ayers between the mesh and fragmentation. IPv6 =0Asuggests that hop-by-hop =
options (e.g. a sequence number for =0Abroadcast/multicast) and routing hea=
ders (for source route) should come =0Aafter addressing but before fragment=
ation. If these hop-by-hop/routing =0Aheaders help determine how a packet i=
s routed, then this allows =0Aindividual fragments to be routed without hav=
ing to do any form a =0Areassembly at each hop and without requiring nodes =
to keep state for a =0Astream of IP packet fragments. This advantage could =
be especially useful =0Afor mesh networks with memory constrained devices. =
It was unclear to us =0Ahow you would support such functionality cleanly in=
 the current 6lowpan =0Aformat because the prot_type field turns into the d=
atagram_offset field =0Ain subsequent fragments.=0A=0ADoes that clear thing=
s up a bit?=0A=0A--=0AJonathan Hui=0Ajhui@archrock.com=0A=0A=0Agabriel mont=
enegro wrote:=0A> Jonathan,=0A>  =0A> =0A> I'm confused by your paragraph b=
elow. I'm not sure what you mean by=0A> this. The prot_type field disappear=
ing in subsequent packets has no=0A> bearing on extensibility as I understa=
nd it. For example, if you were=0A> to in the future decide to carry, say, =
RNP ("random network protocol")=0A> over the current lowpan encapsulation, =
you'd have a prot_type value=0A> assigned for RNP. This would allow you to =
send RNP over lowpan even if=0A> you had a mesh configuration underneath (t=
he mesh delivery header being=0A> a general lowpan layer service), or if yo=
ur RNP packets were large=0A> (by using the fragmentation service, again a =
general lowpan layer=0A> service). If a receiving station were to receive, =
say, a fragment=0A> for an packet, it might not be able to know that it is =
RNP until=0A> more fragments arrive. But it wouldn't be able to do anything=
 until=0A> the entire RNP packet arrives anyways. Just like in IPv4 or v6 =
=0A> fragmentation.=0A>  =0A> Or did you have something else in mind?=0A>  =
=0A> tnx,=0A>  =0A> -gabriel=0A> ----- Original Message ----=0A> In the cur=
rent 6lowpan proposal, the prot_type field disappears in=0A> packets that a=
re subsequent fragments. Thus, the prot_type field in the=0A> current propo=
sal only allows extensibility in upper layer protocols and=0A> possibly in =
packets that do not require fragmentation. In the current=0A> 6lowpan propo=
sal it wasn't clear to us how a new mesh protocol that=0A> wanted to add a =
field to the header would do so in a clean way. Also,=0A> what we were tryi=
ng to convey with the "piggybacking" capability with=0A> the stacked header=
s was that it was possible, not that we should promote=0A> it.
--0-1413705422-1162752334=:24982
Content-Type: text/html; charset=ascii
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:courier, monaco, monospace, sans-serif;f=
ont-size:12pt"><DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco,=
 monospace, sans-serif">Each fragment is routed independently of each other=
 by virtue of the mesh header, right?</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt=
; FONT-FAMILY: courier, monaco, monospace, sans-serif">Each node forwards e=
ach individual fragment according to its routing table, exactly the same</D=
IV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospac=
e, sans-serif">as for any unfragmented packet, so there is no additional st=
ate for fragments as compared to</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FON=
T-FAMILY: courier, monaco, monospace, sans-serif">non-fragments. The only n=
ode that keeps fragments around for reassembly is the end-node, as it</DIV>=
=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, =
sans-serif">is an e2e reassembly procedure (as in IPv6).</DIV>=0A<DIV style=
=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">&=
nbsp;</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, =
monospace, sans-serif">What you're pointing out, I think, is not a lack of =
extensibility per se, but a lack of</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; =
FONT-FAMILY: courier, monaco, monospace, sans-serif">support for source rou=
ting at the mesh header, which was a conscious decision, yes. </DIV>=0A<DIV=
 style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-se=
rif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, mo=
naco, monospace, sans-serif">Adding support for source routing does not req=
uire one to carry the prot_type field in</DIV>=0A<DIV style=3D"FONT-SIZE: 1=
2pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">each fragment. It=
 would require modifying the mesh delivery header to include source routes,=
</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monos=
pace, sans-serif">not just mesh origin and mesh destination address. </DIV>=
=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, =
sans-serif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: cour=
ier, monaco, monospace, sans-serif">I now see that you're doing this a bit =
differently. Instead of the lowpan adaptation layer</DIV>=0A<DIV style=3D"F=
ONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">handli=
ng source routes, you wish to handle it as different protocol itself. </DIV=
>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace,=
 sans-serif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: cou=
rier, monaco, monospace, sans-serif">-gabriel<BR><BR></DIV>=0A<DIV style=3D=
"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">---=
-- Original Message ----<BR>From: Jonathan Hui <jhui@archrock.com><BR=
>To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com><BR>Cc: 6l=
owpan@ietf.org<BR>Sent: Sunday, November 5, 2006 9:41:12 AM<BR>Subject: Re:=
 [6lowpan] Fw: any comments on the proposal from Arch Rock<BR><BR>=0A<DIV>G=
abriel,<BR><BR>You are correct that you can use prot_type to allow extensib=
ility above <BR>both the mesh and fragmentation layer. However, I was tryin=
g to get at <BR>extensibility at layers between the mesh and fragmentation.=
 IPv6 <BR>suggests that hop-by-hop options (e.g. a sequence number for <BR>=
broadcast/multicast) and routing headers (for source route) should come <BR=
>after addressing but before fragmentation. If these hop-by-hop/routing <BR=
>headers help determine how a packet is routed, then this allows <BR>indivi=
dual fragments to be routed without having to do any form a <BR>reassembly =
at each hop and without requiring nodes to keep state for a <BR>stream of I=
P packet fragments. This advantage could be especially useful <BR>for mesh =
networks with memory constrained devices. It was unclear to us <BR>how you =
would support such functionality cleanly in the current 6lowpan <BR>format =
because the prot_type field turns into the datagram_offset field <BR>in sub=
sequent
 fragments.<BR><BR>Does that clear things up a bit?<BR><BR>--<BR>Jonathan H=
ui<BR>jhui@archrock.com<BR><BR><BR>gabriel montenegro wrote:<BR>> Jonath=
an,<BR>>  <BR>> <BR>> I'm confused by your paragraph bel=
ow. I'm not sure what you mean by<BR>> this. The prot_type field disappe=
aring in subsequent packets has no<BR>> bearing on extensibility as I un=
derstand it. For example, if you were<BR>> to in the future decide to ca=
rry, say, RNP ("random network protocol")<BR>> over the current lowpan e=
ncapsulation, you'd have a prot_type value<BR>> assigned for RNP. This w=
ould allow you to send RNP over lowpan even if<BR>> you had a mesh confi=
guration underneath (the mesh delivery header being<BR>> a general lowpa=
n layer service), or if your RNP packets were large<BR>> (by using the f=
ragmentation service, again a general lowpan layer<BR>> service). If a r=
eceiving station were to receive, say, a fragment<BR>> for an packet, it=
 might not be
 able to know that it is RNP until<BR>> more fragments arrive. But it wo=
uldn't be able to do anything until<BR>> the entire RNP packet arrives a=
nyways. Just like in IPv4 or v6 <BR>> fragmentation.<BR>>  =
<BR>> Or did you have something else in mind?<BR>>  <BR>>=
; tnx,<BR>>  <BR>> -gabriel<BR>> ----- Original Message =
----<BR>> In the current 6lowpan proposal, the prot_type field disappear=
s in<BR>> packets that are subsequent fragments. Thus, the prot_type fie=
ld in the<BR>> current proposal only allows extensibility in upper layer=
 protocols and<BR>> possibly in packets that do not require fragmentatio=
n. In the current<BR>> 6lowpan proposal it wasn't clear to us how a new =
mesh protocol that<BR>> wanted to add a field to the header would do so =
in a clean way. Also,<BR>> what we were trying to convey with the "piggy=
backing" capability with<BR>> the stacked headers was that it was possib=
le, not that
 we should promote<BR>> it.</DIV></DIV>=0A<DIV style=3D"FONT-SIZE: 12pt;=
 FONT-FAMILY: courier, monaco, monospace, sans-serif"><BR></DIV></div></bod=
y></html>
--0-1413705422-1162752334=:24982--


--===============0226194166==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--===============0226194166==--




From 6lowpan-bounces@ietf.org Sun Nov 05 15:45:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GgosQ-00030Q-1f; Sun, 05 Nov 2006 15:45:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GgosO-00030D-Eq
	for 6lowpan@ietf.org; Sun, 05 Nov 2006 15:45:56 -0500
Received: from cs1.sf.archedrock.com ([64.147.171.181]
	helo=secure.archedrock.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgosM-00074c-WB
	for 6lowpan@ietf.org; Sun, 05 Nov 2006 15:45:56 -0500
Received: by secure.archedrock.com (Postfix, from userid 101)
	id 6E6F616B0001; Sun,  5 Nov 2006 12:45:52 -0800 (PST)
Received: from [127.0.0.1] (adsl-71-142-86-178.dsl.pltn13.pacbell.net
	[71.142.86.178])
	by secure.archedrock.com (Postfix) with ESMTP id 7646A16B0001;
	Sun,  5 Nov 2006 12:45:51 -0800 (PST)
Message-ID: <454E4D7E.4030307@archrock.com>
Date: Sun, 05 Nov 2006 12:45:50 -0800
From: Jonathan Hui <jhui@archrock.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock
References: <20061105184534.26033.qmail@web81907.mail.mud.yahoo.com>
In-Reply-To: <20061105184534.26033.qmail@web81907.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on 
	cs1.sf.archedrock.com
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_SORBS_DUL autolearn=no version=3.0.6
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Cc: 6lowpan@ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Errors-To: 6lowpan-bounces@ietf.org


What I'm arguing is that there are times where only addressing is not 
enough. This was made clear by the addition of the B-bit in the 6lowpan 
adaptation header, which required changing the 6lowpan adaptation header 
for subsequent fragments because there were no additional reserved bits. 
My argument is that the current adaptation header is relatively 
unforgiving if for some unforseen reason that the 8-bit additional field 
given by setting the B-bit is not enough. Specifically for 
broadcast/multicast protocols, it restricts them to using an 8-bit field 
for whatever extra information they might need. I'm not comfortable with 
making such a bold statement, maybe others are. But once the 6lowpan 
header format has been standardized and adopted widely, it becomes very 
difficult for us to simply modify the header again. In my view, having 
the ability to specify header stacks provides a clean way of extending 
the header, whether or not you view the entire header stack as an 
adaptation header or as a set of separate protocols below the IP layer.

--
Jonathan Hui
jhui@archrock.com


gabriel montenegro wrote:
> Each fragment is routed independently of each other by virtue of the 
> mesh header, right?
> Each node forwards each individual fragment according to its routing 
> table, exactly the same
> as for any unfragmented packet, so there is no additional state for 
> fragments as compared to
> non-fragments. The only node that keeps fragments around for reassembly 
> is the end-node, as it
> is an e2e reassembly procedure (as in IPv6).
>  
> What you're pointing out, I think, is not a lack of extensibility per 
> se, but a lack of
> support for source routing at the mesh header, which was a conscious 
> decision, yes.
>  
> Adding support for source routing does not require one to carry the 
> prot_type field in
> each fragment. It would require modifying the mesh delivery header to 
> include source routes,
> not just mesh origin and mesh destination address.
>  
> I now see that you're doing this a bit differently. Instead of the 
> lowpan adaptation layer
> handling source routes, you wish to handle it as different protocol itself.
>  
> -gabriel
> 
> ----- Original Message ----
> From: Jonathan Hui <jhui@archrock.com>
> To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
> Cc: 6lowpan@ietf.org
> Sent: Sunday, November 5, 2006 9:41:12 AM
> Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock
> 
> Gabriel,
> 
> You are correct that you can use prot_type to allow extensibility above
> both the mesh and fragmentation layer. However, I was trying to get at
> extensibility at layers between the mesh and fragmentation. IPv6
> suggests that hop-by-hop options (e.g. a sequence number for
> broadcast/multicast) and routing headers (for source route) should come
> after addressing but before fragmentation. If these hop-by-hop/routing
> headers help determine how a packet is routed, then this allows
> individual fragments to be routed without having to do any form a
> reassembly at each hop and without requiring nodes to keep state for a
> stream of IP packet fragments. This advantage could be especially useful
> for mesh networks with memory constrained devices. It was unclear to us
> how you would support such functionality cleanly in the current 6lowpan
> format because the prot_type field turns into the datagram_offset field
> in subsequent fragments.
> 
> Does that clear things up a bit?
> 
> --
> Jonathan Hui
> jhui@archrock.com
> 
> 
> gabriel montenegro wrote:
>  > Jonathan,
>  >  
>  >
>  > I'm confused by your paragraph below. I'm not sure what you mean by
>  > this. The prot_type field disappearing in subsequent packets has no
>  > bearing on extensibility as I understand it. For example, if you were
>  > to in the future decide to carry, say, RNP ("random network protocol")
>  > over the current lowpan encapsulation, you'd have a prot_type value
>  > assigned for RNP. This would allow you to send RNP over lowpan even if
>  > you had a mesh configuration underneath (the mesh delivery header being
>  > a general lowpan layer service), or if your RNP packets were large
>  > (by using the fragmentation service, again a general lowpan layer
>  > service). If a receiving station were to receive, say, a fragment
>  > for an packet, it might not be able to know that it is RNP until
>  > more fragments arrive. But it wouldn't be able to do anything until
>  > the entire RNP packet arrives anyways. Just like in IPv4 or v6
>  > fragmentation.
>  >  
>  > Or did you have something else in mind?
>  >  
>  > tnx,
>  >  
>  > -gabriel
>  > ----- Original Message ----
>  > In the current 6lowpan proposal, the prot_type field disappears in
>  > packets that are subsequent fragments. Thus, the prot_type field in the
>  > current proposal only allows extensibility in upper layer protocols and
>  > possibly in packets that do not require fragmentation. In the current
>  > 6lowpan proposal it wasn't clear to us how a new mesh protocol that
>  > wanted to add a field to the header would do so in a clean way. Also,
>  > what we were trying to convey with the "piggybacking" capability with
>  > the stacked headers was that it was possible, not that we should promote
>  > it.
> 

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Sun Nov 05 18:09:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ggr7L-0003BK-I5; Sun, 05 Nov 2006 18:09:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggr7K-0003BF-L0
	for 6lowpan@ietf.org; Sun, 05 Nov 2006 18:09:30 -0500
Received: from nf-out-0910.google.com ([64.233.182.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggr7H-0007iU-Os
	for 6lowpan@ietf.org; Sun, 05 Nov 2006 18:09:30 -0500
Received: by nf-out-0910.google.com with SMTP id n29so1093831nfc
	for <6lowpan@ietf.org>; Sun, 05 Nov 2006 15:09:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=bbIQz/P10/Bieg2zHfD+mt/NF4VjJs9PD37q2ZlCly5tZo6xKmFethT7BHuyHuge8pKLJie2k6jh7OR4tCfp7zFSNaXjDqX9WtGZAQkwOmACuPYkepYDSYIgO1Eg0Mw2SUiTYwB4218zLv61U6eBwK07i/OYlDa6UlB4phOXwjk=
Received: by 10.82.147.6 with SMTP id u6mr612812bud.1162768166367;
	Sun, 05 Nov 2006 15:09:26 -0800 (PST)
Received: by 10.82.182.18 with HTTP; Sun, 5 Nov 2006 15:09:26 -0800 (PST)
Message-ID: <43b91d370611051509u3dd8d25bi30f51d2b5a522fbf@mail.gmail.com>
Date: Sun, 5 Nov 2006 15:09:26 -0800
From: "Samita Chakrabarti" <samitac2@gmail.com>
To: "Mario Mao" <mariomao@gmail.com>
Subject: Re: [6LoWPAN] Router Dynamic Advertisement Algorithm (RDA)
In-Reply-To: <015501c6fbef$5582aa60$7fc0a8c0@netlab.cs.ecnu.edu.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <015501c6fbef$5582aa60$7fc0a8c0@netlab.cs.ecnu.edu.cn>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53
Cc: 6lowpan@ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Errors-To: 6lowpan-bounces@ietf.org

Hi Mario,


Please see my comments below.

> By confirming with Gabriel, I would update some results of our team's work
> on 6LoWPAN, please take it as a reference and give any comment needed,
> thanks.
>

Did you also have an implementation of our 6lowpan-ipv6-nd draft ?

> Basically, our team's work follows drafts prompted by WG. however, we find
> something should be included when implementing. Below is one of the things
> beyond draft: Router Dynamic Advertisement Algorithm (RDA).
>
> For Chakrabarti, I know it is a really different way from the optimization
> in draft 6lowpan-ipv6-nd. But when we design and implement the 6LoWPAN
> stack, we did find it is effective and easier to implement. Hope the idea in
> this mail could do some help, thanks.
>

Are you saying that you implemented RDA algorithm instead ?  How did
you use multicast and controlled flooding at the link-layer(802.15.4)
? Have you
used a simulation or set of real sensors to implement and take measurements?

The main idea of  our 6lowpan-nd draft is to minimize the broadcast or all-node
multicast messages to the low-powered nodes in order to save energy while
maintaining the efficiency of the initiating node. Thus we optimize for unicast
messaging and sometimes use the existing algorithm in IPv6 ND - so it should
be simple to implement. The idea could be applicable beyond 6lowpan scenarios,
i.e to any network that wants to run energy-efficient IPv6 ND protocol.

Thanks,
-Samita




> ===========================
>
> Router Discovery, Prefix and Parameter Discovery need RS and RA message
> defined in NDP. In LoWPAN environment, we need avoid the power consuming
> caused by broadcasting these kinds of message periodically. On the other
> hand, it is not a good idea to simply increase the announcement interval to
> a large value. It would make the network insensitive and lead some child
> nodes inaccessible before they could configure a ipv6 global address. To
> balance them, Host and Router use Router Dynamic Advertisement Algorithm
> (RDA) to send RS and RA.
>
> 1. Assumption
>
> In our environment, we don't conside IPv6 routers would be known by all
> sensor nodes before they get their announcement explicitly. This
> consideration would work for multiple sink scenario. There could be more
> than one sink (router) to balance the load around sink (router). So, Host
> need to send Mulitcast RS or wait for RA.
>
> To support IP multicast, broadcast ability in adaptation layer should be
> included. We have introduced a controlled flooding mechanism to supply such
> kind of requirment. You could get the mean idea in the mail before, I
> remember I have sent it to mail list about 3 months ago.
>
> At last, there will be a little change to RFC2461 on the RA announcement
> interval, not more, but do have. Will it be a big problem? Our
> implementation support both the two way of RA sending algotithm in a single
> Router, one for standard, one for LoWPAN. People could confiure interface to
> use any of them, that means, no conflict between two different links, eg.
> standard for Ethernet and RDA for IEEE 802.15.4. Our test show the Route and
> Host would work fine when enable two advertising interfaces which use
> different advertising algorithm.
>
> 2. Host
>
> When Host starts up, it hold the initial multicast RS until TIME_WAIT_FOR_RA
> elapseed. If Host still miss the wanted RA, a multicast RS should be sent
> out. For TIME_WAIT_FOR_RA, it is a random value between BASE_RA_INTERVAL and
> 2*BASE_RA_INTERVAL. Another, the source address of RS should use unicast
> address but not ::, that make Router could unicast the RA message back to
> Host.
>
> For application that want immediate access to every sensor node,
> TIME_WAIT_FOR_RA could use another smaller value which let RA received
> quickly. However, for most WSN applications that haven't such kind of
> requirement, 10 - 20 minutes wait time may acceptable.
>
> 3. Router
>
> Route would no longer use a relatively fixed interval to send Unsolicited
> RA. As soon as one interface of Router is confiured as an Advertising
> Interface, the interval of sending RA would be calculated by RDA. The
> constants and variables maintained as follow:
>
>     BASE_RA_INTERVAL: the basal interval of sending RA, recommended value is
> 10min.
>     MAX_RA_FACTOR: the maxium RA factor, recommended value is 5-6.
>     a: RA factor.
>     interval: current RA interval.
>     timeToAdv: the time to sending next RA.
>     sendTimes: the times of sending RA using the same interval.
>     recvRSTimes: the times of receiveing RS packet between two unsolicited
> RA.
>
>
> The algorithm comes below, the basic idea is increasing the advertising
> interval to long when topology is stable and decreasing to short when the
> network become wavy:
>
> (1). When advertising interface initializes, let a = 0$B!$(Binterval =
> BASE_RA_INTERVAL*2^a$B!$(BsendTimes = a+1$B!$(BrecvRSTimes = 0$B!$(BtimeToAdv = interval.
>
> (2).
> - (a) When interval time elapsed (that means timeToAdv is decreased to 0),
> send a Multicast Unsolicited RA and let recvRSTimes = 0;
> - (b) If sendTimes > 0 and a < MAX_RA_FACTORIAL, substracte sendTimes by 1;
> if sendTimes is decreased to 0, let a = a+1 and recalculate sendTimes with
> the formula in (1);
> - (c) Recalculate interval with the formula in (1), let timeToAdv =
> interval, wati for sending next RA.
>
> (3).
> - (a) If Router received a valid RS, let a = a/2, recvRSTimes =
> recvRSTimes+1, sendTimes = a+1;
> - (b) Recalculate current timeToAdv: if a is even before receiving RS, let
> timeToAdv = timeToAdv/2^a [see annotation 1]; if it is odd, let timeToAdv =
> timeToAdv/2^(a+1) [see annotation 2];
> - (c) if recvRSTimes < 3, send Unicast Solicited RA with the way defined in
> RFC2461; if recvRSTimes = 3, let timeToAdv = 0, send a Multicast Solicited
> RA immediately and carry out all relative operation in (2); if recvRSTimes >
> 3, nothing else need to do (it is possible Router receive a new RS before
> the scheduled RA sending out, so just let Hosts wait for the scheduled
> Multicast RA).
>
> [Annotation 1]
> timeToAdv = timeToAdv * (newInterval / oldInterval)
>                 = timeToAdv * (BASE_RA_INTERVAL*2^a /
> BASE_RA_INTERVAL*2^(2a) )
>                 = timeToAdv * 2^(-a)
>                 = timeToAdv / 2^a
> [Annotation 2]
> timeToAdv = timeToAdv * (newInterval / oldInterval)
>                 = timeToAdv * (BASE_RA_INTERVAL*2^a /
> BASE_RA_INTERVAL*2^(2a+1) )
>                 = timeToAdv * 2^(-(a+1))
>                 = timeToAdv / 2^(a+1)
>
>
> When advertising interface use RDA, Host will not send RS but wait for
> possible RA when it startup. If it get nothing within TIME_WAIT_FOR_RA, a RS
> would be sent out to solicit RA. This process could reduce the broadcast
> flow of RS when Hosts bootstrap. Meanwhile, Router would send multicast RA
> with a small interval at the begining and increase the sending interval
> gradually. That could satisfy the requirement for RA from Host when 802.15.4
> nodes constructing network. For TIME_WAIT_FOR_RA is a random value between
> BASE_RA_INTERVAL and 2*BASE_RA_INTERVAL, it is highly possible that most of
> the Hosts needn't to send RS when nodes in the same PAN start to construct
> network topology. After the topology has been stable (most of nodes have
> joined into the PAN), interval of RA will increase to a large value which
> alleviate the energy wastage by broadcasting RA message frequently.
>
> When the network become unstable (eg. some nodes lose synchronization with
> beacon, they would start orphan scan and try to re-join the network. At this
> time, node might need to request a new RA message for address
> autoconfiguration) or new node try to join PAN, Host would send RS to
> Router. Router answer the solicitation with Unicast RA and reduce RA
> interval exponentially to response the change of network rapidly. If the PAN
> is suffering a serious undulation (eg. a parent node with several children
> or grandchildren failed, all of children need to re-join the network. The
> result of this scenario is lots of RS messages appearing on the channel),
> Router response this situation by sending a Multicast RA immediately as soon
> as more than 3 RS received between two adjacent unsolicited RA. Now, RA
> factor and RA interval have decreased to small value, Router begin to send
> RA frequently and enters a fast advertising period to accommodate the change
> of network.
>
> When network topology comes stable after gone through the wavy period, RA
> interval would increase again with the RA factor. At last, it reachs a large
> enough value and enters the slow advertising period.
>
> Below table show the change of RA interval (BASE_RA_INTERVAL = 10
> min$B!$(BMAX_RA_FACTOR = 6). RA interval will increase to 10.3h if the network
> topology stays stable (it is also the character of WSN: topology wouldn't
> take frequent change after the initial network organization). Such a long
> interval only take little negative effect to the power consumption.
> =====================================================
> a    interval   sendTimes   Time to achieve the intvl
> 0    10m          1                 0
> 1    20m          2                 10m
> 2    40m          3                 50m
> 3    80m          4                 2.8h
> 4    160m         5                 8.2h
> 5    320m         6                 21.5h
> 6    640m         7                 53.5h
> =====================================================
>
>
> Regards,
>
> Mario Mao
> MarioMao@Gmail.com
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
>

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Sun Nov 05 18:26:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GgrNW-0005Li-Of; Sun, 05 Nov 2006 18:26:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GgrNV-0005LR-4Z
	for 6lowpan@lists.ietf.org; Sun, 05 Nov 2006 18:26:13 -0500
Received: from nf-out-0910.google.com ([64.233.182.187])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgrNR-0001Jy-L4
	for 6lowpan@lists.ietf.org; Sun, 05 Nov 2006 18:26:13 -0500
Received: by nf-out-0910.google.com with SMTP id c2so523878nfe
	for <6lowpan@lists.ietf.org>; Sun, 05 Nov 2006 15:26:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=ogblVclwVapip5hyu3fL5cbw4x77mkcKHrnFLgwA0qLDdEZRV2TRRduqP4SD714Rb20FsCfe/xQTAbdtGRWtgunMLmVIBcdjP9mnuuetbCvPFzvzeZmuZ4H3C4fh2upY9Dt0qWOya0+tRAYp+4z8mQPRu3qBZSm+bpd6HlghvY4=
Received: by 10.82.129.5 with SMTP id b5mr1173333bud.1162769167956;
	Sun, 05 Nov 2006 15:26:07 -0800 (PST)
Received: by 10.82.182.18 with HTTP; Sun, 5 Nov 2006 15:26:07 -0800 (PST)
Message-ID: <43b91d370611051526k167d3735s3e98f609ef34ae65@mail.gmail.com>
Date: Sun, 5 Nov 2006 15:26:07 -0800
From: "Samita Chakrabarti" <samitac2@gmail.com>
To: "Carsten Bormann" <cabo@tzi.org>
Subject: Re: [6lowpan] 6lowpan Architecture Questions
In-Reply-To: <FEA60A59-652E-42DA-B482-48AF7B6D1960@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <002801c6f9d1$33c16030$6501a8c0@RonStrich>
	<FEA60A59-652E-42DA-B482-48AF7B6D1960@tzi.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Cc: 6lowpan <6lowpan@lists.ietf.org>
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Errors-To: 6lowpan-bounces@ietf.org

Hi Carsten, Ron and all:

Agree, it is a good point that we did not clearly discuss the topology for
6lowpan architecture. During 6lowpan-nd discussion, we discussed and
agreed on different supporting topologies for 6lowpan ( both at interim 05
and at Dallas IETF meeting). Section 4 of 6lowpan-nd draft captures that
text (see below). If we decide to have a separate architecture document,
then we can use these portion of the text.


---------------------------------------------------------------------------=
------------------
4.  Assumptions about Topology and Address Mapping

   In order to minimize the multicast packets we need to make some
   assumptions that tie together the L2 functional elements and the L3
   functional elements.  We also state our understanding of how IPv6
   would map to a LowPan network:
   o  One PAN-ID defines one LowPan Network.
   o  Each LowPan corresponds to one IPv6 subnet as PAN-ID may be used
      to determine a subnet.
   o  There is one PAN co-ordinator or PAN group leader per one LowPan.
   o  The IPv6 router which sits in the boundary of the LowPan is a PAN
      co-ordinator.
   o  There can be multiple co-ordinators in the LowPan.
   o  When a device connects to the LowPan at layer 2, it finds out a
      (unicast) layer 2 address for its co-ordinator.
   o  By recursive construction, the previous item implies that a co-
      ordinator knows its co-ordinator from when it connected to the
      LowPan, hence there is distributed knowledge of unicast addresses
      that lead all the way to the PAN co-ordinator.
   o  The IPv6 router assigns addresses through prefix advertisement.
   o  The other FFDs in the network do not act as a IPv6 router, but
      they generally route data packet in the L2 layer (Mesh layer
      routing).
   o  Star topology assumes that each node is one hop away from the PAN
      co-ordinator.
   o  This document defines a mesh topology (see diagram below).  In
      mesh topology, each node is capable of forwarding.  Thus it can be
      assumed as a network of full functional devices (FFDs) with one
      PAN co-ordinator and multiple co-ordinators.





Chakrabarti & Nordmark  Expires December 26, 2006               [Page 6]
=0C
Internet-Draft    LowPan Neighbor Discovery Extensions         June 2006


   o  FFDs may or may not be more than one hop away from the PAN co-
      ordinator.
   o  We assume that the 64-bit EUI-64 addresses are used as link-layer
      address in the lowpan, since these addresses never change for a
      given node.  Appendix A discusses some additional considerations
      should we apply this to the 16-bit addresses.

   This document currently supports the following topologies:


            1)  Star  Topology

                 PAN-C
                    O
                 /  |   \
                o   o    o  <------- RFDs or FFDs

           2) Mesh Topology

            Example-1                               Example-2

                   O    PAN-C                     O <--  PAN-C
              /    |      \      o             /  |    \
             /     |       \   /              /   |     \
            FFD----FFD----- FFD              FFD--FFD-----FFD
             \     |\       /  \              \    | \    /|
              \    | \     /|   o              \   |  \  / |
               \   |  \   / |                   \  |   \/  |
                \  |   \ /  |                    \ |   /\  |
                 \ |    \   |                     \|  /  \ |
                  \|   / \  |                      |/     \|
                   FFD    \ |                      FFD    FFD
                /  | \     FFD
               o   0  o    / \
                           o  o  <--RFDs

   Each FFD may act as simple co-ordinators but there is only one PAN
   co-ordinator in the mesh LowPan topology.

------------------------------------

Thanks,
-Samita


On 10/27/06, Carsten Bormann <cabo@tzi.org> wrote:
> Ron,
>
> good input.
>
> Let me just pick up on one of these points:
>
> The IETF is quite wary about "architecture" documents.
>
> (The OSI reference model is the textbook example here:
> ISO did an architecture ["reference model"], and then, only when
> defining the protocols, found out that the architecture didn't make
> sense.
> But it was too late to fix the architecture, so the bad layers limped
> on until OSI finally died.
> The really funny thing, of course, is that, in 2006, people are
> *still* citing the layers of the defunct reference model...)
>
> In the IETF, we tend to standardize functional components and leave
> it to the market how to build "architectures" out of these.
> Of course, that is not always possible.
> Also, it may be necessary to have an (really: one or more)
> architectures in mind when building components.
>
> So, I'd welcome discussion of architecture(s).  I'm just not sure we
> actually want to "standardize" them.
>
> Gruesse, Carsten
>
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan
>

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Mon Nov 06 01:36:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ggy5b-0000ol-Hu; Mon, 06 Nov 2006 01:36:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggy5Z-0000nk-EC
	for 6lowpan@lists.ietf.org; Mon, 06 Nov 2006 01:36:09 -0500
Received: from mxmss0.kpost.com ([211.117.63.118])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggy08-0003JU-FI
	for 6lowpan@lists.ietf.org; Mon, 06 Nov 2006 01:30:38 -0500
Received: from richfafa ([124.63.25.40]) by mxmss0.kpost.com with ESMTP
	id <20061106063017.EJB25243.mxmss0@richfafa>;
	Mon, 6 Nov 2006 15:30:17 +0900
From: "Lee Jung-Hwan" <john@ibitworld.com>
To: "'Geoff Mulligan'" <geoff@mulligan.com>
Subject: RE: [6lowpan] Proposal for alternative 6lowpan header encoding
Date: Mon, 6 Nov 2006 15:30:16 +0900
Message-ID: <01e301c7016d$06c67180$4101a8c0@richfafa>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: Acb/ovgrgi5tdgMOQKKEOPtGGmH+jQBx8OJw
In-Reply-To: <1162597742.5112.28.camel@localhost>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: '6lowpan' <6lowpan@lists.ietf.org>
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Errors-To: 6lowpan-bounces@ietf.org

 
Folks,

I am Jung-Hwan Lee working for iBIT technologies, Inc in south of korea and
in charge of USN R & D.
our company has being implemented and tested usn modules and gateway with
6lowpan functionality & IPv6 protocol stack.
but, in progress usn modules and gateway, we have several problems. for
examples,
- byte alignment
- 6lowpan <-> IPv6 header translation
- and so on

The ppt files that written by David and Jonathan is so simple and impressive
from the viewpoint of implementor.

Thanks for your paper.


-----Original Message-----
From: Geoff Mulligan [mailto:geoff@mulligan.com] 
Sent: Saturday, November 04, 2006 8:49 AM
To: 6lowpan
Subject: [6lowpan] Proposal for alternative 6lowpan header encoding

Folks,
  Arch Rock have submitted a proposal for a different 6lowpan header
encoding.  David and Jonathan put together a set a slides to describe their
idea to simplify the 6lowpan adaptation header.  They are working on a
complete proposal.

I have posted the slides to the wiki at:

http://6lowpan.tzi.org/FrontPage?action=AttachFile&do=get&target=6lowpan-hea
der-proposal.ppt

You can also get a copy (if you are wiki challenged) at:
http://www.mulligan.com/6lowpan/6lowpan-header-proposal.ppt

Their design seems to follow the ideas of IPv6, reduce the header size in
almost all cases, allow for extensions, byte align the fields and as I've
thought about coding it, it looks like less complex parsing.

While a proposal such as this (ideas tend to come on their own schedule) at
this late stage in our process will be disruptive, the potential value of
simplifying and fixing some of the identified problems in the current design
is, in my opinion, worth the time and effort and risk to our already blown
schedule to evaluate and discuss within the group.
 
Please take a look at the slides.  We only a have few days before the
meeting on Wednesday and if possible I would like to hear peoples thoughts.
I have asked Jonathan and David to attend the WG meeting and to prepare a
more in-depth presentation related to this new design.

        geoff



_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Mon Nov 06 03:34:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ggzvq-0007Nl-Kz; Mon, 06 Nov 2006 03:34:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggzvp-0007N4-7O
	for 6lowpan@ietf.org; Mon, 06 Nov 2006 03:34:13 -0500
Received: from nz-out-0102.google.com ([64.233.162.207])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggzvn-0004wx-3T
	for 6lowpan@ietf.org; Mon, 06 Nov 2006 03:34:13 -0500
Received: by nz-out-0102.google.com with SMTP id 13so845667nzn
	for <6lowpan@ietf.org>; Mon, 06 Nov 2006 00:34:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:to:cc:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole:from;
	b=gxEmzWIGIXLkzZ3IkFUtEpwrqCz07OjKpdQGDoLyw5kjuWEnkiS2ECiJsKiDAqGs+Gh+V4C5xrM6Mn+tI4verYisci5TtzFsn5e5hwDo0RLROUTCv9AQ3vLmlbuoZrgoa2xCt7ROx8B6Zgi+/J2f2iOEebR1cqxFbODNLTao3SI=
Received: by 10.65.84.6 with SMTP id m6mr7413600qbl.1162802050305;
	Mon, 06 Nov 2006 00:34:10 -0800 (PST)
Received: from Maoer ( [211.144.102.60])
	by mx.google.com with ESMTP id 18sm17169862nzo.2006.11.06.00.34.04;
	Mon, 06 Nov 2006 00:34:10 -0800 (PST)
Message-ID: <006101c7017e$86299e50$7fc0a8c0@netlab.cs.ecnu.edu.cn>
To: "Samita Chakrabarti" <samitac2@gmail.com>
References: <015501c6fbef$5582aa60$7fc0a8c0@netlab.cs.ecnu.edu.cn>
	<43b91d370611051509u3dd8d25bi30f51d2b5a522fbf@mail.gmail.com>
Subject: Re: [6LoWPAN] Router Dynamic Advertisement Algorithm (RDA)
Date: Mon, 6 Nov 2006 16:35:19 +0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
From: Mario Mao <mariomao@gmail.com>
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235
Cc: 6lowpan@ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1709829127=="
Errors-To: 6lowpan-bounces@ietf.org

--===============1709829127==
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

SGkgQ2hha3JhYmFydGksDQoNClRoYW5rcyBmb3IgeW91IGZlZWRiYWNrLg0KDQo+IERpZCB5b3Ug
YWxzbyBoYXZlIGFuIGltcGxlbWVudGF0aW9uIG9mIG91ciA2bG93cGFuLWlwdjYtbmQgZHJhZnQg
Pw0KDQpXZSBkb24ndCBpbXBsZW1lbnQgNmxvd3Bhbi1pcHY2LW5kIGRyYWZ0LiBBY3R1YWxseSwg
d2UgZGlkIGNvbnNpZGVyIHRoZSA2bG93cGFuLWlwdjYtbmQgbWV0aG9kIGNhcmVmdWxseSB3aGVu
IGRlc2lnbmluZy4gSG93ZXZlciwgYWZ0ZXIgZXZhbHVhdGlvbiwgd2UgY29uc2lkZXJlZCB0aGVy
ZSBhcmUgc29tZSBwcm9ibGVtIHRvIGltcGxlbWVudCBpdC4gRm9yIGV4YW1wbGUsDQoNCkNvZGUg
c3BhY2UgbGltaXRhdGlvbjogdGhlIE1DVSB3ZSB1c2UgaGF2ZSBhcm91bmQgMjdrIGZyZWUgZm9y
IEFkYXB0YXRpb24gTGF5ZXIsIElQdjYvTkQsIFRDUC9VRFAgYW5kIGFwcGxpY2F0aW9uLiBGdWxs
IGltcGxlbWVudGF0aW9uIG9mIDZsb3dwYW4taXB2Ni1uZCAoZXNwZWNpYWwgYWRkcmVzcyByZXNv
bHV0aW9uKSB3aWxsIG5lZWQgYSBsb3Qgb2YgY29kZSBzcGFjZSwgbm9ybWFsIHNlbnNvciBub2Rl
IGNvdWxkbid0IGFmZm9yZCBpdC4gDQoNCkFub3RoZXIsIHRoZXJlIHN0aWxsIG5lZWRzIHNvbWUg
b3RoZXIgbWVjaGFuaXNtIGJleW9uZCBkcmFmdCdzIGRlZmluaXRpb24sIGFzIGFuIGluc3RhbmNl
LCBzZWUgc2VjdGlvbiA1LjEsIA0KDQoiSW4gYSBtZXNoIHRvcG9sb2d5LCB3aGVuIHN1Y2ggYSBw
YWNrZXQgaXMgcmVjZWl2ZWQgYnkgYSBjby1vcmRpbmF0b3IsIGl0IHdpbGwgbG9vayBhdCB0aGUg
SVB2NiBoZWFkZXIgYW5kIGlmIHRoYXQgaXMgZGVzdGluZWQgdG8gdGhlIGFsbC1yb3V0ZXJzIElQ
djYgbXVsdGljYXN0IGFkZHJlc3MsIHRoZW4gaXQgd2lsbCByZWxheSB0aGF0ICBwYWNrZXQgKHdp
dGhvdXQgZGVjcmVtZW50aW5nIHRoZSBJUHY2IGhvcCBsaW1pdCkgdG8gaXRzIGNvLW9yZGluYXRv
ci4gVGhpcyB3aWxsIGRlbGl2ZXIgdGhlIFJTIHRvd2FyZHMgdGhlIFBBTiBjby1vcmRpbmF0b3Iu
Ig0KDQpXaGVuIG1lc2ggZGVsaXZlcnksIG1lZGktbm9kZSBuZWVkIHRvIGNoZWNrIHRoZSBJUHY2
IGhlYWRlciB0byBkZWNpZGUgaG93IHRvIGZvcndhcmQgZnJhbWVzLiBUaGVyZSBtdXN0IGJlIG1v
cmUgY29kZSB0byBpbXBsZW1lbnQgc3VjaCBhIGFkYXB0YXRpb24tbGF5ZXIgcm91dGUgYWxnb3Jp
dGhtIGFuZCBtYWtlIGFkYXB0YXRpb24tbGF5ZXIgdG9vIGNvbXBsZXguIE1vcmVvdmVyLCBob3cg
YWJvdXQgdGhlIElQdjYgaGVhZGVyIGNvbXByZXNzaW9uLCBzaG91bGQgZXZlcnkgbWVkaS1ub2Rl
IGRvIHRoZSBoZWFkZXIgZGVjb21wcmVzc2lvbiBiZWZvcmUgZGVjaWRpbmcgaG93IHRvIGZvcndh
cmQgYSBmcmFtZT8NCg0KQXQgbGFzdCwgdGhlcmUgYXJlIHNvbWUgYXNzdW1wdGlvbnMgbGlrZSAi
UEFOIGNvLW9yZGluYXRvciBpcyBhbHNvIHRoZSBJUHY2IHJvdXRlciIsIGluIHRoZSBtYWlsIGJl
Zm9yZSwgSSBkZXNjcmliZSB0aGUgcmVhc29uIHdoeSB3ZSBjYW4ndCBhY2NlcHQgaXQgKG11bHRp
cGxlIHNpbmsgc2NlbmFyaW8pLiBTbywgd2UgaGF2ZSB0byBnaXZlIHVwIDZsb3dwYW4taXB2Ni1u
ZCBhbmQgdHJ5IHRvIGZpbmQgYW5vdGhlciB3YXkuDQoNCj4gQXJlIHlvdSBzYXlpbmcgdGhhdCB5
b3UgaW1wbGVtZW50ZWQgUkRBIGFsZ29yaXRobSBpbnN0ZWFkID8gIEhvdyBkaWQNCj4geW91IHVz
ZSBtdWx0aWNhc3QgYW5kIGNvbnRyb2xsZWQgZmxvb2RpbmcgYXQgdGhlIGxpbmstbGF5ZXIoODAy
LjE1LjQpDQo+ID8gSGF2ZSB5b3UNCj4gdXNlZCBhIHNpbXVsYXRpb24gb3Igc2V0IG9mIHJlYWwg
c2Vuc29ycyB0byBpbXBsZW1lbnQgYW5kIHRha2UgbWVhc3VyZW1lbnRzPw0KDQpZZXMsIHJlYWwg
c2Vuc29ycyB3b3JrIGluIG91ciBlbnZpcm9ubWVudC4gVGhlIG11bHRpY2FzdCBhbmQgY29udHJv
bGxlZCBmbG9vZGluZyBoYXZlIGJlZW4gZ2l2ZW4gb3V0IHNvbWUgZGF5cyBiZWZvcmUsIHRoYXQn
cyBhbHNvIHRoZSByZWFzb24gd2h5IHdlIGhhdmUgdGhlICJCIiBiaXQgYXJndW1lbnQgcmVjZW50
bHkuIFBsZWFzZSBzZWUgaXQgYmVsb3csIEkgY3V0IGl0IGZyb20gdGhlIHByZXZpb3VzIG1haWwg
KHRoZXJlIGFyZSBzb21lIGNoYW5nZSwgYnV0IG1haW4gaWRlYSBpcyBzdGFibGUpLiANCg0KUm91
dGVyID0gY28tb3JkaW5hdG9yDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT0NClRoZSBmbG9v
ZGluZyB3YXkgaXMgc2ltcGxlOiBhbGwgSVAgcGFja2V0IHdpdGggbXVsdGljYXN0IGRlc3RpbmF0
aW9uIGFkZHJlc3Mgd2lsbA0KIGJlIGVuY2Fwc3VsZWQgaW4gYW4gYWRhcHRhdGlvbiBCcm9hZGNh
c3QgRnJhbWUuIEhvd2V2ZXIsIHRoZSBmb3JtYXQgb2YgDQphZGFwdGF0aW9uIEJyb2FkY2FzdCBG
cmFtZSBpcyBzb21ld2hhdCBkaWZmZXJlbnQgZnJvbSB0aGUgc3RhbmRhcmQgaGVhZGVyIA0KZm9y
bWF0LiBUaGUgbW9kaWZpZWQgZm9ybWF0IHNob3dlZCBiZWxvdy4NCg0KICAgICAgICAgICAgICAg
IDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogIDAgMSAyIDMgNCA1
IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rDQogfCBMRnwgIHByb3RfdHlwZSAgICB8TXxCfCByc3YgICB8UGF5bG9hZCAob3IgTUQv
QnJvYWRjYXN0IEhkcikuLi4NCiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQpBcyB0aGUgZmlndXJlIHNob3dlZCwgYSAi
QiIgYml0IGlzIGFkZGVkKHJlcGxhY2luZyBvbmUgcnN2IGJpdCkuIFdoZW4gdGhlICJCIiANCmJp
dCBpcyBzZXQsIGEgQnJvYWRjYXN0IEZpZWxkIHdpbGwgYmUgaW5jbHVkZWQgaW4gdGhlIGZyYW1l
IGltbWVkaWF0ZWx5IGZvbGxvd2luZw0KIHRoZSBMb1dQQU4gaGVhZGVyLiBJZiB0aGVyZSBpcyBh
IEJyb2FkY2FzdCBGaWVsZCwgd2Ugd2lsbCBjYWxsIHRoZSANCmFkYXB0YXRpb24gZnJhbWUgYXMg
YSBCcm9hZGNhc3QgRnJhbWUuIFRoZSAiQnJvYWRjYXN0IiBmaWVsZCBpcyBkZWZpbmVkIGFzIA0K
Zm9sbG93cw0KDQogICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg
ICAgICAgICAgIDMNCiAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg
MSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogIHxTfEJyb2FkIFJhZGl1cyB8U2Vx
dWVuY2UgTnVtYmVyfFNvdXJjZSBBZGRyZXNzLCBmb2xsb3dlZCBieS4uLg0KICArLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K
DQpTOiAwIGlmIHVzZSBFVUktNjQgYWRkcmVzcywgb3IgMSBpZiB1c2UgMTYtYml0IGFkZHJlc3Mu
DQpCcm9hZCBSYWRpdXM6IEJyb2FkY2FzdCBSYWRpdXMsIDcgYml0cywgc2hvdWxkIGJlIGRlY3Jl
bWVudCBieSBlYWNoIA0KYnJvYWRjYXN0IHJlbGF5IG5vZGUsIGlmIGl0IGlzIGRlY3JlbWVudGVk
IHRvIDAsIGRpc2NhcmQgdGhlIGZyYW1lLg0KU2VxdWVuY2UgTnVtYmVyOiBBIDgtYml0IG51bWJl
ciB0byBpZGVudGlmeSBkaWZmZXJlbnQgQnJvYWRjYXN0IEZyYW1lIGZyb20NCnRoZSBzYW1lIHNv
dXJjZSBub2RlLiBUaGUgb3JpZ2luYXRvciB3aWxsIGluY3JlbWVudCB0aGUgZmllbGQgYWZ0ZXIg
ZWFjaCANCnNlbmRpbmcuDQpTb3VyY2UgQWRkcmVzczogVGhlIE9yaWdpbmF0b3IncyBNQUMgYWRk
cmVzcy4NCg0KV2l0aCB0aGUgc3VwcG9ydCBvZiB0aGUgIkJyb2FkY2FzdCIgZmllbGQsIGFuIG9y
aWdpbmF0b3Igb3IgYSByZWxheSBub2RlIHdpbGwgDQpzZW5kIHRoZSBCcm9hZGNhc3QgRnJhbWUg
bGlrZSB0aGF0OiBmaXJzdCwgZGVsaXZlciB0aGUgZnJhbWUgdG8gYWxsIFBhbiBDb29yZGluYXRv
ciANCmFuZCBSb3V0ZXJzIGFyb3VuZCB1c2luZyBNQUMgYnJvYWRjYXN0KHdpdGggdGhlIE1BQyBk
ZXN0aW5hdGlvbiBhZGRyZXNzDQogc2V0IHRvIDB4RkZGRiwganVzdCBuZWVkIGJyb2FkY2FzdCBv
bmNlKSwgdGhlbiwgaWYgdGhlcmUgYXJlIEVuZCBEZXZpY2VzIGluIA0KdGhlIG5vZGUncyBuZWln
aGJvciB0YWJsZSwgdW5pY2FzdCB0aGUgZnJhbWUgdG8gdGhlbSBvbmUgYnkgb25lLiBCZXNpZGVz
LCB0byANCmF2b2lkIGJyb2FkY2FzdCBzdG9ybSwgYSBCcm9hZGNhc3QgUmVjb3JkIFRhYmxlIHdp
bGwgYmUgbmVlZGVkLiBUaGUgdGFibGUgd2lsbCANCnJlY29yZCB0aGUgU291cmNlIEFkZHJlc3Mg
YW5kIFNlcXVlbmNlIE51bWJlciBpbiAiQnJvYWRjYXN0IiBmaWVsZCBvZiBlYWNoIA0KcmVjZWl2
ZWQgQnJvYWRjYXN0IEZyYW1lIGFmdGVyIHJlLWJyb2FkY2FzdGluZyBpdCBmaXJzdChFbmQgRGV2
aWNlIGRvbid0IG5lZWQNCiB0byByZS1icm9hZGNhc3RpbmcpLiBTZXF1ZW50aWFsbHksIGEgQnJv
YWRjYXN0IFZhbGlkIFRpbWUgd2lsbCBiZSBpbml0aWFsaXplZCBmb3IgDQp0aGUgbmV3bHkgYWRk
ZWQgQnJvYWRjYXN0IFJlY29yZCBFbnRyeS4gVGhlbiwgYmVmb3JlIHRoZSBlbnRyeSBpcyB0aW1l
ZCBvdXQgDQooQnJvYWRjYXN0IFZhbGlkIFRpbWUgaXMgZGVjcmVtZW50ZWQgdG8gMCksIGFsbCBC
cm9hZGNhc3QgRnJhbWUgd2l0aCB0aGUgc2FtZSANClNvdXJjZSBBZGRyZXNzIGFuZCBTZXF1ZW5j
ZSBOdW1iZXIgc2hvdWxkIGJlIGRpc2NhcmRlZCBidXQgbm90IHJlbGF5ZWQuDQoNCj09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkJlc3QgUmVnYXJkcywNCg0KTWFyaW8gTWFvDQpN
YXJpb01hb0BHbWFpbC5jb20NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJv
bTogIlNhbWl0YSBDaGFrcmFiYXJ0aSIgPHNhbWl0YWMyQGdtYWlsLmNvbT4NClRvOiAiTWFyaW8g
TWFvIiA8bWFyaW9tYW9AZ21haWwuY29tPg0KQ2M6IDw2bG93cGFuQGlldGYub3JnPg0KU2VudDog
TW9uZGF5LCBOb3ZlbWJlciAwNiwgMjAwNiA3OjA5IEFNDQpTdWJqZWN0OiBSZTogWzZMb1dQQU5d
IFJvdXRlciBEeW5hbWljIEFkdmVydGlzZW1lbnQgQWxnb3JpdGhtIChSREEpDQoNCg0KPiBIaSBN
YXJpbywNCj4gDQo+IA0KPiBQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGJlbG93Lg0KPiANCj4gPiBC
eSBjb25maXJtaW5nIHdpdGggR2FicmllbCwgSSB3b3VsZCB1cGRhdGUgc29tZSByZXN1bHRzIG9m
IG91ciB0ZWFtJ3Mgd29yaw0KPiA+IG9uIDZMb1dQQU4sIHBsZWFzZSB0YWtlIGl0IGFzIGEgcmVm
ZXJlbmNlIGFuZCBnaXZlIGFueSBjb21tZW50IG5lZWRlZCwNCj4gPiB0aGFua3MuDQo+ID4NCj4g
DQo+IERpZCB5b3UgYWxzbyBoYXZlIGFuIGltcGxlbWVudGF0aW9uIG9mIG91ciA2bG93cGFuLWlw
djYtbmQgZHJhZnQgPw0KPiANCj4gPiBCYXNpY2FsbHksIG91ciB0ZWFtJ3Mgd29yayBmb2xsb3dz
IGRyYWZ0cyBwcm9tcHRlZCBieSBXRy4gaG93ZXZlciwgd2UgZmluZA0KPiA+IHNvbWV0aGluZyBz
aG91bGQgYmUgaW5jbHVkZWQgd2hlbiBpbXBsZW1lbnRpbmcuIEJlbG93IGlzIG9uZSBvZiB0aGUg
dGhpbmdzDQo+ID4gYmV5b25kIGRyYWZ0OiBSb3V0ZXIgRHluYW1pYyBBZHZlcnRpc2VtZW50IEFs
Z29yaXRobSAoUkRBKS4NCj4gPg0KPiA+IEZvciBDaGFrcmFiYXJ0aSwgSSBrbm93IGl0IGlzIGEg
cmVhbGx5IGRpZmZlcmVudCB3YXkgZnJvbSB0aGUgb3B0aW1pemF0aW9uDQo+ID4gaW4gZHJhZnQg
Nmxvd3Bhbi1pcHY2LW5kLiBCdXQgd2hlbiB3ZSBkZXNpZ24gYW5kIGltcGxlbWVudCB0aGUgNkxv
V1BBTg0KPiA+IHN0YWNrLCB3ZSBkaWQgZmluZCBpdCBpcyBlZmZlY3RpdmUgYW5kIGVhc2llciB0
byBpbXBsZW1lbnQuIEhvcGUgdGhlIGlkZWEgaW4NCj4gPiB0aGlzIG1haWwgY291bGQgZG8gc29t
ZSBoZWxwLCB0aGFua3MuDQo+ID4NCj4gDQo+IEFyZSB5b3Ugc2F5aW5nIHRoYXQgeW91IGltcGxl
bWVudGVkIFJEQSBhbGdvcml0aG0gaW5zdGVhZCA/ICBIb3cgZGlkDQo+IHlvdSB1c2UgbXVsdGlj
YXN0IGFuZCBjb250cm9sbGVkIGZsb29kaW5nIGF0IHRoZSBsaW5rLWxheWVyKDgwMi4xNS40KQ0K
PiA/IEhhdmUgeW91DQo+IHVzZWQgYSBzaW11bGF0aW9uIG9yIHNldCBvZiByZWFsIHNlbnNvcnMg
dG8gaW1wbGVtZW50IGFuZCB0YWtlIG1lYXN1cmVtZW50cz8NCj4gDQo+IFRoZSBtYWluIGlkZWEg
b2YgIG91ciA2bG93cGFuLW5kIGRyYWZ0IGlzIHRvIG1pbmltaXplIHRoZSBicm9hZGNhc3Qgb3Ig
YWxsLW5vZGUNCj4gbXVsdGljYXN0IG1lc3NhZ2VzIHRvIHRoZSBsb3ctcG93ZXJlZCBub2RlcyBp
biBvcmRlciB0byBzYXZlIGVuZXJneSB3aGlsZQ0KPiBtYWludGFpbmluZyB0aGUgZWZmaWNpZW5j
eSBvZiB0aGUgaW5pdGlhdGluZyBub2RlLiBUaHVzIHdlIG9wdGltaXplIGZvciB1bmljYXN0DQo+
IG1lc3NhZ2luZyBhbmQgc29tZXRpbWVzIHVzZSB0aGUgZXhpc3RpbmcgYWxnb3JpdGhtIGluIElQ
djYgTkQgLSBzbyBpdCBzaG91bGQNCj4gYmUgc2ltcGxlIHRvIGltcGxlbWVudC4gVGhlIGlkZWEg
Y291bGQgYmUgYXBwbGljYWJsZSBiZXlvbmQgNmxvd3BhbiBzY2VuYXJpb3MsDQo+IGkuZSB0byBh
bnkgbmV0d29yayB0aGF0IHdhbnRzIHRvIHJ1biBlbmVyZ3ktZWZmaWNpZW50IElQdjYgTkQgcHJv
dG9jb2wuDQo+IA0KPiBUaGFua3MsDQo+IC1TYW1pdGENCj4gDQo+IA0KPiANCj4gDQo+ID4gPT09
PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4NCj4gPiBSb3V0ZXIgRGlzY292ZXJ5LCBQcmVm
aXggYW5kIFBhcmFtZXRlciBEaXNjb3ZlcnkgbmVlZCBSUyBhbmQgUkEgbWVzc2FnZQ0KPiA+IGRl
ZmluZWQgaW4gTkRQLiBJbiBMb1dQQU4gZW52aXJvbm1lbnQsIHdlIG5lZWQgYXZvaWQgdGhlIHBv
d2VyIGNvbnN1bWluZw0KPiA+IGNhdXNlZCBieSBicm9hZGNhc3RpbmcgdGhlc2Uga2luZHMgb2Yg
bWVzc2FnZSBwZXJpb2RpY2FsbHkuIE9uIHRoZSBvdGhlcg0KPiA+IGhhbmQsIGl0IGlzIG5vdCBh
IGdvb2QgaWRlYSB0byBzaW1wbHkgaW5jcmVhc2UgdGhlIGFubm91bmNlbWVudCBpbnRlcnZhbCB0
bw0KPiA+IGEgbGFyZ2UgdmFsdWUuIEl0IHdvdWxkIG1ha2UgdGhlIG5ldHdvcmsgaW5zZW5zaXRp
dmUgYW5kIGxlYWQgc29tZSBjaGlsZA0KPiA+IG5vZGVzIGluYWNjZXNzaWJsZSBiZWZvcmUgdGhl
eSBjb3VsZCBjb25maWd1cmUgYSBpcHY2IGdsb2JhbCBhZGRyZXNzLiBUbw0KPiA+IGJhbGFuY2Ug
dGhlbSwgSG9zdCBhbmQgUm91dGVyIHVzZSBSb3V0ZXIgRHluYW1pYyBBZHZlcnRpc2VtZW50IEFs
Z29yaXRobQ0KPiA+IChSREEpIHRvIHNlbmQgUlMgYW5kIFJBLg0KPiA+DQo+ID4gMS4gQXNzdW1w
dGlvbg0KPiA+DQo+ID4gSW4gb3VyIGVudmlyb25tZW50LCB3ZSBkb24ndCBjb25zaWRlIElQdjYg
cm91dGVycyB3b3VsZCBiZSBrbm93biBieSBhbGwNCj4gPiBzZW5zb3Igbm9kZXMgYmVmb3JlIHRo
ZXkgZ2V0IHRoZWlyIGFubm91bmNlbWVudCBleHBsaWNpdGx5LiBUaGlzDQo+ID4gY29uc2lkZXJh
dGlvbiB3b3VsZCB3b3JrIGZvciBtdWx0aXBsZSBzaW5rIHNjZW5hcmlvLiBUaGVyZSBjb3VsZCBi
ZSBtb3JlDQo+ID4gdGhhbiBvbmUgc2luayAocm91dGVyKSB0byBiYWxhbmNlIHRoZSBsb2FkIGFy
b3VuZCBzaW5rIChyb3V0ZXIpLiBTbywgSG9zdA0KPiA+IG5lZWQgdG8gc2VuZCBNdWxpdGNhc3Qg
UlMgb3Igd2FpdCBmb3IgUkEuDQo+ID4NCj4gPiBUbyBzdXBwb3J0IElQIG11bHRpY2FzdCwgYnJv
YWRjYXN0IGFiaWxpdHkgaW4gYWRhcHRhdGlvbiBsYXllciBzaG91bGQgYmUNCj4gPiBpbmNsdWRl
ZC4gV2UgaGF2ZSBpbnRyb2R1Y2VkIGEgY29udHJvbGxlZCBmbG9vZGluZyBtZWNoYW5pc20gdG8g
c3VwcGx5IHN1Y2gNCj4gPiBraW5kIG9mIHJlcXVpcm1lbnQuIFlvdSBjb3VsZCBnZXQgdGhlIG1l
YW4gaWRlYSBpbiB0aGUgbWFpbCBiZWZvcmUsIEkNCj4gPiByZW1lbWJlciBJIGhhdmUgc2VudCBp
dCB0byBtYWlsIGxpc3QgYWJvdXQgMyBtb250aHMgYWdvLg0KPiA+DQo+ID4gQXQgbGFzdCwgdGhl
cmUgd2lsbCBiZSBhIGxpdHRsZSBjaGFuZ2UgdG8gUkZDMjQ2MSBvbiB0aGUgUkEgYW5ub3VuY2Vt
ZW50DQo+ID4gaW50ZXJ2YWwsIG5vdCBtb3JlLCBidXQgZG8gaGF2ZS4gV2lsbCBpdCBiZSBhIGJp
ZyBwcm9ibGVtPyBPdXINCj4gPiBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0IGJvdGggdGhlIHR3byB3
YXkgb2YgUkEgc2VuZGluZyBhbGdvdGl0aG0gaW4gYSBzaW5nbGUNCj4gPiBSb3V0ZXIsIG9uZSBm
b3Igc3RhbmRhcmQsIG9uZSBmb3IgTG9XUEFOLiBQZW9wbGUgY291bGQgY29uZml1cmUgaW50ZXJm
YWNlIHRvDQo+ID4gdXNlIGFueSBvZiB0aGVtLCB0aGF0IG1lYW5zLCBubyBjb25mbGljdCBiZXR3
ZWVuIHR3byBkaWZmZXJlbnQgbGlua3MsIGVnLg0KPiA+IHN0YW5kYXJkIGZvciBFdGhlcm5ldCBh
bmQgUkRBIGZvciBJRUVFIDgwMi4xNS40LiBPdXIgdGVzdCBzaG93IHRoZSBSb3V0ZSBhbmQNCj4g
PiBIb3N0IHdvdWxkIHdvcmsgZmluZSB3aGVuIGVuYWJsZSB0d28gYWR2ZXJ0aXNpbmcgaW50ZXJm
YWNlcyB3aGljaCB1c2UNCj4gPiBkaWZmZXJlbnQgYWR2ZXJ0aXNpbmcgYWxnb3JpdGhtLg0KPiA+
DQo+ID4gMi4gSG9zdA0KPiA+DQo+ID4gV2hlbiBIb3N0IHN0YXJ0cyB1cCwgaXQgaG9sZCB0aGUg
aW5pdGlhbCBtdWx0aWNhc3QgUlMgdW50aWwgVElNRV9XQUlUX0ZPUl9SQQ0KPiA+IGVsYXBzZWVk
LiBJZiBIb3N0IHN0aWxsIG1pc3MgdGhlIHdhbnRlZCBSQSwgYSBtdWx0aWNhc3QgUlMgc2hvdWxk
IGJlIHNlbnQNCj4gPiBvdXQuIEZvciBUSU1FX1dBSVRfRk9SX1JBLCBpdCBpcyBhIHJhbmRvbSB2
YWx1ZSBiZXR3ZWVuIEJBU0VfUkFfSU5URVJWQUwgYW5kDQo+ID4gMipCQVNFX1JBX0lOVEVSVkFM
LiBBbm90aGVyLCB0aGUgc291cmNlIGFkZHJlc3Mgb2YgUlMgc2hvdWxkIHVzZSB1bmljYXN0DQo+
ID4gYWRkcmVzcyBidXQgbm90IDo6LCB0aGF0IG1ha2UgUm91dGVyIGNvdWxkIHVuaWNhc3QgdGhl
IFJBIG1lc3NhZ2UgYmFjayB0bw0KPiA+IEhvc3QuDQo+ID4NCj4gPiBGb3IgYXBwbGljYXRpb24g
dGhhdCB3YW50IGltbWVkaWF0ZSBhY2Nlc3MgdG8gZXZlcnkgc2Vuc29yIG5vZGUsDQo+ID4gVElN
RV9XQUlUX0ZPUl9SQSBjb3VsZCB1c2UgYW5vdGhlciBzbWFsbGVyIHZhbHVlIHdoaWNoIGxldCBS
QSByZWNlaXZlZA0KPiA+IHF1aWNrbHkuIEhvd2V2ZXIsIGZvciBtb3N0IFdTTiBhcHBsaWNhdGlv
bnMgdGhhdCBoYXZlbid0IHN1Y2gga2luZCBvZg0KPiA+IHJlcXVpcmVtZW50LCAxMCAtIDIwIG1p
bnV0ZXMgd2FpdCB0aW1lIG1heSBhY2NlcHRhYmxlLg0KPiA+DQo+ID4gMy4gUm91dGVyDQo+ID4N
Cj4gPiBSb3V0ZSB3b3VsZCBubyBsb25nZXIgdXNlIGEgcmVsYXRpdmVseSBmaXhlZCBpbnRlcnZh
bCB0byBzZW5kIFVuc29saWNpdGVkDQo+ID4gUkEuIEFzIHNvb24gYXMgb25lIGludGVyZmFjZSBv
ZiBSb3V0ZXIgaXMgY29uZml1cmVkIGFzIGFuIEFkdmVydGlzaW5nDQo+ID4gSW50ZXJmYWNlLCB0
aGUgaW50ZXJ2YWwgb2Ygc2VuZGluZyBSQSB3b3VsZCBiZSBjYWxjdWxhdGVkIGJ5IFJEQS4gVGhl
DQo+ID4gY29uc3RhbnRzIGFuZCB2YXJpYWJsZXMgbWFpbnRhaW5lZCBhcyBmb2xsb3c6DQo+ID4N
Cj4gPiAgICAgQkFTRV9SQV9JTlRFUlZBTDogdGhlIGJhc2FsIGludGVydmFsIG9mIHNlbmRpbmcg
UkEsIHJlY29tbWVuZGVkIHZhbHVlIGlzDQo+ID4gMTBtaW4uDQo+ID4gICAgIE1BWF9SQV9GQUNU
T1I6IHRoZSBtYXhpdW0gUkEgZmFjdG9yLCByZWNvbW1lbmRlZCB2YWx1ZSBpcyA1LTYuDQo+ID4g
ICAgIGE6IFJBIGZhY3Rvci4NCj4gPiAgICAgaW50ZXJ2YWw6IGN1cnJlbnQgUkEgaW50ZXJ2YWwu
DQo+ID4gICAgIHRpbWVUb0FkdjogdGhlIHRpbWUgdG8gc2VuZGluZyBuZXh0IFJBLg0KPiA+ICAg
ICBzZW5kVGltZXM6IHRoZSB0aW1lcyBvZiBzZW5kaW5nIFJBIHVzaW5nIHRoZSBzYW1lIGludGVy
dmFsLg0KPiA+ICAgICByZWN2UlNUaW1lczogdGhlIHRpbWVzIG9mIHJlY2VpdmVpbmcgUlMgcGFj
a2V0IGJldHdlZW4gdHdvIHVuc29saWNpdGVkDQo+ID4gUkEuDQo+ID4NCj4gPg0KPiA+IFRoZSBh
bGdvcml0aG0gY29tZXMgYmVsb3csIHRoZSBiYXNpYyBpZGVhIGlzIGluY3JlYXNpbmcgdGhlIGFk
dmVydGlzaW5nDQo+ID4gaW50ZXJ2YWwgdG8gbG9uZyB3aGVuIHRvcG9sb2d5IGlzIHN0YWJsZSBh
bmQgZGVjcmVhc2luZyB0byBzaG9ydCB3aGVuIHRoZQ0KPiA+IG5ldHdvcmsgYmVjb21lIHdhdnk6
DQo+ID4NCj4gPiAoMSkuIFdoZW4gYWR2ZXJ0aXNpbmcgaW50ZXJmYWNlIGluaXRpYWxpemVzLCBs
ZXQgYSA9IDAsaW50ZXJ2YWwgPQ0KPiA+IEJBU0VfUkFfSU5URVJWQUwqMl5hLHNlbmRUaW1lcyA9
IGErMSxyZWN2UlNUaW1lcyA9IDAsdGltZVRvQWR2ID0gaW50ZXJ2YWwuDQo+ID4NCj4gPiAoMiku
DQo+ID4gLSAoYSkgV2hlbiBpbnRlcnZhbCB0aW1lIGVsYXBzZWQgKHRoYXQgbWVhbnMgdGltZVRv
QWR2IGlzIGRlY3JlYXNlZCB0byAwKSwNCj4gPiBzZW5kIGEgTXVsdGljYXN0IFVuc29saWNpdGVk
IFJBIGFuZCBsZXQgcmVjdlJTVGltZXMgPSAwOw0KPiA+IC0gKGIpIElmIHNlbmRUaW1lcyA+IDAg
YW5kIGEgPCBNQVhfUkFfRkFDVE9SSUFMLCBzdWJzdHJhY3RlIHNlbmRUaW1lcyBieSAxOw0KPiA+
IGlmIHNlbmRUaW1lcyBpcyBkZWNyZWFzZWQgdG8gMCwgbGV0IGEgPSBhKzEgYW5kIHJlY2FsY3Vs
YXRlIHNlbmRUaW1lcyB3aXRoDQo+ID4gdGhlIGZvcm11bGEgaW4gKDEpOw0KPiA+IC0gKGMpIFJl
Y2FsY3VsYXRlIGludGVydmFsIHdpdGggdGhlIGZvcm11bGEgaW4gKDEpLCBsZXQgdGltZVRvQWR2
ID0NCj4gPiBpbnRlcnZhbCwgd2F0aSBmb3Igc2VuZGluZyBuZXh0IFJBLg0KPiA+DQo+ID4gKDMp
Lg0KPiA+IC0gKGEpIElmIFJvdXRlciByZWNlaXZlZCBhIHZhbGlkIFJTLCBsZXQgYSA9IGEvMiwg
cmVjdlJTVGltZXMgPQ0KPiA+IHJlY3ZSU1RpbWVzKzEsIHNlbmRUaW1lcyA9IGErMTsNCj4gPiAt
IChiKSBSZWNhbGN1bGF0ZSBjdXJyZW50IHRpbWVUb0FkdjogaWYgYSBpcyBldmVuIGJlZm9yZSBy
ZWNlaXZpbmcgUlMsIGxldA0KPiA+IHRpbWVUb0FkdiA9IHRpbWVUb0Fkdi8yXmEgW3NlZSBhbm5v
dGF0aW9uIDFdOyBpZiBpdCBpcyBvZGQsIGxldCB0aW1lVG9BZHYgPQ0KPiA+IHRpbWVUb0Fkdi8y
XihhKzEpIFtzZWUgYW5ub3RhdGlvbiAyXTsNCj4gPiAtIChjKSBpZiByZWN2UlNUaW1lcyA8IDMs
IHNlbmQgVW5pY2FzdCBTb2xpY2l0ZWQgUkEgd2l0aCB0aGUgd2F5IGRlZmluZWQgaW4NCj4gPiBS
RkMyNDYxOyBpZiByZWN2UlNUaW1lcyA9IDMsIGxldCB0aW1lVG9BZHYgPSAwLCBzZW5kIGEgTXVs
dGljYXN0IFNvbGljaXRlZA0KPiA+IFJBIGltbWVkaWF0ZWx5IGFuZCBjYXJyeSBvdXQgYWxsIHJl
bGF0aXZlIG9wZXJhdGlvbiBpbiAoMik7IGlmIHJlY3ZSU1RpbWVzID4NCj4gPiAzLCBub3RoaW5n
IGVsc2UgbmVlZCB0byBkbyAoaXQgaXMgcG9zc2libGUgUm91dGVyIHJlY2VpdmUgYSBuZXcgUlMg
YmVmb3JlDQo+ID4gdGhlIHNjaGVkdWxlZCBSQSBzZW5kaW5nIG91dCwgc28ganVzdCBsZXQgSG9z
dHMgd2FpdCBmb3IgdGhlIHNjaGVkdWxlZA0KPiA+IE11bHRpY2FzdCBSQSkuDQo+ID4NCj4gPiBb
QW5ub3RhdGlvbiAxXQ0KPiA+IHRpbWVUb0FkdiA9IHRpbWVUb0FkdiAqIChuZXdJbnRlcnZhbCAv
IG9sZEludGVydmFsKQ0KPiA+ICAgICAgICAgICAgICAgICA9IHRpbWVUb0FkdiAqIChCQVNFX1JB
X0lOVEVSVkFMKjJeYSAvDQo+ID4gQkFTRV9SQV9JTlRFUlZBTCoyXigyYSkgKQ0KPiA+ICAgICAg
ICAgICAgICAgICA9IHRpbWVUb0FkdiAqIDJeKC1hKQ0KPiA+ICAgICAgICAgICAgICAgICA9IHRp
bWVUb0FkdiAvIDJeYQ0KPiA+IFtBbm5vdGF0aW9uIDJdDQo+ID4gdGltZVRvQWR2ID0gdGltZVRv
QWR2ICogKG5ld0ludGVydmFsIC8gb2xkSW50ZXJ2YWwpDQo+ID4gICAgICAgICAgICAgICAgID0g
dGltZVRvQWR2ICogKEJBU0VfUkFfSU5URVJWQUwqMl5hIC8NCj4gPiBCQVNFX1JBX0lOVEVSVkFM
KjJeKDJhKzEpICkNCj4gPiAgICAgICAgICAgICAgICAgPSB0aW1lVG9BZHYgKiAyXigtKGErMSkp
DQo+ID4gICAgICAgICAgICAgICAgID0gdGltZVRvQWR2IC8gMl4oYSsxKQ0KPiA+DQo+ID4NCj4g
PiBXaGVuIGFkdmVydGlzaW5nIGludGVyZmFjZSB1c2UgUkRBLCBIb3N0IHdpbGwgbm90IHNlbmQg
UlMgYnV0IHdhaXQgZm9yDQo+ID4gcG9zc2libGUgUkEgd2hlbiBpdCBzdGFydHVwLiBJZiBpdCBn
ZXQgbm90aGluZyB3aXRoaW4gVElNRV9XQUlUX0ZPUl9SQSwgYSBSUw0KPiA+IHdvdWxkIGJlIHNl
bnQgb3V0IHRvIHNvbGljaXQgUkEuIFRoaXMgcHJvY2VzcyBjb3VsZCByZWR1Y2UgdGhlIGJyb2Fk
Y2FzdA0KPiA+IGZsb3cgb2YgUlMgd2hlbiBIb3N0cyBib290c3RyYXAuIE1lYW53aGlsZSwgUm91
dGVyIHdvdWxkIHNlbmQgbXVsdGljYXN0IFJBDQo+ID4gd2l0aCBhIHNtYWxsIGludGVydmFsIGF0
IHRoZSBiZWdpbmluZyBhbmQgaW5jcmVhc2UgdGhlIHNlbmRpbmcgaW50ZXJ2YWwNCj4gPiBncmFk
dWFsbHkuIFRoYXQgY291bGQgc2F0aXNmeSB0aGUgcmVxdWlyZW1lbnQgZm9yIFJBIGZyb20gSG9z
dCB3aGVuIDgwMi4xNS40DQo+ID4gbm9kZXMgY29uc3RydWN0aW5nIG5ldHdvcmsuIEZvciBUSU1F
X1dBSVRfRk9SX1JBIGlzIGEgcmFuZG9tIHZhbHVlIGJldHdlZW4NCj4gPiBCQVNFX1JBX0lOVEVS
VkFMIGFuZCAyKkJBU0VfUkFfSU5URVJWQUwsIGl0IGlzIGhpZ2hseSBwb3NzaWJsZSB0aGF0IG1v
c3Qgb2YNCj4gPiB0aGUgSG9zdHMgbmVlZG4ndCB0byBzZW5kIFJTIHdoZW4gbm9kZXMgaW4gdGhl
IHNhbWUgUEFOIHN0YXJ0IHRvIGNvbnN0cnVjdA0KPiA+IG5ldHdvcmsgdG9wb2xvZ3kuIEFmdGVy
IHRoZSB0b3BvbG9neSBoYXMgYmVlbiBzdGFibGUgKG1vc3Qgb2Ygbm9kZXMgaGF2ZQ0KPiA+IGpv
aW5lZCBpbnRvIHRoZSBQQU4pLCBpbnRlcnZhbCBvZiBSQSB3aWxsIGluY3JlYXNlIHRvIGEgbGFy
Z2UgdmFsdWUgd2hpY2gNCj4gPiBhbGxldmlhdGUgdGhlIGVuZXJneSB3YXN0YWdlIGJ5IGJyb2Fk
Y2FzdGluZyBSQSBtZXNzYWdlIGZyZXF1ZW50bHkuDQo+ID4NCj4gPiBXaGVuIHRoZSBuZXR3b3Jr
IGJlY29tZSB1bnN0YWJsZSAoZWcuIHNvbWUgbm9kZXMgbG9zZSBzeW5jaHJvbml6YXRpb24gd2l0
aA0KPiA+IGJlYWNvbiwgdGhleSB3b3VsZCBzdGFydCBvcnBoYW4gc2NhbiBhbmQgdHJ5IHRvIHJl
LWpvaW4gdGhlIG5ldHdvcmsuIEF0IHRoaXMNCj4gPiB0aW1lLCBub2RlIG1pZ2h0IG5lZWQgdG8g
cmVxdWVzdCBhIG5ldyBSQSBtZXNzYWdlIGZvciBhZGRyZXNzDQo+ID4gYXV0b2NvbmZpZ3VyYXRp
b24pIG9yIG5ldyBub2RlIHRyeSB0byBqb2luIFBBTiwgSG9zdCB3b3VsZCBzZW5kIFJTIHRvDQo+
ID4gUm91dGVyLiBSb3V0ZXIgYW5zd2VyIHRoZSBzb2xpY2l0YXRpb24gd2l0aCBVbmljYXN0IFJB
IGFuZCByZWR1Y2UgUkENCj4gPiBpbnRlcnZhbCBleHBvbmVudGlhbGx5IHRvIHJlc3BvbnNlIHRo
ZSBjaGFuZ2Ugb2YgbmV0d29yayByYXBpZGx5LiBJZiB0aGUgUEFODQo+ID4gaXMgc3VmZmVyaW5n
IGEgc2VyaW91cyB1bmR1bGF0aW9uIChlZy4gYSBwYXJlbnQgbm9kZSB3aXRoIHNldmVyYWwgY2hp
bGRyZW4NCj4gPiBvciBncmFuZGNoaWxkcmVuIGZhaWxlZCwgYWxsIG9mIGNoaWxkcmVuIG5lZWQg
dG8gcmUtam9pbiB0aGUgbmV0d29yay4gVGhlDQo+ID4gcmVzdWx0IG9mIHRoaXMgc2NlbmFyaW8g
aXMgbG90cyBvZiBSUyBtZXNzYWdlcyBhcHBlYXJpbmcgb24gdGhlIGNoYW5uZWwpLA0KPiA+IFJv
dXRlciByZXNwb25zZSB0aGlzIHNpdHVhdGlvbiBieSBzZW5kaW5nIGEgTXVsdGljYXN0IFJBIGlt
bWVkaWF0ZWx5IGFzIHNvb24NCj4gPiBhcyBtb3JlIHRoYW4gMyBSUyByZWNlaXZlZCBiZXR3ZWVu
IHR3byBhZGphY2VudCB1bnNvbGljaXRlZCBSQS4gTm93LCBSQQ0KPiA+IGZhY3RvciBhbmQgUkEg
aW50ZXJ2YWwgaGF2ZSBkZWNyZWFzZWQgdG8gc21hbGwgdmFsdWUsIFJvdXRlciBiZWdpbiB0byBz
ZW5kDQo+ID4gUkEgZnJlcXVlbnRseSBhbmQgZW50ZXJzIGEgZmFzdCBhZHZlcnRpc2luZyBwZXJp
b2QgdG8gYWNjb21tb2RhdGUgdGhlIGNoYW5nZQ0KPiA+IG9mIG5ldHdvcmsuDQo+ID4NCj4gPiBX
aGVuIG5ldHdvcmsgdG9wb2xvZ3kgY29tZXMgc3RhYmxlIGFmdGVyIGdvbmUgdGhyb3VnaCB0aGUg
d2F2eSBwZXJpb2QsIFJBDQo+ID4gaW50ZXJ2YWwgd291bGQgaW5jcmVhc2UgYWdhaW4gd2l0aCB0
aGUgUkEgZmFjdG9yLiBBdCBsYXN0LCBpdCByZWFjaHMgYSBsYXJnZQ0KPiA+IGVub3VnaCB2YWx1
ZSBhbmQgZW50ZXJzIHRoZSBzbG93IGFkdmVydGlzaW5nIHBlcmlvZC4NCj4gPg0KPiA+IEJlbG93
IHRhYmxlIHNob3cgdGhlIGNoYW5nZSBvZiBSQSBpbnRlcnZhbCAoQkFTRV9SQV9JTlRFUlZBTCA9
IDEwDQo+ID4gbWluLE1BWF9SQV9GQUNUT1IgPSA2KS4gUkEgaW50ZXJ2YWwgd2lsbCBpbmNyZWFz
ZSB0byAxMC4zaCBpZiB0aGUgbmV0d29yaw0KPiA+IHRvcG9sb2d5IHN0YXlzIHN0YWJsZSAoaXQg
aXMgYWxzbyB0aGUgY2hhcmFjdGVyIG9mIFdTTjogdG9wb2xvZ3kgd291bGRuJ3QNCj4gPiB0YWtl
IGZyZXF1ZW50IGNoYW5nZSBhZnRlciB0aGUgaW5pdGlhbCBuZXR3b3JrIG9yZ2FuaXphdGlvbiku
IFN1Y2ggYSBsb25nDQo+ID4gaW50ZXJ2YWwgb25seSB0YWtlIGxpdHRsZSBuZWdhdGl2ZSBlZmZl
Y3QgdG8gdGhlIHBvd2VyIGNvbnN1bXB0aW9uLg0KPiA+ID09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4gYSAgICBpbnRlcnZhbCAgIHNlbmRU
aW1lcyAgIFRpbWUgdG8gYWNoaWV2ZSB0aGUgaW50dmwNCj4gPiAwICAgIDEwbSAgICAgICAgICAx
ICAgICAgICAgICAgICAgICAwDQo+ID4gMSAgICAyMG0gICAgICAgICAgMiAgICAgICAgICAgICAg
ICAgMTBtDQo+ID4gMiAgICA0MG0gICAgICAgICAgMyAgICAgICAgICAgICAgICAgNTBtDQo+ID4g
MyAgICA4MG0gICAgICAgICAgNCAgICAgICAgICAgICAgICAgMi44aA0KPiA+IDQgICAgMTYwbSAg
ICAgICAgIDUgICAgICAgICAgICAgICAgIDguMmgNCj4gPiA1ICAgIDMyMG0gICAgICAgICA2ICAg
ICAgICAgICAgICAgICAyMS41aA0KPiA+IDYgICAgNjQwbSAgICAgICAgIDcgICAgICAgICAgICAg
ICAgIDUzLjVoDQo+ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT0NCj4gPg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IE1hcmlvIE1hbw0K
PiA+IE1hcmlvTWFvQEdtYWlsLmNvbQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA2bG93cGFuIG1haWxpbmcgbGlzdA0KPiA+IDZs
b3dwYW5AaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by82bG93cGFuDQo+ID4NCj4gPg0KPiA+



--===============1709829127==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--===============1709829127==--



From 6lowpan-bounces@ietf.org Mon Nov 06 19:39:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhEzc-0001QC-3s; Mon, 06 Nov 2006 19:39:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEzb-0001Q2-6B
	for 6lowpan@lists.ietf.org; Mon, 06 Nov 2006 19:39:07 -0500
Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEzZ-0003nB-Hc
	for 6lowpan@lists.ietf.org; Mon, 06 Nov 2006 19:39:07 -0500
Received: from [127.0.0.1] (dhcp34-130.ietf67.org [130.129.34.130])
	by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id kA70cs7x061536;
	Mon, 6 Nov 2006 18:39:00 -0600 (CST) (envelope-from salo@saloits.com)
Message-ID: <454FD596.8020605@saloits.com>
Date: Mon, 06 Nov 2006 18:38:46 -0600
From: "Timothy J. Salo" <salo@saloits.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: 6lowpan@lists.ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Cc: 
Subject: [6lowpan] Problem Statement Comments
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Errors-To: 6lowpan-bounces@ietf.org

I read the Problem draft again, and therefore have some (admittedly
belated) comments.

Section 4.1, "IP Connectivity"

   If I were writing this section, I would focus on what we probably
   agree are our primary objectives. (I would probably also try to
   avoid specifying the solution in a requirements document).  I might
   write something like:

     The principal motivation for this work is to seamlessly
     interconnect 802.15.4 networks with IPv4 and IPv6 networks,
     including the Internet.

   I don't think this statement is made clearly and directly in
   this document, (or the charter, the last time I looked).

   The current text of this section, for the most part seems to focus
   more on why IPv6 was chosen as the solution, rather than on a
   strong statement that our objective is to interconnect 802.15.4
   networks with IP networks.  (Yes, the _last_ of the four bullets
   sort of implies this, but it feels like what should be the primary
   message was tacked on the end of some IPv6 justifications.)

Section 3. "Assumptions", Bullet 5.

   While it isn't politically correct to say so, I believe that
   there will be a device between IP networks and 802.15.4 networks
   that meets most reasonable definitions of a "gateway".  Nonetheless,
   it is true that the use of the IPv6-like protocols that are being
   discussed make the operation of this not-really-a-gateway fairly
   straight-forward and transparent.

Section 5. "Goals", Bullet 2.

   This would be a nice place to explain in a sentence or two why
   a stateless header compression technology is needed, and why
   ROHC isn't applicable.

- - - - - - - - - - -

A bunch of nits and diction complaints follow.

"Abstract"

   The abstract claims that "Additional goals may be found necessary
   over time and may be added to this document."  I don't understand
   how this document is going to be modified over time, particularly
   after it is an RFC.

1. "Introduction", First Paragraph

   It might make sense to include "limited computational power and
   limited memory" in this list.  While this is (sort of) implied by
   low cost and low power, these limitations are so fundamental to the
   work of the group that it might not hurt to be explicit about them
   in the first paragraph.

1. "Introduction", Second Paragraph

   I don't understand the term "IP and IPv6".  Assuming this isn't
   an editorial comment on IPv6, is this supposed to read "IPv4 and
   IPv6"?

   I'm not sure I like the phrase "enabling IP communications between
   devices in a LoWPAN" because I assume that our real interest is
   to enable IP communications between devices attached to 802.15.4
   networks and IP devices on _other_ networks, (as well as intra-
   802.15.4 communications).

   Have we identified any items that are not "necessarily appropriate
   tasks for the IETF"?  The purpose of this sentence is not clear
   to me.  Could this sentence be deleted?

2. "Overview", First Paragraph

   Yes, I know the 802.15.4 spec uses the term "relaxed throughput",
   but it still seems a bit affected to me.  "Limited bandwidth"
   seems a bit more direct, (but I warned earlier that this is the
   diction section...)

2. "Overview", Sixth Bullet

   "Limited processing power, limited memory, etc." might read better
   than "low processing, low memory, etc."  I might also delete the
   last sentence -- it doesn't really add much.

2. "Overview", Ninth Bullet

   This bullet seems to munge two ideas together: that connectivity
   may be unreliable and that devices may be be unreliable.  The
   bullet might read better if the ideas were stated separately,
   or maybe if the bullet focused on connectivity rather than devices.

2. "Overview", Tenth Bullet

   Perhaps, "In many environments, devices connected to a LoWPAN
   may sleep for long periods of time in order to conserve energy,
   and are unable to communicate during these sleep periods."

3. "Assumptions", Bullets

   I  might focus on the assumption that using IP technologies will
   simplify the interconnection of 802.15.4 networks and IP networks.
   This is sort of what the last paragraph says, my quibbles about
   the claim that a gateway won't exist notwithstanding.

   I don't really understand what the first bullet is trying to say.
   Perhaps, it would be more clear if a few examples were provided.

   I have some question about how applicable the fourth bullet is.
   Will I be able to ping a LoWPAN device?  Send it an SNMP GET?
   (This is where I will say that it would make a lot more sense
   for the we-can't-call-it-a-gateway to respond to these requests
   for the LoWPAN device.)

Section 4.2, "Topologies", Fourth Bullet

   The notion that many LoWPAN devices will sleep much of the time
   is a very important idea.  I would either make this the focus of
   the bullet, (e.g., move this sentence to the beginning of the
   bullet) or add a separate bullet that mentions it.

Section 4.2, "Topologies", Last Paragraph

   This is a very important paragraph.  Many of my comments try to
   emphasize the idea that we want to seamlessly integrate 802.15.4
   networks with IP networks.  However, this idea currently seems
   to be buried in this discussion of topologies.

Section 5, "Goals", Fourth Bullet

   "Ad hoc" is two words.  (OK, OK, this is pretty minor, but
   ad hoc networks are so closely related to this work that we at
   least ought to spell their name correctly...)

Section 5, "Goals", Seventh Bullet

   This is a very interesting topic.  I don't know whether we want
   to suggest changes to verbose higher-layer protocols or simply
   say "don't do that".  (When reviewing a specification document
   for a system that was going to operate in a wireless environment,
   I finally gave up and simply said, "just globally replace all
    instances of "XML good" with "XML bad".)

-tjs


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Mon Nov 06 20:28:26 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhFku-00061J-Ue; Mon, 06 Nov 2006 20:28:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFkt-00061C-Ps
	for 6lowpan@lists.ietf.org; Mon, 06 Nov 2006 20:27:59 -0500
Received: from grab.coslabs.com ([199.233.92.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhFkr-0001OA-AS
	for 6lowpan@lists.ietf.org; Mon, 06 Nov 2006 20:27:59 -0500
Received: from dhcp66-22.ietf67.org (dhcp66-22.ietf67.org [130.129.66.22])
	by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id kA71RuM5010149;
	Mon, 6 Nov 2006 18:27:56 -0700 (MST)
Subject: Re: [6lowpan] Problem Statement Comments
From: Geoff Mulligan <geoff@mulligan.com>
To: "Timothy J. Salo" <salo@saloits.com>
In-Reply-To: <454FD596.8020605@saloits.com>
References: <454FD596.8020605@saloits.com>
Content-Type: text/plain
Date: Mon, 06 Nov 2006 18:27:50 -0700
Message-Id: <1162862871.5256.11.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.1 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Cc: 6lowpan@lists.ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Errors-To: 6lowpan-bounces@ietf.org

Timothy,
  The WG last call on the problem statement document has long since
closed.  That said, I think that a few of the editorial nits that you
point out could and should be addressed, though we need input from the
rest of the group as to which of your comments should be "fixed".

	geoff

On Mon, 2006-11-06 at 18:38 -0600, Timothy J. Salo wrote:
> I read the Problem draft again, and therefore have some (admittedly
> belated) comments.
> 
> Section 4.1, "IP Connectivity"
> 
>    If I were writing this section, I would focus on what we probably
>    agree are our primary objectives. (I would probably also try to
>    avoid specifying the solution in a requirements document).  I might
>    write something like:
> 
>      The principal motivation for this work is to seamlessly
>      interconnect 802.15.4 networks with IPv4 and IPv6 networks,
>      including the Internet.
> 
>    I don't think this statement is made clearly and directly in
>    this document, (or the charter, the last time I looked).
> 
>    The current text of this section, for the most part seems to focus
>    more on why IPv6 was chosen as the solution, rather than on a
>    strong statement that our objective is to interconnect 802.15.4
>    networks with IP networks.  (Yes, the _last_ of the four bullets
>    sort of implies this, but it feels like what should be the primary
>    message was tacked on the end of some IPv6 justifications.)
> 
> Section 3. "Assumptions", Bullet 5.
> 
>    While it isn't politically correct to say so, I believe that
>    there will be a device between IP networks and 802.15.4 networks
>    that meets most reasonable definitions of a "gateway".  Nonetheless,
>    it is true that the use of the IPv6-like protocols that are being
>    discussed make the operation of this not-really-a-gateway fairly
>    straight-forward and transparent.
> 
> Section 5. "Goals", Bullet 2.
> 
>    This would be a nice place to explain in a sentence or two why
>    a stateless header compression technology is needed, and why
>    ROHC isn't applicable.
> 
> - - - - - - - - - - -
> 
> A bunch of nits and diction complaints follow.
> 
> "Abstract"
> 
>    The abstract claims that "Additional goals may be found necessary
>    over time and may be added to this document."  I don't understand
>    how this document is going to be modified over time, particularly
>    after it is an RFC.
> 
> 1. "Introduction", First Paragraph
> 
>    It might make sense to include "limited computational power and
>    limited memory" in this list.  While this is (sort of) implied by
>    low cost and low power, these limitations are so fundamental to the
>    work of the group that it might not hurt to be explicit about them
>    in the first paragraph.
> 
> 1. "Introduction", Second Paragraph
> 
>    I don't understand the term "IP and IPv6".  Assuming this isn't
>    an editorial comment on IPv6, is this supposed to read "IPv4 and
>    IPv6"?
> 
>    I'm not sure I like the phrase "enabling IP communications between
>    devices in a LoWPAN" because I assume that our real interest is
>    to enable IP communications between devices attached to 802.15.4
>    networks and IP devices on _other_ networks, (as well as intra-
>    802.15.4 communications).
> 
>    Have we identified any items that are not "necessarily appropriate
>    tasks for the IETF"?  The purpose of this sentence is not clear
>    to me.  Could this sentence be deleted?
> 
> 2. "Overview", First Paragraph
> 
>    Yes, I know the 802.15.4 spec uses the term "relaxed throughput",
>    but it still seems a bit affected to me.  "Limited bandwidth"
>    seems a bit more direct, (but I warned earlier that this is the
>    diction section...)
> 
> 2. "Overview", Sixth Bullet
> 
>    "Limited processing power, limited memory, etc." might read better
>    than "low processing, low memory, etc."  I might also delete the
>    last sentence -- it doesn't really add much.
> 
> 2. "Overview", Ninth Bullet
> 
>    This bullet seems to munge two ideas together: that connectivity
>    may be unreliable and that devices may be be unreliable.  The
>    bullet might read better if the ideas were stated separately,
>    or maybe if the bullet focused on connectivity rather than devices.
> 
> 2. "Overview", Tenth Bullet
> 
>    Perhaps, "In many environments, devices connected to a LoWPAN
>    may sleep for long periods of time in order to conserve energy,
>    and are unable to communicate during these sleep periods."
> 
> 3. "Assumptions", Bullets
> 
>    I  might focus on the assumption that using IP technologies will
>    simplify the interconnection of 802.15.4 networks and IP networks.
>    This is sort of what the last paragraph says, my quibbles about
>    the claim that a gateway won't exist notwithstanding.
> 
>    I don't really understand what the first bullet is trying to say.
>    Perhaps, it would be more clear if a few examples were provided.
> 
>    I have some question about how applicable the fourth bullet is.
>    Will I be able to ping a LoWPAN device?  Send it an SNMP GET?
>    (This is where I will say that it would make a lot more sense
>    for the we-can't-call-it-a-gateway to respond to these requests
>    for the LoWPAN device.)
> 
> Section 4.2, "Topologies", Fourth Bullet
> 
>    The notion that many LoWPAN devices will sleep much of the time
>    is a very important idea.  I would either make this the focus of
>    the bullet, (e.g., move this sentence to the beginning of the
>    bullet) or add a separate bullet that mentions it.
> 
> Section 4.2, "Topologies", Last Paragraph
> 
>    This is a very important paragraph.  Many of my comments try to
>    emphasize the idea that we want to seamlessly integrate 802.15.4
>    networks with IP networks.  However, this idea currently seems
>    to be buried in this discussion of topologies.
> 
> Section 5, "Goals", Fourth Bullet
> 
>    "Ad hoc" is two words.  (OK, OK, this is pretty minor, but
>    ad hoc networks are so closely related to this work that we at
>    least ought to spell their name correctly...)
> 
> Section 5, "Goals", Seventh Bullet
> 
>    This is a very interesting topic.  I don't know whether we want
>    to suggest changes to verbose higher-layer protocols or simply
>    say "don't do that".  (When reviewing a specification document
>    for a system that was going to operate in a wireless environment,
>    I finally gave up and simply said, "just globally replace all
>     instances of "XML good" with "XML bad".)
> 
> -tjs
> 
> 
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Tue Nov 07 04:13:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhN0o-0000uz-35; Tue, 07 Nov 2006 04:12:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhN0m-0000uY-I6
	for 6lowpan@ietf.org; Tue, 07 Nov 2006 04:12:52 -0500
Received: from ee.oulu.fi ([130.231.61.23])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhN0k-0004VO-2s
	for 6lowpan@ietf.org; Tue, 07 Nov 2006 04:12:52 -0500
Received: from [10.100.11.184] (ee-gw3 [130.231.61.13])
	by ee.oulu.fi (8.13.8/8.13.8) with ESMTP id kA79Cl1b007741
	for <6lowpan@ietf.org>; Tue, 7 Nov 2006 11:12:47 +0200 (EET)
Message-ID: <45504E40.8070407@ee.oulu.fi>
Date: Tue, 07 Nov 2006 11:13:36 +0200
From: "M. Ikram Ashraf" <ikram@ee.oulu.fi>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: 6lowpan@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Subject: [6lowpan] 6LoWPAN Ov IEEE 802.15.4
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Errors-To: 6lowpan-bounces@ietf.org

Hi,

Actually i am looking for some stuff related to 6LoWPAN over IEEE 802.15.4.

Thanks.
ikram


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Tue Nov 07 22:16:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhdvL-0001g1-Sb; Tue, 07 Nov 2006 22:16:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhdvK-0001fw-Vm
	for 6lowpan@lists.ietf.org; Tue, 07 Nov 2006 22:16:22 -0500
Received: from web81905.mail.mud.yahoo.com ([68.142.207.184])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhdvC-0003ct-C3
	for 6lowpan@lists.ietf.org; Tue, 07 Nov 2006 22:16:22 -0500
Received: (qmail 30329 invoked by uid 60001); 8 Nov 2006 03:16:13 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type;
	b=BVSvg1KzZgkQWqsfuTs+O8B1OrO9CFKOUsLgm5kZHA5siPdQEI49ZPcYa8NqzAYI79vclGzqO3lHhS6nXKZxvb6bvM4/U7F4qAPdBXo+/IQelJlyDO1JIKdptT8fIMXPpJ2Q1oKic8LOrHF0yMQUYF33FrBQxGaZOmev7LcwTA8=
	; 
Message-ID: <20061108031613.30327.qmail@web81905.mail.mud.yahoo.com>
Received: from [130.129.70.150] by web81905.mail.mud.yahoo.com via HTTP;
	Tue, 07 Nov 2006 19:16:13 PST
Date: Tue, 7 Nov 2006 19:16:13 -0800 (PST)
From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Subject: Re: [6lowpan] Proposal for alternative 6lowpan header encoding
To: Geoff Mulligan <geoff@mulligan.com>, 6lowpan <6lowpan@lists.ietf.org>
MIME-Version: 1.0
X-Spam-Score: 1.0 (+)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: 
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0365186587=="
Errors-To: 6lowpan-bounces@ietf.org

--===============0365186587==
Content-Type: multipart/alternative; boundary="0-1435905432-1162955773=:29601"

--0-1435905432-1162955773=:29601
Content-Type: text/plain; charset=ascii
Content-Transfer-Encoding: quoted-printable

By the way, =0A=0AIn order to get an idea of what the format document would=
 look like if we decided to go=0Aahead with its adoption, the Jonathan and =
David have produced a tentative version of the =0Adocument. Since this migh=
t help folks better evaluate the proposal, you can get it here:=0A=0Ahttp:/=
/briefcase.yahoo.com/bc/gabriel_montenegro_2000/lst?&.dir=3D/lowpan&.src=3D=
bc&.view=3Dl=0A=0A=0ABTW, this version is built on version 06 (with changes=
 based on Geoff's review), submitted yesterday, and also available at the a=
bove URL (until it gets=0Aofficially published).=0A=0A-gabriel=0A=0A----- O=
riginal Message ----=0AFrom: Geoff Mulligan <geoff@mulligan.com>=0ATo: 6low=
pan <6lowpan@lists.ietf.org>=0ASent: Friday, November 3, 2006 3:49:02 PM=0A=
Subject: [6lowpan] Proposal for alternative 6lowpan header encoding=0A=0A=
=0AFolks,=0A  Arch Rock have submitted a proposal for a different 6lowpan h=
eader=0Aencoding.  David and Jonathan put together a set a slides to descri=
be=0Atheir idea to simplify the 6lowpan adaptation header.  They are workin=
g=0Aon a complete proposal.=0A=0AI have posted the slides to the wiki at:=
=0A=0Ahttp://6lowpan.tzi.org/FrontPage?action=3DAttachFile&do=3Dget&target=
=3D6lowpan-header-proposal.ppt=0A=0AYou can also get a copy (if you are wik=
i challenged) at:=0Ahttp://www.mulligan.com/6lowpan/6lowpan-header-proposal=
.ppt=0A=0ATheir design seems to follow the ideas of IPv6, reduce the header=
 size=0Ain almost all cases, allow for extensions, byte align the fields an=
d as=0AI've thought about coding it, it looks like less complex parsing.=0A=
=0AWhile a proposal such as this (ideas tend to come on their own schedule)=
=0Aat this late stage in our process will be disruptive, the potential=0Ava=
lue of simplifying and fixing some of the identified problems in the=0Acurr=
ent design is, in my opinion, worth the time and effort and risk to=0Aour a=
lready blown schedule to evaluate and discuss within the group.=0A=0APlease=
 take a look at the slides.  We only a have few days before the=0Ameeting o=
n Wednesday and if possible I would like to hear peoples=0Athoughts.  I hav=
e asked Jonathan and David to attend the WG meeting and=0Ato prepare a more=
 in-depth presentation related to this new design.=0A=0A        geoff=0A=0A=
=0A=0A_______________________________________________=0A6lowpan mailing lis=
t=0A6lowpan@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/6lowpan
--0-1435905432-1162955773=:29601
Content-Type: text/html; charset=ascii
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:courier, monaco, monospace, sans-serif;f=
ont-size:12pt"><DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco,=
 monospace, sans-serif">By the way, </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt;=
 FONT-FAMILY: courier, monaco, monospace, sans-serif"> </DIV>=0A<DIV s=
tyle=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-seri=
f">In order to get an idea of what the format document would look like if w=
e decided to go</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier=
, monaco, monospace, sans-serif">ahead with its adoption, the Jonathan and =
David have produced a tentative version of the </DIV>=0A<DIV style=3D"FONT-=
SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif">document. =
Since this might help folks better evaluate the proposal, you can get it he=
re:</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, mo=
nospace, sans-serif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAM=
ILY: courier, monaco, monospace, sans-serif"><A href=3D"http://briefcase.ya=
hoo.com/bc/gabriel_montenegro_2000/lst?&.dir=3D/lowpan&.src=3Dbc&am=
p;.view=3Dl">http://briefcase.yahoo.com/bc/gabriel_montenegro_2000/lst?&=
;.dir=3D/lowpan&.src=3Dbc&.view=3Dl</A><BR><BR>=0A<DIV style=3D"FON=
T-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">BTW, th=
is version is built on version 06 (with changes based on Geoff's review), s=
ubmitted yesterday, and also available at the above URL (until it gets</DIV=
>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, =
times, serif">officially published).</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt;=
 FONT-FAMILY: times new roman, new york, times, serif"> </DIV>=0A<DIV =
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, se=
rif">-gabriel</DIV>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new=
 roman, new york, times, serif"> </DIV>=0A<DIV style=3D"FONT-SIZE: 12p=
t; FONT-FAMILY: times new roman, new york, times, serif">----- Original Mes=
sage ----<BR>From: Geoff Mulligan <geoff@mulligan.com><BR>To: 6lowpan=
 <6lowpan@lists.ietf.org><BR>Sent: Friday, November 3, 2006 3:49:02 P=
M<BR>Subject: [6lowpan] Proposal for alternative 6lowpan header encoding<BR=
><BR>=0A<DIV>Folks,<BR>  Arch Rock have submitted a proposal for =
a different 6lowpan header<BR>encoding.  David and Jonathan put t=
ogether a set a slides to describe<BR>their idea to simplify the 6lowpan ad=
aptation header.  They are working<BR>on a complete proposal.<BR>=
<BR>I have posted the slides to the wiki at:<BR><BR><A href=3D"http://6lowp=
an.tzi.org/FrontPage?action=3DAttachFile&do=3Dget&target=3D6lowpan-=
header-proposal.ppt" target=3D_blank>http://6lowpan.tzi.org/FrontPage?actio=
n=3DAttachFile&do=3Dget&target=3D6lowpan-header-proposal.ppt</A><BR=
><BR>You can also get a copy (if you are wiki challenged) at:<BR><A href=3D=
"http://www.mulligan.com/6lowpan/6lowpan-header-proposal.ppt" target=3D_bla=
nk>http://www.mulligan.com/6lowpan/6lowpan-header-proposal.ppt</A><BR><BR>T=
heir design seems to follow the ideas of IPv6, reduce the header size<BR>in=
 almost all cases, allow for extensions, byte align the fields and as<BR>I'=
ve thought about coding it, it looks like
 less complex parsing.<BR><BR>While a proposal such as this (ideas tend to =
come on their own schedule)<BR>at this late stage in our process will be di=
sruptive, the potential<BR>value of simplifying and fixing some of the iden=
tified problems in the<BR>current design is, in my opinion, worth the time =
and effort and risk to<BR>our already blown schedule to evaluate and discus=
s within the group.<BR><BR>Please take a look at the slides.  We =
only a have few days before the<BR>meeting on Wednesday and if possible I w=
ould like to hear peoples<BR>thoughts.  I have asked Jonathan and=
 David to attend the WG meeting and<BR>to prepare a more in-depth presentat=
ion related to this new design.<BR><BR>      =
  geoff<BR><BR><BR><BR>__________________________________________=
_____<BR>6lowpan mailing list<BR>6lowpan@ietf.org<BR><A href=3D"https://www=
1.ietf.org/mailman/listinfo/6lowpan"
 target=3D_blank>https://www1.ietf.org/mailman/listinfo/6lowpan</A></DIV></=
DIV><BR></DIV></div></body></html>
--0-1435905432-1162955773=:29601--


--===============0365186587==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--===============0365186587==--




From 6lowpan-bounces@ietf.org Wed Nov 08 02:36:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ghhz9-0000oL-I0; Wed, 08 Nov 2006 02:36:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghhz7-0000ek-7B
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 02:36:33 -0500
Received: from maily.danfoss.com ([193.162.34.7])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghhz5-0001NV-Jp
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 02:36:33 -0500
Received: from DKDN04MX62.dkdn04.danfoss.net ([10.6.2.62]) by
	maily.danfoss.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 8 Nov 2006 08:36:40 +0100
Received: from dkdn01mx21.danfoss.net ([10.12.129.21]) by
	DKDN04MX62.dkdn04.danfoss.net with InterScan Message Security
	Suite; Wed, 08 Nov 2006 08:36:40 +0100
Received: from DKDN01MX34.danfoss.net ([10.12.128.14]) by
	dkdn01mx21.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 8 Nov 2006 08:36:40 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [6lowpan] Proposal for alternative 6lowpan header encoding
Date: Wed, 8 Nov 2006 08:32:27 +0100
Message-ID: <49A38D2FE2C53946A57916AD6A1F00D7139368@DKDN01MX34.danfoss.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [6lowpan] Proposal for alternative 6lowpan header encoding
Thread-Index: AccC5PUe8SPznNZETD2Ys3Y3XNhOXgAIxWkt
References: <20061108031613.30327.qmail@web81905.mail.mud.yahoo.com>
From: "Schumacher Christian Peter Pii" <schumacher@danfoss.com>
To: "gabriel montenegro" <gabriel_montenegro_2000@yahoo.com>,
	"Geoff Mulligan" <geoff@mulligan.com>, "6lowpan" <6lowpan@lists.ietf.org>
X-OriginalArrivalTime: 08 Nov 2006 07:36:40.0090 (UTC)
	FILETIME=[A11B6FA0:01C70308]
X-TM-AS-Product-Ver: SMEX-7.0.0.1526-3.5.1048-14800.000
X-TM-AS-Result: No--21.013000-5.000000-2
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1
Cc: 
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>,
	<mailto:6lowpan-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0216770929=="
Errors-To: 6lowpan-bounces@ietf.org

This is a multi-part message in MIME format.


--===============0216770929==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C70308.A0FFD72D"

This is a multi-part message in MIME format.


------_=_NextPart_001_01C70308.A0FFD72D
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Gabriel.
I'm having difficulty accessing the document at:
http://briefcase.yahoo.com/bc/gabriel_montenegro_2000/lst?&.dir=3D/lowpan=
&.src=3Dbc&.view=3Dl

With Firefox I get a blank page.
With Internet Explorer, it says "This folder is currently empty"

What am I doing wrong?

Thanks in advance
-Christian


-----Original Message-----
From: gabriel montenegro [mailto:gabriel_montenegro_2000@yahoo.com]
Sent: Wed 11/8/2006 4:16 AM
To: Geoff Mulligan; 6lowpan
Subject: Re: [6lowpan] Proposal for alternative 6lowpan header encoding
=20
By the way,=20

In order to get an idea of what the format document would look like if =
we decided to go
ahead with its adoption, the Jonathan and David have produced a =
tentative version of the=20
document. Since this might help folks better evaluate the proposal, you =
can get it here:

http://briefcase.yahoo.com/bc/gabriel_montenegro_2000/lst?&.dir=3D/lowpan=
&.src=3Dbc&.view=3Dl


BTW, this version is built on version 06 (with changes based on Geoff's =
review), submitted yesterday, and also available at the above URL (until =
it gets
officially published).

-gabriel

----- Original Message ----
From: Geoff Mulligan <geoff@mulligan.com>
To: 6lowpan <6lowpan@lists.ietf.org>
Sent: Friday, November 3, 2006 3:49:02 PM
Subject: [6lowpan] Proposal for alternative 6lowpan header encoding


Folks,
  Arch Rock have submitted a proposal for a different 6lowpan header
encoding.  David and Jonathan put together a set a slides to describe
their idea to simplify the 6lowpan adaptation header.  They are working
on a complete proposal.

I have posted the slides to the wiki at:

http://6lowpan.tzi.org/FrontPage?action=3DAttachFile&do=3Dget&target=3D6l=
owpan-header-proposal.ppt

You can also get a copy (if you are wiki challenged) at:
http://www.mulligan.com/6lowpan/6lowpan-header-proposal.ppt

Their design seems to follow the ideas of IPv6, reduce the header size
in almost all cases, allow for extensions, byte align the fields and as
I've thought about coding it, it looks like less complex parsing.

While a proposal such as this (ideas tend to come on their own schedule)
at this late stage in our process will be disruptive, the potential
value of simplifying and fixing some of the identified problems in the
current design is, in my opinion, worth the time and effort and risk to
our already blown schedule to evaluate and discuss within the group.

Please take a look at the slides.  We only a have few days before the
meeting on Wednesday and if possible I would like to hear peoples
thoughts.  I have asked Jonathan and David to attend the WG meeting and
to prepare a more in-depth presentation related to this new design.

        geoff



_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



------_=_NextPart_001_01C70308.A0FFD72D
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7650.28">
<TITLE>RE: [6lowpan] Proposal for alternative 6lowpan header =
encodingHi Gabriel.

I'm having difficulty accessing the document at:

http://briefcase.yahoo.com/bc/gabriel_monten=
egro_2000/lst?&.dir=3D/lowpan&.src=3Dbc&.view=3Dl



With Firefox I get a blank page.

With Internet Explorer, it says "This folder is currently =
empty"



What am I doing wrong?



Thanks in advance

-Christian





-----Original Message-----

From: gabriel montenegro [mailto:gabriel_monteneg=
ro_2000@yahoo.com]

Sent: Wed 11/8/2006 4:16 AM

To: Geoff Mulligan; 6lowpan

Subject: Re: [6lowpan] Proposal for alternative 6lowpan header =
encoding



By the way,



In order to get an idea of what the format document would look like if =
we decided to go

ahead with its adoption, the Jonathan and David have produced a =
tentative version of the

document. Since this might help folks better evaluate the proposal, you =
can get it here:



http://briefcase.yahoo.com/bc/gabriel_monten=
egro_2000/lst?&.dir=3D/lowpan&.src=3Dbc&.view=3Dl





BTW, this version is built on version 06 (with changes based on Geoff's =
review), submitted yesterday, and also available at the above URL (until =
it gets

officially published).



-gabriel



----- Original Message ----

From: Geoff Mulligan <geoff@mulligan.com>

To: 6lowpan <6lowpan@lists.ietf.org>

Sent: Friday, November 3, 2006 3:49:02 PM

Subject: [6lowpan] Proposal for alternative 6lowpan header encoding





Folks,

  Arch Rock have submitted a proposal for a different 6lowpan =
header

encoding.  David and Jonathan put together a set a slides to =
describe

their idea to simplify the 6lowpan adaptation header.  They are =
working

on a complete proposal.



I have posted the slides to the wiki at:



http://6lowpan.tzi.org/FrontPage?actio=
n=3DAttachFile&do=3Dget&target=3D6lowpan-header-proposal.ppt



You can also get a copy (if you are wiki challenged) at:

http=
://www.mulligan.com/6lowpan/6lowpan-header-proposal.ppt



Their design seems to follow the ideas of IPv6, reduce the header =
size

in almost all cases, allow for extensions, byte align the fields and =
as

I've thought about coding it, it looks like less complex parsing.



While a proposal such as this (ideas tend to come on their own =
schedule)

at this late stage in our process will be disruptive, the potential

value of simplifying and fixing some of the identified problems in =
the

current design is, in my opinion, worth the time and effort and risk =
to

our already blown schedule to evaluate and discuss within the group.



Please take a look at the slides.  We only a have few days before =
the

meeting on Wednesday and if possible I would like to hear peoples

thoughts.  I have asked Jonathan and David to attend the WG meeting =
and

to prepare a more in-depth presentation related to this new design.



        geoff







_______________________________________________

6lowpan mailing list

6lowpan@ietf.org

https://www1.ietf=
.org/mailman/listinfo/6lowpan









------_=_NextPart_001_01C70308.A0FFD72D--


--===============0216770929==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--===============0216770929==--




From 6lowpan-bounces@ietf.org Wed Nov 08 05:25:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhkcT-0005Dz-B1; Wed, 08 Nov 2006 05:25:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhkcS-0005DE-3a
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 05:25:20 -0500
Received: from w132233.ppp.asahi-net.or.jp ([121.1.132.233] helo=mama.tanu.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhkW1-0007Rg-A5
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 05:18:42 -0500
Received: from [192.168.21.125] (72-34-69-70.skyriver.net [72.34.69.70])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mama.tanu.org (Postfix) with ESMTP id A259C1A7C47
	for <6lowpan@lists.ietf.org>; Wed,  8 Nov 2006 19:18:36 +0900 (JST)
Message-ID: <4551AEEF.5000308@tanu.org>
Date: Wed, 08 Nov 2006 19:18:23 +0900
From: Shoichi Sakane 
User-Agent: Mail/News 1.5.0.2 (X11/20060428)
MIME-Version: 1.0
To: 6lowpan@lists.ietf.org
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.2 (+)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: 
Subject: [6lowpan] comment about 6lowpan-security-analysis
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

Hi all,

# If you get double mails from me, I am sorry that it was my fault.
# I sent the first mail from my wrong address, so it stacked at the
# owner of this list.

I read draft-daniel-6lowpan-security-analysis-01.txt.  I believe that
this activity is valuable to clarify the security problem for 6LoWPAN.
I thank the authors.  I would like to cooperate with the work as much as
I can.  At first, I have some comments in the section 7.2.

>>   Basically, IPsec targets to general IP nodes operated over ethernet.

It seems questionable.  I believe that it does not assume always using
over ethernet.

>>   It means each node has some of fluent stack size, bandwidth and non-
>>   low cost limitations like 6lowpan.

IPsec basically is based on symmetric cryptography.  This sentence is
only correct for some key mangement protocols to establish the keys,
like IKE.  I believe that KINK is suitable in term of power consumption.
Bandwidth consumption was not considered in both cases.

>>   Given the IPsec background, it is at least not suitable for 6lowpan
>>   nodes.  Especially, 6lowpan node may not be able to operate all IPsec
>>   algorithms on its own capability either FFD or RFD.

It is not needed to support all of likely algorithms of IPsec.  Algorithm
to be implemented for interoperability can be reduced according to RFC4305.
And RFC4309 defines how to use AES-CCM with IPsec so that a stack size might
be reduced because IEEE 802.15.4 does include AEC-CCM.

>>   Bandwidth is very sensitive element in the 6lowpan, but IPsec
>>   generates some of redundant packets such as AH/ESP header.

RFC4301 defined that AH is no longer mandated to implement.
I believe that we use just ESP to protect from almost 6LoWPAN threats.
However it is needed to investigate each threat if we do not need AH.
If we need ESP with AES-CCM, the packet size increases 32 bytes.
        4 bytes for SPI.
        4 bytes for sequence number as no ESN.
        8 bytes for IV.
        6 bytes for padding in minimum.
        1 bytes for pad length.
        1 bytes for next header.
        8 bytes for ICV.

Multiple security association between a 6lowpan node and different end
points make packet sizes increase.  However I do not think such usage
is not suitable for a 6lowpan node.  such usage is not realistic even
for a full function devices like PC.

>>   IPsec needs shared secret key between nodes called IKE (Internet Key
>>   Exchange), and it will make the key exchange in secrecy possible.  It
>>   can, however cause some of redundant packets over the 6lowpan
>>   networks.

Need a minor fix.  IKE is a protocol to establish such keys securely,
not secret keys.

And packets for key exchange is not redundant.  They are obviously necessary
to establish keys even if any method except manual keying are applied.
However, for low computaional power devices, IKE requires much power to
process asymmetric cryptography.  Indeed, a certain algorithm like ECC or
XTR can save power.  But it might not be still suitable for a 6lowpan devices.


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Wed Nov 08 13:11:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhrtX-0004qb-FM; Wed, 08 Nov 2006 13:11:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrtQ-0004ks-3K
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 13:11:20 -0500
Received: from mailhost.informatik.uni-bremen.de
	([2001:638:708:30c9:209:3dff:fe00:7136]
	helo=informatik.uni-bremen.de)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhroY-0002Dw-Kt
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 13:06:19 -0500
Received: from [127.0.0.1] (maildrop [134.102.201.19])
	by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id
	kA8I69Gn021836; Wed, 8 Nov 2006 19:06:10 +0100 (CET)
In-Reply-To: <454FD596.8020605@saloits.com>
References: <454FD596.8020605@saloits.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Carsten Bormann 
Subject: Re: [6lowpan] Problem Statement Comments
Date: Wed, 8 Nov 2006 10:06:08 -0800
To: "Timothy J. Salo" 
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e
Cc: Carsten Bormann , 6lowpan@lists.ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

Tim,

I agree with Geoff's comments; we are a bit late with making major  
changes here.
Let me go through your comments point by point.
(Chair hat off.)

On Nov 06 2006, at 16:38, Timothy J. Salo wrote:

> I read the Problem draft again, and therefore have some (admittedly
> belated) comments.
>
> Section 4.1, "IP Connectivity"
>
>   If I were writing this section, I would focus on what we probably
>   agree are our primary objectives. (I would probably also try to
>   avoid specifying the solution in a requirements document).  I might
>   write something like:
>
>     The principal motivation for this work is to seamlessly
>     interconnect 802.15.4 networks with IPv4 and IPv6 networks,
>     including the Internet.
>
>   I don't think this statement is made clearly and directly in
>   this document, (or the charter, the last time I looked).
>
>   The current text of this section, for the most part seems to focus
>   more on why IPv6 was chosen as the solution, rather than on a
>   strong statement that our objective is to interconnect 802.15.4
>   networks with IP networks.  (Yes, the _last_ of the four bullets
>   sort of implies this, but it feels like what should be the primary
>   message was tacked on the end of some IPv6 justifications.)

IPv6 really needs to be motivated in the problem document.
Re IPv4: we have a clear charter to look at IPv6.
I don't think the proposed direction of change would lead to  
consensus quickly.

> Section 3. "Assumptions", Bullet 5.
>
>   While it isn't politically correct to say so, I believe that
>   there will be a device between IP networks and 802.15.4 networks
>   that meets most reasonable definitions of a "gateway".

In the original, 1974 sense: Yes (we now use the term router).

> Nonetheless,
>   it is true that the use of the IPv6-like protocols that are being
>   discussed make the operation of this not-really-a-gateway fairly
>   straight-forward and transparent.

Routers today do have more functionality than they had in 1974.  This  
does not make them mysterious gateway devices, just function-ful  
routers.
We do want to avoid the "gateway" in the sense that every application  
upgrade requires changes to the gateway.
I think this is what bullet 5 says.

> Section 5. "Goals", Bullet 2.
>
>   This would be a nice place to explain in a sentence or two why
>   a stateless header compression technology is needed, and why
>   ROHC isn't applicable.

Now you are in solution space.
The requirement is:
1) header compression
2) limited memory requirements.
In solution space, this leads to stateless HC as the immediate  
solution, with future enhancements possibly using stateful for things  
like TCP (which may or may not look similar to current ROHC profiles).

> - - - - - - - - - - -
>
> A bunch of nits and diction complaints follow.
>
> "Abstract"
>
>   The abstract claims that "Additional goals may be found necessary
>   over time and may be added to this document."  I don't understand
>   how this document is going to be modified over time, particularly
>   after it is an RFC.

Good catch.
I propose we strike this sentence now.

> 1. "Introduction", First Paragraph
>
>   It might make sense to include "limited computational power and
>   limited memory" in this list.  While this is (sort of) implied by
>   low cost and low power, these limitations are so fundamental to the
>   work of the group that it might not hurt to be explicit about them
>   in the first paragraph.

The intro need not necessary spell out the entire situation, but I  
agree that it would be good to add this.
Note that the sentence is about "IEEE 802.15.4 devices", though,  
which is really a statement about the radio, while your comment is  
about the device as a whole.  So this would be a new sentence about  
the expected characteristics of the devices.

> 1. "Introduction", Second Paragraph
>
>   I don't understand the term "IP and IPv6".

This does sound strange.

> Assuming this isn't
>   an editorial comment on IPv6, is this supposed to read "IPv4 and
>   IPv6"?

No.  This was meant to say "IP in general and IPv6 in particular".

>   I'm not sure I like the phrase "enabling IP communications between
>   devices in a LoWPAN" because I assume that our real interest is
>   to enable IP communications between devices attached to 802.15.4
>   networks and IP devices on _other_ networks, (as well as intra-
>   802.15.4 communications).

So, maybe replace "between" with "with"?

>   Have we identified any items that are not "necessarily appropriate
>   tasks for the IETF"?  The purpose of this sentence is not clear
>   to me.  Could this sentence be deleted?

The sentence could be improved.  The intention is to say that not all  
that needs to be done for "enabling..." can be done in the IETF, so  
we need to focus on the problems the IETF can work on.

> 2. "Overview", First Paragraph
>
>   Yes, I know the 802.15.4 spec uses the term "relaxed throughput",

No, not the throughput is relaxed, the requirements are.
Sentence can stay as is.

>   but it still seems a bit affected to me.  "Limited bandwidth"
>   seems a bit more direct, (but I warned earlier that this is the
>   diction section...)
>
> 2. "Overview", Sixth Bullet
>
>   "Limited processing power, limited memory, etc." might read better
>   than "low processing, low memory, etc."  I might also delete the
>   last sentence -- it doesn't really add much.

I find it useful to remind readers that Moore's law does apply.

> 2. "Overview", Ninth Bullet
>
>   This bullet seems to munge two ideas together: that connectivity
>   may be unreliable and that devices may be be unreliable.  The
>   bullet might read better if the ideas were stated separately,
>   or maybe if the bullet focused on connectivity rather than devices.

In the old Internet, the assumption was that devices were allowed to  
fail, but shouldn't too often.
In a LowPAN, the tradeoffs shift towards unreliable devices -- for  
the purposes of LowPAN, it does not make a big difference whether  
somebody steps on it or it just loses connectivity.

> 2. "Overview", Tenth Bullet
>
>   Perhaps, "In many environments, devices connected to a LoWPAN
>   may sleep for long periods of time in order to conserve energy,
>   and are unable to communicate during these sleep periods."

Good new text.

> 3. "Assumptions", Bullets
>
>   I  might focus on the assumption that using IP technologies will
>   simplify the interconnection of 802.15.4 networks and IP networks.
>   This is sort of what the last paragraph says, my quibbles about
>   the claim that a gateway won't exist notwithstanding.
>
>   I don't really understand what the first bullet is trying to say.
>   Perhaps, it would be more clear if a few examples were provided.

It is trying to say that IP is already available in most  
environments, so it helps to use it.

>   I have some question about how applicable the fourth bullet is.
>   Will I be able to ping a LoWPAN device?  Send it an SNMP GET?
>   (This is where I will say that it would make a lot more sense
>   for the we-can't-call-it-a-gateway to respond to these requests
>   for the LoWPAN device.)

The intention is that the LowPAN devices are IP nodes, with all that  
implies.  A "gateway" that "helpfully" generates fake ICMP replies is  
not always going to help.  (But, yes, optimizations are possible.)

> Section 4.2, "Topologies", Fourth Bullet
>
>   The notion that many LoWPAN devices will sleep much of the time
>   is a very important idea.  I would either make this the focus of
>   the bullet, (e.g., move this sentence to the beginning of the
>   bullet) or add a separate bullet that mentions it.

I read this bullet as saying exactly that.

> Section 4.2, "Topologies", Last Paragraph
>
>   This is a very important paragraph.  Many of my comments try to
>   emphasize the idea that we want to seamlessly integrate 802.15.4
>   networks with IP networks.

Actually, we integrate them *into* IP networks.
(This is a BIG difference.)

> However, this idea currently seems
>   to be buried in this discussion of topologies.

Yes, again, if we had lots of time and editorial manpower, we could  
make this a better document.
But the consensus of the WG is appropriately caught.

> Section 5, "Goals", Fourth Bullet
>
>   "Ad hoc" is two words.

I'd prefer Ad-hoc (still two words) in the adjective position.

> (OK, OK, this is pretty minor, but
>   ad hoc networks are so closely related to this work that we at
>   least ought to spell their name correctly...)
>
> Section 5, "Goals", Seventh Bullet
>
>   This is a very interesting topic.  I don't know whether we want
>   to suggest changes to verbose higher-layer protocols or simply
>   say "don't do that".  (When reviewing a specification document
>   for a system that was going to operate in a wireless environment,
>   I finally gave up and simply said, "just globally replace all
>    instances of "XML good" with "XML bad".)

True, this is not something the format document can do on its own.
Further work will be required, and this may take both forms  
(simplifying or replacing existing protocols).
I agree this bullet is rather nebulous, but so is our understanding  
of our goals in this space.


In summary, I think there is some good editorial input here (thanks  
Tim!), but I don't see any reason to reopen discussion on existing  
consensus.
Depending on how we proceed with the most recent input on the format  
document, we may have time to incorporate that input.

(Chair hat on.)
I would prefer to do this in a way that does not require a new WGLC  
(i.e., editorial only).

Gruesse, Carsten


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Wed Nov 08 13:46:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhsRA-0005BL-Gh; Wed, 08 Nov 2006 13:46:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhsR9-0005BF-JS
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 13:46:11 -0500
Received: from wx-out-0506.google.com ([66.249.82.230])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhsR7-0008Dn-DW
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 13:46:11 -0500
Received: by wx-out-0506.google.com with SMTP id t4so1878200wxc
	for <6lowpan@lists.ietf.org>; Wed, 08 Nov 2006 10:46:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=cC6CAMFxOkRDMnA6hMC3RHsJw6enRgIPCrOnsU2xMvSnVkDMlfaC18aPte3YPjzkgWQGp1UaD0sF3nqk8wVGHSRl97JXf8gbDOjPjwiYiPZS5Oekz8G06o/4z5hYk0madI83X9WMIHLWEA47m6b7B2VDTSW03KVuoAg264GlfvY=
Received: by 10.70.117.3 with SMTP id p3mr9965869wxc.1163011568995;
	Wed, 08 Nov 2006 10:46:08 -0800 (PST)
Received: by 10.70.27.11 with HTTP; Wed, 8 Nov 2006 10:46:08 -0800 (PST)
Message-ID: 
Date: Thu, 9 Nov 2006 03:46:08 +0900
From: "Soohong Daniel Park" 
To: "Carsten Bormann" 
Subject: Re: [6lowpan] Problem Statement Comments
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <454FD596.8020605@saloits.com>
	
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: 6lowpan@lists.ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

Just catching up with the sentence below:

> (Chair hat on.)
> I would prefer to do this in a way that does not require a new WGLC
> (i.e., editorial only).

Don't need to solicit a new WGLC. IESG will solicit IETF LC on the
IETF announcement, then we will be able to speak up if some issues
happen in our mind.

So, I agree with chairs' opinion at this stage.

Thanks,

-- 


Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Wed Nov 08 15:50:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhuNJ-0000hL-9c; Wed, 08 Nov 2006 15:50:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhuN1-0000eE-AN
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 15:50:03 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhuN0-0002PQ-Ke
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 15:50:03 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1DC4826E47;
	Wed,  8 Nov 2006 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GhuMz-0000yO-RR; Wed, 08 Nov 2006 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Wed, 08 Nov 2006 15:50:01 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: 6lowpan@lists.ietf.org
Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-format-06.txt 
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the IPv6 over Low power WPAN Working Group of the IETF.

	Title		: Transmission of IPv6 Packets over IEEE 802.15.4 Networks
	Author(s)	: G. Montenegro, N. Kushalnagar
	Filename	: draft-ietf-6lowpan-format-06.txt
	Pages		: 29
	Date		: 2006-11-8
	
This document describes the frame format for transmission of IPv6
   packets and the method of forming IPv6 link-local addresses and
   statelessly autoconfigured addresses on IEEE 802.15.4 networks.
   Additional specifications include a simple header compression scheme
   using shared context and provisions for packet delivery in IEEE
   802.15.4 meshes.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-6lowpan-format-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-6lowpan-format-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-11-8133536.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-6lowpan-format-06.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-6lowpan-format-06.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-11-8133536.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--NextPart--





From 6lowpan-bounces@ietf.org Wed Nov 08 16:19:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhuoV-0003jY-WB; Wed, 08 Nov 2006 16:18:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhuoU-0003jO-U8
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 16:18:26 -0500
Received: from maily.danfoss.com ([193.162.34.7])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhuoS-0003zz-IY
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 16:18:26 -0500
Received: from DKDN04MX62.dkdn04.danfoss.net ([10.6.2.62]) by
	maily.danfoss.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 8 Nov 2006 22:18:44 +0100
Received: from dkdn01mx21.danfoss.net ([10.12.129.21]) by
	DKDN04MX62.dkdn04.danfoss.net with InterScan Message Security
	Suite; Wed, 08 Nov 2006 22:18:44 +0100
Received: from DKDN01MX34.danfoss.net ([10.12.128.14]) by
	dkdn01mx21.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 8 Nov 2006 22:18:43 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [6lowpan] I-D ACTION:draft-ietf-6lowpan-format-06.txt 
Date: Wed, 8 Nov 2006 22:18:21 +0100
Message-ID: <49A38D2FE2C53946A57916AD6A1F00D7A8EFD2@DKDN01MX34.danfoss.net>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [6lowpan] I-D ACTION:draft-ietf-6lowpan-format-06.txt 
Thread-Index: AccDd9xyd2zME9QyTT+9YCrcaQlTOQAA0oDg
From: "Schumacher Christian Peter Pii" 
To: <6lowpan@lists.ietf.org>
X-OriginalArrivalTime: 08 Nov 2006 21:18:43.0488 (UTC)
	FILETIME=[7824B200:01C7037B]
X-TM-AS-Product-Ver: SMEX-7.0.0.1526-3.5.1048-14800.000
X-TM-AS-Result: No--17.394000-4.000000-1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: 
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

6lowpanners.
Please note, this "old" draft doesn't include the proposal from Arch
Rock.

-Christian


-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20
Sent: 8. november 2006 21:50
To: i-d-announce@ietf.org
Cc: 6lowpan@lists.ietf.org
Subject: [6lowpan] I-D ACTION:draft-ietf-6lowpan-format-06.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts=20
directories.
This draft is a work item of the IPv6 over Low power WPAN Working Group
of the IETF.

	Title		: Transmission of IPv6 Packets over IEEE
802.15.4 Networks
	Author(s)	: G. Montenegro, N. Kushalnagar
	Filename	: draft-ietf-6lowpan-format-06.txt
	Pages		: 29
	Date		: 2006-11-8
=09
This document describes the frame format for transmission of IPv6
   packets and the method of forming IPv6 link-local addresses and
   statelessly autoconfigured addresses on IEEE 802.15.4 networks.
   Additional specifications include a simple header compression scheme
   using shared context and provisions for packet delivery in IEEE
   802.15.4 meshes.

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

To remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request@ietf.org with the word unsubscribe in the body of=20
the message.=20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the=20
username "anonymous" and a password of your e-mail address. After=20
logging in, type "cd internet-drafts" and then=20
"get draft-ietf-6lowpan-format-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-6lowpan-format-06.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Wed Nov 08 16:27:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ghuwq-0006M5-Qr; Wed, 08 Nov 2006 16:27:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghuwq-0006L7-1O
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 16:27:04 -0500
Received: from maily.danfoss.com ([193.162.34.7])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghuwo-0006FB-Ch
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 16:27:04 -0500
Received: from DKDN04MX64.dkdn04.danfoss.net ([10.6.2.64]) by
	maily.danfoss.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 8 Nov 2006 22:27:22 +0100
Received: from dkdn01mx22.danfoss.net ([10.12.129.22]) by
	DKDN04MX64.dkdn04.danfoss.net with InterScan Message Security
	Suite; Wed, 08 Nov 2006 22:27:22 +0100
Received: from DKDN01MX34.danfoss.net ([10.12.128.14]) by
	dkdn01mx22.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 8 Nov 2006 22:27:21 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [6lowpan] Problem Statement Comments
Date: Wed, 8 Nov 2006 22:26:59 +0100
Message-ID: <49A38D2FE2C53946A57916AD6A1F00D7A8EFD6@DKDN01MX34.danfoss.net>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [6lowpan] Problem Statement Comments
Thread-Index: AccDZopfb7FA0fS8SbW0P1voXjblOwAFOXLA
From: "Schumacher Christian Peter Pii" 
To: <6lowpan@lists.ietf.org>
X-OriginalArrivalTime: 08 Nov 2006 21:27:21.0876 (UTC)
	FILETIME=[AD206D40:01C7037C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: Carsten Bormann 
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

6lowpanners.

I've made an editorial update of the problem document based on
post-Last-Call comments and put the it on the wiki (6lowpan.tzi.org).=20

I would to like emphasize that this is only an editorial update and
hopefully shouldn't void conesensus.

Regards
Christian


-----Original Message-----
From: Soohong Daniel Park [mailto:soohongp@gmail.com]=20
Sent: 8. november 2006 19:46
To: Carsten Bormann
Cc: 6lowpan@lists.ietf.org
Subject: Re: [6lowpan] Problem Statement Comments

Just catching up with the sentence below:

> (Chair hat on.)
> I would prefer to do this in a way that does not require a new WGLC
> (i.e., editorial only).

Don't need to solicit a new WGLC. IESG will solicit IETF LC on the
IETF announcement, then we will be able to speak up if some issues
happen in our mind.

So, I agree with chairs' opinion at this stage.

Thanks,

--=20


Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Wed Nov 08 19:12:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhxWo-0005sR-QM; Wed, 08 Nov 2006 19:12:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhxWo-0005rv-3C
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 19:12:22 -0500
Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhxWm-000494-KH
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 19:12:22 -0500
Received: from [127.0.0.1] (dhcp69-130.ietf67.org [130.129.69.130])
	by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id kA90C2iv076915;
	Wed, 8 Nov 2006 18:12:17 -0600 (CST) (envelope-from salo@saloits.com)
Message-ID: <45527247.3060808@saloits.com>
Date: Wed, 08 Nov 2006 18:11:51 -0600
From: "Timothy J. Salo" 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Carsten Bormann 
References: <454FD596.8020605@saloits.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: 6lowpan@lists.ietf.org
Subject: [6lowpan] adhoc/ad-hoc/ad hoc
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

Carsten Bormann wrote:
>>   "Ad hoc" is two words.
> 
> I'd prefer Ad-hoc (still two words) in the adjective position.

I also prefer a few things that are considered incorrect, at least
by standard American English, (e.g., I really think that punctuation
should generally follow the closing quote mark, rather than precede
it). However, I believe that it can quite reasonably be argued
"ad-hoc" is, in fact, wrong.

o	It conflicts with common [American] usage.

o	It conflicts with common IETF and research community
	usage, (although I believe that we have a least one RFC
	that presents a unique opinion about which bit is "bit 0",
	so maybe this isn't a strong argument...)

o	While I really like hyphens, I don't believe that
	introducing a hyphen in "ad hoc" reduces ambiguity,
	(which I think is the primary motivation for using
	hyphens in compound adjectives).

o	I don't carry a good dictionary when I travel, but I am
	pretty sure that current dictionaries say "ad hoc".
	I also understand that the dictionary punctuation takes
	precedence over more generation hyphenation rules.

o	I also don't carry a style manual when I travel, but I
	think that [American] hyphenation rules include a special
	clause for things like "ad hoc", (which says that they
	don't get hyphenated.

More than you every wanted to know,

-tjs


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Wed Nov 08 19:26:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhxkO-00068B-L9; Wed, 08 Nov 2006 19:26:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhxkN-00065H-0D
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 19:26:23 -0500
Received: from mailhost.informatik.uni-bremen.de
	([2001:638:708:30c9:209:3dff:fe00:7136]
	helo=informatik.uni-bremen.de)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhxkK-0006W8-Uu
	for 6lowpan@lists.ietf.org; Wed, 08 Nov 2006 19:26:22 -0500
Received: from [127.0.0.1] (maildrop [134.102.201.19])
	by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id
	kA90QGnW012248; Thu, 9 Nov 2006 01:26:17 +0100 (CET)
In-Reply-To: <45527247.3060808@saloits.com>
References: <454FD596.8020605@saloits.com>
	
	<45527247.3060808@saloits.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5F1809B7-E448-4B69-A00C-8D20BC7AD6E0@tzi.org>
Content-Transfer-Encoding: 7bit
From: Carsten Bormann 
Subject: Re: [6lowpan] adhoc/ad-hoc/ad hoc
Date: Wed, 8 Nov 2006 16:26:14 -0800
To: "Timothy J. Salo" 
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4
Cc: Carsten Bormann , 6lowpan@lists.ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

The RFC editor will sort this one out.

Gruesse, Carsten


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Thu Nov 09 12:18:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiDY1-0004S0-AW; Thu, 09 Nov 2006 12:18:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDY0-0004Rv-Kx
	for 6lowpan@lists.ietf.org; Thu, 09 Nov 2006 12:18:40 -0500
Received: from wx-out-0506.google.com ([66.249.82.234])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiDXz-0001Ka-Bz
	for 6lowpan@lists.ietf.org; Thu, 09 Nov 2006 12:18:40 -0500
Received: by wx-out-0506.google.com with SMTP id h29so244160wxd
	for <6lowpan@lists.ietf.org>; Thu, 09 Nov 2006 09:18:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=CwJ+n5Ofqnc6ehIyT5nhpBvvYBXyiQdy9Qbxr4pm5n93pUKMxSvsfUPEeb33V53IH7UBnZRUuIlAfTS4l9o+PHSU3+64FkaNPhWXBuxyKdmWy2fZTANsVowOIdzxYzMriecpe881UPU/gg0HJxsFFtZ3ZS5kFgukoHXg5qAsHbc=
Received: by 10.70.21.4 with SMTP id 4mr1099419wxu.1163092716691;
	Thu, 09 Nov 2006 09:18:36 -0800 (PST)
Received: by 10.70.27.11 with HTTP; Thu, 9 Nov 2006 09:18:36 -0800 (PST)
Message-ID: 
Date: Fri, 10 Nov 2006 02:18:36 +0900
From: "Daniel Park" 
To: "Shoichi Sakane" 
Subject: Re: [6lowpan] comment about 6lowpan-security-analysis
In-Reply-To: <4551AEEF.5000308@tanu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4551AEEF.5000308@tanu.org>
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Cc: 6lowpan@lists.ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

Shoichi,

Sorry for the delay.

> I read draft-daniel-6lowpan-security-analysis-01.txt.  I believe that
> this activity is valuable to clarify the security problem for 6LoWPAN.
> I thank the authors.  I would like to cooperate with the work as much as
> I can.  At first, I have some comments in the section 7.2.

Thanks, and highly welcome.

> >>   Basically, IPsec targets to general IP nodes operated over ethernet.
>
> It seems questionable.  I believe that it does not assume always using
> over ethernet.

That's why I added *Basically* into the sentence. Your concern will be
clarified later if necessary of course.

> >>   It means each node has some of fluent stack size, bandwidth and non-
> >>   low cost limitations like 6lowpan.
>
> IPsec basically is based on symmetric cryptography.  This sentence is
> only correct for some key mangement protocols to establish the keys,
> like IKE.  I believe that KINK is suitable in term of power consumption.
> Bandwidth consumption was not considered in both cases.

Good suggestion if KINK is feasible for the 6lowpan security. Can you
more elaborate on that ? Especially, what gaps between IKE and KINK
and why you are thinking KINK is suitable in 6lowpan...

> >>   Given the IPsec background, it is at least not suitable for 6lowpan
> >>   nodes.  Especially, 6lowpan node may not be able to operate all IPsec
> >>   algorithms on its own capability either FFD or RFD.
>
> It is not needed to support all of likely algorithms of IPsec.  Algorithm
> to be implemented for interoperability can be reduced according to RFC4305.
> And RFC4309 defines how to use AES-CCM with IPsec so that a stack size might
> be reduced because IEEE 802.15.4 does include AEC-CCM.

As long as we write this document, I lean to a general case. Then, we
will deeply investigate what algorithms can be used for the 6lowpan
security accordingly. But, good suggestion.

> >>   Bandwidth is very sensitive element in the 6lowpan, but IPsec
> >>   generates some of redundant packets such as AH/ESP header.
>
> RFC4301 defined that AH is no longer mandated to implement.
> I believe that we use just ESP to protect from almost 6LoWPAN threats.
> However it is needed to investigate each threat if we do not need AH.
> If we need ESP with AES-CCM, the packet size increases 32 bytes.
>        4 bytes for SPI.
>        4 bytes for sequence number as no ESN.
>        8 bytes for IV.
>        6 bytes for padding in minimum.
>        1 bytes for pad length.
>        1 bytes for next header.
>        8 bytes for ICV.
>
> Multiple security association between a 6lowpan node and different end
> points make packet sizes increase.  However I do not think such usage
> is not suitable for a 6lowpan node.  such usage is not realistic even
> for a full function devices like PC.

Agreed, as I pointed out, we will have further in-depth discussion
when working on the 6lowpan security solution later.

> >>   IPsec needs shared secret key between nodes called IKE (Internet Key
> >>   Exchange), and it will make the key exchange in secrecy possible.  It
> >>   can, however cause some of redundant packets over the 6lowpan
> >>   networks.
>
> Need a minor fix.  IKE is a protocol to establish such keys securely,
> not secret keys.

Agreed,

> And packets for key exchange is not redundant.  They are obviously necessary
> to establish keys even if any method except manual keying are applied.
> However, for low computaional power devices, IKE requires much power to
> process asymmetric cryptography.  Indeed, a certain algorithm like ECC or
> XTR can save power.  But it might not be still suitable for a 6lowpan devices.

Shoichi, your all comments are really acceptable and reasonable. Given
the WG opinion, we will work on the 6lowpan security solution as well
as analysis later.

Now, we are focusing on the basic stuff as 6lowpan format, so let me
stick to this work entirely for a while. Then I will get back to you
with more details regarding 6lowpan security stuffs. But, don't
hesitate to contact me if you have any comments on the 6lowpan
security works.

Obviously, I believe we should work on the 6lowpan security in the 2nd round.

Thanks and keep in touch.

-- 


Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Fri Nov 10 02:56:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiRFK-0001JU-2M; Fri, 10 Nov 2006 02:56:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiRFI-0001JO-7Z
	for 6lowpan@ietf.org; Fri, 10 Nov 2006 02:56:16 -0500
Received: from agp.stanford.edu ([171.67.73.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiRFG-0002xk-RP
	for 6lowpan@ietf.org; Fri, 10 Nov 2006 02:56:16 -0500
Received: from cs-smtp-1.stanford.edu ([172.24.64.20] helo=agp.Stanford.EDU)
	by agp.stanford.edu with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.43)
	id 1GiRFG-0007Cx-CD
	for 6lowpan@ietf.org; Thu, 09 Nov 2006 23:56:14 -0800
Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178]
	helo=[192.168.2.101])
	by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.60) (envelope-from ) id 1GiRFD-0001Ft-6J
	for 6lowpan@ietf.org; Thu, 09 Nov 2006 23:56:13 -0800
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Transfer-Encoding: 7bit
Message-Id: <1F39EE23-1599-446B-89FD-5B3F6730D3BF@cs.stanford.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: 6lowpan@ietf.org
From: Philip Levis 
Date: Thu, 9 Nov 2006 23:56:10 -0800
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: -4.0
X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on
	cs-smtp-1.Stanford.EDU
X-Scan-Signature: fba5d1bf4e2735531ca2f657cf1136db
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Subject: [6lowpan] minimalist processing code
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

Here's some minimal protocol processing code for the proposed format.  
I elided details that would be in the existing format (such as HC1  
parsing). I would not be surprised if there is a bug or two. I've  
done it in C for simplicity's sake. But overall the parsing seems  
pretty easy. The only tricky bit is deciding when to continue parsing  
header fields (mesh) and when not (fragment). Comments/feedback welcome.

typedef nx_struct message {
   cc2420_header_t hdr;
   uint8_t data[0];
} message_t;

typedef ((void)(*)(message_t*, uint8_t*, uint8_t)) proto_process_t;

// Initialize with proper protocol processing functions, be sure
// to stick null handler in for unhandled protocols
proto_process_t parse_proto[128];

parse_proto[0x01] is just parsing IPv6
parse_proto[0x02] is just parsing HC1
parse_proto[0x10] is just parsing BC0
parse_proto[0x7f] just calls alternative dispatch function array (if  
exists)

void parse_fragment(message_t* packet, uint8_t* payload, uint8_t len) {
   uint16_t tag;
   uint16_t size;
   uint16_t offset;
   tag = (payload[0] & 0x1f) << 5;
   tag |= (payload[1] & 0xf8) >> 3;
   size = (payload[1] & 0x7) << 8;
   size |= payload[2];

   if (payload[0] & 0xe == 0xe) {
      offset = payload[3];
      payload = payload + 4;
   }
   else {
      offset = 0;
      payload = payload + 3;
   }

   // do reassembly here, if you want to...
   // check header ordering: don't have mesh within
}

uint64_t longO;
uint64_t longF;
uint16_t shortO;
uint16_t shortF;

void parse_mesh(message_t* packet, uint8_t* payload, uint8_t len) {
   // more robust implementation would check that we don't walk off
   // the end of a malicious packet by ensuring payload never grows
   // to more than payload + len

   // would also need to keep bits on whether we are using long
   // or short addresses, elided for clarity

   uint8_t oBit = payload[0] & 0x20;
   uint8_t fBit = payload[0] & 0x10;
   uint8_t hopsLeft = payload[0] & 0xf;
   payload = payload + 1;

   if (hopsLeft == 0xf) {
     hopsLeft = payload[0];
     payload = payload + 1;
     len--;
   }

   hopsLeft--;

   if (oBit) {
     memcpy(&longO, payload, 8);
     payload += 8;
     len -= 8;
   }
   else {
     memcpy(&shortO, payload, 2);
     payload += 2;
     len -= 2;
   }
   if (fBit) {
     memcpy(&longF, payload, 8);
     payload += 8;
     len -= 8;
   }
   else {
     memcpy(&shortF, payload, 2);
     payload += 2;
     len -= 2;
   }
   // Store addresses and hopsLeft in temporary storage for protocol
   // processing
   parse_packet(packet, payload, len);
}

void parse_packet(message_t* packet, uint8_t* payload, uint8_t len) {
   if (len == 0) {return;}

   uint8_t dispatch = payload[0];
   if (dispatch & 0xc == 0xc) {
     parse_fragment(packet, payload, len);
   }
   else if (dispatch & 0x8) {
     parse_mesh(packet, payload, len);
   }
   else {
     parse_proto[dispatch](packet, payload + 1, len - 1);
   }
}


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Fri Nov 10 14:25:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gic0L-0002sO-Jo; Fri, 10 Nov 2006 14:25:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gic0K-0002rG-Cc
	for 6lowpan@ietf.org; Fri, 10 Nov 2006 14:25:32 -0500
Received: from wx-out-0506.google.com ([66.249.82.236])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GibzV-0004VZ-Ok
	for 6lowpan@ietf.org; Fri, 10 Nov 2006 14:24:44 -0500
Received: by wx-out-0506.google.com with SMTP id h29so597542wxd
	for <6lowpan@ietf.org>; Fri, 10 Nov 2006 11:24:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=TamwT3hkltPe88u1PPIPJXdkLYLXkBb8BVbv9BTJ0aIgr22JK/OavNQTJin5nOSXm3yWKh9sfbIeva5BTrzspuLXXh/zNdtYqsqMw9eFWUZertGdnCktLdlF3Dp/V6tBupN8EfRWBEpTX+lA1ihzgFZcvZHqC+KYC7NwVgTpxv4=
Received: by 10.70.38.12 with SMTP id l12mr3633924wxl.1163186681261;
	Fri, 10 Nov 2006 11:24:41 -0800 (PST)
Received: by 10.70.27.11 with HTTP; Fri, 10 Nov 2006 11:24:41 -0800 (PST)
Message-ID: 
Date: Sat, 11 Nov 2006 04:24:41 +0900
From: "Daniel Park" 
To: "Philip Levis" 
Subject: Re: [6lowpan] minimalist processing code
In-Reply-To: <1F39EE23-1599-446B-89FD-5B3F6730D3BF@cs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1F39EE23-1599-446B-89FD-5B3F6730D3BF@cs.stanford.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Cc: 6lowpan@ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

Philip,

Good job. Also, I'd encourage other guys implementing the previous
format to post their processing code on this list if allowed. That
would be very helpful for the 6lowpan folks to compare them.

Anyway, frankly speaking, I don't have any preference either the
previous format or the new one. Instead, I'd encourage the 6lowpan WG
to select ONE solution for further deployment quickly. Simplicity is
the best way for the success I believe.

Please speed up. Otherwise, we can lose our change in the market.

Cheers,

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.



On 11/10/06, Philip Levis  wrote:
> Here's some minimal protocol processing code for the proposed format.
> I elided details that would be in the existing format (such as HC1
> parsing). I would not be surprised if there is a bug or two. I've
> done it in C for simplicity's sake. But overall the parsing seems
> pretty easy. The only tricky bit is deciding when to continue parsing
> header fields (mesh) and when not (fragment). Comments/feedback welcome.
>
> typedef nx_struct message {
>   cc2420_header_t hdr;
>   uint8_t data[0];
> } message_t;
>
> typedef ((void)(*)(message_t*, uint8_t*, uint8_t)) proto_process_t;
>
> // Initialize with proper protocol processing functions, be sure
> // to stick null handler in for unhandled protocols
> proto_process_t parse_proto[128];
>
> parse_proto[0x01] is just parsing IPv6
> parse_proto[0x02] is just parsing HC1
> parse_proto[0x10] is just parsing BC0
> parse_proto[0x7f] just calls alternative dispatch function array (if
> exists)
>
> void parse_fragment(message_t* packet, uint8_t* payload, uint8_t len) {
>   uint16_t tag;
>   uint16_t size;
>   uint16_t offset;
>   tag = (payload[0] & 0x1f) << 5;
>   tag |= (payload[1] & 0xf8) >> 3;
>   size = (payload[1] & 0x7) << 8;
>   size |= payload[2];
>
>   if (payload[0] & 0xe == 0xe) {
>      offset = payload[3];
>      payload = payload + 4;
>   }
>   else {
>      offset = 0;
>      payload = payload + 3;
>   }
>
>   // do reassembly here, if you want to...
>   // check header ordering: don't have mesh within
> }
>
> uint64_t longO;
> uint64_t longF;
> uint16_t shortO;
> uint16_t shortF;
>
> void parse_mesh(message_t* packet, uint8_t* payload, uint8_t len) {
>   // more robust implementation would check that we don't walk off
>   // the end of a malicious packet by ensuring payload never grows
>   // to more than payload + len
>
>   // would also need to keep bits on whether we are using long
>   // or short addresses, elided for clarity
>
>   uint8_t oBit = payload[0] & 0x20;
>   uint8_t fBit = payload[0] & 0x10;
>   uint8_t hopsLeft = payload[0] & 0xf;
>   payload = payload + 1;
>
>   if (hopsLeft == 0xf) {
>     hopsLeft = payload[0];
>     payload = payload + 1;
>     len--;
>   }
>
>   hopsLeft--;
>
>   if (oBit) {
>     memcpy(&longO, payload, 8);
>     payload += 8;
>     len -= 8;
>   }
>   else {
>     memcpy(&shortO, payload, 2);
>     payload += 2;
>     len -= 2;
>   }
>   if (fBit) {
>     memcpy(&longF, payload, 8);
>     payload += 8;
>     len -= 8;
>   }
>   else {
>     memcpy(&shortF, payload, 2);
>     payload += 2;
>     len -= 2;
>   }
>   // Store addresses and hopsLeft in temporary storage for protocol
>   // processing
>   parse_packet(packet, payload, len);
> }
>
> void parse_packet(message_t* packet, uint8_t* payload, uint8_t len) {
>   if (len == 0) {return;}
>
>   uint8_t dispatch = payload[0];
>   if (dispatch & 0xc == 0xc) {
>     parse_fragment(packet, payload, len);
>   }
>   else if (dispatch & 0x8) {
>     parse_mesh(packet, payload, len);
>   }
>   else {
>     parse_proto[dispatch](packet, payload + 1, len - 1);
>   }
> }
>
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan
>

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Thu Nov 16 10:54:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GkjYp-0005ag-HC; Thu, 16 Nov 2006 10:53:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GkjYo-0005Yb-3d
	for 6lowpan@ietf.org; Thu, 16 Nov 2006 10:53:54 -0500
Received: from mailhost.informatik.uni-bremen.de
	([2001:638:708:30c9:209:3dff:fe00:7136]
	helo=informatik.uni-bremen.de)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkjYY-0006NE-Ft
	for 6lowpan@ietf.org; Thu, 16 Nov 2006 10:53:54 -0500
Received: from [127.0.0.1] (maildrop [134.102.201.19])
	by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id
	kAGFrQbf028242; Thu, 16 Nov 2006 16:53:26 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <890F8F1A-5765-4760-AA67-6D2F918271DE@tzi.org>
Content-Transfer-Encoding: 7bit
From: Carsten Bormann 
Date: Thu, 16 Nov 2006 16:53:22 +0100
To: 6lowpan@ietf.org
X-Mailer: Apple Mail (2.752.2)
X-Virus-Scanned: by amavisd-new
X-Spam-Score: -2.8 (--)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: Carsten Bormann 
Subject: [6lowpan] Minutes, and,
	New encoding proposal: Review of format-d1115 required
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: 6lowpan-bounces@ietf.org

Lowpanners,

I have put a draft version of the meeting minutes on the meeting  
materials manager:

    http://www.ietf.org/proceedings/06nov/minutes/6lowpan.txt

At the meeting, we decided to use up to two months for working on the  
new encoding proposal.
The first milestone was a full draft, which was submitted yesterday  
by the authors.
I have put this ("format-d1115.txt") up together with a reminder on  
the milestones we are trying to keep:

    http://6lowpan.tzi.org/NewEncoding

Please review the draft available at this place and send your review  
to the WG mailing list (i.e., here) by Nov 22nd.

(This is not a WG last-call, but we do need your review by next week  
in order to be able to decide whether to continue with the new  
proposal or revert to the WGLC'ed one.)

Gruesse, Carsten

PS.: The draft will also be submitted to the I-D archives to follow  
procedure.  As we have not yet decided to adopt the proposal, this  
will progress as an individual contribution until we decide to adopt  
it as the WG document, which would then be format-07.


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan



From 6lowpan-bounces@ietf.org Wed Nov 29 15:48:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GpWLV-0000XA-3Q; Wed, 29 Nov 2006 15:47:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWLT-0000Va-H6
	for 6lowpan@ietf.org; Wed, 29 Nov 2006 15:47:55 -0500
Received: from maily.danfoss.com ([193.162.34.7])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpWLS-0002oI-85
	for 6lowpan@ietf.org; Wed, 29 Nov 2006 15:47:55 -0500
Received: from DKDN04MX62.dkdn04.danfoss.net ([10.6.2.62]) by
	maily.danfoss.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 29 Nov 2006 21:47:49 +0100
Received: from dkdn01mx21.danfoss.net ([10.12.129.21]) by
	DKDN04MX62.dkdn04.danfoss.net with InterScan Message Security
	Suite; Wed, 29 Nov 2006 21:47:48 +0100
Received: from DKDN01MX34.danfoss.net ([10.12.128.14]) by
	dkdn01mx21.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 29 Nov 2006 21:47:48 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 29 Nov 2006 21:47:48 +0100
Message-ID: <49A38D2FE2C53946A57916AD6A1F00D7139378@DKDN01MX34.danfoss.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: format document on the wiki
Thread-Index: AccT96DzgyAMvnVXSIG7LcJ5UCZtiA==
From: "Schumacher Christian Peter Pii" 
To: <6lowpan@ietf.org>
X-OriginalArrivalTime: 29 Nov 2006 20:47:48.0791 (UTC)
	FILETIME=[A1552470:01C713F7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: cabo@tzi.org
Subject: [6lowpan] format document on the wiki
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks
	<6lowpan.ietf.org>
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1699409743=="
Errors-To: 6lowpan-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1699409743==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C713F7.A125426E"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C713F7.A125426E
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Lowpanners.

Does anyone have comments for the format document on the wiki?

Are the current implementers happy with this draft?

Please speak up.

Regards
Christian

------_=_NextPart_001_01C713F7.A125426E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




format document on the wikiDear Lowpanners.



Does anyone have comments for the format document on the wiki?



Are the current implementers happy with this draft?



Please speak up.



Regards

Christian




------_=_NextPart_001_01C713F7.A125426E--


--===============1699409743==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

--===============1699409743==--