From pars.mutaf@gmail.com Sat Aug 1 03:38:27 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95AAB3A6907 for <6lowpan@core3.amsl.com>; Sat, 1 Aug 2009 03:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIwsktNy5aXp for <6lowpan@core3.amsl.com>; Sat, 1 Aug 2009 03:38:26 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 06B503A63CB for <6lowpan@ietf.org>; Sat, 1 Aug 2009 03:38:25 -0700 (PDT) Received: by ewy10 with SMTP id 10so2023992ewy.37 for <6lowpan@ietf.org>; Sat, 01 Aug 2009 03:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RjL+LlKSYXF8G3VsRJraj1lkvfxqpRy/3NCYNGQ4PLk=; b=DSlX1C79Yz9LdnRUD0QAY7ZwcqZAZoZISZFYqJ/Ocm+myAXfSgBfD2bOuejNFWr+TS rkdWY3owK6xJ1XexxblS+5orIq6ndOYxq3C6fc+zE+FS4Nn47r0aHZTlGG65ZK93LP7X Worgs277HDb7csyc/3L7LNqDczIzAKFFkxevw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=M13kquqyOIP82sH0zD9dTYaDf+a9NtJ5oFTXORBnXfTwawgd3SuxAcUCHw26TWT/SU q289dBW35cEXDoaQLbuuKqLR/7frNea/7B4lXITe7fLq73gXCJLZ1zbKQk1nUwnZ+WRa YNkDQdQCDQ26WWdGIq92JxfmraQuOiO84yYMs= MIME-Version: 1.0 Received: by 10.210.119.5 with SMTP id r5mr4401625ebc.81.1249123103898; Sat, 01 Aug 2009 03:38:23 -0700 (PDT) In-Reply-To: <4A6D9736.7080700@sensinode.com> References: <18a603a60907160933j48404be5vfdcd2a148d66a873@mail.gmail.com> <4A6D9736.7080700@sensinode.com> Date: Sat, 1 Aug 2009 13:38:23 +0300 Message-ID: <18a603a60908010338u268ff21bq49c7b9b169201b1c@mail.gmail.com> From: Pars Mutaf To: Zach Shelby Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Edge router crash, reboot or new edge router X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 01 Aug 2009 10:38:27 -0000 Hi, On Mon, Jul 27, 2009 at 3:01 PM, Zach Shelby wrote: > Hi Pars, > > Pars Mutaf wrote: > >> I believe understand the motivations behind avoiding broadcast NS messag= es >> upon incoming session. However, what happens if the whiteboard approach >> fails >> i.e. if whiteboard bindings are lost due to edge router crash, reboot >> or changing >> the edge router for whatever administrative reason? > > This is a good question. As whiteboards have soft state, and nodes refres= h > the addresses they are using periodically, a whiteboard failure is not a > disaster to the network. If an Edge Router crashes: > > 1. If the ER reboots without state - the next NR message will refresh the > entries. It could be nice if the LoWPAN somehow knew that this happened > (how?) to avoid waiting up to NR_PERIOD. At least its default route will > stop working, that is an indication. > > 2. If the ER reboots and kept its whiteboard state (recommended) - then o= f > course the ER can't forward on behalf of the node while down. Same for an= y > router, so this isn't a whiteboard problem. > > 3. If the ER goes down permanently, then the node will detect this becaus= e > its default route no longer works or the NR can no longer be sent to the = ER. > It either starts using an alternative ER or continues operating until a n= ew > ER comes on-line. > > In any case the LoWPAN can continue to operate while an ER is down (routi= ng > within the LoWPAN). In an extended LoWPAN nodes will start using alternat= ive > ERs automatically. Several techniques could be used by an ER vendor to > automatically switch state to an alternative ER, use non-volatile memory = for > Whiteboard state, use secondary bindings etc. Using non-volatile memory would solve the problem perhaps. Btw, how much information you can store in non-volatile memory? I think this solution should be explicitly described in the document. This is a major difference from standard neighbor discovery which does not require that neighbor cache state be stored in non-volatile memory. And, I am still not sure that this approach is completely reliable, even with non-volatile memory. What if, for some reason, the node believes that its address was registered, but it is not yet, and incoming packet arrives? This is a race condition. Standard neigbor discovery does not have this problem. In addition, non-volatile memory does not handle the case where the administrator wants to change or upgrade the edge router. In this case whiteboard state would be lost, all idle nodes would be unreachable for NR_PERIOD which should be long for preserving energy. Standard neighbor discovery does not have this problem. What about the following solution? 1. Use standard neighbor discovery. 2. Increase the number of edge routers, i.e. decrease the number of nodes per edge router. This will very much reduce the rate of incoming sessions from the Internet (per edge router) and hence the rate of broadcast Neighbor Solicitations. 3. Increase the neighbor cache lifetime. This will further reduce the Neighbor Solicication rate. Standard neighbor discovery may induce high neighbor solicitation signaling cost, yes. But, this looks like a network management problem to me. Not necessarily a protocol design problem. Regards, pars > > Section 7.9 of nd-04 deals with this partially: > > http://tools.ietf.org/html/draft-ietf-6lowpan-nd-04#section-7.9 > >> A related question: how frequent you believe broadcast NS messages >> (i.e. incoming >> sessions) will be in a 6lowpan network? Or, sessions will be mostly >> initiated by >> 6lowpan nodes? > > We aren't using NS messages at all inside the LoWPAN. Node Registration > messages are always node initiated. > > - Zach > >> Regards, >> >> pars >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > -- > http://www.sensinode.com > http://zachshelby.org - My blog =93On the Internet of Things=94 > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system without > producing, distributing or retaining copies thereof. > From pars.mutaf@gmail.com Sat Aug 1 03:44:06 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53DD3A67EB for <6lowpan@core3.amsl.com>; Sat, 1 Aug 2009 03:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmHNcta9LVMe for <6lowpan@core3.amsl.com>; Sat, 1 Aug 2009 03:44:05 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 9E2A83A69EC for <6lowpan@ietf.org>; Sat, 1 Aug 2009 03:43:54 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so696974eye.31 for <6lowpan@ietf.org>; Sat, 01 Aug 2009 03:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FHCWXUrCK2MNK5Kju6j6+wbepC47xQzR7feTD04zkrI=; b=Is19lcHkay22aiKqF5pTqFvMio7vCrvem74+Wpagwtht/dRjrvmo0kAod6tIr0vDb8 jj/bk1VF398SCbfuFBvU+YgDDJiONMRvkDV22+4zppSO9HrIhe4cv1mOEhZUnoVmNTI6 AThUkyz5NA8CPAjykgiE0bNzc/iDkSiVe5wmA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=F44HOnGZw1XvrXoBI8FIBD3BHXg9P6AwtW/ly5zfKmkal7VImftK6FXeUaamVtaFwQ K49BGJd9oPbAETAXmPVTF/0esuKsUeYEOVXbNJZQyO9BGF/3pOabOfbPQNqTcqHewBGv ohSf9JEpIM4KHPKsa15aWo8p1y+I/52mDNnUo= MIME-Version: 1.0 Received: by 10.211.152.15 with SMTP id e15mr2180993ebo.86.1249123433222; Sat, 01 Aug 2009 03:43:53 -0700 (PDT) In-Reply-To: <4A6D9736.7080700@sensinode.com> References: <18a603a60907160933j48404be5vfdcd2a148d66a873@mail.gmail.com> <4A6D9736.7080700@sensinode.com> Date: Sat, 1 Aug 2009 13:43:53 +0300 Message-ID: <18a603a60908010343q3a6dded9t26790bb3bf20a396@mail.gmail.com> From: Pars Mutaf To: Zach Shelby Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Edge router crash, reboot or new edge router X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 01 Aug 2009 10:44:06 -0000 Hi, On Mon, Jul 27, 2009 at 3:01 PM, Zach Shelby wrote: > Hi Pars, > > Pars Mutaf wrote: > >> I believe understand the motivations behind avoiding broadcast NS messag= es >> upon incoming session. However, what happens if the whiteboard approach >> fails >> i.e. if whiteboard bindings are lost due to edge router crash, reboot >> or changing >> the edge router for whatever administrative reason? > > This is a good question. As whiteboards have soft state, and nodes refres= h > the addresses they are using periodically, a whiteboard failure is not a > disaster to the network. If an Edge Router crashes: > > 1. If the ER reboots without state - the next NR message will refresh the > entries. It could be nice if the LoWPAN somehow knew that this happened > (how?) to avoid waiting up to NR_PERIOD. At least its default route will > stop working, that is an indication. > > 2. If the ER reboots and kept its whiteboard state (recommended) - then o= f > course the ER can't forward on behalf of the node while down. Same for an= y > router, so this isn't a whiteboard problem. > > 3. If the ER goes down permanently, then the node will detect this becaus= e > its default route no longer works or the NR can no longer be sent to the = ER. > It either starts using an alternative ER or continues operating until a n= ew > ER comes on-line. > > In any case the LoWPAN can continue to operate while an ER is down (routi= ng > within the LoWPAN). In an extended LoWPAN nodes will start using alternat= ive > ERs automatically. Several techniques could be used by an ER vendor to > automatically switch state to an alternative ER, use non-volatile memory = for > Whiteboard state, use secondary bindings etc. Using non-volatile memory would solve the problem perhaps. Btw, how much information you can store in non-volatile memory? I think this solution should be explicitly described in the document. This is a major difference from standard neighbor discovery which does not require that neighbor cache state be stored in non-volatile memory. And, I am still not sure that this approach is completely reliable, even with non-volatile memory. What if, for some reason, the node believes that its address was registered, but it is not yet, and incoming packet arrives? This is a race condition. Standard neigbor discovery does not have this problem. In addition, non-volatile memory does not handle the case where the administrator wants to change or upgrade the edge router. In this case whiteboard state would be lost, all idle nodes would be unreachable for NR_PERIOD which should be long for preserving energy. Standard neighbor discovery does not have this problem. What about the following solution? 1. Use standard neighbor discovery. 2. Increase the number of edge routers, i.e. decrease the number of nodes per edge router. This will very much reduce the rate of incoming sessions from the Internet (per edge router) and hence the rate of broadcast Neighbor Solicitations. 3. Increase the neighbor cache lifetime. This will further reduce the Neighbor Solicitation rate. Standard neighbor discovery may induce high neighbor solicitation signaling cost, yes. But, this looks like a network management problem to me. Not necessarily a protocol design problem. Regards, pars > > Section 7.9 of nd-04 deals with this partially: > > http://tools.ietf.org/html/draft-ietf-6lowpan-nd-04#section-7.9 > >> A related question: how frequent you believe broadcast NS messages >> (i.e. incoming >> sessions) will be in a 6lowpan network? Or, sessions will be mostly >> initiated by >> 6lowpan nodes? > > We aren't using NS messages at all inside the LoWPAN. Node Registration > messages are always node initiated. > > - Zach > >> Regards, >> >> pars >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > -- > http://www.sensinode.com > http://zachshelby.org - My blog =93On the Internet of Things=94 > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system without > producing, distributing or retaining copies thereof. > From trac@tools.ietf.org Mon Aug 3 05:45:41 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426143A6D3E for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 05:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wi0sqg8HhnDv for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 05:45:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 8EF543A6C07 for <6lowpan@ietf.org>; Mon, 3 Aug 2009 05:45:40 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MXwv4-0003f7-P7; Mon, 03 Aug 2009 05:45:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: jhui@archrock.com, zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 03 Aug 2009 12:45:38 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/24#comment:1 Message-ID: <069.388fcd7cd7c91e519a2fda2623b2c678@tools.ietf.org> References: <060.56f630ff97fc532f469a4271b1a7afcb@tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <060.56f630ff97fc532f469a4271b1a7afcb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jhui@archrock.com, zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #24: RA periods and Trickle X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 12:45:41 -0000 #24: RA periods and Trickle --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: jhui@archrock.com Type: defect | Status: new Priority: major | Milestone: Component: nd | Version: Severity: - | Resolution: Keywords: | --------------------------------+------------------------------------------- Comment(by zach@sensinode.com): In addition to RA periods, also NR/NC default periods and timeouts need to be defined. Just to clarify, wrt Trickle we only want to mention that such optimizations may be applied for 6LoWPAN-ND. We won't specify Trickle by any means in this document. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 3 05:52:33 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621A03A6DD1 for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 05:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aS0zzUDs1X5g for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 05:52:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id BBD913A6D7B for <6lowpan@ietf.org>; Mon, 3 Aug 2009 05:52:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MXx1n-0005WH-7x; Mon, 03 Aug 2009 05:52:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 03 Aug 2009 12:52:35 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/46 Message-ID: <060.902319ec8a702615fa13c7248867dc4e@tools.ietf.org> X-Trac-Ticket-ID: 46 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #46: M-bit in the RA X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 12:52:33 -0000 #46: M-bit in the RA --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- nd-04 currently redefines the use of the M "Managed" bit to indicate that this router is an ER or has an ER available through it. Several people has found this confusing and would like to keep the original DHCPv6 managed indication for M. This ticket is to change M back to its original meaning (DHCPv6 available). The availability of an ER will instead be encoded into the Prf field. The new Prf field encoding would be: "LoWPAN Routers with no ER available SHOULD set Prf to (00) for low preference, LoWPAN Routers with ER availability SHOULD set Prf to (01) for normal preference, and LoWPAN Edge Routers SHOULD set Prf to (01) for high preference." -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 3 06:00:27 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715AE28C141 for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZCdkbW-A3vS for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:00:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id BCAAB28C16B for <6lowpan@ietf.org>; Mon, 3 Aug 2009 05:58:45 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MXx7n-0005gp-OA; Mon, 03 Aug 2009 05:58:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: jhui@archrock.com, zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 03 Aug 2009 12:58:47 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/47 Message-ID: <060.f40c7d943c73a44f29901bbef0b43cbc@tools.ietf.org> X-Trac-Ticket-ID: 47 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jhui@archrock.com, zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #47: Context improvement X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:00:27 -0000 #47: Context improvement --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: jhui@archrock.com Type: enhancement | Status: new Priority: major | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- In the IETF-75 working group meeting the issue of the CID in the 6LoWPAN Prefix Information Option was brought up. During the IETF the design team found a solution which would clarify the advertisement of Prefix and Context information, which allows CID to be kept in 6LoWPAN-ND. - Separate the Prefix Information and Context Information into separate options. This clarifies what is a prefix and what is context. - Use either the standard RFC4861 Prefix Information Option or an optimized one to save overhead. - Create a new Context Information Option which includes the CID along with the context. Therefore an RA would include a PIO followed by CID options. The use of the Multihop Information Option would remain the same. Work to be performed on the details. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 3 06:09:19 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843763A6AFC for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEyAPbjlI6-E for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:09:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id D71BD3A68F9 for <6lowpan@ietf.org>; Mon, 3 Aug 2009 06:09:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MXxI0-0000D2-Sn; Mon, 03 Aug 2009 06:09:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 03 Aug 2009 13:09:20 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/48 Message-ID: <060.8ef1a86b33678026672bf7d555ba3de4@tools.ietf.org> X-Trac-Ticket-ID: 48 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #48: NR/NC improvements and router state X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:09:19 -0000 #48: NR/NC improvements and router state --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- An enhancement was suggested by Pascal, Jonathan, Richard, Zach wrt NR/NC messages through (relaying) routers. By allowing nodes to send NR messages meant only for the router at a faster interval, slower intervals can be used over multiple hops to the ER. This furthermore makes the state needed on routers more straightforward, and allows routers to implement security mechanisms easier in the future. The changes needed are minimal: - New codes to the NR/NC message. Indicating Request (to ER), Refresh (to Router) or Relayed Request (as is now). - New NC status allowing the router to tell the node to make a request. - Separate Binding Lifetime (for Whiteboard) and Advertisement Interval (for Router). - TID is not incremented upon a refresh to the router. This means that routers would no longer need to keep temporary relay state in-between an NR and an NC. They would instead keep a binding table or currently registered nodes which timees out at e.g. 2.5 * Advertisement Interval. For security reasons routers would only forward for nodes that have registered through them. This also eliminates the need for a neighbor cache in nodes, further simplifying node implementations. -- Ticket URL: 6lowpan From pthubert@cisco.com Mon Aug 3 06:09:38 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407F728C15D for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.176 X-Spam-Level: X-Spam-Status: No, score=-9.176 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkjC4nVodTyb for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:09:34 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DA16828C158 for <6lowpan@ietf.org>; Mon, 3 Aug 2009 06:09:33 -0700 (PDT) X-Files: image002.jpg : 1985 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwAAMJ+dkqQ/uCKe2dsb2JhbACCVZRZgnUBARYkBp53iCmOKgUChBY X-IronPort-AV: E=Sophos;i="4.43,314,1246838400"; d="jpg'145?scan'145,208,217,145";a="46342329" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Aug 2009 13:09:35 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n73D9Y7t002933; Mon, 3 Aug 2009 15:09:34 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n73D9Y61008192; Mon, 3 Aug 2009 13:09:34 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 15:09:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: B2Xl CARY DSQ/ FLru IVCL KpfC PBXb PoLD PwlK RXWe RtWV TiDZ U4qx VPIK Ve1g W5i7; 2; NgBsAG8AdwBwAGEAbgBAAGkAZQB0AGYALgBvAHIAZwA7AHoAYQBjAGgAQABzAGUAbgBzAGkAbgBvAGQAZQAuAGMAbwBtAA==; Sosha1_v1; 7; {68B8BF4C-033F-4030-AA5A-C15146F02081}; cAB0AGgAdQBiAGUAcgB0AEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 03 Aug 2009 13:07:06 GMT; YwBvAG4AZgBsAGkAYwB0ACAAcgBlAHMAbwBsAHUAdABpAG8AbgAgAG8AdgBlAHIAIAB0AGgAZQAgAGIAYQBjAGsAYgBvAG4AZQAgAHcAaQB0AGgAIABTAGUATgBEAA== MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA143B.A572D66C" x-cr-puzzleid: {68B8BF4C-033F-4030-AA5A-C15146F02081} Content-class: urn:content-classes:message Date: Mon, 3 Aug 2009 15:07:06 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07E206C1@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: conflict resolution over the backbone with SeND Thread-Index: AcoUO01RCathkCTzRUCu9nPqUgv+Ng== From: "Pascal Thubert (pthubert)" To: "Zach Shelby" X-OriginalArrivalTime: 03 Aug 2009 13:09:35.0083 (UTC) FILETIME=[A5CDBBB0:01CA143B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12457; t=1249304974; x=1250168974; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20conflict=20resolution=20over=20the=20backbone=2 0with=20SeND |Sender:=20; bh=RhvyfRcC9RDApMcE2E0+U7NsDzBlc0AxxO8JWJd6AVc=; b=ZTKok15lVOpcoQj0mBkX6aKeSeTlXUUVZl0Abt8eR11mviS3X/mXehHp4R o6ciAUf1NccTorYYrUynoe/5oUYR+sgqUvryQ9ATnPldqX7E4fYEu2oCDCig 94bOdHmXGg; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: [6lowpan] conflict resolution over the backbone with SeND X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 03 Aug 2009 13:09:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA143B.A572D66C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA143B.A572D66C" ------_=_NextPart_002_01CA143B.A572D66C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Zach: =20 We do not have a rule when a white board gets a SeND signed claim for an address. That should always win against a non-SeND claim, wouldn't you think? So I guess we need a few words to explain that. =20 =20 Pascal Thubert IP Engineering TC pthubert@cisco.com =20 Phone :+33 497 23 26 34 Mobile :+33 619 98 29 85 Cisco Systems Village d'Entreprises Green Side bat. T3=20 400, Avenue Roumanille 06410 Biot - Sophia Antipolis =20 France www.cisco.com/global/FR/ =20 This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. =20 =20 ------_=_NextPart_002_01CA143B.A572D66C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Zach:

 

