From robert.assimiti@nivis.com Fri May 1 10:05:25 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 E7D563A6C0C for <6lowpan@core3.amsl.com>; Fri, 1 May 2009 10:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.409, 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 sZeM2cTpLX1E for <6lowpan@core3.amsl.com>; Fri, 1 May 2009 10:05:24 -0700 (PDT) Received: from mail.nivis.com (mail.nivis.com [65.205.163.229]) by core3.amsl.com (Postfix) with SMTP id AFA593A70D4 for <6lowpan@ietf.org>; Fri, 1 May 2009 10:05:24 -0700 (PDT) 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: Fri, 1 May 2009 13:05:57 -0400 Message-ID: In-Reply-To: <49FA42CD.2020204@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] non-transitive links and one-interface routers thread-index: AcnJ9CXWIrLYAxuJR2ytNYUxbWnk7gAityCQ References: <49F883AF.7060007@gmail.com> <49F8AFB6.5080607@sensinode.com><49F8C2A8.4030509@gmail.com> <49F9447F.1060903@sensinode.com> <49FA42CD.2020204@gmail.com> From: "Robert Assimiti" To: "Alexandru Petrescu" Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] non-transitive links and one-interface routers 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, 01 May 2009 17:05:26 -0000 Hello Alex, Thanks for the very constructive discussion. It seems that we are trying to reconcile legacy IETF link definitions wit= h the realities of the wireless media. Well, I am afraid that we will need a new definition.=20 Looking at the definitions of a link in most wireless standards (802.15.4= , Zigbee, ISA100.11a, etc) you will find that a link in the wireless cont= ext is quite different that a link over wired media. In you depiction of the three nodes, R1 communicates with R3 over 2 wirel= ess links (or at least what is regarded as a link in most wireless standa= rds). A wireless link is characterized typically by: 1. Direct connectivity between two wireless nodes 2. Characterized by various quality indicators 3. Uni-directional (R1 -> R2 is one link, and R2 -> R1 is 1 link). Uni-di= rectionality is typically imposed by inherent variance of quality indicat= ors in the wireless world. Just because R1 -> R2 have a certain quality i= ndicator, it does not mean that R2 ->R1 will be characterized by the same= indicator. When it comes to the definition of a link, a one-glove-fits-all approach = cannot reconcile the differences (physics) between wired and wireless med= ias. "The nice thing about standards is that there are so many to choose from.= " - Andrew S. Tanenbaum=20 Robert Assimiti Executive Staff=A0Engineer Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behal= f Of Alexandru Petrescu Sent: Thursday, April 30, 2009 8:31 PM To: Zach Shelby Cc: 6lowpan Subject: Re: [6lowpan] non-transitive links and one-interface routers Zach Shelby a =E9crit : > Hi, >=20 > Alexandru Petrescu wrote: >> Zach Shelby a =E9crit : >>> Alex, >>>=20 >>> Alexandru Petrescu wrote: >>>> one-interface routers and links (again) >>>>=20 >>>> Let me first describe one-interface routers as I understand are >>>> proposed in 6LoWPAN: >>>>=20 >>>> +------------------------+---------------+ | >>>> | | 2001:db8:1::1/128 2001:db8:1::2/128 >>>> 2001:db8:1::3/128 _|eth0 _|eth0 >>>> _|eth0 |R1 | |R2 | |R3 | --- >>>> --- --- >>>>=20 >>>> R1 sends an IP packet to R3 but this reaches only R2. R2 picks >>>> the packet, looks at the dst address, finds it's not for self, >>>> consults routing table, finds a host-based route and sends it >>>> to R3. This can work ok. >>>=20 >>> Exactly, you pictured this nicely. This is how LoWPAN Routing >>> works. I'll get back to the definition of that in your other >>> thread. >>=20 >> Ok... >>=20 >> If we say the dashed line is The Link then we're in the ND case, >> any node can talk to any other node at link-layer, no IP routing >> throughout. >>=20 >> But if it is not The Link, and it is not two times The Link - then >> what is it? >>=20 >> What is the link definition needing a LoWPAN single-interface IP >> router? >=20 > The definition used in the other thread for a LoWPAN link, which in a > wireless network may be non-transient, I think covers this case. The definition in the thread, inheriting from rfc4861 and other rfcs, is _not_ a non-transitive link. That link is clearly defined as linking all nodes in the medium: all nodes communicate at link-layer,=20 one-by-one, any node to any node: > link - a communication facility or medium over which > nodes can communicate at the link layer, i.e., > the layer immediately below IP (each node can > communicate to each other in this medium). >=20 > Examples are Ethernets (simple or bridged), PPP > links, X.25, Frame Relay, wireless links or ATM > networks as well as Internet-layer (or > higher-layer) "tunnels", such as tunnels over > IPv4 or IPv6 itself. >=20 > This is a slightly modified definition of the link > defined in RFC4861, in order to cover also the wireles= s > links. Wireless links may be non-transitive (node A > communicates at link layer to both B and C yet B and C= > are not on the same link). Hidden terminal problem in= > wireless communications is described in [reference to > individual draft in AUTOCONF] > draft-baccelli-multi-hop-wireless-communication-02=20 This says that a wireless link is also a link. The fact that "wireless=20= link_s_ may be non-transitive" is alleviated by the fact that "link -=20 =2E.. each node can communicate to each other in this medium". Maybe we shouldn't use "Wireless links" above but "Wireless media"=20 because "link" is the term being defined. > Because the link is non-transient R1 and R2 can communicate, R2 and > R3 can communicate, but R1 and R3 can't. A 'non-transitive' link is different from the Link definition we=20 mentioned above, because nodes on that link can all communicate to each=20= other at link-layer. That Link is not non-transitive, it is transitive. How would one define a 'non-transitive' link? As two serially connected=20= Links? This implies the middle router has two interfaces - which we=20 don't want. So, what is the definition of a 'non-transitive' Link? (I'm not sure how to explain this better, but we don't seem to agree). Alex _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan This e-mail (including any attachments to it) is confidential, proprietar= y, legally privileged, subject to copyright and is sent for the personal = attention of the intended recipient only. If you have received this e-mai= l in error, please reply to advise us immediately, delete it and destroy = any printed copies of it. You are notified that reading, disclosing, copy= ing, distributing or taking any action in reliance on the contents of thi= s information is strictly prohibited. No employee is authorized to conclu= de any binding agreement on behalf of NIVIS LLC with another party by e-m= ail without express written confirmation by an officer of the company. Al= though we have taken reasonable precautions to ensure no viruses are pres= ent in this e-mail, we cannot accept responsibility for any loss or damag= e arising from the viruses in this e-mail or attachments. From zach@sensinode.com Sat May 2 03:27:48 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 37EE53A6AD1 for <6lowpan@core3.amsl.com>; Sat, 2 May 2009 03:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 yhXqY7A200yT for <6lowpan@core3.amsl.com>; Sat, 2 May 2009 03:27:46 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 68CFD3A6A8C for <6lowpan@ietf.org>; Sat, 2 May 2009 03:27:45 -0700 (PDT) Received: from snl-zach.local (line-18566.dyn.kponet.fi [85.29.118.246]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n42AT5sh022406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 May 2009 13:29:06 +0300 Message-ID: <49FC2085.7090406@sensinode.com> Date: Sat, 02 May 2009 13:29:25 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Robert Assimiti References: <49F883AF.7060007@gmail.com> <49F8AFB6.5080607@sensinode.com><49F8C2A8.4030509@gmail.com> <49F9447F.1060903@sensinode.com> <49FA42CD.2020204@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] non-transitive links and one-interface routers 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, 02 May 2009 10:27:48 -0000 Robert, I agree 100%, and this is the approach we have taken already for a long time in the working group. I propose we define this as a "Wireless Link", which has a different definition rfc4861 link. The link definition in the current drafts did need improvement, and we should put it in perspective of the current rfc4861 link assumptions. These architectural and terminology definitions need to go into their own "6LoWPAN Architecture" draft ASAP. This way there is a single place to work on these... they are currently in the ND draft for lack of a better place. - Zach Robert Assimiti wrote: > Hello Alex, > > Thanks for the very constructive discussion. > > It seems that we are trying to reconcile legacy IETF link definitions with the realities of the wireless media. > > Well, I am afraid that we will need a new definition. > > Looking at the definitions of a link in most wireless standards (802.15.4, Zigbee, ISA100.11a, etc) you will find that a link in the wireless context is quite different that a link over wired media. > > In you depiction of the three nodes, R1 communicates with R3 over 2 wireless links (or at least what is regarded as a link in most wireless standards). > > A wireless link is characterized typically by: > > 1. Direct connectivity between two wireless nodes > > 2. Characterized by various quality indicators > > 3. Uni-directional (R1 -> R2 is one link, and R2 -> R1 is 1 link). Uni-directionality is typically imposed by inherent variance of quality indicators in the wireless world. Just because R1 -> R2 have a certain quality indicator, it does not mean that R2 ->R1 will be characterized by the same indicator. > > > When it comes to the definition of a link, a one-glove-fits-all approach cannot reconcile the differences (physics) between wired and wireless medias. > > > "The nice thing about standards is that there are so many to choose from." - Andrew S. Tanenbaum > Robert Assimiti > Executive Staff Engineer > Office: [678]-202-6859 > Mobile: [404]-578-0205 > robert.assimiti@nivis.com > > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Thursday, April 30, 2009 8:31 PM > To: Zach Shelby > Cc: 6lowpan > Subject: Re: [6lowpan] non-transitive links and one-interface routers > > Zach Shelby a écrit : >> Hi, >> >> Alexandru Petrescu wrote: >>> Zach Shelby a écrit : >>>> Alex, >>>> >>>> Alexandru Petrescu wrote: >>>>> one-interface routers and links (again) >>>>> >>>>> Let me first describe one-interface routers as I understand are >>>>> proposed in 6LoWPAN: >>>>> >>>>> +------------------------+---------------+ | >>>>> | | 2001:db8:1::1/128 2001:db8:1::2/128 >>>>> 2001:db8:1::3/128 _|eth0 _|eth0 >>>>> _|eth0 |R1 | |R2 | |R3 | --- >>>>> --- --- >>>>> >>>>> R1 sends an IP packet to R3 but this reaches only R2. R2 picks >>>>> the packet, looks at the dst address, finds it's not for self, >>>>> consults routing table, finds a host-based route and sends it >>>>> to R3. This can work ok. >>>> Exactly, you pictured this nicely. This is how LoWPAN Routing >>>> works. I'll get back to the definition of that in your other >>>> thread. >>> Ok... >>> >>> If we say the dashed line is The Link then we're in the ND case, >>> any node can talk to any other node at link-layer, no IP routing >>> throughout. >>> >>> But if it is not The Link, and it is not two times The Link - then >>> what is it? >>> >>> What is the link definition needing a LoWPAN single-interface IP >>> router? >> The definition used in the other thread for a LoWPAN link, which in a >> wireless network may be non-transient, I think covers this case. > > The definition in the thread, inheriting from rfc4861 and other rfcs, is > _not_ a non-transitive link. That link is clearly defined as linking > all nodes in the medium: all nodes communicate at link-layer, > one-by-one, any node to any node: > >> link - a communication facility or medium over which >> nodes can communicate at the link layer, i.e., >> the layer immediately below IP (each node can >> communicate to each other in this medium). >> >> Examples are Ethernets (simple or bridged), PPP >> links, X.25, Frame Relay, wireless links or ATM >> networks as well as Internet-layer (or >> higher-layer) "tunnels", such as tunnels over >> IPv4 or IPv6 itself. >> >> This is a slightly modified definition of the link >> defined in RFC4861, in order to cover also the wireless >> links. Wireless links may be non-transitive (node A >> communicates at link layer to both B and C yet B and C >> are not on the same link). Hidden terminal problem in >> wireless communications is described in [reference to >> individual draft in AUTOCONF] >> draft-baccelli-multi-hop-wireless-communication-02 > > This says that a wireless link is also a link. The fact that "wireless > link_s_ may be non-transitive" is alleviated by the fact that "link - > ... each node can communicate to each other in this medium". > > Maybe we shouldn't use "Wireless links" above but "Wireless media" > because "link" is the term being defined. > >> Because the link is non-transient R1 and R2 can communicate, R2 and >> R3 can communicate, but R1 and R3 can't. > > A 'non-transitive' link is different from the Link definition we > mentioned above, because nodes on that link can all communicate to each > other at link-layer. That Link is not non-transitive, it is transitive. > > How would one define a 'non-transitive' link? As two serially connected > Links? This implies the middle router has two interfaces - which we > don't want. > > So, what is the definition of a 'non-transitive' Link? > > (I'm not sure how to explain this better, but we don't seem to agree). > > Alex > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- 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 ben@blindcreek.com Sat May 2 09:54: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 26EB23A6A76 for <6lowpan@core3.amsl.com>; Sat, 2 May 2009 09:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 D3UNBviH5tZO for <6lowpan@core3.amsl.com>; Sat, 2 May 2009 09:54:56 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [65.254.51.10]) by core3.amsl.com (Postfix) with ESMTP id ACD823A6991 for <6lowpan@ietf.org>; Sat, 2 May 2009 09:54:56 -0700 (PDT) Received: from [64.74.213.174] (port=1869 helo=RunningDog2) by wilson.nswebhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M0IVY-0001w5-Dm for 6lowpan@ietf.org; Sat, 02 May 2009 11:56:16 -0500 Message-ID: <4ABEC4EF576543178B5C07808188AE82@RunningDog2> From: "Benjamin A. Rolfe" To: "6lowpan" <6lowpan@ietf.org> References: <49F883AF.7060007@gmail.com> <49F8AFB6.5080607@sensinode.com><49F8C2A8.4030509@gmail.com> <49F9447F.1060903@sensinode.com><49FA42CD.2020204@gmail.com> <49FC2085.7090406@sensinode.com> Date: Sat, 2 May 2009 09:55:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] non-transitive links and one-interface routers 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, 02 May 2009 16:54:58 -0000 Hi, I may be easily confused but I think this thread might confuse the more robust thinker too. Maybe thinking in terms of context will help. Within 802.15.4 in the context of the PHY layer, "link" is used to describe a data path between two PHY entities - thus we know for, example in the definition of Link Quality Indicator (LQI) is as Zach interprets it because LQI is defined in the PHY specification clause. In the MAC specification clause, "link" is used in the context of connecting MAC layer entities. With 15.4 this is simple since the MAC "peer" is a direct neighbor, as the MAC provides no forwarding or other multi-hop mechanisms. The term "logical link" is used to describe the data path the PHY+MAC provides to the logical link control layer (LLC) above the MAC. In the 802 architecture, the OSI/RM Data Link layer maps to the LLC and the part of the MAC; the Physical maps to the PHY and part of the MAC, and 802 scope covers only Physical and Data Link layers (IEEE 802-2001 "Overview and Architecture" Figure 1). Some 802 standards provide MAC layer mechanisms supporting multi-hop (forwarding, bridging, etc). The path between two LLC layer entities may traverse multiple lower layer links. The OSI/RM is more general but consistent that a "logical link" provides the path between two network layer entities, which in the real world might encompass many Physical paths. I believe this general usage of logical link is consistent with RFC-4861 ("the layer directly below IP") but I might be wrong. Hope that helps. -Ben ----- Original Message ----- From: "Zach Shelby" To: "Robert Assimiti" Cc: "6lowpan" <6lowpan@ietf.org> Sent: Saturday, May 02, 2009 3:29 AM Subject: Re: [6lowpan] non-transitive links and one-interface routers Robert, I agree 100%, and this is the approach we have taken already for a long time in the working group. I propose we define this as a "Wireless Link", which has a different definition rfc4861 link. The link definition in the current drafts did need improvement, and we should put it in perspective of the current rfc4861 link assumptions. These architectural and terminology definitions need to go into their own "6LoWPAN Architecture" draft ASAP. This way there is a single place to work on these... they are currently in the ND draft for lack of a better place. - Zach Robert Assimiti wrote: > Hello Alex, > > Thanks for the very constructive discussion. > > It seems that we are trying to reconcile legacy IETF link definitions with > the realities of the wireless media. > > Well, I am afraid that we will need a new definition. > Looking at the definitions of a link in most wireless standards (802.15.4, > Zigbee, ISA100.11a, etc) you will find that a link in the wireless context > is quite different that a link over wired media. > > In you depiction of the three nodes, R1 communicates with R3 over 2 > wireless links (or at least what is regarded as a link in most wireless > standards). > > A wireless link is characterized typically by: > > 1. Direct connectivity between two wireless nodes > > 2. Characterized by various quality indicators > > 3. Uni-directional (R1 -> R2 is one link, and R2 -> R1 is 1 link). > Uni-directionality is typically imposed by inherent variance of quality > indicators in the wireless world. Just because R1 -> R2 have a certain > quality indicator, it does not mean that R2 ->R1 will be characterized by > the same indicator. > > > When it comes to the definition of a link, a one-glove-fits-all approach > cannot reconcile the differences (physics) between wired and wireless > medias. > > > "The nice thing about standards is that there are so many to choose > from." - Andrew S. Tanenbaum Robert Assimiti > Executive Staff Engineer > Office: [678]-202-6859 > Mobile: [404]-578-0205 > robert.assimiti@nivis.com > > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Alexandru Petrescu > Sent: Thursday, April 30, 2009 8:31 PM > To: Zach Shelby > Cc: 6lowpan > Subject: Re: [6lowpan] non-transitive links and one-interface routers > > Zach Shelby a écrit : >> Hi, >> >> Alexandru Petrescu wrote: >>> Zach Shelby a écrit : >>>> Alex, >>>> >>>> Alexandru Petrescu wrote: >>>>> one-interface routers and links (again) >>>>> >>>>> Let me first describe one-interface routers as I understand are >>>>> proposed in 6LoWPAN: >>>>> >>>>> +------------------------+---------------+ | >>>>> | | 2001:db8:1::1/128 2001:db8:1::2/128 >>>>> 2001:db8:1::3/128 _|eth0 _|eth0 >>>>> _|eth0 |R1 | |R2 | |R3 | --- >>>>> --- --- >>>>> >>>>> R1 sends an IP packet to R3 but this reaches only R2. R2 picks >>>>> the packet, looks at the dst address, finds it's not for self, >>>>> consults routing table, finds a host-based route and sends it >>>>> to R3. This can work ok. >>>> Exactly, you pictured this nicely. This is how LoWPAN Routing >>>> works. I'll get back to the definition of that in your other >>>> thread. >>> Ok... >>> >>> If we say the dashed line is The Link then we're in the ND case, >>> any node can talk to any other node at link-layer, no IP routing >>> throughout. >>> >>> But if it is not The Link, and it is not two times The Link - then >>> what is it? >>> >>> What is the link definition needing a LoWPAN single-interface IP >>> router? >> The definition used in the other thread for a LoWPAN link, which in a >> wireless network may be non-transient, I think covers this case. > > The definition in the thread, inheriting from rfc4861 and other rfcs, is > _not_ a non-transitive link. That link is clearly defined as linking > all nodes in the medium: all nodes communicate at link-layer, one-by-one, > any node to any node: > >> link - a communication facility or medium over which >> nodes can communicate at the link layer, i.e., >> the layer immediately below IP (each node can >> communicate to each other in this medium). >> >> Examples are Ethernets (simple or bridged), PPP >> links, X.25, Frame Relay, wireless links or ATM >> networks as well as Internet-layer (or >> higher-layer) "tunnels", such as tunnels over >> IPv4 or IPv6 itself. >> >> This is a slightly modified definition of the link >> defined in RFC4861, in order to cover also the wireless >> links. Wireless links may be non-transitive (node A >> communicates at link layer to both B and C yet B and C >> are not on the same link). Hidden terminal problem in >> wireless communications is described in [reference to >> individual draft in AUTOCONF] >> draft-baccelli-multi-hop-wireless-communication-02 > > This says that a wireless link is also a link. The fact that "wireless > link_s_ may be non-transitive" is alleviated by the fact that "link - ... > each node can communicate to each other in this medium". > > Maybe we shouldn't use "Wireless links" above but "Wireless media" because > "link" is the term being defined. > >> Because the link is non-transient R1 and R2 can communicate, R2 and >> R3 can communicate, but R1 and R3 can't. > > A 'non-transitive' link is different from the Link definition we mentioned > above, because nodes on that link can all communicate to each other at > link-layer. That Link is not non-transitive, it is transitive. > > How would one define a 'non-transitive' link? As two serially connected > Links? This implies the middle router has two interfaces - which we don't > want. > > So, what is the definition of a 'non-transitive' Link? > > (I'm not sure how to explain this better, but we don't seem to agree). > > Alex > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > This e-mail (including any attachments to it) is confidential, > proprietary, legally privileged, subject to copyright and is sent for the > personal attention of the intended recipient only. If you have received > this e-mail in error, please reply to advise us immediately, delete it and > destroy any printed copies of it. You are notified that reading, > disclosing, copying, distributing or taking any action in reliance on the > contents of this information is strictly prohibited. No employee is > authorized to conclude any binding agreement on behalf of NIVIS LLC with > another party by e-mail without express written confirmation by an officer > of the company. Although we have taken reasonable precautions to ensure no > viruses are present in this e-mail, we cannot accept responsibility for > any loss or damage arising from the viruses in this e-mail or attachments. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- 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. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From geoff@mulligan.org Sat May 2 11:36:40 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 C83493A6E62 for <6lowpan@core3.amsl.com>; Sat, 2 May 2009 11:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 rZDoNT0nnZVl for <6lowpan@core3.amsl.com>; Sat, 2 May 2009 11:36:39 -0700 (PDT) Received: from server1.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 1DE5628C0CE for <6lowpan@ietf.org>; Sat, 2 May 2009 11:36:15 -0700 (PDT) Received: from [199.233.92.21] (dev21.coslabs.com [199.233.92.21]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id n42IbRj2016855; Sat, 2 May 2009 12:37:27 -0600 (MDT) From: Geoff Mulligan To: "Benjamin A. Rolfe" In-Reply-To: <4ABEC4EF576543178B5C07808188AE82@RunningDog2> References: <49F883AF.7060007@gmail.com> <49F8AFB6.5080607@sensinode.com> <49F8C2A8.4030509@gmail.com> <49F9447F.1060903@sensinode.com> <49FA42CD.2020204@gmail.com> <49FC2085.7090406@sensinode.com> <4ABEC4EF576543178B5C07808188AE82@RunningDog2> Content-Type: text/plain; charset="UTF-8" Date: Sat, 02 May 2009 12:37:22 -0600 Message-Id: <1241289442.10595.16.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] non-transitive links and one-interface routers 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, 02 May 2009 18:36:40 -0000 Ben, I understand that a link at the PHY is defined a limited to a single hop between two direct neighbors. If the DLL / LLC does not provide any forwarding capability then a link would seem to be the same - a single hop between two direct neighbors. What is a link if the DLL or LLC provides a multi-hop forwarding capability? geoff If the On Sat, 2009-05-02 at 09:55 -0700, Benjamin A. Rolfe wrote: > Hi, > I may be easily confused but I think this thread might confuse the more > robust thinker too. Maybe thinking in terms of context will help. > > Within 802.15.4 in the context of the PHY layer, "link" is used to describe > a data path between two PHY entities - thus we know for, example in the > definition of Link Quality Indicator (LQI) is as Zach interprets it because > LQI is defined in the PHY specification clause. In the MAC specification > clause, "link" is used in the context of connecting MAC layer entities. > With 15.4 this is simple since the MAC "peer" is a direct neighbor, as the > MAC provides no forwarding or other multi-hop mechanisms. The term "logical > link" is used to describe the data path the PHY+MAC provides to the logical > link control layer (LLC) above the MAC. > > In the 802 architecture, the OSI/RM Data Link layer maps to the LLC and the > part of the MAC; the Physical maps to the PHY and part of the MAC, and 802 > scope covers only Physical and Data Link layers (IEEE 802-2001 "Overview and > Architecture" Figure 1). Some 802 standards provide MAC layer mechanisms > supporting multi-hop (forwarding, bridging, etc). The path between two LLC > layer entities may traverse multiple lower layer links. The OSI/RM is more > general but consistent that a "logical link" provides the path between two > network layer entities, which in the real world might encompass many > Physical paths. I believe this general usage of logical link is consistent > with RFC-4861 ("the layer directly below IP") but I might be wrong. > > Hope that helps. > -Ben > > > > ----- Original Message ----- > From: "Zach Shelby" > To: "Robert Assimiti" > Cc: "6lowpan" <6lowpan@ietf.org> > Sent: Saturday, May 02, 2009 3:29 AM > Subject: Re: [6lowpan] non-transitive links and one-interface routers > > > Robert, > > I agree 100%, and this is the approach we have taken already for a long > time in the working group. I propose we define this as a "Wireless > Link", which has a different definition rfc4861 link. The link > definition in the current drafts did need improvement, and we should put > it in perspective of the current rfc4861 link assumptions. > > These architectural and terminology definitions need to go into their > own "6LoWPAN Architecture" draft ASAP. This way there is a single place > to work on these... they are currently in the ND draft for lack of a > better place. > > - Zach > > Robert Assimiti wrote: > > Hello Alex, > > > > Thanks for the very constructive discussion. > > > > It seems that we are trying to reconcile legacy IETF link definitions with > > the realities of the wireless media. > > > > Well, I am afraid that we will need a new definition. > > Looking at the definitions of a link in most wireless standards (802.15.4, > > Zigbee, ISA100.11a, etc) you will find that a link in the wireless context > > is quite different that a link over wired media. > > > > In you depiction of the three nodes, R1 communicates with R3 over 2 > > wireless links (or at least what is regarded as a link in most wireless > > standards). > > > > A wireless link is characterized typically by: > > > > 1. Direct connectivity between two wireless nodes > > > > 2. Characterized by various quality indicators > > > > 3. Uni-directional (R1 -> R2 is one link, and R2 -> R1 is 1 link). > > Uni-directionality is typically imposed by inherent variance of quality > > indicators in the wireless world. Just because R1 -> R2 have a certain > > quality indicator, it does not mean that R2 ->R1 will be characterized by > > the same indicator. > > > > > > When it comes to the definition of a link, a one-glove-fits-all approach > > cannot reconcile the differences (physics) between wired and wireless > > medias. > > > > > > "The nice thing about standards is that there are so many to choose > > from." - Andrew S. Tanenbaum Robert Assimiti > > Executive Staff Engineer > > Office: [678]-202-6859 > > Mobile: [404]-578-0205 > > robert.assimiti@nivis.com > > > > > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > > Of Alexandru Petrescu > > Sent: Thursday, April 30, 2009 8:31 PM > > To: Zach Shelby > > Cc: 6lowpan > > Subject: Re: [6lowpan] non-transitive links and one-interface routers > > > > Zach Shelby a écrit : > >> Hi, > >> > >> Alexandru Petrescu wrote: > >>> Zach Shelby a écrit : > >>>> Alex, > >>>> > >>>> Alexandru Petrescu wrote: > >>>>> one-interface routers and links (again) > >>>>> > >>>>> Let me first describe one-interface routers as I understand are > >>>>> proposed in 6LoWPAN: > >>>>> > >>>>> +------------------------+---------------+ | > >>>>> | | 2001:db8:1::1/128 2001:db8:1::2/128 > >>>>> 2001:db8:1::3/128 _|eth0 _|eth0 > >>>>> _|eth0 |R1 | |R2 | |R3 | --- > >>>>> --- --- > >>>>> > >>>>> R1 sends an IP packet to R3 but this reaches only R2. R2 picks > >>>>> the packet, looks at the dst address, finds it's not for self, > >>>>> consults routing table, finds a host-based route and sends it > >>>>> to R3. This can work ok. > >>>> Exactly, you pictured this nicely. This is how LoWPAN Routing > >>>> works. I'll get back to the definition of that in your other > >>>> thread. > >>> Ok... > >>> > >>> If we say the dashed line is The Link then we're in the ND case, > >>> any node can talk to any other node at link-layer, no IP routing > >>> throughout. > >>> > >>> But if it is not The Link, and it is not two times The Link - then > >>> what is it? > >>> > >>> What is the link definition needing a LoWPAN single-interface IP > >>> router? > >> The definition used in the other thread for a LoWPAN link, which in a > >> wireless network may be non-transient, I think covers this case. > > > > The definition in the thread, inheriting from rfc4861 and other rfcs, is > > _not_ a non-transitive link. That link is clearly defined as linking > > all nodes in the medium: all nodes communicate at link-layer, one-by-one, > > any node to any node: > > > >> link - a communication facility or medium over which > >> nodes can communicate at the link layer, i.e., > >> the layer immediately below IP (each node can > >> communicate to each other in this medium). > >> > >> Examples are Ethernets (simple or bridged), PPP > >> links, X.25, Frame Relay, wireless links or ATM > >> networks as well as Internet-layer (or > >> higher-layer) "tunnels", such as tunnels over > >> IPv4 or IPv6 itself. > >> > >> This is a slightly modified definition of the link > >> defined in RFC4861, in order to cover also the wireless > >> links. Wireless links may be non-transitive (node A > >> communicates at link layer to both B and C yet B and C > >> are not on the same link). Hidden terminal problem in > >> wireless communications is described in [reference to > >> individual draft in AUTOCONF] > >> draft-baccelli-multi-hop-wireless-communication-02 > > > > This says that a wireless link is also a link. The fact that "wireless > > link_s_ may be non-transitive" is alleviated by the fact that "link - ... > > each node can communicate to each other in this medium". > > > > Maybe we shouldn't use "Wireless links" above but "Wireless media" because > > "link" is the term being defined. > > > >> Because the link is non-transient R1 and R2 can communicate, R2 and > >> R3 can communicate, but R1 and R3 can't. > > > > A 'non-transitive' link is different from the Link definition we mentioned > > above, because nodes on that link can all communicate to each other at > > link-layer. That Link is not non-transitive, it is transitive. > > > > How would one define a 'non-transitive' link? As two serially connected > > Links? This implies the middle router has two interfaces - which we don't > > want. > > > > So, what is the definition of a 'non-transitive' Link? > > > > (I'm not sure how to explain this better, but we don't seem to agree). > > > > Alex > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > This e-mail (including any attachments to it) is confidential, > > proprietary, legally privileged, subject to copyright and is sent for the > > personal attention of the intended recipient only. If you have received > > this e-mail in error, please reply to advise us immediately, delete it and > > destroy any printed copies of it. You are notified that reading, > > disclosing, copying, distributing or taking any action in reliance on the > > contents of this information is strictly prohibited. No employee is > > authorized to conclude any binding agreement on behalf of NIVIS LLC with > > another party by e-mail without express written confirmation by an officer > > of the company. Although we have taken reasonable precautions to ensure no > > viruses are present in this e-mail, we cannot accept responsibility for > > any loss or damage arising from the viruses in this e-mail or attachments. > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > From jabeille@cisco.com Mon May 4 01:10: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 104543A680D for <6lowpan@core3.amsl.com>; Mon, 4 May 2009 01:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 4zy4zEaPeW09 for <6lowpan@core3.amsl.com>; Mon, 4 May 2009 01:10:31 -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 B0FAA3A69CC for <6lowpan@ietf.org>; Mon, 4 May 2009 01:10:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,291,1238976000"; d="scan'208";a="39688119" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 May 2009 08:11:54 +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 n448Bsuj010310; Mon, 4 May 2009 10:11:54 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n448Bs34017154; Mon, 4 May 2009 08:11:54 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 10:11:54 +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: Mon, 4 May 2009 10:11:52 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A860302D105@xmb-ams-33d.emea.cisco.com> In-Reply-To: <4ABEC4EF576543178B5C07808188AE82@RunningDog2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] non-transitive links and one-interface routers Thread-Index: AcnLRvBWeeyBJjwoSrWPUPvO5p3jnABSElhA References: <49F883AF.7060007@gmail.com> <49F8AFB6.5080607@sensinode.com><49F8C2A8.4030509@gmail.com> <49F9447F.1060903@sensinode.com><49FA42CD.2020204@gmail.com><49FC2085.7090406@sensinode.com> <4ABEC4EF576543178B5C07808188AE82@RunningDog2> From: "Julien Abeille (jabeille)" To: "Benjamin A. Rolfe" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 04 May 2009 08:11:54.0334 (UTC) FILETIME=[FC6077E0:01C9CC8F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11117; t=1241424714; x=1242288714; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[6lowpan]=20non-transitive=20links=20an d=20one-interface=20routers |Sender:=20; bh=nzFSqygrrvIgMXyqFJ4Y6191GCY377TtGxzLpE0foh8=; b=EijtQPHBWAENZh6ZgBtX2/NiADdlmpE+ypGKM0AudyziSQDTOfwbkBotU/ M4TiZFVeBoFhvkX5AVPhpNp5ylrYeVNtdmkjGuNDeI1MyUVQY88THyZ3E3LW /1V5IeB8s3; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [6lowpan] non-transitive links and one-interface routers 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, 04 May 2009 08:10:38 -0000 Hi all, I did not dig in the details, but the 16ng group had some discussions = about the link definition for IPv6 over 802.16, which has similarities = with our case (it is wireless): http://www.ietf.org/rfc/rfc5154.txt http://www.ietf.org/rfc/rfc5121.txt http://www.ietf.org/rfc/rfc4968.txt They ended up with a definition which escapes the transitivity = discussion: RFC 5154: Link Topological area bounded by routers, which decrement the IPv4 TTL or IPv6 Hop Limit when forwarding the packet as specified from [RFC4903]. Hope this helps, Julien -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Benjamin A. Rolfe Sent: samedi 2 mai 2009 18:56 To: 6lowpan Subject: Re: [6lowpan] non-transitive links and one-interface routers Hi, I may be easily confused but I think this thread might confuse the more = robust thinker too. Maybe thinking in terms of context will help. Within 802.15.4 in the context of the PHY layer, "link" is used to = describe a data path between two PHY entities - thus we know for, = example in the definition of Link Quality Indicator (LQI) is as Zach = interprets it because=20 LQI is defined in the PHY specification clause. In the MAC = specification=20 clause, "link" is used in the context of connecting MAC layer entities.=20 With 15.4 this is simple since the MAC "peer" is a direct neighbor, as = the MAC provides no forwarding or other multi-hop mechanisms. The term = "logical link" is used to describe the data path the PHY+MAC provides to = the logical link control layer (LLC) above the MAC. In the 802 architecture, the OSI/RM Data Link layer maps to the LLC and = the part of the MAC; the Physical maps to the PHY and part of the MAC, = and 802 scope covers only Physical and Data Link layers (IEEE 802-2001 = "Overview and Architecture" Figure 1). Some 802 standards provide MAC = layer mechanisms supporting multi-hop (forwarding, bridging, etc). The = path between two LLC layer entities may traverse multiple lower layer = links. The OSI/RM is more general but consistent that a "logical link" = provides the path between two network layer entities, which in the real = world might encompass many Physical paths. I believe this general usage = of logical link is consistent with RFC-4861 ("the layer directly below = IP") but I might be wrong. Hope that helps. -Ben ----- Original Message ----- From: "Zach Shelby" To: "Robert Assimiti" Cc: "6lowpan" <6lowpan@ietf.org> Sent: Saturday, May 02, 2009 3:29 AM Subject: Re: [6lowpan] non-transitive links and one-interface routers Robert, I agree 100%, and this is the approach we have taken already for a long time in the working group. I propose we define this as a "Wireless Link", which has a different definition rfc4861 link. The link definition in the current drafts did need improvement, and we should put it in perspective of the current rfc4861 link assumptions. These architectural and terminology definitions need to go into their own "6LoWPAN Architecture" draft ASAP. This way there is a single place to work on these... they are currently in the ND draft for lack of a better place. - Zach Robert Assimiti wrote: > Hello Alex, > > Thanks for the very constructive discussion. > > It seems that we are trying to reconcile legacy IETF link definitions = with=20 > the realities of the wireless media. > > Well, I am afraid that we will need a new definition. > Looking at the definitions of a link in most wireless standards = (802.15.4,=20 > Zigbee, ISA100.11a, etc) you will find that a link in the wireless = context=20 > is quite different that a link over wired media. > > In you depiction of the three nodes, R1 communicates with R3 over 2=20 > wireless links (or at least what is regarded as a link in most = wireless=20 > standards). > > A wireless link is characterized typically by: > > 1. Direct connectivity between two wireless nodes > > 2. Characterized by various quality indicators > > 3. Uni-directional (R1 -> R2 is one link, and R2 -> R1 is 1 link).=20 > Uni-directionality is typically imposed by inherent variance of = quality=20 > indicators in the wireless world. Just because R1 -> R2 have a certain = > quality indicator, it does not mean that R2 ->R1 will be characterized = by=20 > the same indicator. > > > When it comes to the definition of a link, a one-glove-fits-all = approach=20 > cannot reconcile the differences (physics) between wired and wireless=20 > medias. > > > "The nice thing about standards is that there are so many to choose=20 > from." - Andrew S. Tanenbaum Robert Assimiti > Executive Staff Engineer > Office: [678]-202-6859 > Mobile: [404]-578-0205 > robert.assimiti@nivis.com > > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf=20 > Of Alexandru Petrescu > Sent: Thursday, April 30, 2009 8:31 PM > To: Zach Shelby > Cc: 6lowpan > Subject: Re: [6lowpan] non-transitive links and one-interface routers > > Zach Shelby a =E9crit : >> Hi, >> >> Alexandru Petrescu wrote: >>> Zach Shelby a =E9crit : >>>> Alex, >>>> >>>> Alexandru Petrescu wrote: >>>>> one-interface routers and links (again) >>>>> >>>>> Let me first describe one-interface routers as I understand are >>>>> proposed in 6LoWPAN: >>>>> >>>>> +------------------------+---------------+ | >>>>> | | 2001:db8:1::1/128 2001:db8:1::2/128 >>>>> 2001:db8:1::3/128 _|eth0 _|eth0 >>>>> _|eth0 |R1 | |R2 | |R3 | --- >>>>> --- --- >>>>> >>>>> R1 sends an IP packet to R3 but this reaches only R2. R2 picks >>>>> the packet, looks at the dst address, finds it's not for self, >>>>> consults routing table, finds a host-based route and sends it >>>>> to R3. This can work ok. >>>> Exactly, you pictured this nicely. This is how LoWPAN Routing >>>> works. I'll get back to the definition of that in your other >>>> thread. >>> Ok... >>> >>> If we say the dashed line is The Link then we're in the ND case, >>> any node can talk to any other node at link-layer, no IP routing >>> throughout. >>> >>> But if it is not The Link, and it is not two times The Link - then >>> what is it? >>> >>> What is the link definition needing a LoWPAN single-interface IP >>> router? >> The definition used in the other thread for a LoWPAN link, which in a >> wireless network may be non-transient, I think covers this case. > > The definition in the thread, inheriting from rfc4861 and other rfcs, = is > _not_ a non-transitive link. That link is clearly defined as linking > all nodes in the medium: all nodes communicate at link-layer, = one-by-one,=20 > any node to any node: > >> link - a communication facility or medium over which >> nodes can communicate at the link layer, i.e., >> the layer immediately below IP (each node can >> communicate to each other in this medium). >> >> Examples are Ethernets (simple or bridged), PPP >> links, X.25, Frame Relay, wireless links or ATM >> networks as well as Internet-layer (or >> higher-layer) "tunnels", such as tunnels over >> IPv4 or IPv6 itself. >> >> This is a slightly modified definition of the link >> defined in RFC4861, in order to cover also the = wireless >> links. Wireless links may be non-transitive (node A >> communicates at link layer to both B and C yet B and = C >> are not on the same link). Hidden terminal problem = in >> wireless communications is described in [reference = to >> individual draft in AUTOCONF] >> draft-baccelli-multi-hop-wireless-communication-02 > > This says that a wireless link is also a link. The fact that = "wireless=20 > link_s_ may be non-transitive" is alleviated by the fact that "link - = ...=20 > each node can communicate to each other in this medium". > > Maybe we shouldn't use "Wireless links" above but "Wireless media" = because=20 > "link" is the term being defined. > >> Because the link is non-transient R1 and R2 can communicate, R2 and >> R3 can communicate, but R1 and R3 can't. > > A 'non-transitive' link is different from the Link definition we = mentioned=20 > above, because nodes on that link can all communicate to each other at = > link-layer. That Link is not non-transitive, it is transitive. > > How would one define a 'non-transitive' link? As two serially = connected=20 > Links? This implies the middle router has two interfaces - which we = don't=20 > want. > > So, what is the definition of a 'non-transitive' Link? > > (I'm not sure how to explain this better, but we don't seem to agree). > > Alex > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > This e-mail (including any attachments to it) is confidential,=20 > proprietary, legally privileged, subject to copyright and is sent for = the=20 > personal attention of the intended recipient only. If you have = received=20 > this e-mail in error, please reply to advise us immediately, delete it = and=20 > destroy any printed copies of it. You are notified that reading,=20 > disclosing, copying, distributing or taking any action in reliance on = the=20 > contents of this information is strictly prohibited. No employee is=20 > authorized to conclude any binding agreement on behalf of NIVIS LLC = with=20 > another party by e-mail without express written confirmation by an = officer=20 > of the company. Although we have taken reasonable precautions to = ensure no=20 > viruses are present in this e-mail, we cannot accept responsibility = for=20 > any loss or damage arising from the viruses in this e-mail or = attachments. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 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. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From alexandru.petrescu@gmail.com Wed May 6 01:16:51 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 323E03A6977 for <6lowpan@core3.amsl.com>; Wed, 6 May 2009 01:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, 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 TlhDd9txx62l for <6lowpan@core3.amsl.com>; Wed, 6 May 2009 01:16:44 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id A58A828C258 for <6lowpan@ietf.org>; Wed, 6 May 2009 01:16:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n468H2Sq002783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 May 2009 10:17:02 +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 n468H24u002955; Wed, 6 May 2009 10:17:02 +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 n468H2bj022629; Wed, 6 May 2009 10:17:02 +0200 Message-ID: <4A01477E.7000603@gmail.com> Date: Wed, 06 May 2009 10:17:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Julien Abeille (jabeille)" References: <49F883AF.7060007@gmail.com> <49F8AFB6.5080607@sensinode.com><49F8C2A8.4030509@gmail.com> <49F9447F.1060903@sensinode.com><49FA42CD.2020204@gmail.com><49FC2085.7090406@sensinode.com> <4ABEC4EF576543178B5C07808188AE82@RunningDog2> <38F26F36EAA981478A49D1F37F474A860302D105@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A860302D105@xmb-ams-33d.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] non-transitive links and one-interface routers 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, 06 May 2009 08:16:51 -0000 Julien Abeille (jabeille) a écrit : > Hi all, > > I did not dig in the details, but the 16ng group had some discussions > about the link definition for IPv6 over 802.16, which has > similarities with our case (it is wireless): > http://www.ietf.org/rfc/rfc5154.txt > http://www.ietf.org/rfc/rfc5121.txt > http://www.ietf.org/rfc/rfc4968.txt > > They ended up with a definition which escapes the transitivity > discussion: RFC 5154: Link Topological area bounded by routers, which > decrement the IPv4 TTL or IPv6 Hop Limit when forwarding the packet > as specified from [RFC4903]. This, and the link definition in the IPv6 RFCs, contradict the notion that a link is non-transitive, and that a router makes it transitive by forwarding packets within it. If a LoWPAN one-interface router decrements the Hop Limit of a forwarded packet then this is _two_ links. And a router with a single physical interface can hardly be connected to two links simultaneously. Maybe a LoWPAN link is not a link... Alex From zach@sensinode.com Thu May 7 01:16:40 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 B72073A6AE5 for <6lowpan@core3.amsl.com>; Thu, 7 May 2009 01:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 CPBKXalQ4wB6 for <6lowpan@core3.amsl.com>; Thu, 7 May 2009 01:16:40 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 87DA03A70E6 for <6lowpan@ietf.org>; Thu, 7 May 2009 01:16:28 -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 n478Hp4g006545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Thu, 7 May 2009 11:17:52 +0300 Message-ID: <4A029937.6070701@sensinode.com> Date: Thu, 07 May 2009 11:17:59 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowpan] ND status 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, 07 May 2009 08:16:40 -0000 Hi, We've had quite long threads about issues around both neighbor discovery and general 6lowpan terminology/architectural issues. Now we need to move on to get a new version of draft-ietf-6lowpan-nd out which captures the current needed improvements. I have added some new tickets to try and summarize the latest list discussions: http://trac.tools.ietf.org/wg/6lowpan/trac/query?component=nd&order=id #28 - Edge Router -> Border Router (as used in ROLL) #29 - Whiteboard examples #30 - IP forwarding examples All of the general 6lowpan terminology and architectural related text will go into its own "6LoWPAN Architecture" section. If possible, this will be moved to separate architecture document at some point. The terminology in this section will be improved based on the discussions on the list. I plan to get draft-ietf-6lowpan-nd-03 out next week. - Zach -- 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 samitac2@gmail.com Mon May 11 01:21: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 A1FC83A6B79 for <6lowpan@core3.amsl.com>; Mon, 11 May 2009 01:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 JT-5sHMhsrSN for <6lowpan@core3.amsl.com>; Mon, 11 May 2009 01:21:32 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id E7ED03A6DE5 for <6lowpan@ietf.org>; Mon, 11 May 2009 01:21:00 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so2244542qwe.31 for <6lowpan@ietf.org>; Mon, 11 May 2009 01:22:29 -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=yxlhx+sIbTllxedJ1LVfHhR5t6qt+zVkJQcND9NdCb0=; b=Ye3lqcyD4Q0sPk1rgfo7+5Al44n5Z4RLI11NUnKfC1OS7j7ZwYZXwoCeNSkRS3vNzS YBYLuG4RCz93R9C850nBxEpbIca5QkVzIrwU/vJKFZnNFSmN8a35VwCys/RGOSXusagT 2uRyRxJ3RTuJ1pPOE1tG8CKtODC2MEfhmoynQ= 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=PLFMa1GeMd+7jItQa0VaMm5FkJOZv6JoVHnaEGFFxczbnosDAwo3cifcwT5mF3nC+4 YAUrSoxvFvMbdR5HSwrK0bqjoXlaWNSUlEFZsRbpKzrr7Yo98vVT7NzSg0s7DrULOYqe JwPDZte7mWtcp4h1QfUhSL7BJqVkLdh+koGjk= MIME-Version: 1.0 Received: by 10.229.79.2 with SMTP id n2mr578288qck.8.1242030149606; Mon, 11 May 2009 01:22:29 -0700 (PDT) In-Reply-To: <4A029937.6070701@sensinode.com> References: <4A029937.6070701@sensinode.com> Date: Mon, 11 May 2009 01:22:29 -0700 Message-ID: <43b91d370905110122m469107f2w78a13f6c3b8a33ff@mail.gmail.com> From: Samita Chakrabarti To: Zach Shelby Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] ND status 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, 11 May 2009 08:21:33 -0000 Hi Zach, In addition, an arrow/line diagram showing each step of ND from bootstrapping to address resolution will be very useful. We can add this at the Appendix if not in the main body of the draft. Thanks, -Samita On 5/7/09, Zach Shelby wrote: > Hi, > > We've had quite long threads about issues around both neighbor discovery = and > general 6lowpan terminology/architectural issues. > > Now we need to move on to get a new version of draft-ietf-6lowpan-nd out > which captures the current needed improvements. I have added some new > tickets to try and summarize the latest list discussions: > > http://trac.tools.ietf.org/wg/6lowpan/trac/query?component=3Dnd&order=3Di= d > > #28 - Edge Router -> Border Router (as used in ROLL) > #29 - Whiteboard examples > #30 - IP forwarding examples > > All of the general 6lowpan terminology and architectural related text wil= l > go into its own "6LoWPAN Architecture" section. If possible, this will be > moved to separate architecture document at some point. The terminology in > this section will be improved based on the discussions on the list. > > I plan to get draft-ietf-6lowpan-nd-03 out next week. > > - Zach > > -- > 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. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From pthubert@cisco.com Mon May 11 06:11: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 8F8E93A6F50 for <6lowpan@core3.amsl.com>; Mon, 11 May 2009 06:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.003 X-Spam-Level: X-Spam-Status: No, score=-10.003 tagged_above=-999 required=5 tests=[AWL=0.596, 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 7b8jTFF0wPDh for <6lowpan@core3.amsl.com>; Mon, 11 May 2009 06:11: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 280293A6F14 for <6lowpan@ietf.org>; Mon, 11 May 2009 06:11:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,327,1238976000"; d="scan'208";a="40263287" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 May 2009 13:12:43 +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 n4BDCiqM021874; Mon, 11 May 2009 15:12:44 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4BDChrT002612; Mon, 11 May 2009 13:12:43 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 May 2009 15:12:43 +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: Mon, 11 May 2009 15:12:39 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0770C66D@xmb-ams-337.emea.cisco.com> In-Reply-To: <43b91d370905110122m469107f2w78a13f6c3b8a33ff@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ND status Thread-Index: AcnSEb7wblyTavmoQ6OuhaI5s5UhMQAKGNig References: <4A029937.6070701@sensinode.com> <43b91d370905110122m469107f2w78a13f6c3b8a33ff@mail.gmail.com> From: "Pascal Thubert (pthubert)" To: "Samita Chakrabarti" , "Zach Shelby" X-OriginalArrivalTime: 11 May 2009 13:12:43.0970 (UTC) FILETIME=[2BB09A20:01C9D23A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2319; t=1242047564; x=1242911564; 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]=20ND=20status |Sender:=20; bh=itm5LwkaK2OE80ZNEcZJOE2geM5+arypeXWttBZxxmw=; b=sz3c7xdvtbJzort+mIqWwVU0ZILMh2FMtonRBZGlFJbhN9Bkw4KzFxaY9l z4cH2QBKcwSeMjEg+tESyFzf2g2DtjU6byfyGGIL3CcIeekV9MmErrhJhoNY icjhpCArLU; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] ND status 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, 11 May 2009 13:11:15 -0000 Agreed, great idea Samita. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Samita Chakrabarti >Sent: lundi 11 mai 2009 10:22 >To: Zach Shelby >Cc: 6lowpan >Subject: Re: [6lowpan] ND status > >Hi Zach, > >In addition, an arrow/line diagram showing each step of ND from >bootstrapping to address resolution will be very useful. We can add >this at the Appendix if not in the main body of the draft. > >Thanks, >-Samita > >On 5/7/09, Zach Shelby wrote: >> Hi, >> >> We've had quite long threads about issues around both neighbor discovery and >> general 6lowpan terminology/architectural issues. >> >> Now we need to move on to get a new version of draft-ietf-6lowpan-nd out >> which captures the current needed improvements. I have added some new >> tickets to try and summarize the latest list discussions: >> >> http://trac.tools.ietf.org/wg/6lowpan/trac/query?component=3Dnd&order=3Di= d >> >> #28 - Edge Router -> Border Router (as used in ROLL) >> #29 - Whiteboard examples >> #30 - IP forwarding examples >> >> All of the general 6lowpan terminology and architectural related text will >> go into its own "6LoWPAN Architecture" section. If possible, this will be >> moved to separate architecture document at some point. The terminology in >> this section will be improved based on the discussions on the list. >> >> I plan to get draft-ietf-6lowpan-nd-03 out next week. >> >> - Zach >> >> -- >> 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. >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Tue May 12 02:19: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 4C1253A6A66 for <6lowpan@core3.amsl.com>; Tue, 12 May 2009 02:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 5sdnDNDXMMdb for <6lowpan@core3.amsl.com>; Tue, 12 May 2009 02:19: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 108FD3A692D for <6lowpan@ietf.org>; Tue, 12 May 2009 02:19: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 n4C9L0mr027996 for <6lowpan@ietf.org>; Tue, 12 May 2009 11:21:00 +0200 (CEST) Received: from wlan-client-343.informatik.uni-bremen.de (wlan-client-343.informatik.uni-bremen.de [134.102.117.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id C3DBB1704D6; Tue, 12 May 2009 11:21:00 +0200 (CEST) Message-Id: From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 12 May 2009 11:20:59 +0200 X-Mailer: Apple Mail (2.930.3) Subject: [6lowpan] HC-04: fixes and redundancies 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, 12 May 2009 09:19:42 -0000 In the processing of rereading HC-04 on the way to possible WGLC, I found some editorial defects, see: http://trac.tools.ietf.org/wg/6lowpan/trac/query?component=hc Jonathan and I are working on resolving those, but I'd sure like to hear your comments. I also ran into the following observation about destination address compression. (I'm going to abbreviate the last four bits of the IPHC base header in the form M-DAC-DAM, e.g. 1-1-01 for the case mentioned in defect #34.) It appears to me that the cases 0-0-00 0-1-00 1-1-00 all have exactly the same semantics: send the destination address in- line. I'm not going to address 0-0-00 and 0-1-00, because that part is used by ISA100, and it's probably not worth diverging (although it might be a good idea to reserve 0-1-00 in both documents). But we can still fix 1-1-00 without creating a change there. We know we are compressing a multicast address since the M bit is 1. Two observations: Multicast addresses always start with FF, which makes the first 8 bits redundant. Also, the last 13 bits of the multicast address might be encoded in the MAC-layer destination address. Do we want to make use of these up to 21 inferrable bits (or part of them)? Note that we can always fall back to 0-0-00 or 0-1-00 which are perfectly capable of transporting multicast addresses. Gruesse, Carsten From zach@sensinode.com Tue May 12 02:35:30 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 AB50E3A6D96 for <6lowpan@core3.amsl.com>; Tue, 12 May 2009 02:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 r3VatF294tEH for <6lowpan@core3.amsl.com>; Tue, 12 May 2009 02:35:29 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4B9B13A6D92 for <6lowpan@ietf.org>; Tue, 12 May 2009 02:35:28 -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 n4C9auF0025620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Tue, 12 May 2009 12:36:56 +0300 Message-ID: <4A09435E.4090109@sensinode.com> Date: Tue, 12 May 2009 12:37:34 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowpan] Terminology 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, 12 May 2009 09:35:30 -0000 Hi, I am working on an updated terminology set for the nd draft. The terminology is now split with 6LoWPAN general terminology now in its own section. I would like comments on this updated set (below) where I have tried to find a solution based on the constructive discussions we had on the list. After looking through all the background RFCs in detail, it actually turns out this is not as hard as we thought. RFC4861 actually does cover the wireless case as it defines assymetric properties of wireless links including non-transitivity (see Section 2.2). In fact RFC4861 actually mentions that the protocol (ND) will presumably be extended in the future to deal with links that are assymetric (non-reflexive, non-transitive). That is what we are doing with ND for 6LoWPAN! Therefore I have now defined link as being non-transitive and complex NBMA, which can be somewhat overcome using link-layer mesh techniques or by with IP routing. This greatly simplifies the definition of a subnet (whew!), as we keep the RFC4291 where subnet <= link. As we are performing IP routing to overcome the non-transitive nature, the subnet does exhibit one aspect of multi-link subnet mentioned in RFC4903. IP routing has been defined as Alex recommended as it has specific properties to 6LoWPAN. In the architecture section of nd-03 we will include LoWPAN IP routing examples including topology and what is in the table. General 6LoWPAN Terminology: This section defines additional general terms related to the 6LoWPAN architecture used in this specification: IP Routing The forwarding of datagrams at the IP layer between arbitrary source-destination pairs, during which the hop limit is decremented. In the LoWPAN context, IP routing is performed by LoWPAN Routers on a single interface within the same link to overcome the non-transient nature of the link. Exact match search is performed on the dst address of the IP packet to find the next- hop to the destination. Referred to as routing in this document. Link The link is a communication facility or medium over which nodes can communicate at the link-layer, i.e., the layer directly below IP ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy wireless links such as IEEE 802.15.4, which is a special type of link as described in [RFC4861] exhibiting severe assymetric reachability with both non-reflexive and non-transitive qualities. Furthermore complex Non-broadcast Multi-Access (NBMA) behaviour is exhibited as these links do not support native multicast, and broadcast reaches only a subset of nodes on the link. The use of link-layer mesh technology (see Mesh Under) emulates transitivity across the link but still has problems with non-reflexitivity. Multicast on a link-layer mesh is usually implemented as a broadcast flood. Link-local Standard IPv6 link-local scope as defined in [RFC4291] and [RFC4861] is supported by the 6LoWPAN link and subnet model. Link-local scope is achieved by setting the hop limit to 1, using link-local prefix or link-local multicast scope. If a link is non-transient then link-local scope includes only a subset of nodes on the link (the set of nodes within assymetric radio range of a node). Nodes in the link-local scope of a node are its neighbors, and this link-local scope may be different for each node on a link. LoWPAN Host A node that only sources or sinks IPv6 datagrams. Referred to as a host in this document. LoWPAN Node A node that composes a LoWPAN and is used to refer to both hosts and routers. Referred to as a node in this document. LoWPAN Router A node that forwards datagrams between arbitrary source- destination pairs using a single 6LoWPAN interface performing IP routing on that interface. Mesh Under A term referring to a configuration where the link-local scope is defined by the boundaries of the LoWPAN and includes all the 6LoWPAN interfaces within it. Forwarding and multihop routing functions are achieved at the link layer. In this configuration the link may still exhibit assymetric behaviour. Route Over A term referring to a configuration where the link is non- transient and the link-local scope reaches only a subset of the LoWPAN nodes. IP routing is performed by LoWPAN Routers to overcome to the non-transient nature of the link. This configuration may consist of both routers nad hosts. Subnet A subnet is the collection of interfaces having the same IPv6 subnet prefix on a link, as defined in [RFC4291]. A LoWPAN is made up of the interfaces of LoWPAN Nodes and Edge Routers sharing the same subnet prefix. Due to the non-transient nature of 6LoWPAN links, IP routing may be used on the link to provide transitivity. This exhibits a multi-link subnet feature with regard to hop limit as defined in [RFC4903], and thus 6LoWPAN applications should make no assumptions about the hop limit as it may be decremented in a LoWPAN. -- 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 Peter.Burnett@philips.com Tue May 12 02:51: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 CBB9A3A6859 for <6lowpan@core3.amsl.com>; Tue, 12 May 2009 02:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=0.511, 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 fHpO06T1yXQh for <6lowpan@core3.amsl.com>; Tue, 12 May 2009 02:51:36 -0700 (PDT) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id 385E93A6977 for <6lowpan@ietf.org>; Tue, 12 May 2009 02:51:33 -0700 (PDT) Received: from NLHILEXH01.connect1.local (172.16.153.76) by connect1.philips.com (172.16.156.40) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 12 May 2009 11:53:07 +0200 Received: from NLCLUEXM06.connect1.local ([172.16.153.55]) by NLHILEXH01.connect1.local ([172.16.153.76]) with mapi; Tue, 12 May 2009 11:52:59 +0200 From: "Burnett, Peter" To: Zach Shelby , 6lowpan <6lowpan@ietf.org> Date: Tue, 12 May 2009 11:53:00 +0200 Thread-Topic: [6lowpan] Terminology Thread-Index: AcnS5TeZe5m8QJG5RTaHm/VP00OemQAAXlyA Message-ID: <8E9C227490A7614B87D90C0AE18CF22CADE8CC7F49@NLCLUEXM06.connect1.local> References: <4A09435E.4090109@sensinode.com> In-Reply-To: <4A09435E.4090109@sensinode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [6lowpan] Terminology 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, 12 May 2009 09:51:37 -0000 Zach, I'm wondering if the term 'non-reflexive' in RFC4861 should have been 'non-= symmetric'. Mathematically, an equivalence relationship is defined as being= reflexive, symmetric and transitive. Symmetric is the property which is un= true on a unidirectional link not reflexive. Apologies if this is nonsense, I'm new to this list. Thanks Peter -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Zach Shelby Sent: 2009 May 12 10:38 To: 6lowpan Subject: [6lowpan] Terminology Hi, I am working on an updated terminology set for the nd draft. The terminology is now split with 6LoWPAN general terminology now in its own section. I would like comments on this updated set (below) where I have tried to find a solution based on the constructive discussions we had on the list. After looking through all the background RFCs in detail, it actually turns out this is not as hard as we thought. RFC4861 actually does cover the wireless case as it defines assymetric properties of wireless links including non-transitivity (see Section 2.2). In fact RFC4861 actually mentions that the protocol (ND) will presumably be extended in the future to deal with links that are assymetric (non-reflexive, non-transitive). That is what we are doing with ND for 6LoWPAN! Therefore I have now defined link as being non-transitive and complex NBMA, which can be somewhat overcome using link-layer mesh techniques or by with IP routing. This greatly simplifies the definition of a subnet (whew!), as we keep the RFC4291 where subnet <=3D link. As we are performing IP routing to overcome the non-transitive nature, the subnet does exhibit one aspect of multi-link subnet mentioned in RFC4903. IP routing has been defined as Alex recommended as it has specific properties to 6LoWPAN. In the architecture section of nd-03 we will include LoWPAN IP routing examples including topology and what is in the table. General 6LoWPAN Terminology: This section defines additional general terms related to the 6LoWPAN architecture used in this specification: IP Routing The forwarding of datagrams at the IP layer between arbitrary source-destination pairs, during which the hop limit is decremented. In the LoWPAN context, IP routing is performed by LoWPAN Routers on a single interface within the same link to overcome the non-transient nature of the link. Exact match search is performed on the dst address of the IP packet to find the next- hop to the destination. Referred to as routing in this document. Link The link is a communication facility or medium over which nodes can communicate at the link-layer, i.e., the layer directly below IP ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy wireless links such as IEEE 802.15.4, which is a special type of link as described in [RFC4861] exhibiting severe assymetric reachability with both non-reflexive and non-transitive qualities. Furthermore complex Non-broadcast Multi-Access (NBMA) behaviour is exhibited as these links do not support native multicast, and broadcast reaches only a subset of nodes on the link. The use of link-layer mesh technology (see Mesh Under) emulates transitivity across the link but still has problems with non-reflexitivity. Multicast on a link-layer mesh is usually implemented as a broadcast flood. Link-local Standard IPv6 link-local scope as defined in [RFC4291] and [RFC4861] is supported by the 6LoWPAN link and subnet model. Link-local scope is achieved by setting the hop limit to 1, using link-local prefix or link-local multicast scope. If a link is non-transient then link-local scope includes only a subset of nodes on the link (the set of nodes within assymetric radio range of a node). Nodes in the link-local scope of a node are its neighbors, and this link-local scope may be different for each node on a link. LoWPAN Host A node that only sources or sinks IPv6 datagrams. Referred to as a host in this document. LoWPAN Node A node that composes a LoWPAN and is used to refer to both hosts and routers. Referred to as a node in this document. LoWPAN Router A node that forwards datagrams between arbitrary source- destination pairs using a single 6LoWPAN interface performing IP routing on that interface. Mesh Under A term referring to a configuration where the link-local scope is defined by the boundaries of the LoWPAN and includes all the 6LoWPAN interfaces within it. Forwarding and multihop routing functions are achieved at the link layer. In this configuration the link may still exhibit assymetric behaviour. Route Over A term referring to a configuration where the link is non- transient and the link-local scope reaches only a subset of the LoWPAN nodes. IP routing is performed by LoWPAN Routers to overcome to the non-transient nature of the link. This configuration may consist of both routers nad hosts. Subnet A subnet is the collection of interfaces having the same IPv6 subnet prefix on a link, as defined in [RFC4291]. A LoWPAN is made up of the interfaces of LoWPAN Nodes and Edge Routers sharing the same subnet prefix. Due to the non-transient nature of 6LoWPAN links, IP routing may be used on the link to provide transitivity. This exhibits a multi-link subnet feature with regard to hop limit as defined in [RFC4903], and thus 6LoWPAN applications should make no assumptions about the hop limit as it may be decremented in a LoWPAN. -- 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. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From jhui@archrock.com Tue May 12 09:29: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 DB76A3A6935 for <6lowpan@core3.amsl.com>; Tue, 12 May 2009 09:29: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=[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 Rs3yK8mVr2Ti for <6lowpan@core3.amsl.com>; Tue, 12 May 2009 09:29:18 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 23C4528C14A for <6lowpan@ietf.org>; Tue, 12 May 2009 09:29:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id CC2F9AF8DE; Tue, 12 May 2009 09:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQGebOxDscf3; Tue, 12 May 2009 09:30:40 -0700 (PDT) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id E588FAF89B; Tue, 12 May 2009 09:30:39 -0700 (PDT) Message-Id: <4FD5823A-1059-4C60-9C1C-F48A42A1B7DC@archrock.com> From: Jonathan Hui To: Carsten Bormann In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 12 May 2009 09:30:38 -0700 References: X-Mailer: Apple Mail (2.930.3) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] HC-04: fixes and redundancies 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, 12 May 2009 16:29:18 -0000 Hi Carsten, You are right that there is redundancy w.r.t. carrying the full destination address in-line. I think this was noted before. At the time someone did mention that leaving redundancy does potentially allow optimizations based on link-local vs. global and unicast vs. multicast properties of the destination address without having to fully recompose the address and interpreting a full IPv6 address. Because there were no objects (strong or minor) to the idea, we left the redundancy in. However, I'm not aware of anyone actually making use of the proposed optimization by allowing redundancy in the format. So maybe we should revisit this? -- Jonathan Hui On May 12, 2009, at 2:20 AM, Carsten Bormann wrote: > In the processing of rereading HC-04 on the way to possible WGLC, I > found some editorial defects, see: > > http://trac.tools.ietf.org/wg/6lowpan/trac/query?component=hc > > Jonathan and I are working on resolving those, but I'd sure like to > hear your comments. > > I also ran into the following observation about destination address > compression. > (I'm going to abbreviate the last four bits of the IPHC base header > in the form M-DAC-DAM, e.g. 1-1-01 for the case mentioned in defect > #34.) > > It appears to me that the cases > 0-0-00 > 0-1-00 > 1-1-00 > all have exactly the same semantics: send the destination address in- > line. > > I'm not going to address 0-0-00 and 0-1-00, because that part is > used by ISA100, and it's probably not worth diverging (although it > might be a good idea to reserve 0-1-00 in both documents). > But we can still fix 1-1-00 without creating a change there. > > We know we are compressing a multicast address since the M bit is 1. > Two observations: > Multicast addresses always start with FF, which makes the first 8 > bits redundant. > Also, the last 13 bits of the multicast address might be encoded in > the MAC-layer destination address. > > Do we want to make use of these up to 21 inferrable bits (or part of > them)? > Note that we can always fall back to 0-0-00 or 0-1-00 which are > perfectly capable of transporting multicast addresses. > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Tue May 12 13:46:09 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 973B63A6E81 for <6lowpan@core3.amsl.com>; Tue, 12 May 2009 13:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Cpvfcpg0m-S0 for <6lowpan@core3.amsl.com>; Tue, 12 May 2009 13:46:08 -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 5C12B3A6D3E for <6lowpan@ietf.org>; Tue, 12 May 2009 13:45:39 -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 n4CKl2aN004953 for <6lowpan@ietf.org>; Tue, 12 May 2009 22:47:02 +0200 (CEST) Received: from [192.168.217.107] (p5489EBA4.dip.t-dialin.net [84.137.235.164]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 0AAD01704D6; Tue, 12 May 2009 22:47:01 +0200 (CEST) Message-Id: <08C2117B-E5C5-4B1F-A048-AE19B036E48D@tzi.org> From: Carsten Bormann To: Carsten Bormann In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 12 May 2009 22:47:00 +0200 References: X-Mailer: Apple Mail (2.930.3) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] HC-04: fixes and redundancies 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, 12 May 2009 20:46:09 -0000 On May 12, 2009, at 11:20, Carsten Bormann wrote: > it might be a good idea to reserve 0-1-00 in both documents). Actually, to maintain symmetry (and be able to use the same code path) between SAC/SAM and DAC/DAM, it would be a much better idea to specify 0-0-00 as reserved (0-00 means :: = all zeros for SAC/SAM, which is not a valid destination address). Gruesse, Carsten From dokaspar.ietf@gmail.com Wed May 13 00:42: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 E4C503A683B for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 00:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 a4RpoOIi2Th8 for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 00:42:32 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id DE5AF3A68D9 for <6lowpan@ietf.org>; Wed, 13 May 2009 00:42:31 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so229364fkq.5 for <6lowpan@ietf.org>; Wed, 13 May 2009 00:44:00 -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=IM8UjYUEc4VzowLEJra4R/Lxm502f4v2OUGzXC0ycW4=; b=uA89jKcSXGkZhQb1AX9RkHhSc8w2yNJhSKbCGUJK4s3NbfF4jUhGCjfRcyDgDgWYDT rQl44yVWgx7PWDiq30jyiR+YkaEeqGnpjCg5PjkQS04Skoud/J0Y+e2gsITiFWQLYMfv jDLyJM43LmyQOfb703ee1ZW2E+7qv+7Ma8kMQ= 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=WbpDNVX2krK8ky1h7VrdmoSCpWm05PbOOn2Am81LPhMJoJTG4sbJeyByYxPG4GOkmd igjkvF1cLZ1NzvDUSDqxb4rNm3ov23c5u62Q03NNYTXdTrfeDuSreVVwsBslLycXHFoq Whye/M+OPBzwMaZbFB2ltSGuuhyFD5uCcc6zI= MIME-Version: 1.0 Received: by 10.103.161.16 with SMTP id n16mr434369muo.79.1242200640611; Wed, 13 May 2009 00:44:00 -0700 (PDT) In-Reply-To: <8E9C227490A7614B87D90C0AE18CF22CADE8CC7F49@NLCLUEXM06.connect1.local> References: <4A09435E.4090109@sensinode.com> <8E9C227490A7614B87D90C0AE18CF22CADE8CC7F49@NLCLUEXM06.connect1.local> Date: Wed, 13 May 2009 09:44:00 +0200 Message-ID: <2a3692de0905130044p4b9be817m8ec7a58adf50a7d2@mail.gmail.com> From: Dominik Kaspar To: "Burnett, Peter" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Terminology 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, 13 May 2009 07:42:34 -0000 Hi, Would 'non-reflexive' (better called 'irreflexive') reachability mean that a node can not reach itself? If so... I think the term still makes sense, because 6LoWPAN nodes usually cannot send and receive at the same time (except if they had two physical radio interfaces). By the way, typo: assymetric -> asymmetric. Greetings, Dominik On Tue, May 12, 2009 at 11:53 AM, Burnett, Peter wrote: > Zach, > I'm wondering if the term 'non-reflexive' in RFC4861 should have been 'no= n-symmetric'. Mathematically, an equivalence relationship is defined as bei= ng reflexive, symmetric and transitive. Symmetric is the property which is = untrue on a unidirectional link not reflexive. > Apologies if this is nonsense, I'm new to this list. > Thanks > Peter > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behal= f Of Zach Shelby > Sent: 2009 May 12 10:38 > To: 6lowpan > Subject: [6lowpan] Terminology > > Hi, > > I am working on an updated terminology set for the nd draft. The > terminology is now split with 6LoWPAN general terminology now in its own > section. I would like comments on this updated set (below) where I have > tried to find a solution based on the constructive discussions we had on > the list. > > After looking through all the background RFCs in detail, it actually > turns out this is not as hard as we thought. RFC4861 actually does cover > the wireless case as it defines assymetric properties of wireless links > including non-transitivity (see Section 2.2). In fact RFC4861 actually > mentions that the protocol (ND) will presumably be extended in the > future to deal with links that are assymetric (non-reflexive, > non-transitive). That is what we are doing with ND for 6LoWPAN! > > Therefore I have now defined link as being non-transitive and complex > NBMA, which can be somewhat overcome using link-layer mesh techniques or > by with IP routing. This greatly simplifies the definition of a subnet > (whew!), as we keep the RFC4291 where subnet <=3D link. As we are > performing IP routing to overcome the non-transitive nature, the subnet > does exhibit one aspect of multi-link subnet mentioned in RFC4903. > > IP routing has been defined as Alex recommended as it has specific > properties to 6LoWPAN. In the architecture section of nd-03 we will > include LoWPAN IP routing examples including topology and what is in the > table. > > > > > General 6LoWPAN Terminology: > > =A0 =A0This section defines additional general terms related to the 6LoWP= AN > =A0 =A0architecture used in this specification: > > =A0 =A0IP Routing > > =A0 =A0 =A0 The forwarding of datagrams at the IP layer between arbitrary > =A0 =A0 =A0 source-destination pairs, during which the hop limit is > =A0 =A0 =A0 decremented. =A0In the LoWPAN context, IP routing is performe= d by > =A0 =A0 =A0 LoWPAN Routers on a single interface within the same link to > =A0 =A0 =A0 overcome the non-transient nature of the link. =A0Exact match= search > =A0 =A0 =A0 is performed on the dst address of the IP packet to find the = next- > =A0 =A0 =A0 hop to the destination. =A0Referred to as routing in this doc= ument. > > =A0 =A0Link > > =A0 =A0 =A0 The link is a communication facility or medium over which nod= es > =A0 =A0 =A0 can communicate at the link-layer, i.e., the layer directly b= elow > =A0 =A0 =A0 IP ([RFC4861]). 6LoWPAN assumes the use of low-power and loss= y > =A0 =A0 =A0 wireless links such as IEEE 802.15.4, which is a special type= of > =A0 =A0 =A0 link as described in [RFC4861] exhibiting severe assymetric > =A0 =A0 =A0 reachability with both non-reflexive and non-transitive quali= ties. > =A0 =A0 =A0 Furthermore complex Non-broadcast Multi-Access (NBMA) behavio= ur is > =A0 =A0 =A0 exhibited as these links do not support native multicast, and > =A0 =A0 =A0 broadcast reaches only a subset of nodes on the link. =A0The = use of > =A0 =A0 =A0 link-layer mesh technology (see Mesh Under) emulates transiti= vity > =A0 =A0 =A0 across the link but still has problems with non-reflexitivity= . > =A0 =A0 =A0 Multicast on a link-layer mesh is usually implemented as a > =A0 =A0 =A0 broadcast flood. > > =A0 =A0Link-local > > =A0 =A0 =A0 Standard IPv6 link-local scope as defined in [RFC4291] and > =A0 =A0 =A0 [RFC4861] is supported by the 6LoWPAN link and subnet model. > =A0 =A0 =A0 Link-local scope is achieved by setting the hop limit to 1, u= sing > =A0 =A0 =A0 link-local prefix or link-local multicast scope. =A0If a link= is > =A0 =A0 =A0 non-transient then link-local scope includes only a subset of > =A0 =A0 =A0 nodes on the link (the set of nodes within assymetric radio r= ange > =A0 =A0 =A0 of a node). =A0Nodes in the link-local scope of a node are it= s > =A0 =A0 =A0 neighbors, and this link-local scope may be different for eac= h > =A0 =A0 =A0 node on a link. > > =A0 =A0LoWPAN Host > > =A0 =A0 =A0 A node that only sources or sinks IPv6 datagrams. =A0Referred= to as > =A0 =A0 =A0 a host in this document. > > =A0 =A0LoWPAN Node > > =A0 =A0 =A0 A node that composes a LoWPAN and is used to refer to both ho= sts > =A0 =A0 =A0 and routers. =A0Referred to as a node in this document. > > =A0 =A0LoWPAN Router > > =A0 =A0 =A0 A node that forwards datagrams between arbitrary source- > =A0 =A0 =A0 destination pairs using a single 6LoWPAN interface performing= IP > =A0 =A0 =A0 routing on that interface. > > =A0 =A0Mesh Under > > =A0 =A0 =A0 A term referring to a configuration where the link-local scop= e is > =A0 =A0 =A0 defined by the boundaries of the LoWPAN and includes all the > =A0 =A0 =A0 6LoWPAN interfaces within it. =A0Forwarding and multihop rout= ing > =A0 =A0 =A0 functions are achieved at the link layer. =A0In this configur= ation > =A0 =A0 =A0 the link may still exhibit assymetric behaviour. > > =A0 =A0Route Over > > =A0 =A0 =A0 A term referring to a configuration where the link is non- > =A0 =A0 =A0 transient and the link-local scope reaches only a subset of t= he > =A0 =A0 =A0 LoWPAN nodes. =A0IP routing is performed by LoWPAN Routers to > =A0 =A0 =A0 overcome to the non-transient nature of the link. =A0This > =A0 =A0 =A0 configuration may consist of both routers nad hosts. > > =A0 =A0Subnet > > =A0 =A0 =A0 A subnet is the collection of interfaces having the same IPv6 > =A0 =A0 =A0 subnet prefix on a link, as defined in [RFC4291]. =A0A LoWPAN= is > =A0 =A0 =A0 made up of the interfaces of LoWPAN Nodes and Edge Routers sh= aring > =A0 =A0 =A0 the same subnet prefix. =A0Due to the non-transient nature of > =A0 =A0 =A0 6LoWPAN links, IP routing may be used on the link to provide > =A0 =A0 =A0 transitivity. =A0This exhibits a multi-link subnet feature wi= th > =A0 =A0 =A0 regard to hop limit as defined in [RFC4903], and thus 6LoWPAN > =A0 =A0 =A0 applications should make no assumptions about the hop limit a= s it > =A0 =A0 =A0 may be decremented in a LoWPAN. > > > -- > 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. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From alexandru.petrescu@gmail.com Wed May 13 02:56:46 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 9DCCC3A6E12 for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 02:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, 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 3IufMw3nB4zZ for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 02:56:45 -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 1E9B93A6D1B for <6lowpan@ietf.org>; Wed, 13 May 2009 02:56:44 -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 n4D9u47c008745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 11:56:04 +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 n4D9wEH2030509; Wed, 13 May 2009 11:58:14 +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 n4D9wDN3029106; Wed, 13 May 2009 11:58:14 +0200 Message-ID: <4A0A99B5.40506@gmail.com> Date: Wed, 13 May 2009 11:58:13 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dominik Kaspar References: <4A09435E.4090109@sensinode.com> <8E9C227490A7614B87D90C0AE18CF22CADE8CC7F49@NLCLUEXM06.connect1.local> <2a3692de0905130044p4b9be817m8ec7a58adf50a7d2@mail.gmail.com> In-Reply-To: <2a3692de0905130044p4b9be817m8ec7a58adf50a7d2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Terminology 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, 13 May 2009 09:56:46 -0000 Dominik Kaspar a écrit : > Hi, > > Would 'non-reflexive' (better called 'irreflexive') reachability 'Irreflexive' sounds good to my dictionary, and to me better than non-reflexive. 'Reachability' is absent from many dictionaries. Alex > mean that a node can not reach itself? If so... I think the term > still makes sense, because 6LoWPAN nodes usually cannot send and > receive at the same time (except if they had two physical radio > interfaces). > > By the way, typo: assymetric -> asymmetric. > > Greetings, Dominik > > > On Tue, May 12, 2009 at 11:53 AM, Burnett, Peter > wrote: >> Zach, I'm wondering if the term 'non-reflexive' in RFC4861 should >> have been 'non-symmetric'. Mathematically, an equivalence >> relationship is defined as being reflexive, symmetric and >> transitive. Symmetric is the property which is untrue on a >> unidirectional link not reflexive. Apologies if this is nonsense, >> I'm new to this list. Thanks Peter >> >> -----Original Message----- From: 6lowpan-bounces@ietf.org >> [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby Sent: >> 2009 May 12 10:38 To: 6lowpan Subject: [6lowpan] Terminology >> >> Hi, >> >> I am working on an updated terminology set for the nd draft. The >> terminology is now split with 6LoWPAN general terminology now in >> its own section. I would like comments on this updated set (below) >> where I have tried to find a solution based on the constructive >> discussions we had on the list. >> >> After looking through all the background RFCs in detail, it >> actually turns out this is not as hard as we thought. RFC4861 >> actually does cover the wireless case as it defines assymetric >> properties of wireless links including non-transitivity (see >> Section 2.2). In fact RFC4861 actually mentions that the protocol >> (ND) will presumably be extended in the future to deal with links >> that are assymetric (non-reflexive, non-transitive). That is what >> we are doing with ND for 6LoWPAN! >> >> Therefore I have now defined link as being non-transitive and >> complex NBMA, which can be somewhat overcome using link-layer mesh >> techniques or by with IP routing. This greatly simplifies the >> definition of a subnet (whew!), as we keep the RFC4291 where subnet >> <= link. As we are performing IP routing to overcome the >> non-transitive nature, the subnet does exhibit one aspect of >> multi-link subnet mentioned in RFC4903. >> >> IP routing has been defined as Alex recommended as it has specific >> properties to 6LoWPAN. In the architecture section of nd-03 we will >> include LoWPAN IP routing examples including topology and what is >> in the table. >> >> >> >> >> General 6LoWPAN Terminology: >> >> This section defines additional general terms related to the >> 6LoWPAN architecture used in this specification: >> >> IP Routing >> >> The forwarding of datagrams at the IP layer between arbitrary >> source-destination pairs, during which the hop limit is >> decremented. In the LoWPAN context, IP routing is performed by >> LoWPAN Routers on a single interface within the same link to >> overcome the non-transient nature of the link. Exact match search >> is performed on the dst address of the IP packet to find the next- >> hop to the destination. Referred to as routing in this document. >> >> Link >> >> The link is a communication facility or medium over which nodes can >> communicate at the link-layer, i.e., the layer directly below IP >> ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy >> wireless links such as IEEE 802.15.4, which is a special type of >> link as described in [RFC4861] exhibiting severe assymetric >> reachability with both non-reflexive and non-transitive qualities. >> Furthermore complex Non-broadcast Multi-Access (NBMA) behaviour is >> exhibited as these links do not support native multicast, and >> broadcast reaches only a subset of nodes on the link. The use of >> link-layer mesh technology (see Mesh Under) emulates transitivity >> across the link but still has problems with non-reflexitivity. >> Multicast on a link-layer mesh is usually implemented as a >> broadcast flood. >> >> Link-local >> >> Standard IPv6 link-local scope as defined in [RFC4291] and >> [RFC4861] is supported by the 6LoWPAN link and subnet model. >> Link-local scope is achieved by setting the hop limit to 1, using >> link-local prefix or link-local multicast scope. If a link is >> non-transient then link-local scope includes only a subset of nodes >> on the link (the set of nodes within assymetric radio range of a >> node). Nodes in the link-local scope of a node are its neighbors, >> and this link-local scope may be different for each node on a link. >> >> >> LoWPAN Host >> >> A node that only sources or sinks IPv6 datagrams. Referred to as a >> host in this document. >> >> LoWPAN Node >> >> A node that composes a LoWPAN and is used to refer to both hosts >> and routers. Referred to as a node in this document. >> >> LoWPAN Router >> >> A node that forwards datagrams between arbitrary source- >> destination pairs using a single 6LoWPAN interface performing IP >> routing on that interface. >> >> Mesh Under >> >> A term referring to a configuration where the link-local scope is >> defined by the boundaries of the LoWPAN and includes all the >> 6LoWPAN interfaces within it. Forwarding and multihop routing >> functions are achieved at the link layer. In this configuration >> the link may still exhibit assymetric behaviour. >> >> Route Over >> >> A term referring to a configuration where the link is non- >> transient and the link-local scope reaches only a subset of the >> LoWPAN nodes. IP routing is performed by LoWPAN Routers to >> overcome to the non-transient nature of the link. This >> configuration may consist of both routers nad hosts. >> >> Subnet >> >> A subnet is the collection of interfaces having the same IPv6 >> subnet prefix on a link, as defined in [RFC4291]. A LoWPAN is made >> up of the interfaces of LoWPAN Nodes and Edge Routers sharing the >> same subnet prefix. Due to the non-transient nature of 6LoWPAN >> links, IP routing may be used on the link to provide transitivity. >> This exhibits a multi-link subnet feature with regard to hop limit >> as defined in [RFC4903], and thus 6LoWPAN applications should make >> no assumptions about the hop limit as it may be decremented in a >> LoWPAN. >> >> >> -- 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. _______________________________________________ 6lowpan >> mailing list 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended >> solely for the addressee(s). If you are not the intended recipient, >> you are hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original >> message. _______________________________________________ 6lowpan >> mailing list 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > _______________________________________________ 6lowpan mailing list > 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan > From alexandru.petrescu@gmail.com Wed May 13 03:39:24 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 25C453A6A24 for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 03:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, 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 M3LoSax7+kkR for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 03:39:23 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id ADF993A6A11 for <6lowpan@ietf.org>; Wed, 13 May 2009 03:39:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4DAer2l009397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 12:40:53 +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 n4DAeqmc004485; Wed, 13 May 2009 12:40:53 +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 n4DAepGt007246; Wed, 13 May 2009 12:40:52 +0200 Message-ID: <4A0AA3B3.9010301@gmail.com> Date: Wed, 13 May 2009 12:40:51 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <4A09435E.4090109@sensinode.com> In-Reply-To: <4A09435E.4090109@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Terminology 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, 13 May 2009 10:39:24 -0000 Zach, thanks for consolidating our recent discussions. I have comments on the proposed terminology. I mainly agree with most terms. I point where I don't agree. Zach Shelby a écrit : > Hi, > > I am working on an updated terminology set for the nd draft. The > terminology is now split with 6LoWPAN general terminology now in its > own section. I would like comments on this updated set (below) where > I have tried to find a solution based on the constructive > discussions we had on the list. > > After looking through all the background RFCs in detail, it actually > turns out this is not as hard as we thought. RFC4861 actually does > cover the wireless case as it defines assymetric properties of > wireless links including non-transitivity (see Section 2.2). YEs. > In fact RFC4861 actually mentions that the protocol (ND) will > presumably be extended in the future to deal with links that are > assymetric (non-reflexive, non-transitive). That is what we are doing > with ND for 6LoWPAN! YEs, it seems straightforward and obvious to agree. I agree with it, makes sense and is concrete. However, just a note to say this is what AUTOCONF and MANET WGs also claim(ed). Despite this obviousness, it is not stipulated in neither of the three Charters. By my reading, nothing in the three Charters makes think about the necessity to extend ND to deal with non-transitive links, although many people's conversations assume it so. This was just a note. > Therefore I have now defined link as being non-transitive and complex > NBMA, which can be somewhat overcome using link-layer mesh > techniques or by with IP routing. This greatly simplifies the > definition of a subnet (whew!), as we keep the RFC4291 where subnet > <= link. As we are performing IP routing to overcome the > non-transitive nature, the subnet does exhibit one aspect of > multi-link subnet mentioned in RFC4903. > > IP Routing > > The forwarding of datagrams at the IP layer between arbitrary > source-destination pairs, during which the hop limit is decremented. > In the LoWPAN context, IP routing is performed by LoWPAN Routers on > a single interface within the same link to overcome the non-transient > nature of the link. Exact match search is performed on the dst > address of the IP packet to find the next- hop to the destination. > Referred to as routing in this document. > > Link > > The link is a communication facility or medium over which nodes can > communicate at the link-layer, i.e., the layer directly below IP > ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy wireless > links such as IEEE 802.15.4, which is a special type of link as > described in [RFC4861] exhibiting severe assymetric reachability with > both non-reflexive and non-transitive qualities. Furthermore complex > Non-broadcast Multi-Access (NBMA) behaviour is exhibited as these > links do not support native multicast, and broadcast reaches only a > subset of nodes on the link. The use of link-layer mesh technology > (see Mesh Under) emulates transitivity across the link but still has > problems with non-reflexitivity. Multicast on a link-layer mesh is > usually implemented as a broadcast flood. > > Link-local > > Standard IPv6 link-local scope as defined in [RFC4291] and [RFC4861] > is supported by the 6LoWPAN link and subnet model. Link-local scope > is achieved by setting the hop limit to 1, using link-local prefix > or link-local multicast scope. If a link is non-transient then non-transient? or non-transitive? > link-local scope includes only a subset of nodes on the link (the set > of nodes within assymetric radio range of a node). you mean the link-local scope covers the symmetric range, not the asymmetric range. I think? > Nodes in the link-local scope of a node are its neighbors, and this > link-local scope may be different for each node on a link. 'Link' being different than 'link-local' scope starts to be difficult to grasp. I hear you saying the link-local scope may not cover the entire link, only the part of it which is fully transitive and reflexive. It leads me more and more to think a non-transitive link is actually two links. Each link with its own link-local scope, each fully transitive and symmetric. (If so, the problem left is to fit a router with a single interface connecting to two links simultaneously (the parts of a non-transitive link).) > LoWPAN Host > > A node that only sources or sinks IPv6 datagrams. Referred to as a > host in this document. > > LoWPAN Node > > A node that composes a LoWPAN and is used to refer to both hosts and > routers. Referred to as a node in this document. > > LoWPAN Router > > A node that forwards datagrams between arbitrary source- destination > pairs using a single 6LoWPAN interface performing IP routing on that > interface. > > Mesh Under > > A term referring to a configuration where the link-local scope is > defined by the boundaries of the LoWPAN and includes all the 6LoWPAN > interfaces within it. Forwarding and multihop routing functions are > achieved at the link layer. In this configuration the link may > still exhibit assymetric behaviour. > > Route Over > > A term referring to a configuration where the link is non- transient > and the link-local scope reaches only a subset of the LoWPAN nodes. > IP routing is performed by LoWPAN Routers to overcome to the > non-transient nature of the link. This configuration may consist of > both routers nad hosts. nit: nad, should be and. > Subnet > > A subnet is the collection of interfaces having the same IPv6 subnet > prefix on a link, as defined in [RFC4291]. A LoWPAN is made up of > the interfaces of LoWPAN Nodes and Edge Routers sharing the same > subnet prefix. Due to the non-transient nature of 6LoWPAN links, IP > routing may be used on the link to provide transitivity. This > exhibits a multi-link subnet feature with regard to hop limit as > defined in [RFC4903], and thus 6LoWPAN applications should make no > assumptions about the hop limit as it may be decremented in a LoWPAN. If a hop limit is decremented within the subnet then this is not a single subnet... ND messages on the same link (subnet) don't decrement the Hop Limit. Alex > > > > From dokaspar.ietf@gmail.com Wed May 13 03:41:08 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 C53C63A6B22 for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 03:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 M5wWi6zUIKTt for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 03:41:07 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 9CFD83A6A11 for <6lowpan@ietf.org>; Wed, 13 May 2009 03:40:49 -0700 (PDT) Received: by fxm2 with SMTP id 2so553548fxm.37 for <6lowpan@ietf.org>; Wed, 13 May 2009 03:42:19 -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=rBMa+ax3Z+TeKNx2Oxj9U5ZdUzRuZIN9QX94JErsnzM=; b=FFW3G2UT/+x+DFAHLIvF5J8dTLQpRyAOCFclPZyH9bV77ppsjKKeFbUM4ZyrWW/ojC q2+fejMWWSWl79rfKAGNjclgrbOyvC0cSuS/bhn5pXJdKb2c0azaYJy5gEfvf4rAnBBZ AEo66fik+/uDHdHhXoubKlc68z4mS80TMGw6E= 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=IQib5iaqdVOjSAaT4M2bNtDQGU2GxtmUbgoJBzUm5QC0l9bxTexrDdR2Auv+GUNV/5 Js3+ihDCiGky1BmH6SHAeIFY9E5U6d4a6Hk7qRP1ZnmFLilWAsLti+5pb2AbDxHoIBTw zYV4aLe08AmUMocsVfLlsY85u2CStg1myxYdI= MIME-Version: 1.0 Received: by 10.103.227.13 with SMTP id e13mr581725mur.2.1242211339433; Wed, 13 May 2009 03:42:19 -0700 (PDT) In-Reply-To: <4A0A99B5.40506@gmail.com> References: <4A09435E.4090109@sensinode.com> <8E9C227490A7614B87D90C0AE18CF22CADE8CC7F49@NLCLUEXM06.connect1.local> <2a3692de0905130044p4b9be817m8ec7a58adf50a7d2@mail.gmail.com> <4A0A99B5.40506@gmail.com> Date: Wed, 13 May 2009 12:42:19 +0200 Message-ID: <2a3692de0905130342v27086e88v3e02a14315a2194c@mail.gmail.com> From: Dominik Kaspar To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Terminology 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, 13 May 2009 10:41:08 -0000 Hi Alex, Indeed, 'reachability' is not listed in many directories. However, the IETF seems to accept it as a word. For instance: RFC 1273 "Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet" RFC 5549 "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop" Cheers, Dominik On Wed, May 13, 2009 at 11:58 AM, Alexandru Petrescu wrote: > Dominik Kaspar a =E9crit : >> >> Hi, >> >> Would 'non-reflexive' (better called 'irreflexive') reachability > > 'Irreflexive' sounds good to my dictionary, and to me better than > non-reflexive. > > 'Reachability' is absent from many dictionaries. > > Alex > >> mean that a node can not reach itself? If so... I think the term >> still makes sense, because 6LoWPAN nodes usually cannot send and >> receive at the same time (except if they had two physical radio >> interfaces). >> >> By the way, typo: assymetric -> asymmetric. >> >> Greetings, Dominik >> >> >> On Tue, May 12, 2009 at 11:53 AM, Burnett, Peter >> wrote: >>> >>> Zach, I'm wondering if the term 'non-reflexive' in RFC4861 should >>> have been 'non-symmetric'. Mathematically, an equivalence >>> relationship is defined as being reflexive, symmetric and >>> transitive. Symmetric is the property which is untrue on a >>> unidirectional link not reflexive. Apologies if this is nonsense, >>> I'm new to this list. Thanks Peter >>> >>> -----Original Message----- From: 6lowpan-bounces@ietf.org >>> [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby Sent: >>> 2009 May 12 10:38 To: 6lowpan Subject: [6lowpan] Terminology >>> >>> Hi, >>> >>> I am working on an updated terminology set for the nd draft. The >>> terminology is now split with 6LoWPAN general terminology now in >>> its own section. I would like comments on this updated set (below) >>> where I have tried to find a solution based on the constructive >>> discussions we had on the list. >>> >>> After looking through all the background RFCs in detail, it >>> actually turns out this is not as hard as we thought. RFC4861 >>> actually does cover the wireless case as it defines assymetric >>> properties of wireless links including non-transitivity (see >>> Section 2.2). In fact RFC4861 actually mentions that the protocol >>> (ND) will presumably be extended in the future to deal with links >>> that are assymetric (non-reflexive, non-transitive). That is what >>> we are doing with ND for 6LoWPAN! >>> >>> Therefore I have now defined link as being non-transitive and >>> complex NBMA, which can be somewhat overcome using link-layer mesh >>> techniques or by with IP routing. This greatly simplifies the >>> definition of a subnet (whew!), as we keep the RFC4291 where subnet >>> <=3D link. As we are performing IP routing to overcome the >>> non-transitive nature, the subnet does exhibit one aspect of >>> multi-link subnet mentioned in RFC4903. >>> >>> IP routing has been defined as Alex recommended as it has specific >>> properties to 6LoWPAN. In the architecture section of nd-03 we will >>> =A0include LoWPAN IP routing examples including topology and what is >>> in the table. >>> >>> >>> >>> >>> General 6LoWPAN Terminology: >>> >>> This section defines additional general terms related to the >>> 6LoWPAN architecture used in this specification: >>> >>> IP Routing >>> >>> The forwarding of datagrams at the IP layer between arbitrary >>> source-destination pairs, during which the hop limit is decremented. = =A0In the >>> LoWPAN context, IP routing is performed by LoWPAN Routers on a single >>> interface within the same link to overcome the non-transient nature of = the >>> link. =A0Exact match search is performed on the dst address of the IP p= acket >>> to find the next- hop to the destination. =A0Referred to as routing in = this >>> document. >>> >>> Link >>> >>> The link is a communication facility or medium over which nodes can >>> communicate at the link-layer, i.e., the layer directly below IP >>> ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy wireless >>> links such as IEEE 802.15.4, which is a special type of link as describ= ed in >>> [RFC4861] exhibiting severe assymetric reachability with both non-refle= xive >>> and non-transitive qualities. Furthermore complex Non-broadcast Multi-A= ccess >>> (NBMA) behaviour is exhibited as these links do not support native >>> multicast, and broadcast reaches only a subset of nodes on the link. = =A0The >>> use of link-layer mesh technology (see Mesh Under) emulates transitivit= y >>> across the link but still has problems with non-reflexitivity. Multicas= t on >>> a link-layer mesh is usually implemented as a broadcast flood. >>> >>> Link-local >>> >>> Standard IPv6 link-local scope as defined in [RFC4291] and [RFC4861] is >>> supported by the 6LoWPAN link and subnet model. Link-local scope is ach= ieved >>> by setting the hop limit to 1, using link-local prefix or link-local >>> multicast scope. =A0If a link is non-transient then link-local scope in= cludes >>> only a subset of nodes >>> on the link (the set of nodes within assymetric radio range of a >>> node). =A0Nodes in the link-local scope of a node are its neighbors, >>> and this link-local scope may be different for each node on a link. >>> >>> >>> LoWPAN Host >>> >>> A node that only sources or sinks IPv6 datagrams. =A0Referred to as a >>> host in this document. >>> >>> LoWPAN Node >>> >>> A node that composes a LoWPAN and is used to refer to both hosts and >>> routers. =A0Referred to as a node in this document. >>> >>> LoWPAN Router >>> >>> A node that forwards datagrams between arbitrary source- destination >>> pairs using a single 6LoWPAN interface performing IP routing on that >>> interface. >>> >>> Mesh Under >>> >>> A term referring to a configuration where the link-local scope is defin= ed >>> by the boundaries of the LoWPAN and includes all the 6LoWPAN interfaces >>> within it. =A0Forwarding and multihop routing functions are achieved at= the >>> link layer. =A0In this configuration the link may still exhibit assymet= ric >>> behaviour. >>> >>> Route Over >>> >>> A term referring to a configuration where the link is non- transient an= d >>> the link-local scope reaches only a subset of the LoWPAN nodes. =A0IP r= outing >>> is performed by LoWPAN Routers to overcome to the non-transient nature = of >>> the link. =A0This configuration may consist of both routers nad hosts. >>> >>> Subnet >>> >>> A subnet is the collection of interfaces having the same IPv6 subnet >>> prefix on a link, as defined in [RFC4291]. =A0A LoWPAN is made >>> up of the interfaces of LoWPAN Nodes and Edge Routers sharing the >>> same subnet prefix. =A0Due to the non-transient nature of 6LoWPAN >>> links, IP routing may be used on the link to provide transitivity. >>> This exhibits a multi-link subnet feature with regard to hop limit >>> as defined in [RFC4903], and thus 6LoWPAN applications should make >>> no assumptions about the hop limit as it may be decremented in a >>> LoWPAN. >>> >>> >>> -- 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. _______________________________________________ 6lowpan >>> mailing list 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> The information contained in this message may be confidential and >>> legally protected under applicable law. The message is intended >>> solely for the addressee(s). If you are not the intended recipient, >>> you are hereby notified that any use, forwarding, dissemination, or >>> reproduction of this message is strictly prohibited and may be >>> unlawful. If you are not the intended recipient, please contact the >>> sender by return e-mail and destroy all copies of the original >>> message. _______________________________________________ 6lowpan >>> mailing list 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> _______________________________________________ 6lowpan mailing list >> 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan >> > > > From zach@sensinode.com Wed May 13 06:16: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 C319A3A6D0E for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 06:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 ZO+sKbJwgcSg for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 06:16:53 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id DF28A3A6A4F for <6lowpan@ietf.org>; Wed, 13 May 2009 06:16:52 -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 n4DDIJmB011253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 16:18:19 +0300 Message-ID: <4A0AC8CA.7050704@sensinode.com> Date: Wed, 13 May 2009 16:19:06 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dominik Kaspar References: <4A09435E.4090109@sensinode.com> <8E9C227490A7614B87D90C0AE18CF22CADE8CC7F49@NLCLUEXM06.connect1.local> <2a3692de0905130044p4b9be817m8ec7a58adf50a7d2@mail.gmail.com> In-Reply-To: <2a3692de0905130044p4b9be817m8ec7a58adf50a7d2@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Terminology 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, 13 May 2009 13:16:54 -0000 Dominik, I would prefer using the RFC4861 terminology exactly, here is the text from Section 2.2 page 9: asymmetric reachability - a link where non-reflexive and/or non-transitive reachability is part of normal operation. (Non- reflexive reachability means packets from A reach B, but packets from B don't reach A. Non-transitive reachability means packets from A reach B, and packets from B reach C, but packets from A don't reach C.) Many radio links exhibit these properties. Here is an updated link definition including examples (in brackets): Link The link is a communication facility or medium over which nodes can communicate at the link-layer, i.e., the layer directly below IP ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy wireless links such as IEEE 802.15.4, which is a special type of link as described in [RFC4861] exhibiting severe asymmetric reachability with both non-reflexive (A can reach B, but B can't reach A) and non-transitive (A can reach B, and B can reach C, but A can't reach C) qualities. Furthermore complex Non-broadcast Multi-Access (NBMA) behaviour is exhibited as these links do not support native multicast, and broadcast reaches only a subset of nodes on the link. Such a wireless link may consist of multiple overlapping link-local scopes. The use of link-layer mesh technology (see Mesh Under) emulates transitivity across the link but still has problems with non- reflexitivity. Multicast on a link-layer mesh is usually implemented as a broadcast flood. - Zach Dominik Kaspar wrote: > Hi, > > Would 'non-reflexive' (better called 'irreflexive') reachability mean > that a node can not reach itself? If so... I think the term still > makes sense, because 6LoWPAN nodes usually cannot send and receive at > the same time (except if they had two physical radio interfaces). > > By the way, typo: assymetric -> asymmetric. > > Greetings, > Dominik > > > On Tue, May 12, 2009 at 11:53 AM, Burnett, Peter > wrote: >> Zach, >> I'm wondering if the term 'non-reflexive' in RFC4861 should have been 'non-symmetric'. Mathematically, an equivalence relationship is defined as being reflexive, symmetric and transitive. Symmetric is the property which is untrue on a unidirectional link not reflexive. >> Apologies if this is nonsense, I'm new to this list. >> Thanks >> Peter >> >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby >> Sent: 2009 May 12 10:38 >> To: 6lowpan >> Subject: [6lowpan] Terminology >> >> Hi, >> >> I am working on an updated terminology set for the nd draft. The >> terminology is now split with 6LoWPAN general terminology now in its own >> section. I would like comments on this updated set (below) where I have >> tried to find a solution based on the constructive discussions we had on >> the list. >> >> After looking through all the background RFCs in detail, it actually >> turns out this is not as hard as we thought. RFC4861 actually does cover >> the wireless case as it defines assymetric properties of wireless links >> including non-transitivity (see Section 2.2). In fact RFC4861 actually >> mentions that the protocol (ND) will presumably be extended in the >> future to deal with links that are assymetric (non-reflexive, >> non-transitive). That is what we are doing with ND for 6LoWPAN! >> >> Therefore I have now defined link as being non-transitive and complex >> NBMA, which can be somewhat overcome using link-layer mesh techniques or >> by with IP routing. This greatly simplifies the definition of a subnet >> (whew!), as we keep the RFC4291 where subnet <= link. As we are >> performing IP routing to overcome the non-transitive nature, the subnet >> does exhibit one aspect of multi-link subnet mentioned in RFC4903. >> >> IP routing has been defined as Alex recommended as it has specific >> properties to 6LoWPAN. In the architecture section of nd-03 we will >> include LoWPAN IP routing examples including topology and what is in the >> table. >> >> >> >> >> General 6LoWPAN Terminology: >> >> This section defines additional general terms related to the 6LoWPAN >> architecture used in this specification: >> >> IP Routing >> >> The forwarding of datagrams at the IP layer between arbitrary >> source-destination pairs, during which the hop limit is >> decremented. In the LoWPAN context, IP routing is performed by >> LoWPAN Routers on a single interface within the same link to >> overcome the non-transient nature of the link. Exact match search >> is performed on the dst address of the IP packet to find the next- >> hop to the destination. Referred to as routing in this document. >> >> Link >> >> The link is a communication facility or medium over which nodes >> can communicate at the link-layer, i.e., the layer directly below >> IP ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy >> wireless links such as IEEE 802.15.4, which is a special type of >> link as described in [RFC4861] exhibiting severe assymetric >> reachability with both non-reflexive and non-transitive qualities. >> Furthermore complex Non-broadcast Multi-Access (NBMA) behaviour is >> exhibited as these links do not support native multicast, and >> broadcast reaches only a subset of nodes on the link. The use of >> link-layer mesh technology (see Mesh Under) emulates transitivity >> across the link but still has problems with non-reflexitivity. >> Multicast on a link-layer mesh is usually implemented as a >> broadcast flood. >> >> Link-local >> >> Standard IPv6 link-local scope as defined in [RFC4291] and >> [RFC4861] is supported by the 6LoWPAN link and subnet model. >> Link-local scope is achieved by setting the hop limit to 1, using >> link-local prefix or link-local multicast scope. If a link is >> non-transient then link-local scope includes only a subset of >> nodes on the link (the set of nodes within assymetric radio range >> of a node). Nodes in the link-local scope of a node are its >> neighbors, and this link-local scope may be different for each >> node on a link. >> >> LoWPAN Host >> >> A node that only sources or sinks IPv6 datagrams. Referred to as >> a host in this document. >> >> LoWPAN Node >> >> A node that composes a LoWPAN and is used to refer to both hosts >> and routers. Referred to as a node in this document. >> >> LoWPAN Router >> >> A node that forwards datagrams between arbitrary source- >> destination pairs using a single 6LoWPAN interface performing IP >> routing on that interface. >> >> Mesh Under >> >> A term referring to a configuration where the link-local scope is >> defined by the boundaries of the LoWPAN and includes all the >> 6LoWPAN interfaces within it. Forwarding and multihop routing >> functions are achieved at the link layer. In this configuration >> the link may still exhibit assymetric behaviour. >> >> Route Over >> >> A term referring to a configuration where the link is non- >> transient and the link-local scope reaches only a subset of the >> LoWPAN nodes. IP routing is performed by LoWPAN Routers to >> overcome to the non-transient nature of the link. This >> configuration may consist of both routers nad hosts. >> >> Subnet >> >> A subnet is the collection of interfaces having the same IPv6 >> subnet prefix on a link, as defined in [RFC4291]. A LoWPAN is >> made up of the interfaces of LoWPAN Nodes and Edge Routers sharing >> the same subnet prefix. Due to the non-transient nature of >> 6LoWPAN links, IP routing may be used on the link to provide >> transitivity. This exhibits a multi-link subnet feature with >> regard to hop limit as defined in [RFC4903], and thus 6LoWPAN >> applications should make no assumptions about the hop limit as it >> may be decremented in a LoWPAN. >> >> >> -- >> 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. >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> -- 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 Wed May 13 06:44:17 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 A3B8C3A6FBE for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 06:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 ZMsN4CwnT9Yp for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 06:44:16 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 9B0113A6A42 for <6lowpan@ietf.org>; Wed, 13 May 2009 06:44:15 -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 n4DDjgCv014492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 16:45:42 +0300 Message-ID: <4A0ACF35.6030004@sensinode.com> Date: Wed, 13 May 2009 16:46:29 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> In-Reply-To: <4A0AA3B3.9010301@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Terminology 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, 13 May 2009 13:44:17 -0000 Alex, Alexandru Petrescu wrote: > Zach, thanks for consolidating our recent discussions. I have comments > on the proposed terminology. I mainly agree with most terms. I point > where I don't agree. Good we're getting close here. There are several hard facts that we have to live with in this WG, which I try to capture in these definitions: 1. A LoWPAN must have a common subnet prefix, this is how compression works! 2. The wireless links we work with are non-transitive, non-reflexive. It is made up of overlapping broadcast scopes. 3. L3 routing inside LoWPANs is a reality (vendors are doing it, ROLL is designing it) So we have two options (#1 is what I am proposing, #2 was used in nd-02): 1. Model the whole wireless channel as a non-transitive link, made up of overlapping broadcast scopes (link-local scopes). A LoWPAN is a subnet, which may be a multi-hop subnet. 2. Model each broadcast scope as a link. A LoWPAN is a subnet, which is a multi-link subnet as it is made up of a whole bunch of overlapping links. Considering RFC4861, RFC4903 and IETF terminology on a whole #1 is easier to swallow. > Zach Shelby a écrit : >> Hi, >> >> I am working on an updated terminology set for the nd draft. The >> terminology is now split with 6LoWPAN general terminology now in its >> own section. I would like comments on this updated set (below) where >> I have tried to find a solution based on the constructive >> discussions we had on the list. >> >> After looking through all the background RFCs in detail, it actually >> turns out this is not as hard as we thought. RFC4861 actually does >> cover the wireless case as it defines assymetric properties of >> wireless links including non-transitivity (see Section 2.2). > > YEs. > >> In fact RFC4861 actually mentions that the protocol (ND) will >> presumably be extended in the future to deal with links that are >> assymetric (non-reflexive, non-transitive). That is what we are doing >> with ND for 6LoWPAN! > > YEs, it seems straightforward and obvious to agree. I agree with it, > makes sense and is concrete. > > However, just a note to say this is what AUTOCONF and MANET WGs also > claim(ed). Despite this obviousness, it is not stipulated in neither of > the three Charters. > > By my reading, nothing in the three Charters makes think about the > necessity to extend ND to deal with non-transitive links, although many > people's conversations assume it so. > > This was just a note. >> Therefore I have now defined link as being non-transitive and complex >> NBMA, which can be somewhat overcome using link-layer mesh techniques >> or by with IP routing. This greatly simplifies the definition of a >> subnet (whew!), as we keep the RFC4291 where subnet <= link. As we are >> performing IP routing to overcome the non-transitive nature, the >> subnet does exhibit one aspect of multi-link subnet mentioned in RFC4903. >> >> IP Routing >> >> The forwarding of datagrams at the IP layer between arbitrary >> source-destination pairs, during which the hop limit is decremented. >> In the LoWPAN context, IP routing is performed by LoWPAN Routers on >> a single interface within the same link to overcome the non-transient >> nature of the link. Exact match search is performed on the dst >> address of the IP packet to find the next- hop to the destination. >> Referred to as routing in this document. >> >> Link >> >> The link is a communication facility or medium over which nodes can >> communicate at the link-layer, i.e., the layer directly below IP >> ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy wireless >> links such as IEEE 802.15.4, which is a special type of link as >> described in [RFC4861] exhibiting severe assymetric reachability with >> both non-reflexive and non-transitive qualities. Furthermore complex >> Non-broadcast Multi-Access (NBMA) behaviour is exhibited as these >> links do not support native multicast, and broadcast reaches only a >> subset of nodes on the link. The use of link-layer mesh technology >> (see Mesh Under) emulates transitivity across the link but still has >> problems with non-reflexitivity. Multicast on a link-layer mesh is >> usually implemented as a broadcast flood. >> >> Link-local >> >> Standard IPv6 link-local scope as defined in [RFC4291] and [RFC4861] >> is supported by the 6LoWPAN link and subnet model. Link-local scope >> is achieved by setting the hop limit to 1, using link-local prefix >> or link-local multicast scope. If a link is non-transient then > > non-transient? or non-transitive? non-transitive, thanks. >> link-local scope includes only a subset of nodes on the link (the set >> of nodes within assymetric radio range of a node). > > you mean the link-local scope covers the symmetric range, not the > asymmetric range. I think? symmetric, exactly. >> Nodes in the link-local scope of a node are its neighbors, and this >> link-local scope may be different for each node on a link. > > 'Link' being different than 'link-local' scope starts to be difficult to > grasp. This is exactly what a non-transitive link is according to RFC4861 definition. This is also the reality with wireless links the 6lowpan WG is dealing with - it covers the situation well using IETF terminology. > I hear you saying the link-local scope may not cover the entire > link, only the part of it which is fully transitive and reflexive. It > leads me more and more to think a non-transitive link is actually two > links. Each link with its own link-local scope, each fully transitive > and symmetric. (If so, the problem left is to fit a router with a > single interface connecting to two links simultaneously (the parts of a > non-transitive link).) You can't split this non-transitive link into a clean set of transitive ones just like that. It doesn't work, especially from the single-interface router point of view. A - B - C A can reach B, B can reach C, but A can't reach C. B is a LoWPAN Router. From its perspective, its link-local scope includes both A and C. It does not have two links by any means. It is forwarding between two nodes on the same link (and in the same link-local scope) who don't have transitivity between each other (A and C). >> LoWPAN Host >> >> A node that only sources or sinks IPv6 datagrams. Referred to as a >> host in this document. >> >> LoWPAN Node >> >> A node that composes a LoWPAN and is used to refer to both hosts and >> routers. Referred to as a node in this document. >> >> LoWPAN Router >> >> A node that forwards datagrams between arbitrary source- destination >> pairs using a single 6LoWPAN interface performing IP routing on that >> interface. > > >> Mesh Under >> >> A term referring to a configuration where the link-local scope is >> defined by the boundaries of the LoWPAN and includes all the 6LoWPAN >> interfaces within it. Forwarding and multihop routing functions are >> achieved at the link layer. In this configuration the link may >> still exhibit assymetric behaviour. >> >> Route Over >> >> A term referring to a configuration where the link is non- transient >> and the link-local scope reaches only a subset of the LoWPAN nodes. >> IP routing is performed by LoWPAN Routers to overcome to the >> non-transient nature of the link. This configuration may consist of >> both routers nad hosts. > > nit: nad, should be and. > >> Subnet >> >> A subnet is the collection of interfaces having the same IPv6 subnet >> prefix on a link, as defined in [RFC4291]. A LoWPAN is made up of >> the interfaces of LoWPAN Nodes and Edge Routers sharing the same >> subnet prefix. Due to the non-transient nature of 6LoWPAN links, IP >> routing may be used on the link to provide transitivity. This >> exhibits a multi-link subnet feature with regard to hop limit as >> defined in [RFC4903], and thus 6LoWPAN applications should make no >> assumptions about the hop limit as it may be decremented in a LoWPAN. > > If a hop limit is decremented within the subnet then this is not a > single subnet... I don't agree. Read RFC4903 again. It exhibits one aspect of a multi-link subnet. However as I am proposing we model the 6LoWPAN as a non-transient link what we have here is actually a multi-hop subnet, which is a lesser evil than a multi-link subnet. > ND messages on the same link (subnet) don't decrement the Hop Limit. LoWPAN IP Routers do decrement the hop limit, and all nodes in a LoWPAN are inside a subnet because this is the 6lowpan wg. This is something we just can't change in 6lowpan - the whole concept behind the compression is that there is a shared prefix across the LoWPAN, which is why we can compress addresses. So we are stuck with LoWPAN = subnet. If the subnet term is a problem, then I did make a suggestion earlier to stop calling it a subnet all together and just call it a LoWPAN... or supernet? Neighborhood? > Alex > > > >> >> >> >> > > -- 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 alexandru.petrescu@gmail.com Wed May 13 13:31: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 CF22C3A6BCD for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 13:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[AWL=-0.943, BAYES_40=-0.185, 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 hfN7szLgQrw5 for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 13:31:50 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id CFA8B28C25F for <6lowpan@ietf.org>; Wed, 13 May 2009 13:30:58 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id BF6FB4B0149; Wed, 13 May 2009 22:32:27 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP id 46F6A4B00E6; Wed, 13 May 2009 22:32:24 +0200 (CEST) Message-ID: <4A0B2E50.3040006@gmail.com> Date: Wed, 13 May 2009 22:32:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> <4A0ACF35.6030004@sensinode.com> In-Reply-To: <4A0ACF35.6030004@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090513-0, 13/05/2009), Outbound message X-Antivirus-Status: Clean Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Terminology 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, 13 May 2009 20:31:50 -0000 Zach Shelby a écrit : [...] >> I hear you saying the link-local scope may not cover the entire >> link, only the part of it which is fully transitive and reflexive. It >> leads me more and more to think a non-transitive link is actually two >> links. Each link with its own link-local scope, each fully transitive >> and symmetric. (If so, the problem left is to fit a router with a >> single interface connecting to two links simultaneously (the parts of >> a non-transitive link).) > > You can't split this non-transitive link into a clean set of transitive > ones just like that. It doesn't work, especially from the > single-interface router point of view. > > A - B - C > > A can reach B, B can reach C, but A can't reach C. > > B is a LoWPAN Router. From its perspective, its link-local scope > includes both A and C. It does not have two links by any means. It is > forwarding between two nodes on the same link (and in the same > link-local scope) who don't have transitivity between each other (A and C). B in LL scopes of both A and C, B has a single interface... could it be that B forwards a packet from A to C without A hearing it too? Node A receiving its own packet could be easily qualified as noise. Otherwise nodes should have a means to know on _which_ link-local scopes are they, and send data on only one scope. But I think there's only one link-local address per interface, and only a scope_id field in the respective C struct. Sorry for insisting on this, it is IMHO. I will agree with the WG further. Alex From zach@sensinode.com Wed May 13 14:25: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 F2C053A6898 for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 14:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 7KT7x3gytVsw for <6lowpan@core3.amsl.com>; Wed, 13 May 2009 14:25:40 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 363FD3A6BE0 for <6lowpan@ietf.org>; Wed, 13 May 2009 14:25:39 -0700 (PDT) Received: from snl-zach.local (line-4896.dyn.kponet.fi [85.29.65.114]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n4DLQq23025199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 00:26:52 +0300 Message-ID: <4A0B3B4D.6000704@sensinode.com> Date: Thu, 14 May 2009 00:27:41 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> <4A0ACF35.6030004@sensinode.com> <4A0B2E50.3040006@gmail.com> In-Reply-To: <4A0B2E50.3040006@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Terminology 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, 13 May 2009 21:25:42 -0000 Alexandru Petrescu wrote: > Zach Shelby a écrit : > [...] >>> I hear you saying the link-local scope may not cover the entire >>> link, only the part of it which is fully transitive and reflexive. It >>> leads me more and more to think a non-transitive link is actually two >>> links. Each link with its own link-local scope, each fully >>> transitive and symmetric. (If so, the problem left is to fit a >>> router with a single interface connecting to two links simultaneously >>> (the parts of a non-transitive link).) >> >> You can't split this non-transitive link into a clean set of >> transitive ones just like that. It doesn't work, especially from the >> single-interface router point of view. > > >> A - B - C >> >> A can reach B, B can reach C, but A can't reach C. >> >> B is a LoWPAN Router. From its perspective, its link-local scope >> includes both A and C. It does not have two links by any means. It is >> forwarding between two nodes on the same link (and in the same >> link-local scope) who don't have transitivity between each other (A >> and C). > > B in LL scopes of both A and C, B has a single interface... could it be > that B forwards a packet from A to C without A hearing it too? A's link-layer can hear when B forwards the packet (unless it went to sleep immediately).. > Node A receiving its own packet could be easily qualified as noise. However, as the IP destination is the unicast address of C, the link-layer destination is the MAC address of C. Thus A's link-layer will discard it. Medium access control schemes of wireless link-layers are able to deal with extra transmissions from multihop forwarding. Of course because you are forwarding with a single interface, your channel capacity decreases with more hops (this is the multihop penalty of all such schemes, including Mesh Under). > Otherwise nodes should have a means to know on _which_ link-local scopes > are they, and send data on only one scope. But I think there's only one > link-local address per interface, and only a scope_id field in the > respective C struct. Not needed, the link-layer deals with this using MAC addressing and the MAC algorithm. A node just tracks who are its neighbors. > Sorry for insisting on this, it is IMHO. I will agree with the WG further. No problem, as a WG we needed to re-assure we agree on the terminology. In fact I think you helped make a big improvement with the link and LoWPAN IP routing definitions. > Alex -- 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 alexandru.petrescu@gmail.com Thu May 14 02:39:34 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 447AA3A6EA7 for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 02:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, 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 tDEsSrTf9H+A for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 02:39:33 -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 2E84D3A6CD8 for <6lowpan@ietf.org>; Thu, 14 May 2009 02:39:33 -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 n4E9crU4013696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 May 2009 11:38:53 +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 n4E9f451008516; Thu, 14 May 2009 11:41:04 +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 n4E9f3JX019668; Thu, 14 May 2009 11:41:03 +0200 Message-ID: <4A0BE72F.6030507@gmail.com> Date: Thu, 14 May 2009 11:41:03 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> <4A0ACF35.6030004@sensinode.com> <4A0B2E50.3040006@gmail.com> <4A0B3B4D.6000704@sensinode.com> In-Reply-To: <4A0B3B4D.6000704@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Terminology 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, 14 May 2009 09:39:34 -0000 Zach Shelby a écrit : > > Alexandru Petrescu wrote: >> Zach Shelby a écrit : [...] >>>> I hear you saying the link-local scope may not cover the >>>> entire link, only the part of it which is fully transitive and >>>> reflexive. It leads me more and more to think a non-transitive >>>> link is actually two links. Each link with its own link-local >>>> scope, each fully transitive and symmetric. (If so, the >>>> problem left is to fit a router with a single interface >>>> connecting to two links simultaneously (the parts of a >>>> non-transitive link).) >>> >>> You can't split this non-transitive link into a clean set of >>> transitive ones just like that. It doesn't work, especially from >>> the single-interface router point of view. >>> >>> A - B - C >>> >>> A can reach B, B can reach C, but A can't reach C. >>> >>> B is a LoWPAN Router. From its perspective, its link-local scope >>> includes both A and C. It does not have two links by any means. >>> It is forwarding between two nodes on the same link (and in the >>> same link-local scope) who don't have transitivity between each >>> other (A and C). >> >> B in LL scopes of both A and C, B has a single interface... could >> it be that B forwards a packet from A to C without A hearing it >> too? > > A's link-layer can hear when B forwards the packet (unless it went to > sleep immediately).. Ok. >> Node A receiving its own packet could be easily qualified as noise. >> >> > > However, as the IP destination is the unicast address of C, the > link-layer destination is the MAC address of C. Thus A's link-layer > will discard it. Ok when the IP and MAC addresses are not multicast. When they are, like when A sends an RS to "all-nodes" IP address (converted into "all-nodes" MAC address) B repeats back this packet to A (because in the same link-local scope as A), in addition to forwarding it to C. This could lead to more noise, maybe even an RA generated by A. > Medium access control schemes of wireless link-layers are able to > deal with extra transmissions from multihop forwarding. I agree MAC schemes could alleviate the B transmits back to A problems. And these schemes are part (supposedly?) of the Mesh-Under concept. Which makes think that Route-Over wouldn't work without Mesh-Under at the same time. > Of course because you are forwarding with a single interface, your > channel capacity decreases with more hops (this is the multihop > penalty of all such schemes, including Mesh Under). Ok. >> Otherwise nodes should have a means to know on _which_ link-local >> scopes are they, and send data on only one scope. But I think >> there's only one link-local address per interface, and only a >> scope_id field in the respective C struct. > > Not needed, the link-layer deals with this using MAC addressing and > the MAC algorithm. A node just tracks who are its neighbors. Ok. Some questions rest about how does the link layer deal with link-layer multicast addresses, when they are used by RS and NS, such that to avoid noise amplification on non-transitive links. Alex From zach@sensinode.com Thu May 14 02:59:32 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 422823A6A8B for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 02:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 qYrBhIx3CD37 for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 02:59:31 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E93823A6F32 for <6lowpan@ietf.org>; Thu, 14 May 2009 02:59:30 -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 n4EA0wxV019813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 13:00:58 +0300 Message-ID: <4A0BEC0D.5060609@sensinode.com> Date: Thu, 14 May 2009 13:01:49 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> <4A0ACF35.6030004@sensinode.com> <4A0B2E50.3040006@gmail.com> <4A0B3B4D.6000704@sensinode.com> <4A0BE72F.6030507@gmail.com> In-Reply-To: <4A0BE72F.6030507@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Terminology 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, 14 May 2009 09:59:32 -0000 Alexandru Petrescu wrote: > Zach Shelby a écrit : >> >> Alexandru Petrescu wrote: >>> Zach Shelby a écrit : [...] >>>>> I hear you saying the link-local scope may not cover the entire >>>>> link, only the part of it which is fully transitive and reflexive. >>>>> It leads me more and more to think a non-transitive >>>>> link is actually two links. Each link with its own link-local >>>>> scope, each fully transitive and symmetric. (If so, the problem >>>>> left is to fit a router with a single interface connecting to two >>>>> links simultaneously (the parts of a non-transitive link).) >>>> >>>> You can't split this non-transitive link into a clean set of >>>> transitive ones just like that. It doesn't work, especially from the >>>> single-interface router point of view. >>>> >>>> A - B - C >>>> >>>> A can reach B, B can reach C, but A can't reach C. >>>> >>>> B is a LoWPAN Router. From its perspective, its link-local scope >>>> includes both A and C. It does not have two links by any means. It >>>> is forwarding between two nodes on the same link (and in the same >>>> link-local scope) who don't have transitivity between each other (A >>>> and C). >>> >>> B in LL scopes of both A and C, B has a single interface... could it >>> be that B forwards a packet from A to C without A hearing it too? >> >> A's link-layer can hear when B forwards the packet (unless it went to >> sleep immediately).. > > Ok. > >>> Node A receiving its own packet could be easily qualified as noise. >>> >>> >> >> However, as the IP destination is the unicast address of C, the >> link-layer destination is the MAC address of C. Thus A's link-layer >> will discard it. > > Ok when the IP and MAC addresses are not multicast. > > When they are, like when A sends an RS to "all-nodes" IP address > (converted into "all-nodes" MAC address) B repeats back this packet to A > (because in the same link-local scope as A), in addition to forwarding > it to C. This could lead to more noise, maybe even an RA generated by A. Multicast with link-local scope, is simply a link-layer broadcast and is not retransmitted. So the above does not occur. Thus this kind of multicast used by RAs and NSs is not a big problem. We should still keep the frequency of these down. If you try to do a multicast with scope > 2, then you have a flooding problem unless multicast is implemented in some other way. This is why we use the Whiteboard approach in 6lowpan-nd, to avoid the need to flood the LoWPAN. >> Medium access control schemes of wireless link-layers are able to deal >> with extra transmissions from multihop forwarding. > > I agree MAC schemes could alleviate the B transmits back to A problems. > And these schemes are part (supposedly?) of the Mesh-Under concept. > Which makes think that Route-Over wouldn't work without Mesh-Under at > the same time. This has nothing to do with mesh-under. Every wireless link-layer implements medium access control, for example CSMA in the case of IEEE 802.15.4. >> Of course because you are forwarding with a single interface, your >> channel capacity decreases with more hops (this is the multihop >> penalty of all such schemes, including Mesh Under). > > Ok. > >>> Otherwise nodes should have a means to know on _which_ link-local >>> scopes are they, and send data on only one scope. But I think >>> there's only one link-local address per interface, and only a >>> scope_id field in the respective C struct. >> >> Not needed, the link-layer deals with this using MAC addressing and >> the MAC algorithm. A node just tracks who are its neighbors. > > Ok. Some questions rest about how does the link layer deal with > link-layer multicast addresses, when they are used by RS and NS, such > that to avoid noise amplification on non-transitive links. You use link-local scope and it is not a problem (RS and NS are link-local messages). You of course want to keep the amount of ND signaling on a whole as low as possible - which is a goal of 6lowpan-nd. > Alex > > -- 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 alexandru.petrescu@gmail.com Thu May 14 03:59:10 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 ED27F3A69B2 for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 03:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, 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 8gO3HVT-d0yh for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 03:59:10 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 87C083A67AA for <6lowpan@ietf.org>; Thu, 14 May 2009 03:59:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4EB0eEp016794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 May 2009 13:00:40 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4EB0eV5023516; Thu, 14 May 2009 13:00:40 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n4EB0dUL015057; Thu, 14 May 2009 13:00:39 +0200 Message-ID: <4A0BF9D7.8060202@gmail.com> Date: Thu, 14 May 2009 13:00:39 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> <4A0ACF35.6030004@sensinode.com> <4A0B2E50.3040006@gmail.com> <4A0B3B4D.6000704@sensinode.com> <4A0BE72F.6030507@gmail.com> <4A0BEC0D.5060609@sensinode.com> In-Reply-To: <4A0BEC0D.5060609@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Terminology 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, 14 May 2009 10:59:11 -0000 Zach Shelby a écrit : [...] > If you try to do a multicast with scope > 2, then you have a flooding > problem unless multicast is implemented in some other way. This is > why we use the Whiteboard approach in 6lowpan-nd, to avoid the need > to flood the LoWPAN. 6lowpan-ND Whiteboard instead of link-layer multicast... maybe we should make another thread... For example it says: > Another consequence [of forming address from MAC] is that the > link-local address is presumably unique on the Extended LoWPAN, This is not a very safe assumption IMHO. At least because the uniqueness assumed with IPv6 addresses formed from short 16bit addresses is a uniqueness relative to a "PAN id" (and not to a LoWPAN, not an Extended LoWPAN), even less globally unique. And we don't know anything about the uniqueness of PAN-IDs, do we? > which enables the use of Optimistic Duplicate Address Detection > (oDAD) [RFC4429] over the Transit Link and the LoWPAN. AFAIK oDAD does use the typical ND link-local multicast messages, so does 6LoWPAN use ND link-local multicast messages or not? (Transit Link on Edge Router overlaps its link-local scope over the LoWPAN) > To simplify address resolution it is assumed that nodes within a > LoWPAN use addresses in a homogeneous way and that the unicast IPv6 > address IIDs resolve directly to a corresponding link-layer address. I just suppose it unsafe to assume an IPv6 address IIDs address resolves directly into a MAC address, IMHO. Because: -it prohibits the use of manually assigned link-local addresses. -it requires link-layers to have MAC addresses (not all have). -in particular for IPv6-over-802.15.4 it is difficult to distinguish an IID to correspond to a short (16bit) or normal MAC address. What is the MAC address from which this IPv6 address was formed? fe80::21:70ff:feb8:8252 After removing the fffe and the fe80 - is there a short 16bit MAC address in there concatenated to the PAN ID? Or is it a locally unique manually assigned 48bit MAC address? Or a locally-unique self-derived non-standard USB address? > Upon a registration flow, an edge router doing DAD Doing DAD or DAD? > If successful, this address is returned in an Address Option of the > RC with the 'A' flag set and the assigned IPv6 address formed from > the generated link-layer address with the defualt prefix inline. This is typically a DHCPv6 function (a router forming an address for a host and sending it for assignment on interface). One would expect the draft to refer DHCPv6 and say why not, no? Alex From alexandru.petrescu@gmail.com Thu May 14 04:04: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 53DFE3A67AA for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 04:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, 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 ut2+SOlOJTM9 for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 04:04:12 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 449B628C0EC for <6lowpan@ietf.org>; Thu, 14 May 2009 04:04:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4EB5iKg017833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 May 2009 13:05:44 +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 n4EB5h9O024629; Thu, 14 May 2009 13:05:44 +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 n4EB5hJ6014466; Thu, 14 May 2009 13:05:43 +0200 Message-ID: <4A0BFB07.9030803@gmail.com> Date: Thu, 14 May 2009 13:05:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> <4A0ACF35.6030004@sensinode.com> <4A0B2E50.3040006@gmail.com> <4A0B3B4D.6000704@sensinode.com> <4A0BE72F.6030507@gmail.com> <4A0BEC0D.5060609@sensinode.com> In-Reply-To: <4A0BEC0D.5060609@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] multicast with link-local scope (was: Terminology) 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, 14 May 2009 11:04:13 -0000 Zach Shelby a écrit : [...] > Multicast with link-local scope, is simply a link-layer broadcast and is > not retransmitted. I am not sure what you mean (in general? 802.15.4 in particular?) but multicast with link-local scope maps into link-layer multicast, and is not simply link-layer broadcast. Some link-layers do support link-layer multicast and it is all an advantage to ND. For example to each IP link-local multicast address corresponds a MAC link-layer multicast address (like 33:33::1). Moreover, IPv6 stacks simply don't work with link-layer addresses which use MAC broadcast addresses (48 1 bits). Alex So the above does not occur. Thus this kind of > multicast used by RAs and NSs is not a big problem. We should still keep > the frequency of these down. > > If you try to do a multicast with scope > 2, then you have a flooding > problem unless multicast is implemented in some other way. This is why > we use the Whiteboard approach in 6lowpan-nd, to avoid the need to flood > the LoWPAN. > >>> Medium access control schemes of wireless link-layers are able to >>> deal with extra transmissions from multihop forwarding. >> >> I agree MAC schemes could alleviate the B transmits back to A problems. >> And these schemes are part (supposedly?) of the Mesh-Under concept. >> Which makes think that Route-Over wouldn't work without Mesh-Under at >> the same time. > > This has nothing to do with mesh-under. Every wireless link-layer > implements medium access control, for example CSMA in the case of IEEE > 802.15.4. > >>> Of course because you are forwarding with a single interface, your >>> channel capacity decreases with more hops (this is the multihop >>> penalty of all such schemes, including Mesh Under). >> >> Ok. >> >>>> Otherwise nodes should have a means to know on _which_ link-local >>>> scopes are they, and send data on only one scope. But I think >>>> there's only one link-local address per interface, and only a >>>> scope_id field in the respective C struct. >>> >>> Not needed, the link-layer deals with this using MAC addressing and >>> the MAC algorithm. A node just tracks who are its neighbors. >> >> Ok. Some questions rest about how does the link layer deal with >> link-layer multicast addresses, when they are used by RS and NS, such >> that to avoid noise amplification on non-transitive links. > > You use link-local scope and it is not a problem (RS and NS are > link-local messages). You of course want to keep the amount of ND > signaling on a whole as low as possible - which is a goal of 6lowpan-nd. > >> Alex >> >> > From zach@sensinode.com Thu May 14 04:24: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 461133A6DC0 for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 04:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 xd3YkvjPmNRK for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 04:24:38 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id BDB563A6D32 for <6lowpan@ietf.org>; Thu, 14 May 2009 04:24:37 -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 n4EBQ4Cv027151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 14:26:05 +0300 Message-ID: <4A0C0000.5000402@sensinode.com> Date: Thu, 14 May 2009 14:26:56 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> <4A0ACF35.6030004@sensinode.com> <4A0B2E50.3040006@gmail.com> <4A0B3B4D.6000704@sensinode.com> <4A0BE72F.6030507@gmail.com> <4A0BEC0D.5060609@sensinode.com> <4A0BF9D7.8060202@gmail.com> In-Reply-To: <4A0BF9D7.8060202@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Terminology 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, 14 May 2009 11:24:39 -0000 Hi, Now you are off of terminology, good. Let's leave the terminology alone for a while. On 6lowpan-nd we need to concentrate on the protocol details and implementation aspects. I changed the name of this thread. But lets please not re-tread on old subjects here. How about we do our best on nd-03 to make things crystal clear and then do another comment round? OK? Some of your criticism here is on the very foundations of what this WG was chartered to do, and how e.g. IEEE 802.15.4 and similar link-layers work. Those we can't do anything about, so no use arguing about them. Alexandru Petrescu wrote: > Zach Shelby a écrit : > [...] >> If you try to do a multicast with scope > 2, then you have a flooding >> problem unless multicast is implemented in some other way. This is >> why we use the Whiteboard approach in 6lowpan-nd, to avoid the need to >> flood the LoWPAN. > > 6lowpan-ND Whiteboard instead of link-layer multicast... maybe we > should make another thread... Again we are down to a link-layer reality. We don't have link-layer multicast available. > For example it says: >> Another consequence [of forming address from MAC] is that the >> link-local address is presumably unique on the Extended LoWPAN, > > This is not a very safe assumption IMHO. In 6lowpan-nd we are performing DAD across the entire LoWPAN before removing the optimistic flag on an address. So it is unique after that, regardless of being short. > At least because the uniqueness assumed with IPv6 addresses formed from > short 16bit addresses is a uniqueness relative to a "PAN id" (and not to > a LoWPAN, not an Extended LoWPAN), even less globally unique. And we > don't know anything about the uniqueness of PAN-IDs, do we? > >> which enables the use of Optimistic Duplicate Address Detection (oDAD) >> [RFC4429] over the Transit Link and the LoWPAN. > > AFAIK oDAD does use the typical ND link-local multicast messages, so > does 6LoWPAN use ND link-local multicast messages or not? Over the transit link, which is the backbone link in an Extended LoWPAN. So it works exactly as in standard RFC4861. I'll fix that to say "backbone link". > (Transit Link on Edge Router overlaps its link-local scope over the > LoWPAN) > >> To simplify address resolution it is assumed that nodes within a >> LoWPAN use addresses in a homogeneous way and that the unicast IPv6 >> address IIDs resolve directly to a corresponding link-layer address. > > I just suppose it unsafe to assume an IPv6 address IIDs address resolves > directly into a MAC address, IMHO. Because: It is not unsafe, it is the basic way that 6lowpan works. > -it prohibits the use of manually assigned link-local addresses. Not true at all. Please read IEEE 802.15.4 and RFC4944 specs. e.g. IEEE 802.15.4 MAC implementations let you assign any address you want to the interface. So you can change your 64-bit or 16-bit address any time you want. > -it requires link-layers to have MAC addresses (not all have). The kinds of link layers we are dealing with in 6lowpan do have MAC addresses. > -in particular for IPv6-over-802.15.4 it is difficult to > distinguish an IID to correspond to a short (16bit) or normal MAC > address. What is the MAC address from which this IPv6 address was > formed? > fe80::21:70ff:feb8:8252 > After removing the fffe and the fe80 - is there a short 16bit MAC > address in there concatenated to the PAN ID? Or is it a locally unique > manually assigned 48bit MAC address? Or a locally-unique self-derived > non-standard USB address? That does not conform to RFC4944. Anyways, there are only two ways to derive the IID in RFC4944. You can tell them apart using the U/L flag in addition to the 16-bit zero field in-between the PAN-ID and 16-bit short address. I don't see a problem here. >> Upon a registration flow, an edge router doing DAD > > Doing DAD or DAD? DAD >> If successful, this address is returned in an Address Option of the RC >> with the 'A' flag set and the assigned IPv6 address formed from the >> generated link-layer address with the defualt prefix inline. > > This is typically a DHCPv6 function (a router forming an address for a > host and sending it for assignment on interface). One would expect the > draft to refer DHCPv6 and say why not, no? This is claim and defend addressing. It is just a random number generated on behalf of the node (and then checked with DAD)... After this point it is completely up to the node to defend this address. The Whiteboard keeps absolutely no state regarding the generation, just a standard whiteboard entry. We have talked about this many times before. The node itself could just as well perform the random 16-bit address generation and then try to register it (thus performing DAD) on a trial-and-error basis. > Alex > > -- 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 Thu May 14 04:30: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 5D0C828C226 for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 04:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 rL0CqMVEJpZP for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 04:30:42 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D23CD28C23C for <6lowpan@ietf.org>; Thu, 14 May 2009 04:30:41 -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 n4EBW2JY027624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 14:32:07 +0300 Message-ID: <4A0C0165.5040401@sensinode.com> Date: Thu, 14 May 2009 14:32:53 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> <4A0ACF35.6030004@sensinode.com> <4A0B2E50.3040006@gmail.com> <4A0B3B4D.6000704@sensinode.com> <4A0BE72F.6030507@gmail.com> <4A0BEC0D.5060609@sensinode.com> <4A0BFB07.9030803@gmail.com> In-Reply-To: <4A0BFB07.9030803@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] multicast with link-local scope 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, 14 May 2009 11:30:43 -0000 Alexandru Petrescu wrote: > Zach Shelby a écrit : > [...] >> Multicast with link-local scope, is simply a link-layer broadcast and >> is not retransmitted. > > I am not sure what you mean (in general? 802.15.4 in particular?) but > multicast with link-local scope maps into link-layer multicast, and is > not simply link-layer broadcast. Some link-layers do support link-layer > multicast and it is all an advantage to ND. In general, for the types of link-layer this WG deals with. Please see RFC4944, RFC4919, IEEE 802.15.4. Link-local scope multicast is mapped to a broadcast (0xffff)... see page 4 of RFC4944. Other wireless link-layers are similar. > For example to each IP link-local multicast address corresponds a MAC > link-layer multicast address (like 33:33::1). Moreover, IPv6 stacks > simply don't work with link-layer addresses which use MAC broadcast > addresses (48 1 bits). > Alex > > So the above does not occur. Thus this kind of >> multicast used by RAs and NSs is not a big problem. We should still >> keep the frequency of these down. >> >> If you try to do a multicast with scope > 2, then you have a flooding >> problem unless multicast is implemented in some other way. This is why >> we use the Whiteboard approach in 6lowpan-nd, to avoid the need to >> flood the LoWPAN. >> >>>> Medium access control schemes of wireless link-layers are able to >>>> deal with extra transmissions from multihop forwarding. >>> >>> I agree MAC schemes could alleviate the B transmits back to A problems. >>> And these schemes are part (supposedly?) of the Mesh-Under concept. >>> Which makes think that Route-Over wouldn't work without Mesh-Under at >>> the same time. >> >> This has nothing to do with mesh-under. Every wireless link-layer >> implements medium access control, for example CSMA in the case of IEEE >> 802.15.4. >> >>>> Of course because you are forwarding with a single interface, your >>>> channel capacity decreases with more hops (this is the multihop >>>> penalty of all such schemes, including Mesh Under). >>> >>> Ok. >>> >>>>> Otherwise nodes should have a means to know on _which_ link-local >>>>> scopes are they, and send data on only one scope. But I think >>>>> there's only one link-local address per interface, and only a >>>>> scope_id field in the respective C struct. >>>> >>>> Not needed, the link-layer deals with this using MAC addressing and >>>> the MAC algorithm. A node just tracks who are its neighbors. >>> >>> Ok. Some questions rest about how does the link layer deal with >>> link-layer multicast addresses, when they are used by RS and NS, such >>> that to avoid noise amplification on non-transitive links. >> >> You use link-local scope and it is not a problem (RS and NS are >> link-local messages). You of course want to keep the amount of ND >> signaling on a whole as low as possible - which is a goal of 6lowpan-nd. >> >>> Alex >>> >>> >> > > -- 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 alexandru.petrescu@gmail.com Thu May 14 08:19:09 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 270A328C2AE for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 08:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, 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 Gh06VDFoMv0c for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 08:19:06 -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 7B11E28C2B8 for <6lowpan@ietf.org>; Thu, 14 May 2009 08:19:06 -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 n4EFILsj023041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 May 2009 17:18:23 +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 n4EFKVe8029034; Thu, 14 May 2009 17:20:31 +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 n4EFKUwb011001; Thu, 14 May 2009 17:20:31 +0200 Message-ID: <4A0C36BE.8040302@gmail.com> Date: Thu, 14 May 2009 17:20:30 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> <4A0ACF35.6030004@sensinode.com> <4A0B2E50.3040006@gmail.com> <4A0B3B4D.6000704@sensinode.com> <4A0BE72F.6030507@gmail.com> <4A0BEC0D.5060609@sensinode.com> <4A0BFB07.9030803@gmail.com> <4A0C0165.5040401@sensinode.com> In-Reply-To: <4A0C0165.5040401@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] multicast with link-local scope 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, 14 May 2009 15:19:09 -0000 Zach, I may miss something big, but here goes my comment anyways... Zach Shelby a écrit : > Alexandru Petrescu wrote: >> Zach Shelby a écrit : >> [...] >>> Multicast with link-local scope, is simply a link-layer broadcast and >>> is not retransmitted. >> >> I am not sure what you mean (in general? 802.15.4 in particular?) but >> multicast with link-local scope maps into link-layer multicast, and is >> not simply link-layer broadcast. Some link-layers do support >> link-layer multicast and it is all an advantage to ND. > > In general, for the types of link-layer this WG deals with. Please see > RFC4944, RFC4919, IEEE 802.15.4. Link-local scope multicast is mapped to > a broadcast (0xffff)... see page 4 of RFC4944. Other wireless > link-layers are similar. Unless I miss something big I'm afraid there may be an error both in what is said above, and in rfc4944. rfc4944 doesn't seem to say a link-local scope multicast address is mapped into 0xffff, but probably into something like 0x8001. BEsides, it doesn't seem to say what IP address corresponds to the 16bit MAC broadcast address 0xffff. If the rule used for mapping ff02::1 into 0x8001 were used to map 0xffff into an IP address then that would be ff02::9f, which is different than the all-nodes link-scoped multicast address ff02::1. In short, by rfc4944: ff02::1 maps into 0x8001 0xffff maps into ff02::9f HEre's the relevant rfc4944 text: rfc4944 says "An IPv6 packet with a multicast destination address (DST), consisting of the sixteen octets DST[1] through DST[16], is transmitted to the following 802.15.4 16-bit multicast address: 100 dst[15] dst [16]" rfc4944 later says " This document creates a new IANA registry for the 16-bit short address fields as used in 6LoWPAN packets. [...] This registry MUST include the addresses 0xffff (16-bit broadcast address accepted by all devices currently listening to the channel) and 0xfffe as defined in [ieee802.15.4]." Additionally, when it talks use of link-layer broadcast to immitate link-layer multicast, it doesn't say which IP link-scoped multicast address is mapped into 0xffff. > Hence, IPv6 level multicast packets MUST be carried as link-layer > broadcast frames in IEEE 802.15.4 networks. [...] > > 2. A short destination address is included in the frame, and it MUST > match the broadcast address (0xffff). With real link-layer multicast there are several multicast addresses, like 33:33::1, 33:33::2, etc. Each corresponds to IP link-scope multicast address which is ff02::1, ff02::2, etc. For example NS is sent to 33:33::1/ff02::1 whereas RS is sent to 33:33::2/ff02::2 Now, with the above rfc4944 step 2, are both RS and NS sent to 0xffff? Or only RS? rfc4944 is silent about this, yet of paramount importance to implementer. Alex PS: there is more error in rfc4944 saying that "IPv6 level multicast packets MUST be carried as link layer broadcast frames" - because only the link-local scoped IP multicast packets should, and not the globally-scoped multicast packets. PPS: there is even more error in rfc4944 requiring every byte in the IP multicast address (bytes 1 to 16) to correspond to "100 DST[15] DST[16]" because globally multicast packets (i.e. group ff0e::1) I doubt should be multicast at link-layer, they should be unicasted to the router. From cabo@tzi.org Thu May 14 08:42:03 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 3B46928C2C7 for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 08:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 qjmhQ4FkWQfW for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 08:42:02 -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 0BB7628C283 for <6lowpan@ietf.org>; Thu, 14 May 2009 08:42:01 -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 n4EFhPsb020148; Thu, 14 May 2009 17:43:25 +0200 (CEST) Received: from wlan-client-326.informatik.uni-bremen.de (wlan-client-326.informatik.uni-bremen.de [134.102.117.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id DD6021704D6; Thu, 14 May 2009 17:43:24 +0200 (CEST) From: Carsten Bormann To: Alexandru Petrescu In-Reply-To: <4A0C36BE.8040302@gmail.com> References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> <4A0ACF35.6030004@sensinode.com> <4A0B2E50.3040006@gmail.com> <4A0B3B4D.6000704@sensinode.com> <4A0BE72F.6030507@gmail.com> <4A0BEC0D.5060609@sensinode.com> <4A0BFB07.9030803@gmail.com> <4A0C0165.5040401@sensinode.com> <4A0C36BE.8040302@gmail.com> Message-Id: <19B8A12F-B8FC-4235-A448-292CD9F148C9@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: Thu, 14 May 2009 17:43:24 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] multicast with link-local scope 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, 14 May 2009 15:42:03 -0000 > rfc4944 doesn't seem to say a link-local scope multicast address is > mapped into 0xffff, but probably into something like 0x8001. That depends. Section 9 addressing is explicitly for mesh-under only (section 9, first sentence) -- if there is an actual multicast framework under/in the adaptation layer, it was considered useful to map the L3 multicast addresses to different MAC addresses as well. If not, all multicast maps to 0xffff broadcast. > BEsides, it doesn't seem to say what IP address corresponds to the > 16bit MAC broadcast address 0xffff. If the rule used for mapping > ff02::1 into 0x8001 were used to map 0xffff into an IP address then > that would be ff02::9f, which is different than the all-nodes link- > scoped multicast address ff02::1. No, section 9 addressing only uses 16-bit addresses of the form 100xxxxx xxxxxxxx. 0xffff is 11111111 11111111, so it is not section 9 addressing. > For example NS is sent to 33:33::1/ff02::1 > whereas RS is sent to 33:33::2/ff02::2 We don't use Ethernet's 48-bit MAC addresses in 4944. (Let's try to focus the discussion on the 6lowpan list to 6lowpan, please.) > PS: there is more error in rfc4944 saying that "IPv6 level multicast > packets MUST be carried as link layer broadcast frames" - because > only the link-local scoped IP multicast packets should, and not the > globally-scoped multicast packets. This is the non-mesh-under multicast case. No error. > PPS: there is even more error in rfc4944 requiring every byte in the > IP multicast address (bytes 1 to 16) to correspond to "100 DST[15] > DST[16]" because globally multicast packets (i.e. group ff0e::1) I > doubt should be multicast at link-layer, they should be unicasted to > the router. Not with mesh-under multicast. Discussing mesh-under multicast is always a bit difficult because there is no actual system instance to discuss it relative to. One could argue that putting currently unused functionality into 4944 might have been premature, but it might also help commonality of any mesh-under multicast solutions that arise. Gruesse, Carsten From alexandru.petrescu@gmail.com Thu May 14 09:29: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 2E3D73A704C for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 09:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, 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 h2iRtdpKSkyL for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 09:29:32 -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 D5E2A3A7048 for <6lowpan@ietf.org>; Thu, 14 May 2009 09:29:31 -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 n4EGSqh9014237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 May 2009 18:28:53 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4EGV3BA008066; Thu, 14 May 2009 18:31:03 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n4EGV2UT001461; Thu, 14 May 2009 18:31:03 +0200 Message-ID: <4A0C4746.9030202@gmail.com> Date: Thu, 14 May 2009 18:31:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Carsten Bormann References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> <4A0ACF35.6030004@sensinode.com> <4A0B2E50.3040006@gmail.com> <4A0B3B4D.6000704@sensinode.com> <4A0BE72F.6030507@gmail.com> <4A0BEC0D.5060609@sensinode.com> <4A0BFB07.9030803@gmail.com> <4A0C0165.5040401@sensinode.com> <4A0C36BE.8040302@gmail.com> <19B8A12F-B8FC-4235-A448-292CD9F148C9@tzi.org> In-Reply-To: <19B8A12F-B8FC-4235-A448-292CD9F148C9@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] multicast with link-local scope 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, 14 May 2009 16:29:33 -0000 Thanks for enlightening about this. Carsten Bormann a écrit : >> rfc4944 doesn't seem to say a link-local scope multicast address is >> mapped into 0xffff, but probably into something like 0x8001. > > That depends. Section 9 addressing is explicitly for mesh-under only > (section 9, first sentence) -- if there is an actual multicast > framework under/in the adaptation layer, it was considered useful to > map the L3 multicast addresses to different MAC addresses as well. If > not, all multicast maps to 0xffff broadcast. Let me see I understand correctly. If mesh-under and multicast adaptation layer then: ff02::1 maps into 0x8001 ff02::2 maps into 0x8002 Else: ffXX:X:X:X:X:X:X:X map into 0xffff Right? If yes I disagree with mapping all IP multicast addresses into 0xffff MAC broadcast, because ff0e::1 global-scoped IP address shouldn't be sent to link-layer broadcast - it may be considered noise. >> For example NS is sent to 33:33::1/ff02::1 whereas RS is sent to >> 33:33::2/ff02::2 > > We don't use Ethernet's 48-bit MAC addresses in 4944. (Let's try to > focus the discussion on the 6lowpan list to 6lowpan, please.) How about suggesting IEEE 802.15.4 to use Ethernet's MAC multicast features? Is there already an IEEE activity doing this? >> PS: there is more error in rfc4944 saying that "IPv6 level >> multicast packets MUST be carried as link layer broadcast frames" - >> because only the link-local scoped IP multicast packets should, and >> not the globally-scoped multicast packets. > > This is the non-mesh-under multicast case. No error. There is an error in sending a global-scoped IP multicast packet to a link broadcast address - one's neighbors may have not subscribed to that global group yet they receive the packet. I disagree doing so. [...] > Discussing mesh-under multicast is always a bit difficult because > there is no actual system instance to discuss it relative to. I agree! > One could argue that putting currently unused functionality into 4944 > might have been premature, but it might also help commonality of any > mesh-under multicast solutions that arise. It could have also been formulated as a requirement document, instead of a hardly implementable mapping method. Something like: if you need IPv6 to work on this adaptation layer then the adaptation layer should be link-layer multicast capable - please design the multicast-capable adaptation layer and tell me the multicast addresses you're using so that I can map the IP multicast addresses onto them... I guess this could have solved many problems about non-transitive single-interface multiple-linkscope routers too. Alex From cabo@tzi.org Thu May 14 09:59: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 3C3F428C2DB for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 09:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 JCfofoOPjO9j for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 09:59:35 -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 0C1E73A6C78 for <6lowpan@ietf.org>; Thu, 14 May 2009 09:59:34 -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 n4EH0rVQ018696; Thu, 14 May 2009 19:00:53 +0200 (CEST) Received: from wlan-client-326.informatik.uni-bremen.de (wlan-client-326.informatik.uni-bremen.de [134.102.117.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 277871704D6; Thu, 14 May 2009 19:00:53 +0200 (CEST) From: Carsten Bormann To: Alexandru Petrescu In-Reply-To: <4A0C4746.9030202@gmail.com> References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> <4A0ACF35.6030004@sensinode.com> <4A0B2E50.3040006@gmail.com> <4A0B3B4D.6000704@sensinode.com> <4A0BE72F.6030507@gmail.com> <4A0BEC0D.5060609@sensinode.com> <4A0BFB07.9030803@gmail.com> <4A0C0165.5040401@sensinode.com> <4A0C36BE.8040302@gmail.com> <19B8A12F-B8FC-4235-A448-292CD9F148C9@tzi.org> <4A0C4746.9030202@gmail.com> Message-Id: <3BA69C8C-73DF-447A-B47E-F40A9B525CF4@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: Thu, 14 May 2009 19:00:52 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] multicast with link-local scope 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, 14 May 2009 16:59:36 -0000 > Let me see I understand correctly. > > If mesh-under and multicast adaptation layer then: > > ff02::1 maps into 0x8001 > ff02::2 maps into 0x8002 Correct. > Else: > > ffXX:X:X:X:X:X:X:X map into 0xffff Correct (for valid values of X). > If yes I disagree with mapping all IP multicast addresses into 0xffff > MAC broadcast, because ff0e::1 global-scoped IP address shouldn't be > sent to link-layer broadcast That's what 4944 says, though (and it would even work quite well for a route-over solution with e.g. SMF). > - it may be considered noise. I don't understand that sentence. Noise is an L1 concept. > How about suggesting IEEE 802.15.4 to use Ethernet's MAC multicast > features? Is there already an IEEE activity doing this? I don't think we want to suggest IEEE to make the MAC layer *more* complicated. >>> PS: there is more error in rfc4944 saying that "IPv6 level >>> multicast packets MUST be carried as link layer broadcast frames" - >>> because only the link-local scoped IP multicast packets should, and >>> not the globally-scoped multicast packets. >> This is the non-mesh-under multicast case. No error. > > There is an error in sending a global-scoped IP multicast packet to a > link broadcast address - one's neighbors may have not subscribed to > that > global group yet they receive the packet. In many adaptation layers, including Ethernet, multiple IP multicast addresses are mapped to one L2 multicast address. Mapping all IP multicast addresses to one L2 broadcast address is just slightly more extreme. In any case, you have to filter at L3 as well. (Yes, that's really ugly with fragmentation, but sending fragmented multicasts is not very useful on a wireless network in any case.) > It could have also been formulated as a requirement document, > instead of > a hardly implementable mapping method. > > Something like: if you need IPv6 to work on this adaptation layer then > the adaptation layer should be link-layer multicast capable - please > design the multicast-capable adaptation layer and tell me the > multicast > addresses you're using so that I can map the IP multicast addresses > onto > them... > > I guess this could have solved many problems about non-transitive > single-interface multiple-linkscope routers too. You lost me completely here, but since we are not redesigning 4944 just yet, I don't think we need to discuss this further right now. Gruesse, Carsten From alexandru.petrescu@gmail.com Thu May 14 12:58:10 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 5F48B3A6893 for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 12:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, 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 8eF3F9Dc8Qve for <6lowpan@core3.amsl.com>; Thu, 14 May 2009 12:58:09 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 40E9C3A679C for <6lowpan@ietf.org>; Thu, 14 May 2009 12:58:07 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 508AED481E6; Thu, 14 May 2009 21:59:36 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 2DB69D4808E; Thu, 14 May 2009 21:59:34 +0200 (CEST) Message-ID: <4A0C781B.9050709@gmail.com> Date: Thu, 14 May 2009 21:59:23 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Carsten Bormann References: <4A09435E.4090109@sensinode.com> <4A0AA3B3.9010301@gmail.com> <4A0ACF35.6030004@sensinode.com> <4A0B2E50.3040006@gmail.com> <4A0B3B4D.6000704@sensinode.com> <4A0BE72F.6030507@gmail.com> <4A0BEC0D.5060609@sensinode.com> <4A0BFB07.9030803@gmail.com> <4A0C0165.5040401@sensinode.com> <4A0C36BE.8040302@gmail.com> <19B8A12F-B8FC-4235-A448-292CD9F148C9@tzi.org> <4A0C4746.9030202@gmail.com> <3BA69C8C-73DF-447A-B47E-F40A9B525CF4@tzi.org> In-Reply-To: <3BA69C8C-73DF-447A-B47E-F40A9B525CF4@tzi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090513-0, 13/05/2009), Outbound message X-Antivirus-Status: Clean Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] multicast with link-local scope 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, 14 May 2009 19:58:10 -0000 Carsten Bormann a écrit : >> Let me see I understand correctly. >> >> If mesh-under and multicast adaptation layer then: >> >> ff02::1 maps into 0x8001 ff02::2 maps into 0x8002 > > Correct. > >> Else: >> >> ffXX:X:X:X:X:X:X:X map into 0xffff > > Correct (for valid values of X). Ok, I agree on this interpretation, thanks for clarification. >> If yes I disagree with mapping all IP multicast addresses into >> 0xffff MAC broadcast, because ff0e::1 global-scoped IP address >> shouldn't be sent to link-layer broadcast > > That's what 4944 says, though (and it would even work quite well for > a route-over solution with e.g. SMF). > >> - it may be considered noise. > > I don't understand that sentence. Noise is an L1 concept. Ok, noise is an L1 concept. At L3 what I've seen reported in the past is "ARP storm" over non-multicast capable Ethernet links (with broadcast address 0xffffffff) which disappeared when multicast-capable addresses (33:33:x:x:x:x) started to appear, together with the MUST join a group before receiving data from it, and used extensively by ND. ND using 0xffff addresses, and nodes free from the requirement to join groups, looks as a return to the past and its inefficiencies, maybe risk of "LoWPAN ND storm". >> How about suggesting IEEE 802.15.4 to use Ethernet's MAC multicast >> features? Is there already an IEEE activity doing this? > > I don't think we want to suggest IEEE to make the MAC layer *more* > complicated. How about suggesting 802.15 subgroups to re-use the 802.3 MAC layer, as 802.16 did. That should be more complete than the adaptation layer. >>>> PS: there is more error in rfc4944 saying that "IPv6 level >>>> multicast packets MUST be carried as link layer broadcast >>>> frames" - because only the link-local scoped IP multicast >>>> packets should, and not the globally-scoped multicast packets. >>> This is the non-mesh-under multicast case. No error. >> >> There is an error in sending a global-scoped IP multicast packet to >> a link broadcast address - one's neighbors may have not subscribed >> to that global group yet they receive the packet. > > In many adaptation layers, including Ethernet, multiple IP multicast > addresses are mapped to one L2 multicast address. Ok, true... > Mapping all IP multicast addresses to one L2 broadcast address is > just slightly more extreme. In any case, you have to filter at L3 as > well. (Yes, that's really ugly with fragmentation, but sending > fragmented multicasts is not very useful on a wireless network in any > case.) > >> It could have also been formulated as a requirement document, >> instead of a hardly implementable mapping method. >> >> Something like: if you need IPv6 to work on this adaptation layer >> then the adaptation layer should be link-layer multicast capable - >> please design the multicast-capable adaptation layer and tell me >> the multicast addresses you're using so that I can map the IP >> multicast addresses onto them... >> >> I guess this could have solved many problems about non-transitive >> single-interface multiple-linkscope routers too. > > You lost me completely here, but since we are not redesigning 4944 > just yet, I don't think we need to discuss this further right now. WEll no, we aren't redesigning 4944. We could provide comments on it though, it's an RFC, and it's used as basis for LoWPAN ND which is further used by ROLL. If RFC 4944 had a multicast-capable adaptation layer, or required 802.15.4 to offer such, then probably the ER wouldn't be required to do the otherwise unnecessary proxying. In LoWPAN ND the ER proxies ND on its egress interface, on behalf of each LoWPAN nodes, i.e. sending an MLD Report for each node. Hundreds of thousands of such reports - why? It would be simpler if ER separated the links and had two multicast-capable links. --------------- |Upstream Router| --------------- | |Egress --- |ER | --- | 0 0 0 0 0 (nodes) > Edge routers are introduced to scale the Neighbor Discovery > Operations by reducing the amount of costly multicast ND messages > over a LoWPAN subnet that may cover hundreds or thousands of nodes. At the cost of what? Moving the problem from LoWPAN to ER's Egress interface - why? Alex From alexandru.petrescu@gmail.com Fri May 15 08:54:40 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 CCE713A70D3 for <6lowpan@core3.amsl.com>; Fri, 15 May 2009 08:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, 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 ASclZLZj5DOV for <6lowpan@core3.amsl.com>; Fri, 15 May 2009 08:54:40 -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 D34153A6889 for <6lowpan@ietf.org>; Fri, 15 May 2009 08:54:39 -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 n4FFs1da017598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <6lowpan@ietf.org>; Fri, 15 May 2009 17:54:01 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4FFuBMT001813 for <6lowpan@ietf.org>; Fri, 15 May 2009 17:56:11 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n4FFuAYP003358 for <6lowpan@ietf.org>; Fri, 15 May 2009 17:56:11 +0200 Message-ID: <4A0D909A.3030106@gmail.com> Date: Fri, 15 May 2009 17:56:10 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] Mesh-under does offer multicast link-layer 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, 15 May 2009 15:54:40 -0000 I need to correct my stance here, now knowing IEEE 802.15.5 mesh-under does offer multicast link-layer. I think when mesh-under is available, multicast link-layer is also available, and when so the LoWPAN ND should take advantage of it: do the typical link-scoped multicast operations: join, leave. I think the '100' described by 4944 "Multicast Address Mapping" should be known and reserved by IEEE, if it's not already, such that other than IP protocols don't make group addresses which start with '100'. And I also suggest to have specific text in LoWPAN ND draft which says that if mesh-under is available then group ff02::1 maps into 0x8001 and ff02::2 into 0x8002, and LoWPAN ND should use the link-layer multicast features if mesh-under is available. Example specific statement is "LoWPAN node SHOULD or MUST join the group ff02::1, if mesh-under is available". This expands the current LoWPAN ND text which says "A LoWPAN Node does not need to join the solicited-node multicast address for its own addresses and SHOULD NOT have to answer a multicast Neighbor Solicitation." What do you think? Alex From cabo@tzi.org Fri May 15 11:23: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 19D8D28C19F for <6lowpan@core3.amsl.com>; Fri, 15 May 2009 11:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 HJ0Fu8dTfM5E for <6lowpan@core3.amsl.com>; Fri, 15 May 2009 11:23:57 -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 088E528C182 for <6lowpan@ietf.org>; Fri, 15 May 2009 11:23:56 -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 n4FIPMdh013389 for <6lowpan@ietf.org>; Fri, 15 May 2009 20:25:22 +0200 (CEST) Received: from [192.168.217.107] (p5489E321.dip.t-dialin.net [84.137.227.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 11D301704D6; Fri, 15 May 2009 20:25:22 +0200 (CEST) Message-Id: <4CAA4C55-FBA8-4976-BC8C-E89AB80A40FC@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@ietf.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: Fri, 15 May 2009 20:25:20 +0200 X-Mailer: Apple Mail (2.935.3) Subject: [6lowpan] Minutes from IETF 74 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, 15 May 2009 18:23:58 -0000 The draft minutes for IETF 74 are at http://www.ietf.org/proceedings/09mar/minutes/6lowpan.txt Please tell me (or the list) about any corrections required. I apologize for the delay and the length (I didn't have time to make them shorter). Gruesse, Carsten From zach@sensinode.com Mon May 18 05:14:17 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 C168928C2B8 for <6lowpan@core3.amsl.com>; Mon, 18 May 2009 05:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 U+auhQvTl3XN for <6lowpan@core3.amsl.com>; Mon, 18 May 2009 05:14:16 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4133628C2A3 for <6lowpan@ietf.org>; Mon, 18 May 2009 05:14:15 -0700 (PDT) Received: from snl-zach.local (82-128-196-163-Torikatu-TR1.suomi.net [82.128.196.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n4ICFjcI023857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 May 2009 15:15:45 +0300 Message-ID: <4A115173.2080700@sensinode.com> Date: Mon, 18 May 2009 15:15:47 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A0D909A.3030106@gmail.com> In-Reply-To: <4A0D909A.3030106@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Mesh-under does offer multicast link-layer 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, 18 May 2009 12:14:17 -0000 Hi, Alexandru Petrescu wrote: > I need to correct my stance here, now knowing IEEE 802.15.5 mesh-under > does offer multicast link-layer. IEEE 802.15.4-2006 does not support multicast. RFC4944 Section 9 only has a theoretical mapping of multicast addresses to 16-bit short addresses. It assumes that some future LoWPAN mesh-under routing algorithm would have some way of realizing those multicast mechanisms. Multicast would likely still be mapped to IEEE 802.15.4 broadcast, and even worse, over multihops that is flooding. In fact, because each link-local scope multicast could be a multihop flood, it might even be much worse without IP knowing it. Section 9 was done a bit prematurely, as in the end there are no LoWPAN mesh algorithms being specified, the concentration is on IP routing and ROLL. > I think when mesh-under is available, multicast link-layer is also > available, and when so the LoWPAN ND should take advantage of it: do the > typical link-scoped multicast operations: join, leave. I don't have a problem with a limited amount of link-scope multicast use if it is a simple broadcast (not a flood), if it actually reaches the nodes intended, and the frequency is low. For example link-local scoped multicast is used in ND for 6LoWPAN by RS/RA messages. The frequency is optimized using the Trickle algorithm. > I think the '100' described by 4944 "Multicast Address Mapping" should > be known and reserved by IEEE, if it's not already, such that other than > IP protocols don't make group addresses which start with '100'. This has nothing to do with IEEE 802.15.4 right now. If IEEE 802.15.4 would support multicast some day, we should of course encourage them to consider RFC4944 Section 9 format. > And I also suggest to have specific text in LoWPAN ND draft which says > that if mesh-under is available then group ff02::1 maps into 0x8001 and > ff02::2 into 0x8002, and LoWPAN ND should use the link-layer multicast > features if mesh-under is available. Section 9 of RFC4944 refers only to a LoWPAN mesh-under solution (which doesn't exist today). Other link-layers which may support mesh-under might have a completely different mapping. It would be confusing to specify a mapping which is not useful. Better to leave the mapping up to the link-layer. > Example specific statement is "LoWPAN node SHOULD or MUST join the group > ff02::1, if mesh-under is available". This expands the current LoWPAN > ND text which says "A LoWPAN Node does not need to join the > solicited-node multicast address for its own addresses and SHOULD NOT > have to answer a multicast Neighbor Solicitation." Avoiding the need for nodes to answer multicast messages has more to do with the fact that much of the time nodes are sleeping, and furthermore the link-layer scope does not cover all the nodes useful for performing ND operations (the whole subnet). Mesh-under has exactly the same sleeping node problem as route-over. Furthermore in a mesh-under configuration, even though it seems link-local scope covers the entire LoWPAN, doing an all-nodes multicast on the link-layer will likely be a flood. So link-layer abstraction here doesn't make things any more efficient. It just hides the ugly stuff. Now that said, the ROLL working group does have a requirement to support a more efficient way to support some > link-local scope multicast operations. I don't see that helping us with ND for 6LoWPAN operations. Furthermore we can't depend on a specific routing algorithm. - Zach > What do you think? > Alex > > > _______________________________________________ > 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. From alexandru.petrescu@gmail.com Tue May 19 03:48: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 6598D3A70B3 for <6lowpan@core3.amsl.com>; Tue, 19 May 2009 03:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, 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 ig6Qr3ZMMs1w for <6lowpan@core3.amsl.com>; Tue, 19 May 2009 03:48:52 -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 29D033A682D for <6lowpan@ietf.org>; Tue, 19 May 2009 03:48: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 n4JAmFfW026237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 May 2009 12:48:15 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4JAoQF5005561; Tue, 19 May 2009 12:50:27 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n4JAoQom009946; Tue, 19 May 2009 12:50:26 +0200 Message-ID: <4A128EF2.8040703@gmail.com> Date: Tue, 19 May 2009 12:50:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <4A0D909A.3030106@gmail.com> <4A115173.2080700@sensinode.com> In-Reply-To: <4A115173.2080700@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] disagreement on link-layer multicast 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, 19 May 2009 10:48:53 -0000 Zach, I humbly take advantage of this to express disagreement, and my support of the following: -LoWPAN node SHOULD join the relevant multicast groups when the underlying link is multicast-capable (contrary to what draft-ietf-6lowpan-nd suggests) - risk of inefficient link use. -IP LoWPAN node shouldn't use the 0xffff link broadcast addresses - risk of 'storms'. -adaptation layer shouldn't precede the IP header, nor should it eliminate it (as rfc4944 does) - otherwise there's no more IP. -IP layer shouldn't do tasks reserved to the link-layer - risk of 'layer violation'. I dare to qualify these as bviously debatable points (although apparently only I maintain them), and I do think they deserve much larger discussion. I do share the point of view of the need to connect these devices to the Internet. Yours, Alex Zach Shelby a écrit : > Hi, > > Alexandru Petrescu wrote: >> I need to correct my stance here, now knowing IEEE 802.15.5 >> mesh-under does offer multicast link-layer. > > IEEE 802.15.4-2006 does not support multicast. > > RFC4944 Section 9 only has a theoretical mapping of multicast > addresses to 16-bit short addresses. It assumes that some future > LoWPAN mesh-under routing algorithm would have some way of realizing > those multicast mechanisms. Multicast would likely still be mapped to > IEEE 802.15.4 broadcast, and even worse, over multihops that is > flooding. In fact, because each link-local scope multicast could be a > multihop flood, it might even be much worse without IP knowing it. > Section 9 was done a bit prematurely, as in the end there are no > LoWPAN mesh algorithms being specified, the concentration is on IP > routing and ROLL. > >> I think when mesh-under is available, multicast link-layer is also >> available, and when so the LoWPAN ND should take advantage of it: >> do the typical link-scoped multicast operations: join, leave. > > I don't have a problem with a limited amount of link-scope multicast > use if it is a simple broadcast (not a flood), if it actually reaches > the nodes intended, and the frequency is low. For example link-local > scoped multicast is used in ND for 6LoWPAN by RS/RA messages. The > frequency is optimized using the Trickle algorithm. > >> I think the '100' described by 4944 "Multicast Address Mapping" >> should be known and reserved by IEEE, if it's not already, such >> that other than IP protocols don't make group addresses which start >> with '100'. > > This has nothing to do with IEEE 802.15.4 right now. If IEEE 802.15.4 > would support multicast some day, we should of course encourage them > to consider RFC4944 Section 9 format. > >> And I also suggest to have specific text in LoWPAN ND draft which >> says that if mesh-under is available then group ff02::1 maps into >> 0x8001 and ff02::2 into 0x8002, and LoWPAN ND should use the >> link-layer multicast features if mesh-under is available. > > Section 9 of RFC4944 refers only to a LoWPAN mesh-under solution > (which doesn't exist today). Other link-layers which may support > mesh-under might have a completely different mapping. It would be > confusing to specify a mapping which is not useful. For other link layers with other mappings, specify other IPv6-over-that-link documents. > Better to leave the mapping up to the link-layer. IPv6 over Ethernet takes a specific mapping, it doesn't leave it to Ethernet. >> Example specific statement is "LoWPAN node SHOULD or MUST join the >> group ff02::1, if mesh-under is available". This expands the >> current LoWPAN ND text which says "A LoWPAN Node does not need to >> join the solicited-node multicast address for its own addresses and >> SHOULD NOT have to answer a multicast Neighbor Solicitation." > > Avoiding the need for nodes to answer multicast messages has more to > do with the fact that much of the time nodes are sleeping, and > furthermore the link-layer scope does not cover all the nodes useful > for performing ND operations (the whole subnet). Mesh-under has > exactly the same sleeping node problem as route-over. > > Furthermore in a mesh-under configuration, even though it seems > link-local scope covers the entire LoWPAN, doing an all-nodes > multicast on the link-layer will likely be a flood. So link-layer > abstraction here doesn't make things any more efficient. It just > hides the ugly stuff. > > Now that said, the ROLL working group does have a requirement to > support a more efficient way to support some > link-local scope > multicast operations. I don't see that helping us with ND for 6LoWPAN > operations. Furthermore we can't depend on a specific routing > algorithm. > > - Zach > >> What do you think? > > >> Alex >> >> >> _______________________________________________ 6lowpan mailing >> list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan >> >> > From zach@sensinode.com Tue May 19 04:10:11 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 62C823A6DDD for <6lowpan@core3.amsl.com>; Tue, 19 May 2009 04:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 kjOfUsIj7XqW for <6lowpan@core3.amsl.com>; Tue, 19 May 2009 04:10:09 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 30F393A6DCC for <6lowpan@ietf.org>; Tue, 19 May 2009 04:10:08 -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 n4JBBdXQ010950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 May 2009 14:11:40 +0300 Message-ID: <4A1293F3.2000402@sensinode.com> Date: Tue, 19 May 2009 14:11:47 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A0D909A.3030106@gmail.com> <4A115173.2080700@sensinode.com> <4A128EF2.8040703@gmail.com> In-Reply-To: <4A128EF2.8040703@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] disagreement on link-layer multicast 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, 19 May 2009 11:10:11 -0000 Hi, Alexandru Petrescu wrote: > Zach, > > I humbly take advantage of this to express disagreement, and my support > of the following: > -LoWPAN node SHOULD join the relevant multicast groups when the > underlying link is multicast-capable (contrary to what > draft-ietf-6lowpan-nd suggests) - risk of inefficient link use. Sure, we can say that (I will take an AP). We will still reduce the frequency and use of multicast wherever possible however in 6lowpan-nd. > -IP LoWPAN node shouldn't use the 0xffff link broadcast addresses - risk > of 'storms'. The IP LoWPAN node makes no such decision at L3... It sends a packet to FF02::1 or FF02::2 for example, the mapping is done by the link-layer adaptation. Most link-layers will use some kind of broadcast (like IEEE 802.15.4) to send such a packet. I agree, we must minimize the use of multicast so that broadcast storms as you call them don't occur. Even if you use a link-layer adaptation that emulated multicast - you are still broadcasting on wireless links, even flooding. So this all boils down to minimizing the use of multicast. > -adaptation layer shouldn't precede the IP header, nor should it > eliminate it (as rfc4944 does) - otherwise there's no more IP. No comment. > -IP layer shouldn't do tasks reserved to the link-layer - risk of 'layer > violation'. Nor is it in this working group. The IP layer also has to live with *existing link layers*, and actually function efficiently with them. Just because you would like a link-layer to function in some way - it doesn't mean it will. This is not a theoretical exercise - we are working with real radios here. > I dare to qualify these as bviously debatable points (although > apparently only I maintain them), and I do think they deserve much > larger discussion. > I do share the point of view of the need to connect these devices to the > Internet. > > Yours, > > Alex > > Zach Shelby a écrit : >> Hi, >> >> Alexandru Petrescu wrote: >>> I need to correct my stance here, now knowing IEEE 802.15.5 >>> mesh-under does offer multicast link-layer. >> >> IEEE 802.15.4-2006 does not support multicast. >> >> RFC4944 Section 9 only has a theoretical mapping of multicast >> addresses to 16-bit short addresses. It assumes that some future >> LoWPAN mesh-under routing algorithm would have some way of realizing >> those multicast mechanisms. Multicast would likely still be mapped to >> IEEE 802.15.4 broadcast, and even worse, over multihops that is >> flooding. In fact, because each link-local scope multicast could be a >> multihop flood, it might even be much worse without IP knowing it. >> Section 9 was done a bit prematurely, as in the end there are no >> LoWPAN mesh algorithms being specified, the concentration is on IP >> routing and ROLL. >> >>> I think when mesh-under is available, multicast link-layer is also >>> available, and when so the LoWPAN ND should take advantage of it: do >>> the typical link-scoped multicast operations: join, leave. >> >> I don't have a problem with a limited amount of link-scope multicast >> use if it is a simple broadcast (not a flood), if it actually reaches >> the nodes intended, and the frequency is low. For example link-local >> scoped multicast is used in ND for 6LoWPAN by RS/RA messages. The >> frequency is optimized using the Trickle algorithm. >> >>> I think the '100' described by 4944 "Multicast Address Mapping" >>> should be known and reserved by IEEE, if it's not already, such that >>> other than IP protocols don't make group addresses which start >>> with '100'. >> >> This has nothing to do with IEEE 802.15.4 right now. If IEEE 802.15.4 >> would support multicast some day, we should of course encourage them >> to consider RFC4944 Section 9 format. >> >>> And I also suggest to have specific text in LoWPAN ND draft which >>> says that if mesh-under is available then group ff02::1 maps into >>> 0x8001 and ff02::2 into 0x8002, and LoWPAN ND should use the >>> link-layer multicast features if mesh-under is available. >> >> Section 9 of RFC4944 refers only to a LoWPAN mesh-under solution >> (which doesn't exist today). Other link-layers which may support >> mesh-under might have a completely different mapping. It would be >> confusing to specify a mapping which is not useful. > > For other link layers with other mappings, specify other > IPv6-over-that-link documents. > >> Better to leave the mapping up to the link-layer. > > IPv6 over Ethernet takes a specific mapping, it doesn't leave it to > Ethernet. > >>> Example specific statement is "LoWPAN node SHOULD or MUST join the >>> group ff02::1, if mesh-under is available". This expands the current >>> LoWPAN ND text which says "A LoWPAN Node does not need to join the >>> solicited-node multicast address for its own addresses and >>> SHOULD NOT have to answer a multicast Neighbor Solicitation." >> >> Avoiding the need for nodes to answer multicast messages has more to >> do with the fact that much of the time nodes are sleeping, and >> furthermore the link-layer scope does not cover all the nodes useful >> for performing ND operations (the whole subnet). Mesh-under has >> exactly the same sleeping node problem as route-over. >> >> Furthermore in a mesh-under configuration, even though it seems >> link-local scope covers the entire LoWPAN, doing an all-nodes >> multicast on the link-layer will likely be a flood. So link-layer >> abstraction here doesn't make things any more efficient. It just hides >> the ugly stuff. >> >> Now that said, the ROLL working group does have a requirement to >> support a more efficient way to support some > link-local scope >> multicast operations. I don't see that helping us with ND for 6LoWPAN >> operations. Furthermore we can't depend on a specific routing algorithm. >> >> - Zach >> >>> What do you think? >> >> >>> Alex >>> >>> >>> _______________________________________________ 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. From Cam.Williams@tac.com Tue May 19 07:35:03 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 980C128C0F6 for <6lowpan@core3.amsl.com>; Tue, 19 May 2009 07:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 v-YFyFiahy9Q for <6lowpan@core3.amsl.com>; Tue, 19 May 2009 07:35:02 -0700 (PDT) Received: from mail51.messagelabs.com (mail51.messagelabs.com [216.82.241.99]) by core3.amsl.com (Postfix) with SMTP id D754128C0F9 for <6lowpan@ietf.org>; Tue, 19 May 2009 07:35:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Cam.Williams@tac.com X-Msg-Ref: server-6.tower-51.messagelabs.com!1242743775!21929753!3 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [208.69.45.7] Received: (qmail 3667 invoked from network); 19 May 2009 14:36:37 -0000 Received: from unknown (HELO servus-exch2.main.root.tac.com) (208.69.45.7) by server-6.tower-51.messagelabs.com with SMTP; 19 May 2009 14:36:37 -0000 Received: from Servus-exch3.main.root.tac.com ([10.159.8.232]) by servus-exch2.main.root.tac.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 May 2009 09:27:36 -0500 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, 19 May 2009 10:27:34 -0400 Message-ID: In-Reply-To: <4A1293F3.2000402@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] disagreement on link-layer multicast Thread-Index: AcnYcqHFqH6qQfm5Tkibbq7MFujvdQAGRHqg References: <4A0D909A.3030106@gmail.com> <4A115173.2080700@sensinode.com><4A128EF2.8040703@gmail.com> <4A1293F3.2000402@sensinode.com> From: To: , X-OriginalArrivalTime: 19 May 2009 14:27:36.0435 (UTC) FILETIME=[F4B65C30:01C9D88D] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] disagreement on link-layer multicast 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, 19 May 2009 14:35:03 -0000 =20 Hello Zach, You wrote: I agree, we must minimize the use of multicast so that broadcast storms = as you call them don't occur. Even if you use a link-layer adaptation = that emulated multicast - you are still broadcasting on wireless links, = even flooding. So this all boils down to minimizing the use of = multicast. Comment: Multicast can be done without flooding the network, if the nodes that = are members of the multicast group are clumped, not evenly distributed = throughout the network. A non-member node decrements a radius count and = forwards the multicast. A member node reloads (or computes) the radius = count and forwards the multicast. Forwarding is a one-hop broadcast. = Once the radius count is 0, forwarding stops. I'm sure that there are = even better ways than this simple mechanism. Cheers, Cam --- Cam Williams Schneider-Electric TAC R&D 978 975 9533 office 978 500 8807 cell -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Zach Shelby Sent: Tuesday, May 19, 2009 7:12 AM To: Alexandru Petrescu Cc: 6lowpan Subject: Re: [6lowpan] disagreement on link-layer multicast Hi, Alexandru Petrescu wrote: > Zach, >=20 > I humbly take advantage of this to express disagreement, and my=20 > support of the following: > -LoWPAN node SHOULD join the relevant multicast groups when the =20 > underlying link is multicast-capable (contrary to what =20 > draft-ietf-6lowpan-nd suggests) - risk of inefficient link use. Sure, we can say that (I will take an AP). We will still reduce the = frequency and use of multicast wherever possible however in 6lowpan-nd. > -IP LoWPAN node shouldn't use the 0xffff link broadcast addresses -=20 > risk of 'storms'. The IP LoWPAN node makes no such decision at L3... It sends a packet to FF02::1 or FF02::2 for example, the mapping is done by the link-layer = adaptation. Most link-layers will use some kind of broadcast (like IEEE 802.15.4) to send such a packet. I agree, we must minimize the use of multicast so that broadcast storms = as you call them don't occur. Even if you use a link-layer adaptation = that emulated multicast - you are still broadcasting on wireless links, = even flooding. So this all boils down to minimizing the use of = multicast. > -adaptation layer shouldn't precede the IP header, nor should it =20 > eliminate it (as rfc4944 does) - otherwise there's no more IP. No comment. > -IP layer shouldn't do tasks reserved to the link-layer - risk of=20 > 'layer violation'. Nor is it in this working group. The IP layer also has to live with = *existing link layers*, and actually function efficiently with them.=20 Just because you would like a link-layer to function in some way - it = doesn't mean it will. This is not a theoretical exercise - we are = working with real radios here. > I dare to qualify these as bviously debatable points (although=20 > apparently only I maintain them), and I do think they deserve much=20 > larger discussion. > I do share the point of view of the need to connect these devices to=20 > the Internet. >=20 > Yours, >=20 > Alex >=20 > Zach Shelby a =E9crit : >> Hi, >> >> Alexandru Petrescu wrote: >>> I need to correct my stance here, now knowing IEEE 802.15.5=20 >>> mesh-under does offer multicast link-layer. >> >> IEEE 802.15.4-2006 does not support multicast. >> >> RFC4944 Section 9 only has a theoretical mapping of multicast=20 >> addresses to 16-bit short addresses. It assumes that some future=20 >> LoWPAN mesh-under routing algorithm would have some way of realizing=20 >> those multicast mechanisms. Multicast would likely still be mapped to = =20 >> IEEE 802.15.4 broadcast, and even worse, over multihops that is=20 >> flooding. In fact, because each link-local scope multicast could be a = =20 >> multihop flood, it might even be much worse without IP knowing it. >> Section 9 was done a bit prematurely, as in the end there are no=20 >> LoWPAN mesh algorithms being specified, the concentration is on IP=20 >> routing and ROLL. >> >>> I think when mesh-under is available, multicast link-layer is also =20 >>> available, and when so the LoWPAN ND should take advantage of it: do = >>> the typical link-scoped multicast operations: join, leave. >> >> I don't have a problem with a limited amount of link-scope multicast=20 >> use if it is a simple broadcast (not a flood), if it actually reaches = =20 >> the nodes intended, and the frequency is low. For example link-local = >> scoped multicast is used in ND for 6LoWPAN by RS/RA messages. The=20 >> frequency is optimized using the Trickle algorithm. >> >>> I think the '100' described by 4944 "Multicast Address Mapping"=20 >>> should be known and reserved by IEEE, if it's not already, such that = >>> other than IP protocols don't make group addresses which start with = >>> '100'. >> >> This has nothing to do with IEEE 802.15.4 right now. If IEEE 802.15.4 = =20 >> would support multicast some day, we should of course encourage them = >> to consider RFC4944 Section 9 format. >> >>> And I also suggest to have specific text in LoWPAN ND draft which=20 >>> says that if mesh-under is available then group ff02::1 maps into >>> 0x8001 and ff02::2 into 0x8002, and LoWPAN ND should use the=20 >>> link-layer multicast features if mesh-under is available. >> >> Section 9 of RFC4944 refers only to a LoWPAN mesh-under solution=20 >> (which doesn't exist today). Other link-layers which may support=20 >> mesh-under might have a completely different mapping. It would be=20 >> confusing to specify a mapping which is not useful. >=20 > For other link layers with other mappings, specify other=20 > IPv6-over-that-link documents. >=20 >> Better to leave the mapping up to the link-layer. >=20 > IPv6 over Ethernet takes a specific mapping, it doesn't leave it to=20 > Ethernet. >=20 >>> Example specific statement is "LoWPAN node SHOULD or MUST join the=20 >>> group ff02::1, if mesh-under is available". This expands the=20 >>> current LoWPAN ND text which says "A LoWPAN Node does not need to=20 >>> join the solicited-node multicast address for its own addresses and = >>> SHOULD NOT have to answer a multicast Neighbor Solicitation." >> >> Avoiding the need for nodes to answer multicast messages has more to=20 >> do with the fact that much of the time nodes are sleeping, and=20 >> furthermore the link-layer scope does not cover all the nodes useful=20 >> for performing ND operations (the whole subnet). Mesh-under has=20 >> exactly the same sleeping node problem as route-over. >> >> Furthermore in a mesh-under configuration, even though it seems=20 >> link-local scope covers the entire LoWPAN, doing an all-nodes=20 >> multicast on the link-layer will likely be a flood. So link-layer=20 >> abstraction here doesn't make things any more efficient. It just=20 >> hides the ugly stuff. >> >> Now that said, the ROLL working group does have a requirement to=20 >> support a more efficient way to support some > link-local scope=20 >> multicast operations. I don't see that helping us with ND for 6LoWPAN = =20 >> operations. Furthermore we can't depend on a specific routing = algorithm. >> >> - Zach >> >>> What do you think? >> >> >>> Alex >>> >>> >>> _______________________________________________ 6lowpan mailing list = >>> 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> >> >=20 >=20 -- 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. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From zach@sensinode.com Tue May 19 12:44: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 8A7883A6E00 for <6lowpan@core3.amsl.com>; Tue, 19 May 2009 12:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 vb8hUujEPjEO for <6lowpan@core3.amsl.com>; Tue, 19 May 2009 12:44:20 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 1DC013A6CAB for <6lowpan@ietf.org>; Tue, 19 May 2009 12:44:18 -0700 (PDT) Received: from snl-zach.local (line-7757.dyn.kponet.fi [85.29.76.170]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n4JJjnKk007793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 May 2009 22:45:49 +0300 Message-ID: <4A130C77.1050707@sensinode.com> Date: Tue, 19 May 2009 22:45:59 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Cam.Williams@tac.com References: <4A0D909A.3030106@gmail.com> <4A115173.2080700@sensinode.com><4A128EF2.8040703@gmail.com> <4A1293F3.2000402@sensinode.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] disagreement on link-layer multicast 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, 19 May 2009 19:44:21 -0000 Hi Cam, Cam.Williams@tac.com wrote: > > Hello Zach, > > You wrote: > I agree, we must minimize the use of multicast so that broadcast storms as you call them don't occur. Even if you use a link-layer adaptation that emulated multicast - you are still broadcasting on wireless links, even flooding. So this all boils down to minimizing the use of multicast. ...in the context of neighbor discovery. Its actually not just flooding that is a problem, but also node sleep cycles. So you also can't depend on multicast to actually reach all nodes. > Comment: > Multicast can be done without flooding the network, if the nodes that are members of the multicast group are clumped, not evenly distributed throughout the network. A non-member node decrements a radius count and forwards the multicast. A member node reloads (or computes) the radius count and forwards the multicast. Forwarding is a one-hop broadcast. Once the radius count is 0, forwarding stops. I'm sure that there are even better ways than this simple mechanism. Totally agree. This *could* be provided by some link-layer or adaptation (unknown today), and e.g. ROLL has a requirement to support larger scope multicast in its routing algorithm. But this won't help us for neighbor discovery (RFC4861) where lots of link-local scope all-node and all-router multicast is used. So instead in draft-6lowpan-nd we use unicast, and some link-local scope multicast when we don't need to reaching sleeping nodes. For other purposes I am sure that ROLL or multicast link-layers will make some forms of multicast useful in LoWPANs to reach groups of nodes. - Zach > Cheers, > > Cam > --- > Cam Williams > Schneider-Electric TAC R&D > 978 975 9533 office > 978 500 8807 cell > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby > Sent: Tuesday, May 19, 2009 7:12 AM > To: Alexandru Petrescu > Cc: 6lowpan > Subject: Re: [6lowpan] disagreement on link-layer multicast > > Hi, > > Alexandru Petrescu wrote: >> Zach, >> >> I humbly take advantage of this to express disagreement, and my >> support of the following: > >> -LoWPAN node SHOULD join the relevant multicast groups when the >> underlying link is multicast-capable (contrary to what >> draft-ietf-6lowpan-nd suggests) - risk of inefficient link use. > > Sure, we can say that (I will take an AP). We will still reduce the frequency and use of multicast wherever possible however in 6lowpan-nd. > >> -IP LoWPAN node shouldn't use the 0xffff link broadcast addresses - >> risk of 'storms'. > > The IP LoWPAN node makes no such decision at L3... It sends a packet to > FF02::1 or FF02::2 for example, the mapping is done by the link-layer adaptation. Most link-layers will use some kind of broadcast (like IEEE > 802.15.4) to send such a packet. > > I agree, we must minimize the use of multicast so that broadcast storms as you call them don't occur. Even if you use a link-layer adaptation that emulated multicast - you are still broadcasting on wireless links, even flooding. So this all boils down to minimizing the use of multicast. > >> -adaptation layer shouldn't precede the IP header, nor should it >> eliminate it (as rfc4944 does) - otherwise there's no more IP. > > No comment. > >> -IP layer shouldn't do tasks reserved to the link-layer - risk of >> 'layer violation'. > > Nor is it in this working group. The IP layer also has to live with *existing link layers*, and actually function efficiently with them. > Just because you would like a link-layer to function in some way - it doesn't mean it will. This is not a theoretical exercise - we are working with real radios here. > >> I dare to qualify these as bviously debatable points (although >> apparently only I maintain them), and I do think they deserve much >> larger discussion. > >> I do share the point of view of the need to connect these devices to >> the Internet. >> >> Yours, >> >> Alex >> >> Zach Shelby a écrit : >>> Hi, >>> >>> Alexandru Petrescu wrote: >>>> I need to correct my stance here, now knowing IEEE 802.15.5 >>>> mesh-under does offer multicast link-layer. >>> IEEE 802.15.4-2006 does not support multicast. >>> >>> RFC4944 Section 9 only has a theoretical mapping of multicast >>> addresses to 16-bit short addresses. It assumes that some future >>> LoWPAN mesh-under routing algorithm would have some way of realizing >>> those multicast mechanisms. Multicast would likely still be mapped to >>> IEEE 802.15.4 broadcast, and even worse, over multihops that is >>> flooding. In fact, because each link-local scope multicast could be a >>> multihop flood, it might even be much worse without IP knowing it. >>> Section 9 was done a bit prematurely, as in the end there are no >>> LoWPAN mesh algorithms being specified, the concentration is on IP >>> routing and ROLL. >>> >>>> I think when mesh-under is available, multicast link-layer is also >>>> available, and when so the LoWPAN ND should take advantage of it: do >>>> the typical link-scoped multicast operations: join, leave. >>> I don't have a problem with a limited amount of link-scope multicast >>> use if it is a simple broadcast (not a flood), if it actually reaches >>> the nodes intended, and the frequency is low. For example link-local >>> scoped multicast is used in ND for 6LoWPAN by RS/RA messages. The >>> frequency is optimized using the Trickle algorithm. >>> >>>> I think the '100' described by 4944 "Multicast Address Mapping" >>>> should be known and reserved by IEEE, if it's not already, such that >>>> other than IP protocols don't make group addresses which start with >>>> '100'. >>> This has nothing to do with IEEE 802.15.4 right now. If IEEE 802.15.4 >>> would support multicast some day, we should of course encourage them >>> to consider RFC4944 Section 9 format. >>> >>>> And I also suggest to have specific text in LoWPAN ND draft which >>>> says that if mesh-under is available then group ff02::1 maps into >>>> 0x8001 and ff02::2 into 0x8002, and LoWPAN ND should use the >>>> link-layer multicast features if mesh-under is available. >>> Section 9 of RFC4944 refers only to a LoWPAN mesh-under solution >>> (which doesn't exist today). Other link-layers which may support >>> mesh-under might have a completely different mapping. It would be >>> confusing to specify a mapping which is not useful. >> For other link layers with other mappings, specify other >> IPv6-over-that-link documents. >> >>> Better to leave the mapping up to the link-layer. >> IPv6 over Ethernet takes a specific mapping, it doesn't leave it to >> Ethernet. >> >>>> Example specific statement is "LoWPAN node SHOULD or MUST join the >>>> group ff02::1, if mesh-under is available". This expands the >>>> current LoWPAN ND text which says "A LoWPAN Node does not need to >>>> join the solicited-node multicast address for its own addresses and >>>> SHOULD NOT have to answer a multicast Neighbor Solicitation." >>> Avoiding the need for nodes to answer multicast messages has more to >>> do with the fact that much of the time nodes are sleeping, and >>> furthermore the link-layer scope does not cover all the nodes useful >>> for performing ND operations (the whole subnet). Mesh-under has >>> exactly the same sleeping node problem as route-over. >>> >>> Furthermore in a mesh-under configuration, even though it seems >>> link-local scope covers the entire LoWPAN, doing an all-nodes >>> multicast on the link-layer will likely be a flood. So link-layer >>> abstraction here doesn't make things any more efficient. It just >>> hides the ugly stuff. >>> >>> Now that said, the ROLL working group does have a requirement to >>> support a more efficient way to support some > link-local scope >>> multicast operations. I don't see that helping us with ND for 6LoWPAN >>> operations. Furthermore we can't depend on a specific routing algorithm. >>> >>> - Zach >>> >>>> What do you think? >>> >>>> Alex >>>> >>>> >>>> _______________________________________________ 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. > _______________________________________________ > 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. From zach@sensinode.com Wed May 20 13:31: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 21C733A69A9 for <6lowpan@core3.amsl.com>; Wed, 20 May 2009 13:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 RPRhgRJO7oR2 for <6lowpan@core3.amsl.com>; Wed, 20 May 2009 13:31:35 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A8B493A6DC1 for <6lowpan@ietf.org>; Wed, 20 May 2009 13:31:33 -0700 (PDT) Received: from snl-zach.local (line-7867.dyn.kponet.fi [85.29.77.25]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n4KKX56J009053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Wed, 20 May 2009 23:33:06 +0300 Message-ID: <4A146912.9040706@sensinode.com> Date: Wed, 20 May 2009 23:33:22 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowpan] Questions for nd-03 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, 20 May 2009 20:31:36 -0000 We are making progress towards the nd-03 release (by Friday I hope). Reviews by several people brought up the following issues that were not on the ticket list, which I want to check with the WG and include in nd-03: 1. The messages Router Registration/Router Confirmation (RR/RC), would make much more sense to 6LoWPAN newcomers if they would be called Node Registration/Node Confirmation instead (NR/NC). We discussed this earlier but didn't find a name - NR/NC seems to work well. Is the WG OK with this change? 2. nd-02 was difficult to understand for implementers as there started to be many optional things across multiple link types and multiple LoWPAN types. Several good reviews pointed out that 6lowpan-nd really needs the Whiteboard for any benefit (otherwise you do RFC4861..), and making it a default data structure for Edge Routers would make this easier to understand and implement. The suggestion is to make the Whiteboard a standard data structure for Edge Routers. Considering that Edge Routers implement full IPv6 and RFC4861, the complexity this adds is really marginal. Is the WG OK this change? Thanks, 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 zach@sensinode.com Mon May 25 06:15:04 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 7E44B3A6F7B for <6lowpan@core3.amsl.com>; Mon, 25 May 2009 06:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 L0E7lJsNyNas for <6lowpan@core3.amsl.com>; Mon, 25 May 2009 06:15:03 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 6F9FB3A6F6E for <6lowpan@ietf.org>; Mon, 25 May 2009 06:15:02 -0700 (PDT) Received: from snl-zach.local ([82.203.205.227]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n4PDGWn9022634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Mon, 25 May 2009 16:16:33 +0300 Message-ID: <4A1A9A2B.7060708@sensinode.com> Date: Mon, 25 May 2009 16:16:27 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowpan] MIPv6 and 6LoWPAN 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, 25 May 2009 13:15:04 -0000 Hi, On a bit of a tangent... I have been studying different ways of dealing with mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide some mobility support for micro-mobility, which is good. Properly designed applications can also deal with IP addresses changing. But what if you would want to have a stable IP address for a 6LoWPAN node or a stable prefix for a whole LoWPAN? MIPv6 have several problems to be used directly by LoWPAN nodes, e.g.: - IP-in-IP encapsulation with the home agent - Security for binding management messages - Potentially large amounts of binding messages Is anyone aware of work on MIPv6 proxy mechanisms which would allow e.g. an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node? Maybe revive the Foreign Agent for IPv6? ;-) NEMO is much more clearly applicable to 6LoWPAN network mobility. The basic NEMO protocol is a perfect match, allowing an Edge Router or other router in the visited network to act as a Mobile Router and perform MIPv6 on behalf of the network. Thus maintaining constant prefixes for all LoWPANs under the router. I don't see route optimization to be necessary for NEMO used with 6LoWPAN, the performance of traffic going through the home agent should be fine. Thoughts? - 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 jabeille@cisco.com Mon May 25 07:20: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 AE3B63A6AE5 for <6lowpan@core3.amsl.com>; Mon, 25 May 2009 07:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.985 X-Spam-Level: X-Spam-Status: No, score=-9.985 tagged_above=-999 required=5 tests=[AWL=0.614, 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 9P-cE3Qwz5dc for <6lowpan@core3.amsl.com>; Mon, 25 May 2009 07:20:11 -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 4485C3A6FE3 for <6lowpan@ietf.org>; Mon, 25 May 2009 07:20:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,244,1241395200"; d="scan'208";a="41284010" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 May 2009 14:21:51 +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 n4PELplS007551; Mon, 25 May 2009 16:21:51 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4PELp3F027538; Mon, 25 May 2009 14:21:51 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 May 2009 16:21: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 May 2009 16:21:49 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A8603210E6F@xmb-ams-33d.emea.cisco.com> In-Reply-To: <4A1A9A2B.7060708@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] MIPv6 and 6LoWPAN Thread-Index: AcndOxCXPHHcX3cER4aGhlbrn3JdQQACHAoQ References: <4A1A9A2B.7060708@sensinode.com> From: "Julien Abeille (jabeille)" To: "Zach Shelby" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 25 May 2009 14:21:51.0208 (UTC) FILETIME=[256B6680:01C9DD44] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2726; t=1243261311; x=1244125311; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[6lowpan]=20MIPv6=20and=206LoWPAN |Sender:=20; bh=7zvNZnW+VxMPl0hmckPgMjYqxgCl85zVWEX5MCDt+0w=; b=H4coLsgkyZv+2avcvh1oKf+zJJOnaKxBiycf7/v8KWy5ulmbQfKXwhp+xk f5elVXRdr2mspPdic95cwQVO1C8xhtAn2wu6bcf9u518uEnGjdrdJDKka2OA 7TJdlToBeP; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [6lowpan] MIPv6 and 6LoWPAN 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, 25 May 2009 14:20:12 -0000 Hi Zach, The issue with NEMO is that if nodes move from one router to another (meaning the routers doing the nemo signaling), their address change. NEMO is made to handle mobility of the whole network behind the router, not individual nodes moving from this network to another. What you are probably looking for is Proxy Mobile IPv6 (http://www.ietf.org/rfc/rfc5213.txt) and in general the work behing done by the netlmm working group (http://www.ietf.org/html.charters/netlmm-charter.html) and the netext working group (http://www.ietf.org/html.charters/netext-charter.html). Best, Julien -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby Sent: lundi 25 mai 2009 15:16 To: 6lowpan Subject: [6lowpan] MIPv6 and 6LoWPAN Hi, On a bit of a tangent... I have been studying different ways of dealing with mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide some mobility support for micro-mobility, which is good. Properly designed applications can also deal with IP addresses changing. But what if you would want to have a stable IP address for a 6LoWPAN node or a stable prefix for a whole LoWPAN? MIPv6 have several problems to be used directly by LoWPAN nodes, e.g.: - IP-in-IP encapsulation with the home agent - Security for binding management messages - Potentially large amounts of binding messages Is anyone aware of work on MIPv6 proxy mechanisms which would allow e.g.=20 an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node?=20 Maybe revive the Foreign Agent for IPv6? ;-) NEMO is much more clearly applicable to 6LoWPAN network mobility. The basic NEMO protocol is a perfect match, allowing an Edge Router or other router in the visited network to act as a Mobile Router and perform MIPv6 on behalf of the network. Thus maintaining constant prefixes for all LoWPANs under the router. I don't see route optimization to be necessary for NEMO used with 6LoWPAN, the performance of traffic going through the home agent should be fine. Thoughts? - 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. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From jonghyouk@gmail.com Mon May 25 07:39: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 17A7228C0DD for <6lowpan@core3.amsl.com>; Mon, 25 May 2009 07:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, URIBL_GREY=0.25] 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 AL7oiMx0uNRH for <6lowpan@core3.amsl.com>; Mon, 25 May 2009 07:39:34 -0700 (PDT) Received: from mail-px0-f193.google.com (mail-px0-f193.google.com [209.85.216.193]) by core3.amsl.com (Postfix) with ESMTP id F23423A6BE3 for <6lowpan@ietf.org>; Mon, 25 May 2009 07:39:33 -0700 (PDT) Received: by pxi31 with SMTP id 31so2645972pxi.29 for <6lowpan@ietf.org>; Mon, 25 May 2009 07:41:09 -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; bh=M2nj5hENUPOEp0UmV34PmWEJJoeHPH3M3alxUTIT/Ew=; b=U2BSyDRKbc1t2tzRJybvyfbEsHwcQvr+pGkwUITOKvAzcT1hBOgSVZFMFnZbhBiuFy c+/ME4FtAABZXiOO9+sR/8mrB2EKRmxreosLpsEFKSufK+CoHtCvt+tByppinEaQk0/u jingkWAPCk3G5sVxI4VR40ycDM1IR7LUt+dAE= 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; b=cEmjHhUQMeQoag3U4eL5G4qFY/RkxF8VHCij8tTw/8O/uptAJMcSV9DPgUzXzg0i6r NbgJnTkYfUHwn0TIpTONl7RMiapGnxFEuxTwMLseYq3Nh65a9QgMPUiboeZZWGPZg/uJ F3Ib8qoSdRimU9IE82IBTFUi+Pxll0e8MpBT4= MIME-Version: 1.0 Received: by 10.110.63.17 with SMTP id l17mr237370tia.36.1243262468840; Mon, 25 May 2009 07:41:08 -0700 (PDT) In-Reply-To: <38F26F36EAA981478A49D1F37F474A8603210E6F@xmb-ams-33d.emea.cisco.com> References: <4A1A9A2B.7060708@sensinode.com> <38F26F36EAA981478A49D1F37F474A8603210E6F@xmb-ams-33d.emea.cisco.com> Date: Mon, 25 May 2009 23:41:08 +0900 Message-ID: From: Jong-Hyouk Lee To: Zach Shelby , "Julien Abeille (jabeille)" Content-Type: multipart/alternative; boundary=001485eefddad15f37046abd9993 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] MIPv6 and 6LoWPAN 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, 25 May 2009 14:39:42 -0000 --001485eefddad15f37046abd9993 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, all. NEMO scenarios within PMIPv6 domain have been presented in the following document. http://tools.ietf.org/html/draft-jhlee-netlmm-nemo-scenarios-01 Hope you find useful scenarios for 6LowPAN. Cheers. On Mon, May 25, 2009 at 11:21 PM, Julien Abeille (jabeille) < jabeille@cisco.com> wrote: > Hi Zach, > > The issue with NEMO is that if nodes move from one router to another > (meaning the routers doing the nemo signaling), their address change. > NEMO is made to handle mobility of the whole network behind the router, > not individual nodes moving from this network to another. > > What you are probably looking for is Proxy Mobile IPv6 > (http://www.ietf.org/rfc/rfc5213.txt) and in general the work behing > done by the netlmm working group > (http://www.ietf.org/html.charters/netlmm-charter.html) and the netext > working group (http://www.ietf.org/html.charters/netext-charter.html). > > Best, > Julien > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Zach Shelby > Sent: lundi 25 mai 2009 15:16 > To: 6lowpan > Subject: [6lowpan] MIPv6 and 6LoWPAN > > Hi, > > On a bit of a tangent... I have been studying different ways of dealing > with mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide > some mobility support for micro-mobility, which is good. Properly > designed applications can also deal with IP addresses changing. But what > if you would want to have a stable IP address for a 6LoWPAN node or a > stable prefix for a whole LoWPAN? > > MIPv6 have several problems to be used directly by LoWPAN nodes, e.g.: > - IP-in-IP encapsulation with the home agent > - Security for binding management messages > - Potentially large amounts of binding messages Is anyone aware of work > on MIPv6 proxy mechanisms which would allow e.g. > an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node? > Maybe revive the Foreign Agent for IPv6? ;-) > > NEMO is much more clearly applicable to 6LoWPAN network mobility. The > basic NEMO protocol is a perfect match, allowing an Edge Router or other > router in the visited network to act as a Mobile Router and perform > MIPv6 on behalf of the network. Thus maintaining constant prefixes for > all LoWPANs under the router. I don't see route optimization to be > necessary for NEMO used with 6LoWPAN, the performance of traffic going > through the home agent should be fine. > > Thoughts? > > - 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. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://hurryon.googlepages.com/ --001485eefddad15f37046abd9993 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all.

