From eunah.ietf@gmail.com Tue Feb 10 21:55: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 CFA403A6968 for <6lowpan@core3.amsl.com>; Tue, 10 Feb 2009 21:55:48 -0800 (PST) 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 eywSfx2C21ka for <6lowpan@core3.amsl.com>; Tue, 10 Feb 2009 21:55:47 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id D55953A67B4 for <6lowpan@ietf.org>; Tue, 10 Feb 2009 21:55:47 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so24323rvf.49 for <6lowpan@ietf.org>; Tue, 10 Feb 2009 21:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=HVqTUmtp/Exev6MYwMmhUFLsKXiwcxzQ1WLRYo5zotM=; b=Bz0r2c94z0dkeCBHq9VpzI+EAmUQnVjpFSgRlfy4Q4F4TSg9ZU88kyAHK4L8e4BLYZ vEQrEDu+gTMljDgcigcyCh3mDoKo0QLRwsn2K+v6ltD4LBumtuCJ+ANeU20KTPZ5Oo0g QqSwfgm7V8V7dbzmjAGHMxvh7Xv1XweGj7pLA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=gSsg8+cxd5rZ5f1fPksQd3Yr5Ux6yA1bOWNlml+GCBxTAauFPqoxJS7TnaXNO8J8My r+B6oT6kTrB2aav2RYp3xeVyvy/ZSyAUbkgdYcUWVTjUq84kUncowOvPtwtThU/BHnLo j88u0kJm9pBSHXCNAgrsyFdG8ktdNvM7wT+H4= MIME-Version: 1.0 Received: by 10.141.29.21 with SMTP id g21mr422180rvj.198.1234331751270; Tue, 10 Feb 2009 21:55:51 -0800 (PST) Date: Wed, 11 Feb 2009 14:55:51 +0900 Message-ID: <77f1dba80902102155x53ae53f5h62fad1839025498a@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann Subject: [6lowpan] UPDATE '6LoWPAN Routing Requirements' 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, 11 Feb 2009 05:55:48 -0000 Dear 6LoWPANers, For revision of the routing requirement documents, please give us your comments. Currently, we have 4 tickets at issue tracker. (http://trac.tools.ietf.org/wg/6lowpan/trac/query?component=routing-requirements) - #1: "Make sure interface to 15.4 is clear". One of the comments in Minneapolis was whether 6LoWPAN WG is assuming only the 802.15.4 frame format or the whole PHY/MAC protocol. - #2: "Improve discussion of mutual requirements of routing and header compression". the relation between routing and header compression, contexts, etc - #3: "Discuss hibernation-induced latency with the latency requirements". Latency may be affected by nodes hibernation, depending on the MAC used. Other MAC approaches than the legacy 802.15.4 may be used (e.g. TDMA) and duty cycling may also affect latency (and many other things). - #4: "Refine discussion on how MAC-layer ACKs can go into routing". There was a comment that 802.15.4 does not protect layer two acknowledgments. So many systems use data frames for acknowledgements. Please feel free to give us comments on these issues or any other issues for the revision. Greetings, -eunah From eunah.ietf@gmail.com Tue Feb 10 23:10: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 8A6A23A67AC for <6lowpan@core3.amsl.com>; Tue, 10 Feb 2009 23:10:13 -0800 (PST) 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 PxuyFZIxTBsN for <6lowpan@core3.amsl.com>; Tue, 10 Feb 2009 23:10:12 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id BDC283A68AD for <6lowpan@ietf.org>; Tue, 10 Feb 2009 23:10:12 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so39630rvf.49 for <6lowpan@ietf.org>; Tue, 10 Feb 2009 23:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=O8k0wSK2wTryDji1GEXBpHzt8yQ9aBcoC+yTpOdqIBg=; b=Zeokh0LjW3pBARIuGrcndLBpRnldHj7SDMNH1nPibk3jXMIMq0ZoJQQVruGRD7geEV 97ZpFnCN/DYybV3TYc/s4QgaBSGhhJ5DTddIOULXBPIXyOLak+/vSfBU3KI3JT53piZU Ew00PUaxGnr/8BkuTpziL9QXY25OCBJWSDan4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=S5f2U+YRw8oMSzEFLfghimwxB/CchdDI6WIufnqUQoSzDL4S5JPuzEfYlAeEZtb0W3 toNXcfyGFLqqceUUxd2f31hXi+MNPUnEYu6jXvd0VdvB7XYHgAg34oS9sqZuEROxkei3 6dOePqqzQGO0OwH4bTFQNfrCRS8qkygBplrio= MIME-Version: 1.0 Received: by 10.140.125.1 with SMTP id x1mr3537990rvc.162.1234336216273; Tue, 10 Feb 2009 23:10:16 -0800 (PST) Date: Wed, 11 Feb 2009 16:10:16 +0900 Message-ID: <77f1dba80902102310j42f860e5jb1029fe2ca926eee@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Chevrollier, N.G. \(Nicolas\)" , JP Vasseur Subject: [6lowpan] UPDATE 'use cases' 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, 11 Feb 2009 07:10:13 -0000 Dear 6lowpaners, The authors of 6lowpan use-cases would like to get your comments on the http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-01.txt. Your feedback will help a lot for the revision work. Thanks, -eunah From zach@sensinode.com Wed Feb 11 07:00: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 882DB3A6C81 for <6lowpan@core3.amsl.com>; Wed, 11 Feb 2009 07:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZ5WnzF0bp-K for <6lowpan@core3.amsl.com>; Wed, 11 Feb 2009 07:00:23 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4FA663A6C75 for <6lowpan@ietf.org>; Wed, 11 Feb 2009 07:00:23 -0800 (PST) Received: from h073010.gprs.dnafinland.fi (h073010.gprs.dnafinland.fi [87.93.73.10]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n1BF0G4N023555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 17:00:18 +0200 Message-ID: <4992E846.3080708@sensinode.com> Date: Wed, 11 Feb 2009 17:01:26 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Eunsook \"Eunah\" Kim" References: <77f1dba80902102155x53ae53f5h62fad1839025498a@mail.gmail.com> In-Reply-To: <77f1dba80902102155x53ae53f5h62fad1839025498a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] UPDATE '6LoWPAN Routing Requirements' 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, 11 Feb 2009 15:00:24 -0000 Hi, In Minneapolis, there was another comment that came up (from me, and some others) which should be added as a ticket. Didn't notice it wasn't there earlier, sorry. -00 of the draft is extremely IEEE 802.15.4 specific. The working group has moved towards link-layer independence and has accepted that 6lowpan is being used over other radio technologies in addition to 802.15.4. In fact, the new HC and ND drafts are already written to be link-layer independent. My request is to make this draft more link-layer agnostic. I think it is fine to use IEEE 802.15.4 as an example, however it should be mentioned and considered that 6lowpan will be used over other low-power radios which may have similar characteristics to 802.15.4, but surely not the exact same mechanisms such as RFD/FFD and superframes. The use of these features in practice in the industry is also marginal even for 802.15.4. On the same note - we need to correct this in RFC4944 as well either through an update or replacing it. Making it clear to newcomers that 6lowpan is only for 802.15.4. Thanks, Zach Eunsook "Eunah" Kim wrote: > Dear 6LoWPANers, > > For revision of the routing requirement documents, please give us your comments. > Currently, we have 4 tickets at issue tracker. > > (http://trac.tools.ietf.org/wg/6lowpan/trac/query?component=routing-requirements) > > - #1: "Make sure interface to 15.4 is clear". > One of the comments in Minneapolis > was whether 6LoWPAN WG is assuming only the 802.15.4 frame format or the > whole PHY/MAC protocol. > > - #2: "Improve discussion of mutual requirements of routing and header > compression". > the relation between routing and header compression, contexts, etc > > - #3: "Discuss hibernation-induced latency with the latency requirements". > Latency may be affected by nodes hibernation, depending on the MAC used. > Other MAC approaches than the legacy 802.15.4 may be used (e.g. TDMA) and > duty cycling may also affect latency (and many other things). > > - #4: "Refine discussion on how MAC-layer ACKs can go into routing". > There was a comment that 802.15.4 does not protect layer two acknowledgments. > So many systems use data frames for acknowledgements. > > > Please feel free to give us comments on these issues or any other > issues for the revision. > > Greetings, > -eunah > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 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 Feb 11 08:31: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 64E903A6A9C; Wed, 11 Feb 2009 08:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.052, 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 lU3jkEyONT6c; Wed, 11 Feb 2009 08:31:57 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id B07E13A69D2; Wed, 11 Feb 2009 08:31:56 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1BGUJlE012077; Wed, 11 Feb 2009 17:30:19 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1BGVxIl004411; Wed, 11 Feb 2009 17:31:59 +0100 (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 n1BGVxD1028530; Wed, 11 Feb 2009 17:31:59 +0100 Message-ID: <4992FD7F.8070408@gmail.com> Date: Wed, 11 Feb 2009 17:31:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ROLL WG , 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 16:31:58 -0000 [Where should I post this message, to 6LoWPAN or to ROLL list? Both?] Dear WG members, draft-ietf-6lowpan-routing-requirements-00 lists a Problem Statement, some Scenarios and a set of Routing Requirements. Generally I find it a well written document, with many meaningful details. There are very many parts of this document to which I silently agree, even some parts I wholehartedly agree. I like the distinction route-above mesh-under, and many other parts too. Some high-level questions: -is there a requirement to connect a 6LoWPAN network to the Internet? -is the 6LoWPAN using addressing architecture and longest-prefix match based routing as in the Internet? -how many interfaces will a 15.4 device have potentially? Following are detail questions and comments. I believe they're not as important as the items mentioned above. > 1. Problem Statement Is this _the_ problem statement or should I better go read draft-ietf-6lowpan-problem-08? They differ largely... > The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" > [3]) briefly mentions four requirements on routing protocols; > > (a) low overhead on data packets > > (b) low routing overhead What is routing more generally? Is it the act a router performs when presenting with a packet, searching in a routing table, maybe exploring its ND structures, maybe sending ND messages and then emitting the packet? Or is it exchanging IP datagrams containing prefixes and metrics and reachability information, such that nodes have a common view of the network paths? I think this is worth discussing, in order to better target what the work should follow this problem statement and reqs. Are the low overhead requirements put on the database construction messages? Or on the individual act of forwarding a packet? > On the other hand, the route-over approach relies on IP routing and > therefore supports routing over possibly various types of > interconnected links (see also Figure 1). At several places in the draft, when link 'types', device 'types' are mentioned, I'm tempted to believe 6LoWPAN considers links other than 802.15.4 links? Is it so? Should 6LoWPAN routing protocol work also with aseptic point-to-point links? Or are the 'types' limited within the relatively large scope of 802.3 compatible MACs (I believe 802.15.4 and 802.16 to fit within). This is of paramount importance in setting the scope. > The most significant consequence of mesh-under routing is that > routing would be directly based on the IEEE 802.15.4 standard, Which 'routing' is directly based on 802.15.4 standard? The 'IP routing' is based on that standard? This brings back to defining what routing is. Maybe better call 'mesh-under routing' 'mesh-under switching'. IP routing and addressing may be fundamentally different than mesh-under addressing and switching - in the way hosts get and maintain their addresses and in the way routers/switches search their databases (exact match vs longest-prefix). > When a route-over protocol is built in the IPv6 layer, the Dispatch > value can be chosen as one of the Dispatch patterns for 6LoWPAN, > compressed or uncompressed IPv6, followed by the IPv6 header. Sorry, I can't parse this. A route-over protocol would act both at IP layer and application/transport layers. Depends what a routing protocol is. For example ICMP Redirect, or NEMOv6 or ND act at IP layer, whereas RIPng is over UDP. 'followed by'... when reading left to right or reverse? > For route-over, a default route to the ER could be inserted into the > routing system. In the routing system of the 6LoWPAN network? Or in the routing system of the fixed Internet network? > IP-based low-power WPAN technology is still in its early stage of 'WPAN'? > a. Network Properties: > > * Number of Devices, Density and Network Diameter: These parameters > usually affect the routing state directly (e.g. the number of > entries in a routing table or neighbor list). Especially in large > and dense networks, policies must What is 'large' and 'dense'? Is it about physical dimensions? Or IP dimensions? Density sounds as a physical characteristic (many devices in a small area) whereas Diameter sounds as a pure IP term (max number of IP hops). The number of entries in the routing table mostly depends on the planned addressing architecture. One can have a very high-diameter network with a very hierarchical addressing structures, many default routes, and very few entries in the routing tables (maybe only 1 per hop). Is the addressing architecture for 6LoWPAN networks planned? Is the addressing architecture following the Internet model? > b. Node Parameters: How many interfaces does a 6LoWPAN node typically have? This is of paramount importance deciding whether any type of repeating/bridging needs to happen. > * Throughput: The maximum user data throughput of a bulk data > transmission between a single sender and a single receiver through an > unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as > follows [19]: [...] > > In the case of 915 MHz band: Sorry, for my clarification: is 915MHz the width of band centered on the 2.4GHz mentioned above? Or is it the central frequency (thus replacing the "2.4GHz" mentioned above)? > [R02] 6LoWPAN routing protocols SHOULD cause minimal power > consumption by the efficient use of control packets (e.g., minimize > expensive multicast which cause broadcast to the entire LoWPAN) and > by the efficient routing of data packets. YEs, but multicast may be more efficient than broadcast - is it sufficient? I think it is sufficient to rely on multicast and avoid unnecessary duplication such as in broadcast. 'Efficient routing of data packets' - is it also efficient search in the routing table? That may be part of 'routing' too. > possibliy Nit: iy > [R03] 6LoWPAN routing protocol control messages SHOULD not create > fragmentation of physical layer (PHY) frames. Err... I think PHY frames aren't fragmented... not sure I understand this requirement? Sounds as if one wants an UDP control packets to not be sent in several pieces, because of overhead involved fragmenting/reassembling. Then make sure first IP doesn't fragment. > Therefore, 6LoWPAN routing should not cause packets to exceed the > IEEE 802.15.4 frame size [81bytes]. Is this a requirement on the mesh-under link-layer switching protocol? Or on the 'route-above' protocol? If the latter - I think this requirement is a violation of layer independence :-) It sounds very special to me to limit the size of the messages of an IP routing protocol. Knowing that IP can fragment too. > [R05] The design of routing protocols for 6LoWPANs must consider the > end-to-end latency requirements of applications and IEEE 802.15.4 > link latency characteristics. 'Routing'? Or 'Transport'? end-to-end is what Transport typically takes care of, not routing. If Routing: which routing? The forwarding ahppening at a node? Or the convergence time? The exchange of routing messages? > Some routing protocols are aware of the hop count of a path. I think all of them are, no? > In homes, buildings, or infrastructure, some nodes will be installed > with mains power. Such power-installed nodes MUST be If they have mains power - will they use Power-Line Communications? > Building monitoring applications, for instance, require that the > mobile devices SHOULD be capable of leaving (handing-off) from an old > network joining onto a new network within 15 seconds [17]. Should such a mobile device change its IP address or is it free to change it? > [R13] 6LoWPAN routing protocol SHOULD support various traffic > patterns; point-to-point, point-to-multipoint, and multipoint-to- > point, while avoid excessive multicast traffic (broadcast in link > layer) in 6LoWPAN. It's called multicast at link-layer too (802.3); thus it avoids unnecessary packet duplication, thus it avoids duplication of broadcasted packets and thus avoids excessive traffic. If we talk IPv6 and recent link layers then I mostly forget the term 'broadcast' and use multicast instead. > 6LoWPAN routing protocols should be designed with the consideration > of forwarding packets from/to multiple sources/destinations. Sorry, what do you mean? An IP packet with multiple src fields? > Current WG drafts in the ROLL working group explain that the workload > or traffic pattern of use cases for 6LoWPANs tend to be highly > structured, unlike the any- to-any data transfers that dominate > typical client and server workloads. Sorry, what do you mean by 'any-to-any' data transfers? Any relationship to 'IP anycast'? > [R14] 6LoWPAN protocols SHOULD support secure delivery of control > messages. A minimal security level can be achieved by utilizing AES- > based mechanism provided by IEEE 802.15.4. Isn't AES superstrong and thus computation intensive and thus energy intensive? Intuitively speaking, maybe SHA-1 is sufficient for reduced needs in constrained environments. > [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending > "Hello" messages. ND doesn't send Hello messages, but NS, NA, RS and RA. > [R18] If the routing protocol functionality includes enabling IP > multicast, then it may want to employ coordinator roles, if any, as > relay points of group-targeting messages instead of using link-layer > multicast (broadcast). link-layer multicast no broadcast. Nit: 'MAC sub-layer' appears only once and in the figure they're all 'layers'. Alex From alexandru.petrescu@gmail.com Wed Feb 11 09:33: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 511603A6B95 for <6lowpan@core3.amsl.com>; Wed, 11 Feb 2009 09:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 4KiDKltBmAzz for <6lowpan@core3.amsl.com>; Wed, 11 Feb 2009 09:33:42 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 5CE6D3A6B4D for <6lowpan@ietf.org>; Wed, 11 Feb 2009 09:33:42 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1BHXiGe022558; Wed, 11 Feb 2009 18:33:44 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1BHXhTh029494; Wed, 11 Feb 2009 18:33:44 +0100 (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 n1BHXhFQ032469; Wed, 11 Feb 2009 18:33:43 +0100 Message-ID: <49930BF7.2080303@gmail.com> Date: Wed, 11 Feb 2009 18:33:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Zach Shelby References: <77f1dba80902102155x53ae53f5h62fad1839025498a@mail.gmail.com> <4992E846.3080708@sensinode.com> In-Reply-To: <4992E846.3080708@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] UPDATE '6LoWPAN Routing Requirements' 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, 11 Feb 2009 17:33:43 -0000 Zach Shelby a écrit : > Hi, > > In Minneapolis, there was another comment that came up (from me, and > some others) which should be added as a ticket. Didn't notice it > wasn't there earlier, sorry. > > -00 of the draft is extremely IEEE 802.15.4 specific. The working > group has moved towards link-layer independence and has accepted that > 6lowpan is being used over other radio technologies in addition to > 802.15.4. In fact, the new HC and ND drafts are already written to be > link-layer independent. Sorry, I don't understand. With respect to draft-ietf-6lowpan-nd-00.txt Do you mean ND for 6LoWPAN could work over a WiFi link? Alex From alexandru.petrescu@gmail.com Wed Feb 11 10:49: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 9FCA93A6D56 for <6lowpan@core3.amsl.com>; Wed, 11 Feb 2009 10:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[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 D3SKnekivKNI for <6lowpan@core3.amsl.com>; Wed, 11 Feb 2009 10:49:53 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 6844C3A6911 for <6lowpan@ietf.org>; Wed, 11 Feb 2009 10:49:50 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1BInsGJ017277 for <6lowpan@ietf.org>; Wed, 11 Feb 2009 19:49:54 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1BInsR3024728 for <6lowpan@ietf.org>; Wed, 11 Feb 2009 19:49:54 +0100 (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 n1BInrWN024424 for <6lowpan@ietf.org>; Wed, 11 Feb 2009 19:49:53 +0100 Message-ID: <49931DD1.6000505@gmail.com> Date: Wed, 11 Feb 2009 19:49:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] Some comments on draft-ietf-6lowpan-nd-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 18:49:54 -0000 Hello WG and authors of draft-ietf-6lowpan-nd-00.txt I would like to provide some comments on this draft. However, it is not very clear to me: is this ND going to be used over other links than 802.15.4? For example over IEEE 802.3 or WiFi? If yes, then I have several comments, some of which below. Otherwise forget it... > 4.2. Router Advertisement Message > > The RA message for 6LoWPAN is based on the [RFC4861] RA message with > the addition of a new flag "E". In addition new options are > identified. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Cur Hop Limit |M|O|x|x|x|x|E|x| Router Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reachable Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Retrans Timer | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options ... > +-+-+-+-+-+-+-+-+-+-+-+ > x: Bits currently reserved for existing RA flags as per [RFC5175]. Well no, rfc5175 names the allocated flags: > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |M|O|H|Prf|P|R|R| > +-+-+-+-+-+-+-+-+ Meaning the rightmost two bits are not currently used (and reading your text implies the rightmost bit is currently used). Why not using that RFC's Flags Expansion Option, instead of requesting allocation of the 'E' bit in the current Flags? > o A subnet covers all the LoWPANs and their backbone link with the > same IPv6 global or local prefix. This is throughout the document: I'm not sure I understand 'local' prefix. Is it the globally reserved fe80::/10 link-local scope prefix? Is it fc00::/7 globally unique yet smaller than global scope? > In addition [this document] specifies prefix and context > dissemination for use with router advertisements I'm not sure about the dissemination part. Is it a simple advertising on a link? The typical Router Advertisement? If yes, then advertising a prefix on a link is nothing new, thus one may probably better say "document specifies a relationship between HC context and prefix". Dissemination sounds to me as if the network contained several IP hops with decrementing HopLimit fields, whereas here there seems to be a single subnet. > LoWPAN Subnet > > A subnet including a LoWPAN or Extended LoWPAN, together with the > backbone link sharing the same prefix. The same prefix and same prefix length? Sharing is confusing to me. I don't think you meant to say the backbone link and the LoWPAN link had the same prefixes and prefix lengths, respectively. > If a local or global prefix is included in the RA, the host may form > an optimistic global unique address with stateless autoconfiguration. > What's local or global prefix? fe80::/10 is globally unique prefix yet local scope. An IPv6 address self-formed on Ethernet is globally unique yet local scope. ULA fc00 ? I'm not sure what you mean. > If the host moves to a different LoWPAN, with a different default > prefix, the bootstrapping process is initiated again. Throughout the document I don't understand 'default' prefix. Are there other alternative or preferred prefixes? > 6LoWPAN Prefix Information Option: This option includes information > about the default subnet prefix for the LoWPAN along with other > shared contexts for the subnet. Same, default prefix. > 4.4.3. Multihop Information Option > > This option identifies the set of prefix information options by a > sequence number. This allows for the full set of prefix information > options to be sent only periodically in unsolicited RAs. If a host > detects a difference in the sequence number of this option, then the > prefix information has likely changed, and is then requested with an > RS. I'm not sure the term Multihop is appropriate to name this option? There is no decrementing of HopLimit, it's a single subnet, thus no multihop. Or this Multihop means that it's multi-link-layer-hop? I'm not sure how people call when my PC talks to a neighbor PC in the same subnet but separated by 3 switches - is that Multihop? > A subnet is a collection of LoWPAN links interconnected by routers > that may share one or more local or global prefixes. Local or global prefix. > The node might also form Unique Local and Global Unicast addresses, Is this Unique Local address an RFC4193 "Unique Local IPv6 Unicast Addresses"? This could be clarified. > This specification includes a method for requesting a unique > stateless address from the Edge Router by setting the 'A' flag in an > Address Option during registration. Is this unique stateless address the same as the prior mentioned Unique Local address, same as rfc4193? > To simplify address resolution it is assumed that LoWPAN nodes are > assigned addresses in a homogeneous so that the unicast IPv6 > addresses IID resolve directly to a corresponding link-layer address. > Thus avoiding address resolution when possible. I'm afraid this way of avoiding NS-NA address resolution means effectively forbidding manually assigned addresses - is this ok? > This specification includes a method for requesting a unique > stateless address from the Edge Router by setting the 'A' flag in an > Address Option during registration. A new mechanism to assign addresses? Why wouldn't DHCP be sufficient? Maybe Stateless DHCP RFC3736? > then the ER aquires an appropriate, unique link-layer address for the > network either by generating it and performing DAD, or with some > other method. A link-layer address or a link-local address? I suppose the latter. Although sometimes the link-layer ids are also negotiated... but not sure one would DAD the link-layer address. Alex From zach@sensinode.com Wed Feb 11 12:58:59 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 9BF633A6A8A for <6lowpan@core3.amsl.com>; Wed, 11 Feb 2009 12:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+u5k5er9tpJ for <6lowpan@core3.amsl.com>; Wed, 11 Feb 2009 12:58:58 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E79B03A6BFD for <6lowpan@ietf.org>; Wed, 11 Feb 2009 12:58:57 -0800 (PST) Received: from snl-zach.local (line-17565.dyn.kponet.fi [85.29.115.13]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n1BKwutv003696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 22:58:57 +0200 Message-ID: <49933C58.2090406@sensinode.com> Date: Wed, 11 Feb 2009 23:00:08 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <49931DD1.6000505@gmail.com> In-Reply-To: <49931DD1.6000505@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Some comments on draft-ietf-6lowpan-nd-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 20:58:59 -0000 Alex, Thanks for the comments. We are quite close to releasing -01 of this draft (next week). Many of your concerns are covered there. But you have many valid questions below - let's get back to them after -01 is out OK? We'll try to take them into account in -01 already where possible. Regarding 802.3 and WiFi - they are definitely out of scope for 6lowpan, as are all links which run standard IPv6. This WG concentrates on low-power, low-bandwidth wireless ad-hoc radios such as 802.15.4, low-power ISM band etc. Cheers, Zach Alexandru Petrescu wrote: > Hello WG and authors of draft-ietf-6lowpan-nd-00.txt > > I would like to provide some comments on this draft. > > However, it is not very clear to me: is this ND going to be used over > other links than 802.15.4? For example over IEEE 802.3 or WiFi? > > If yes, then I have several comments, some of which below. Otherwise > forget it... > >> 4.2. Router Advertisement Message >> >> The RA message for 6LoWPAN is based on the [RFC4861] RA message with >> the addition of a new flag "E". In addition new options are >> identified. >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Code | Checksum | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Cur Hop Limit |M|O|x|x|x|x|E|x| Router Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reachable Time | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Retrans Timer | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Options ... >> +-+-+-+-+-+-+-+-+-+-+-+ > >> x: Bits currently reserved for existing RA flags as per [RFC5175]. > > > Well no, rfc5175 names the allocated flags: >> 0 1 2 3 4 5 6 7 >> +-+-+-+-+-+-+-+-+ >> |M|O|H|Prf|P|R|R| >> +-+-+-+-+-+-+-+-+ > > Meaning the rightmost two bits are not currently used (and reading your > text implies the rightmost bit is currently used). > > Why not using that RFC's Flags Expansion Option, instead of requesting > allocation of the 'E' bit in the current Flags? > >> o A subnet covers all the LoWPANs and their backbone link with the >> same IPv6 global or local prefix. > > This is throughout the document: I'm not sure I understand 'local' > prefix. Is it the globally reserved fe80::/10 link-local scope prefix? > Is it fc00::/7 globally unique yet smaller than global scope? > >> In addition [this document] specifies prefix and context dissemination >> for use with router advertisements > > I'm not sure about the dissemination part. Is it a simple advertising on > a link? The typical Router Advertisement? If yes, then advertising a > prefix on a link is nothing new, thus one may probably better say > "document specifies a relationship between HC context and prefix". > > Dissemination sounds to me as if the network contained several IP hops > with decrementing HopLimit fields, whereas here there seems to be a > single subnet. > >> LoWPAN Subnet >> >> A subnet including a LoWPAN or Extended LoWPAN, together with the >> backbone link sharing the same prefix. > > The same prefix and same prefix length? Sharing is confusing to me. I > don't think you meant to say the backbone link and the LoWPAN link had > the same prefixes and prefix lengths, respectively. > >> If a local or global prefix is included in the RA, the host may form >> an optimistic global unique address with stateless autoconfiguration. >> > What's local or global prefix? > > fe80::/10 is globally unique prefix yet local scope. > > An IPv6 address self-formed on Ethernet is globally unique yet local scope. > > ULA fc00 ? > > I'm not sure what you mean. > >> If the host moves to a different LoWPAN, with a different default >> prefix, the bootstrapping process is initiated again. > > Throughout the document I don't understand 'default' prefix. Are there > other alternative or preferred prefixes? > >> 6LoWPAN Prefix Information Option: This option includes information >> about the default subnet prefix for the LoWPAN along with other >> shared contexts for the subnet. > > Same, default prefix. > >> 4.4.3. Multihop Information Option >> >> This option identifies the set of prefix information options by a >> sequence number. This allows for the full set of prefix information >> options to be sent only periodically in unsolicited RAs. If a host >> detects a difference in the sequence number of this option, then the >> prefix information has likely changed, and is then requested with an RS. > > I'm not sure the term Multihop is appropriate to name this option? There > is no decrementing of HopLimit, it's a single subnet, thus no multihop. > > Or this Multihop means that it's multi-link-layer-hop? I'm not sure how > people call when my PC talks to a neighbor PC in the same subnet but > separated by 3 switches - is that Multihop? > >> A subnet is a collection of LoWPAN links interconnected by routers >> that may share one or more local or global prefixes. > > Local or global prefix. > >> The node might also form Unique Local and Global Unicast addresses, > > Is this Unique Local address an RFC4193 "Unique Local IPv6 Unicast > Addresses"? This could be clarified. > >> This specification includes a method for requesting a unique stateless >> address from the Edge Router by setting the 'A' flag in an >> Address Option during registration. > > Is this unique stateless address the same as the prior mentioned Unique > Local address, same as rfc4193? > >> To simplify address resolution it is assumed that LoWPAN nodes are >> assigned addresses in a homogeneous so that the unicast IPv6 addresses >> IID resolve directly to a corresponding link-layer address. >> Thus avoiding address resolution when possible. > > I'm afraid this way of avoiding NS-NA address resolution means > effectively forbidding manually assigned addresses - is this ok? > >> This specification includes a method for requesting a unique stateless >> address from the Edge Router by setting the 'A' flag in an >> Address Option during registration. > > A new mechanism to assign addresses? Why wouldn't DHCP be sufficient? > Maybe Stateless DHCP RFC3736? > >> then the ER aquires an appropriate, unique link-layer address for the >> network either by generating it and performing DAD, or with some >> other method. > > A link-layer address or a link-local address? I suppose the latter. > Although sometimes the link-layer ids are also negotiated... but not > sure one would DAD the link-layer address. > > Alex > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 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 eunah.ietf@gmail.com Wed Feb 11 18:38: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 092483A6916; Wed, 11 Feb 2009 18:38:03 -0800 (PST) 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 fvxSkYSzGn9y; Wed, 11 Feb 2009 18:38:01 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.155]) by core3.amsl.com (Postfix) with ESMTP id 87E713A67CF; Wed, 11 Feb 2009 18:38:01 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so1258766poe.4 for ; Wed, 11 Feb 2009 18:38:05 -0800 (PST) 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=uDuLq+0WTjvrGlpefjSKUuMVAb6+WpVPI6Mr6jiUafc=; b=s12LUKiXk5KWSQ8obCldImSNZRiwRHK4b9DOqWFHZL1Y+V65DxJ/LWq5SWa8LoAdSY p1GxuS1AlSZerduqWxFl9l2jRAcwMvCSbpltpvDHRPJ+on+GkF06cPWLO64adO4/TbZU 4ZlpXoGHZpR/pOqLEgU36FyqtgeDNJiPsgmWM= 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=Zup8YJuJSbIq+rvSUJGiVcji8tC7WmKRwZtDjL7VahTqQUQPw4kVoVR+V7CCiHoj+Y HrCe5tKjPPkcjf975+FdxSikJXCwZ9wavZZeMkKP35zeCeY9miczJD1y5KVa+/8GkFhF d5fjniDGUUWnzvR6fnVvg1g2D+qvAmVqdhGQI= MIME-Version: 1.0 Received: by 10.141.209.6 with SMTP id l6mr208041rvq.192.1234406285844; Wed, 11 Feb 2009 18:38:05 -0800 (PST) In-Reply-To: <4992FD7F.8070408@gmail.com> References: <4992FD7F.8070408@gmail.com> Date: Thu, 12 Feb 2009 11:38:05 +0900 Message-ID: <77f1dba80902111838g44541a6ubc347b0ce03abfa0@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 02:38:03 -0000 Dear Alex, Thank you very much for your detail comments. I think your comments help us clarify many points on the draft. I'm just about to leave to other town for a domestic biz trip. I will get back to you asap. Thanks, -eunah On Thu, Feb 12, 2009 at 1:31 AM, Alexandru Petrescu wrote: > [Where should I post this message, to 6LoWPAN or to ROLL list? Both?] > > Dear WG members, > > draft-ietf-6lowpan-routing-requirements-00 lists a Problem Statement, > some Scenarios and a set of Routing Requirements. Generally I find it a > well written document, with many meaningful details. > > There are very many parts of this document to which I silently agree, > even some parts I wholehartedly agree. I like the distinction > route-above mesh-under, and many other parts too. > > Some high-level questions: > -is there a requirement to connect a 6LoWPAN network to the Internet? > -is the 6LoWPAN using addressing architecture and longest-prefix match > based routing as in the Internet? > -how many interfaces will a 15.4 device have potentially? > > Following are detail questions and comments. I believe they're not as > important as the items mentioned above. > >> 1. Problem Statement > > Is this _the_ problem statement or should I better go read > draft-ietf-6lowpan-problem-08? They differ largely... > >> The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" [3]) >> briefly mentions four requirements on routing protocols; >> >> (a) low overhead on data packets >> >> (b) low routing overhead > > > What is routing more generally? Is it the act a router performs when > presenting with a packet, searching in a routing table, maybe exploring > its ND structures, maybe sending ND messages and then emitting the packet? > > Or is it exchanging IP datagrams containing prefixes and metrics and > reachability information, such that nodes have a common view of the > network paths? > > I think this is worth discussing, in order to better target what the > work should follow this problem statement and reqs. > > Are the low overhead requirements put on the database construction > messages? Or on the individual act of forwarding a packet? > >> On the other hand, the route-over approach relies on IP routing and >> therefore supports routing over possibly various types of interconnected >> links (see also Figure 1). > > At several places in the draft, when link 'types', device 'types' are > mentioned, I'm tempted to believe 6LoWPAN considers links other than > 802.15.4 links? Is it so? Should 6LoWPAN routing protocol work also > with aseptic point-to-point links? > > Or are the 'types' limited within the relatively large scope of 802.3 > compatible MACs (I believe 802.15.4 and 802.16 to fit within). > > This is of paramount importance in setting the scope. > >> The most significant consequence of mesh-under routing is that routing >> would be directly based on the IEEE 802.15.4 standard, > > Which 'routing' is directly based on 802.15.4 standard? The 'IP > routing' is based on that standard? This brings back to defining what > routing is. > > Maybe better call 'mesh-under routing' 'mesh-under switching'. > > IP routing and addressing may be fundamentally different than mesh-under > addressing and switching - in the way hosts get and maintain their > addresses and in the way routers/switches search their databases (exact > match vs longest-prefix). > >> When a route-over protocol is built in the IPv6 layer, the Dispatch value >> can be chosen as one of the Dispatch patterns for 6LoWPAN, compressed or >> uncompressed IPv6, followed by the IPv6 header. > > > Sorry, I can't parse this. > > A route-over protocol would act both at IP layer and > application/transport layers. Depends what a routing protocol is. For > example ICMP Redirect, or NEMOv6 or ND act at IP layer, whereas RIPng is > over UDP. > > 'followed by'... when reading left to right or reverse? > >> For route-over, a default route to the ER could be inserted into the >> routing system. > > In the routing system of the 6LoWPAN network? Or in the routing system > of the fixed Internet network? > >> IP-based low-power WPAN technology is still in its early stage of > > 'WPAN'? > >> a. Network Properties: >> >> * Number of Devices, Density and Network Diameter: These parameters >> usually affect the routing state directly (e.g. the number of >> entries in a routing table or neighbor list). Especially in large >> and dense networks, policies must > > What is 'large' and 'dense'? Is it about physical dimensions? Or IP > dimensions? > > Density sounds as a physical characteristic (many devices in a small > area) whereas Diameter sounds as a pure IP term (max number of IP hops). > > The number of entries in the routing table mostly depends on the planned > addressing architecture. One can have a very high-diameter network with > a very hierarchical addressing structures, many default routes, and very > few entries in the routing tables (maybe only 1 per hop). > > Is the addressing architecture for 6LoWPAN networks planned? > > Is the addressing architecture following the Internet model? > >> b. Node Parameters: > > How many interfaces does a 6LoWPAN node typically have? This is of > paramount importance deciding whether any type of repeating/bridging > needs to happen. > >> * Throughput: The maximum user data throughput of a bulk data >> transmission between a single sender and a single receiver through an >> unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as follows >> [19]: [...] >> >> In the case of 915 MHz band: > > Sorry, for my clarification: is 915MHz the width of band centered on > the 2.4GHz mentioned above? Or is it the central frequency (thus > replacing the "2.4GHz" mentioned above)? > >> [R02] 6LoWPAN routing protocols SHOULD cause minimal power consumption by >> the efficient use of control packets (e.g., minimize expensive multicast >> which cause broadcast to the entire LoWPAN) and by the efficient routing of >> data packets. > > YEs, but multicast may be more efficient than broadcast - is it > sufficient? I think it is sufficient to rely on multicast and avoid > unnecessary duplication such as in broadcast. > > 'Efficient routing of data packets' - is it also efficient search in the > routing table? That may be part of 'routing' too. > >> possibliy > > Nit: iy > >> [R03] 6LoWPAN routing protocol control messages SHOULD not create >> fragmentation of physical layer (PHY) frames. > > Err... I think PHY frames aren't fragmented... not sure I understand > this requirement? > > Sounds as if one wants an UDP control packets to not be sent in several > pieces, because of overhead involved fragmenting/reassembling. > > Then make sure first IP doesn't fragment. > >> Therefore, 6LoWPAN routing should not cause packets to exceed the IEEE >> 802.15.4 frame size [81bytes]. > > Is this a requirement on the mesh-under link-layer switching protocol? > Or on the 'route-above' protocol? If the latter - I think this > requirement is a violation of layer independence :-) > > It sounds very special to me to limit the size of the messages of an IP > routing protocol. > > Knowing that IP can fragment too. > >> [R05] The design of routing protocols for 6LoWPANs must consider the >> end-to-end latency requirements of applications and IEEE 802.15.4 link >> latency characteristics. > > 'Routing'? Or 'Transport'? end-to-end is what Transport typically > takes care of, not routing. > > If Routing: which routing? The forwarding ahppening at a node? Or the > convergence time? The exchange of routing messages? > >> Some routing protocols are aware of the hop count of a path. > > I think all of them are, no? > >> In homes, buildings, or infrastructure, some nodes will be installed >> with mains power. Such power-installed nodes MUST be > > If they have mains power - will they use Power-Line Communications? > >> Building monitoring applications, for instance, require that the mobile >> devices SHOULD be capable of leaving (handing-off) from an old >> network joining onto a new network within 15 seconds [17]. > > Should such a mobile device change its IP address or is it free to > change it? > >> [R13] 6LoWPAN routing protocol SHOULD support various traffic patterns; >> point-to-point, point-to-multipoint, and multipoint-to- point, while avoid >> excessive multicast traffic (broadcast in link layer) in 6LoWPAN. > > It's called multicast at link-layer too (802.3); thus it avoids > unnecessary packet duplication, thus it avoids duplication of > broadcasted packets and thus avoids excessive traffic. > > If we talk IPv6 and recent link layers then I mostly forget the term > 'broadcast' and use multicast instead. > >> 6LoWPAN routing protocols should be designed with the consideration of >> forwarding packets from/to multiple sources/destinations. > > Sorry, what do you mean? An IP packet with multiple src fields? > >> Current WG drafts in the ROLL working group explain that the workload >> or traffic pattern of use cases for 6LoWPANs tend to be highly >> structured, unlike the any- to-any data transfers that dominate typical >> client and server workloads. > > Sorry, what do you mean by 'any-to-any' data transfers? Any > relationship to 'IP anycast'? > >> [R14] 6LoWPAN protocols SHOULD support secure delivery of control >> messages. A minimal security level can be achieved by utilizing AES- >> based mechanism provided by IEEE 802.15.4. > > Isn't AES superstrong and thus computation intensive and thus > energy intensive? > > Intuitively speaking, maybe SHA-1 is sufficient for reduced needs in > constrained environments. > >> [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending "Hello" >> messages. > > ND doesn't send Hello messages, but NS, NA, RS and RA. > >> [R18] If the routing protocol functionality includes enabling IP >> multicast, then it may want to employ coordinator roles, if any, as relay >> points of group-targeting messages instead of using link-layer >> multicast (broadcast). > > link-layer multicast no broadcast. > > Nit: 'MAC sub-layer' appears only once and in the figure they're > all 'layers'. > > Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From eunah.ietf@gmail.com Mon Feb 16 02:28:52 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 501443A69A3; Mon, 16 Feb 2009 02:28:52 -0800 (PST) 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 z78qn4IDqA9u; Mon, 16 Feb 2009 02:28:50 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 50BED3A6BFB; Mon, 16 Feb 2009 02:28:50 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1454085rvb.49 for ; Mon, 16 Feb 2009 02:28:59 -0800 (PST) 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=vQypir/5yCKIRPmBhZUW3UgAuJ9bkkJtV9Dl+9GsGps=; b=gCWc4OoRL1RKKcJuRsf1vGpZb1zxac3WWw0+MJimFVA4l3l5qeuGjGSIO3o4iaWval MNC2FTjBNZxW05PI6Ek/+OUOl5H2H291fd5SW2teiSeiRlrzNSmE6vH3IzsBLLYHthbm ZR9epIyx07JGJN4dbvmbwLH4vDGjgZ6UpwMWQ= 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=iwiGNMZ9YjRptZZE80AX78KHagULhWqbzd47FiqIn6nB2HnLeVVNITVWAWEZk9KDz+ U4q8DanM2QAPevHKL4b2/CcFvddMW/jpc5iKvy/Ssm79AKTugOng+IUKABw1kDESYkz9 0Q4IvPKP/o3vT3dsvj4eUbkyys1qB/opFfqaU= MIME-Version: 1.0 Received: by 10.141.26.19 with SMTP id d19mr1204925rvj.184.1234780139359; Mon, 16 Feb 2009 02:28:59 -0800 (PST) In-Reply-To: <4992FD7F.8070408@gmail.com> References: <4992FD7F.8070408@gmail.com> Date: Mon, 16 Feb 2009 19:28:59 +0900 Message-ID: <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 10:28:52 -0000 Dear Alex, Thank again for your detail comments. As I told you before, it helps us to refine our draft. Some of your comments are about fundamental of 6LoWPAN, so I guess other 6LoWPANers may help me to give you some answers. Anyway, I put my thoughts in line. On Thu, Feb 12, 2009 at 1:31 AM, Alexandru Petrescu wrote: > [Where should I post this message, to 6LoWPAN or to ROLL list? Both?] > > Dear WG members, > > draft-ietf-6lowpan-routing-requirements-00 lists a Problem Statement, > some Scenarios and a set of Routing Requirements. Generally I find it a > well written document, with many meaningful details. > Thank you very much for your possitive comments. :) > There are very many parts of this document to which I silently agree, > even some parts I wholehartedly agree. I like the distinction > route-above mesh-under, and many other parts too. Thanks again. :) > > Some high-level questions: > -is there a requirement to connect a 6LoWPAN network to the Internet? Do you mean in terms of routing? Or a general view of 6LoWPAN? The birth of 6LoWPAN is to make the Low-power low rate network (based on IEEE 802.15.4) look like an IPv6 link. If you only meant routing, the reachability can be achieved by mesh routing (or mesh switching in your comment below) or route-over. I don't know if it answers your question. > -is the 6LoWPAN using addressing architecture and longest-prefix match > based routing as in the Internet? Alex, I think RFC 4944 may help your curiosity of 6lowpan fundamental. Although the header compression format is updating in 6lowpan now, you can find a basic needs of 6lowpan in the RFC. If I shortly explain, an IPv6 Interface Identifier is obtained from the 64-bit or 16-bit IEEE 802.15.4 address. The IPv6 link-local address for an IEEE 802.15.4 interface is formed by appending the Interface Identifier to a certain prefix (see Section 6 and Section 7 of RFC 4944). With regard to routing, I understand the answer is 'yes' in the case of route-over. Please kindly let me know if you already checked the RFC and your intention from the question was different from my answer. :) > -how many interfaces will a 15.4 device have potentially? > Well, currently, as I follow up, one interface only for a sensor node in 6LoWPAN. A gateway usually have more than one interface (e.g., 15.4 + 802.11 or others). > Following are detail questions and comments. I believe they're not as > important as the items mentioned above. > >> 1. Problem Statement > > Is this _the_ problem statement or should I better go read > draft-ietf-6lowpan-problem-08? They differ largely... First of all, just for your information, draft-ietf-6lowpan-problem-08 is now RFC 4919. The section 1, problem statement of our draft is focusing on routing in 6LoWPANs, and RFC 4919 states general problem of 6LoWPAN, including a brief requirement as you refered in the below. > >> The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" [3]) >> briefly mentions four requirements on routing protocols; >> >> (a) low overhead on data packets >> >> (b) low routing overhead > > > What is routing more generally? Is it the act a router performs when > presenting with a packet, searching in a routing table, maybe exploring > its ND structures, maybe sending ND messages and then emitting the packet? > > Or is it exchanging IP datagrams containing prefixes and metrics and > reachability information, such that nodes have a common view of the > network paths? I would say that it include all the functionalities needed for the selection of a path from source to destination. However, I should be careful use the term 'router' here. Although 6lowpan nodes may perform such routing functionality for the reachability, it's different from traditional term of 'router'. In route-over, they call 6lowpan nodes performing routing as 'routers' - One radio hop is a single IP link. However, in mesh-under, only one 6lowpan router exists in one 6lowpan (ER in Figure 2 of the draft) - Whole 6lowpan is One IPv6 link. To cover the both case, please understand in this way; 6LoWPAN node may perform such a 'routing-related functionalities'. > > I think this is worth discussing, in order to better target what the > work should follow this problem statement and reqs. > > Are the low overhead requirements put on the database construction > messages? Or on the individual act of forwarding a packet? I would say 'on both'. > >> On the other hand, the route-over approach relies on IP routing and >> therefore supports routing over possibly various types of interconnected >> links (see also Figure 1). > > At several places in the draft, when link 'types', device 'types' are > mentioned, I'm tempted to believe 6LoWPAN considers links other than > 802.15.4 links? Is it so? Should 6LoWPAN routing protocol work also > with aseptic point-to-point links? > Or are the 'types' limited within the relatively large scope of 802.3 > compatible MACs (I believe 802.15.4 and 802.16 to fit within). > > This is of paramount importance in setting the scope. > Oh, link 'type'. ;) Currently 6lowpan is clearly based on 802.15.4, although some talks that 6LoWPAN can run on top of other radios with similar characteristics. And, for route-over (as ROLL WG is working on), the benefit which have been insisted is that the routing mechanism is link-independent. Mesh-under of 6lowpan is 802.15.4 dependent. But I don't know what is 'aseptic' point to point links. >> The most significant consequence of mesh-under routing is that routing >> would be directly based on the IEEE 802.15.4 standard, > > Which 'routing' is directly based on 802.15.4 standard? The 'IP > routing' is based on that standard? This brings back to defining what > routing is. > Ah~ I think we should change the wording. I meant that the requirements of 6lowpan routing inherit the stringent characterisitcs of 802.15.4. I will change the text to make it clear. Thanks. :) > Maybe better call 'mesh-under routing' 'mesh-under switching'. > > IP routing and addressing may be fundamentally different than mesh-under > addressing and switching - in the way hosts get and maintain their > addresses and in the way routers/switches search their databases (exact > match vs longest-prefix). > Agreed. Either term is okay by me. Just due to the specific characteristics of 6lowpan configuration, multi-hop path selection can be achieved in mesh-under. I will ask others if mesh-under switching is better to be clarified. >> When a route-over protocol is built in the IPv6 layer, the Dispatch value >> can be chosen as one of the Dispatch patterns for 6LoWPAN, compressed or >> uncompressed IPv6, followed by the IPv6 header. > > > Sorry, I can't parse this. > > A route-over protocol would act both at IP layer and > application/transport layers. Depends what a routing protocol is. For > example ICMP Redirect, or NEMOv6 or ND act at IP layer, whereas RIPng is > over UDP. > > 'followed by'... when reading left to right or reverse? > When I read the text again, it can be confusing. I will try to rephrase it. 6LoPWAN provides compressed or uncompressed IPv6 header. It just wants to explain the relationship between 6lowpan header and routing header. You will get the information from RFC 4944. >> For route-over, a default route to the ER could be inserted into the >> routing system. > > In the routing system of the 6LoWPAN network? Or in the routing system > of the fixed Internet network? 6lowpan. I will also try to rephrase it to be clear. thanks. :) > >> IP-based low-power WPAN technology is still in its early stage of > > 'WPAN'? > wireless personal area network. 6lowpan = IPv6 over Low power WPAN. But, actually i think it's better to just use 6LoWPAN, to keep the consistancy of the document. I will change it. >> a. Network Properties: >> >> * Number of Devices, Density and Network Diameter: These parameters >> usually affect the routing state directly (e.g. the number of >> entries in a routing table or neighbor list). Especially in large >> and dense networks, policies must > > What is 'large' and 'dense'? Is it about physical dimensions? Or IP > dimensions? It is about physical dimensions. > > Density sounds as a physical characteristic (many devices in a small > area) whereas Diameter sounds as a pure IP term (max number of IP hops). > > The number of entries in the routing table mostly depends on the planned > addressing architecture. One can have a very high-diameter network with > a very hierarchical addressing structures, many default routes, and very > few entries in the routing tables (maybe only 1 per hop). > I fully agree with you. I will discuss woth co-authors and modify the text, since in the case of appropriate hierarchical addressing structures, what the text of the draft says may not be true. > Is the addressing architecture for 6LoWPAN networks planned? > > Is the addressing architecture following the Internet model? > can be both, i think. It's dependent on 6lowpan scenario. >> b. Node Parameters: > > How many interfaces does a 6LoWPAN node typically have? This is of > paramount importance deciding whether any type of repeating/bridging > needs to happen. In my view, currently one interface for 15.4, for normal 6lowpan nodes. > >> * Throughput: The maximum user data throughput of a bulk data >> transmission between a single sender and a single receiver through an >> unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as follows >> [19]: [...] >> >> In the case of 915 MHz band: > > Sorry, for my clarification: is 915MHz the width of band centered on > the 2.4GHz mentioned above? Or is it the central frequency (thus > replacing the "2.4GHz" mentioned above)? it is the central frequency. > >> [R02] 6LoWPAN routing protocols SHOULD cause minimal power consumption by >> the efficient use of control packets (e.g., minimize expensive multicast >> which cause broadcast to the entire LoWPAN) and by the efficient routing of >> data packets. > > YEs, but multicast may be more efficient than broadcast - is it > sufficient? I think it is sufficient to rely on multicast and avoid > unnecessary duplication such as in broadcast. > multicast may be more efficient. However, 802.15.4 does not support multicast. for 6lowpan's view, IP multicast is expensive in terms of energy usage for 6lowpan nodes. > 'Efficient routing of data packets' - is it also efficient search in the > routing table? That may be part of 'routing' too. > Good point. :) >> possibliy > > Nit: iy thanks. ;) > >> [R03] 6LoWPAN routing protocol control messages SHOULD not create >> fragmentation of physical layer (PHY) frames. > > Err... I think PHY frames aren't fragmented... not sure I understand > this requirement? > > Sounds as if one wants an UDP control packets to not be sent in several > pieces, because of overhead involved fragmenting/reassembling. > > Then make sure first IP doesn't fragment. > It means 6lowpan packet should not occur fragmentation. text will be modified to make it clear. thanks. >> Therefore, 6LoWPAN routing should not cause packets to exceed the IEEE >> 802.15.4 frame size [81bytes]. > > Is this a requirement on the mesh-under link-layer switching protocol? > Or on the 'route-above' protocol? If the latter - I think this > requirement is a violation of layer independence :-) > > It sounds very special to me to limit the size of the messages of an IP > routing protocol. > > Knowing that IP can fragment too. Yes, I know your argument. :) But it's 6lowpan specific requirement, and as I know many 6lowpaners are agreed on this one. I got a comment from one roll routing requirement author that this requirement can be considered in roll as well. I may make a chance to see you to explain some detail of 6lowpan before the meeting, if you are interested in? ;) > >> [R05] The design of routing protocols for 6LoWPANs must consider the >> end-to-end latency requirements of applications and IEEE 802.15.4 link >> latency characteristics. > > 'Routing'? Or 'Transport'? end-to-end is what Transport typically > takes care of, not routing. > > If Routing: which routing? The forwarding ahppening at a node? Or the > convergence time? The exchange of routing messages? > Erm.. maybe we should consider your comments more deeply. Carles, one of the authors suggested to remove 'end-to-end' from the text. The text meant all the mechanisms that are used to perform routing functions. >> Some routing protocols are aware of the hop count of a path. > > I think all of them are, no? The text is to explain that simple hop-count is not enough for 6lowpan. There exist Link quality based routing metrics than number of hops. > >> In homes, buildings, or infrastructure, some nodes will be installed >> with mains power. Such power-installed nodes MUST be > > If they have mains power - will they use Power-Line Communications? > Not necessarily. For communication with sensors/actuators, 802.15.4 radio communication is used, but supported by affluent power instead of small battery.. >> Building monitoring applications, for instance, require that the mobile >> devices SHOULD be capable of leaving (handing-off) from an old >> network joining onto a new network within 15 seconds [17]. > > Should such a mobile device change its IP address or is it free to > change it? > Actually, I don't aware such a case that 6lowpan nodes need to change the IP address yet. We just give the example of ROLL documents which are targeting specific applications, to explain some relavent work. >> [R13] 6LoWPAN routing protocol SHOULD support various traffic patterns; >> point-to-point, point-to-multipoint, and multipoint-to- point, while avoid >> excessive multicast traffic (broadcast in link layer) in 6LoWPAN. > > It's called multicast at link-layer too (802.3); thus it avoids > unnecessary packet duplication, thus it avoids duplication of > broadcasted packets and thus avoids excessive traffic. > > If we talk IPv6 and recent link layers then I mostly forget the term > 'broadcast' and use multicast instead. > As I explained before, we would like to avoid IP multicast. I will revise the text to make it clear as 'IP multicast'. >> 6LoWPAN routing protocols should be designed with the consideration of >> forwarding packets from/to multiple sources/destinations. > > Sorry, what do you mean? An IP packet with multiple src fields? > No, it means that some applications may have multiple sources that transmit data to one destination; or a single source may transmit data to several destination nodes; etc. >> Current WG drafts in the ROLL working group explain that the workload >> or traffic pattern of use cases for 6LoWPANs tend to be highly >> structured, unlike the any- to-any data transfers that dominate typical >> client and server workloads. > > Sorry, what do you mean by 'any-to-any' data transfers? Any > relationship to 'IP anycast'? No. but if IP anycast is used, it will be one way to implement any-to-any data transfer. > >> [R14] 6LoWPAN protocols SHOULD support secure delivery of control >> messages. A minimal security level can be achieved by utilizing AES- >> based mechanism provided by IEEE 802.15.4. > > Isn't AES superstrong and thus computation intensive and thus > energy intensive? > > Intuitively speaking, maybe SHA-1 is sufficient for reduced needs in > constrained environments. > The IEEE 802.15.4 specification mandates support of AES. So, it is given as an example of secure mechanism utilized from 802.15.4 features. >> [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending "Hello" >> messages. > > ND doesn't send Hello messages, but NS, NA, RS and RA. Ah~ Good point. we will make it clear for the revision. > >> [R18] If the routing protocol functionality includes enabling IP >> multicast, then it may want to employ coordinator roles, if any, as relay >> points of group-targeting messages instead of using link-layer >> multicast (broadcast). > > link-layer multicast no broadcast. I don't know if 'link-layer multicast' is a proper term when 802.15.4 does not provide multicast. > > Nit: 'MAC sub-layer' appears only once and in the figure they're > all 'layers'. > > Alex Thanks. we will change it. ;) Thank you very much to spend your time to review the documents. We will gather a bit more comments and will soon post the revision applying your comments. Your comments are always appreciated. :) Best Regards, -eunah > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From eunah.ietf@gmail.com Mon Feb 16 02:31:06 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99E5428C108 for <6lowpan@core3.amsl.com>; Mon, 16 Feb 2009 02:31:06 -0800 (PST) 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 yDBlwgg-naA0 for <6lowpan@core3.amsl.com>; Mon, 16 Feb 2009 02:31:05 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id A777328C0FE for <6lowpan@ietf.org>; Mon, 16 Feb 2009 02:31:05 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1454698rvb.49 for <6lowpan@ietf.org>; Mon, 16 Feb 2009 02:31:15 -0800 (PST) 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=fkJw71nfaz/avSQ6daQM7ReU3jI4tPKmAYM8OWGii6U=; b=b4fVVASVzZuoX3ayJtbEnjS97CBerw4sph39OnNMqVwYg54N1l319hL12aolYize3s 9BiDR9YB70LbbiZ8Qc0TZwh80kK9kvJAbS6Cfu7zUMxl21y08d2b4qKK02cnDDdFL0ik L4spwHWqMHvyQq0deObA1YwG68Ajq1pwGJSkg= 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=EoVMkSr0ICcrHR96iHrUZRuchjxP0U+ZEi6eJ6Vw0UjLF0wXbpFYnIDAHYyVCr9qJe 0tC0wLP9z0fsNwDGlgnY1j8kyYrSu9uABGTWzsZ+clwXRM+TmcyQCvzlCUMnjYOQfE32 8wRIV9K1KjMNU+E8O2Ea10CIINdiiFnZkeYnc= MIME-Version: 1.0 Received: by 10.141.137.6 with SMTP id p6mr2615915rvn.273.1234780275549; Mon, 16 Feb 2009 02:31:15 -0800 (PST) In-Reply-To: <4992E846.3080708@sensinode.com> References: <77f1dba80902102155x53ae53f5h62fad1839025498a@mail.gmail.com> <4992E846.3080708@sensinode.com> Date: Mon, 16 Feb 2009 19:31:15 +0900 Message-ID: <77f1dba80902160231j68e22766q40066d5c677fcd4@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] UPDATE '6LoWPAN Routing Requirements' 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, 16 Feb 2009 10:31:06 -0000 Zach, Thank you very much for your comment. The issue is already in the issue tracker. #1 is actually for that. We are revising the text. Thanks a lot, -eunah On Thu, Feb 12, 2009 at 12:01 AM, Zach Shelby wrote: > Hi, > > In Minneapolis, there was another comment that came up (from me, and some > others) which should be added as a ticket. Didn't notice it wasn't there > earlier, sorry. > > -00 of the draft is extremely IEEE 802.15.4 specific. The working group has > moved towards link-layer independence and has accepted that 6lowpan is being > used over other radio technologies in addition to 802.15.4. In fact, the new > HC and ND drafts are already written to be link-layer independent. > > My request is to make this draft more link-layer agnostic. I think it is > fine to use IEEE 802.15.4 as an example, however it should be mentioned and > considered that 6lowpan will be used over other low-power radios which may > have similar characteristics to 802.15.4, but surely not the exact same > mechanisms such as RFD/FFD and superframes. The use of these features in > practice in the industry is also marginal even for 802.15.4. > > On the same note - we need to correct this in RFC4944 as well either through > an update or replacing it. Making it clear to newcomers that 6lowpan is only > for 802.15.4. > > Thanks, > Zach > > Eunsook "Eunah" Kim wrote: >> >> Dear 6LoWPANers, >> >> For revision of the routing requirement documents, please give us your >> comments. >> Currently, we have 4 tickets at issue tracker. >> >> >> (http://trac.tools.ietf.org/wg/6lowpan/trac/query?component=routing-requirements) >> >> - #1: "Make sure interface to 15.4 is clear". >> One of the comments in Minneapolis >> was whether 6LoWPAN WG is assuming only the 802.15.4 frame format or the >> whole PHY/MAC protocol. >> >> - #2: "Improve discussion of mutual requirements of routing and header >> compression". >> the relation between routing and header compression, contexts, etc >> >> - #3: "Discuss hibernation-induced latency with the latency requirements". >> Latency may be affected by nodes hibernation, depending on the MAC used. >> Other MAC approaches than the legacy 802.15.4 may be used (e.g. TDMA) and >> duty cycling may also affect latency (and many other things). >> >> - #4: "Refine discussion on how MAC-layer ACKs can go into routing". >> There was a comment that 802.15.4 does not protect layer two >> acknowledgments. >> So many systems use data frames for acknowledgements. >> >> >> Please feel free to give us comments on these issues or any other >> issues for the revision. >> >> Greetings, >> -eunah >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > -- > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti > FINLAND > > mobile: +358 40 7796297 > > 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 Mon Feb 16 06:51:23 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB0A28B23E; Mon, 16 Feb 2009 06:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.105, 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 ZFZvrq5iy8Ma; Mon, 16 Feb 2009 06:51:21 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 0A61D3A6A9F; Mon, 16 Feb 2009 06:51:20 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1GEnj4H014307; Mon, 16 Feb 2009 15:49:45 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1GEpR6O005360; Mon, 16 Feb 2009 15:51:27 +0100 (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 n1GEpQN5011882; Mon, 16 Feb 2009 15:51:27 +0100 Message-ID: <49997D6E.2030409@gmail.com> Date: Mon, 16 Feb 2009 15:51:26 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Eunsook \"Eunah\" Kim" References: <4992FD7F.8070408@gmail.com> <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> In-Reply-To: <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org, ROLL WG Subject: Re: [6lowpan] [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 14:51:23 -0000 [I cut ROLL from the distribution list, because it seems I post too much on the ROLL list] Thanks for the message. I mainly agree with you. I commented on some of the text, below. Eunsook "Eunah" Kim a écrit : [...] >> Some high-level questions: >> -is there a requirement to connect a 6LoWPAN network to the Internet? > > Do you mean in terms of routing? Or a general view of 6LoWPAN? > The birth of 6LoWPAN is to make the Low-power low rate network (based > on IEEE 802.15.4) look like an IPv6 link. > > If you only meant routing, the reachability can be achieved by mesh > routing (or mesh switching in your comment below) or route-over. > > I don't know if it answers your question. If a network running 6LoWPAN routing system (designed according to 6lowpan-routing-requirements) is connected to the Internet - will anything break? >> -is the 6LoWPAN using addressing architecture and longest-prefix match >> based routing as in the Internet? > > Alex, I think RFC 4944 may help your curiosity of 6lowpan fundamental. > > Although the header compression format is updating in 6lowpan now, you > can find a basic needs of 6lowpan in the RFC. > If I shortly explain, an IPv6 Interface Identifier is obtained from > the 64-bit or 16-bit IEEE 802.15.4 address. The IPv6 link-local > address for an IEEE 802.15.4 interface is formed by appending the > Interface Identifier to a certain prefix (see Section 6 and Section 7 > of RFC 4944). With regard to routing, I understand the answer is 'yes' > in the case of route-over. > Please kindly let me know if you already checked the RFC and your > intention from the question was different from my answer. :) Yes, thanks for posting rfc4944, I checked it. Will the 6LoWPAN router use longest-prefix match (as IP protocols do) or exact-match (as some VLAN switch protocols do). Will the 6LoWPAN addressing architecture be local to the network, or integrated in the Internet. How is a link-local scoped solicited node multicast address mapped into an 802.15.4 address? rfc4944 says rightmost 2 bytes go into a 802.15.4 16-bit multicast address. But rfc4291 says a solicited node multicast address has the rightmost 3 octets as significant (FF02:0:0:0:0:1:FFXX:XXXX). Will NS/NA and DAD work ok on these links? >> -how many interfaces will a 15.4 device have potentially? >> > > Well, currently, as I follow up, one interface only for a sensor node > in 6LoWPAN. A gateway usually have more than one interface (e.g., 15.4 > + 802.11 or others). Well a sensor node which is supposed to do routing with only one interface will be different than a PC doing routing with two interfaces (the typical case). >> Following are detail questions and comments. I believe they're not as >> important as the items mentioned above. >> >>> 1. Problem Statement >> Is this _the_ problem statement or should I better go read >> draft-ietf-6lowpan-problem-08? They differ largely... > > First of all, just for your information, draft-ietf-6lowpan-problem-08 > is now RFC 4919. Ok, thanks. > The section 1, problem statement of our draft is focusing on routing > in 6LoWPANs, and RFC 4919 states general problem of 6LoWPAN, including > a brief requirement as you refered in the below. > >>> The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" [3]) >>> briefly mentions four requirements on routing protocols; >>> >>> (a) low overhead on data packets >>> >>> (b) low routing overhead >> >> What is routing more generally? Is it the act a router performs when >> presenting with a packet, searching in a routing table, maybe exploring >> its ND structures, maybe sending ND messages and then emitting the packet? >> >> Or is it exchanging IP datagrams containing prefixes and metrics and >> reachability information, such that nodes have a common view of the >> network paths? > > I would say that it include all the functionalities needed for the > selection of a path from source to destination. > However, I should be careful use the term 'router' here. > Although 6lowpan nodes may perform such routing functionality for the > reachability, it's different from traditional term of 'router'. > In route-over, they call 6lowpan nodes performing routing as 'routers' > - One radio hop is a single IP link. > However, in mesh-under, only one 6lowpan router exists in one 6lowpan > (ER in Figure 2 of the draft) - Whole 6lowpan is One IPv6 link. > To cover the both case, please understand in this way; 6LoWPAN node > may perform such a 'routing-related functionalities'. > >> I think this is worth discussing, in order to better target what the >> work should follow this problem statement and reqs. >> >> Are the low overhead requirements put on the database construction >> messages? Or on the individual act of forwarding a packet? > > I would say 'on both'. Ok. >>> On the other hand, the route-over approach relies on IP routing and >>> therefore supports routing over possibly various types of interconnected >>> links (see also Figure 1). >> At several places in the draft, when link 'types', device 'types' are >> mentioned, I'm tempted to believe 6LoWPAN considers links other than >> 802.15.4 links? Is it so? Should 6LoWPAN routing protocol work also >> with aseptic point-to-point links? >> Or are the 'types' limited within the relatively large scope of 802.3 >> compatible MACs (I believe 802.15.4 and 802.16 to fit within). >> >> This is of paramount importance in setting the scope. >> > > Oh, link 'type'. ;) Currently 6lowpan is clearly based on 802.15.4, > although some talks that 6LoWPAN can run on top of other radios with > similar characteristics. And, for route-over (as ROLL WG is working > on), the benefit which have been insisted is that the routing > mechanism is link-independent. Mesh-under of 6lowpan is 802.15.4 > dependent. > But I don't know what is 'aseptic' point to point links. Sorry, I meant 'aseptic' to say point-to-point links over which ND is not run actually, no need for ND nor DAD. They have specific ways in which the IPv6 link-local address is formed. They're often independent on the link layer technology. PPP over IPv6 (RFC) is an example. >>> The most significant consequence of mesh-under routing is that routing >>> would be directly based on the IEEE 802.15.4 standard, >> >> Which 'routing' is directly based on 802.15.4 standard? The 'IP >> routing' is based on that standard? This brings back to defining what >> routing is. >> > > Ah~ I think we should change the wording. I meant that the > requirements of 6lowpan routing inherit the stringent characterisitcs > of 802.15.4. I will change the text to make it clear. Thanks. :) Sure. >> Maybe better call 'mesh-under routing' 'mesh-under switching'. >> >> IP routing and addressing may be fundamentally different than mesh-under >> addressing and switching - in the way hosts get and maintain their >> addresses and in the way routers/switches search their databases (exact >> match vs longest-prefix). >> > > Agreed. Either term is okay by me. Just due to the specific > characteristics of 6lowpan configuration, > multi-hop path selection can be achieved in mesh-under. I will ask > others if mesh-under switching is better to be clarified. Ok. >>> When a route-over protocol is built in the IPv6 layer, the Dispatch value >>> can be chosen as one of the Dispatch patterns for 6LoWPAN, compressed or >>> uncompressed IPv6, followed by the IPv6 header. >> >> Sorry, I can't parse this. >> >> A route-over protocol would act both at IP layer and >> application/transport layers. Depends what a routing protocol is. For >> example ICMP Redirect, or NEMOv6 or ND act at IP layer, whereas RIPng is >> over UDP. >> >> 'followed by'... when reading left to right or reverse? >> > > When I read the text again, it can be confusing. I will try to rephrase it. > 6LoPWAN provides compressed or uncompressed IPv6 header. > It just wants to explain the relationship between 6lowpan header and > routing header. > You will get the information from RFC 4944. Ok. >>> For route-over, a default route to the ER could be inserted into the >>> routing system. >> In the routing system of the 6LoWPAN network? Or in the routing system >> of the fixed Internet network? > > 6lowpan. I will also try to rephrase it to be clear. thanks. :) Sure, it answers my question. >>> IP-based low-power WPAN technology is still in its early stage of >> 'WPAN'? >> > wireless personal area network. > 6lowpan = IPv6 over Low power WPAN. But, actually i think it's better > to just use 6LoWPAN, to keep the consistancy of the document. > I will change it. Ok, I meant to say WPAN surprisingly appears there first, without explanation. >>> a. Network Properties: >>> >>> * Number of Devices, Density and Network Diameter: These parameters >>> usually affect the routing state directly (e.g. the number of >>> entries in a routing table or neighbor list). Especially in large >>> and dense networks, policies must >> What is 'large' and 'dense'? Is it about physical dimensions? Or IP >> dimensions? > > It is about physical dimensions. I think Diameter has a physical sense only if it's a circle. I don't think networks have a physical shape of a circle. I may be wrong though. >> Density sounds as a physical characteristic (many devices in a small >> area) whereas Diameter sounds as a pure IP term (max number of IP hops). >> >> The number of entries in the routing table mostly depends on the planned >> addressing architecture. One can have a very high-diameter network with >> a very hierarchical addressing structures, many default routes, and very >> few entries in the routing tables (maybe only 1 per hop). >> > > I fully agree with you. I will discuss woth co-authors and modify the > text, since in the case of appropriate hierarchical addressing > structures, what the text of the draft says may not be true. Sure, thanks. >> Is the addressing architecture for 6LoWPAN networks planned? >> >> Is the addressing architecture following the Internet model? >> > > can be both, i think. It's dependent on 6lowpan scenario. > >>> b. Node Parameters: >> How many interfaces does a 6LoWPAN node typically have? This is of >> paramount importance deciding whether any type of repeating/bridging >> needs to happen. > > In my view, currently one interface for 15.4, for normal 6lowpan nodes. This is a distinguishing characteristic, routing with only one interface. >>> * Throughput: The maximum user data throughput of a bulk data >>> transmission between a single sender and a single receiver through an >>> unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as follows >>> [19]: [...] >>> >>> In the case of 915 MHz band: >> Sorry, for my clarification: is 915MHz the width of band centered on >> the 2.4GHz mentioned above? Or is it the central frequency (thus >> replacing the "2.4GHz" mentioned above)? > > it is the central frequency. Ok. >>> [R02] 6LoWPAN routing protocols SHOULD cause minimal power consumption by >>> the efficient use of control packets (e.g., minimize expensive multicast >>> which cause broadcast to the entire LoWPAN) and by the efficient routing of >>> data packets. >> YEs, but multicast may be more efficient than broadcast - is it >> sufficient? I think it is sufficient to rely on multicast and avoid >> unnecessary duplication such as in broadcast. >> > > multicast may be more efficient. However, 802.15.4 does not support multicast. > for 6lowpan's view, IP multicast is expensive in terms of energy usage > for 6lowpan nodes. Ok. >> 'Efficient routing of data packets' - is it also efficient search in the >> routing table? That may be part of 'routing' too. >> > > Good point. :) > >>> possibliy >> Nit: iy > > thanks. ;) > >>> [R03] 6LoWPAN routing protocol control messages SHOULD not create >>> fragmentation of physical layer (PHY) frames. >> Err... I think PHY frames aren't fragmented... not sure I understand >> this requirement? >> >> Sounds as if one wants an UDP control packets to not be sent in several >> pieces, because of overhead involved fragmenting/reassembling. >> >> Then make sure first IP doesn't fragment. >> > > It means 6lowpan packet should not occur fragmentation. text will be > modified to make it clear. thanks. > >>> Therefore, 6LoWPAN routing should not cause packets to exceed the IEEE >>> 802.15.4 frame size [81bytes]. >> Is this a requirement on the mesh-under link-layer switching protocol? >> Or on the 'route-above' protocol? If the latter - I think this >> requirement is a violation of layer independence :-) >> >> It sounds very special to me to limit the size of the messages of an IP >> routing protocol. >> >> Knowing that IP can fragment too. > > Yes, I know your argument. :) But it's 6lowpan specific requirement, > and as I know many 6lowpaners are agreed on this one. I got a comment > from one roll routing requirement author that this requirement can be > considered in roll as well. I may make a chance to see you to explain > some detail of 6lowpan before the meeting, if you are interested in? > ;) > >>> [R05] The design of routing protocols for 6LoWPANs must consider the >>> end-to-end latency requirements of applications and IEEE 802.15.4 link >>> latency characteristics. >> 'Routing'? Or 'Transport'? end-to-end is what Transport typically >> takes care of, not routing. >> >> If Routing: which routing? The forwarding ahppening at a node? Or the >> convergence time? The exchange of routing messages? >> > > Erm.. maybe we should consider your comments more deeply. Carles, one > of the authors suggested to remove 'end-to-end' from the text. The > text meant all the mechanisms that are used to perform routing > functions. I agree. >>> Some routing protocols are aware of the hop count of a path. >> I think all of them are, no? > > The text is to explain that simple hop-count is not enough for > 6lowpan. There exist Link quality based routing metrics than number of > hops. Ok. >>> In homes, buildings, or infrastructure, some nodes will be installed >>> with mains power. Such power-installed nodes MUST be >> If they have mains power - will they use Power-Line Communications? >> > > Not necessarily. For communication with sensors/actuators, 802.15.4 > radio communication is used, but supported by affluent power instead > of small battery.. > >>> Building monitoring applications, for instance, require that the mobile >>> devices SHOULD be capable of leaving (handing-off) from an old >>> network joining onto a new network within 15 seconds [17]. >> Should such a mobile device change its IP address or is it free to >> change it? >> > > Actually, I don't aware such a case that 6lowpan nodes need to change > the IP address yet. > We just give the example of ROLL documents which are targeting > specific applications, to explain some relavent work. Ok. >>> [R13] 6LoWPAN routing protocol SHOULD support various traffic patterns; >>> point-to-point, point-to-multipoint, and multipoint-to- point, while avoid >>> excessive multicast traffic (broadcast in link layer) in 6LoWPAN. >> It's called multicast at link-layer too (802.3); thus it avoids >> unnecessary packet duplication, thus it avoids duplication of >> broadcasted packets and thus avoids excessive traffic. >> >> If we talk IPv6 and recent link layers then I mostly forget the term >> 'broadcast' and use multicast instead. >> > > As I explained before, we would like to avoid IP multicast. I will > revise the text to make it clear as 'IP multicast'. > >>> 6LoWPAN routing protocols should be designed with the consideration of >>> forwarding packets from/to multiple sources/destinations. >> Sorry, what do you mean? An IP packet with multiple src fields? >> > > No, it means that some applications may have multiple sources that > transmit data to one destination; or a single source may transmit data > to several destination nodes; etc. That's much clearer. >>> Current WG drafts in the ROLL working group explain that the workload >>> or traffic pattern of use cases for 6LoWPANs tend to be highly >>> structured, unlike the any- to-any data transfers that dominate typical >>> client and server workloads. >> Sorry, what do you mean by 'any-to-any' data transfers? Any >> relationship to 'IP anycast'? > > No. but if IP anycast is used, it will be one way to implement > any-to-any data transfer. > >>> [R14] 6LoWPAN protocols SHOULD support secure delivery of control >>> messages. A minimal security level can be achieved by utilizing AES- >>> based mechanism provided by IEEE 802.15.4. >> Isn't AES superstrong and thus computation intensive and thus >> energy intensive? >> >> Intuitively speaking, maybe SHA-1 is sufficient for reduced needs in >> constrained environments. >> > > The IEEE 802.15.4 specification mandates support of AES. So, it is > given as an example of secure mechanism utilized from 802.15.4 > features. > >>> [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending "Hello" >>> messages. >> ND doesn't send Hello messages, but NS, NA, RS and RA. > > Ah~ Good point. we will make it clear for the revision. >>> [R18] If the routing protocol functionality includes enabling IP >>> multicast, then it may want to employ coordinator roles, if any, as relay >>> points of group-targeting messages instead of using link-layer >>> multicast (broadcast). >> link-layer multicast no broadcast. > > I don't know if 'link-layer multicast' is a proper term when 802.15.4 > does not provide multicast. Maybe that's a requirement to put on 802.15.4 not on 6LoWPAN. I mean it would be difficult to revive the 'broadcast' concept back into IPv6 documents, I suppose. Alex >> Nit: 'MAC sub-layer' appears only once and in the figure they're >> all 'layers'. >> >> Alex > > Thanks. we will change it. ;) > > Thank you very much to spend your time to review the documents. > We will gather a bit more comments and will soon post the revision > applying your comments. > Your comments are always appreciated. :) > > Best Regards, > -eunah > > >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > From hamid.mukhtar@gmail.com Mon Feb 16 09:41: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 72F583A68EF for <6lowpan@core3.amsl.com>; Mon, 16 Feb 2009 09:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 bPiPdnfzHW3c for <6lowpan@core3.amsl.com>; Mon, 16 Feb 2009 09:41:25 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.236]) by core3.amsl.com (Postfix) with ESMTP id 4E6AB3A68C8 for <6lowpan@ietf.org>; Mon, 16 Feb 2009 09:41:25 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id e34so1988864qbe.41 for <6lowpan@ietf.org>; Mon, 16 Feb 2009 09:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=NvLusyoLdXKj/ezd0ms2ydwWIdGzMTnYBezFcdAF3Y4=; b=AufEJwnpc1PS2LKt096MkCGbMjCaxestgVLN5bmlz+BJkaQjLdQozd+clwReQdzO2W Tl2Wuntgx+kRUSThio3pdY17RbzEL8et+snd4McRCwmq1HwbG82RWSpwolrMZtyVpbAL Ae314w161l6zBSokkrfGCYqQLP3jGJk/nzIOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Cg96fAbE7ym7R40ZF/rT9w7gHOpO2s0pXa0Fwy3vXSgiTz0yXtx8ZQM9E0qu1pc5VM o+DAje+f1q9Ejel+f8jfWDEEEtYo79EHxPocxUyU3fAPU3fG6Ilzmi+uRDQ3NuWOQLg8 LD9cHKizvxG5dYr6i7TD5vmUyCPBYOSLwKadU= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.141.36.17 with SMTP id o17mr2772221rvj.261.1234806093529; Mon, 16 Feb 2009 09:41:33 -0800 (PST) In-Reply-To: <49997D6E.2030409@gmail.com> References: <4992FD7F.8070408@gmail.com> <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> <49997D6E.2030409@gmail.com> Date: Tue, 17 Feb 2009 02:41:33 +0900 X-Google-Sender-Auth: 8c582521d70e991e Message-ID: From: Hamid Mukhtar To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 17:41:27 -0000 On Mon, Feb 16, 2009 at 11:51 PM, Alexandru Petrescu wrote: > > [I cut ROLL from the distribution list, because it seems I post too much > on the ROLL list] > > Thanks for the message. I mainly agree with you. I commented on some of= the text, below. > > Eunsook "Eunah" Kim a =E9crit : > [...] >>> >>> Some high-level questions: >>> -is there a requirement to connect a 6LoWPAN network to the Internet? >> >> Do you mean in terms of routing? Or a general view of 6LoWPAN? >> The birth of 6LoWPAN is to make the Low-power low rate network (based >> on IEEE 802.15.4) look like an IPv6 link. >> >> If you only meant routing, the reachability can be achieved by mesh >> routing (or mesh switching in your comment below) or route-over. >> >> I don't know if it answers your question. > > If a network running 6LoWPAN routing system (designed according to 6lowpa= n-routing-requirements) is connected to the Internet - will anything break? > >>> -is the 6LoWPAN using addressing architecture and longest-prefix match >>> based routing as in the Internet? >> >> Alex, I think RFC 4944 may help your curiosity of 6lowpan fundamental. > > > >> >> Although the header compression format is updating in 6lowpan now, you >> can find a basic needs of 6lowpan in the RFC. >> If I shortly explain, an IPv6 Interface Identifier is obtained from >> the 64-bit or 16-bit IEEE 802.15.4 address. The IPv6 link-local >> address for an IEEE 802.15.4 interface is formed by appending the >> Interface Identifier to a certain prefix (see Section 6 and Section 7 >> of RFC 4944). With regard to routing, I understand the answer is 'yes' >> in the case of route-over. >> Please kindly let me know if you already checked the RFC and your >> intention from the question was different from my answer. :) > > Yes, thanks for posting rfc4944, I checked it. > > Will the 6LoWPAN router use longest-prefix match (as IP protocols do) or = exact-match (as some VLAN switch protocols do). > > Will the 6LoWPAN addressing architecture be local to the network, or inte= grated in the Internet. RFC4944's HC1 supports both link-local and global addressing i.e. all 128 bits can be carried inline or the elided suffix can be derived from lower-layers. The new HC scheme also supports both types of addressing. > > How is a link-local scoped solicited node multicast address mapped into a= n 802.15.4 address? > > rfc4944 says rightmost 2 bytes go into a 802.15.4 16-bit multicast addres= s. > > But rfc4291 says a solicited node multicast address has the rightmost 3 o= ctets as significant (FF02:0:0:0:0:1:FFXX:XXXX). > > Will NS/NA and DAD work ok on these links? > The new HC format can handle this scenario http://tools.ietf.org/html/draft-ietf-6lowpan-hc it supports compression of the Solicited-Node Multicast Address (FF02::1:FFXX:XXXX). >>> -how many interfaces will a 15.4 device have potentially? >>> >> >> Well, currently, as I follow up, one interface only for a sensor node >> in 6LoWPAN. A gateway usually have more than one interface (e.g., 15.4 >> + 802.11 or others). > > Well a sensor node which is supposed to do routing with only one interfac= e will be different than a PC doing routing with two interfaces (the typica= l case). > >>> Following are detail questions and comments. I believe they're not as >>> important as the items mentioned above. >>> >>>> 1. Problem Statement >>> >>> Is this _the_ problem statement or should I better go read >>> draft-ietf-6lowpan-problem-08? They differ largely... >> >> First of all, just for your information, draft-ietf-6lowpan-problem-08 >> is now RFC 4919. > > Ok, thanks. > >> The section 1, problem statement of our draft is focusing on routing >> in 6LoWPANs, and RFC 4919 states general problem of 6LoWPAN, including >> a brief requirement as you refered in the below. >> >>>> The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" [= 3]) >>>> briefly mentions four requirements on routing protocols; >>>> >>>> (a) low overhead on data packets >>>> >>>> (b) low routing overhead >>> >>> What is routing more generally? Is it the act a router performs when >>> presenting with a packet, searching in a routing table, maybe exploring >>> its ND structures, maybe sending ND messages and then emitting the pack= et? >>> >>> Or is it exchanging IP datagrams containing prefixes and metrics and >>> reachability information, such that nodes have a common view of the >>> network paths? >> >> I would say that it include all the functionalities needed for the >> selection of a path from source to destination. >> However, I should be careful use the term 'router' here. >> Although 6lowpan nodes may perform such routing functionality for the >> reachability, it's different from traditional term of 'router'. >> In route-over, they call 6lowpan nodes performing routing as 'routers' >> - One radio hop is a single IP link. >> However, in mesh-under, only one 6lowpan router exists in one 6lowpan >> (ER in Figure 2 of the draft) - Whole 6lowpan is One IPv6 link. >> To cover the both case, please understand in this way; 6LoWPAN node >> may perform such a 'routing-related functionalities'. >> >>> I think this is worth discussing, in order to better target what the >>> work should follow this problem statement and reqs. >>> >>> Are the low overhead requirements put on the database construction >>> messages? Or on the individual act of forwarding a packet? >> >> I would say 'on both'. > > Ok. > >>>> On the other hand, the route-over approach relies on IP routing and >>>> therefore supports routing over possibly various types of interconnect= ed >>>> links (see also Figure 1). >>> >>> At several places in the draft, when link 'types', device 'types' are >>> mentioned, I'm tempted to believe 6LoWPAN considers links other than >>> 802.15.4 links? Is it so? Should 6LoWPAN routing protocol work also >>> with aseptic point-to-point links? >>> Or are the 'types' limited within the relatively large scope of 802.3 >>> compatible MACs (I believe 802.15.4 and 802.16 to fit within). >>> >>> This is of paramount importance in setting the scope. >>> >> >> Oh, link 'type'. ;) Currently 6lowpan is clearly based on 802.15.4, >> although some talks that 6LoWPAN can run on top of other radios with >> similar characteristics. And, for route-over (as ROLL WG is working >> on), the benefit which have been insisted is that the routing >> mechanism is link-independent. Mesh-under of 6lowpan is 802.15.4 >> dependent. >> But I don't know what is 'aseptic' point to point links. > > Sorry, I meant 'aseptic' to say point-to-point links over which ND is not= run actually, no need for ND nor DAD. They have specific ways in which th= e IPv6 link-local address is formed. They're often independent on the link= layer technology. PPP over IPv6 (RFC) is an example. > >>>> The most significant consequence of mesh-under routing is that routing >>>> would be directly based on the IEEE 802.15.4 standard, > > >> >>> >>> Which 'routing' is directly based on 802.15.4 standard? The 'IP >>> routing' is based on that standard? This brings back to defining what >>> routing is. >>> >> >> Ah~ I think we should change the wording. I meant that the >> requirements of 6lowpan routing inherit the stringent characterisitcs >> of 802.15.4. I will change the text to make it clear. Thanks. :) > > Sure. > >>> Maybe better call 'mesh-under routing' 'mesh-under switching'. >>> >>> IP routing and addressing may be fundamentally different than mesh-unde= r >>> addressing and switching - in the way hosts get and maintain their >>> addresses and in the way routers/switches search their databases (exact >>> match vs longest-prefix). >>> >> >> Agreed. Either term is okay by me. Just due to the specific >> characteristics of 6lowpan configuration, >> multi-hop path selection can be achieved in mesh-under. I will ask >> others if mesh-under switching is better to be clarified. > > Ok. > >>>> When a route-over protocol is built in the IPv6 layer, the Dispatch va= lue >>>> can be chosen as one of the Dispatch patterns for 6LoWPAN, compressed = or >>>> uncompressed IPv6, followed by the IPv6 header. >>> >>> Sorry, I can't parse this. >>> >>> A route-over protocol would act both at IP layer and >>> application/transport layers. Depends what a routing protocol is. For >>> example ICMP Redirect, or NEMOv6 or ND act at IP layer, whereas RIPng i= s >>> over UDP. >>> >>> 'followed by'... when reading left to right or reverse? >>> >> >> When I read the text again, it can be confusing. I will try to rephrase = it. >> 6LoPWAN provides compressed or uncompressed IPv6 header. >> It just wants to explain the relationship between 6lowpan header and >> routing header. >> You will get the information from RFC 4944. > > Ok. > >>>> For route-over, a default route to the ER could be inserted into the >>>> routing system. >>> >>> In the routing system of the 6LoWPAN network? Or in the routing system >>> of the fixed Internet network? >> >> 6lowpan. I will also try to rephrase it to be clear. thanks. :) > > Sure, it answers my question. > >>>> IP-based low-power WPAN technology is still in its early stage of >>> >>> 'WPAN'? >>> >> wireless personal area network. >> 6lowpan =3D IPv6 over Low power WPAN. But, actually i think it's better >> to just use 6LoWPAN, to keep the consistancy of the document. >> I will change it. > > Ok, I meant to say WPAN surprisingly appears there first, without explana= tion. > >>>> a. Network Properties: >>>> >>>> * Number of Devices, Density and Network Diameter: These parameters >>>> usually affect the routing state directly (e.g. the number of >>>> entries in a routing table or neighbor list). Especially in large >>>> and dense networks, policies must >>> >>> What is 'large' and 'dense'? Is it about physical dimensions? Or IP >>> dimensions? >> >> It is about physical dimensions. > > I think Diameter has a physical sense only if it's a circle. I don't thi= nk networks have a physical shape of a circle. I may be wrong though. > >>> Density sounds as a physical characteristic (many devices in a small >>> area) whereas Diameter sounds as a pure IP term (max number of IP hops)= . >>> >>> The number of entries in the routing table mostly depends on the planne= d >>> addressing architecture. One can have a very high-diameter network wit= h >>> a very hierarchical addressing structures, many default routes, and ver= y >>> few entries in the routing tables (maybe only 1 per hop). >>> >> >> I fully agree with you. I will discuss woth co-authors and modify the >> text, since in the case of appropriate hierarchical addressing >> structures, what the text of the draft says may not be true. > > Sure, thanks. > >>> Is the addressing architecture for 6LoWPAN networks planned? >>> >>> Is the addressing architecture following the Internet model? >>> >> >> can be both, i think. It's dependent on 6lowpan scenario. >> >>>> b. Node Parameters: >>> >>> How many interfaces does a 6LoWPAN node typically have? This is of >>> paramount importance deciding whether any type of repeating/bridging >>> needs to happen. >> >> In my view, currently one interface for 15.4, for normal 6lowpan nodes. > > This is a distinguishing characteristic, routing with only one interface. > >>>> * Throughput: The maximum user data throughput of a bulk data >>>> transmission between a single sender and a single receiver through an >>>> unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as fol= lows >>>> [19]: [...] >>>> >>>> In the case of 915 MHz band: >>> >>> Sorry, for my clarification: is 915MHz the width of band centered on >>> the 2.4GHz mentioned above? Or is it the central frequency (thus >>> replacing the "2.4GHz" mentioned above)? >> >> it is the central frequency. > > Ok. > >>>> [R02] 6LoWPAN routing protocols SHOULD cause minimal power consumption= by >>>> the efficient use of control packets (e.g., minimize expensive multica= st >>>> which cause broadcast to the entire LoWPAN) and by the efficient routi= ng of >>>> data packets. >>> >>> YEs, but multicast may be more efficient than broadcast - is it >>> sufficient? I think it is sufficient to rely on multicast and avoid >>> unnecessary duplication such as in broadcast. >>> >> >> multicast may be more efficient. However, 802.15.4 does not support mult= icast. >> for 6lowpan's view, IP multicast is expensive in terms of energy usage >> for 6lowpan nodes. > > Ok. > >>> 'Efficient routing of data packets' - is it also efficient search in th= e >>> routing table? That may be part of 'routing' too. >>> >> >> Good point. :) >> >>>> possibliy >>> >>> Nit: iy >> >> thanks. ;) >> >>>> [R03] 6LoWPAN routing protocol control messages SHOULD not create >>>> fragmentation of physical layer (PHY) frames. >>> >>> Err... I think PHY frames aren't fragmented... not sure I understand >>> this requirement? >>> >>> Sounds as if one wants an UDP control packets to not be sent in several >>> pieces, because of overhead involved fragmenting/reassembling. >>> >>> Then make sure first IP doesn't fragment. >>> >> >> It means 6lowpan packet should not occur fragmentation. text will be >> modified to make it clear. thanks. >> >>>> Therefore, 6LoWPAN routing should not cause packets to exceed the IEEE >>>> 802.15.4 frame size [81bytes]. >>> >>> Is this a requirement on the mesh-under link-layer switching protocol? >>> Or on the 'route-above' protocol? If the latter - I think this >>> requirement is a violation of layer independence :-) >>> >>> It sounds very special to me to limit the size of the messages of an IP >>> routing protocol. >>> >>> Knowing that IP can fragment too. >> >> Yes, I know your argument. :) But it's 6lowpan specific requirement, >> and as I know many 6lowpaners are agreed on this one. I got a comment >> from one roll routing requirement author that this requirement can be >> considered in roll as well. I may make a chance to see you to explain >> some detail of 6lowpan before the meeting, if you are interested in? >> ;) >> >>>> [R05] The design of routing protocols for 6LoWPANs must consider the >>>> end-to-end latency requirements of applications and IEEE 802.15.4 lin= k >>>> latency characteristics. >>> >>> 'Routing'? Or 'Transport'? end-to-end is what Transport typically >>> takes care of, not routing. >>> >>> If Routing: which routing? The forwarding ahppening at a node? Or the >>> convergence time? The exchange of routing messages? >>> >> >> Erm.. maybe we should consider your comments more deeply. Carles, one >> of the authors suggested to remove 'end-to-end' from the text. The >> text meant all the mechanisms that are used to perform routing >> functions. > > I agree. > >>>> Some routing protocols are aware of the hop count of a path. >>> >>> I think all of them are, no? >> >> The text is to explain that simple hop-count is not enough for >> 6lowpan. There exist Link quality based routing metrics than number of >> hops. > > Ok. > >>>> In homes, buildings, or infrastructure, some nodes will be installed >>>> with mains power. Such power-installed nodes MUST be >>> >>> If they have mains power - will they use Power-Line Communications? >>> >> >> Not necessarily. For communication with sensors/actuators, 802.15.4 >> radio communication is used, but supported by affluent power instead >> of small battery.. >> >>>> Building monitoring applications, for instance, require that the mobil= e >>>> devices SHOULD be capable of leaving (handing-off) from an old >>>> network joining onto a new network within 15 seconds [17]. >>> >>> Should such a mobile device change its IP address or is it free to >>> change it? >>> >> >> Actually, I don't aware such a case that 6lowpan nodes need to change >> the IP address yet. >> We just give the example of ROLL documents which are targeting >> specific applications, to explain some relavent work. > > Ok. > >>>> [R13] 6LoWPAN routing protocol SHOULD support various traffic patterns= ; >>>> point-to-point, point-to-multipoint, and multipoint-to- point, while a= void >>>> excessive multicast traffic (broadcast in link layer) in 6LoWPAN. >>> >>> It's called multicast at link-layer too (802.3); thus it avoids >>> unnecessary packet duplication, thus it avoids duplication of >>> broadcasted packets and thus avoids excessive traffic. >>> >>> If we talk IPv6 and recent link layers then I mostly forget the term >>> 'broadcast' and use multicast instead. >>> >> >> As I explained before, we would like to avoid IP multicast. I will >> revise the text to make it clear as 'IP multicast'. >> >>>> 6LoWPAN routing protocols should be designed with the consideration of >>>> forwarding packets from/to multiple sources/destinations. >>> >>> Sorry, what do you mean? An IP packet with multiple src fields? >>> >> >> No, it means that some applications may have multiple sources that >> transmit data to one destination; or a single source may transmit data >> to several destination nodes; etc. > > That's much clearer. > >>>> Current WG drafts in the ROLL working group explain that the workload >>>> or traffic pattern of use cases for 6LoWPANs tend to be highly >>>> structured, unlike the any- to-any data transfers that dominate typica= l >>>> client and server workloads. >>> >>> Sorry, what do you mean by 'any-to-any' data transfers? Any >>> relationship to 'IP anycast'? >> >> No. but if IP anycast is used, it will be one way to implement >> any-to-any data transfer. >> >>>> [R14] 6LoWPAN protocols SHOULD support secure delivery of control >>>> messages. A minimal security level can be achieved by utilizing AES- >>>> based mechanism provided by IEEE 802.15.4. >>> >>> Isn't AES superstrong and thus computation intensive and thus >>> energy intensive? >>> >>> Intuitively speaking, maybe SHA-1 is sufficient for reduced needs in >>> constrained environments. >>> >> >> The IEEE 802.15.4 specification mandates support of AES. So, it is >> given as an example of secure mechanism utilized from 802.15.4 >> features. >> >>>> [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending "He= llo" >>>> messages. >>> >>> ND doesn't send Hello messages, but NS, NA, RS and RA. >> >> Ah~ Good point. we will make it clear for the revision. >>>> >>>> [R18] If the routing protocol functionality includes enabling IP >>>> multicast, then it may want to employ coordinator roles, if any, as re= lay >>>> points of group-targeting messages instead of using link-layer >>>> multicast (broadcast). >>> >>> link-layer multicast no broadcast. >> >> I don't know if 'link-layer multicast' is a proper term when 802.15.4 >> does not provide multicast. > > Maybe that's a requirement to put on 802.15.4 not on 6LoWPAN. > > I mean it would be difficult to revive the 'broadcast' concept back into = IPv6 documents, I suppose. > > Alex > > >>> Nit: 'MAC sub-layer' appears only once and in the figure they're >>> all 'layers'. >>> >>> Alex >> >> Thanks. we will change it. ;) >> >> Thank you very much to spend your time to review the documents. >> We will gather a bit more comments and will soon post the revision >> applying your comments. >> Your comments are always appreciated. :) >> >> Best Regards, >> -eunah >> >> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan Regards, Hamid From dokaspar.ietf@gmail.com Mon Feb 16 14:14: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 1E95828C13F for <6lowpan@core3.amsl.com>; Mon, 16 Feb 2009 14:14:13 -0800 (PST) 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_72=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 tl0FxXjCa3PW for <6lowpan@core3.amsl.com>; Mon, 16 Feb 2009 14:14:12 -0800 (PST) Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id B886E28C13D for <6lowpan@ietf.org>; Mon, 16 Feb 2009 14:14:11 -0800 (PST) Received: by fxm13 with SMTP id 13so6357217fxm.13 for <6lowpan@ietf.org>; Mon, 16 Feb 2009 14:14:21 -0800 (PST) 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=R1wii2/frVWz2J6rFs7NvxFHEwLnNS8RhW17lWOoS1I=; b=vxf1O1z2bOzKKm0VJ154BnKk5i4Le4l//zEIup3lNK8le+w8tJPaq12QsaVz9faCr/ sEV7PppaWg+Ef3alHHZSaZvfZ7+GXetKufxZeH8DG3PoiBr4kFu/TT+2XVvA4d27w/ws IwFEhdH9EXaGYtBfOFxdkmeDsk9q0iXA1WUDE= 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=c29C6MnhWng88IR+KRQHRGnvdwExHx9TpMQPo7kML+kk0E+SAdBtjDIxbpqMf0zJfM wSm3GtkJMhxQYkaiSVUIKgdsQqD7YADT/jXXycsMWEOM9MT+FgUtUpqvGP3ry0MrKW4m eZ/D95nv+3zGXZfQpJVTycBGi07UJrVPCcBGw= MIME-Version: 1.0 Received: by 10.181.151.18 with SMTP id d18mr530938bko.183.1234822460922; Mon, 16 Feb 2009 14:14:20 -0800 (PST) In-Reply-To: <063.637170e9dd6fca588a52db4e9860d379@tools.ietf.org> References: <054.0a536d47022bd655d10a6af676b2f629@tools.ietf.org> <063.637170e9dd6fca588a52db4e9860d379@tools.ietf.org> Date: Mon, 16 Feb 2009 23:14:20 +0100 Message-ID: <2a3692de0902161414p6af274f0ua114c6c727727f08@mail.gmail.com> From: Dominik Kaspar To: 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: cabo@tzi.org Subject: Re: [6lowpan] #1: Make sure interface to 15.4 is clearly defined 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, 16 Feb 2009 22:14:13 -0000 Dear list, In the attempt of resolving issue #1, I came accross the following references to PAN coordinators: (1) In order to ease routing table updates and reduce error control messages, it would be helpful if nodes leaving the network inform their coordinator about their intention to disassociate. proposed change: In order to ease routing table updates, reduce their size, and minimize error control messages, nodes leaving the network may announce their disassociation to the closest edge router. (2) [R17] In case there are one or more nodes allocated to coordinator roles, the coordinators MAY take the role of keeping track of node association and de-association within the LoWPAN. proposed change: delete R17 (3) [R18] If the routing protocol functionality includes enabling IP multicast, then it may want to employ coordinator roles, if any, as relay points of group-targeting messages instead of using link-layer multicast (broadcast). proposed change: [R17] If the routing protocol functionality includes enabling IP multicast, then it may want to employ relay points of group-targeting messages instead of using link-layer multicast (broadcast). I've committed the proposed changes into the SVN repository. Best regards, Dominik On Thu, Nov 20, 2008 at 4:03 PM, 6lowpan issue tracker wrote: > #1: Make sure interface to 15.4 is clearly defined > ----------------------------------+----------------------------------------- > Reporter: cabo@tzi.org | Owner: cabo@tzi.org > Type: defect | Status: assigned > Priority: major | Milestone: > Component: routing-requirements | Version: > Severity: Active WG Document | Resolution: > Keywords: | > ----------------------------------+----------------------------------------- > > Comment(by cabo@tzi.org): > > - We should pay attention to whether we are assuming just 802.15.4 frame > format or the whole 802.15.4 protocol (including MAC features). > > -- > Ticket URL: > 6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From eunah.ietf@gmail.com Tue Feb 17 02:19: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 228E63A6A97; Tue, 17 Feb 2009 02:19:08 -0800 (PST) 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 uh1+CyD5cz1o; Tue, 17 Feb 2009 02:19:07 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 030903A65A5; Tue, 17 Feb 2009 02:19:06 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1886759rvb.49 for ; Tue, 17 Feb 2009 02:19:17 -0800 (PST) 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=/u645bGurOoggUmGJST06zE0mTObRl76Ppbd+0QRtPQ=; b=rNhU3f3kLv5phJndCUmF4TD/t7Hs9MIQ0PPKtiILyCLsC+RtN+9om2QxVUd8Rx/eo3 pPtF2bTA7WiuSs2LCQcrtJpGSpmrAeyPl53tSbmS+xTuVyYB52cL3d9Zb9PwY3PCioci YVDYwHu82W23sI8Itj0gFNzbWMYIG+U4oDRVg= 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=FMNQozU2XVSJfV47fy4OIPCwi3BiDaTtfHYQg5AViMmiaZ/ljRcXhrWm/XUH2ISTPt 4rwya2CfZx2J21e8RRNf2o5hUL8IhuDMGA8/48cW62S0+GdRhYp7Q1AkiKiIw9aUnXxw D3Edq2jMZDe3gPvIqmi0zWkp71feqaQ99D4Uo= MIME-Version: 1.0 Received: by 10.141.195.5 with SMTP id x5mr3189438rvp.282.1234865957235; Tue, 17 Feb 2009 02:19:17 -0800 (PST) In-Reply-To: <49997D6E.2030409@gmail.com> References: <4992FD7F.8070408@gmail.com> <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> <49997D6E.2030409@gmail.com> Date: Tue, 17 Feb 2009 19:19:17 +0900 Message-ID: <77f1dba80902170219r6a0b319awfffab6aef2abbfe9@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 10:19:08 -0000 Alex, Thanks again. :) I put my answers in line. > Thanks for the message. I mainly agree with you. I commented on some of > the text, below. > >>> Some high-level questions: >>> -is there a requirement to connect a 6LoWPAN network to the Internet? >> >> Do you mean in terms of routing? Or a general view of 6LoWPAN? >> The birth of 6LoWPAN is to make the Low-power low rate network (based >> on IEEE 802.15.4) look like an IPv6 link. >> >> If you only meant routing, the reachability can be achieved by mesh >> routing (or mesh switching in your comment below) or route-over. >> >> I don't know if it answers your question. > > If a network running 6LoWPAN routing system (designed according to > 6lowpan-routing-requirements) is connected to the Internet - will anything > break? > Basically, no I don't think so. But, I would like to explain two scenarios to consider. Let's consider the network like this: (a 6lowpan:A)--(gateway/ER)--(outside ipv6 network:B) 1. mesh-under: every node in A does routing (switching/forwarding/or other proper term) with MAC address within A. It is not directly do routing to a node in B. This mechanism is used for this limited situation, and many existing sensor networks based on 802.15.4 have been deployed fitting in the concept. 2. route-over: basically, it should be the same as traditional IPv6 routing, except the gateway needs to work on compression/decompression of IP/UDP.. headers. [snip..] > > Will the 6LoWPAN router use longest-prefix match (as IP protocols do) or > exact-match (as some VLAN switch protocols do). > In route-over, every intermediate node which performs routing fucntions is called 6lowpan router. I didn't see a runing route-over solution for 6LoWPAN yet. In my opinion, it will use as IP protocols do. (I understand that's the concept of route-over. I think ROLL people may answer it more clearly) In mesh-under, generally, one IPv6 router exists in one 6lowpan. 6lowpan nodes in the lowpan will perform routing functions but not use IPv6 address. Whole 6lowpan is one IPv6 link, and the IPv6 router of 6lowpan will act as a normal IPv6 router to communicate with other IPv6 router outside of the 6lowpan, but the functionality for inside of 6lowpan routing would differ (not use IPv6 addresses). I would like to know it helps you to understand better. > Will the 6LoWPAN addressing architecture be local to the network, or > integrated in the Internet. Both are supported. As Hamid already explained, the current 6LoWPAN format documents (RFC 4944 and HC1) supports both link-local and global addressing. >[snip..] >>>> On the other hand, the route-over approach relies on IP routing and >>>> therefore supports routing over possibly various types of interconnected >>>> links (see also Figure 1). >>> >>> At several places in the draft, when link 'types', device 'types' are >>> mentioned, I'm tempted to believe 6LoWPAN considers links other than >>> 802.15.4 links? Is it so? Should 6LoWPAN routing protocol work also >>> with aseptic point-to-point links? >>> Or are the 'types' limited within the relatively large scope of 802.3 >>> compatible MACs (I believe 802.15.4 and 802.16 to fit within). >>> >>> This is of paramount importance in setting the scope. >>> >> >> Oh, link 'type'. ;) Currently 6lowpan is clearly based on 802.15.4, >> although some talks that 6LoWPAN can run on top of other radios with >> similar characteristics. And, for route-over (as ROLL WG is working >> on), the benefit which have been insisted is that the routing >> mechanism is link-independent. Mesh-under of 6lowpan is 802.15.4 >> dependent. >> But I don't know what is 'aseptic' point to point links. > > Sorry, I meant 'aseptic' to say point-to-point links over which ND is not > run actually, no need for ND nor DAD. They have specific ways in which the > IPv6 link-local address is formed. They're often independent on the link > layer technology. PPP over IPv6 (RFC) is an example. > Oh, we need ND, and you already know the draft. :) >>>> a. Network Properties: >>>> >>>> * Number of Devices, Density and Network Diameter: These parameters >>>> usually affect the routing state directly (e.g. the number of >>>> entries in a routing table or neighbor list). Especially in large >>>> and dense networks, policies must >>> >>> What is 'large' and 'dense'? Is it about physical dimensions? Or IP >>> dimensions? >> >> It is about physical dimensions. > > I think Diameter has a physical sense only if it's a circle. I don't think > networks have a physical shape of a circle. I may be wrong though. > I also need to check. Maybe Carles (one of the co-authors who works on routing parameters) can answer it? ;) [snip..] >>>> [R18] If the routing protocol functionality includes enabling IP >>>> multicast, then it may want to employ coordinator roles, if any, as >>>> relay >>>> points of group-targeting messages instead of using link-layer >>>> multicast (broadcast). >>> >>> link-layer multicast no broadcast. >> >> I don't know if 'link-layer multicast' is a proper term when 802.15.4 >> does not provide multicast. > > Maybe that's a requirement to put on 802.15.4 not on 6LoWPAN. > > I mean it would be difficult to revive the 'broadcast' concept back into > IPv6 documents, I suppose. > Yes, i also think that it's great if 802.15.4 supports link-layer multicast. As it does not, 6lowpan wants to avoid IP multicast which causes link broadcast as much as possible. I should think what else term can be used instead of broadcast if it is not acceptable termniology. > Alex > Thanks again for your valuable comments. I'm working on revision to apply your considerations and comments. :) I will soon upload it. But please feel free to give your opinion in any moment. :) -eunah -eunah From eunah.ietf@gmail.com Tue Feb 17 02:29:57 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 111D33A6B83 for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 02:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=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 DSmfOwwHbn8V for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 02:29:56 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.152]) by core3.amsl.com (Postfix) with ESMTP id 3D0E03A6877 for <6lowpan@ietf.org>; Tue, 17 Feb 2009 02:29:56 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so8509999poe.4 for <6lowpan@ietf.org>; Tue, 17 Feb 2009 02:30:06 -0800 (PST) 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=xzbpEiqBWgtdGmTyWEk0wGPiL0DfzC4SBb4ge4Q0W4c=; b=BE08Z6yXN9bu/kIn5FKHPZRIgiFLqK6IyVro+Y+qt0WUUJGW2p8ZstBxbYzNwHuvOE +/KHU3DhAN2zyv9qdDtT2LA0eRAoUTc92mZP7Sd91r9yj3sY+mYaQWQgX6qk/Yj6jXPl /qLIjWeS1AE7gh+2tfHnGOo41wKuQ+y2o4Oko= 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=YmEk71djesj2MHOXnzJ7thkduR7u34+I2FAE0LPF1zKncuA/swL0D8794zWsyjMJ5k heUmQOpsuuZ2fyykmSgEktC3IeoDUyfxPTyaXoTXdnS3IX1HGFK/0nh2dNY1uZBfnpkd 6unpSpRS1Ct99h0rtt+CxQehpLw9yhZAe5bcQ= MIME-Version: 1.0 Received: by 10.141.115.6 with SMTP id s6mr3208646rvm.124.1234866606549; Tue, 17 Feb 2009 02:30:06 -0800 (PST) In-Reply-To: <2a3692de0902161414p6af274f0ua114c6c727727f08@mail.gmail.com> References: <054.0a536d47022bd655d10a6af676b2f629@tools.ietf.org> <063.637170e9dd6fca588a52db4e9860d379@tools.ietf.org> <2a3692de0902161414p6af274f0ua114c6c727727f08@mail.gmail.com> Date: Tue, 17 Feb 2009 19:30:06 +0900 Message-ID: <77f1dba80902170230ma71f8a2n651871a40d47f084@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: Dominik Kaspar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] #1: Make sure interface to 15.4 is clearly defined 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, 17 Feb 2009 10:29:57 -0000 Dominik, I agree on your proposed changes, except deleting R17. I would like to be careful to delete it. The requirement is added from comment. Can we think more if it is really not necessary requirement or if we can rephrase it? -eunah On Tue, Feb 17, 2009 at 7:14 AM, Dominik Kaspar wrote: > Dear list, > > In the attempt of resolving issue #1, I came accross the following > references to PAN coordinators: > > (1) > > In order to ease routing table updates and reduce error control > messages, it would be helpful if nodes leaving the network > inform their coordinator about their intention to disassociate. > > proposed change: > > In order to ease routing table updates, reduce their size, and > minimize error control messages, nodes leaving the network may > announce their disassociation to the closest edge router. > > (2) > > [R17] In case there are one or more nodes allocated to coordinator > roles, the coordinators MAY take the role of keeping track of node > association and de-association within the LoWPAN. > > proposed change: delete R17 > > (3) > > [R18] If the routing protocol functionality includes enabling IP > multicast, then it may want to employ coordinator roles, if any, as > relay points of group-targeting messages instead of using link-layer > multicast (broadcast). > > proposed change: > > [R17] If the routing protocol functionality includes enabling IP > multicast, then it may want to employ relay points of group-targeting > messages instead of using link-layer multicast (broadcast). > > I've committed the proposed changes into the SVN repository. > > Best regards, > Dominik > > > On Thu, Nov 20, 2008 at 4:03 PM, 6lowpan issue tracker > wrote: >> #1: Make sure interface to 15.4 is clearly defined >> ----------------------------------+----------------------------------------- >> Reporter: cabo@tzi.org | Owner: cabo@tzi.org >> Type: defect | Status: assigned >> Priority: major | Milestone: >> Component: routing-requirements | Version: >> Severity: Active WG Document | Resolution: >> Keywords: | >> ----------------------------------+----------------------------------------- >> >> Comment(by cabo@tzi.org): >> >> - We should pay attention to whether we are assuming just 802.15.4 frame >> format or the whole 802.15.4 protocol (including MAC features). >> >> -- >> Ticket URL: >> 6lowpan >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From dokaspar.ietf@gmail.com Tue Feb 17 02:44: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 7ADB13A684C for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 02:44:18 -0800 (PST) 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_72=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 x0xNwyiM1WTS for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 02:44:17 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 1A4F93A6A97 for <6lowpan@ietf.org>; Tue, 17 Feb 2009 02:44:16 -0800 (PST) Received: by bwz5 with SMTP id 5so3857953bwz.13 for <6lowpan@ietf.org>; Tue, 17 Feb 2009 02:44:26 -0800 (PST) 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=C/8sWQEFdTB/ExB3JLgOyEnbc48LEHVBbQT9sOg8iOQ=; b=gPSLCEbGqlddblbCS5LHSdtRrlpH/BbhZs/ZSHbnJsBFd27qdU4VS/iBRpVtcat6NJ 1FNJchVH4FHQm2n92JIzNpNq3kRGdftTNa+Sg53xBhl3TzBdFi14audUkZm9aq/TbHla yBXhwgitQVMQBI37sRJGyAFbahInP8baHZG8I= 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=VkCg+KBuSKEEZIEboQvfzIOHOao50SmLp0b5RZ/QeCXVvhc/RuBb20AkkWuENTFzI/ XAvZqN5Sz5fF04aQCmjE8XGoNhyA445r99D+xigXU2ZP3uQfBQpppX6QzXH21MsQhtb6 xtcso1t3AXTVxrG3AuOWfOW5ebxf8OFEPOjsw= MIME-Version: 1.0 Received: by 10.180.239.2 with SMTP id m2mr2006084bkh.8.1234867466731; Tue, 17 Feb 2009 02:44:26 -0800 (PST) In-Reply-To: <77f1dba80902170230ma71f8a2n651871a40d47f084@mail.gmail.com> References: <054.0a536d47022bd655d10a6af676b2f629@tools.ietf.org> <063.637170e9dd6fca588a52db4e9860d379@tools.ietf.org> <2a3692de0902161414p6af274f0ua114c6c727727f08@mail.gmail.com> <77f1dba80902170230ma71f8a2n651871a40d47f084@mail.gmail.com> Date: Tue, 17 Feb 2009 11:44:26 +0100 Message-ID: <2a3692de0902170244i3b970f93x5cf4efa5395500d8@mail.gmail.com> From: Dominik Kaspar To: Eunsook Eunah Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] #1: Make sure interface to 15.4 is clearly defined 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, 17 Feb 2009 10:44:18 -0000 Hi Eunah, About deleting R17, which looked like this: [R17] In case there are one or more nodes allocated to coordinator roles, the coordinators MAY take the role of keeping track of node association and de-association within the LoWPAN. There is already a list of device types and roles in the draft, but it does not include a coordinator type... so, in my opinion, either we add a coordinator type (if that exists in reality), or we delete R17. Greetings, Dominik On Tue, Feb 17, 2009 at 11:30 AM, Eunsook Eunah Kim wrote: > Dominik, > I agree on your proposed changes, except deleting R17. > I would like to be careful to delete it. The requirement is added from comment. > Can we think more if it is really not necessary requirement or if we > can rephrase it? > > -eunah > > On Tue, Feb 17, 2009 at 7:14 AM, Dominik Kaspar wrote: >> Dear list, >> >> In the attempt of resolving issue #1, I came accross the following >> references to PAN coordinators: >> >> (1) >> >> In order to ease routing table updates and reduce error control >> messages, it would be helpful if nodes leaving the network >> inform their coordinator about their intention to disassociate. >> >> proposed change: >> >> In order to ease routing table updates, reduce their size, and >> minimize error control messages, nodes leaving the network may >> announce their disassociation to the closest edge router. >> >> (2) >> >> [R17] In case there are one or more nodes allocated to coordinator >> roles, the coordinators MAY take the role of keeping track of node >> association and de-association within the LoWPAN. >> >> proposed change: delete R17 >> >> (3) >> >> [R18] If the routing protocol functionality includes enabling IP >> multicast, then it may want to employ coordinator roles, if any, as >> relay points of group-targeting messages instead of using link-layer >> multicast (broadcast). >> >> proposed change: >> >> [R17] If the routing protocol functionality includes enabling IP >> multicast, then it may want to employ relay points of group-targeting >> messages instead of using link-layer multicast (broadcast). >> >> I've committed the proposed changes into the SVN repository. >> >> Best regards, >> Dominik >> >> >> On Thu, Nov 20, 2008 at 4:03 PM, 6lowpan issue tracker >> wrote: >>> #1: Make sure interface to 15.4 is clearly defined >>> ----------------------------------+----------------------------------------- >>> Reporter: cabo@tzi.org | Owner: cabo@tzi.org >>> Type: defect | Status: assigned >>> Priority: major | Milestone: >>> Component: routing-requirements | Version: >>> Severity: Active WG Document | Resolution: >>> Keywords: | >>> ----------------------------------+----------------------------------------- >>> >>> Comment(by cabo@tzi.org): >>> >>> - We should pay attention to whether we are assuming just 802.15.4 frame >>> format or the whole 802.15.4 protocol (including MAC features). >>> >>> -- >>> Ticket URL: >>> 6lowpan >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > From carlesgo@entel.upc.edu Tue Feb 17 04:56:52 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 9D1D13A69CE for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 04:56:52 -0800 (PST) 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 0tnwXn5W7pe3 for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 04:56:51 -0800 (PST) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by core3.amsl.com (Postfix) with ESMTP id 8BBF83A6989 for <6lowpan@ietf.org>; Tue, 17 Feb 2009 04:56:50 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id n1HCufa9028538; Tue, 17 Feb 2009 13:56:41 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 7F1972CBD05; Tue, 17 Feb 2009 14:56:37 +0100 (CET) Received: from 62.57.232.106 by webmail.entel.upc.edu with HTTP; Tue, 17 Feb 2009 13:56:43 +0100 (CET) Message-ID: <60766.62.57.232.106.1234875403.squirrel@webmail.entel.upc.edu> In-Reply-To: <77f1dba80902170219r6a0b319awfffab6aef2abbfe9@mail.gmail.com> References: <4992FD7F.8070408@gmail.com> <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> <49997D6E.2030409@gmail.com> <77f1dba80902170219r6a0b319awfffab6aef2abbfe9@mail.gmail.com> Date: Tue, 17 Feb 2009 13:56:43 +0100 (CET) From: "Carles Gomez Montenegro" To: "Eunsook \"Eunah\" Kim" User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Tue, 17 Feb 2009 13:56:41 +0100 (CET) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 12:56:52 -0000 Hi Alex and list, Just a small comment, adding to Eunah's answers. Please see inline. [...] >>>>> a. Network Properties: >>>>> >>>>> * Number of Devices, Density and Network Diameter: These parameters >>>>> usually affect the routing state directly (e.g. the number of >>>>> entries in a routing table or neighbor list). Especially in large >>>>> and dense networks, policies must >>>> >>>> What is 'large' and 'dense'? Is it about physical dimensions? Or IP >>>> dimensions? >>> >>> It is about physical dimensions. >> >> I think Diameter has a physical sense only if it's a circle. I don't >> think >> networks have a physical shape of a circle. I may be wrong though. >> > > I also need to check. Maybe Carles (one of the co-authors who works on > routing parameters) can answer it? ;) Sure. 'Large' and 'dense' refer to physical dimensions. 'Network diameter' is actually a term used in graph theory. It refers to the maximum distance between any two vertices of the graph. In my opinion, 'network diameter' can be thought of from several points of view, depending on the layer at which the related graph is derived. For instance, communication between two nodes may be possible through a link, but depending on the routing strategy, such link may not be found out or used. Hence, the physical layer graph and the network layer graph may not be identical. Thanks Alex for the comment. We will try to address the fact that some of the mentioned parameters are mainly phisycal ones, while 'network diameter' may not. Carles From alexandru.petrescu@gmail.com Tue Feb 17 07:27:35 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 3C59E3A6A15 for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 07:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 CP1xMaolS-tz for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 07:27:34 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 15E593A67DD for <6lowpan@ietf.org>; Tue, 17 Feb 2009 07:27:33 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1HFRag8024131; Tue, 17 Feb 2009 16:27:36 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1HFRa7U020540; Tue, 17 Feb 2009 16:27:36 +0100 (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 n1HFRaLb031511; Tue, 17 Feb 2009 16:27:36 +0100 Message-ID: <499AD767.5050505@gmail.com> Date: Tue, 17 Feb 2009 16:27:35 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Hamid Mukhtar References: <4992FD7F.8070408@gmail.com> <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> <49997D6E.2030409@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 15:27:35 -0000 Hamid Mukhtar a écrit : > On Mon, Feb 16, 2009 at 11:51 PM, Alexandru Petrescu > wrote: >> [I cut ROLL from the distribution list, because it seems I post too much >> on the ROLL list] >> >> Thanks for the message. I mainly agree with you. I commented on some of the text, below. >> >> Eunsook "Eunah" Kim a écrit : >> [...] >>>> Some high-level questions: >>>> -is there a requirement to connect a 6LoWPAN network to the Internet? >>> Do you mean in terms of routing? Or a general view of 6LoWPAN? >>> The birth of 6LoWPAN is to make the Low-power low rate network (based >>> on IEEE 802.15.4) look like an IPv6 link. >>> >>> If you only meant routing, the reachability can be achieved by mesh >>> routing (or mesh switching in your comment below) or route-over. >>> >>> I don't know if it answers your question. >> If a network running 6LoWPAN routing system (designed according to 6lowpan-routing-requirements) is connected to the Internet - will anything break? >> >>>> -is the 6LoWPAN using addressing architecture and longest-prefix match >>>> based routing as in the Internet? >>> Alex, I think RFC 4944 may help your curiosity of 6lowpan fundamental. >>> >>> Although the header compression format is updating in 6lowpan now, you >>> can find a basic needs of 6lowpan in the RFC. >>> If I shortly explain, an IPv6 Interface Identifier is obtained from >>> the 64-bit or 16-bit IEEE 802.15.4 address. The IPv6 link-local >>> address for an IEEE 802.15.4 interface is formed by appending the >>> Interface Identifier to a certain prefix (see Section 6 and Section 7 >>> of RFC 4944). With regard to routing, I understand the answer is 'yes' >>> in the case of route-over. >>> Please kindly let me know if you already checked the RFC and your >>> intention from the question was different from my answer. :) >> Yes, thanks for posting rfc4944, I checked it. >> >> Will the 6LoWPAN router use longest-prefix match (as IP protocols do) or exact-match (as some VLAN switch protocols do). >> >> Will the 6LoWPAN addressing architecture be local to the network, or integrated in the Internet. > > > RFC4944's HC1 supports both link-local and global addressing i.e. all > 128 bits can be carried inline or the elided suffix can be derived > from lower-layers. > > The new HC scheme also supports both types of addressing. I have no doubts the header compression scheme can accommodate both global and link-local addresses. By 'local' I meant also Unique Local IPv6 Unicast Addresses (rfc4193). The discussion was around how is the IPv6 addressing architecture designed for a 6LoWPAN network. >> How is a link-local scoped solicited node multicast address mapped into an 802.15.4 address? >> >> rfc4944 says rightmost 2 bytes go into a 802.15.4 16-bit multicast address. >> >> But rfc4291 says a solicited node multicast address has the rightmost 3 octets as significant (FF02:0:0:0:0:1:FFXX:XXXX). >> >> Will NS/NA and DAD work ok on these links? >> > > The new HC format can handle this scenario > http://tools.ietf.org/html/draft-ietf-6lowpan-hc > > it supports compression of the Solicited-Node Multicast Address > (FF02::1:FFXX:XXXX). Ok, thanks for the message, I will check the HC draft. Alex From alexandru.petrescu@gmail.com Tue Feb 17 07:37: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 BB01D28C120 for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 07:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.095, 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 l1QLwzV+C93G for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 07:37:54 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9BF28C111 for <6lowpan@ietf.org>; Tue, 17 Feb 2009 07:37:54 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1HFaIBd012442; Tue, 17 Feb 2009 16:36:19 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1HFc1JQ002450; Tue, 17 Feb 2009 16:38:01 +0100 (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 n1HFc0Nf009753; Tue, 17 Feb 2009 16:38:01 +0100 Message-ID: <499AD9D8.7020602@gmail.com> Date: Tue, 17 Feb 2009 16:38:00 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Eunsook \"Eunah\" Kim" References: <4992FD7F.8070408@gmail.com> <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> <49997D6E.2030409@gmail.com> <77f1dba80902170219r6a0b319awfffab6aef2abbfe9@mail.gmail.com> In-Reply-To: <77f1dba80902170219r6a0b319awfffab6aef2abbfe9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 15:37:55 -0000 Eunsook "Eunah" Kim a écrit : > Alex, Thanks again. :) I put my answers in line. > >> Thanks for the message. I mainly agree with you. I commented on >> some of the text, below. >> >>>> Some high-level questions: -is there a requirement to connect a >>>> 6LoWPAN network to the Internet? >>> Do you mean in terms of routing? Or a general view of 6LoWPAN? >>> The birth of 6LoWPAN is to make the Low-power low rate network >>> (based on IEEE 802.15.4) look like an IPv6 link. >>> >>> If you only meant routing, the reachability can be achieved by >>> mesh routing (or mesh switching in your comment below) or >>> route-over. >>> >>> I don't know if it answers your question. >> If a network running 6LoWPAN routing system (designed according to >> 6lowpan-routing-requirements) is connected to the Internet - will >> anything break? >> > > Basically, no I don't think so. But, I would like to explain two > scenarios to consider. Let's consider the network like this: (a > 6lowpan:A)--(gateway/ER)--(outside ipv6 network:B) > > 1. mesh-under: every node in A does routing (switching/forwarding/or > other proper term) with MAC address within A. It is not directly do > routing to a node in B. This mechanism is used for this limited > situation, and many existing sensor networks based on 802.15.4 have > been deployed fitting in the concept. Makes sense to me, providfed the 6lowpanA) network is always connected at the left of that particular gatewayER, never elsewhere. > 2. route-over: basically, it should be the same as traditional IPv6 > routing, except the gateway needs to work on > compression/decompression of IP/UDP.. headers. I was not aware of that constraint. You seem to imply the 'route-over' capability requires the use of Header Compression. I will have to check the HC 6LoWPAN draft. >> Will the 6LoWPAN router use longest-prefix match (as IP protocols >> do) or exact-match (as some VLAN switch protocols do). >> > > In route-over, every intermediate node which performs routing > fucntions is called 6lowpan router. I didn't see a runing route-over > solution for 6LoWPAN yet. In my opinion, it will use as IP protocols > do. (I understand that's the concept of route-over. I think ROLL > people may answer it more clearly) In mesh-under, generally, one IPv6 > router exists in one 6lowpan. 6lowpan nodes in the lowpan will > perform routing functions but not use IPv6 address. Whole 6lowpan is > one IPv6 link, and the IPv6 router of 6lowpan will act as a normal > IPv6 router to communicate with other IPv6 router outside of the > 6lowpan, but the functionality for inside of 6lowpan routing would > differ (not use IPv6 addresses). I wouldn't call the route-over 'routing' (or perform routing functions) if it didn't use IP addresses. It's confusing. > I would like to know it helps you to understand better. > >> Will the 6LoWPAN addressing architecture be local to the network, >> or integrated in the Internet. > > Both are supported. As Hamid already explained, the current 6LoWPAN > format documents (RFC 4944 and HC1) supports both link-local and > global addressing. > >> [snip..] >>>>> On the other hand, the route-over approach relies on IP >>>>> routing and therefore supports routing over possibly various >>>>> types of interconnected links (see also Figure 1). >>>> At several places in the draft, when link 'types', device >>>> 'types' are mentioned, I'm tempted to believe 6LoWPAN considers >>>> links other than 802.15.4 links? Is it so? Should 6LoWPAN >>>> routing protocol work also with aseptic point-to-point links? >>>> Or are the 'types' limited within the relatively large scope of >>>> 802.3 compatible MACs (I believe 802.15.4 and 802.16 to fit >>>> within). >>>> >>>> This is of paramount importance in setting the scope. >>>> >>> Oh, link 'type'. ;) Currently 6lowpan is clearly based on >>> 802.15.4, although some talks that 6LoWPAN can run on top of >>> other radios with similar characteristics. And, for route-over >>> (as ROLL WG is working on), the benefit which have been insisted >>> is that the routing mechanism is link-independent. Mesh-under of >>> 6lowpan is 802.15.4 dependent. But I don't know what is 'aseptic' >>> point to point links. >> Sorry, I meant 'aseptic' to say point-to-point links over which ND >> is not run actually, no need for ND nor DAD. They have specific >> ways in which the IPv6 link-local address is formed. They're often >> independent on the link layer technology. PPP over IPv6 (RFC) is >> an example. >> > > Oh, we need ND, and you already know the draft. :) > >>>>> a. Network Properties: >>>>> >>>>> * Number of Devices, Density and Network Diameter: These >>>>> parameters usually affect the routing state directly (e.g. >>>>> the number of entries in a routing table or neighbor list). >>>>> Especially in large and dense networks, policies must >>>> What is 'large' and 'dense'? Is it about physical dimensions? >>>> Or IP dimensions? >>> It is about physical dimensions. >> I think Diameter has a physical sense only if it's a circle. I >> don't think networks have a physical shape of a circle. I may be >> wrong though. >> > > I also need to check. Maybe Carles (one of the co-authors who works > on routing parameters) can answer it? ;) > > [snip..] >>>>> [R18] If the routing protocol functionality includes enabling >>>>> IP multicast, then it may want to employ coordinator roles, >>>>> if any, as relay points of group-targeting messages instead >>>>> of using link-layer multicast (broadcast). >>>> link-layer multicast no broadcast. >>> I don't know if 'link-layer multicast' is a proper term when >>> 802.15.4 does not provide multicast. >> Maybe that's a requirement to put on 802.15.4 not on 6LoWPAN. >> >> I mean it would be difficult to revive the 'broadcast' concept back >> into IPv6 documents, I suppose. >> > Yes, i also think that it's great if 802.15.4 supports link-layer > multicast. As it does not, 6lowpan wants to avoid IP multicast which > causes link broadcast as much as possible. I should think what else > term can be used instead of broadcast if it is not acceptable > termniology. Well, at IEEE 802 link-layer, broadcast means 'ff:ff:ff:ff:ff:ff' address, whereas multicast means '33:33:0:0:0:X' address. Anything different has too many meanings. I would actually appreciate a lot if this link-layer multicast requirement went back to IEEE 802.15.4 instead of being addresses in an IETF draft. It risks being specified for the sake of specifying it, but implementations may simply go on and not use neither broadcast nor multicast. Just some thoughts. Alex From hamid.mukhtar@gmail.com Tue Feb 17 18:43: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 340953A6B6F for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 18:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 fF9ry8SaZLLY for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 18:43:53 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 5B6753A6941 for <6lowpan@ietf.org>; Tue, 17 Feb 2009 18:43:53 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2222935rvb.49 for <6lowpan@ietf.org>; Tue, 17 Feb 2009 18:44:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=nfj9iDuDmZ/iCJKIAJLtF5lc463rt8mXPOEcoaO6iLE=; b=RzMsNIq73x2vsu0sL4t3FWUP10+g2BztxzpWznRlopMLLrEaNkPRTC2T0VVAxZj+NU Rx3mmlRM+WWi/8t5rUbnvDYQa0U4LkQKdVRCLjbtdpwAyxOkC8cGvtx5RHJnqls84Rlu dUDaKitz2c+ULq7fSZQYnXyP4jNhoraid0FKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=niNyMg+HRDSv9iAUEqbjKAc9SVD2pBG4mXmQSNITquz/88p+gVMYm81+/iyTPoM1Bo L7hsp0I8uE3E9Gxu49LfPZBuprMrgq21Uq6ZE7V8y1DQUGrJZgRtkOmSu9PWvV2m+bF+ IFEvZs3q3KCjbLrnPac/Ely88IAV6nGpk98fM= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.140.136.5 with SMTP id j5mr1189570rvd.167.1234925043841; Tue, 17 Feb 2009 18:44:03 -0800 (PST) In-Reply-To: <499AD767.5050505@gmail.com> References: <4992FD7F.8070408@gmail.com> <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> <49997D6E.2030409@gmail.com> <499AD767.5050505@gmail.com> Date: Wed, 18 Feb 2009 11:44:03 +0900 X-Google-Sender-Auth: 2ffb69f47879c316 Message-ID: From: Hamid Mukhtar To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 02:43:54 -0000 On Wed, Feb 18, 2009 at 12:27 AM, Alexandru Petrescu wrote: > Hamid Mukhtar a =E9crit : >> >> On Mon, Feb 16, 2009 at 11:51 PM, Alexandru Petrescu >> wrote: >>> >>> [I cut ROLL from the distribution list, because it seems I post too muc= h >>> on the ROLL list] >>> >>> Thanks for the message. I mainly agree with you. I commented on some = of >>> the text, below. >>> >>> Eunsook "Eunah" Kim a =E9crit : >>> [...] >>>>> >>>>> Some high-level questions: >>>>> -is there a requirement to connect a 6LoWPAN network to the Internet? >>>> >>>> Do you mean in terms of routing? Or a general view of 6LoWPAN? >>>> The birth of 6LoWPAN is to make the Low-power low rate network (based >>>> on IEEE 802.15.4) look like an IPv6 link. >>>> >>>> If you only meant routing, the reachability can be achieved by mesh >>>> routing (or mesh switching in your comment below) or route-over. >>>> >>>> I don't know if it answers your question. >>> >>> If a network running 6LoWPAN routing system (designed according to >>> 6lowpan-routing-requirements) is connected to the Internet - will anyth= ing >>> break? >>> >>>>> -is the 6LoWPAN using addressing architecture and longest-prefix matc= h >>>>> based routing as in the Internet? >>>> >>>> Alex, I think RFC 4944 may help your curiosity of 6lowpan fundamental. >>>> >>>> Although the header compression format is updating in 6lowpan now, you >>>> can find a basic needs of 6lowpan in the RFC. >>>> If I shortly explain, an IPv6 Interface Identifier is obtained from >>>> the 64-bit or 16-bit IEEE 802.15.4 address. The IPv6 link-local >>>> address for an IEEE 802.15.4 interface is formed by appending the >>>> Interface Identifier to a certain prefix (see Section 6 and Section 7 >>>> of RFC 4944). With regard to routing, I understand the answer is 'yes' >>>> in the case of route-over. >>>> Please kindly let me know if you already checked the RFC and your >>>> intention from the question was different from my answer. :) >>> >>> Yes, thanks for posting rfc4944, I checked it. >>> >>> Will the 6LoWPAN router use longest-prefix match (as IP protocols do) o= r >>> exact-match (as some VLAN switch protocols do). >>> >>> Will the 6LoWPAN addressing architecture be local to the network, or >>> integrated in the Internet. >> >> >> RFC4944's HC1 supports both link-local and global addressing i.e. all >> 128 bits can be carried inline or the elided suffix can be derived >> from lower-layers. >> >> The new HC scheme also supports both types of addressing. > > I have no doubts the header compression scheme can accommodate both globa= l > and link-local addresses. > > By 'local' I meant also Unique Local IPv6 Unicast Addresses (rfc4193). > > The discussion was around how is the IPv6 addressing architecture designe= d > for a 6LoWPAN network. > For the 6LoWPAN side the IIDs are derived from the lower-layers. As per my understanding of 6LoWPAN, the Unique Local Addresses (ULAs) are not utilised for local communication i.e. for local communication the addresses are link-local addresses with prefix elided. However, for communication with nodes outside 6LoWPAN the 6LoWPAN node's prefix can either be a global prefix or a ULA's prefix. >>> How is a link-local scoped solicited node multicast address mapped into >>> an 802.15.4 address? >>> >>> rfc4944 says rightmost 2 bytes go into a 802.15.4 16-bit multicast >>> address. >>> >>> But rfc4291 says a solicited node multicast address has the rightmost 3 >>> octets as significant (FF02:0:0:0:0:1:FFXX:XXXX). >>> >>> Will NS/NA and DAD work ok on these links? >>> >> >> The new HC format can handle this scenario >> http://tools.ietf.org/html/draft-ietf-6lowpan-hc >> >> it supports compression of the Solicited-Node Multicast Address >> (FF02::1:FFXX:XXXX). > > Ok, thanks for the message, I will check the HC draft. > > Alex > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > Regards, Hamid From eunah.ietf@gmail.com Tue Feb 17 18:59: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 1F12E3A68A4 for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 18:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 hydzqphis-9Z for <6lowpan@core3.amsl.com>; Tue, 17 Feb 2009 18:59:11 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.153]) by core3.amsl.com (Postfix) with ESMTP id 2B6DC3A67D7 for <6lowpan@ietf.org>; Tue, 17 Feb 2009 18:59:10 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so9305282poe.4 for <6lowpan@ietf.org>; Tue, 17 Feb 2009 18:59:21 -0800 (PST) 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=UUfsCsYxPCQ/jwGZq2zDJCW7yam5w3EbrBB1QSPzo6Q=; b=oitKcI5zapZPY2mHcuW4oDVGmQnd+lVSwhAXHDHqw6LJntiwNpwgT5JlDmbJcfG/QN O01Mr9n2+TLnzGpFKXBQd2ISEPUCtMbFL5ZbLZDz+zp+x0k5TfApW7fG6T4zj4v5zQb3 HJSwFrd8DxGOQHPAFOOqhb0qQMuXwIumDGQnA= 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=fhbVeSNNIkINfq96dTJxQ882Qi2wa1YLsLqMpZXkt5kn59eEqkGcLMpf+MNx8SnbFm 6bZR+3Oz4++PaHJ7XjFMMsWhTLMjKA/rZZ0oM7IFDxecYZrg1BF7tnFSWpZAOryYcluQ QuDAMbwPKcspZdhQGeehUbOY/6Qq3DNil28Sk= MIME-Version: 1.0 Received: by 10.140.193.15 with SMTP id q15mr3632579rvf.274.1234925961467; Tue, 17 Feb 2009 18:59:21 -0800 (PST) In-Reply-To: <499AD9D8.7020602@gmail.com> References: <4992FD7F.8070408@gmail.com> <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> <49997D6E.2030409@gmail.com> <77f1dba80902170219r6a0b319awfffab6aef2abbfe9@mail.gmail.com> <499AD9D8.7020602@gmail.com> Date: Wed, 18 Feb 2009 11:59:21 +0900 Message-ID: <77f1dba80902171859w780f8e96s1d85bcccc42ca380@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 02:59:12 -0000 Dear Alex, There are misunderstanding, so I would like to clarify them. Thanks. > >> 2. route-over: basically, it should be the same as traditional IPv6 >> routing, except the gateway needs to work on >> compression/decompression of IP/UDP.. headers. > > I was not aware of that constraint. You seem to imply the 'route-over' > capability requires the use of Header Compression. I will have to check > the HC 6LoWPAN draft. > Oh, no. ROUTING mechanism WON"T require header compression/decompression. Routing will be included after IP/UDP, or where the routing protocol is designed in. I just gave you an example of 6lowpan network to communicate with non-6lowpan. Just what I want to say was you need decoding 6lowpan_header for the communication. It's not the routing role. >>> Will the 6LoWPAN router use longest-prefix match (as IP protocols >>> do) or exact-match (as some VLAN switch protocols do). >>> >> >> In route-over, every intermediate node which performs routing fucntions is >> called 6lowpan router. I didn't see a runing route-over >> solution for 6LoWPAN yet. In my opinion, it will use as IP protocols >> do. (I understand that's the concept of route-over. I think ROLL >> people may answer it more clearly) In mesh-under, generally, one IPv6 >> router exists in one 6lowpan. 6lowpan nodes in the lowpan will >> perform routing functions but not use IPv6 address. Whole 6lowpan is >> one IPv6 link, and the IPv6 router of 6lowpan will act as a normal >> IPv6 router to communicate with other IPv6 router outside of the >> 6lowpan, but the functionality for inside of 6lowpan routing would >> differ (not use IPv6 addresses). > > I wouldn't call the route-over 'routing' (or perform routing functions) > if it didn't use IP addresses. It's confusing. > Mesh-under doesn't use IP address. Route-over uses IP address. As I understand, Route-over for LoWPAN or LLNs is the same like other IP based routing. So far, mesh-under was widely-understood way to make a multi-hop connection in LoWPAN, and ROLL was born to make IP based routing for it. So it uses IP address for routing. >> [snip..] >>>>>> >>>>>> [R18] If the routing protocol functionality includes enabling >>>>>> IP multicast, then it may want to employ coordinator roles, >>>>>> if any, as relay points of group-targeting messages instead >>>>>> of using link-layer multicast (broadcast). >>>>> >>>>> link-layer multicast no broadcast. >>>> >>>> I don't know if 'link-layer multicast' is a proper term when >>>> 802.15.4 does not provide multicast. >>> >>> Maybe that's a requirement to put on 802.15.4 not on 6LoWPAN. >>> >>> I mean it would be difficult to revive the 'broadcast' concept back >>> into IPv6 documents, I suppose. >>> >> Yes, i also think that it's great if 802.15.4 supports link-layer >> multicast. As it does not, 6lowpan wants to avoid IP multicast which >> causes link broadcast as much as possible. I should think what else >> term can be used instead of broadcast if it is not acceptable >> termniology. > > Well, at IEEE 802 link-layer, broadcast means 'ff:ff:ff:ff:ff:ff' > address, whereas multicast means '33:33:0:0:0:X' address. Anything > different has too many meanings. > > I would actually appreciate a lot if this link-layer multicast > requirement went back to IEEE 802.15.4 instead of being addresses in an > IETF draft. It risks being specified for the sake of specifying it, but > implementations may simply go on and not use neither broadcast nor > multicast. > > Just some thoughts. > > Alex > 6lowpan is on 802.15.4, and IP multicast will go all nodes in the lowpan which is energy-expensive for lowpan nodes. Thus, i think such a restraint of all-nodes receiving packets is necessary to be considered when we design a solution for lowpan. And, in my opinion, this is well-agreed issue for 6lowpaners. (RFC 4944 also mentioned it) If we avoid to say broadcasting issue, can you help me to find how we contain such a requirement, based on IETF conventional way? :) Thank you much, -eunah From alexandru.petrescu@gmail.com Wed Feb 18 03:39: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 C6A9B28C202 for <6lowpan@core3.amsl.com>; Wed, 18 Feb 2009 03:39:32 -0800 (PST) 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 m3HDJCfLFcNi for <6lowpan@core3.amsl.com>; Wed, 18 Feb 2009 03:39:31 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id C06673A6C62 for <6lowpan@ietf.org>; Wed, 18 Feb 2009 03:39:19 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1IBdOdl007777; Wed, 18 Feb 2009 12:39:24 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1IBdOKL012056; Wed, 18 Feb 2009 12:39:24 +0100 (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 n1IBdKNO008774; Wed, 18 Feb 2009 12:39:21 +0100 Message-ID: <499BF368.2070906@gmail.com> Date: Wed, 18 Feb 2009 12:39:20 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Hamid Mukhtar References: <4992FD7F.8070408@gmail.com> <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> <49997D6E.2030409@gmail.com> <499AD767.5050505@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 11:39:32 -0000 Hamid Mukhtar a écrit : > On Wed, Feb 18, 2009 at 12:27 AM, Alexandru Petrescu > wrote: >> Hamid Mukhtar a écrit : >>> On Mon, Feb 16, 2009 at 11:51 PM, Alexandru Petrescu >>> wrote: >>>> [I cut ROLL from the distribution list, because it seems I post >>>> too much on the ROLL list] >>>> >>>> Thanks for the message. I mainly agree with you. I commented >>>> on some of the text, below. >>>> >>>> Eunsook "Eunah" Kim a écrit : [...] >>>>>> Some high-level questions: -is there a requirement to >>>>>> connect a 6LoWPAN network to the Internet? >>>>> Do you mean in terms of routing? Or a general view of >>>>> 6LoWPAN? The birth of 6LoWPAN is to make the Low-power low >>>>> rate network (based on IEEE 802.15.4) look like an IPv6 link. >>>>> >>>>> >>>>> >>>>> >>>>> If you only meant routing, the reachability can be achieved >>>>> by mesh routing (or mesh switching in your comment below) or >>>>> route-over. >>>>> >>>>> I don't know if it answers your question. >>>> If a network running 6LoWPAN routing system (designed according >>>> to 6lowpan-routing-requirements) is connected to the Internet >>>> - will anything break? >>>> >>>>>> -is the 6LoWPAN using addressing architecture and >>>>>> longest-prefix match based routing as in the Internet? >>>>> Alex, I think RFC 4944 may help your curiosity of 6lowpan >>>>> fundamental. >>>>> >>>>> Although the header compression format is updating in 6lowpan >>>>> now, you can find a basic needs of 6lowpan in the RFC. If I >>>>> shortly explain, an IPv6 Interface Identifier is obtained >>>>> from the 64-bit or 16-bit IEEE 802.15.4 address. The IPv6 >>>>> link-local address for an IEEE 802.15.4 interface is formed >>>>> by appending the Interface Identifier to a certain prefix >>>>> (see Section 6 and Section 7 of RFC 4944). With regard to >>>>> routing, I understand the answer is 'yes' in the case of >>>>> route-over. Please kindly let me know if you already checked >>>>> the RFC and your intention from the question was different >>>>> from my answer. :) >>>> Yes, thanks for posting rfc4944, I checked it. >>>> >>>> Will the 6LoWPAN router use longest-prefix match (as IP >>>> protocols do) or exact-match (as some VLAN switch protocols >>>> do). >>>> >>>> Will the 6LoWPAN addressing architecture be local to the >>>> network, or integrated in the Internet. >>> >>> RFC4944's HC1 supports both link-local and global addressing i.e. >>> all 128 bits can be carried inline or the elided suffix can be >>> derived from lower-layers. >>> >>> The new HC scheme also supports both types of addressing. >> I have no doubts the header compression scheme can accommodate both >> global and link-local addresses. >> >> By 'local' I meant also Unique Local IPv6 Unicast Addresses >> (rfc4193). >> >> The discussion was around how is the IPv6 addressing architecture >> designed for a 6LoWPAN network. >> > > For the 6LoWPAN side the IIDs are derived from the lower-layers. Ok, but there should be freedom for manual configuration of global addresses as well. Or for use of DHCPv6. > As per my understanding of 6LoWPAN, the Unique Local Addresses (ULAs) > are not utilised for local communication i.e. for local > communication the addresses are link-local addresses with prefix > elided. Not sure why should the f80 prefix be elided. > However, for communication with nodes outside 6LoWPAN the 6LoWPAN > node's prefix can either be a global prefix or a ULA's prefix. Well yes, that's a good principle, but rfc4944 seems to be saying only /64 prefixes are valid (supposedly /56 are not ok). Which is not good. I will comment separately for this RFC. Alex From alexandru.petrescu@gmail.com Wed Feb 18 03:43:56 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 E539228C1EE for <6lowpan@core3.amsl.com>; Wed, 18 Feb 2009 03:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, 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 OvSYZo0LN2+3 for <6lowpan@core3.amsl.com>; Wed, 18 Feb 2009 03:43:56 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id C873C3A67B6 for <6lowpan@ietf.org>; Wed, 18 Feb 2009 03:43:55 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1IBgNB5016413 for <6lowpan@ietf.org>; Wed, 18 Feb 2009 12:42:24 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1IBi6V1019637 for <6lowpan@ietf.org>; Wed, 18 Feb 2009 12:44:06 +0100 (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 n1IBi6On000963 for <6lowpan@ietf.org>; Wed, 18 Feb 2009 12:44:06 +0100 Message-ID: <499BF486.5070103@gmail.com> Date: Wed, 18 Feb 2009 12:44:06 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] comments and questions on rfc4944 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, 18 Feb 2009 11:43:57 -0000 Dear 6LoWPANers, I have some comments and questions on RFC4944. I wrote these comments while reading the RFC to get familiar with it. I don't know what are the intentions of progressing the draft. For the record. > IEEE 802.15.4 defines four types of frames: beacon frames, MAC > command frames, acknowledgement frames, and data frames. IPv6 > packets MUST be carried on data frames. Data frames may optionally > request that they be acknowledged. In keeping with [RFC3819], it is > recommended that IPv6 packets be carried in frames for which > acknowledgements are requested so as to aid link-layer recovery. So IPv6 packets must be carried on data frames, and on frames for which acks are requested. Are all data frames requesting acks? If not, what distinguishes data frames requesting acks from data frames not requesting acks? > 2. A short destination address is included in the frame, and it MUST > match the broadcast address (0xffff). What is the IP destination address in this case? > 2. Even though the above space calculation shows the worst-case > scenario, it does point out the fact that header compression is > compelling to the point of almost being unavoidable. Since we > expect that most (if not all) applications of IP over IEEE > 802.15.4 will make use of header compression, it is defined below > in Section 10. This is dangerously approaching saying IP HC is a MUST for 15.4 networks. I disagree. > 5. LoWPAN Adaptation Layer and Frame Format Is this mandatory use in 15.4 IPv6 networks? > | 01 000001 | IPv6 - Uncompressed IPv6 Addresses | or Uncompressed IPv6 headers (the full IPv6 headers are present)? because later it says: > IPv6: Specifies that the following header is an uncompressed IPv6 > header [RFC2460]. > 6. Stateless Address Autoconfiguration > > > This section defines how to obtain an IPv6 interface identifier. So why is the section title misleading. > The Interface Identifier [RFC4291] for an IEEE 802.15.4 interface may > be based on the EUI-64 identifier [EUI64] assigned to the IEEE > 802.15.4 device. In this case, the Interface Identifier is formed > from the EUI-64 according to the "IPv6 over Ethernet" specification > [RFC2464]. Is there an 802.3 layer on top of 802.15.4? This is good to clarify. > An IPv6 address prefix used for stateless autoconfiguration [RFC4862] > of an IEEE 802.15.4 interface MUST have a length of 64 bits. Does this effectively forbid 54bit prefix lengths? > The IPv6 link-local address [RFC4291] for an IEEE 802.15.4 interface > is formed by appending the Interface Identifier, as defined above, to > the prefix FE80::/64. /64 or /10? (rfc3513.txt says Link-local unicast 1111111010 FE80::/10 2.5.6) > 9. Multicast Address Mapping > > The functionality in this section MUST only be used in a mesh-enabled > LoWPAN. Yes, but it's not clear: will a mesh-enabled LoWPAN use route-over or mesh-under routing? > The functionality in this section MUST only be used in a mesh-enabled > LoWPAN. 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: But I thought 802.15.4 wihtout adaptation layer doesn't have multicast addresses. What happens with the lost octet of a solicited-node IP multicast address? (it has 3, and this uses only 2). > 10. Header Compression > > > There is much published and in-progress standardization work on > header compression. Yes, ROHC evolved... > 10.1. Encoding of IPv6 Header Fields > > > By virtue of having joined the same 6LoWPAN network, devices share > some state. This makes it possible to compress headers without > explicitly building any compression context state. Therefore, > 6LoWPAN header compression does not keep any flow state; instead, it > relies on information pertaining to the entire link. The following > IPv6 header values are expected to be common on 6LoWPAN networks, so > the HC1 header has been constructed to efficiently compress them from > the onset: Version is IPv6; both IPv6 source and destination > addresses are link local; For this reason, 6LoWPAN HC may not be useful when the network is connected to the Internet (src/dst addresses be global). > both the > Traffic Class and the Flow Label are zero; So no qos and HC, ok? > and the Next Header is > UDP, ICMP or TCP. So no Mobile IPv6 and HC, ok? Alex From alexandru.petrescu@gmail.com Wed Feb 18 05:31:35 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 0DC483A6A34 for <6lowpan@core3.amsl.com>; Wed, 18 Feb 2009 05:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.084, 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 VDi-VB68T2ig for <6lowpan@core3.amsl.com>; Wed, 18 Feb 2009 05:31:34 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 97D613A69CC for <6lowpan@ietf.org>; Wed, 18 Feb 2009 05:31:33 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1IDVfl9027976; Wed, 18 Feb 2009 14:31:41 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1IDVeAf019283; Wed, 18 Feb 2009 14:31:40 +0100 (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 n1IDVevo007285; Wed, 18 Feb 2009 14:31:40 +0100 Message-ID: <499C0DBC.8090806@gmail.com> Date: Wed, 18 Feb 2009 14:31:40 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Eunsook \"Eunah\" Kim" References: <4992FD7F.8070408@gmail.com> <77f1dba80902160228s4b25285ageb085c51c402fd40@mail.gmail.com> <49997D6E.2030409@gmail.com> <77f1dba80902170219r6a0b319awfffab6aef2abbfe9@mail.gmail.com> <499AD9D8.7020602@gmail.com> <77f1dba80902171859w780f8e96s1d85bcccc42ca380@mail.gmail.com> In-Reply-To: <77f1dba80902171859w780f8e96s1d85bcccc42ca380@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 13:31:35 -0000 Eunsook "Eunah" Kim a écrit : > Dear Alex, > > There are misunderstanding, so I would like to clarify them. Thanks. > >>> 2. route-over: basically, it should be the same as traditional >>> IPv6 routing, except the gateway needs to work on >>> compression/decompression of IP/UDP.. headers. >> I was not aware of that constraint. You seem to imply the >> 'route-over' capability requires the use of Header Compression. I >> will have to check the HC 6LoWPAN draft. >> > > Oh, no. ROUTING mechanism WON"T require header > compression/decompression. Routing will be included after IP/UDP, or > where the routing protocol is designed in. I just gave you an example > of 6lowpan network to communicate with non-6lowpan. Just what I want > to say was you need decoding 6lowpan_header for the communication. > It's not the routing role. > > >>>> Will the 6LoWPAN router use longest-prefix match (as IP >>>> protocols do) or exact-match (as some VLAN switch protocols >>>> do). >>>> >>> In route-over, every intermediate node which performs routing >>> fucntions is called 6lowpan router. I didn't see a runing >>> route-over solution for 6LoWPAN yet. In my opinion, it will use >>> as IP protocols do. (I understand that's the concept of >>> route-over. I think ROLL people may answer it more clearly) In >>> mesh-under, generally, one IPv6 router exists in one 6lowpan. >>> 6lowpan nodes in the lowpan will perform routing functions but >>> not use IPv6 address. Whole 6lowpan is one IPv6 link, and the >>> IPv6 router of 6lowpan will act as a normal IPv6 router to >>> communicate with other IPv6 router outside of the 6lowpan, but >>> the functionality for inside of 6lowpan routing would differ (not >>> use IPv6 addresses). >> I wouldn't call the route-over 'routing' (or perform routing >> functions) if it didn't use IP addresses. It's confusing. >> > > Mesh-under doesn't use IP address. Route-over uses IP address. As I > understand, Route-over for LoWPAN or LLNs is the same like other IP > based routing. So far, mesh-under was widely-understood way to make a > multi-hop connection in LoWPAN, and ROLL was born to make IP based > routing for it. So it uses IP address for routing. I think we're in principle in agreement on this one. >>> [snip..] >>>>>>> [R18] If the routing protocol functionality includes >>>>>>> enabling IP multicast, then it may want to employ >>>>>>> coordinator roles, if any, as relay points of >>>>>>> group-targeting messages instead of using link-layer >>>>>>> multicast (broadcast). >>>>>> link-layer multicast no broadcast. >>>>> I don't know if 'link-layer multicast' is a proper term when >>>>> 802.15.4 does not provide multicast. >>>> Maybe that's a requirement to put on 802.15.4 not on 6LoWPAN. >>>> >>>> I mean it would be difficult to revive the 'broadcast' concept >>>> back into IPv6 documents, I suppose. >>>> >>> Yes, i also think that it's great if 802.15.4 supports link-layer >>> multicast. As it does not, 6lowpan wants to avoid IP multicast >>> which causes link broadcast as much as possible. I should think >>> what else term can be used instead of broadcast if it is not >>> acceptable termniology. >> Well, at IEEE 802 link-layer, broadcast means 'ff:ff:ff:ff:ff:ff' >> address, whereas multicast means '33:33:0:0:0:X' address. Anything >> different has too many meanings. >> >> I would actually appreciate a lot if this link-layer multicast >> requirement went back to IEEE 802.15.4 instead of being addresses >> in an IETF draft. It risks being specified for the sake of >> specifying it, but implementations may simply go on and not use >> neither broadcast nor multicast. >> >> Just some thoughts. >> >> Alex >> > > 6lowpan is on 802.15.4, and IP multicast will go all nodes in the > lowpan which is energy-expensive for lowpan nodes. You mean broadcast (not multicast)? Broadcast may happen as you say: a broadcast message goes to all nodes in the lowpan. But multicast happens differently: the multicast message goes only to the nodes having previously subscribed for it. The same multicast concept is valid for link-layer and for IP. In this sense, multicast may be less energy-intensive than broadcast. I can understand 802.15.4 doesn't provide link-layer multicast, but I can't understand why. > Thus, i think such a restraint of all-nodes receiving packets is > necessary to be considered when we design a solution for lowpan. And, > in my opinion, this is well-agreed issue for 6lowpaners. (RFC 4944 > also mentioned it) I think there may be a misunderstanding with rfc4944. It is not clear in rfc4944 whether or not link-layer multicast is available or not in 802.15.4, and whether the rfc4944 adaptation layer provides link-layer multicast or not, to the IPv6 stack. > If we avoid to say broadcasting issue, can you help me to find how we > contain such a requirement, based on IETF conventional way? :) Sorry, I don't know precisely :-) First, I am trying to identify whether a conventional IEEE 802.3 multicast-capable MAC is specified to run somehow over IEEE 802.15.4. And if yes, then maybe that is all that is needed for an IPv6 stack running over 802.15.4 links, by reusing more of the rfc2464 IPv6-over-Ethernet. If not, and if 802.15.4 doesn't want to specify the link-layer multicast behaviour, then maybe the adaptation layer would specify the link-layer multicast behaviour. In all this, I think a liaison person to IEEE 802.15.4 group could provide advice. Maybe that person is already determined. Until a working link-layer multicast behaviour is specified for 802.15.4 links, ND can only work as ptp link. And DHCPv6, SLAAC (stateless autoconf) and OSPF too - only ptp links. Alex From jhui@archrock.com Wed Feb 18 07:53: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 9C99F3A6A15 for <6lowpan@core3.amsl.com>; Wed, 18 Feb 2009 07:53:50 -0800 (PST) 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 a0Nba7qj5s3n for <6lowpan@core3.amsl.com>; Wed, 18 Feb 2009 07:53:49 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 8D4533A6A08 for <6lowpan@ietf.org>; Wed, 18 Feb 2009 07:53:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 1BBDCAF8C2; Wed, 18 Feb 2009 07:54:02 -0800 (PST) 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 8UXvTR+ZMvRG; Wed, 18 Feb 2009 07:54:01 -0800 (PST) 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 F1ABDAF8B2; Wed, 18 Feb 2009 07:54:00 -0800 (PST) Message-Id: From: Jonathan Hui To: Alexandru Petrescu In-Reply-To: <499BF486.5070103@gmail.com> 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: Wed, 18 Feb 2009 07:53:59 -0800 References: <499BF486.5070103@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] comments and questions on rfc4944 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, 18 Feb 2009 15:53:50 -0000 Hi Alex, as you have noticed, RFC 4944 needs cleanup. We have already discussed updating and/or replacing RFC 4944 within this WG. Please see additional comments inline: On Feb 18, 2009, at 3:44 AM, Alexandru Petrescu wrote: > Dear 6LoWPANers, > > I have some comments and questions on RFC4944. I wrote these > comments while reading the RFC to get familiar with it. I don't > know what are the intentions of progressing the draft. For the > record. > >> IEEE 802.15.4 defines four types of frames: beacon frames, MAC >> command frames, acknowledgement frames, and data frames. IPv6 >> packets MUST be carried on data frames. Data frames may optionally >> request that they be acknowledged. In keeping with [RFC3819], it >> is recommended that IPv6 packets be carried in frames for which >> acknowledgements are requested so as to aid link-layer recovery. > > So IPv6 packets must be carried on data frames, and on frames for > which acks are requested. Are all data frames requesting acks? If > not, what distinguishes data frames requesting acks from data frames > not requesting acks? There is an ack request bit in the 15.4 header. Please see the referenced 15.4 spec. >> 2. A short destination address is included in the frame, and it >> MUST >> match the broadcast address (0xffff). > > What is the IP destination address in this case? A multicast address. >> 2. Even though the above space calculation shows the worst-case >> scenario, it does point out the fact that header compression is >> compelling to the point of almost being unavoidable. Since we >> expect that most (if not all) applications of IP over IEEE >> 802.15.4 will make use of header compression, it is defined >> below >> in Section 10. > > This is dangerously approaching saying IP HC is a MUST for 15.4 > networks. I disagree. You are correct. That's why RFC 4944 also specifies uncompressed IPv6 headers. >> 5. LoWPAN Adaptation Layer and Frame Format > > Is this mandatory use in 15.4 IPv6 networks? Yes. The adaptation layer also adds a protocol dispatch that is sorely missing from the 15.4 header. >> | 01 000001 | IPv6 - Uncompressed IPv6 Addresses | > > or Uncompressed IPv6 headers (the full IPv6 headers are present)? > > because later it says: >> IPv6: Specifies that the following header is an uncompressed IPv6 >> header [RFC2460]. Yes. Should be "Uncompressed IPv6 Header". >> 6. Stateless Address Autoconfiguration >> This section defines how to obtain an IPv6 interface identifier. > > So why is the section title misleading. Not sure what you mean. One has to construct an IID somehow and this section specifies how to obtain one from a 15.4 address. >> The Interface Identifier [RFC4291] for an IEEE 802.15.4 interface >> may >> be based on the EUI-64 identifier [EUI64] assigned to the IEEE >> 802.15.4 device. In this case, the Interface Identifier is formed >> from the EUI-64 according to the "IPv6 over Ethernet" specification >> [RFC2464]. > > Is there an 802.3 layer on top of 802.15.4? This is good to clarify. No. But you're right, the analogy is not a good one. 802.2. has 6-byte addrs, while 15.4 has 8-byte EUI-64's. >> An IPv6 address prefix used for stateless autoconfiguration >> [RFC4862] >> of an IEEE 802.15.4 interface MUST have a length of 64 bits. > > Does this effectively forbid 54bit prefix lengths? You're right. It should say something closer to what's in RFC 4862. Specifically: 1. The left-most 'prefix length' bits of the address are those of the link-local prefix. 2. The bits in the address to the right of the link-local prefix are set to all zeroes. 3. If the length of the interface identifier is N bits, the right- most N bits of the address are replaced by the interface identifier. (Remove link-local to support arbitrary prefixes). >> The IPv6 link-local address [RFC4291] for an IEEE 802.15.4 >> interface >> is formed by appending the Interface Identifier, as defined >> above, to >> the prefix FE80::/64. > > /64 or /10? (rfc3513.txt says Link-local unicast 1111111010 > FE80::/10 2.5.6) Should be /10 with zeros padded as mentioned above. > > 9. Multicast Address Mapping > > >> The functionality in this section MUST only be used in a mesh- >> enabled >> LoWPAN. > > Yes, but it's not clear: will a mesh-enabled LoWPAN use route-over > or mesh-under routing? There is still debate within the 6LoWPAN group on this subject. >> The functionality in this section MUST only be used in a mesh- >> enabled >> LoWPAN. 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: > > But I thought 802.15.4 wihtout adaptation layer doesn't have > multicast addresses. When not using a mesh addressing header, MAC-layer broadcast is used to support multicast. > What happens with the lost octet of a solicited-node IP multicast > address? (it has 3, and this uses only 2). When using mesh addressing header, you only have the last 13 bits to work with. Think of these bits as a possible optimization so that the adaptation layer can optimize multicast delivery over multiple hops. BTW, I don't believe we should be specifying L2-stuff like this within the IETF. Much of the stuff in the RFC was there long before I got my hands on it. >> 10. Header Compression >> There is much published and in-progress standardization work on >> header compression. > > Yes, ROHC evolved... And is still flow-based... >> 10.1. Encoding of IPv6 Header Fields >> By virtue of having joined the same 6LoWPAN network, devices share >> some state. This makes it possible to compress headers without >> explicitly building any compression context state. Therefore, >> 6LoWPAN header compression does not keep any flow state; instead, >> it >> relies on information pertaining to the entire link. The following >> IPv6 header values are expected to be common on 6LoWPAN networks, >> so >> the HC1 header has been constructed to efficiently compress them >> from >> the onset: Version is IPv6; both IPv6 source and destination >> addresses are link local; > > For this reason, 6LoWPAN HC may not be useful when the network is > connected to the Internet (src/dst addresses be global). Exactly right. Which is why we're actively working on a new HC specification. >> both the >> Traffic Class and the Flow Label are zero; > > So no qos and HC, ok? Fixed in the new HC. >> and the Next Header is >> UDP, ICMP or TCP. > > So no Mobile IPv6 and HC, ok? Fixed in the new HC. -- Jonathan Hui > > > Alex > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From alexandru.petrescu@gmail.com Wed Feb 18 08:47:05 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 AEAC03A6928 for <6lowpan@core3.amsl.com>; Wed, 18 Feb 2009 08:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.081, 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 EE5VoA-gh+sD for <6lowpan@core3.amsl.com>; Wed, 18 Feb 2009 08:47:04 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 38F073A680E for <6lowpan@ietf.org>; Wed, 18 Feb 2009 08:47:04 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1IGlDZv015083; Wed, 18 Feb 2009 17:47:13 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1IGlDd1017733; Wed, 18 Feb 2009 17:47:13 +0100 (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 n1IGlCqO007618; Wed, 18 Feb 2009 17:47:13 +0100 Message-ID: <499C3B90.5080605@gmail.com> Date: Wed, 18 Feb 2009 17:47:12 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jonathan Hui References: <499BF486.5070103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] comments and questions on rfc4944 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, 18 Feb 2009 16:47:05 -0000 Hi Jonathan, Jonathan Hui a écrit : >> I have some comments and questions on RFC4944. I wrote these >> comments while reading the RFC to get familiar with it. I don't >> know what are the intentions of progressing the draft. For the >> record. >> >>> IEEE 802.15.4 defines four types of frames: beacon frames, MAC >>> command frames, acknowledgement frames, and data frames. IPv6 >>> packets MUST be carried on data frames. Data frames may >>> optionally request that they be acknowledged. In keeping with >>> [RFC3819], it is recommended that IPv6 packets be carried in >>> frames for which acknowledgements are requested so as to aid >>> link-layer recovery. >> >> So IPv6 packets must be carried on data frames, and on frames for >> which acks are requested. Are all data frames requesting acks? If >> not, what distinguishes data frames requesting acks from data >> frames not requesting acks? > > There is an ack request bit in the 15.4 header. Please see the > referenced 15.4 spec. Ok, I see, it would have been clearer if it said "be carried in data frames for which..." instead of "be carried in frames for which...". BEcause otherwise makes think the "data frames" are different than the "frames requesting acks". >>> 2. A short destination address is included in the frame, and it >>> MUST match the broadcast address (0xffff). >> >> What is the IP destination address in this case? > > A multicast address. Which IP multicast address? The all-nodes multicast address? The all-routers multicast address? Which scope (interface, link, site)? A newly defined 'all-somethings' address? (rfc3513 lists some possibilities). >>> 5. LoWPAN Adaptation Layer and Frame Format >> >> Is this mandatory use in 15.4 IPv6 networks? > > Yes. The adaptation layer also adds a protocol dispatch that is > sorely missing from the 15.4 header. I think link-layer multicast capabilities are more missing than anything else. More important than HC too and than mesh-under routing. >>> 6. Stateless Address Autoconfiguration This section defines how >>> to obtain an IPv6 interface identifier. >> >> So why is the section title misleading. > > Not sure what you mean. One has to construct an IID somehow and this > section specifies how to obtain one from a 15.4 address. 95% of text in this section describes how to form the IID. I think it would be better called "Forming an IID on 802.15.4" rather than Stateless Address Autoconfiguration. (the fact that rfc2464 calls its section 4 "Stateless Autoconfiguration" is a misnomer which should be corrected, because (1) makes people think it's about an address being autoconfigured statelessly - it's actually an IID not an address, and (2) it can easily be misunderstood for "Stateless Address Autoconfiguration" RFC4862 which is much more than just forming an IID and involves messages being exchanged.) >>> An IPv6 address prefix used for stateless autoconfiguration >>> [RFC4862] of an IEEE 802.15.4 interface MUST have a length of 64 >>> bits. >> >> Does this effectively forbid 54bit prefix lengths? > > You're right. It should say something closer to what's in RFC 4862. > Specifically: > > 1. The left-most 'prefix length' bits of the address are those of > the link-local prefix. > > 2. The bits in the address to the right of the link-local prefix are > set to all zeroes. > > 3. If the length of the interface identifier is N bits, the right- > most N bits of the address are replaced by the interface identifier. I fully agree with this 3rd point. An implementation does so. I think this may be used to suggest correction to RFC2464 as well (it requires the prefix to be 64bits, bottom of page 3, and I disagree, it could be shorter). I think I will post separately see what people think on the 6man list. [...] >> What happens with the lost octet of a solicited-node IP multicast >> address? (it has 3, and this uses only 2). > > When using mesh addressing header, you only have the last 13 bits to > work with. Think of these bits as a possible optimization so that > the adaptation layer can optimize multicast delivery over multiple > hops. BTW, I don't believe we should be specifying L2-stuff like this > within the IETF. This is what I'm thinking too. But I don't know how to make it otherwise work. If IEEE doesn't offer a multicast-capable link-layer, and if nobody else does, I'm afraid many IPv6-based protocols simply won't work. I think it could be too much work to modify every other protocol (DHCPv6, Mobile IPv6, ND, SLAAC, OSPF, RIPng to name a few relying on link-layer multicast) to work on such specific link-layer. >>> 10. Header Compression There is much published and in-progress >>> standardization work on header compression. >> >> Yes, ROHC evolved... > > And is still flow-based... Sounds as an inconvenient of it, but I don't see 'flow' mentioned in HC (for other than Flow Label). I would have expected to see how HC is not flow-based, or similar. Also, I would have expected to see the MANET Packet Format, rfc5444, ways of compressing IP addresses and prefixees. >>> 10.1. Encoding of IPv6 Header Fields By virtue of having joined >>> the same 6LoWPAN network, devices share some state. This makes >>> it possible to compress headers without explicitly building any >>> compression context state. Therefore, 6LoWPAN header compression >>> does not keep any flow state; instead, it relies on information >>> pertaining to the entire link. The following IPv6 header values >>> are expected to be common on 6LoWPAN networks, so the HC1 header >>> has been constructed to efficiently compress them from the onset: >>> Version is IPv6; both IPv6 source and destination addresses are >>> link local; >> >> For this reason, 6LoWPAN HC may not be useful when the network is >> connected to the Internet (src/dst addresses be global). > > Exactly right. Which is why we're actively working on a new HC > specification. Oh I see, the HC draft, ok. Alex From zach@sensinode.com Mon Feb 23 13:38:35 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 C0C1B3A63D3 for <6lowpan@core3.amsl.com>; Mon, 23 Feb 2009 13:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, URIBL_RHS_DOB=1.083] 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 TedIo738m107 for <6lowpan@core3.amsl.com>; Mon, 23 Feb 2009 13:38:34 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B1D9128C1C7 for <6lowpan@ietf.org>; Mon, 23 Feb 2009 13:37:50 -0800 (PST) Received: from snl-zach.local (line-17103.dyn.kponet.fi [85.29.113.63]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n1NLc3rw004362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Mon, 23 Feb 2009 23:38:04 +0200 Message-ID: <49A317CD.2020600@sensinode.com> Date: Mon, 23 Feb 2009 23:40:29 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) 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-01] 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, 23 Feb 2009 21:38:35 -0000 Hi, Version -01 of ND for 6lowpan is now available. http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-01.txt This revision closes a long list of smaller and major tickets. Thanks to all the feedback in Minneapolis and on the list. Here is a summary of changes: - Specified the duplicate owner interface identifier procedures. A TID lollypop algorithm was sufficient (nonce unnecessary). - Defined fault tolerance using secondary bindings. - Defined ad-hoc network operation. - Removed the E flag from RA and the X flag from RR/RC. - Completed message examples. - Lots of improvements in text quality and consistency were made. The draft is now quite stable, and includes all the functionality we envision for IESG submission. I will submit -02 before the cutoff March 10th, which will be presented in San Francisco. Looking forward to reviews, and especially implementation feedback. Regards, Zach -------- Original Message -------- Subject: New Version Notification for draft-ietf-6lowpan-nd-01 Date: Mon, 23 Feb 2009 13:24:20 -0800 (PST) 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-01.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository. Filename: draft-ietf-6lowpan-nd Revision: 01 Title: Neighbor Discovery for 6LoWPAN Creation_date: 2009-02-23 WG ID: 6lowpan Number_of_pages: 46 Abstract: This document specifies Neighbor Discovery optimized for 6LoWPAN. The 6LoWPAN format allows IPv6 to be used over very constrained wireless networks often making use of extended multihop topologies. However, the use of standard IPv6 Neighbor Discovery over 6LoWPAN networks has several problems. Standard Neighbor Discovery was not designed for wireless links, and the standard IPv6 link concept and heavy use of multicast makes it inefficient. This document spefies a new mechanism allowing efficient Duplicate Address Detection over entire 6LoWPAN networks. In addition it specifies context dissemination for use with router advertisements, claim and defend addressing, and the support of extended LoWPANs over backbone links. The IETF Secretariat. -- 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.