We do not have a rule when a white board gets a = SeND signed claim for an address. That should always win against a non-SeND claim, = wouldn’t you think? So I guess we need a few words to explain = that.

 

<= /p>

= Pascal Thubert
IP Engineering TC

pthubert@cisco.com
Phone :+33 497 23 26 34
Mobile :+33 619 98 29 85

Cisco = Systems=
  Village d'Entreprises Green Side bat. T3
  400, Avenue Roumanille
  06410 Biot - Sophia Antipolis 
  France
  www.cisco.com/global/FR/

This e-mail may contain confidential and privileged = material for the sole use of the intended recipient. Any review, use, = distribution or disclosure by others is strictly prohibited. If you are not the = intended recipient (or authorized to receive for the recipient), please = contact the sender by reply e-mail and delete all copies of this = message.

 

 

------_=_NextPart_002_01CA143B.A572D66C-- ------_=_NextPart_001_01CA143B.A572D66C Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.jpg Content-Location: image002.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABWAIEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKoXmsWdjqFrYzybZrokRj 1py6tZtqzaWJR9pVN5T2rj/GH/I/eHf95f8A0OrjG7szOc7K6O9oqnqWq2mkwLPeSeWjuEB9zVtS GUMDkEZFRYu/QWimswRSzHAUZJqrpmqWmrWxuLOTfGGKk+4osF+gyy1mz1C9urS3k3S2rbZBV+uC 8Ef8jn4h/wCuh/8AQzXYf2tZjVxpfmj7UY/M2e1XKNnZEQnzRuy7RRRUGgUUUUAFFFFABRRRQAVy /hPxFea1qerW9yqBLWXEe30yR/SuoqnZaVZ6fNcTW0QR7l98hHc1SasyWndWOOtv+Sw3H/XD/wBk Wjxh/wAj94d/3h/6HXYrpVmuqNqYiH2lk2F/asTX/D1zqXinSNRiYCK0b95n2Oa0UlzL0MZQai15 md8VP+QHZ/8AXz/7Ka3tb1GbSfCUt9bhTLFApXd05wP61f1HTLTVYFhvIhIiuHAPqKkurOC8s5LS dA0Mi7WX2qOZWSL5HeTXUy9L1CbVfByX04USzWzFgvTOCKxPhZ/yLk//AF8n/wBBFdfb2kFrZpaR IFhRNgX2qPTtMtdKtjb2cYjjLFiPc0cys0PkfMm+hxvgj/kc/EP/AF0P/oZpW/5LIv8A17f+061f Dnh650rxDq99MwMd2+Y8ehJP9a2/7LtDqo1Pyh9pCbN/tVuS5n6GcYPlS8zD8T+IrzSNc0izt1Qx 3cmJN3XGQP611FU7zSrO+ube4uIg8ls26M+hq5WbasrGyTTdwoooqSgooooAKKKKACkZgqlmOABk mlqlrEMtxo95DBnzHhYLj1xQNK7scPqvxUI1CSz0LTHv/KJDPzg49Mdq6vStek1DwuNYktTDJ5bO YW4wV7fpXnnwv1zR9DS/s9VkS1uzLnfIOoAwVz9c16PPfWmpeGrq6sZFkgeGTayjg8HNYwk2rtno 4qlCnJU4w2tr3KPhLxZ/wkujz6jNai1WBypAfdwB16CucPxO1G8vJv7H0CW8tIWw8gzn9Kk+FCxP 4TvVmx5ZmYPn0xzXL6vbnwWx1Hw14lSWGWXm3DZbv1HcVLlLlTNoUKPt507a9N7HrGoa7aaVoY1W /Jhj2KxQ/eyR9361xNr8U769vYzBoMhsnlCebySM/himfEGS81r4eadqXllclZJlUcDI61s+GPF/ hhfDtjAtzDA6osbQEc7+h49zVOTcrXsZQowhR53Dmd2vQ1fFPi2w8LWKT3QaSWX/AFUK9W/+tXJ6 d8WibxE1fS3tLeU4SUZ6evP9Kp/FBDa+K9I1O7iMtgoUMOoOGyR+VL8R/Eugav4ft7TTXjubl3Vo /LXmMen9MVMpu712NaGGpuEE4t8277HqUciTRLLGwZHAKkdxT6yvDEE1t4Z06C4BEqW6hweucVq1 utjyZJKTSCiiimSFFFFABRRRQAUUUUAc9q3gXw7rNybm7sB5x5Z42KlvritOy0exsNKXS7eHbaqh TZkng9eavUUuVXuaOrNxUW3ZGbpfh/S9GspbKwtRDBKSXTcTnP1NY0Pw18LQXKziwLMrbsPISPyr q6KXLHsNV6qbak9dyJ7aCS2Ns8SNCV2mMjjHpiucX4c+GEvlu0sNrq4cKJDtB+ldRRTcU9xQqzhf lbVypqGmWWq2jWl9bpPC38LCsbTfAHhvSrsXVvYAyr90yMW2n1ANdJRQ4pu7CNWpGLjFtIKKKKZm FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//9k= ------_=_NextPart_001_01CA143B.A572D66C-- From trac@tools.ietf.org Mon Aug 3 06:12:20 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF61F28C17C for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v34rEBHwd7rH for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:12:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 2EC1C28C176 for <6lowpan@ietf.org>; Mon, 3 Aug 2009 06:12:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MXxKw-00018P-QP; Mon, 03 Aug 2009 06:12:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 03 Aug 2009 13:12:22 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/49 Message-ID: <060.0233618d857e9213f8073f69ec1cdf07@tools.ietf.org> X-Trac-Ticket-ID: 49 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #49: Next-hop determination X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:12:20 -0000 #49: Next-hop determination --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: defect | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- This can be simplified further. The nd-04 use of the neighbor cache was broken. - Link-local (FE80::) always is sent on the interface. - Global, anycast and multicast are always sent to the default router. This is compatible with removal of the neighbor cache from ticket #48 as it is no longer needed for next-hop determination. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 3 06:14:42 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C863A694C for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDf5vh0mvnDp for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:14:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id ED8C528C158 for <6lowpan@ietf.org>; Mon, 3 Aug 2009 06:14:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MXxNB-0006aH-Jv; Mon, 03 Aug 2009 06:14:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: pthubert@cisco.com, zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 03 Aug 2009 13:14:41 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/50 Message-ID: <060.819f8f512d5b0032aa8dfa41ba3920eb@tools.ietf.org> X-Trac-Ticket-ID: 50 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #50: SeND on backbone link X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:14:42 -0000 #50: SeND on backbone link --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: pthubert@cisco.com Type: enhancement | Status: new Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- We do not have a rule when a white board gets a SeND signed claim for an address. That should always win against a non-SeND claim. We need a few words to explain that. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 3 06:17:42 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1F028C10F for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M98PDLLtHEBR for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:17:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id A09D728C181 for <6lowpan@ietf.org>; Mon, 3 Aug 2009 06:17:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MXxQ8-0005IM-Cn; Mon, 03 Aug 2009 06:17:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: pthubert@cisco.com, zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 03 Aug 2009 13:17:44 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/51 Message-ID: <060.b0aa1bde6f48ac0ec354bc7609c28693@tools.ietf.org> X-Trac-Ticket-ID: 51 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #51: Address and OII collision table X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:17:42 -0000 #51: Address and OII collision table --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: pthubert@cisco.com Type: enhancement | Status: new Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Table like in the nd-04 IETF-75 presentation to be added to the Edge Router section. This will help to easily see the different actions to be taken depending on the values in the NR upon processing. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 3 06:18:28 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23EFC28C190 for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9cGQreT6tLf for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:18:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 844D628C18B for <6lowpan@ietf.org>; Mon, 3 Aug 2009 06:18:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MXxQs-00079j-B6; Mon, 03 Aug 2009 06:18:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 03 Aug 2009 13:18:30 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/48#comment:1 Message-ID: <069.d6eca50652a24ec090b47420f8510e8b@tools.ietf.org> References: <060.8ef1a86b33678026672bf7d555ba3de4@tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <060.8ef1a86b33678026672bf7d555ba3de4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #48: NR/NC improvements and router state X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:18:28 -0000 #48: NR/NC improvements and router state --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: enhancement | Status: new Priority: major | Milestone: Component: nd | Version: Severity: - | Resolution: Keywords: | --------------------------------+------------------------------------------- Changes (by zach@sensinode.com): * owner: => zach@sensinode.com -- Ticket URL: 6lowpan From zach@sensinode.com Mon Aug 3 06:26:13 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AACFE3A6C6E for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKeRuZgAI2fX for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 06:26:12 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 7C2F53A6BE2 for <6lowpan@ietf.org>; Mon, 3 Aug 2009 06:26:11 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n73DQAAt006957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Mon, 3 Aug 2009 16:26:10 +0300 Message-ID: <4A76E574.5000109@sensinode.com> Date: Mon, 03 Aug 2009 16:26:12 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowpan] Moving to nd-05 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 03 Aug 2009 13:26:13 -0000 Hi, I have now updated all of our open issue tickets wrt nd-04 based on the feedback received on the list and in Stockholm so far. It is positive to see that we are moving towards last call after nd-05. The message at the WG meeting was a clear "Get it Done". http://trac.tools.ietf.org/wg/6lowpan/trac/query?status=new&component=nd The DT will be working on solutions for some tickets that need further design work. We will pass these solutions on to the mailing list as well for comments (tickets #47 and #48). Comments and ideas from the WG are welcome. We plan on releasing nd-05 at the end of next week. Regards, Zach -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From cabo@tzi.org Mon Aug 3 08:09:12 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7AB83A6E32 for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 08:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOfXV+mSrQBH for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 08:09:12 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 7331B3A6E37 for <6lowpan@ietf.org>; Mon, 3 Aug 2009 08:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n73F94XT009483; Mon, 3 Aug 2009 17:09:05 +0200 (CEST) Received: from [192.168.217.107] (p5489F1F1.dip.t-dialin.net [84.137.241.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 80D3FBE2A; Mon, 3 Aug 2009 17:09:04 +0200 (CEST) From: Carsten Bormann To: 6lowpan@ietf.org In-Reply-To: <060.902319ec8a702615fa13c7248867dc4e@tools.ietf.org> References: <060.902319ec8a702615fa13c7248867dc4e@tools.ietf.org> Message-Id: <58101DA0-2C6E-4E7B-AE87-053B620C31C7@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 17:09:02 +0200 X-Mailer: Apple Mail (2.935.3) Subject: Re: [6lowpan] #46: M-bit in the RA X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 03 Aug 2009 15:09:13 -0000 > "LoWPAN Routers with no ER available SHOULD set Prf to (00) for low > preference, LoWPAN Routers with ER availability SHOULD set Prf to > (01) for > normal preference, and LoWPAN Edge Routers SHOULD set Prf to (01) > for high > preference." Make that: > "LoWPAN Routers with no ER available SHOULD set Prf to (11) for low > preference, LoWPAN Routers with ER availability SHOULD set Prf to > (00) for > normal preference, and LoWPAN Edge Routers SHOULD set Prf to (01) > for high > preference." Prf is a two-bit signed (two's complement) field. 11 = -1. 00 = 0. 01 = 1. (10 = 2. is reserved in RFC 4191 -- we could start to use it if needed, though.) I haven't thought through whether SHOULD is the right level of requirement here. (Intuitively, I'd say MUST, because I can imagine the protocol seriously misbehaving without.) (Maybe it would also be good to add a short note that, while the M and O bits are available, they are not very useful in a 6LoWPAN.) Gruesse, Carsten From cabo@tzi.org Mon Aug 3 08:17:16 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498A628C16B for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 08:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.962 X-Spam-Level: X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+p2+LaL2QIb for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 08:17:15 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 2D81B3A6AFC for <6lowpan@ietf.org>; Mon, 3 Aug 2009 08:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n73FH6RV012367; Mon, 3 Aug 2009 17:17:06 +0200 (CEST) Received: from [192.168.217.107] (p5489F1F1.dip.t-dialin.net [84.137.241.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id ACBF2BE31; Mon, 3 Aug 2009 17:17:05 +0200 (CEST) From: Carsten Bormann To: 6lowpan@ietf.org In-Reply-To: <060.f40c7d943c73a44f29901bbef0b43cbc@tools.ietf.org> References: <060.f40c7d943c73a44f29901bbef0b43cbc@tools.ietf.org> Message-Id: <4B8CF782-A2DC-424C-9303-19E14816A473@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 17:17:04 +0200 X-Mailer: Apple Mail (2.935.3) Subject: Re: [6lowpan] #47: Context improvement X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 03 Aug 2009 15:17:16 -0000 > - Separate the Prefix Information and Context Information into > separate > options. This clarifies what is a prefix and what is context. > > - Use either the standard RFC4861 Prefix Information Option or an > optimized one to save overhead. The 4861 PIO is about twice the size of the 6LoWPAN one, as 4861 always sends all 16 bytes of a prefix and then needs to add padding (and a reserved field). Combining 6LoWPAN-PIO and CID-IO into one option makes it unnecessary to send all the global prefix(es) of the LoWPAN twice. There is still enough space in the option to indicate whether the CID number is valid or not (the A bit already tells us whether this is a valid subnet prefix). When we went CBHC, I heard some noises that the context info might get somewhat large for distribution in RAs. With this changes, yes, they will. I still haven't heard a rationale for this change. If there is indeed a need to clarify, do so in the text, not the encoding. Gruesse, Carsten From pars.mutaf@gmail.com Mon Aug 3 10:08:28 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2473328C17D for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 10:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKmRk6zipti0 for <6lowpan@core3.amsl.com>; Mon, 3 Aug 2009 10:08:27 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 9C8623A68F6 for <6lowpan@ietf.org>; Mon, 3 Aug 2009 10:08:26 -0700 (PDT) Received: by ewy10 with SMTP id 10so3189259ewy.37 for <6lowpan@ietf.org>; Mon, 03 Aug 2009 10:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=p4TmsHr52Lj7uVs53LPO+qbkiK9SSd5S+QcbDbqvK6A=; b=PXevzKCmDFE3Q17wQKNFyFUDuyACjDfESX5XY3LpR0kq+TAgxAQDu4ed55QVgmgmTw Sq9X2oJsHtMDUPYOtctBgTpI6VPAJg+pBUDKO9mUovonnEgdkShvW+sMIwDQWw+N4oou FqC5bCbLk5wXepq/KJQkpzmr9m5fjfZsPE61E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jI5W1ok+CyAtN9MkuDtldpQPeq6a4FDqx6uAPny1PJWdLRVubz0RCBMeJCK20z5BiC p7q/9YZngaZCbaWe/shkEB6iMLdd3l8ZbPooqXNlhaOS/02N4ii7lpGy8PhEr4q6/J5I +LV1JSqBBEJonnN9Zh+Y8/keGfDgSPjbSkVxU= MIME-Version: 1.0 Received: by 10.210.89.7 with SMTP id m7mr5342951ebb.14.1249319305537; Mon, 03 Aug 2009 10:08:25 -0700 (PDT) In-Reply-To: <4A6D9736.7080700@sensinode.com> References: <18a603a60907160933j48404be5vfdcd2a148d66a873@mail.gmail.com> <4A6D9736.7080700@sensinode.com> Date: Mon, 3 Aug 2009 20:08:25 +0300 Message-ID: <18a603a60908031008l582a6cccwa8720e596530cae3@mail.gmail.com> From: Pars Mutaf To: Zach Shelby Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Edge router crash, reboot or new edge router X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 03 Aug 2009 17:08:28 -0000 On Mon, Jul 27, 2009 at 3:01 PM, Zach Shelby wrote: > Hi Pars, > > Pars Mutaf wrote: > >> I believe understand the motivations behind avoiding broadcast NS messag= es >> upon incoming session. However, what happens if the whiteboard approach >> fails >> i.e. if whiteboard bindings are lost due to edge router crash, reboot >> or changing >> the edge router for whatever administrative reason? > > This is a good question. As whiteboards have soft state, and nodes refres= h > the addresses they are using periodically, a whiteboard failure is not a > disaster to the network. If an Edge Router crashes: > > 1. If the ER reboots without state - the next NR message will refresh the > entries. It could be nice if the LoWPAN somehow knew that this happened > (how?) to avoid waiting up to NR_PERIOD. At least its default route will > stop working, that is an indication. Idle nodes need to preserve energy, and in order to reduce the bandwidth co= st, NR_PERIOD should be large. In this case, idle nodes will be unreachable for a long time without knowing it. If the WG does not prefer standard neighbor discovery, the following soluti= on comes to mind for handling reboot with loss of state: When the router boots up and its whiteboard is empty, it periodically broadcasts an alert message indicating that all nodes should register within T seconds. In order to avoid neighbor registration storms, upon receipt of the of this message, a node should wait a random amount of time between 0 and T se= conds and register. The bandwidth consumed during this period depends on T and th= e number of nodes. This assumes that if whiteboard state is lost, all of them is lost. This assumption holds in case of reboot with loss of state, or edge router upgrade. If NR_PERIOD is much longer than T/2 (average registration time), this will= be advantageous in case of reboot with loss of state. But if T is too small, there will be a registration storm. There is also no guarantee that a node will hear the alert message and register in time. This solution can work well if the number of nodes in the subnet is small. In this case however, stateless neighbor discovery also can work well without inducing too much signaling cost and it perfectly handles loss of state. > 2. If the ER reboots and kept its whiteboard state (recommended) - then o= f I guess here you suggest storing the whiteboard state in non-volatile memor= y. This may be clarified in the document. Routers in general store the routing tables in volatile memory. OS and configuration files only are stored in non-volat= ile memory. So I guess, reboot with loss of state is not a negligible scenario, unless explicit solution in the document. Regards, pars > course the ER can't forward on behalf of the node while down. Same for an= y > router, so this isn't a whiteboard problem. > > 3. If the ER goes down permanently, then the node will detect this becaus= e > its default route no longer works or the NR can no longer be sent to the = ER. > It either starts using an alternative ER or continues operating until a n= ew > ER comes on-line. > > In any case the LoWPAN can continue to operate while an ER is down (routi= ng > within the LoWPAN). In an extended LoWPAN nodes will start using alternat= ive > ERs automatically. Several techniques could be used by an ER vendor to > automatically switch state to an alternative ER, use non-volatile memory = for > Whiteboard state, use secondary bindings etc. > > Section 7.9 of nd-04 deals with this partially: > > http://tools.ietf.org/html/draft-ietf-6lowpan-nd-04#section-7.9 > >> A related question: how frequent you believe broadcast NS messages >> (i.e. incoming >> sessions) will be in a 6lowpan network? Or, sessions will be mostly >> initiated by >> 6lowpan nodes? > > We aren't using NS messages at all inside the LoWPAN. Node Registration > messages are always node initiated. > > - Zach > >> Regards, >> >> pars >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > -- > http://www.sensinode.com > http://zachshelby.org - My blog =93On the Internet of Things=94 > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system without > producing, distributing or retaining copies thereof. > From trac@tools.ietf.org Tue Aug 4 00:56:54 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C433A6FAD for <6lowpan@core3.amsl.com>; Tue, 4 Aug 2009 00:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw6+KBGTdz3G for <6lowpan@core3.amsl.com>; Tue, 4 Aug 2009 00:56:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id B10AD3A6FAC for <6lowpan@ietf.org>; Tue, 4 Aug 2009 00:56:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MYEtD-0007lG-HY; Tue, 04 Aug 2009 00:56:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Tue, 04 Aug 2009 07:56:55 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/46#comment:1 Message-ID: <069.44756ce116ba678b3a607c5797570717@tools.ietf.org> References: <060.902319ec8a702615fa13c7248867dc4e@tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <060.902319ec8a702615fa13c7248867dc4e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #46: M-bit in the RA X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 07:56:54 -0000 #46: M-bit in the RA --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: Keywords: | --------------------------------+------------------------------------------- Comment(by zach@sensinode.com): Fix from Carsten: Prf is a two-bit signed (two's complement) field. 11 = -1. 00 = 0. 01 = 1. (10 = 2. is reserved in RFC 4191 -- we could start to use it if needed, though.) I haven't thought through whether SHOULD is the right level of requirement here. (Intuitively, I'd say MUST, because I can imagine the protocol seriously misbehaving without.) (Maybe it would also be good to add a short note that, while the M and O bits are available, they are not very useful in a 6LoWPAN.) Gruesse, Carsten -- Ticket URL: 6lowpan From zach@sensinode.com Tue Aug 4 01:15:45 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 630BC3A6DB8 for <6lowpan@core3.amsl.com>; Tue, 4 Aug 2009 01:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vNFUkJsLWcV for <6lowpan@core3.amsl.com>; Tue, 4 Aug 2009 01:15:44 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C6F8B3A6DE6 for <6lowpan@ietf.org>; Tue, 4 Aug 2009 01:15:43 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n748FcP5025134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Aug 2009 11:15:38 +0300 Message-ID: <4A77EE2C.40604@sensinode.com> Date: Tue, 04 Aug 2009 11:15:40 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Pars Mutaf References: <18a603a60907160933j48404be5vfdcd2a148d66a873@mail.gmail.com> <4A6D9736.7080700@sensinode.com> <18a603a60908031008l582a6cccwa8720e596530cae3@mail.gmail.com> In-Reply-To: <18a603a60908031008l582a6cccwa8720e596530cae3@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Edge router crash, reboot or new edge router X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 04 Aug 2009 08:15:45 -0000 Pars, Sorry it took some time to reply. We are recovering from IETF meeting hangover. Thanks a lot for you thought here - you just hit on a point we have been wanting to fix. See below. Pars Mutaf wrote: > On Mon, Jul 27, 2009 at 3:01 PM, Zach Shelby wrote: >> Hi Pars, >> >> Pars Mutaf wrote: >> >>> I believe understand the motivations behind avoiding broadcast NS messages >>> upon incoming session. However, what happens if the whiteboard approach >>> fails >>> i.e. if whiteboard bindings are lost due to edge router crash, reboot >>> or changing >>> the edge router for whatever administrative reason? >> This is a good question. As whiteboards have soft state, and nodes refresh >> the addresses they are using periodically, a whiteboard failure is not a >> disaster to the network. If an Edge Router crashes: >> >> 1. If the ER reboots without state - the next NR message will refresh the >> entries. It could be nice if the LoWPAN somehow knew that this happened >> (how?) to avoid waiting up to NR_PERIOD. At least its default route will >> stop working, that is an indication. Another thing to consider is that Neighbor Discovery is only one part of the formula. If you have an ER crash - your routing algorithm (probably the DAG root in RPL) has to start from scratch as well. > Idle nodes need to preserve energy, and in order to reduce the bandwidth cost, > NR_PERIOD should be large. In this case, idle nodes will be unreachable > for a long time without knowing it. And this is not a problem, as sleeping nodes can't (not considering low-power wakeup of course) be reached anyways. It is a problem for nodes that stay awake. It would be nice if a node that is awake between NR messages figures out that its current primary ER is no longer available. > If the WG does not prefer standard neighbor discovery, the following solution > comes to mind for handling reboot with loss of state: > > When the router boots up and its whiteboard is empty, it periodically > broadcasts an > alert message indicating that all nodes should register within T seconds. > > In order to avoid neighbor registration storms, upon receipt of the of > this message, a node should wait a random amount of time between 0 and T seconds > and register. The bandwidth consumed during this period depends on T and the > number of nodes. > > This assumes that if whiteboard state is lost, all of them is lost. > This assumption > holds in case of reboot with loss of state, or edge router upgrade. > > If NR_PERIOD is much longer than T/2 (average registration time), this will be > advantageous in case of reboot with loss of state. But if T is too > small, there will > be a registration storm. > > There is also no guarantee that a node will hear the alert message and > register in time. This is an interesting idea. The DT has been playing with the idea of allowing an ER or a router to send an unsolicited NC to the network in order to tell that it has reset, or that an ER is no longer available. In ticket #48 (http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/48) we already propose a status "Please re-register" for an NC that a router can send to a node. If we let this be sent from any ER or router then it serves the purpose above well. The random delay could be between 0 and (NR_PERIOD + NR_PERIOD/2) to keep the average as you suggest. > This solution can work well if the number of nodes in the subnet is > small. In this case > however, stateless neighbor discovery also can work well without > inducing too much > signaling cost and it perfectly handles loss of state. The reason we don't use RFC4861 is not just because of state. It just doesn't work with non-transitive links where nodes are mostly sleeping. RFC4861 was designed for Ethernet-like links. > >> 2. If the ER reboots and kept its whiteboard state (recommended) - then of > > I guess here you suggest storing the whiteboard state in non-volatile memory. > This may be clarified in the document. Routers in general store the > routing tables > in volatile memory. OS and configuration files only are stored in non-volatile > memory. This is an implementation issue, I just used it as an example. We should not expect that a router is able to do this in the protocol design. > So I guess, reboot with loss of state is not a negligible scenario, > unless explicit > solution in the document. > > Regards, > > pars Thanks! Zach > > >> course the ER can't forward on behalf of the node while down. Same for any >> router, so this isn't a whiteboard problem. >> >> 3. If the ER goes down permanently, then the node will detect this because >> its default route no longer works or the NR can no longer be sent to the ER. >> It either starts using an alternative ER or continues operating until a new >> ER comes on-line. >> >> In any case the LoWPAN can continue to operate while an ER is down (routing >> within the LoWPAN). In an extended LoWPAN nodes will start using alternative >> ERs automatically. Several techniques could be used by an ER vendor to >> automatically switch state to an alternative ER, use non-volatile memory for >> Whiteboard state, use secondary bindings etc. >> >> Section 7.9 of nd-04 deals with this partially: >> >> http://tools.ietf.org/html/draft-ietf-6lowpan-nd-04#section-7.9 >> >>> A related question: how frequent you believe broadcast NS messages >>> (i.e. incoming >>> sessions) will be in a 6lowpan network? Or, sessions will be mostly >>> initiated by >>> 6lowpan nodes? >> We aren't using NS messages at all inside the LoWPAN. Node Registration >> messages are always node initiated. >> >> - Zach >> >>> Regards, >>> >>> pars >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> -- >> http://www.sensinode.com >> http://zachshelby.org - My blog “On the Internet of Things” >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> This e-mail and all attached material are confidential and may contain >> legally privileged information. If you are not the intended recipient, >> please contact the sender and delete the e-mail from your system without >> producing, distributing or retaining copies thereof. >> -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From zach@sensinode.com Tue Aug 4 01:39:37 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F873A6FBA for <6lowpan@core3.amsl.com>; Tue, 4 Aug 2009 01:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5xX-rVb0QsL for <6lowpan@core3.amsl.com>; Tue, 4 Aug 2009 01:39:36 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8B3573A6FAD for <6lowpan@ietf.org>; Tue, 4 Aug 2009 01:39:18 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n748dGT8026770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Aug 2009 11:39:16 +0300 Message-ID: <4A77F3B6.6020305@sensinode.com> Date: Tue, 04 Aug 2009 11:39:18 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Carsten Bormann References: <060.f40c7d943c73a44f29901bbef0b43cbc@tools.ietf.org> <4B8CF782-A2DC-424C-9303-19E14816A473@tzi.org> In-Reply-To: <4B8CF782-A2DC-424C-9303-19E14816A473@tzi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #47: Context improvement X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 04 Aug 2009 08:39:37 -0000 Hi, Carsten Bormann wrote: >> - Separate the Prefix Information and Context Information into separate >> options. This clarifies what is a prefix and what is context. >> >> - Use either the standard RFC4861 Prefix Information Option or an >> optimized one to save overhead. > > The 4861 PIO is about twice the size of the 6LoWPAN one, as 4861 always > sends all 16 bytes of a prefix and then needs to add padding (and a > reserved field). Yep. It needs to be optimized. > Combining 6LoWPAN-PIO and CID-IO into one option makes it unnecessary to > send all the global prefix(es) of the LoWPAN twice. > There is still enough space in the option to indicate whether the CID > number is valid or not (the A bit already tells us whether this is a > valid subnet prefix). > > When we went CBHC, I heard some noises that the context info might get > somewhat large for distribution in RAs. > With this changes, yes, they will. You are correct, this will take more space using multiple options. Already this is an issue when having lots of contexts. > I still haven't heard a rationale for this change. If there is indeed a > need to clarify, do so in the text, not the encoding. If I understand it, the rational for separating the prefix information from context information, was to allow for context information to be distributed in other ways as well in the future. E.g. including a Context Information Option also in other messages. What if we would do something like this. 1. Rename the current option to "6LoWPAN Information Option" making it more neutral to whether it is carrying prefix or context information. 2. Add the extra bits needed to tell if the CID is valid or not. 3. Make it clear that the option can carry a prefix, a context or a prefix which is also a context. This option would be generic enough that it could also potentially be carried in messages other than RAs. Here is a shot at a proposal: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Info Length |L|A|C|V| CID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Information . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6LoWPAN Information Option format Type: TBD4 Length: 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. May be 1, 2 or 3 depending on the length of the Prefix field. Info Length: 8-bit unsigned integer. The number of leading bits in the Information field that are valid. The value ranges from 0 to 128. The info length field provides necessary information for on-link determination (when combined with the L flag in the prefix information option). It also assists with address autoconfiguration as specified in [RFC4862], for which there may be more restrictions on the info length. L: 1-bit on-link flag. This flag MUST be unset for Route Over LoWPANs and Extended LoWPANs, and MAY be set for Mesh Under Simple LoWPANs. A: 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for stateless address configuration as specified in [RFC4861]. C: 1-bit context flag. This flag indicates that this information option also serves as a context on the LoWPAN and is identified by the CID field. V: 1-bit context validity flag. This flag indicates if the context is valid, and is used only in combination with the C flag. CID: 4-bit Context Identifier for this information. CID is used by context based header compression specified in [I-D.ietf-6lowpan-hc]. The list of CIDs for a LoWPAN is configured on Edge Routers, who distribute the prefix list to all nodes in the LoWPAN. CID = 0 identifies the default context to be used. Valid Lifetime: 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xffffffff) represents infinity. Information: The IPv6 prefix or context information indicated. This may be a partial prefix, a partial context or even an entire IPv6 address for use as a context for compression. Zach > Gruesse, Carsten > -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From jvasseur@cisco.com Fri Aug 7 00:47:19 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18D13A6E1D for <6lowpan@core3.amsl.com>; Fri, 7 Aug 2009 00:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.49 X-Spam-Level: X-Spam-Status: No, score=-9.49 tagged_above=-999 required=5 tests=[AWL=1.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQF1wRoows31 for <6lowpan@core3.amsl.com>; Fri, 7 Aug 2009 00:47:18 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 160CA3A67AC for <6lowpan@ietf.org>; Fri, 7 Aug 2009 00:47:17 -0700 (PDT) X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcAANJ4e0qQ/uCLe2dsb2JhbACCJi+XawEBFiQGnBGIKpAYBYQWgVGCUw X-IronPort-AV: E=Sophos;i="4.43,340,1246838400"; d="scan'208,217";a="46635173" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Aug 2009 07:47:20 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n777lJD3027983; Fri, 7 Aug 2009 09:47:19 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n777lJ5O023003; Fri, 7 Aug 2009 07:47:19 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 09:47:19 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 09:47:18 +0200 Message-Id: From: JP Vasseur To: Jonathan Hui Content-Type: multipart/alternative; boundary=Apple-Mail-265-741098514 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 09:47:18 +0200 References: <20090630171501.5D84E3A6CBF@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Aug 2009 07:47:18.0958 (UTC) FILETIME=[4A3A34E0:01CA1733] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16810.004 X-TM-AS-Result: No--27.409500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8161; t=1249631239; x=1250495239; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20I-D=20Action=3Adraft-ietf-6lowpan-hc-0 5.txt=20 |Sender:=20; bh=F9oqolyf73B/iXmJwfldIpBtVQ9BjdQxaViFs7aR86o=; b=d6b1/3d108w9sUMtFKDq4cH7evaAlFf2M7aSw7kP/LaxIsfUYm/d9mila1 RmObeKvzCCTfc70uVknnRDcGLQ3GKwTo/kqwbqahwIfbe8VKEcoR2LhvB5H5 mDRBj0/iaA; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: [6lowpan] Fwd: I-D Action:draft-ietf-6lowpan-hc-05.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 07 Aug 2009 07:47:19 -0000 --Apple-Mail-265-741098514 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Jonathan, As discussed in Stockholm, it might be good to point out what is changed wrt to 4944. Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: June 30, 2009 7:15:01 PM CEDT > To: i-d-announce@ietf.org > Cc: 6lowpan@lists.ietf.org > Subject: I-D Action:draft-ietf-6lowpan-hc-05.txt > Reply-To: internet-drafts@ietf.org > > 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 : Compression Format for IPv6 Datagrams in 6LoWPAN > Networks > Author(s) : J. Hui, P. Thubert > Filename : draft-ietf-6lowpan-hc-05.txt > Pages : 19 > Date : 2009-06-30 > > This document specifies an IPv6 header compression format for IPv6 > packet delivery in 6LoWPAN networks. The compression format relies > on shared context to allow compression of arbitrary prefixes. The > information that is maintained in that shared context is out of > scope. This document specifies compression of multicast addresses > and a framework for compressing next headers. This framework > specifies UDP compression and is prepared for additional transports. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-hc-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-265-741098514 Content-Type: multipart/mixed; boundary=Apple-Mail-266-741098515 --Apple-Mail-266-741098515 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Hi = Jonathan,