NEMO scenarios within PMIPv6 domain have been presented in = the following document.

http://tools.ietf.org/html/draft-jhlee-netl= mm-nemo-scenarios-01

Hope you find useful scenarios for 6LowPAN.

Cheers.

On Mon, May 25, 2009 at 11:21 PM, Julien Abeille (jab= eille) <jabeille= @cisco.com> wrote:
Hi Zach,

The issue with NEMO is that if nodes move from one router to another
(meaning the routers doing the nemo signaling), their address change.
NEMO is made to handle mobility of the whole network behind the router,
not individual nodes moving from this network to another.

What you are probably looking for is Proxy Mobile IPv6
(http://w= ww.ietf.org/rfc/rfc5213.txt) and in general the work behing
done by the netlmm working group
(http://www.ietf.org/html.charters/netlmm-charter.html) and = the netext
working group (http://www.ietf.org/html.charters/netext-charter.ht= ml).

Best,
Julien

-----Original Message-----
From: 6lowpan-bounces@ietf.org<= /a> [mailto:6lowpan-bounces@iet= f.org] On
Behalf Of Zach Shelby
Sent: lundi 25 mai 2009 15:16
To: 6lowpan
Subject: [6lowpan] MIPv6 and 6LoWPAN

Hi,

On a bit of a tangent... I have been studying different ways of dealing
with mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide
some mobility support for micro-mobility, which is good. Properly
designed applications can also deal with IP addresses changing. But what if you would want to have a stable IP address for a 6LoWPAN node or a
stable prefix for a whole LoWPAN?

MIPv6 have several problems to be used directly by LoWPAN nodes, e.g.:
- IP-in-IP encapsulation with the home agent
- Security for binding management messages
- Potentially large amounts of binding messages Is anyone aware of work
on MIPv6 proxy mechanisms which would allow e.g.
an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node?
Maybe revive the Foreign Agent for IPv6? ;-)

NEMO is much more clearly applicable to 6LoWPAN network mobility. The
basic NEMO protocol is a perfect match, allowing an Edge Router or other router in the visited network to act as a Mobile Router and perform
MIPv6 on behalf of the network. Thus maintaining constant prefixes for
all LoWPANs under the router. I don't see route optimization to be
necessary for NEMO used with 6LoWPAN, the performance of traffic going
through the home agent should be fine.

Thoughts?

- 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.
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan



--
Internet Ma= nagement Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.
#email: jonghyouk (at) gmail (dot) com
#webpage: http://hurryon.googlepages.com/
--001485eefddad15f37046abd9993-- From ricardo.mendao@gmail.com Mon May 25 13:37: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 2E2BC3A689B for <6lowpan@core3.amsl.com>; Mon, 25 May 2009 13:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, URIBL_GREY=0.25] 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 DLNDzoToBq42 for <6lowpan@core3.amsl.com>; Mon, 25 May 2009 13:37:03 -0700 (PDT) Received: from smtp2.dei.uc.pt (smtp.dei.uc.pt [193.137.203.253]) by core3.amsl.com (Postfix) with ESMTP id 468393A67AD for <6lowpan@ietf.org>; Mon, 25 May 2009 13:37:02 -0700 (PDT) Received: from [192.168.2.4] (a213-22-125-25.cpe.netcabo.pt [213.22.125.25]) (authenticated bits=0) by smtp2.dei.uc.pt (8.14.3/8.14.3) with ESMTP id n4PKbcu0016109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Mon, 25 May 2009 21:38:08 +0100 Message-Id: From: Ricardo Silva To: 6lowpan@ietf.org In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1313-839770515 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 25 May 2009 21:37:39 +0000 References: X-Mailer: Apple Mail (2.935.3) X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner-ID: n4PKbcu0016109 X-FCTUC-DEI-SIC-MailScanner: Not scanned: please contact helpdesk@dei.uc.pt for details X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SORBS-DNSBL, SpamAssassin (not cached, score=-52.986, required 3.252, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.06, BAYES_00 -1.50, HTML_MESSAGE 0.00, L_SMTP_AUTH -50.00, URIBL_GREY 0.25) X-FCTUC-DEI-SIC-MailScanner-From: ricardo.mendao@gmail.com Subject: Re: [6lowpan] MIPv6 and 6LoWPAN (Ricardo Silva) 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, 25 May 2009 20:37:12 -0000 --Apple-Mail-1313-839770515 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Dear All, I am sending our draft about mobility in lowPANs. It would be great =20= if you could send me your feedback. https://datatracker.ietf.org/drafts/draft-silva-6lowpan-mipv6/ Best regards, Ricardo Mend=E3o Silva Laboratory of Telecommunications and Telematic Department of Informatics Engineering University of Coimbra PORTUGAL On May 25, 2009, at 7:00 PM, 6lowpan-request@ietf.org wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/6lowpan > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send 6lowpan mailing list submissions to > 6lowpan@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/6lowpan > or, via email, send a message with subject or body 'help' to > 6lowpan-request@ietf.org > > You can reach the person managing the list at > 6lowpan-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 6lowpan digest..." > > > Today's Topics: > > 1. MIPv6 and 6LoWPAN (Zach Shelby) > 2. Re: MIPv6 and 6LoWPAN (Julien Abeille (jabeille)) > 3. Re: MIPv6 and 6LoWPAN (Jong-Hyouk Lee) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 May 2009 16:16:27 +0300 > From: Zach Shelby > Subject: [6lowpan] MIPv6 and 6LoWPAN > To: 6lowpan <6lowpan@ietf.org> > Message-ID: <4A1A9A2B.7060708@sensinode.com> > Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed > > Hi, > > On a bit of a tangent... I have been studying different ways of =20 > dealing > with mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide > some mobility support for micro-mobility, which is good. Properly > designed applications can also deal with IP addresses changing. But =20= > what > if you would want to have a stable IP address for a 6LoWPAN node or a > stable prefix for a whole LoWPAN? > > MIPv6 have several problems to be used directly by LoWPAN nodes, e.g.: > - IP-in-IP encapsulation with the home agent > - Security for binding management messages > - Potentially large amounts of binding messages > Is anyone aware of work on MIPv6 proxy mechanisms which would allow =20= > e.g. > an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node? > Maybe revive the Foreign Agent for IPv6? ;-) > > NEMO is much more clearly applicable to 6LoWPAN network mobility. The > basic NEMO protocol is a perfect match, allowing an Edge Router or =20 > other > router in the visited network to act as a Mobile Router and perform > MIPv6 on behalf of the network. Thus maintaining constant prefixes for > all LoWPANs under the router. I don't see route optimization to be > necessary for NEMO used with 6LoWPAN, the performance of traffic going > through the home agent should be fine. > > Thoughts? > > - Zach > > --=20 > 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 =20 > without > producing, distributing or retaining copies thereof. > > > ------------------------------ > > Message: 2 > Date: Mon, 25 May 2009 16:21:49 +0200 > From: "Julien Abeille (jabeille)" > Subject: Re: [6lowpan] MIPv6 and 6LoWPAN > To: "Zach Shelby" , "6lowpan" <6lowpan@ietf.org> > Message-ID: > = <38F26F36EAA981478A49D1F37F474A8603210E6F@xmb-ams-33d.emea.cisco.com> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi Zach, > > The issue with NEMO is that if nodes move from one router to another > (meaning the routers doing the nemo signaling), their address change. > NEMO is made to handle mobility of the whole network behind the =20 > router, > not individual nodes moving from this network to another. > > What you are probably looking for is Proxy Mobile IPv6 > (http://www.ietf.org/rfc/rfc5213.txt) and in general the work behing > done by the netlmm working group > (http://www.ietf.org/html.charters/netlmm-charter.html) and the netext > working group (http://www.ietf.org/html.charters/netext-charter.html). > > Best, > Julien > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Zach Shelby > Sent: lundi 25 mai 2009 15:16 > To: 6lowpan > Subject: [6lowpan] MIPv6 and 6LoWPAN > > Hi, > > On a bit of a tangent... I have been studying different ways of =20 > dealing > with mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide > some mobility support for micro-mobility, which is good. Properly > designed applications can also deal with IP addresses changing. But =20= > what > if you would want to have a stable IP address for a 6LoWPAN node or a > stable prefix for a whole LoWPAN? > > MIPv6 have several problems to be used directly by LoWPAN nodes, e.g.: > - IP-in-IP encapsulation with the home agent > - Security for binding management messages > - Potentially large amounts of binding messages Is anyone aware of =20 > work > on MIPv6 proxy mechanisms which would allow e.g. > an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node? > Maybe revive the Foreign Agent for IPv6? ;-) > > NEMO is much more clearly applicable to 6LoWPAN network mobility. The > basic NEMO protocol is a perfect match, allowing an Edge Router or =20 > other > router in the visited network to act as a Mobile Router and perform > MIPv6 on behalf of the network. Thus maintaining constant prefixes for > all LoWPANs under the router. I don't see route optimization to be > necessary for NEMO used with 6LoWPAN, the performance of traffic going > through the home agent should be fine. > > Thoughts? > > - 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 =20 > without > producing, distributing or retaining copies thereof. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > ------------------------------ > > Message: 3 > Date: Mon, 25 May 2009 23:41:08 +0900 > From: Jong-Hyouk Lee > Subject: Re: [6lowpan] MIPv6 and 6LoWPAN > To: Zach Shelby , "Julien Abeille (jabeille)" > > Cc: 6lowpan <6lowpan@ietf.org> > Message-ID: > > Content-Type: text/plain; charset=3D"iso-8859-1" > > Hi, all. > > NEMO scenarios within PMIPv6 domain have been presented in the =20 > following > document. > > http://tools.ietf.org/html/draft-jhlee-netlmm-nemo-scenarios-01 > > Hope you find useful scenarios for 6LowPAN. > > Cheers. > > On Mon, May 25, 2009 at 11:21 PM, Julien Abeille (jabeille) < > jabeille@cisco.com> wrote: > >> Hi Zach, >> >> The issue with NEMO is that if nodes move from one router to another >> (meaning the routers doing the nemo signaling), their address change. >> NEMO is made to handle mobility of the whole network behind the =20 >> router, >> not individual nodes moving from this network to another. >> >> What you are probably looking for is Proxy Mobile IPv6 >> (http://www.ietf.org/rfc/rfc5213.txt) and in general the work behing >> done by the netlmm working group >> (http://www.ietf.org/html.charters/netlmm-charter.html) and the =20 >> netext >> working group (http://www.ietf.org/html.charters/netext-=20 >> charter.html). >> >> Best, >> Julien >> >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Zach Shelby >> Sent: lundi 25 mai 2009 15:16 >> To: 6lowpan >> Subject: [6lowpan] MIPv6 and 6LoWPAN >> >> Hi, >> >> On a bit of a tangent... I have been studying different ways of =20 >> dealing >> with mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide >> some mobility support for micro-mobility, which is good. Properly >> designed applications can also deal with IP addresses changing. But =20= >> what >> if you would want to have a stable IP address for a 6LoWPAN node or a >> stable prefix for a whole LoWPAN? >> >> MIPv6 have several problems to be used directly by LoWPAN nodes, =20 >> e.g.: >> - IP-in-IP encapsulation with the home agent >> - Security for binding management messages >> - Potentially large amounts of binding messages Is anyone aware of =20= >> work >> on MIPv6 proxy mechanisms which would allow e.g. >> an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node? >> Maybe revive the Foreign Agent for IPv6? ;-) >> >> NEMO is much more clearly applicable to 6LoWPAN network mobility. The >> basic NEMO protocol is a perfect match, allowing an Edge Router or =20= >> other >> router in the visited network to act as a Mobile Router and perform >> MIPv6 on behalf of the network. Thus maintaining constant prefixes =20= >> for >> all LoWPANs under the router. I don't see route optimization to be >> necessary for NEMO used with 6LoWPAN, the performance of traffic =20 >> going >> through the home agent should be fine. >> >> Thoughts? >> >> - 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 =20 >> contain >> legally privileged information. If you are not the intended =20 >> recipient, >> please contact the sender and delete the e-mail from your system =20 >> without >> producing, distributing or retaining copies thereof. >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > > > > --=20 > Internet Management Technology Lab, Sungkyunkwan University. > Jong-Hyouk Lee. > > #email: jonghyouk (at) gmail (dot) com > #webpage: http://hurryon.googlepages.com/ > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: = > > > ------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > End of 6lowpan Digest, Vol 52, Issue 18 > *************************************** --Apple-Mail-1313-839770515 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,

 I am sending = our draft about mobility in lowPANs. It would be great if you could send = me your feedback.

ht= tps://datatracker.ietf.org/drafts/draft-silva-6lowpan-mipv6/

Best regards,

Ricardo Mend=E3o = Silva

Laboratory of Telecommunications and = Telematic
Department of Informatics = Engineering
University of = Coimbra
PORTUGAL


On May 25, 2009, at 7:00 PM, 6lowpan-request@ietf.org = wrote:

If you have received this digest without all the = individual message
attachments you will need to update your digest = options in your list
subscription.  To do so, go to

https://www.ietf.or= g/mailman/listinfo/6lowpan

Click the 'Unsubscribe or edit = options' button, log in, and set "Get
MIME or Plain Text Digests?" to = MIME.  You can set this option
globally for all the list digests = you receive at this point.



Send 6lowpan mailing list = submissions to
6lowpan@ietf.org

To = subscribe or unsubscribe via the World Wide Web, visit
= https://www.ietf.org/mailman/listinfo/6lowpan
or, via email, = send a message with subject or body 'help' to
= 6lowpan-request@ietf.org

You can reach the person managing = the list at
= 6lowpan-owner@ietf.org

When replying, please edit your = Subject line so it is more specific
than "Re: Contents of 6lowpan = digest..."


Today's Topics:

  1. MIPv6 and = 6LoWPAN (Zach Shelby)
  2. Re: MIPv6 and 6LoWPAN (Julien = Abeille (jabeille))
  3. Re: MIPv6 and 6LoWPAN (Jong-Hyouk = Lee)


----------------------------------------------------------= ------------

Message: 1
Date: Mon, 25 May 2009 16:16:27 = +0300
From: Zach Shelby <zach@sensinode.com>
Subject: [6lowpan] = MIPv6 and 6LoWPAN
To: 6lowpan <6lowpan@ietf.org>
Message-ID: = <4A1A9A2B.7060708@sensinode.com>
Content-Type: text/plain; = charset=3Dwindows-1252; format=3Dflowed

Hi,

On a bit of a = tangent... I have been studying different ways of dealing
with = mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide =
some mobility support for micro-mobility, which is good. Properly =
designed applications can also deal with IP addresses changing. But = what
if you would want to have a stable IP address for a 6LoWPAN = node or a
stable prefix for a whole LoWPAN?

MIPv6 have = several problems to be used directly by LoWPAN nodes, e.g.:
- = IP-in-IP encapsulation with the home agent
- Security for binding = management messages
- Potentially large amounts of binding = messages
Is anyone aware of work on MIPv6 proxy mechanisms which = would allow e.g.
an Edge Router to proxy MIPv6 operations on behalf = of a LoWPAN node?
Maybe revive the Foreign Agent for IPv6? = ;-)