As discussed in Stockholm, it might = be good to point out = what is changed wrt to 4944.

=
Thanks.

JP.

Begin = forwarded message:

Date: June 30, 2009 7:15:01 PM = CEDT
To: i-d-announce@ietf.org
Cc: 6lowpan@lists.ietf.org
Subject: I-D = Action:draft-ietf-6lowpan-hc-05.txt 

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 =           : = Compression Format for IPv6 Datagrams in 6LoWPAN Networks
Author(s) =       : J. Hui, P. Thubert
Filename =        : = draft-ietf-6lowpan-hc-05.txt
Pages =           : = 19
= Date =            : = 2009-06-30

This document specifies an IPv6 header compression = format for IPv6
packet delivery in 6LoWPAN networks.  The = compression format relies
on shared context to allow compression of = arbitrary prefixes.  The
information that is maintained in that = shared context is out of
scope.  This document specifies = compression of multicast addresses
and a framework for compressing = next headers.  This framework
specifies UDP compression and is = prepared for additional transports.

A URL for this Internet-Draft = is:
= http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-hc-05.txt
Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-266-741098515 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain<BR>Content-ID: &lt;2009-06-30100512.I-D@ietf.org&gt;<BR><BR> --Apple-Mail-266-741098515 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-266-741098515-- --Apple-Mail-265-741098514-- From jvasseur@cisco.com Fri Aug 7 01:36:42 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE80C3A6E88 for <6lowpan@core3.amsl.com>; Fri, 7 Aug 2009 01:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.576 X-Spam-Level: X-Spam-Status: No, score=-9.576 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq9sdcHO9ikO for <6lowpan@core3.amsl.com>; Fri, 7 Aug 2009 01:36:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B5D5C3A6A45 for <6lowpan@ietf.org>; Fri, 7 Aug 2009 01:36:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAAAIuEe0qQ/uCLe2dsb2JhbACCJDGXbAEBFiQGnCqIKpAYBYQWgVE X-IronPort-AV: E=Sophos;i="4.43,340,1246838400"; d="scan'208,217";a="46639183" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Aug 2009 08:36:42 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n778agN5007105; Fri, 7 Aug 2009 10:36:42 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n778agBB005058; Fri, 7 Aug 2009 08:36:42 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 10:36:43 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 10:36:42 +0200 Message-Id: From: JP Vasseur To: Eunsook Eunah Kim In-Reply-To: <77f1dba80907280906m1cdda4adv82e32c5f19e99ef1@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-298-744060917 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 10:36:40 +0200 References: <20090728155727.E8EF33A7056@core3.amsl.com> <77f1dba80907280906m1cdda4adv82e32c5f19e99ef1@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 07 Aug 2009 08:36:42.0183 (UTC) FILETIME=[30727570:01CA173A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12547; t=1249634202; x=1250498202; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20Fwd=3A=20New=20Version=20No tification=20for=20draft-ietf-6lowpan-routing-requirements-0 4 |Sender:=20; bh=64+tFrjb2zRqck/eWsGW1VCX1Ea76A7kiabgdEfl5xg=; b=gBRj2qmOIFJksmSKGsyaL6pxe3GyEdErQj0sUYAI4mKh/FCfDYLw7PvAVx nMv7O+72xHXD/NIQqkyVWvtf2QdgQgjvoX3KPFxuqqTuN9Izrg/EFJWeS1Cw EnsC3nU0Ma; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-routing-requirements-04 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 07 Aug 2009 08:36:43 -0000 --Apple-Mail-298-744060917 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hu Eunah, On Jul 28, 2009, at 6:06 PM, Eunsook Eunah Kim wrote: > Dear 6lowpaners, > > The draft of 6lowpan routing requirements are revised to -04, applying > the comments at the meeting. > JP worries the term *routing* in adaptation layer, and Eric gave us a > good terminology to use there. > Now you will find the description under the figure to reduce the > confusion between "IP routing" and "mesh-under path computation + > forwarding". :-) > > I would like to point out again that the figure is to show the basic > architecture based on RFC4944 and WG concensus so far. > > Please check the revised version and give your comments. > Just to make sure that we are on the same page, I am not so much worried about the terminology but the architecture here ... cut and paste from the ID: Figure 1 shows the place of 6LoWPAN routing in the entire network stack. +-----------------------------+ +-----------------------------+ | Application Layer | | Application Layer | +-----------------------------+ +-----------------------------+ | Transport Layer (TCP/UDP) | | Transport Layer (TCP/UDP) | +-----------------------------+ +-----------------------------+ | Network Layer (IPv6) | | Network +---------+ | +-----------------------------+ | Layer | Routing | | | 6LoWPAN +---------+ | | (IPv6) +---------+ | | Adaptation | Routing*| | +-----------------------------+ | Layer +---------+ | | 6LoWPAN Adaptation Layer | +-----------------------------+ +-----------------------------+ | IEEE 802.15.4 (MAC) | | IEEE 802.15.4 (MAC) | +-----------------------------+ +-----------------------------+ | IEEE 802.15.4 (PHY) | | IEEE 802.15.4 (PHY) | +-----------------------------+ +-----------------------------+ * Here, 'Routing' is not equivalent to IP routing, but includes the functionalities of path computation and forwarding under the IP layer. In our world, routing is performed at the IP layer (RPL) so as to run on a myriad of L2. Routing in an adaptation layer makes no sense to me. Perform L2 meshing/routing is a reality of course, and I personally believe that trying to combine L2 meshing with L3 routing in our world is completely wrong but this is another discussion. For example, you write: "When a 6LoWPAN follows the Mesh Under configuration, the LoWPAN Edge Router (ER) is the only IPv6 router in the 6LoWPAN (see Figure 3). This means that the IPv6 link-local scope includes all nodes in the LoWPAN. For this, a Mesh Under mechanism MUST be provided to support multi-hop transmission." Who is the normative MUST for ? Back to L2 meshing/routing, if there must be document somewhere I truly believe that this should go in some white paper or a book, not sure that we need an IETF requirement document. If the objective is to provide requirements for L2 meshing/routing, then it should be discussed with the SDO in charge on these L2 technologies. Still, there is good data in the document and I would be happy to discuss on how we could make some use of it. Thanks. JP. > -eunah > > ---------- Forwarded message ---------- > From: IETF I-D Submission Tool > Date: Tue, Jul 28, 2009 at 5:57 PM > Subject: New Version Notification for draft-ietf-6lowpan-routing- > requirements-04 > To: eunah.ietf@gmail.com > Cc: dokaspar.ietf@gmail.com, carlesgo@entel.upc.edu, cabo@tzi.org > > > > A new version of I-D, draft-ietf-6lowpan-routing-requirements-04.txt > has been successfuly submitted by Eunsook Kim and posted to the IETF > repository. > > Filename: draft-ietf-6lowpan-routing-requirements > Revision: 04 > Title: Problem Statement and Requirements for 6LoWPAN > Routing > Creation_date: 2009-07-28 > WG ID: 6lowpan > Number_of_pages: 32 > > Abstract: > 6LoWPANs are formed by devices that are compatible with the IEEE > 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor > the 6LoWPAN format specification define how mesh topologies could be > obtained and maintained. Thus, it should be considered how 6LoWPAN > formation and multi-hop routing could be supported. > This document provides the problem statement and design space for > 6LoWPAN routing. It defines the routing requirements for 6LoWPAN > networks, considering the low-power and other particular > characteristics of the devices and links. The purpose of this > document is not to recommend specific solutions, but to provide > general, layer-agnostic guidelines about the design of 6LoWPAN > routing, which can lead to further analysis and protocol design. > This document is intended as input to groups working on routing > protocols relevant to 6LoWPAN, such as the IETF ROLL WG. > > > > The IETF Secretariat. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --Apple-Mail-298-744060917 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hu Eunah,