NEMO is much more clearly applicable to 6LoWPAN network = mobility. The
basic NEMO protocol is a perfect match, allowing an = Edge Router or other
router in the visited network to act as a = Mobile Router and perform
MIPv6 on behalf of the network. Thus = maintaining constant prefixes for
all LoWPANs under the router. I = don't see route optimization to be
necessary for NEMO used with = 6LoWPAN, the performance of traffic going
through the home agent = should be fine.

Thoughts?

- 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.


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

Message: = 2
Date: Mon, 25 May 2009 16:21:49 +0200
From: "Julien Abeille = (jabeille)" <jabeille@cisco.com>
Subject: Re: [6lowpan] MIPv6 and = 6LoWPAN
To: "Zach Shelby" <zach@sensinode.com>, "6lowpan" = <6lowpan@ietf.org>
Message-ID:
= <38F26F36EAA981478A49D1F37F474A8603210E6F@xmb-ams-33d.emea.cisco= .com>
Content-Type: text/plain; charset=3D"us-ascii"

Hi = Zach,

The issue with NEMO is that if nodes move from one router = to another
(meaning the routers doing the nemo signaling), their = address change.
NEMO is made to handle mobility of the whole network = behind the router,
not individual nodes moving from this network to = another.

What you are probably looking for is Proxy Mobile = IPv6
(http://www.ietf.org/rfc/rfc5213.txt) and in general the work = behing
done by the netlmm working = group
(http://www.ietf.org/html.charters/netlmm-charter.html) and the = netext
working group = (http://www.ietf.org/html.charters/netext-charter.html).

Best,
J= ulien

-----Original Message-----
From: = 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On
Behalf = Of Zach Shelby
Sent: lundi 25 mai 2009 15:16
To: = 6lowpan
Subject: [6lowpan] MIPv6 and 6LoWPAN

Hi,

On a = bit of a tangent... I have been studying different ways of = dealing
with mobility of 6LoWPAN nodes and networks. Extended LoWPANs = provide
some mobility support for micro-mobility, which is good. = Properly
designed applications can also deal with IP addresses = changing. But what
if you would want to have a stable IP address for = a 6LoWPAN node or a
stable prefix for a whole LoWPAN?

MIPv6 = have several problems to be used directly by LoWPAN nodes, e.g.:
- = IP-in-IP encapsulation with the home agent
- Security for binding = management messages
- Potentially large amounts of binding messages = Is anyone aware of work
on MIPv6 proxy mechanisms which would allow = e.g.
an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN = node?
Maybe revive the Foreign Agent for IPv6? ;-)

NEMO is = much more clearly applicable to 6LoWPAN network mobility. The
basic = NEMO protocol is a perfect match, allowing an Edge Router or = other
router in the visited network to act as a Mobile Router and = perform
MIPv6 on behalf of the network. Thus maintaining constant = prefixes for
all LoWPANs under the router. I don't see route = optimization to be
necessary for NEMO used with 6LoWPAN, the = performance of traffic going
through the home agent should be = fine.

Thoughts?

- = 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.
_______________________________________________
6lowpan = mailing = list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan<= br>

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

Message: 3
Date: = Mon, 25 May 2009 23:41:08 +0900
From: Jong-Hyouk Lee = <jonghyouk@gmail.com>
Subject: Re: [6lowpan] MIPv6 and = 6LoWPAN
To: Zach Shelby <zach@sensinode.com>, "Julien = Abeille (jabeille)"
<jabeille@cisco.com>
Cc: = 6lowpan <6lowpan@ietf.org>
Message-ID:
= <f54070070905250741h3899da4fscb044b7d1fa71c8a@mail.gmail.com>Content-Type: text/plain; charset=3D"iso-8859-1"

Hi, = all.

NEMO scenarios within PMIPv6 domain have been presented in = the = following
document.

http://tools.ietf.org/html/draft-jhlee-netlm= m-nemo-scenarios-01

Hope you find useful scenarios for = 6LowPAN.

Cheers.

On Mon, May 25, 2009 at 11:21 PM, Julien = Abeille (jabeille) <
jabeille@cisco.com> wrote:

Hi Zach,

The issue with = NEMO is that if nodes move from one router to = another
(meaning the routers = doing the nemo signaling), their address = change.
NEMO is made to handle = mobility of the whole network behind the = router,
not individual nodes = moving from this network to another.

What you are = probably looking for is Proxy Mobile IPv6
(http://www.ietf.org/rfc/rfc5213.txt) and in general the = work behing
done by the netlmm = working group
(http://www.ietf.org/html.charters/netlmm-charter.html) = and the netext
working group = (http://www.ietf.org/html.charters/netext-charter.html).
<= blockquote type=3D"cite">
Best,
Julien

-----Original = Message-----
From: = 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] = On
Behalf Of Zach = Shelby
Sent: lundi 25 mai 2009 = 15:16
To: = 6lowpan
Subject: [6lowpan] = MIPv6 and 6LoWPAN

Hi,

On a bit of a = tangent... I have been studying different ways of = dealing
with mobility of = 6LoWPAN nodes and networks. Extended LoWPANs = provide
some mobility support = for micro-mobility, which is good. Properly
designed applications can also deal with IP addresses = changing. But what
if you = would want to have a stable IP address for a 6LoWPAN node or = a
stable prefix for a whole = LoWPAN?

MIPv6 have = several problems to be used directly by LoWPAN nodes, = e.g.:
- IP-in-IP encapsulation = with the home agent
- Security = for binding management messages
- Potentially large amounts of binding messages Is anyone = aware of work
on MIPv6 proxy = mechanisms which would allow e.g.
an Edge Router to proxy MIPv6 operations on behalf of a = LoWPAN node?
Maybe revive the = Foreign Agent for IPv6? ;-)

NEMO is much = more clearly applicable to 6LoWPAN network mobility. = The
basic NEMO protocol is a = perfect match, allowing an Edge Router or = other
router in the visited = network to act as a Mobile Router and = perform
MIPv6 on behalf of the = network. Thus maintaining constant prefixes = for
all LoWPANs under the = router. I don't see route optimization to be
necessary for NEMO used with 6LoWPAN, the performance of = traffic going
through the home = agent should be fine.

Thoughts?

- = 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.
_______________________________________________
6lowpan mailing = list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing = list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan




--
Internet = Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk = Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: = http://hurryon.googlepages.com/
-------------- next part = --------------
An HTML attachment was scrubbed...
URL: = <http://www.ietf.org/mail-archive/web/6lowpan/attachments/20090525/29c2= 8f21/attachment.htm>

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

________= _______________________________________
6lowpan mailing = list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan<= br>

End of 6lowpan Digest, Vol 52, Issue = 18
***************************************
=




= --Apple-Mail-1313-839770515-- From zach@sensinode.com Mon May 25 14:06:26 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 6A83B3A701A for <6lowpan@core3.amsl.com>; Mon, 25 May 2009 14:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, URIBL_GREY=0.25] 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 27dPVhBL9lFn for <6lowpan@core3.amsl.com>; Mon, 25 May 2009 14:06:24 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 9E5F83A6EFD for <6lowpan@ietf.org>; Mon, 25 May 2009 14:06:19 -0700 (PDT) Received: from snl-zach.local ([81.253.32.61]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n4PL7n8K003353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 00:07:53 +0300 Message-ID: <4A1B08A7.7050201@sensinode.com> Date: Tue, 26 May 2009 00:07:51 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ricardo Silva References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] MIPv6 and 6LoWPAN (Ricardo Silva) 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, 25 May 2009 21:06:26 -0000 Hi Ricardo, Thanks for reminding about your draft. A couple quick comments: - This model would require the edge routers to be aware of this "Micro MIPv6" message format, and to provide the compression/decompression. This means such a micro format would need separate standardization. - You should take draft-ietf-6lowpan-hc-05 (when posted) into account as it will provide next-header compression for extension headers including some of the optimizations needed by your draft. You might want to consider PMIPv6 and NEMO in your next draft, and how proxy methods could be used first and foremost to avoid LoWPAN nodes to get involved with MIPv6 at all. PMIPv6 and NEMO don't solve the problem of node mobility between domains however, which would still require a LoWPAN node to speak MIPv6. Then again, it probably is just a reality that IPv6 addresses of LoWPAN nodes will change upon inter-domain node mobility... and applications will need to live with that. - Zach Ricardo Silva wrote: > Dear All, > > I am sending our draft about mobility in lowPANs. It would be great if > you could send me your feedback. > > https://datatracker.ietf.org/drafts/draft-silva-6lowpan-mipv6/ > > Best regards, > > Ricardo Mendão Silva > > Laboratory of Telecommunications and Telematic > Department of Informatics Engineering > University of Coimbra > PORTUGAL > > > On May 25, 2009, at 7:00 PM, 6lowpan-request@ietf.org > wrote: > >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >> >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >> >> >> >> Send 6lowpan mailing list submissions to >> 6lowpan@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/6lowpan >> or, via email, send a message with subject or body 'help' to >> 6lowpan-request@ietf.org >> >> You can reach the person managing the list at >> 6lowpan-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of 6lowpan digest..." >> >> >> Today's Topics: >> >> 1. MIPv6 and 6LoWPAN (Zach Shelby) >> 2. Re: MIPv6 and 6LoWPAN (Julien Abeille (jabeille)) >> 3. Re: MIPv6 and 6LoWPAN (Jong-Hyouk Lee) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 25 May 2009 16:16:27 +0300 >> From: Zach Shelby >> Subject: [6lowpan] MIPv6 and 6LoWPAN >> To: 6lowpan <6lowpan@ietf.org> >> Message-ID: <4A1A9A2B.7060708@sensinode.com> >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> Hi, >> >> On a bit of a tangent... I have been studying different ways of dealing >> with mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide >> some mobility support for micro-mobility, which is good. Properly >> designed applications can also deal with IP addresses changing. But what >> if you would want to have a stable IP address for a 6LoWPAN node or a >> stable prefix for a whole LoWPAN? >> >> MIPv6 have several problems to be used directly by LoWPAN nodes, e.g.: >> - IP-in-IP encapsulation with the home agent >> - Security for binding management messages >> - Potentially large amounts of binding messages >> Is anyone aware of work on MIPv6 proxy mechanisms which would allow e.g. >> an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node? >> Maybe revive the Foreign Agent for IPv6? ;-) >> >> NEMO is much more clearly applicable to 6LoWPAN network mobility. The >> basic NEMO protocol is a perfect match, allowing an Edge Router or other >> router in the visited network to act as a Mobile Router and perform >> MIPv6 on behalf of the network. Thus maintaining constant prefixes for >> all LoWPANs under the router. I don't see route optimization to be >> necessary for NEMO used with 6LoWPAN, the performance of traffic going >> through the home agent should be fine. >> >> Thoughts? >> >> - 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. >> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 25 May 2009 16:21:49 +0200 >> From: "Julien Abeille (jabeille)" >> Subject: Re: [6lowpan] MIPv6 and 6LoWPAN >> To: "Zach Shelby" , "6lowpan" <6lowpan@ietf.org> >> Message-ID: >> <38F26F36EAA981478A49D1F37F474A8603210E6F@xmb-ams-33d.emea.cisco.com> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi Zach, >> >> The issue with NEMO is that if nodes move from one router to another >> (meaning the routers doing the nemo signaling), their address change. >> NEMO is made to handle mobility of the whole network behind the router, >> not individual nodes moving from this network to another. >> >> What you are probably looking for is Proxy Mobile IPv6 >> (http://www.ietf.org/rfc/rfc5213.txt) and in general the work behing >> done by the netlmm working group >> (http://www.ietf.org/html.charters/netlmm-charter.html) and the netext >> working group (http://www.ietf.org/html.charters/netext-charter.html). >> >> Best, >> Julien >> >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Zach Shelby >> Sent: lundi 25 mai 2009 15:16 >> To: 6lowpan >> Subject: [6lowpan] MIPv6 and 6LoWPAN >> >> Hi, >> >> On a bit of a tangent... I have been studying different ways of dealing >> with mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide >> some mobility support for micro-mobility, which is good. Properly >> designed applications can also deal with IP addresses changing. But what >> if you would want to have a stable IP address for a 6LoWPAN node or a >> stable prefix for a whole LoWPAN? >> >> MIPv6 have several problems to be used directly by LoWPAN nodes, e.g.: >> - IP-in-IP encapsulation with the home agent >> - Security for binding management messages >> - Potentially large amounts of binding messages Is anyone aware of work >> on MIPv6 proxy mechanisms which would allow e.g. >> an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node? >> Maybe revive the Foreign Agent for IPv6? ;-) >> >> NEMO is much more clearly applicable to 6LoWPAN network mobility. The >> basic NEMO protocol is a perfect match, allowing an Edge Router or other >> router in the visited network to act as a Mobile Router and perform >> MIPv6 on behalf of the network. Thus maintaining constant prefixes for >> all LoWPANs under the router. I don't see route optimization to be >> necessary for NEMO used with 6LoWPAN, the performance of traffic going >> through the home agent should be fine. >> >> Thoughts? >> >> - 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. >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> >> ------------------------------ >> >> Message: 3 >> Date: Mon, 25 May 2009 23:41:08 +0900 >> From: Jong-Hyouk Lee >> Subject: Re: [6lowpan] MIPv6 and 6LoWPAN >> To: Zach Shelby , "Julien Abeille (jabeille)" >> >> Cc: 6lowpan <6lowpan@ietf.org> >> Message-ID: >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Hi, all. >> >> NEMO scenarios within PMIPv6 domain have been presented in the following >> document. >> >> http://tools.ietf.org/html/draft-jhlee-netlmm-nemo-scenarios-01 >> >> Hope you find useful scenarios for 6LowPAN. >> >> Cheers. >> >> On Mon, May 25, 2009 at 11:21 PM, Julien Abeille (jabeille) < >> jabeille@cisco.com> wrote: >> >>> Hi Zach, >>> >>> The issue with NEMO is that if nodes move from one router to another >>> (meaning the routers doing the nemo signaling), their address change. >>> NEMO is made to handle mobility of the whole network behind the router, >>> not individual nodes moving from this network to another. >>> >>> What you are probably looking for is Proxy Mobile IPv6 >>> (http://www.ietf.org/rfc/rfc5213.txt) and in general the work behing >>> done by the netlmm working group >>> (http://www.ietf.org/html.charters/netlmm-charter.html) and the netext >>> working group (http://www.ietf.org/html.charters/netext-charter.html). >>> >>> Best, >>> Julien >>> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> Behalf Of Zach Shelby >>> Sent: lundi 25 mai 2009 15:16 >>> To: 6lowpan >>> Subject: [6lowpan] MIPv6 and 6LoWPAN >>> >>> Hi, >>> >>> On a bit of a tangent... I have been studying different ways of dealing >>> with mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide >>> some mobility support for micro-mobility, which is good. Properly >>> designed applications can also deal with IP addresses changing. But what >>> if you would want to have a stable IP address for a 6LoWPAN node or a >>> stable prefix for a whole LoWPAN? >>> >>> MIPv6 have several problems to be used directly by LoWPAN nodes, e.g.: >>> - IP-in-IP encapsulation with the home agent >>> - Security for binding management messages >>> - Potentially large amounts of binding messages Is anyone aware of work >>> on MIPv6 proxy mechanisms which would allow e.g. >>> an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node? >>> Maybe revive the Foreign Agent for IPv6? ;-) >>> >>> NEMO is much more clearly applicable to 6LoWPAN network mobility. The >>> basic NEMO protocol is a perfect match, allowing an Edge Router or other >>> router in the visited network to act as a Mobile Router and perform >>> MIPv6 on behalf of the network. Thus maintaining constant prefixes for >>> all LoWPANs under the router. I don't see route optimization to be >>> necessary for NEMO used with 6LoWPAN, the performance of traffic going >>> through the home agent should be fine. >>> >>> Thoughts? >>> >>> - 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. >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> >> >> >> -- >> Internet Management Technology Lab, Sungkyunkwan University. >> Jong-Hyouk Lee. >> >> #email: jonghyouk (at) gmail (dot) com >> #webpage: http://hurryon.googlepages.com/ >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> >> ------------------------------ >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> >> End of 6lowpan Digest, Vol 52, Issue 18 >> *************************************** > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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. From pthubert@cisco.com Tue May 26 03:02: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 D0D8E3A68FF for <6lowpan@core3.amsl.com>; Tue, 26 May 2009 03:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.889 X-Spam-Level: X-Spam-Status: No, score=-9.889 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, URIBL_GREY=0.25] 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 u56Lg9lcf46X for <6lowpan@core3.amsl.com>; Tue, 26 May 2009 03:02:42 -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 23B003A67FB for <6lowpan@ietf.org>; Tue, 26 May 2009 03:02:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,250,1241395200"; d="scan'208";a="41332125" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 May 2009 10:04:21 +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 n4QA4LOk022905; Tue, 26 May 2009 12:04:21 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4QA4LHS026658; Tue, 26 May 2009 10:04:21 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 May 2009 12:04:21 +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, 26 May 2009 12:04:16 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0784B669@xmb-ams-337.emea.cisco.com> In-Reply-To: <4A1B08A7.7050201@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] MIPv6 and 6LoWPAN (Ricardo Silva) Thread-Index: AcndfOrbCKJWdgTrTESSbOwrYJ6/bwAawwpg References: <4A1B08A7.7050201@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "Ricardo Silva" X-OriginalArrivalTime: 26 May 2009 10:04:21.0437 (UTC) FILETIME=[570D2ED0:01C9DDE9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15240; t=1243332261; x=1244196261; 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]=20MIPv6=20and=206LoWPAN=20(Ri cardo=20Silva) |Sender:=20; bh=zRpVKlFvGNpUCMjPeu5bI9TPXr+mliI2qDZk4z6gUyA=; b=nUe7VlHIgDi5K+lQ+YxhInV3ed7IIZuWjn3jddF12QNIo7MLiAUMnUjCrr aI5i0fwIRObh2mXh8Vimnx928hzNppgSg5qUgdihnhhlx9MJu/q1OQgFwIim M76S3VrLdI; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "Charles E. Perkins" , 6lowpan@ietf.org Subject: Re: [6lowpan] MIPv6 and 6LoWPAN (Ricardo Silva) 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, 26 May 2009 10:02:43 -0000 Agreed all the way through, Also:=20 - we have to consider HA and edge router cohabitation on a same link, = since the 3775(bis) HA policy is not to give an address back without = proper defense when the node comes back home. IOW, the HA policy is that = the proxy wins against the real thing, a model that I pushed to change = in the revision but failed to this point. - I have trouble to see PMIP in route over when the LoWPAN routers are = actually very constrained as well, probably a lot more than a mobile = device such as a palmtop that would use the LoWPAN as last resort = communication medium. MIPv6 or NEMO seem a better fit in that case. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Zach Shelby >Sent: lundi 25 mai 2009 23:08 >To: Ricardo Silva >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] MIPv6 and 6LoWPAN (Ricardo Silva) > >Hi Ricardo, > >Thanks for reminding about your draft. A couple quick comments: > >- This model would require the edge routers to be aware of this "Micro >MIPv6" message format, and to provide the compression/decompression. >This means such a micro format would need separate standardization. > >- You should take draft-ietf-6lowpan-hc-05 (when posted) into account = as >it will provide next-header compression for extension headers including >some of the optimizations needed by your draft. > >You might want to consider PMIPv6 and NEMO in your next draft, and how >proxy methods could be used first and foremost to avoid LoWPAN nodes to >get involved with MIPv6 at all. > >PMIPv6 and NEMO don't solve the problem of node mobility between = domains >however, which would still require a LoWPAN node to speak MIPv6. > >Then again, it probably is just a reality that IPv6 addresses of LoWPAN >nodes will change upon inter-domain node mobility... and applications >will need to live with that. > >- Zach > >Ricardo Silva wrote: >> Dear All, >> >> I am sending our draft about mobility in lowPANs. It would be great = if >> you could send me your feedback. >> >> https://datatracker.ietf.org/drafts/draft-silva-6lowpan-mipv6/ >> >> Best regards, >> >> Ricardo Mend=E3o Silva >> >> Laboratory of Telecommunications and Telematic >> Department of Informatics Engineering >> University of Coimbra >> PORTUGAL >> >> >> On May 25, 2009, at 7:00 PM, 6lowpan-request@ietf.org >> wrote: >> >>> If you have received this digest without all the individual message >>> attachments you will need to update your digest options in your list >>> subscription. To do so, go to >>> >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>> MIME or Plain Text Digests?" to MIME. You can set this option >>> globally for all the list digests you receive at this point. >>> >>> >>> >>> Send 6lowpan mailing list submissions to >>> 6lowpan@ietf.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> or, via email, send a message with subject or body 'help' to >>> 6lowpan-request@ietf.org >>> >>> You can reach the person managing the list at >>> 6lowpan-owner@ietf.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of 6lowpan digest..." >>> >>> >>> Today's Topics: >>> >>> 1. MIPv6 and 6LoWPAN (Zach Shelby) >>> 2. Re: MIPv6 and 6LoWPAN (Julien Abeille (jabeille)) >>> 3. Re: MIPv6 and 6LoWPAN (Jong-Hyouk Lee) >>> >>> >>> = ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Mon, 25 May 2009 16:16:27 +0300 >>> From: Zach Shelby >>> Subject: [6lowpan] MIPv6 and 6LoWPAN >>> To: 6lowpan <6lowpan@ietf.org> >>> Message-ID: <4A1A9A2B.7060708@sensinode.com> >>> Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed >>> >>> Hi, >>> >>> On a bit of a tangent... I have been studying different ways of = dealing >>> with mobility of 6LoWPAN nodes and networks. Extended LoWPANs = provide >>> some mobility support for micro-mobility, which is good. Properly >>> designed applications can also deal with IP addresses changing. But = what >>> if you would want to have a stable IP address for a 6LoWPAN node or = a >>> stable prefix for a whole LoWPAN? >>> >>> MIPv6 have several problems to be used directly by LoWPAN nodes, = e.g.: >>> - IP-in-IP encapsulation with the home agent >>> - Security for binding management messages >>> - Potentially large amounts of binding messages >>> Is anyone aware of work on MIPv6 proxy mechanisms which would allow = e.g. >>> an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node? >>> Maybe revive the Foreign Agent for IPv6? ;-) >>> >>> NEMO is much more clearly applicable to 6LoWPAN network mobility. = The >>> basic NEMO protocol is a perfect match, allowing an Edge Router or = other >>> router in the visited network to act as a Mobile Router and perform >>> MIPv6 on behalf of the network. Thus maintaining constant prefixes = for >>> all LoWPANs under the router. I don't see route optimization to be >>> necessary for NEMO used with 6LoWPAN, the performance of traffic = going >>> through the home agent should be fine. >>> >>> Thoughts? >>> >>> - 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. >>> >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Mon, 25 May 2009 16:21:49 +0200 >>> From: "Julien Abeille (jabeille)" >>> Subject: Re: [6lowpan] MIPv6 and 6LoWPAN >>> To: "Zach Shelby" , "6lowpan" <6lowpan@ietf.org> >>> Message-ID: >>> = <38F26F36EAA981478A49D1F37F474A8603210E6F@xmb-ams-33d.emea.cisco.com> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi Zach, >>> >>> The issue with NEMO is that if nodes move from one router to another >>> (meaning the routers doing the nemo signaling), their address = change. >>> NEMO is made to handle mobility of the whole network behind the = router, >>> not individual nodes moving from this network to another. >>> >>> What you are probably looking for is Proxy Mobile IPv6 >>> (http://www.ietf.org/rfc/rfc5213.txt) and in general the work behing >>> done by the netlmm working group >>> (http://www.ietf.org/html.charters/netlmm-charter.html) and the = netext >>> working group = (http://www.ietf.org/html.charters/netext-charter.html). >>> >>> Best, >>> Julien >>> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> Behalf Of Zach Shelby >>> Sent: lundi 25 mai 2009 15:16 >>> To: 6lowpan >>> Subject: [6lowpan] MIPv6 and 6LoWPAN >>> >>> Hi, >>> >>> On a bit of a tangent... I have been studying different ways of = dealing >>> with mobility of 6LoWPAN nodes and networks. Extended LoWPANs = provide >>> some mobility support for micro-mobility, which is good. Properly >>> designed applications can also deal with IP addresses changing. But = what >>> if you would want to have a stable IP address for a 6LoWPAN node or = a >>> stable prefix for a whole LoWPAN? >>> >>> MIPv6 have several problems to be used directly by LoWPAN nodes, = e.g.: >>> - IP-in-IP encapsulation with the home agent >>> - Security for binding management messages >>> - Potentially large amounts of binding messages Is anyone aware of = work >>> on MIPv6 proxy mechanisms which would allow e.g. >>> an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node? >>> Maybe revive the Foreign Agent for IPv6? ;-) >>> >>> NEMO is much more clearly applicable to 6LoWPAN network mobility. = The >>> basic NEMO protocol is a perfect match, allowing an Edge Router or = other >>> router in the visited network to act as a Mobile Router and perform >>> MIPv6 on behalf of the network. Thus maintaining constant prefixes = for >>> all LoWPANs under the router. I don't see route optimization to be >>> necessary for NEMO used with 6LoWPAN, the performance of traffic = going >>> through the home agent should be fine. >>> >>> Thoughts? >>> >>> - 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. >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> >>> ------------------------------ >>> >>> Message: 3 >>> Date: Mon, 25 May 2009 23:41:08 +0900 >>> From: Jong-Hyouk Lee >>> Subject: Re: [6lowpan] MIPv6 and 6LoWPAN >>> To: Zach Shelby , "Julien Abeille (jabeille)" >>> >>> Cc: 6lowpan <6lowpan@ietf.org> >>> Message-ID: >>> >>> Content-Type: text/plain; charset=3D"iso-8859-1" >>> >>> Hi, all. >>> >>> NEMO scenarios within PMIPv6 domain have been presented in the = following >>> document. >>> >>> http://tools.ietf.org/html/draft-jhlee-netlmm-nemo-scenarios-01 >>> >>> Hope you find useful scenarios for 6LowPAN. >>> >>> Cheers. >>> >>> On Mon, May 25, 2009 at 11:21 PM, Julien Abeille (jabeille) < >>> jabeille@cisco.com> wrote: >>> >>>> Hi Zach, >>>> >>>> The issue with NEMO is that if nodes move from one router to = another >>>> (meaning the routers doing the nemo signaling), their address = change. >>>> NEMO is made to handle mobility of the whole network behind the = router, >>>> not individual nodes moving from this network to another. >>>> >>>> What you are probably looking for is Proxy Mobile IPv6 >>>> (http://www.ietf.org/rfc/rfc5213.txt) and in general the work = behing >>>> done by the netlmm working group >>>> (http://www.ietf.org/html.charters/netlmm-charter.html) and the = netext >>>> working group = (http://www.ietf.org/html.charters/netext-charter.html). >>>> >>>> Best, >>>> Julien >>>> >>>> -----Original Message----- >>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>>> Behalf Of Zach Shelby >>>> Sent: lundi 25 mai 2009 15:16 >>>> To: 6lowpan >>>> Subject: [6lowpan] MIPv6 and 6LoWPAN >>>> >>>> Hi, >>>> >>>> On a bit of a tangent... I have been studying different ways of = dealing >>>> with mobility of 6LoWPAN nodes and networks. Extended LoWPANs = provide >>>> some mobility support for micro-mobility, which is good. Properly >>>> designed applications can also deal with IP addresses changing. But = what >>>> if you would want to have a stable IP address for a 6LoWPAN node or = a >>>> stable prefix for a whole LoWPAN? >>>> >>>> MIPv6 have several problems to be used directly by LoWPAN nodes, = e.g.: >>>> - IP-in-IP encapsulation with the home agent >>>> - Security for binding management messages >>>> - Potentially large amounts of binding messages Is anyone aware of = work >>>> on MIPv6 proxy mechanisms which would allow e.g. >>>> an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN = node? >>>> Maybe revive the Foreign Agent for IPv6? ;-) >>>> >>>> NEMO is much more clearly applicable to 6LoWPAN network mobility. = The >>>> basic NEMO protocol is a perfect match, allowing an Edge Router or = other >>>> router in the visited network to act as a Mobile Router and perform >>>> MIPv6 on behalf of the network. Thus maintaining constant prefixes = for >>>> all LoWPANs under the router. I don't see route optimization to be >>>> necessary for NEMO used with 6LoWPAN, the performance of traffic = going >>>> through the home agent should be fine. >>>> >>>> Thoughts? >>>> >>>> - 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. >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>> >>> >>> >>> -- >>> Internet Management Technology Lab, Sungkyunkwan University. >>> Jong-Hyouk Lee. >>> >>> #email: jonghyouk (at) gmail (dot) com >>> #webpage: http://hurryon.googlepages.com/ >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> = >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> >>> End of 6lowpan Digest, Vol 52, Issue 18 >>> *************************************** >> >> >> >> >> >> >> = ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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. >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Tue May 26 03:05:10 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 45FA63A706B for <6lowpan@core3.amsl.com>; Tue, 26 May 2009 03:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.903 X-Spam-Level: X-Spam-Status: No, score=-9.903 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, URIBL_GREY=0.25] 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 WJQDrrSh6egK for <6lowpan@core3.amsl.com>; Tue, 26 May 2009 03:05:08 -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 9B7B43A705A for <6lowpan@ietf.org>; Tue, 26 May 2009 03:05:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,250,1241395200"; d="scan'208";a="41332541" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 May 2009 10:06:48 +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 n4QA6mYL032291; Tue, 26 May 2009 12:06:48 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4QA6mCv027777; Tue, 26 May 2009 10:06:48 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 May 2009 12:06:48 +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, 26 May 2009 12:06:43 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0784B66F@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] MIPv6 and 6LoWPAN (Ricardo Silva) Thread-Index: AcndfOrbCKJWdgTrTESSbOwrYJ6/bwAawwpgAABn2LA= References: <4A1B08A7.7050201@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "Ricardo Silva" X-OriginalArrivalTime: 26 May 2009 10:06:48.0109 (UTC) FILETIME=[AE798DD0:01C9DDE9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16085; t=1243332408; x=1244196408; 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]=20MIPv6=20and=206LoWPAN=20(Ri cardo=20Silva) |Sender:=20; bh=vhRAT2a5yHI4yvRZlf24mvG6/tQYZg9TZ356zkFKWv8=; b=xDodqDECRP7nfyMKsCA32Bkc7YfHvzDL433SyaJAlcR8YQaV85vcv52JS/ LdZwuaIBz4CEdOBvQ/Ycj+0fOhzGZ+9/VQIE2DAqDhOfqYAGqy1LTpKfxbUs nTCQyYfEAV; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "Charles E. Perkins" , 6lowpan@ietf.org Subject: Re: [6lowpan] MIPv6 and 6LoWPAN (Ricardo Silva) 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, 26 May 2009 10:05:10 -0000 For those interested in the proxy conflict issue between an edge router = and a HA, please follow this link: http://trac.tools.ietf.org/wg/mext/trac/ticket/16=20 Pascal >-----Original Message----- >From: Pascal Thubert (pthubert) >Sent: mardi 26 mai 2009 12:04 >To: 'Zach Shelby'; Ricardo Silva >Cc: 6lowpan@ietf.org; 'Charles E. Perkins' >Subject: RE: [6lowpan] MIPv6 and 6LoWPAN (Ricardo Silva) > >Agreed all the way through, > >Also: > >- we have to consider HA and edge router cohabitation on a same link, = since the 3775(bis) HA policy is not to >give an address back without proper defense when the node comes back = home. IOW, the HA policy is that the >proxy wins against the real thing, a model that I pushed to change in = the revision but failed to this point. > >- I have trouble to see PMIP in route over when the LoWPAN routers are = actually very constrained as well, >probably a lot more than a mobile device such as a palmtop that would = use the LoWPAN as last resort >communication medium. MIPv6 or NEMO seem a better fit in that case. > >Pascal > >>-----Original Message----- >>From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Zach Shelby >>Sent: lundi 25 mai 2009 23:08 >>To: Ricardo Silva >>Cc: 6lowpan@ietf.org >>Subject: Re: [6lowpan] MIPv6 and 6LoWPAN (Ricardo Silva) >> >>Hi Ricardo, >> >>Thanks for reminding about your draft. A couple quick comments: >> >>- This model would require the edge routers to be aware of this "Micro >>MIPv6" message format, and to provide the compression/decompression. >>This means such a micro format would need separate standardization. >> >>- You should take draft-ietf-6lowpan-hc-05 (when posted) into account = as >>it will provide next-header compression for extension headers = including >>some of the optimizations needed by your draft. >> >>You might want to consider PMIPv6 and NEMO in your next draft, and how >>proxy methods could be used first and foremost to avoid LoWPAN nodes = to >>get involved with MIPv6 at all. >> >>PMIPv6 and NEMO don't solve the problem of node mobility between = domains >>however, which would still require a LoWPAN node to speak MIPv6. >> >>Then again, it probably is just a reality that IPv6 addresses of = LoWPAN >>nodes will change upon inter-domain node mobility... and applications >>will need to live with that. >> >>- Zach >> >>Ricardo Silva wrote: >>> Dear All, >>> >>> I am sending our draft about mobility in lowPANs. It would be great = if >>> you could send me your feedback. >>> >>> https://datatracker.ietf.org/drafts/draft-silva-6lowpan-mipv6/ >>> >>> Best regards, >>> >>> Ricardo Mend=E3o Silva >>> >>> Laboratory of Telecommunications and Telematic >>> Department of Informatics Engineering >>> University of Coimbra >>> PORTUGAL >>> >>> >>> On May 25, 2009, at 7:00 PM, 6lowpan-request@ietf.org >>> wrote: >>> >>>> If you have received this digest without all the individual message >>>> attachments you will need to update your digest options in your = list >>>> subscription. To do so, go to >>>> >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>>> Click the 'Unsubscribe or edit options' button, log in, and set = "Get >>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>> globally for all the list digests you receive at this point. >>>> >>>> >>>> >>>> Send 6lowpan mailing list submissions to >>>> 6lowpan@ietf.org >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> or, via email, send a message with subject or body 'help' to >>>> 6lowpan-request@ietf.org >>>> >>>> You can reach the person managing the list at >>>> 6lowpan-owner@ietf.org >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of 6lowpan digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. MIPv6 and 6LoWPAN (Zach Shelby) >>>> 2. Re: MIPv6 and 6LoWPAN (Julien Abeille (jabeille)) >>>> 3. Re: MIPv6 and 6LoWPAN (Jong-Hyouk Lee) >>>> >>>> >>>> = ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Mon, 25 May 2009 16:16:27 +0300 >>>> From: Zach Shelby >>>> Subject: [6lowpan] MIPv6 and 6LoWPAN >>>> To: 6lowpan <6lowpan@ietf.org> >>>> Message-ID: <4A1A9A2B.7060708@sensinode.com> >>>> Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed >>>> >>>> Hi, >>>> >>>> On a bit of a tangent... I have been studying different ways of = dealing >>>> with mobility of 6LoWPAN nodes and networks. Extended LoWPANs = provide >>>> some mobility support for micro-mobility, which is good. Properly >>>> designed applications can also deal with IP addresses changing. But = what >>>> if you would want to have a stable IP address for a 6LoWPAN node or = a >>>> stable prefix for a whole LoWPAN? >>>> >>>> MIPv6 have several problems to be used directly by LoWPAN nodes, = e.g.: >>>> - IP-in-IP encapsulation with the home agent >>>> - Security for binding management messages >>>> - Potentially large amounts of binding messages >>>> Is anyone aware of work on MIPv6 proxy mechanisms which would allow = e.g. >>>> an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN = node? >>>> Maybe revive the Foreign Agent for IPv6? ;-) >>>> >>>> NEMO is much more clearly applicable to 6LoWPAN network mobility. = The >>>> basic NEMO protocol is a perfect match, allowing an Edge Router or = other >>>> router in the visited network to act as a Mobile Router and perform >>>> MIPv6 on behalf of the network. Thus maintaining constant prefixes = for >>>> all LoWPANs under the router. I don't see route optimization to be >>>> necessary for NEMO used with 6LoWPAN, the performance of traffic = going >>>> through the home agent should be fine. >>>> >>>> Thoughts? >>>> >>>> - 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. >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 2 >>>> Date: Mon, 25 May 2009 16:21:49 +0200 >>>> From: "Julien Abeille (jabeille)" >>>> Subject: Re: [6lowpan] MIPv6 and 6LoWPAN >>>> To: "Zach Shelby" , "6lowpan" = <6lowpan@ietf.org> >>>> Message-ID: >>>> = <38F26F36EAA981478A49D1F37F474A8603210E6F@xmb-ams-33d.emea.cisco.com> >>>> Content-Type: text/plain; charset=3D"us-ascii" >>>> >>>> Hi Zach, >>>> >>>> The issue with NEMO is that if nodes move from one router to = another >>>> (meaning the routers doing the nemo signaling), their address = change. >>>> NEMO is made to handle mobility of the whole network behind the = router, >>>> not individual nodes moving from this network to another. >>>> >>>> What you are probably looking for is Proxy Mobile IPv6 >>>> (http://www.ietf.org/rfc/rfc5213.txt) and in general the work = behing >>>> done by the netlmm working group >>>> (http://www.ietf.org/html.charters/netlmm-charter.html) and the = netext >>>> working group = (http://www.ietf.org/html.charters/netext-charter.html). >>>> >>>> Best, >>>> Julien >>>> >>>> -----Original Message----- >>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>>> Behalf Of Zach Shelby >>>> Sent: lundi 25 mai 2009 15:16 >>>> To: 6lowpan >>>> Subject: [6lowpan] MIPv6 and 6LoWPAN >>>> >>>> Hi, >>>> >>>> On a bit of a tangent... I have been studying different ways of = dealing >>>> with mobility of 6LoWPAN nodes and networks. Extended LoWPANs = provide >>>> some mobility support for micro-mobility, which is good. Properly >>>> designed applications can also deal with IP addresses changing. But = what >>>> if you would want to have a stable IP address for a 6LoWPAN node or = a >>>> stable prefix for a whole LoWPAN? >>>> >>>> MIPv6 have several problems to be used directly by LoWPAN nodes, = e.g.: >>>> - IP-in-IP encapsulation with the home agent >>>> - Security for binding management messages >>>> - Potentially large amounts of binding messages Is anyone aware of = work >>>> on MIPv6 proxy mechanisms which would allow e.g. >>>> an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN = node? >>>> Maybe revive the Foreign Agent for IPv6? ;-) >>>> >>>> NEMO is much more clearly applicable to 6LoWPAN network mobility. = The >>>> basic NEMO protocol is a perfect match, allowing an Edge Router or = other >>>> router in the visited network to act as a Mobile Router and perform >>>> MIPv6 on behalf of the network. Thus maintaining constant prefixes = for >>>> all LoWPANs under the router. I don't see route optimization to be >>>> necessary for NEMO used with 6LoWPAN, the performance of traffic = going >>>> through the home agent should be fine. >>>> >>>> Thoughts? >>>> >>>> - 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. >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 3 >>>> Date: Mon, 25 May 2009 23:41:08 +0900 >>>> From: Jong-Hyouk Lee >>>> Subject: Re: [6lowpan] MIPv6 and 6LoWPAN >>>> To: Zach Shelby , "Julien Abeille (jabeille)" >>>> >>>> Cc: 6lowpan <6lowpan@ietf.org> >>>> Message-ID: >>>> >>>> Content-Type: text/plain; charset=3D"iso-8859-1" >>>> >>>> Hi, all. >>>> >>>> NEMO scenarios within PMIPv6 domain have been presented in the = following >>>> document. >>>> >>>> http://tools.ietf.org/html/draft-jhlee-netlmm-nemo-scenarios-01 >>>> >>>> Hope you find useful scenarios for 6LowPAN. >>>> >>>> Cheers. >>>> >>>> On Mon, May 25, 2009 at 11:21 PM, Julien Abeille (jabeille) < >>>> jabeille@cisco.com> wrote: >>>> >>>>> Hi Zach, >>>>> >>>>> The issue with NEMO is that if nodes move from one router to = another >>>>> (meaning the routers doing the nemo signaling), their address = change. >>>>> NEMO is made to handle mobility of the whole network behind the = router, >>>>> not individual nodes moving from this network to another. >>>>> >>>>> What you are probably looking for is Proxy Mobile IPv6 >>>>> (http://www.ietf.org/rfc/rfc5213.txt) and in general the work = behing >>>>> done by the netlmm working group >>>>> (http://www.ietf.org/html.charters/netlmm-charter.html) and the = netext >>>>> working group = (http://www.ietf.org/html.charters/netext-charter.html). >>>>> >>>>> Best, >>>>> Julien >>>>> >>>>> -----Original Message----- >>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] = On >>>>> Behalf Of Zach Shelby >>>>> Sent: lundi 25 mai 2009 15:16 >>>>> To: 6lowpan >>>>> Subject: [6lowpan] MIPv6 and 6LoWPAN >>>>> >>>>> Hi, >>>>> >>>>> On a bit of a tangent... I have been studying different ways of = dealing >>>>> with mobility of 6LoWPAN nodes and networks. Extended LoWPANs = provide >>>>> some mobility support for micro-mobility, which is good. Properly >>>>> designed applications can also deal with IP addresses changing. = But what >>>>> if you would want to have a stable IP address for a 6LoWPAN node = or a >>>>> stable prefix for a whole LoWPAN? >>>>> >>>>> MIPv6 have several problems to be used directly by LoWPAN nodes, = e.g.: >>>>> - IP-in-IP encapsulation with the home agent >>>>> - Security for binding management messages >>>>> - Potentially large amounts of binding messages Is anyone aware of = work >>>>> on MIPv6 proxy mechanisms which would allow e.g. >>>>> an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN = node? >>>>> Maybe revive the Foreign Agent for IPv6? ;-) >>>>> >>>>> NEMO is much more clearly applicable to 6LoWPAN network mobility. = The >>>>> basic NEMO protocol is a perfect match, allowing an Edge Router or = other >>>>> router in the visited network to act as a Mobile Router and = perform >>>>> MIPv6 on behalf of the network. Thus maintaining constant prefixes = for >>>>> all LoWPANs under the router. I don't see route optimization to be >>>>> necessary for NEMO used with 6LoWPAN, the performance of traffic = going >>>>> through the home agent should be fine. >>>>> >>>>> Thoughts? >>>>> >>>>> - 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. >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>> >>>> >>>> >>>> >>>> -- >>>> Internet Management Technology Lab, Sungkyunkwan University. >>>> Jong-Hyouk Lee. >>>> >>>> #email: jonghyouk (at) gmail (dot) com >>>> #webpage: http://hurryon.googlepages.com/ >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: >>>> = >>>> >>>> ------------------------------ >>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>>> >>>> End of 6lowpan Digest, Vol 52, Issue 18 >>>> *************************************** >>> >>> >>> >>> >>> >>> >>> = ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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. >>_______________________________________________ >>6lowpan mailing list >>6lowpan@ietf.org >>https://www.ietf.org/mailman/listinfo/6lowpan From alexandru.petrescu@gmail.com Tue May 26 04:03: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 12B753A6B74 for <6lowpan@core3.amsl.com>; Tue, 26 May 2009 04:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, 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 woE4xpSFY3lT for <6lowpan@core3.amsl.com>; Tue, 26 May 2009 04:03:26 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 0760E3A6987 for <6lowpan@ietf.org>; Tue, 26 May 2009 04:03:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4QB56Q0024965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 May 2009 13:05:06 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4QB55Fd013881; Tue, 26 May 2009 13:05:05 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n4QB55Rt025969; Tue, 26 May 2009 13:05:05 +0200 Message-ID: <4A1BCCE1.9030100@gmail.com> Date: Tue, 26 May 2009 13:05:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <4A1A9A2B.7060708@sensinode.com> In-Reply-To: <4A1A9A2B.7060708@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] MIPv6 and 6LoWPAN 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, 26 May 2009 11:03:27 -0000 Hi Zach, Right, a good conceptual place to put a Mobile IPv6-based NEMO Mobile Router is the Edge Router. However, the Edge Router (Border Router?) isn't supposed to move. There are other concepts in the NEMO-MANET interaction space that could be interesting for LoWPAN ER. For example, if each ER informed the other ER about the prefix it holds on its sensor link, then the other ERs could reach these sensors. This was proposed for example for egress-egress interactions of Mobile Routers, using ICMP RA. It could probably be OSPF instead. Also, probably, it could make sense to have one sensor-node MR to move from under one ER (move together with some of its smaller sensornode LFNs) to another ER, and consider the old ER to be its Home Agent, and execute Mobile IPv6-based NEMO protocol extensions. In this sense, the ER wouldn't be an IPv6-based FA, but a HA. About PMIPv6: obviously PMIPv6 would apply in a sense, but first is ER supposed to be the PMIPv6 MAG or the PMIPv6 LMA? (PMIPv6 design works in a way as NEMO does, in that PMIPv6 MAG updates a prefix on PMIPv6 LMA, just as NEMO MR updates a prefix on NEMO HA). Alex Zach Shelby a écrit : > Hi, > > On a bit of a tangent... I have been studying different ways of > dealing with mobility of 6LoWPAN nodes and networks. Extended LoWPANs > provide some mobility support for micro-mobility, which is good. > Properly designed applications can also deal with IP addresses > changing. But what if you would want to have a stable IP address for > a 6LoWPAN node or a stable prefix for a whole LoWPAN? > > MIPv6 have several problems to be used directly by LoWPAN nodes, > e.g.: - IP-in-IP encapsulation with the home agent - Security for > binding management messages - Potentially large amounts of binding > messages Is anyone aware of work on MIPv6 proxy mechanisms which > would allow e.g. an Edge Router to proxy MIPv6 operations on behalf > of a LoWPAN node? Maybe revive the Foreign Agent for IPv6? ;-) > > NEMO is much more clearly applicable to 6LoWPAN network mobility. The > basic NEMO protocol is a perfect match, allowing an Edge Router or > other router in the visited network to act as a Mobile Router and > perform MIPv6 on behalf of the network. Thus maintaining constant > prefixes for all LoWPANs under the router. I don't see route > optimization to be necessary for NEMO used with 6LoWPAN, the > performance of traffic going through the home agent should be fine. > > Thoughts? > > - Zach > From jabeille@cisco.com Tue May 26 07:23: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 039C828C22C for <6lowpan@core3.amsl.com>; Tue, 26 May 2009 07:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.061 X-Spam-Level: X-Spam-Status: No, score=-10.061 tagged_above=-999 required=5 tests=[AWL=0.538, 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 2tiWphZatspM for <6lowpan@core3.amsl.com>; Tue, 26 May 2009 07:23:15 -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 9AC8828C206 for <6lowpan@ietf.org>; Tue, 26 May 2009 07:23:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,251,1241395200"; d="scan'208";a="41370320" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 May 2009 14:23:19 +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 n4QENJJD026725; Tue, 26 May 2009 16:23:19 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4QENJi1011579; Tue, 26 May 2009 14:23:19 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 May 2009 16:23:19 +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, 26 May 2009 16:23:17 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86032113B1@xmb-ams-33d.emea.cisco.com> In-Reply-To: <4A1BCCE1.9030100@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] MIPv6 and 6LoWPAN Thread-Index: Acnd8eDNCNbgNrveT12f71rnzS9tIgAGow6A References: <4A1A9A2B.7060708@sensinode.com> <4A1BCCE1.9030100@gmail.com> From: "Julien Abeille (jabeille)" To: "Alexandru Petrescu" , "Zach Shelby" X-OriginalArrivalTime: 26 May 2009 14:23:19.0533 (UTC) FILETIME=[847A79D0:01C9DE0D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3439; t=1243347799; x=1244211799; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[6lowpan]=20MIPv6=20and=206LoWPAN |Sender:=20; bh=rbP1kT2xPpxZNJtSW5FvcvOqYfKWQii0GDtoxethuYs=; b=mg9ZfVqZWsnutkFJeC2y8qKdiQaftzj/UCd1l0Ch2mekv7ElRJLaS8KVUa QVvwWaL/fwc6vCRaJP8d8oy7CoTox6THL4/g00KunuR39Lv/GuBwZ8//cr/G Abd4vkfEGu; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] MIPv6 and 6LoWPAN 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, 26 May 2009 14:23:16 -0000 Hi all, -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Alexandru Petrescu Sent: mardi 26 mai 2009 13:05 To: Zach Shelby Cc: 6lowpan Subject: Re: [6lowpan] MIPv6 and 6LoWPAN Hi Zach, Right, a good conceptual place to put a Mobile IPv6-based NEMO Mobile = Router is the Edge Router. However, the Edge Router (Border Router?) = isn't supposed to move. There are other concepts in the NEMO-MANET interaction space that could = be interesting for LoWPAN ER. For example, if each ER informed the = other ER about the prefix it holds on its sensor link, then the other = ERs could reach these sensors. This was proposed for example for = egress-egress interactions of Mobile Routers, using ICMP RA. It could = probably be OSPF instead. Also, probably, it could make sense to have one sensor-node MR to move = from under one ER (move together with some of its smaller sensornode LFNs) to another ER, and consider the old ER to be its Home Agent, and = execute Mobile IPv6-based NEMO protocol extensions. In this sense, the = ER wouldn't be an IPv6-based FA, but a HA. About PMIPv6: obviously PMIPv6 would apply in a sense, but first is ER = supposed to be the PMIPv6 MAG or the PMIPv6 LMA? [Julien] In my opinion ER would be a MAG. As Pascal mentionned, this = works pretty well in a mesh under scenario, not route over. I would = think MIPv6 applies in the route over case. I do not see yet what NEMO = would bring. (PMIPv6 design works in a way as NEMO does, in that PMIPv6 MAG updates a = prefix on PMIPv6 LMA, just as NEMO MR updates a prefix on NEMO HA). [Julien] I agree, but in NEMO by default the MR moves, and the nodes on = the ingress interface don't. In PMIPv6 the MAG does not move, and the = nodes on the ingress do. Best, Julien Alex Zach Shelby a =E9crit : > Hi, >=20 > On a bit of a tangent... I have been studying different ways of=20 > dealing with mobility of 6LoWPAN nodes and networks. Extended LoWPANs = > provide some mobility support for micro-mobility, which is good. > Properly designed applications can also deal with IP addresses=20 > changing. But what if you would want to have a stable IP address for a = > 6LoWPAN node or a stable prefix for a whole LoWPAN? >=20 > MIPv6 have several problems to be used directly by LoWPAN nodes, > e.g.: - IP-in-IP encapsulation with the home agent - Security for=20 > binding management messages - Potentially large amounts of binding=20 > messages Is anyone aware of work on MIPv6 proxy mechanisms which would = > allow e.g. an Edge Router to proxy MIPv6 operations on behalf of a=20 > LoWPAN node? Maybe revive the Foreign Agent for IPv6? ;-) >=20 > NEMO is much more clearly applicable to 6LoWPAN network mobility. The = > basic NEMO protocol is a perfect match, allowing an Edge Router or=20 > other router in the visited network to act as a Mobile Router and=20 > perform MIPv6 on behalf of the network. Thus maintaining constant=20 > prefixes for all LoWPANs under the router. I don't see route=20 > optimization to be necessary for NEMO used with 6LoWPAN, the=20 > performance of traffic going through the home agent should be fine. >=20 > Thoughts? >=20 > - Zach >=20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From zach@sensinode.com Tue May 26 14:26: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 387273A6B0A for <6lowpan@core3.amsl.com>; Tue, 26 May 2009 14:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 Ooy9CmuoJ-aD for <6lowpan@core3.amsl.com>; Tue, 26 May 2009 14:26:16 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8F5BA3A6B37 for <6lowpan@ietf.org>; Tue, 26 May 2009 14:25:50 -0700 (PDT) Received: from snl-zach.local ([81.253.14.224]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n4QLREfi011034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 00:27:15 +0300 Message-ID: <4A1C5DBC.9040105@sensinode.com> Date: Tue, 26 May 2009 23:23:08 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Julien Abeille (jabeille)" References: <4A1A9A2B.7060708@sensinode.com> <4A1BCCE1.9030100@gmail.com> <38F26F36EAA981478A49D1F37F474A86032113B1@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86032113B1@xmb-ams-33d.emea.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] MIPv6 and 6LoWPAN 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, 26 May 2009 21:26:18 -0000 Hi, Thanks for all the pointers. I'll need some time think and come back to this much later. After hanging out with Pascal today in Sophia we actually have a solution for this - after HC and ND are through first. Julien Abeille (jabeille) wrote: > Hi all, > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: mardi 26 mai 2009 13:05 > To: Zach Shelby > Cc: 6lowpan > Subject: Re: [6lowpan] MIPv6 and 6LoWPAN > > Hi Zach, > > Right, a good conceptual place to put a Mobile IPv6-based NEMO Mobile Router is the Edge Router. However, the Edge Router (Border Router?) isn't supposed to move. > > There are other concepts in the NEMO-MANET interaction space that could be interesting for LoWPAN ER. For example, if each ER informed the other ER about the prefix it holds on its sensor link, then the other ERs could reach these sensors. This was proposed for example for egress-egress interactions of Mobile Routers, using ICMP RA. It could probably be OSPF instead. > > Also, probably, it could make sense to have one sensor-node MR to move from under one ER (move together with some of its smaller sensornode > LFNs) to another ER, and consider the old ER to be its Home Agent, and execute Mobile IPv6-based NEMO protocol extensions. In this sense, the ER wouldn't be an IPv6-based FA, but a HA. > > About PMIPv6: obviously PMIPv6 would apply in a sense, but first is ER supposed to be the PMIPv6 MAG or the PMIPv6 LMA? > [Julien] In my opinion ER would be a MAG. As Pascal mentionned, this works pretty well in a mesh under scenario, not route over. I would think MIPv6 applies in the route over case. I do not see yet what NEMO would bring. Agreed. After looking into the dirty details of PMIPv6 - it is really not suitable for 6lowpan as is, espcially for route over. > (PMIPv6 design works in a way as NEMO does, in that PMIPv6 MAG updates a prefix on PMIPv6 LMA, just as NEMO MR updates a prefix on NEMO HA). > [Julien] I agree, but in NEMO by default the MR moves, and the nodes on the ingress interface don't. In PMIPv6 the MAG does not move, and the nodes on the ingress do. Exactly - they are for two different purposes clearly. Edge routers definitely can move, and whole LoWPANs of course, look at body sensor networks for example. Here NEMO is perfect. Pascal pointed out the work on Proxy Home Agents and GlobalHaHa, which may really make MIPv6 suitable for LoWPAN nodes. This is something to consider in the future at least - seems to have the best potential for node mobility. Anyways - we're not chartered for this now - but wink, wink - when rechartering some day this is an interesting topic. > Best, > Julien > > Alex > > > Zach Shelby a écrit : >> Hi, >> >> On a bit of a tangent... I have been studying different ways of >> dealing with mobility of 6LoWPAN nodes and networks. Extended LoWPANs >> provide some mobility support for micro-mobility, which is good. >> Properly designed applications can also deal with IP addresses >> changing. But what if you would want to have a stable IP address for a >> 6LoWPAN node or a stable prefix for a whole LoWPAN? >> >> MIPv6 have several problems to be used directly by LoWPAN nodes, >> e.g.: - IP-in-IP encapsulation with the home agent - Security for >> binding management messages - Potentially large amounts of binding >> messages Is anyone aware of work on MIPv6 proxy mechanisms which would >> allow e.g. an Edge Router to proxy MIPv6 operations on behalf of a >> LoWPAN node? Maybe revive the Foreign Agent for IPv6? ;-) >> >> NEMO is much more clearly applicable to 6LoWPAN network mobility. The >> basic NEMO protocol is a perfect match, allowing an Edge Router or >> other router in the visited network to act as a Mobile Router and >> perform MIPv6 on behalf of the network. Thus maintaining constant >> prefixes for all LoWPANs under the router. I don't see route >> optimization to be necessary for NEMO used with 6LoWPAN, the >> performance of traffic going through the home agent should be fine. >> >> Thoughts? >> >> - Zach >> > > > _______________________________________________ > 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. From trac@tools.ietf.org Wed May 27 15:36: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 0E16A3A6F2B for <6lowpan@core3.amsl.com>; Wed, 27 May 2009 15:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.788 X-Spam-Level: X-Spam-Status: No, score=-101.788 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 np2ZMrJRTsDA for <6lowpan@core3.amsl.com>; Wed, 27 May 2009 15:36:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (lptools1.amsl.com [64.170.98.42]) by core3.amsl.com (Postfix) with ESMTP id 04AAE3A6D52 for <6lowpan@ietf.org>; Wed, 27 May 2009 15:36:03 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1M9Rkl-0006DR-Iq; Wed, 27 May 2009 15:37: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: cabo@tzi.org, zach@sensinode.com X-Trac-Project: 6lowpan Date: Wed, 27 May 2009 22:37:43 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/25#comment:1 Message-ID: <069.5c7b09470f36bfb4506442cbe6de5799@tools.ietf.org> References: <060.6d06a810fbf0896efb35b9109dae4f1f@tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <060.6d06a810fbf0896efb35b9109dae4f1f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 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] #25: Choosing the best default router 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: Wed, 27 May 2009 22:36:16 -0000 #25: Choosing the best default router --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: cabo@tzi.org Type: defect | 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 -03 -- Ticket URL: 6lowpan From trac@tools.ietf.org Wed May 27 15:36: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 64EBE3A6A04 for <6lowpan@core3.amsl.com>; Wed, 27 May 2009 15:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.777 X-Spam-Level: X-Spam-Status: No, score=-101.777 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 BFUv3nOvV-2r for <6lowpan@core3.amsl.com>; Wed, 27 May 2009 15:36:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (lptools1.amsl.com [64.170.98.42]) by core3.amsl.com (Postfix) with ESMTP id BD3E93A69DE for <6lowpan@ietf.org>; Wed, 27 May 2009 15:36:44 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1M9RlT-0006EG-OC; Wed, 27 May 2009 15:38:27 -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: Wed, 27 May 2009 22:38:27 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/21#comment:1 Message-ID: <069.aec6536b0be70b92201d91141dcc8def@tools.ietf.org> References: <060.1df5119d7fc43511ab21b5dc22b830b9@tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <060.1df5119d7fc43511ab21b5dc22b830b9@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] #21: Architecture section 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: Wed, 27 May 2009 22:36:45 -0000 #21: Architecture section --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: wontfix Keywords: | --------------------------------+------------------------------------------- Changes (by zach@sensinode.com): * status: new => closed * resolution: => wontfix Comment: Not needed. 6lowpan general terminology and ND terminology seperated in nd-03. -- Ticket URL: 6lowpan From trac@tools.ietf.org Wed May 27 15:37: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 D8B263A70AA for <6lowpan@core3.amsl.com>; Wed, 27 May 2009 15:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.768 X-Spam-Level: X-Spam-Status: No, score=-101.768 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 Wod50tx8+x8d for <6lowpan@core3.amsl.com>; Wed, 27 May 2009 15:37:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (lptools1.amsl.com [64.170.98.42]) by core3.amsl.com (Postfix) with ESMTP id 3A43C3A69DE for <6lowpan@ietf.org>; Wed, 27 May 2009 15:37:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1M9RmB-0006Eg-7B; Wed, 27 May 2009 15:39:11 -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: Wed, 27 May 2009 22:39:11 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/28#comment:3 Message-ID: <069.db31e2a42c1c5c42565e4bf91802784d@tools.ietf.org> References: <060.747b6537afa1abc34317989d768ebb7c@tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <060.747b6537afa1abc34317989d768ebb7c@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] #28: Edge Router -> Border Router 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: Wed, 27 May 2009 22:37:28 -0000 #28: Edge Router -> Border Router --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: enhancement | Status: closed Priority: trivial | Milestone: Component: nd | Version: Severity: - | Resolution: wontfix Keywords: | --------------------------------+------------------------------------------- Changes (by zach@sensinode.com): * status: new => closed * resolution: => wontfix Comment: Doesn't seem to be WG consensus on this. Leave ER for now. -- Ticket URL: 6lowpan From trac@tools.ietf.org Wed May 27 15:37: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 B5CAA3A714D for <6lowpan@core3.amsl.com>; Wed, 27 May 2009 15:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.76 X-Spam-Level: X-Spam-Status: No, score=-101.76 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 0FJ3wo0wGKvr for <6lowpan@core3.amsl.com>; Wed, 27 May 2009 15:37:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (lptools1.amsl.com [64.170.98.42]) by core3.amsl.com (Postfix) with ESMTP id 1ED4A3A7147 for <6lowpan@ietf.org>; Wed, 27 May 2009 15:37:47 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1M9RmU-0006Er-3c; Wed, 27 May 2009 15:39: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: Wed, 27 May 2009 22:39:30 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/29#comment:1 Message-ID: <069.14419aeaf7485f76147f91478d019a4f@tools.ietf.org> References: <060.cfa4b56df84bee3ff225beae78109017@tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <060.cfa4b56df84bee3ff225beae78109017@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] #29: Whiteboard examples 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: Wed, 27 May 2009 22:37:47 -0000 #29: Whiteboard examples --------------------------------+------------------------------------------- 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-03 -- Ticket URL: 6lowpan From zach@sensinode.com Wed May 27 15:53: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 9D68728C2A7 for <6lowpan@core3.amsl.com>; Wed, 27 May 2009 15:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 2QHlRLNg57-a for <6lowpan@core3.amsl.com>; Wed, 27 May 2009 15:53:54 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3B38828C29C for <6lowpan@ietf.org>; Wed, 27 May 2009 15:53:53 -0700 (PDT) Received: from snl-zach.local ([81.253.3.252]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n4RMtRFh012478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Thu, 28 May 2009 01:55:29 +0300 Message-ID: <4A1DC4DF.6090009@sensinode.com> Date: Thu, 28 May 2009 00:55:27 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-03] 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, 27 May 2009 22:53:55 -0000 A new version of draft-ietf-6lowpan-nd is now available at: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-03.txt We've worked hard to close most of the tickets on this draft, and it it now leaner and much more complete. Thanks to everyone for the hard work on discussion and comments. Changes: - Updated terminology, with RFC4861 non-transitive link model - 6LoWPAN and ND terminology separated - Protocol overview explains RFC4861 diff in detail - RR/RC is now Node Registration/Confirmation (NR/NC) - Added NR failure codes - ER Metric now included in 6LoWPAN Prefix Summary option for use in default router determination by hosts - Examples of host data structures, and the Whiteboard given - Whiteboard is supported by all Edge Routers for option simplicity - Edge Router Specification chapter re-structured, clarifying optional Extended LoWPAN operation - NS/NA now completely optional for nodes. No address resolution or NS/NA NUD required. - Link-local operation now compatible with oDAD (was broken) - Exception to hop limit = 255 for NR/NC messages - Security considerations improved - ICMPv6 destination unreachable supported Before the Stockholm cutoff we will submit -04 of the draft. Now it is time for full reviews, security reviews and implementor feedback within the next 3-4 weeks. We will be fishing for AD and IAB feedback as well before Stockholm. - Zach -------- Original Message -------- Subject: New Version Notification for draft-ietf-6lowpan-nd-03 Date: Wed, 27 May 2009 15:34:43 -0700 (PDT) From: IETF I-D Submission Tool To: zach@sensinode.com CC: pthubert@cisco.com,jhui@archrock.com,samitac@ipinfusion.com,Erik.Nordmark@Sun.COM A new version of I-D, draft-ietf-6lowpan-nd-03.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository. Filename: draft-ietf-6lowpan-nd Revision: 03 Title: Neighbor Discovery for 6LoWPAN Creation_date: 2009-05-28 WG ID: 6lowpan Number_of_pages: 52 Abstract: This document specifies Neighbor Discovery optimized for 6LoWPAN. The 6LoWPAN format allows IPv6 to be used over energy and bandwidth constrained wireless networks often making use of multihop topologies. However, the use of standard IPv6 Neighbor Discovery with 6LoWPAN has several problems. Standard Neighbor Discovery was not designed for non-transitive wireless links, and the standard IPv6 link concept and heavy use of multicast makes it inefficient. This document specifies a new ND mechanism allowing for the efficient detection of duplicate addresses over entire LoWPANs while avoiding or simplifying other ND operations. In addition it specifies context dissemination for use with router advertisements, claim and defend address generation, and the support of Extended LoWPANs over backbone links. The IETF Secretariat. -- 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 pthubert@cisco.com Fri May 29 02:54: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 D09C83A6E36 for <6lowpan@core3.amsl.com>; Fri, 29 May 2009 02:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.796 X-Spam-Level: X-Spam-Status: No, score=-8.796 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_05=-1.11, 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 xb4LY3w90Bve for <6lowpan@core3.amsl.com>; Fri, 29 May 2009 02:54:09 -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 58D3A3A6AB3 for <6lowpan@ietf.org>; Fri, 29 May 2009 02:54:08 -0700 (PDT) X-Files: image002.jpg : 1984 X-IronPort-AV: E=Sophos;i="4.41,270,1241395200"; d="jpg'145?scan'145,208,217,145";a="41640898" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 May 2009 09:55:10 +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 n4T9tAl1018633 for <6lowpan@ietf.org>; Fri, 29 May 2009 11:55:10 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4T9tAnZ002806 for <6lowpan@ietf.org>; Fri, 29 May 2009 09:55:10 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 11:55:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C9E043.8E049F99" x-cr-hashedpuzzle: CeOc C5to DAB2 DuAF Du5l D0Un EQH6 FQlt Fu29 HCzr HH8l IsPW JNBb J44R MNYJ M0Ed; 1; NgBsAG8AdwBwAGEAbgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {EA3E6398-01CD-484B-9820-2514D8A82529}; cAB0AGgAdQBiAGUAcgB0AEAAYwBpAHMAYwBvAC4AYwBvAG0A; Fri, 29 May 2009 09:45:10 GMT; cwBvAHUAcgBjAGUAIABhAGQAZAByAGUAcwBzACAAdgBhAGwAaQBkAGEAdABpAG8AbgAgAGkAbgAgAE4ARAAgADAAMwA= x-cr-puzzleid: {EA3E6398-01CD-484B-9820-2514D8A82529} Content-class: urn:content-classes:message Date: Fri, 29 May 2009 11:55:10 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC078A5242@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: source address validation in ND 03 Thread-Index: AcngQh0RPHYNikU9Sj6tOeS45cbL8Q== From: "Pascal Thubert (pthubert)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 29 May 2009 09:55:10.0839 (UTC) FILETIME=[8E1BD870:01C9E043] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=25439; t=1243590910; x=1244454910; 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:=20source=20address=20validation=20in=20ND=2003 |Sender:=20; bh=sgf78uK3XJX7gTC6a26kAGGytiep/H/3nEKRM84Fugo=; b=DDj5HuDlWdP+UDYkxiLCcn9Ab7AORVPteckU62lxxRVz1N/DMmhFYrdJOL 3j1iQ0++CZSxQw4RIgZiON6ylu8vw+4kLIgGCmkNv7dozsw/6e2n+NaN7snb FHiSzmrJIp; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [6lowpan] source address validation in ND 03 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, 29 May 2009 09:54:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E043.8E049F99 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9E043.8E049F99" ------_=_NextPart_002_01C9E043.8E049F99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The current draft inherits source address validation text from the backbone router draft that's meant to prevent nodes in the LoWPAN from using any address as source. =20 section 7.5. about forwarding by Edge Routers has:=20 " Upon receiving packets on one of its LoWPAN interfaces, the Edge Router checks whether it has a binding for the source address. If it does, then the Edge Router can forward the packet; otherwise, the Edge Router MUST discard the packet. " =20 That was fine for a backbone router in a mesh under situation but that seems to falls short for route over, because in that case the Edge Router is not necessarily the first hop: - How can we be sure that the route over infrastructure will actually route the packet via the right Edge Router? - How can we filter impersonation attacks from within the same LoWPAN? =20 So what can we do?=20 =20 a) One way is to tunnel to the edge router.=20 =20 Over the tunnel, the Edge router is really the first hop. It can check that the source address exists but cannot match the LLA. Some credential like a soft token in the tunnel header could prove that the node is really himself. =20 Caveat: that forces all local comm. through the Edge Router and back, so that's overhead in each packet + overhead in path length. =20 b) Another way is to place the function in the first LowPAN Router (the node's default GW).=20 =20 The current draft (03, just posted) imposes that the node registration goes though the first hop router, that either handles it (if it is ER) or relays it (if it is only LoWPAN Router). In either case, the LoWPAN router functionality in the first hop router maintains a binding state upon positive Node Completion. That state binds the registered IP address with the Link Layer Address that is received as source LLA in the Node Registration MAC header. That state is what enables the LoWPAN Router to forward back to the node. Draft 03 does not use NS/NA inside the LoWPAN and thus does not require the traditional ND Neighbor cache there. So what we could do is mandate that the LoWPAN Router uses that same binding table to check the source of the packets that it forwards from the attached nodes for 1) being registered properly and 2) matching LLA. =20 Caveat: after the first LoWPAN router, the source IP does not match the LLA anymore so there must be an additional mechanism in place for trusting LoWPAN routers.=20 =20 What do you think? =20 =20 =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 =20 ------_=_NextPart_002_01C9E043.8E049F99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The current draft = inherits source address validation text from the backbone router draft = that’s meant to prevent nodes in the LoWPAN from using any address as = source.

 

section 7.5. about = forwarding by Edge Routers has:

“

        Upon receiving packets on one of its LoWPAN interfaces, the Edge

        Router checks whether it has a binding for the = source address.  If it

        does, then the Edge Router can forward the = packet; otherwise, the

        Edge Router MUST discard the = packet.

“

 

That was fine for = a backbone router in a mesh under situation but that seems to falls short for route = over, because in that case the Edge Router is not necessarily the first = hop:

-          How can we be sure that the route over = infrastructure will actually route the packet via the right Edge Router?

-          How can we filter impersonation attacks from = within the same LoWPAN?

 

So what can we do? =

 

a)      = One way is to tunnel to the edge router.

 