On = Jul 28, 2009, at 6:06 PM, Eunsook Eunah Kim wrote:

Dear = 6lowpaners,

The draft of 6lowpan routing requirements are revised = to -04, applying
the comments at the meeting.
JP worries the term = *routing* in adaptation layer, and Eric gave us a
good terminology to = use there.
Now you will find the description under the figure to = reduce the
confusion between "IP routing" and "mesh-under path = computation +
forwarding". :-)

I would like to point out again = that the figure is to show the basic
architecture based on RFC4944 = and WG concensus so far.

Please check the revised version and = give your comments.


Just = to make sure that we are on the same page, I am not so much = worried
about the terminology but the architecture here = ... 

cut and paste from the = ID:

Figure 1 shows the place of 6LoWPAN routing in =
the entire network
   stack.

    +-----------------------------+    +-----------------------------+
    |  Application Layer          |    |  Application Layer          |
    +-----------------------------+    +-----------------------------+
    |  Transport Layer (TCP/UDP)  |    |  Transport Layer (TCP/UDP)  |
    +-----------------------------+    +-----------------------------+
    |  Network Layer (IPv6)       |    |  Network       +---------+  |
    +-----------------------------+    |  Layer         | Routing |  |
    |  6LoWPAN       +---------+  |    |  (IPv6)        +---------+  |
    |  Adaptation    | Routing*|  |    +-----------------------------+
    |  Layer         +---------+  |    |  6LoWPAN Adaptation Layer   |
    +-----------------------------+    +-----------------------------+
    |  IEEE 802.15.4 (MAC)        |    |  IEEE 802.15.4 (MAC)        |
    +-----------------------------+    +-----------------------------+
    |  IEEE 802.15.4 (PHY)        |    |  IEEE 802.15.4 (PHY)        |
    +-----------------------------+    +-----------------------------+
    * Here, 'Routing' is not equivalent to IP routing,
      but includes the functionalities of path computation and
      forwarding under the IP layer.