Over the tunnel, the Edge router is really the = first hop. It can check that the source address exists but cannot match the LLA. Some credential like a soft token in the tunnel header could prove that the = node is really himself.

 

Caveat: that forces all local comm. through the = Edge Router and back, so that’s overhead in each packet + overhead in path = length.

 

b)      = Another way is to place the function in the first LowPAN Router (the = node’s default GW).

 

The current draft = (03, just posted) imposes that the node registration goes though the first hop = router, that either handles it (if it is ER) or relays it (if it is only LoWPAN Router). In either case, the LoWPAN router functionality in the first = hop router maintains a binding state upon positive Node Completion. That = state binds the registered IP address with the Link Layer Address that is = received as source LLA in the Node Registration MAC header. That state is what = enables the LoWPAN Router to forward back to the node. Draft 03 does not use NS/NA = inside the LoWPAN and thus does not require the traditional ND Neighbor cache = there. So what we could do is mandate that the LoWPAN Router uses that same = binding table to check the source of the packets that it forwards from the = attached nodes for 1) being registered properly and 2) matching = LLA.

 

Caveat: after the = first LoWPAN router, the source IP does not match the LLA anymore so there = must be an additional mechanism in place for trusting LoWPAN routers. =

 

What do you think?

 

 

 

3D"cid:image002.jpg@01C9E052.E08EBA00"<= /p>

Pascal Thubert=
IP Engineering TC

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

<= b>= 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_01C9E043.8E049F99-- ------_=_NextPart_001_01C9E043.8E049F99 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/s9VkS1uzLnfIOoAwVz9c16PPfWmpeGrq6sZFkgeGTayjg8GsYSbV2z0c VShTkqcYbW17lHwl4s/4SXR59RmtRarA5UgPu4A69BXOH4najeXk39j6BLeWkLYeQZz+lSfChYn8 J3qzY8szMHz6Y5rl9Xtz4LY6j4a8SpLDLLzbhst36juKlylypm0KFH286dtem9j1jUNdtNK0Marf kwx7FYofvZI+79a4m1+Kd9e3sZg0GQ2TyhPN5JGfwxTPiDJea18PNO1LyyuSskyqOBkda2fDHi/w wvh2xgW5hgdUWNoCOd/Q8e5qnJuVr2MoUYQo87hzO7XoavinxbYeFrFJ7oNJLL/qoV6t/wDWrk9O +LRN4iavpb2lvKcJKM9PXn+lU/ightfFekandxGWwUKGHUHDZI/Kl+I/iXQNX8P29pprx3Ny7q0f lrzGPT+mKmU3d67GtDDU3CCcW+bd9j1KORJolljYMjgFSO4p9ZXhiCa28M6dBcAiVLdQ4PUHFatb rY8mSSk0gooopkhRRRQAUUUUAFFFFAHPat4F8O6zcm5u7AeceWeNipb64rTstHsbDSl0u3h22qoU 2ZJ4PXmr1FLlV7mjqzcVFt2Rm6X4f0vRrKWysLUQwSkl03E5z9TWND8NfC0Fys4sCzK27DyEj8q6 uilyx7DVeqm2pPXcie2gktjbPEjQldpjI4x6YrnF+HPhhL5btLDa6uHCiQ7QfpXUUU3FPcUKs4X5 W1cqahpllqto1pfW6Twt/CwrG03wB4b0q7F1b2AMq/dMjFtp9QDXSUUOKbuwjVqRi4xbSCiiimZh RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== ------_=_NextPart_001_01C9E043.8E049F99-- From richard.kelsey@ember.com Fri May 29 07:54: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 522253A6C1E for <6lowpan@core3.amsl.com>; Fri, 29 May 2009 07:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 oMW3iFv84sJE for <6lowpan@core3.amsl.com>; Fri, 29 May 2009 07:54:11 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 55C503A6C62 for <6lowpan@ietf.org>; Fri, 29 May 2009 07:54:11 -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); Fri, 29 May 2009 10:56:32 -0400 Date: Fri, 29 May 2009 10:56:12 -0400 Message-Id: <87ljogyn3n.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC078A5242@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <7892795E1A87F04CADFCCF41FADD00FC078A5242@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 29 May 2009 14:56:32.0174 (UTC) FILETIME=[A76C9CE0:01C9E06D] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] source address validation in ND 03 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, 29 May 2009 14:54:12 -0000 Date: Fri, 29 May 2009 11:55:10 +0200 From: "Pascal Thubert (pthubert)" The current draft inherits source address validation text from the backbone router draft that's meant to prevent nodes in the LoWPAN from using any address as source. section 7.5. about forwarding by Edge Routers has: " Upon receiving packets on one of its LoWPAN interfaces, the Edge Router checks whether it has a binding for the source address. If it does, then the Edge Router can forward the packet; otherwise, the Edge Router MUST discard the packet. " That was fine for a backbone router in a mesh under situation but that seems to falls short for route over, because in that case the Edge Router is not necessarily the first hop: The check described in the passage above seems to be guarding against the use of a source address that is not bound within the LoWPAN. It doesn't appear to be concerned with a LoWPAN node using a source address that is bound to some other node in the same LoWPAN. For the former, guarding against the use of an unbound source address, I don't think it matters whether the Edge Router is the first hop or not. -Richard Kelsey From pthubert@cisco.com Fri May 29 08:39: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 E39A53A6B55 for <6lowpan@core3.amsl.com>; Fri, 29 May 2009 08:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.021 X-Spam-Level: X-Spam-Status: No, score=-10.021 tagged_above=-999 required=5 tests=[AWL=0.578, 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 noL4dhiP9kMe for <6lowpan@core3.amsl.com>; Fri, 29 May 2009 08:39: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 75AB33A6B6F for <6lowpan@ietf.org>; Fri, 29 May 2009 08:39:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,272,1241395200"; d="scan'208";a="41682108" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 May 2009 15:34:26 +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 n4TFYQw0010188; Fri, 29 May 2009 17:34:26 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4TFYQnx005696; Fri, 29 May 2009 15:34:26 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 17:34:26 +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: Fri, 29 May 2009 17:34:21 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC078A543B@xmb-ams-337.emea.cisco.com> In-Reply-To: <87ljogyn3n.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] source address validation in ND 03 Thread-Index: AcngbYPuDtTgFMk1T9eCGM7KIciEOgABLSdA References: <7892795E1A87F04CADFCCF41FADD00FC078A5242@xmb-ams-337.emea.cisco.com> <87ljogyn3n.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 29 May 2009 15:34:26.0529 (UTC) FILETIME=[F30BA510:01C9E072] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1703; t=1243611266; x=1244475266; 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]=20source=20address=20validati on=20in=20ND=2003 |Sender:=20; bh=IjDwqjsYuVHdvkmiAqQ97R6RPcgfAQmSZEIgOEXOWaE=; b=ht9aRqnbuWUOL/cQAVlBXQjaDE1k1EwtEL4BrJ+ddRnMx6iQ0gBuX06X8e 3013Cw2siq4hIE4y0Zj6R97sw6WbVQytTMKhWMlGYZ5e99vqjDXyQ37xbeEE H0O9KGk10T; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] source address validation in ND 03 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, 29 May 2009 15:39:16 -0000 Hi Richard Agreed but in extended the whiteboard is distributed so if your packet get out the wrong edge router it would filter them out... Pascal >-----Original Message----- >From: Richard Kelsey [mailto:richard.kelsey@ember.com] >Sent: vendredi 29 mai 2009 16:56 >To: Pascal Thubert (pthubert) >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] source address validation in ND 03 > > Date: Fri, 29 May 2009 11:55:10 +0200 > From: "Pascal Thubert (pthubert)" > > The current draft inherits source address validation text from the > backbone router draft that's meant to prevent nodes in the LoWPAN from > using any address as source. > > section 7.5. about forwarding by Edge Routers has: > > " > Upon receiving packets on one of its LoWPAN interfaces, the Edge > Router checks whether it has a binding for the source address. If > it does, then the Edge Router can forward the packet; otherwise, > the Edge Router MUST discard the packet. > " > > That was fine for a backbone router in a mesh under > situation but that seems to falls short for route over, > because in that case the Edge Router is not necessarily > the first hop: > >The check described in the passage above seems to be >guarding against the use of a source address that is not >bound within the LoWPAN. It doesn't appear to be concerned >with a LoWPAN node using a source address that is bound to >some other node in the same LoWPAN. For the former, >guarding against the use of an unbound source address, I >don't think it matters whether the Edge Router is the first >hop or not. > -Richard Kelsey From richard.kelsey@ember.com Fri May 29 09:29: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 A42633A69A8 for <6lowpan@core3.amsl.com>; Fri, 29 May 2009 09:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 ye44DOdLxwme for <6lowpan@core3.amsl.com>; Fri, 29 May 2009 09:29:41 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id A4FFD3A6906 for <6lowpan@ietf.org>; Fri, 29 May 2009 09:29:41 -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); Fri, 29 May 2009 12:29:46 -0400 Date: Fri, 29 May 2009 12:29:26 -0400 Message-Id: <87iqjjzxcp.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC078A543B@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <7892795E1A87F04CADFCCF41FADD00FC078A5242@xmb-ams-337.emea.cisco.com> <87ljogyn3n.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC078A543B@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 29 May 2009 16:29:46.0049 (UTC) FILETIME=[ADA23310:01C9E07A] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] source address validation in ND 03 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, 29 May 2009 16:29:42 -0000 Date: Fri, 29 May 2009 17:34:21 +0200 From: "Pascal Thubert (pthubert)" >From: Richard Kelsey [mailto:richard.kelsey@ember.com] >To: Pascal Thubert (pthubert) > > Date: Fri, 29 May 2009 11:55:10 +0200 > From: "Pascal Thubert (pthubert)" > > The current draft inherits source address validation text from the > backbone router draft that's meant to prevent nodes in the LoWPAN from > using any address as source. > > section 7.5. about forwarding by Edge Routers has: > > " > Upon receiving packets on one of its LoWPAN interfaces, the Edge > Router checks whether it has a binding for the source address. If > it does, then the Edge Router can forward the packet; otherwise, > the Edge Router MUST discard the packet. > " > > That was fine for a backbone router in a mesh under > situation but that seems to falls short for route over, > because in that case the Edge Router is not necessarily > the first hop: > >The check described in the passage above seems to be >guarding against the use of a source address that is not >bound within the LoWPAN. It doesn't appear to be concerned >with a LoWPAN node using a source address that is bound to >some other node in the same LoWPAN. For the former, >guarding against the use of an unbound source address, I >don't think it matters whether the Edge Router is the first >hop or not. Agreed but in extended the whiteboard is distributed so if your packet get out the wrong edge router it would filter them out... Pascal, Doesn't the Extended LoWPAN backbone take care of that? >From 7.3: Addresses that are not found in the Whiteboard are queried over the backbone using the ND operation in place for that type of link, ... Either you have a Simple LoWPAN, in which case there is only one Edge Router, or you have an extended LoWPAN, in which case the Edge Routers can query each other over the backbone if they see a source address that is not in their local whiteboard. I think that this works for the Simple and Extended LoWPANs as described in the draft. It would be nice if there were a way of having additional Edge Routers that were not on a high-speed backbone. An Edge Router whose other IP network was another LoWPAN, for example. If that were permitted, a node would have to route packets via an edge router with which it was registered, as you described. -Richard Kelsey ---------------- This message and the information it contains are the proprietary and confidential property of Ember Corporation and may be privileged. If you are not the intended recipient, please do not read, copy, disclose or distribute its contents to any party, and notify the sender immediately.