In = our world, routing is performed at the IP layer (RPL) so as to run = on a myriad of L2. 
Routing in an adaptation layer = makes no sense to me. Perform L2 meshing/routing is
a reality = of course, and I personally believe that trying to combine L2 = meshing with L3 
routing in our world is completely = wrong but this is another discussion.

For = example, you write:

"When a 6LoWPAN follows the Mesh Under configuration, the = LoWPAN Edge
   Router (ER) is the only IPv6 router in the =
6LoWPAN (see Figure 3).
   This means that the IPv6 link-local scope includes all nodes in the
   LoWPAN.  For this, a Mesh Under mechanism MUST be provided to support
   multi-hop transmission."

Who is the = normative MUST for ?

Back to L2 = meshing/routing, if there must be document somewhere I = truly 
believe that this should go in some white paper or = a book, not sure that we
need an IETF requirement = document. If the objective is to provide requirements
for L2 = meshing/routing, then it should be discussed with the SDO in charge = on
these L2 technologies.

Still, = there is good data in the document and I would be happy to discuss on = how
we could make some use of = it.

Thanks.

JP.
-eunah

---------- Forwarded = message ----------
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Dat= e: Tue, Jul 28, 2009 at 5:57 PM
Subject: New Version Notification for = draft-ietf-6lowpan-routing-requirements-04
To: eunah.ietf@gmail.com
Cc: dokaspar.ietf@gmail.com, carlesgo@entel.upc.edu, cabo@tzi.org



A new = version of I-D, draft-ietf-6lowpan-routing-requirements-04.txt
has = been successfuly submitted by Eunsook Kim and posted to the = IETF
repository.

Filename:       =  draft-ietf-6lowpan-routing-requirements
Revision:     =    04
Title:           Problem = Statement and Requirements for 6LoWPAN Routing
Creation_date:   = 2009-07-28
WG ID:           = 6lowpan
Number_of_pages: 32

Abstract:
6LoWPANs are formed = by devices that are compatible with the IEEE
802.15.4 standard. =  However, neither the IEEE 802.15.4 standard nor
the 6LoWPAN = format specification define how mesh topologies could be
obtained and = maintained.  Thus, it should be considered how 6LoWPAN
formation = and multi-hop routing could be supported.
This document provides the = problem statement and design space for
6LoWPAN routing.  It = defines the routing requirements for 6LoWPAN
networks, considering = the low-power and other particular
characteristics of the devices and = links.  The purpose of this
document is not to recommend = specific solutions, but to provide
general, layer-agnostic guidelines = about the design of 6LoWPAN
routing, which can lead to further = analysis and protocol design.
This document is intended as input to = groups working on routing
protocols relevant to 6LoWPAN, such as the = IETF ROLL WG.



The IETF = Secretariat.
_______________________________________________
6lowpan= mailing list
6lowpan@ietf.org
https://www.ietf.= org/mailman/listinfo/6lowpan

= = --Apple-Mail-298-744060917-- From cabo@tzi.org Fri Aug 7 06:10:50 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737BE3A6B53 for <6lowpan@core3.amsl.com>; Fri, 7 Aug 2009 06:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.755 X-Spam-Level: X-Spam-Status: No, score=-5.755 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1lOIAdOHDeJ for <6lowpan@core3.amsl.com>; Fri, 7 Aug 2009 06:10:49 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 05F213A6A66 for <6lowpan@ietf.org>; Fri, 7 Aug 2009 06:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n77DAeY4021192; Fri, 7 Aug 2009 15:10:40 +0200 (CEST) Received: from [192.168.217.107] (p5489E749.dip.t-dialin.net [84.137.231.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id D46D6BC56; Fri, 7 Aug 2009 15:10:39 +0200 (CEST) From: Carsten Bormann To: JP Vasseur In-Reply-To: References: <20090728155727.E8EF33A7056@core3.amsl.com> <77f1dba80907280906m1cdda4adv82e32c5f19e99ef1@mail.gmail.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 15:10:37 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-routing-requirements-04 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 07 Aug 2009 13:10:50 -0000 On Aug 7, 2009, at 10:36, JP Vasseur wrote: > In our world, routing is performed at the IP layer (RPL) so as to run on a myriad of L2. JP, too bad we didn't have time during the 6lowpan meeting to continue the discussion in Stockholm when it became interesting. To understand the confusion, you have to look back about three decades. In the mid-1970s, there was a gold-rush by different entities to establish their network architecture as the global standard. Everything about interoperability that we now take for granted in the Internet was unreachable utopia by then. The Open Systems Interconnection (OSI) project at ISO decided to develop a *Reference Model*, which was to bring order into the chaos by *prescribing* a layered architecture for the standardization that was going to be planned. You need to understand that ISO 7498 was much less a technical than a political document, trying to reign in the diverging lines of development. We all know where OSI went. However, the seven-layer model has become such a striking idol of network architecture that it has been used for introductory courses in networking ever since, even though it has been completely irrelevant for 15 years. The ARPANET/Internet community developed its own architecture, with TCP (later split into TCP/IP) at the middle, applications on top, and subnetworks below. This architecture has been written up in RFC 1122, section 1.1 -- please read. Note that when RFC 1122 talks about a link layer, it means the link to one of the subnetworks making up the Internet, not the subnetworks themselves -- the Internet architecture is subnetwork architecture agnostic! The *gateways* that speak a link layer protocol to the subnetworks only became *routers* later. The important observation is that OSI was a prescriptive full-stack model, designed essentially to ward off alternative designs. In contrast, the Internet architecture is a descriptive model of the layers around the Internet layer, with decreasing focus as we go further away from the Internet layer. In recent research, it has become clearer and clearer that the fixed-layers OSI model is constraining development and its straitjacket needs to be discarded to be able to move on. It is extremely unfortunate that we continue to describe protocol *functions* by OSI *layer* numbers: -- the OSI layer numbers don't fit the Internet model. E.g., TCP covers both L4 and certain parts of L5 in the OSI model. Of course, as the OSI model is only used as an idol and not as the actual obsolete specification it is now, nobody remembers that, so for many TCP now is a "layer 4" protocol. -- many functions are performed by multiple layers in the OSI model (e.g., reliability, flow control). Many functions *not* performed by a specific OSI layer *are* performed by the most equivalent layer in a modern architecture and v.v. -- the strict layering no longer works (see above). L2TP is above L3. Why use the layer numbers except as an extremely compact abbreviation? Sorry, I have given too many networking courses. Back to your argument. The argument that the routing function is always exclusively performed at the IP layer is invalid. It certainly was invalid for ARPANET (or CYCLADES, for that matter), which had their own elaborate routing protocols. It also certainly is invalid for 6LoWPAN networks such as ISA100 that employ mesh routing functionality at the subnetwork layer (which ISA100 calls DLL, Data Link Layer). However, at the political level, we generally don't do subnetworks in the IETF (nontrivial exceptions notwithstanding), so routing work in the IETF is indeed about IP routing. 6LoWPAN is designed based on the technical characteristics of IEEE 802.15.4 technology, but retains a degree of independence from some aspects of the subnetwork architecture. If the basic IEEE 802.15.4 functionality is augmented by routing functionality within the subnetwork layer, i.e., routing based on subnetwork identifiers (MAC addresses), the 6LoWPAN routing requirements apply to that. If the routing within the LoWPAN is done using IP identifiers, the 6LoWPAN requirements apply to that. RPL is an interesting candidate routing protocol for the latter, but also could be used for the former after adapting the identifier formats. The requirements are mostly independent of the identifier space being routed, and that is the reason the routing requirements document applies to both mesh-under and route-over. Gruesse, Carsten From alexandru.petrescu@gmail.com Mon Aug 17 02:26:53 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5B33A683A for <6lowpan@core3.amsl.com>; Mon, 17 Aug 2009 02:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.068 X-Spam-Level: X-Spam-Status: No, score=-1.068 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdcFRoFtI8Dd for <6lowpan@core3.amsl.com>; Mon, 17 Aug 2009 02:26:53 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id C99543A6DA6 for <6lowpan@ietf.org>; Mon, 17 Aug 2009 02:26:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n7H9Qmh7011831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Aug 2009 11:26:48 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n7H9QlEj027918; Mon, 17 Aug 2009 11:26:47 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n7H9QkIq025793; Mon, 17 Aug 2009 11:26:47 +0200 Message-ID: <4A892256.50606@gmail.com> Date: Mon, 17 Aug 2009 11:26:46 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Carsten Bormann References: <20090728155727.E8EF33A7056@core3.amsl.com> <77f1dba80907280906m1cdda4adv82e32c5f19e99ef1@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-routing-requirements-04 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 17 Aug 2009 09:26:53 -0000 Carsten Bormann a écrit : [large snip] > 6LoWPAN is designed based on the technical characteristics of IEEE > 802.15.4 technology, but retains a degree of independence from some > aspects of the subnetwork architecture. If the basic IEEE 802.15.4 > functionality is augmented by routing functionality within the > subnetwork layer, i.e., routing based on subnetwork identifiers (MAC > addresses), the 6LoWPAN routing requirements apply to that. If the > routing within the LoWPAN is done using IP identifiers, the 6LoWPAN > requirements apply to that. And what if 802.15.5 L2 mesh routing is used in a 802.15 network? I suppose both the 6LoWPAN adaptation layer and RPL become less necessary routing, in that case. I doubt the 6LoWPAN routing requirements apply to 802.15.5. Alex From trac@tools.ietf.org Mon Aug 17 08:18:00 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D554D3A6A3A for <6lowpan@core3.amsl.com>; Mon, 17 Aug 2009 08:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rfc0D3fLdwR2 for <6lowpan@core3.amsl.com>; Mon, 17 Aug 2009 08:18:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 463C63A6A1E for <6lowpan@ietf.org>; Mon, 17 Aug 2009 08:18:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Md3yH-00031K-4Z; Mon, 17 Aug 2009 08:18:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: jhui@archrock.com, zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 17 Aug 2009 15:18:05 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/47#comment:1 Message-ID: <069.a12b2b676c38648499bcfeaafc1723fc@tools.ietf.org> References: <060.f40c7d943c73a44f29901bbef0b43cbc@tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <060.f40c7d943c73a44f29901bbef0b43cbc@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jhui@archrock.com, zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #47: Context improvement X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 15:18:00 -0000 #47: Context improvement --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: jhui@archrock.com Type: enhancement | Status: closed Priority: major | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@sensinode.com): * status: new => closed * resolution: => fixed Comment: Fixed in -05. Solved using an updated 6LoWPAN Information Option as suggested on the mailing list. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 17 08:18:36 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C8428C146 for <6lowpan@core3.amsl.com>; Mon, 17 Aug 2009 08:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cgRgqo7FRgl for <6lowpan@core3.amsl.com>; Mon, 17 Aug 2009 08:18:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id B23883A6AE4 for <6lowpan@ietf.org>; Mon, 17 Aug 2009 08:18:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Md3yr-00053a-1d; Mon, 17 Aug 2009 08:18:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 17 Aug 2009 15:18:41 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/48#comment:2 Message-ID: <069.ebe261ab29cce9369063b4c4f87927a3@tools.ietf.org> References: <060.8ef1a86b33678026672bf7d555ba3de4@tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <060.8ef1a86b33678026672bf7d555ba3de4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #48: NR/NC improvements and router state X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 15:18:36 -0000 #48: NR/NC improvements and router state --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: enhancement | Status: closed Priority: major | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@sensinode.com): * status: new => closed * resolution: => fixed Comment: Done in nd-05. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 17 08:19:54 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740663A6DA5 for <6lowpan@core3.amsl.com>; Mon, 17 Aug 2009 08:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYJ47ICfztZo for <6lowpan@core3.amsl.com>; Mon, 17 Aug 2009 08:19:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 8DD0D3A6AA6 for <6lowpan@ietf.org>; Mon, 17 Aug 2009 08:19:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Md3zN-0007ng-TO; Mon, 17 Aug 2009 08:19:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 17 Aug 2009 15:19:13 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/46#comment:2 Message-ID: <069.c1229925afc3c8bb48b202ad53f22638@tools.ietf.org> References: <060.902319ec8a702615fa13c7248867dc4e@tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <060.902319ec8a702615fa13c7248867dc4e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #46: M-bit in the RA X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 15:19:54 -0000 #46: M-bit in the RA --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@sensinode.com): * status: new => closed * resolution: => fixed Comment: Done in nd-05. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 17 08:21:39 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957FA3A6F37 for <6lowpan@core3.amsl.com>; Mon, 17 Aug 2009 08:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-e2NsV4t5+u for <6lowpan@core3.amsl.com>; Mon, 17 Aug 2009 08:21:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id C68DE3A6F2A for <6lowpan@ietf.org>; Mon, 17 Aug 2009 08:21:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Md41n-0000DC-DY; Mon, 17 Aug 2009 08:21:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 17 Aug 2009 15:21:42 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/49#comment:1 Message-ID: <069.c35fd19b3e894296e3a17efd63f79a60@tools.ietf.org> References: <060.0233618d857e9213f8073f69ec1cdf07@tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <060.0233618d857e9213f8073f69ec1cdf07@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #49: Next-hop determination X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 15:21:39 -0000 #49: Next-hop determination --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: defect | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@sensinode.com): * status: new => closed * resolution: => fixed Comment: Done in nd-05. Neighbor cache and destination cache no longer needed. Included the possibility (MAY) for performing address resolution on the host-router interface using existing caches, for networks that for some reason need that. Thus relaxed the requirement for IID to link-layer address mapping, although true for vast majority of 6LoWPAN networks. -- Ticket URL: 6lowpan From richard.kelsey@ember.com Tue Aug 18 06:00:58 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035353A68F3 for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 06:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOGoBUPSHUmd for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 06:00:57 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 0213928C15A for <6lowpan@ietf.org>; Tue, 18 Aug 2009 06:00:56 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 08:26:26 -0400 Date: Tue, 18 Aug 2009 08:26:50 -0400 Message-Id: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com> To: 6lowpan@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 18 Aug 2009 12:26:26.0633 (UTC) FILETIME=[1B29DB90:01CA1FFF] Subject: [6lowpan] making progress on fragmentation X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 18 Aug 2009 13:00:58 -0000 I would like to work towards the adoption of Pascal's fragmentation draft (draft-thubert-6lowpan-simple-fragment- recovery) as a working group document. Partly for the reason giving in the draft, that retries are needed to make delivery of large packets reliable, but also because retries are needed to make delivery of *small* packets reliable. With Ember's earlier, non-IP stacks, we have found that customers expect IP-like reliability even from non-IP protocols. We have gotten reliable delivery (as reliable as UDP packets in the Internet, say) on a radio mesh only by repairing routes without dropping data packets. The hard part of route repair is knowing when to do it. The most reliabile way is to use end-to-end ACKs within the mesh. Using NACKs would be more efficient that ACKs, but these are lossy networks and NACKs are even less reliable than data packets, because they only get sent when something is already broken. When a route breaks, we get the following sequence of events: 1. send a packet 2. fail to receive an ACK 3. update the route 4. resend the packet This has allowed us to get end-to-end mesh reliability approaching that expected from IP links. The usual higher-level IP retry mechanisms can take over from there. (Sending fragments multiple hops in a route-over network will require some kind of label switching. That will need to be discussed over in ROLL.) How close are we to consensus on Pascal's draft? What needs to be fixed/improved/removed? -Richard Kelsey From cabo@tzi.org Tue Aug 18 06:26:43 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985CA28C144 for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 06:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.879 X-Spam-Level: X-Spam-Status: No, score=-5.879 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Asyxj3lYTu9c for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 06:26:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 4628328C140 for <6lowpan@ietf.org>; Tue, 18 Aug 2009 06:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n7IDQWNs022446; Tue, 18 Aug 2009 15:26:32 +0200 (CEST) Received: from [192.168.217.101] (p5489F20B.dip.t-dialin.net [84.137.242.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id AD319BC2E; Tue, 18 Aug 2009 15:26:31 +0200 (CEST) From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> In-Reply-To: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com> References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com> Message-Id: <4186F14A-435F-4C74-9D31-31BF03A6C1A2@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 15:26:30 +0200 X-Mailer: Apple Mail (2.936) Subject: [6lowpan] Call for working group adoption (Re: making progress on fragmentation) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 18 Aug 2009 13:26:43 -0000 Richard, thank you for seconding Pascal's draft. We have had multiple discussions of the fragment recovery drafts in IETF meetings. Each time, we found some aspect some of us didn't like, and then Pascal submitted an updated version solving that problem. The only thing that got considerable push-back this time was that the draft shouldn't try to deprecate 4944's fragment headers. I think this is a statement that could easily be taken out in a working group draft submission. (Of course, any other technical wrinkles can be ironed out during the period the document is a WG draft.) So I would like to take the opportunity to ask here on the mailing list whether we should adopt http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-06 (with the abovementioned change) as a working group document. --> If you want to advance this draft, please indicate your support on the mailing list. If you think this is a bad idea, please say so, too. (I would like to receive responses by this Friday, Aug 21, as I'm going on vacation after that.) Note that we also have to hear from our AD on this item, as it is not formally on our charter. A year ago, Mark Townsley gave us some form of go ahead when we discussed whether we should be delaying the charter for adding this as a work item. He said that waiting wasn't necessary, and we were free to start work. http://www.mail-archive.com/6lowpan@ietf.org/msg01114.html Still, we would need to add a line item under the deliverables, and our new AD would have to concur -- which is probably easiest after the yays and nays. Gruesse, Carsten From rdroms@cisco.com Tue Aug 18 06:37:39 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197A728C1A5 for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 06:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmYGLB4q42aJ for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 06:37:38 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2219428C1A4 for <6lowpan@ietf.org>; Tue, 18 Aug 2009 06:37:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANNLikpAZnmf/2dsb2JhbADAAIgtkDwFhBk X-IronPort-AV: E=Sophos;i="4.43,402,1246838400"; d="scan'208";a="54476081" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Aug 2009 13:37:14 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7IDbEj3008063; Tue, 18 Aug 2009 09:37:14 -0400 Received: from bxb-rdroms-8714.cisco.com (bxb-rdroms-8714.cisco.com [10.98.10.85]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7IDb9WU003091; Tue, 18 Aug 2009 13:37:14 GMT Message-Id: <0C6EA69F-2455-4A8F-96BB-596576A790FB@cisco.com> From: Ralph Droms To: Carsten Bormann In-Reply-To: <4186F14A-435F-4C74-9D31-31BF03A6C1A2@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 18 Aug 2009 09:37:03 -0400 References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com> <4186F14A-435F-4C74-9D31-31BF03A6C1A2@tzi.org> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2219; t=1250602634; x=1251466634; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[6lowpan]=20Call=20for=20working=20grou p=20adoption=20(Re=3A=20making=20progress=20on=20fragmentati on) |Sender:=20 |To:=20Carsten=20Bormann=20; bh=R1UN45dBB7eUJlOs85Jh+/Kk00Amyh8dveVs2EolaD4=; b=KWPeHUJLNZ01R0K/Bk1ijWZF1htIS7jc5EFO08bD0aU8V9w4luWf2K/KGy dPPaDSKeANYPbIqgWV5MPCCxpj20A9nqdknFHy4YL+v7hxkenDJ7Ic4KzKKY cHdW192Ak5; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Call for working group adoption (Re: making progress on fragmentation) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 18 Aug 2009 13:37:39 -0000 I've had a couple of off-line discussions; now seems like a good time to ask the WG: does anyone have empirical evidence about the impact of fragment loss in 802.15.4 networks that would motivate the need for reliable fragment delivery? - Ralph On Aug 18, 2009, at 9:26 AM 8/18/09, Carsten Bormann wrote: > Richard, > > thank you for seconding Pascal's draft. > > We have had multiple discussions of the fragment recovery drafts in > IETF meetings. > Each time, we found some aspect some of us didn't like, and then > Pascal submitted an updated version solving that problem. > The only thing that got considerable push-back this time was that > the draft shouldn't try to deprecate 4944's fragment headers. > I think this is a statement that could easily be taken out in a > working group draft submission. > (Of course, any other technical wrinkles can be ironed out during > the period the document is a WG draft.) > > So I would like to take the opportunity to ask here on the mailing > list whether we should adopt > http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-06 > (with the abovementioned change) as a working group document. > > --> > If you want to advance this draft, please indicate your support on > the mailing list. > If you think this is a bad idea, please say so, too. > (I would like to receive responses by this Friday, Aug 21, as I'm > going on vacation after that.) > > Note that we also have to hear from our AD on this item, as it is > not formally on our charter. > A year ago, Mark Townsley gave us some form of go ahead when we > discussed whether we should be delaying the charter for adding this > as a work item. > He said that waiting wasn't necessary, and we were free to start work. > http://www.mail-archive.com/6lowpan@ietf.org/msg01114.html > Still, we would need to add a line item under the deliverables, and > our new AD would have to concur -- which is probably easiest after > the yays and nays. > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Tue Aug 18 06:54:45 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF2F3A6C26 for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 06:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sRjiLqVu3sL for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 06:54:44 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id EA8D03A6B33 for <6lowpan@ietf.org>; Tue, 18 Aug 2009 06:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n7IDs6s9003003; Tue, 18 Aug 2009 15:54:06 +0200 (CEST) Received: from [192.168.217.101] (p5489F20B.dip.t-dialin.net [84.137.242.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 5ABEEBC5B; Tue, 18 Aug 2009 15:54:06 +0200 (CEST) From: Carsten Bormann To: Richard Kelsey In-Reply-To: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com> References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 15:54:05 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] making progress on fragmentation X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 18 Aug 2009 13:54:45 -0000 > (Sending fragments multiple hops in a route-over network > will require some kind of label switching. That will need > to be discussed over in ROLL.) To document what everyone has been saying on the hallway: If you think strictly in layers, you have to reassemble the packet on each L2/L3 boundary, and then re-fragment on each L3/L2 boundary. However, the following optimization is obvious to anyone skilled in the art of layer violation: 1) Upon receiving an initial fragment for a tuple (SA, DA, datagram size, datagram tag), if there is no reassembly buffer, do not create an actual full reassembly buffer, but just a rump data structure that records the IP addresses in that first fragment as well as the coverage of the packet space by actual data forwarded. Forward (or deliver locally) the fragment based on the IP addresses. 2) Upon receiving a non-initial fragment, if there already is a rump reassembly buffer for the tuple, forward based on that, and record coverage. Otherwise, create a full reassembly buffer with the data received -- it might be for you! 3) Upon receiving an initial fragment for a tuple that has a full reassembly buffer, (if not for local delivery) forward the initial fragment, record the IP addresses (and the coverage). Then pump out the data in the reassembly buffer as bandwidth permits. Each time a (full or rump) reassembly buffer gets full coverage, drop it (or keep it some short additional amount of time to account for late-coming duplicates). Of course, the uncertainty when to drop reassembly buffers remains, but at least you don't have to keep the actual data (as soon as you have the initial fragment). The way the (lack of) information works resequences on every hop, so the likelihood of initial fragments missing is limited. What we didn't provide in 4944 was a way to indicate "It's for you" in each fragment. The last-hop sender may not always know, but when it does, having that information might help with buffer management. Gruesse, Carsten From richard.kelsey@ember.com Tue Aug 18 07:36:28 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F62D28C1AE for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 07:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv0dyfisoCb6 for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 07:36:27 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4C1E03A6B04 for <6lowpan@ietf.org>; Tue, 18 Aug 2009 07:36:27 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 10:36:45 -0400 Date: Tue, 18 Aug 2009 10:37:10 -0400 Message-Id: <87hbw52nop.fsf@kelsey-ws.hq.ember.com> To: Carsten Bormann In-reply-to: (message from Carsten Bormann on Tue, 18 Aug 2009 15:54:05 +0200) From: Richard Kelsey References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 18 Aug 2009 14:36:45.0897 (UTC) FILETIME=[4FCEDB90:01CA2011] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] making progress on fragmentation X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 18 Aug 2009 14:36:28 -0000 From: Carsten Bormann Date: Tue, 18 Aug 2009 15:54:05 +0200 Cc: 6lowpan@ietf.org > (Sending fragments multiple hops in a route-over network > will require some kind of label switching. That will need > to be discussed over in ROLL.) To document what everyone has been saying on the hallway: We clearly hang out in different hallways :-). If you think strictly in layers, you have to reassemble the packet on each L2/L3 boundary, and then re-fragment on each L3/L2 boundary. However, the following optimization is obvious to anyone skilled in the art of layer violation: [... store routing data from the initial fragment for use in forwarding subsequent ones ...] The difficulty is that the various fragments may easily take different paths through the mesh. Even if no route changes occur, there may still be multiple paths. The current RPL draft, for example, allows a router to maintain multiple next hops for a given DAG root. A router that alternates between two next hops for load balancing is going to be a bit of a problem. -Richard Kelsey From richard.kelsey@ember.com Tue Aug 18 08:01:18 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E235B3A6AB1 for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 08:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol0-a109CRrm for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 08:01:18 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 06E7B3A69ED for <6lowpan@ietf.org>; Tue, 18 Aug 2009 08:01:17 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 11:01:44 -0400 Date: Tue, 18 Aug 2009 11:02:08 -0400 Message-Id: <87fxbp2mj3.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey In-reply-to: <87hbw52nop.fsf@kelsey-ws.hq.ember.com> (message from Richard Kelsey on Tue, 18 Aug 2009 10:37:10 -0400) From: Richard Kelsey References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com> <87hbw52nop.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 18 Aug 2009 15:01:44.0696 (UTC) FILETIME=[CD296F80:01CA2014] Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] making progress on fragmentation X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 18 Aug 2009 15:01:19 -0000 In responding to Carsten, I wrote: If you think strictly in layers, you have to reassemble the packet on each L2/L3 boundary, and then re-fragment on each L3/L2 boundary. However, the following optimization is obvious to anyone skilled in the art of layer violation: [... store routing data from the initial fragment for use in forwarding subsequent ones ...] The difficulty is that the various fragments may easily take different paths through the mesh. Even if no route changes occur, there may still be multiple paths. The current RPL draft, for example, allows a router to maintain multiple next hops for a given DAG root. A router that alternates between two next hops for load balancing is going to be a bit of a problem. Please ignore all that. I am clearly not skilled in the art of layer violation and will need to think about this some more. -Richard Kelsey From cabo@tzi.org Tue Aug 18 08:05:41 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB9B3A6E82 for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 08:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg1rEitRoQbj for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 08:05:41 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id D7A623A6E7E for <6lowpan@ietf.org>; Tue, 18 Aug 2009 08:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n7IF5XFq008050; Tue, 18 Aug 2009 17:05:34 +0200 (CEST) Received: from [192.168.217.101] (p5489F20B.dip.t-dialin.net [84.137.242.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 9E53CBCB2; Tue, 18 Aug 2009 17:05:33 +0200 (CEST) From: Carsten Bormann To: Richard Kelsey In-Reply-To: <87hbw52nop.fsf@kelsey-ws.hq.ember.com> References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com> <87hbw52nop.fsf@kelsey-ws.hq.ember.com> Message-Id: <0F37DF94-C13F-4ECB-86E3-5C0F79F3ECF1@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 17:05:32 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] making progress on fragmentation X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 18 Aug 2009 15:05:42 -0000 On Aug 18, 2009, at 16:37, Richard Kelsey wrote: > A router that alternates > between two next hops for load balancing is going to be a > bit of a problem. Indeed; so the procedure I have described would benefit from recording the next hop chosen in the rump reassembly buffer. (Another obvious hack would be to send the initial fragment to both/ all next hops; unfortunately the obvious optimization of only sending the actual data to one of them and just the first bytes with the addresses to other other ones is outlawed by 4944, page 12, penultimate paragraph.) Gruesse, Carsten From pthubert@cisco.com Tue Aug 18 08:26:49 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7635828C26E for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 08:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.745 X-Spam-Level: X-Spam-Status: No, score=-7.745 tagged_above=-999 required=5 tests=[AWL=-1.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlCoo9+uwVbD for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 08:26:48 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6B4DD28C251 for <6lowpan@ietf.org>; Tue, 18 Aug 2009 08:26:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACNlikqQ/uCK/2dsb2JhbAC/e4gtLgiQDQWCRQiBTIFTXA X-IronPort-AV: E=Sophos;i="4.43,402,1246838400"; d="scan'208";a="54525613" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2009 15:26:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7IFQqtU013567; Tue, 18 Aug 2009 17:26:52 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7IFQqjD016975; Tue, 18 Aug 2009 15:26:52 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 17:26:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Aug 2009 17:26:46 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0D07E7@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] making progress on fragmentation Thread-Index: AcogC4gn/35oXwtGSJyh2OrYtMPGeQADGw5Q References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "Richard Kelsey" X-OriginalArrivalTime: 18 Aug 2009 15:26:51.0886 (UTC) FILETIME=[4F8460E0:01CA2018] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2730; t=1250609212; x=1251473212; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20making=20progress=20on=20fr agmentation |Sender:=20; bh=MQxAM8mW6KeAc7INtesXLje1h8Or8EHwQiwgMyoyBcg=; b=MruF7OViYXG1G+zHbYSwW8HlPxfkRSp1yMnbE+uYT0aeRycPofrg2X+hX+ WoXIJZAPBXuqiuaXVkJ7mQV3enC9khqKtLARTX83hudlkGkS1qb1j6UFcK5i vtzRlwEknf; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] making progress on fragmentation X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 18 Aug 2009 15:26:49 -0000 Hi Carsten You right. But please also include mesh under in your reasoning; I = initially crafted this work in the light of the work at ISA100.11a, that = is mesh under and thus needs end to end recovery. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Carsten Bormann >Sent: mardi 18 ao=FBt 2009 15:54 >To: Richard Kelsey >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] making progress on fragmentation > >> (Sending fragments multiple hops in a route-over network >> will require some kind of label switching. That will need >> to be discussed over in ROLL.) > >To document what everyone has been saying on the hallway: > >If you think strictly in layers, you have to reassemble the packet on >each L2/L3 boundary, and then re-fragment on each L3/L2 boundary. >However, the following optimization is obvious to anyone skilled in >the art of layer violation: > >1) Upon receiving an initial fragment for a tuple (SA, DA, datagram >size, datagram tag), if there is no reassembly buffer, do not create >an actual full reassembly buffer, but just a rump data structure that >records the IP addresses in that first fragment as well as the >coverage of the packet space by actual data forwarded. Forward (or >deliver locally) the fragment based on the IP addresses. >2) Upon receiving a non-initial fragment, if there already is a rump >reassembly buffer for the tuple, forward based on that, and record >coverage. Otherwise, create a full reassembly buffer with the data >received -- it might be for you! >3) Upon receiving an initial fragment for a tuple that has a full >reassembly buffer, (if not for local delivery) forward the initial >fragment, record the IP addresses (and the coverage). Then pump out >the data in the reassembly buffer as bandwidth permits. > >Each time a (full or rump) reassembly buffer gets full coverage, drop >it (or keep it some short additional amount of time to account for >late-coming duplicates). > >Of course, the uncertainty when to drop reassembly buffers remains, >but at least you don't have to keep the actual data (as soon as you >have the initial fragment). The way the (lack of) information works >resequences on every hop, so the likelihood of initial fragments >missing is limited. > >What we didn't provide in 4944 was a way to indicate "It's for you" in >each fragment. The last-hop sender may not always know, but when it >does, having that information might help with buffer management. > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Tue Aug 18 09:27:27 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1EFF3A6E7E for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 09:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjT34Cun0sdJ for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 09:27:27 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 855AD3A683F for <6lowpan@ietf.org>; Tue, 18 Aug 2009 09:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n7IGRNKK005082 for <6lowpan@ietf.org>; Tue, 18 Aug 2009 18:27:23 +0200 (CEST) Received: from [192.168.217.101] (p5489F20B.dip.t-dialin.net [84.137.242.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id DDFD5BD07; Tue, 18 Aug 2009 18:27:22 +0200 (CEST) Message-Id: <0A5E490A-5E03-4741-8F34-F001EABCE91D@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> In-Reply-To: <0C6EA69F-2455-4A8F-96BB-596576A790FB@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 18 Aug 2009 18:27:21 +0200 References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com> <4186F14A-435F-4C74-9D31-31BF03A6C1A2@tzi.org> <0C6EA69F-2455-4A8F-96BB-596576A790FB@cisco.com> X-Mailer: Apple Mail (2.936) Subject: Re: [6lowpan] Call for working group adoption (Re: making progress on fragmentation) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 18 Aug 2009 16:27:27 -0000 On Aug 18, 2009, at 15:37, Ralph Droms wrote: > does anyone have empirical evidence about the impact of fragment > loss in 802.15.4 networks that would motivate the need for reliable > fragment delivery? (no WG chair hat:) I can't answer that question. But it is important to describe the applicability of http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-06 some more. As it stands, the draft addresses the mesh-under case. There is little gain for the hop-by-hop fragmentation/reassembly implied by route-over; it is also not clear how to apply the draft to the route- over fragmentation optimization I described in the other sub-thread (who would send the FRACK?). We do have "fragment recovery" in 4944 in the sense that it is (lower- case) recommended to use 802.15.4's link-layer ACK to increase the reliability of each (L2) hop (4944, Section 2, first paragraph). What we don't have is recovery on the whole L2 path from the fragmenting L3/L2 boundary (mesh-under ingress, MUI) to the reassembling L2/L3 boundary (mesh-under egress, MUE). The argument I have understood for the draft is that there may be (MU) route changes (possibly including MU multipath routing) between MUI and MUE during transmission of the fragments of a single (larger) packet, causing some parts to be lost even with good use of per-hop acknowledgements. A 1280 byte packet will take some 40 ms of pure airtime on 2.4 GHz or some 500 ms on .868 GHz. Multiply this by a realistic media sharing multiplier, and there does appear some opportunity for radio characteristics to change during that time. But that is just a hunch, and some numbers from a real-life network would indeed help. For now, my (WG member) answer to the WG chair's question whether we should adopt that draft is a luke-warm "I wouldn't mind". Gruesse, Carsten From richard.kelsey@ember.com Tue Aug 18 13:33:47 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2333A6A17 for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 13:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtuy2EGQGfdr for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 13:33:46 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 8C88A3A68AC for <6lowpan@ietf.org>; Tue, 18 Aug 2009 13:33:46 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 16:34:21 -0400 Date: Tue, 18 Aug 2009 16:34:46 -0400 Message-Id: <87eir8g8t5.fsf@kelsey-ws.hq.ember.com> To: Ralph Droms In-reply-to: <0C6EA69F-2455-4A8F-96BB-596576A790FB@cisco.com> (message from Ralph Droms on Tue, 18 Aug 2009 09:37:03 -0400) From: Richard Kelsey References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com> <4186F14A-435F-4C74-9D31-31BF03A6C1A2@tzi.org> <0C6EA69F-2455-4A8F-96BB-596576A790FB@cisco.com> X-OriginalArrivalTime: 18 Aug 2009 20:34:21.0880 (UTC) FILETIME=[44920B80:01CA2043] Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] Call for working group adoption (Re: making progress on fragmentation) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 18 Aug 2009 20:33:47 -0000 From: Ralph Droms Date: Tue, 18 Aug 2009 09:37:03 -0400 I've had a couple of off-line discussions; now seems like a good time to ask the WG: does anyone have empirical evidence about the impact of fragment loss in 802.15.4 networks that would motivate the need for reliable fragment delivery? I do not have any empirical evidence on the impact of fragment loss. I do have empirical evidence on the utility of end-to-end ACKs for message reliability in a 802.15.4 mesh. The need for end-to-end ACKs stems from the lack of any reliable self-repair mechanism for mesh routes. When a route breaks, it isn't enough to wait and resend. Often some kind of active repair is needed. Speaking figuratively, when a backhoe cuts a cable, you have to send a truck. In advocating for Pascal's fragmentation proposal I am trying to kill four birds with two stones. The birds are: - using end-to-end ACKs to detect when routes are broken - avoiding the need to reassemble and refragment large packets in a route-over network - increasing the reliability of large, fragmented packets - compact and efficient source routing The stones are: - Pascal's proposal or something like it - LoWPAN-compatible label switching -Richard Kelsey From pthubert@cisco.com Wed Aug 19 00:16:55 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB24F28C242 for <6lowpan@core3.amsl.com>; Wed, 19 Aug 2009 00:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.663 X-Spam-Level: X-Spam-Status: No, score=-9.663 tagged_above=-999 required=5 tests=[AWL=0.936, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52PALRh9L18T for <6lowpan@core3.amsl.com>; Wed, 19 Aug 2009 00:16:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9377F28C18F for <6lowpan@ietf.org>; Wed, 19 Aug 2009 00:16:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloAAAdEi0qQ/uCLe2dsb2JhbACbDAEBFiQGoiaILZEzBYQZgi8 X-IronPort-AV: E=Sophos;i="4.43,407,1246838400"; d="scan'208";a="47394156" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Aug 2009 07:16:58 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7J7GwAd007987; Wed, 19 Aug 2009 09:16:58 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7J7Gw1q009301; Wed, 19 Aug 2009 07:16:58 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 09:16:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Aug 2009 09:16:48 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0D0912@XMB-AMS-107.cisco.com> In-Reply-To: <87fxbp2mj3.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] making progress on fragmentation Thread-Index: AcogFMQmxL6AyRwbS8O3rGNzYAKWJwAA+TTg References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com><87hbw52nop.fsf@kelsey-ws.hq.ember.com> <87fxbp2mj3.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 19 Aug 2009 07:16:58.0657 (UTC) FILETIME=[0A335110:01CA209D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2281; t=1250666218; x=1251530218; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20making=20progress=20on=20fr agmentation |Sender:=20; bh=2KPmv3GL4lgQcUzuY41FLMhTmJc8BO8DkwORAZjZdaw=; b=vStQ4yjGObwlR84MKqcOpl9uQOjLqEe3UoGd8w0+SFEBR+3BTldzLpaK7m TL6wbBJDS4rSnr9BcDQIkNjUA7AxiStcZRJ2K+sPKVa8ANKh6AlBBp7PuiMC QAOxPaiD9i; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] making progress on fragmentation X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 19 Aug 2009 07:16:55 -0000 Hi Richard: Upon the first fragment, the trick is to lay an label along the path = followed by that fragment (that is IP routed), and all further fragments = are label switched along that path. So alternate routes are not possible = for fragments. The label game is played by swapping the datagram_tag to = make a new locally significant one at each hop. I'm ready to accept such = a violation considering the penalty of reassembling at each hop :) The fragment recovery helps in a number of fashions: - it provides explicit signaling that the reception is complete and thus = enables to clean up intermediate states. - it enables the source to swap a path by resending a first fragment = that will take a new route - and then the obvious, recovery and flow control. Too bad ECN is gone = for the time being. Cheers, Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Richard Kelsey >Sent: mardi 18 ao=FBt 2009 17:02 >To: Richard Kelsey >Cc: cabo@tzi.org; 6lowpan@ietf.org >Subject: Re: [6lowpan] making progress on fragmentation > >In responding to Carsten, I wrote: > > If you think strictly in layers, you have to reassemble the = packet on > each L2/L3 boundary, and then re-fragment on each L3/L2 boundary. > However, the following optimization is obvious to anyone skilled = in > the art of layer violation: > > [... store routing data from the initial fragment for use > in forwarding subsequent ones ...] > > The difficulty is that the various fragments may easily take > different paths through the mesh. Even if no route changes > occur, there may still be multiple paths. The current RPL > draft, for example, allows a router to maintain multiple > next hops for a given DAG root. A router that alternates > between two next hops for load balancing is going to be a > bit of a problem. > >Please ignore all that. I am clearly not skilled in >the art of layer violation and will need to think >about this some more. > -Richard Kelsey >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From richard.kelsey@ember.com Wed Aug 19 06:44:58 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037103A6F67 for <6lowpan@core3.amsl.com>; Wed, 19 Aug 2009 06:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqqlyE1kMz8S for <6lowpan@core3.amsl.com>; Wed, 19 Aug 2009 06:44:57 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id D3F1228C3D6 for <6lowpan@ietf.org>; Wed, 19 Aug 2009 06:44:40 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 09:45:16 -0400 Date: Wed, 19 Aug 2009 09:45:41 -0400 Message-Id: <87d46r3oje.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D0D0912@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com><87hbw52nop.fsf@kelsey-ws.hq.ember.com> <87fxbp2mj3.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0D0912@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 19 Aug 2009 13:45:16.0743 (UTC) FILETIME=[48F11D70:01CA20D3] Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] making progress on fragmentation X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 19 Aug 2009 13:44:58 -0000 Date: Wed, 19 Aug 2009 09:16:48 +0200 From: "Pascal Thubert (pthubert)" Pascal, Upon the first fragment, the trick is to lay an label along the path followed by that fragment (that is IP routed), and all further fragments are label switched along that path. So alternate routes are not possible for fragments. I did eventually realize that Carsten was describing using datagram tags as labels. You could get end-to-end ACKs in this scheme by having only the destination intiate ACKs and only the source initiate retries. Intermediate nodes would only relay fragments and ACKs. This would require an explicit description of the process, rather than leaving it up to implementors. The label game is played by swapping the datagram_tag to make a new locally significant one at each hop. This works only if all fragments take the same path. Fragments that took different paths would arrive at the destination with different datagram_tags and not be associated with one another. On the other hand, if you don't swap the datagram_tags you are vulnerable to collisions. I'm ready to accept such a violation considering the penalty of reassembling at each hop :) I would prefer to have explicit labelling, both for clarity and because it could be used for sequences of short packets as well as for fragmented long packets. The fragment recovery helps in a number of fashions: - it provides explicit signaling that the reception is complete and thus enables to clean up intermediate states. - it enables the source to swap a path by resending a first fragment that will take a new route For a packet that doesn't fit evenly into N fragments you could make the first fragment shorter and have all subsequent fragments be of maximal size. -Richard Kelsey From pthubert@cisco.com Wed Aug 19 08:38:23 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196E73A6A04 for <6lowpan@core3.amsl.com>; Wed, 19 Aug 2009 08:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.726 X-Spam-Level: X-Spam-Status: No, score=-9.726 tagged_above=-999 required=5 tests=[AWL=0.873, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3gpHN+9nJH8 for <6lowpan@core3.amsl.com>; Wed, 19 Aug 2009 08:38:21 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 577C93A694F for <6lowpan@ietf.org>; Wed, 19 Aug 2009 08:38:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkAADy5i0qQ/uCLe2dsb2JhbACbDQEBFiQGoWaIL5FSBYQagVM X-IronPort-AV: E=Sophos;i="4.43,408,1246838400"; d="scan'208";a="47440924" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Aug 2009 15:38:25 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7JFcP68007672; Wed, 19 Aug 2009 17:38:25 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7JFcPe0000346; Wed, 19 Aug 2009 15:38:25 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 17:38:25 +0200 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 Date: Wed, 19 Aug 2009 17:38:19 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0D0B75@XMB-AMS-107.cisco.com> In-Reply-To: <87d46r3oje.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] making progress on fragmentation Thread-Index: Acog0zlT6Gzk9an3Sl6u+liTqkjgUQACm8Gw References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com><87hbw52nop.fsf@kelsey-ws.hq.ember.com> <87fxbp2mj3.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0D0912@XMB-AMS-107.cisco.com> <87d46r3oje.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 19 Aug 2009 15:38:25.0563 (UTC) FILETIME=[1764D6B0:01CA20E3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4380; t=1250696305; x=1251560305; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20making=20progress=20on=20fr agmentation |Sender:=20; bh=tcJI6pcgX56aB7CKUKPYguSZ9j8z8216TN9NOmBnjFo=; b=NyoL1th3O2w2CnXKDA39nTgaGyFrdTcUqWSmzR19IfELsg/OivxPuNAe5+ KuYxDTfCyrKPmokNnybUJrZtAncarppEZl67ex8ePdoiGxtjiKXk4BRMkhaG 1avGpDpOtt; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] making progress on fragmentation X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 19 Aug 2009 15:38:23 -0000 Hi Richard: > > Upon the first fragment, the trick is to lay an label along the path > followed by that fragment (that is IP routed), and all further > fragments are label switched along that path. So alternate routes are > not possible for fragments. > >I did eventually realize that Carsten was describing >using datagram tags as labels. In more words: In route over the L2 source changes at each hop. The datagram tag is associated to the source MAC and only valid (and unique) for that source MAC. Upon a first fragment: ---------------------- Source IPv6 address =3D IP_A (maybe hops away) Destination IPv6 address = =3D IP_B (maybe hops away) Source MAC =3D MAC_prv Datagram_tag=3D DT_prv - do a route lookup and get Next hop IPv6 to B =3D IP_nxt - do a ND resolution and get IP_nxt MAC =3D MAC_nxt Since it is a first fragment of a packet from that source MAC MAC_prv for that tag DT_prv: - clean up any leftover resource associated to the tupple (MAC_prv, DT_prv) - allocate a new label for that flow, DT_nxt, from a LRU pool or something. - allocate a Label swap structure for (MAC_prv, DT_prv) that contains (MAC_nxt, DT_nxt) - allocate a Label swap structure for (MAC_nxt, DT_nxt) that contains (MAC_prv, DT_prv) - swap the MAC info to "from me to MAC_nxt"; Swap the datagram_tag to DT_nxt; Forward. Upon next fragments (that are not first fragments) -------------------------------------------------- - lookup (MAC_nxt, DT_nxt) to get (MAC_prv, DT_prv) - If not found drop fragment. (ICMP error back could be possible) - else swap mac and tag and forward, as before Upon fr-acks: ---------- - lookup (MAC_nxt, DT_nxt) to get (MAC_prv, DT_prv) - If not found drop. - else swap mac and tag and forward, as before - if the bitmap is acks all (could change the draft to make it all ones) or errors (all zeroes) cleanup resource Add some aging stuff to clean up stale states and there you are :) >You could get end-to-end ACKs in this scheme by having >only the destination intiate ACKs and only the source >initiate retries. Intermediate nodes would only relay >fragments and ACKs. This would require an explicit >description of the process, rather than leaving it up >to implementors. Sure > > The label game is played by swapping the datagram_tag to > make a new locally significant one at each hop. > >This works only if all fragments take the same path. >Fragments that took different paths would arrive at >the destination with different datagram_tags and not >be associated with one another. On the other hand, >if you don't swap the datagram_tags you are vulnerable >to collisions. Agreed; They have to since the first fragment sets the path. The key consequence is that we cannot benefit from rerouting along a DAG.=20 So we end up with the loss statistics of one link times the number of hops. IOW the fragment recovery is badly needed if we play this game. > I'm ready to accept such a violation considering the > penalty of reassembling at each hop :) > >I would prefer to have explicit labelling, both for >clarity and because it could be used for sequences of >short packets as well as for fragmented long packets. Makes sense. Ideally both would look and feel the same to the intermediate nodes. At the end of day the difference could be subtle, like a type or something. I'm also interested in cleanly removing the states when all done. It appears that with the local operation above any node can play the game or not without knowledge that the peers also do. In other words, we could reassemble along the way and only nodes that wish/know_how_to skip the process would do so. > The fragment recovery helps in a number of fashions: > > - it provides explicit signaling that the reception is complete and > thus enables to clean up intermediate states. > > - it enables the source to swap a path by resending a first fragment > that will take a new route > >For a packet that doesn't fit evenly into N fragments you >could make the first fragment shorter and have all >subsequent fragments be of maximal size. > Neat. I also like the idea of enabling fragments not to be fragments but a series of packets. Cheers, Pascal > -Richard Kelsey From richard.kelsey@ember.com Wed Aug 19 09:35:21 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8353A69F3 for <6lowpan@core3.amsl.com>; Wed, 19 Aug 2009 09:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ-+PdS8c5yR for <6lowpan@core3.amsl.com>; Wed, 19 Aug 2009 09:35:20 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6452E3A67AC for <6lowpan@ietf.org>; Wed, 19 Aug 2009 09:35:20 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 12:35:56 -0400 Date: Wed, 19 Aug 2009 12:36:21 -0400 Message-Id: <87ab1v3gmy.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D0D0B75@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com><87hbw52nop.fsf@kelsey-ws.hq.ember.com> <87fxbp2mj3.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0D0912@XMB-AMS-107.cisco.com> <87d46r3oje.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0D0B75@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 19 Aug 2009 16:35:56.0368 (UTC) FILETIME=[203BE500:01CA20EB] Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] making progress on fragmentation X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 19 Aug 2009 16:35:21 -0000 Date: Wed, 19 Aug 2009 17:38:19 +0200 From: "Pascal Thubert (pthubert)" Pascal, In route over the L2 source changes at each hop. The datagram tag is associated to the source MAC and only valid (and unique) for that source MAC. Upon a first fragment: ---------------------- [...] Upon next fragments (that are not first fragments) -------------------------------------------------- [...] Upon fr-acks: ---------- - lookup (MAC_nxt, DT_nxt) to get (MAC_prv, DT_prv) - If not found drop. - else swap mac and tag and forward, as before - if the bitmap is acks all (could change the draft to make it all ones) or errors (all zeroes) cleanup resource You have to be careful about cleaning up just because you see a complete ack. Transmission is unreliable in both directions. If an intermediate node deletes the record and the source fails to get the complete ack, the source will start over from the beginning, even though the destination already has the packet. And with the label/datagram_tag swapping, the destination has no way of knowing that the retransmission is a copy of a packet it has already received. It appears that with the local operation above any node can play the game or not without knowledge that the peers also do. In other words, we could reassemble along the way and only nodes that wish/know_how_to skip the process would do so. I still think that there needs to be a way to distinguish between an intermittent problem, where just resending a dropped fragment is enough, and a broken route. This gets a lot harder if an intermediate node might reassemble the packet. -Richard Kelsey From pthubert@cisco.com Thu Aug 20 02:08:15 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3383A6929 for <6lowpan@core3.amsl.com>; Thu, 20 Aug 2009 02:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.828 X-Spam-Level: X-Spam-Status: No, score=-9.828 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOFJGsApQLp5 for <6lowpan@core3.amsl.com>; Thu, 20 Aug 2009 02:08:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0322B3A6D95 for <6lowpan@ietf.org>; Thu, 20 Aug 2009 02:08:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsAAE+vjEqQ/uCLe2dsb2JhbACbCwEBFiQGoBuIL5FBBYQa X-IronPort-AV: E=Sophos;i="4.43,413,1246838400"; d="scan'208";a="47489273" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Aug 2009 09:08:18 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7K98IAg021781; Thu, 20 Aug 2009 11:08:18 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7K98Iex023737; Thu, 20 Aug 2009 09:08:18 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 11:08:18 +0200 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 Date: Thu, 20 Aug 2009 11:08:08 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0D0D1A@XMB-AMS-107.cisco.com> In-Reply-To: <87ab1v3gmy.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] making progress on fragmentation Thread-Index: Acog6xBydWjKTPqcTGGtK5vA/ZtnbwAf7sgQ References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com><87hbw52nop.fsf@kelsey-ws.hq.ember.com> <87fxbp2mj3.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0D0912@XMB-AMS-107.cisco.com> <87d46r3oje.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0D0B75@XMB-AMS-107.cisco.com> <87ab1v3gmy.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 20 Aug 2009 09:08:18.0301 (UTC) FILETIME=[C1FDDAD0:01CA2175] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3824; t=1250759298; x=1251623298; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20making=20progress=20on=20fr agmentation |Sender:=20; bh=g34WUCpJbJmXkQw1+sArApsSaSDiVqx7IEHeyJ3y1Qc=; b=O2uvdWG0z9bGLDCWLz0JS7dp3yRcAQY3Rln5KoX5vkmO48rCYk0R6C5sa/ 5RQbsQXPCJ1QAtx4Lfwd28DM4/oVHZN7WrrVymYzY0EG6r5iVmIKWeEJ1TlG 2p0hvxHX2Y; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] making progress on fragmentation X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 20 Aug 2009 09:08:15 -0000 Hi Richard > In route over the L2 source changes at each hop. The datagram tag is > associated to the source MAC and only valid (and unique) for that source > MAC. > > Upon a first fragment: > ---------------------- > [...] > > Upon next fragments (that are not first fragments) > -------------------------------------------------- > [...] > > Upon fr-acks: > ---------- > - lookup (MAC_nxt, DT_nxt) to get (MAC_prv, DT_prv) > - If not found drop. > - else swap mac and tag and forward, as before > - if the bitmap is acks all (could change the draft to make it all ones) > or errors (all zeroes) cleanup resource > >You have to be careful about cleaning up just because you >see a complete ack. Transmission is unreliable in both >directions. If an intermediate node deletes the record and >the source fails to get the complete ack, the source will >start over from the beginning, even though the destination >already has the packet. And with the label/datagram_tag >swapping, the destination has no way of knowing that the >retransmission is a copy of a packet it has already received. Say that an ack(all) or and ack (0 =3D=3D error) cleans up the states = down to a point where it gets lost midway.=20 If the retried fragment is not the first fragment, the first node that cannot forward that fragment because it has its states cleanup has to ack (0 =3D=3D error), effectively cleaning the rest of the way between = the source and itself. A node that exhausts retries on a fragment can also to that. One side question is whether the packet that ends up in ack(0 =3D=3D = error) should be retried at the source, and I think not. So the problem is limited to loosing the ack that acks the first fragment. The source will retry it and establish a new path, where the packet will be resent. If the lost ack was an ack(all), that means that all the fragments were acked in a single shot. The packet will be duplicated.=20 One way of avoiding duplication is to drop a packet when the first fragment is lost.=20 Another is to have intermediate acks that force to ack the first fragment before they are all sent. It appears that the frag draft would benefit from a way for the source to clean up all on the way forward like the ack(0) does on the way back. I'll look into it. > It appears that with the local operation above any node > can play the game or not without knowledge that the peers > also do. In other words, we could reassemble along the > way and only nodes that wish/know_how_to skip the process > would do so. > >I still think that there needs to be a way to distinguish >between an intermittent problem, where just resending a >dropped fragment is enough, and a broken route. This gets >a lot harder if an intermediate node might reassemble the >packet. > =20 The whole idea is that a path is broken but that routing should find a new one. If you reassemble at midway, then the packet has progressed forward and the router that now owns the packet is the new source for a fragmentation process.=20 If the label path gets broken between it and the next fragmentation endpoint, the router is entitled to find a new path. If it cannot, it is up to routing to fix that. RPL attempts to maintain DAGs to enable multiple forwarding solutions and limit that risk. My question to the group is whether this frag forwarding process should be described in the frag draft. The reason why we might need to do so is the need to ack(0 =3D=3D error) en route when the label path is broken = or the retries are exhausted. The need to do this comes from the label switching trick and does not make sense otherwise. What do you think? Cheers, Pascal From cabo@tzi.org Sat Aug 22 15:29:36 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00043A6BEA for <6lowpan@core3.amsl.com>; Sat, 22 Aug 2009 15:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.971 X-Spam-Level: X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqFuY0zJlq9m for <6lowpan@core3.amsl.com>; Sat, 22 Aug 2009 15:29:36 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id C8E483A6864 for <6lowpan@ietf.org>; Sat, 22 Aug 2009 15:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n7MMTQtI029216 for <6lowpan@ietf.org>; Sun, 23 Aug 2009 00:29:30 +0200 (CEST) Received: from [192.168.217.105] (p5489E1B6.dip.t-dialin.net [84.137.225.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 2D935BE4A; Sun, 23 Aug 2009 00:29:26 +0200 (CEST) Message-Id: <8AE56997-8070-466D-9734-2A74E4456483@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 23 Aug 2009 00:29:24 +0200 X-Mailer: Apple Mail (2.936) Cc: Carsten Bormann Subject: [6lowpan] Please review the draft minutes from IETF75 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sat, 22 Aug 2009 22:29:37 -0000 LoWPANners, I put up the draft minutes for the Stockholm IETF75 meeting at: http://www.ietf.org/proceedings/75/minutes/6lowpan.txt Please review them and send any corrections to me and/or the list. (I will act on them when I'm back from my 12-day vacation.) Gruesse, Carsten