From 6lowpan-bounces@ietf.org Thu Apr 7 14:26:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23539; Thu, 7 Apr 2005 14:26:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbqO-0005cV-UU; Thu, 07 Apr 2005 14:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbYk-0000nk-MV; Thu, 07 Apr 2005 14:16:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbYj-0000nf-Rv for 6lowpan@megatron.ietf.org; Thu, 07 Apr 2005 14:16:53 -0400 Received: from mailx.danfoss.com (mailx.danfoss.com [193.162.34.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22476 for <6lowpan@lists.ietf.org>; Thu, 7 Apr 2005 14:16:51 -0400 (EDT) Received: from dkdn04mx62.dkdn04.danfoss.net ([10.6.2.62]) by mailx.danfoss.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Apr 2005 20:16:19 +0200 Received: from dkdn01mx21.danfoss.net ([10.12.129.21]) by 10.6.4.62 with InterScan Messaging Security Suite; Thu, 07 Apr 2005 20:16:19 +0200 Received: from dkdn01mx25.danfoss.net ([10.12.129.25]) by dkdn01mx21.danfoss.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 20:16:19 +0200 Received: from DKDN01MX34.danfoss.net ([10.12.128.14]) by dkdn01mx25.danfoss.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 20:16:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Apr 2005 20:16:18 +0200 Message-ID: <49A38D2FE2C53946A57916AD6A1F00D748E6D1@DKDN01MX34.danfoss.net> Thread-Topic: Test mail Thread-Index: AcU7neT7HyKK/NevT9SAgaeRq/ut8w== From: =?iso-8859-1?Q?Nielsen_Klaus_S=F8nderskov?= To: <6lowpan@ietf.org> X-OriginalArrivalTime: 07 Apr 2005 18:16:19.0065 (UTC) FILETIME=[E52B4690:01C53B9D] Subject: [6lowpan] Test mail X-BeenThere: 6lowpan@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.lists.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0392714431==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Status: O This is a multi-part message in MIME format. --===============0392714431== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53B9D.E50F0AB3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C53B9D.E50F0AB3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, as I have not received any mail since signed up I send this test mail... Sorry for the disturbance...=20 Best regards, Klaus S=F8nderskov Nielsen Danfoss Communication Technology Centre * E14-N8, DK-6430 Nordborg, Denmark * (+45) 7488 5275 E-mail: Klaus.S.Nielsen@danfoss.com www: http://www.Danfoss.com =20 ------_=_NextPart_001_01C53B9D.E50F0AB3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Test mail

Hi all,
as I have not received any mail since = signed up I send this test mail…

Sorry for the disturbance… =

Best regards,
Klaus S=F8nderskov = Nielsen
Danfoss Communication Technology = Centre
* = E14-N8, DK-6430 Nordborg, Denmark
( = (+45) 7488 5275
E-mail: Klaus.S.Nielsen@danfoss.com
www: http://www.Danfoss.com

------_=_NextPart_001_01C53B9D.E50F0AB3-- --===============0392714431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ 6lowpan mailing list 6lowpan@lists.ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0392714431==-- From 6lowpan-bounces@ietf.org Thu Apr 14 10:05:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14519; Thu, 14 Apr 2005 10:05:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM58a-0000VR-S0; Thu, 14 Apr 2005 10:16:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4wt-0006Bf-A7; Thu, 14 Apr 2005 10:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4to-0005H4-SI for 6lowpan@megatron.ietf.org; Thu, 14 Apr 2005 10:00:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13875; Thu, 14 Apr 2005 10:00:42 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM53g-0000EO-2S; Thu, 14 Apr 2005 10:11:04 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j3EE0ZPt011985; Thu, 14 Apr 2005 16:00:36 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Thu, 14 Apr 2005 16:00:34 +0200 To: 6lowpan@ietf.org X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 14 Apr 2005 10:04:02 -0400 Cc: minutes@ietf.org, Carsten Bormann Subject: [6lowpan] Draft minutes of Minneapolis 6lowpan meeting X-BeenThere: 6lowpan@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.lists.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Content-Transfer-Encoding: 7bit Status: O Lowpanners, attached please find the minutes I have written up from notes taken by Bob Moskowitz and me. I must admit that I didn't catch all of the sometimes fast-paced discussion (as is my right as a non-native speaker :-), so my apologies in advance if I'm mis-representing your positions or am misspelling you name. We still have a couple of days to correct these minutes before they are frozen in the proceedings. Please send all minor corrections to me; but keep things that might be more contentious on the list please. (These are minutes of a meeting that is already over, but I don't mind spawning some list discussion from the points raised here -- just make it clear that you are not suggesting a minutes correction.) Gruesse, Carsten IPv6 over Low power WPAN (6LOWPAN) Working Group Minutes ======================================================== Reported by Bob Moskowitz and Carsten Bormann The 6LOWPAN working group met once at the 62nd IETF meeting (Minneapolis, March 2005). The meeting was chaired by Geoff Mulligan. WG Charter Geoff Mulligan went through the charter of the new working group and asked if there were any comments. There were none. Problem statement -- draft-kushalnagar-lowpan-goals-assumptions-00.txt Nandakishore (Nandu) Kushalnagar presented the problem statement draft (see slides). This document is at the level of a personal contribution; there was no contention to use this draft as the basis for discussion in the working group. Regarding the issue of routing, Nandu pointed to a separate presentation later on the agenda. While the intention was to use existing routing protocols, making them work at the subnetwork level requires some changes. This brought up the question how to handle the plethora of routing protocol proposals that can be expected. Geoff stated that the the working group scope does not include routing, it is IP over foo. There is an opportunity to look at other issues, maybe as an informational document; the charter nonetheless is limited to the two documents being discussed. A 15.4 contributor (Pradeep? The note takers apologize for not catching names very well.) mentioned that in 15.4, there are two mechanisms: CSMA/CA and slotted; IP discovery will be different for the two. Gabriel Montenegro pointed to the subsequent agenda item, which goes into each of the modes we assume. Geoff proposed to include in the problem statement the assumption of CSMA/CA, instead of the superframe structure ("slotted"). Lixia Zhang noted that the WG will be constrained by its charter and asked whether there was a plan to address the inevitable issues of deployment: management and security. Nandu proposed to make use of existing security working groups in the IETF, without making specific proposals which of these might be of interest. Geoff proposed to complete the IPv6-over-15.4 document first. Lixia insisted that deployable security must be part of the initial result or there will be a deployment surprise. Gabriel said that while the charter has very specific goals; there is some language that allows future work -- the WG may be able to recharter when we have a better understanding; the issues might be the subject of individual submissions in the interim. Simone Ruffino asked whether, for the mesh network that is built below IP, the intention is to adapt existing mechanisms of stateless autoconf or invent a new one. Nandu said the intention was to use the existing IPv6 mechanisms, but pointed out that for 15.4's 16-bit addresses we need a different method. Simone asked whether the whole LoWPAN was to be considered one link in the IPv6 architecture sense. Nandu affirmed. Bob Hinden asked for further clarification. Bob Moskowitz said that the LoWPAN looks like an 802 LAN to higher layers. Bob Hinden mentioned that the IPv6 autocongifuration/address architecture defines how to create interface tokens and asked that these not be reinvented. Nandu agreed. Gabriel later attempted to clarify the answer to Bob Hinden's question by pointing out that 15.4 has a PAN ID, which, in IPv6 architecture words, identifies a link -- multiple PAN IDs can overlap, but not interact. The discussion returned to the question how to use IETF security working groups for developing the LoWPAN solution. Margaret Wasserman pointed out that there is a number of groups to look at. Geoff stated that none of them is actively looking at LoWPAN. Gabriel agreed that LoWPANs require security work but said we don't necessarily have to solve them in the 6LOWPAN WG, can do that in the security WGs. Bob Moskowitz noted that 802.15.4 has a security format to encrypt the payloads, but does not have a key management scheme or exchange methodology -- defining that would be one valuable thing to do, reminding everyone that this is a hop-by-hop security model and that for end-to-end security, a higher layer security mechanism is required. Pekka Savola clarified that while there is an IETF security area; it would be too much to expect security area people to just come in and fix the WG's protocols; the WG has to do this and, if necessary, ask for help. He pointed out that, if this WG does not do the necessary security work; the result will be held up in the IESG for security. Geoff countered that the WG is not currently chartered to do security Margaret asked why are there any specific security issues that aren't either a problem of IEEE or general IETF issues? Nandu answered that a LoWPAN has different characteristics, including its packet size, and the wireless multi-hop, related to MANET type of network The WG chair closes the mike line and refers further security discussion to the final agenda item. One last comment was that it was not easy to see how stateless autoconfiguration fits into the LoWPAN model -- it was hard to imagine routers giving out the appropriate advertisements... IPv6 over 15.4 -- draft-montenegro-lowpan-ipv6-over-802.15.4-01.txt Gabriel Montenegro presented the IPv6 over 15.4 draft (see slides), pointing out that, although this is already the -02 version (second revision) of the draft, this was going to be the first face to face discussion in this working group. During the presentation, a poll indicated that about ten of those present in the room had read the draft. Gabriel pointed out that, for assigment of 16-bit addresses, 15.4 defines a prodecure with a central coordinator, which does all the necessary work, we can use that. The mapping between PAN ID and IPv6 prefixes is not currently defined. During the presentation of the frame format and adaptation layer, Carsten Bormann asked how compatible this format was with transporting LLC packets as well. This had not been examined. Bob Hinden asked why RFC 2507 (IP Header Compression) wasn't being used as a header compression format. Carsten answered that the requirements for 6LOWPAN's header compression scheme are very different from the ones that RFC 2507 addresses (which addresses flow-based compression). Carsten asked about the relationship of the reassembly scheme proposed and the reordering assumed from the link (e.g., the MSL issue). Bob Moskowitz clarified that Meshes are being discussed in 802.11, .15, .16, and none of them addresses reordering. Gabriel noted that there is a mistake in the current draft -- there is a need for multiple M bits. Rajeev Koodli asked whether the IPv6 routing header could not be used to solve the problem. Gabriel clarified that routing headers carry IP addresses, while the "Final destination" field is about MAC addresses. Bob Moskowitz added that all 802 meshes need special multi-MAC formats for meshes and pointed out the 4-address format used in .11. When Gabriel presented the header compression mechanism proposed, Alain asked about same-subnet vs. link-local source and destination addresses -- does this mean the assumption is that LoWPAN devices never listen to a router? Gabriel stated this as the most common case; however, global addresses are possible -- and even expected to be compressible. Alain wondered whether this has a bearing on the address selection policy to be used by endpoints. Gabriel asked whether, based on the current address selection policy, we have to modify anything. Alain answered that, if only link-local addresses are used, the current address selection policy is fine. Greg Daly pointed out that, while link-local addressing is the most common case, at the moment, it is quite possible there will be off-link traffic. Gabriel answered that this remaind possible, just will be less compressible. Gabriel then speculated about possible integration of the compression state and the routing information. Krishnan asked why there was no attempt compress out the hop limit as well. Gabriel answered that this was worthwhile to examine. Rajeev pointed to a paper about stateless header compression he had at IEEE ICC 2005. Gabriel also stated a need to expand the work to also examine TCP header compression. Sub-IP Mesh for LoWPAN Nandu started the discussion pointing out that work on the Sub-IP Mesh is not currently part of charter. Discussion ensued about other standards alliances working on standards in the same space. (See slides for Nandu's presentation.) A draft for reactive routing at the Sub-IP level is in the works; replacing AODV hello by 15.4 specific messages. The suggestion is that this be separate from the basic IPv6 over 15.4 specification. In the future, other protocols like OLSR, DYMO, DSR should be considered, but care must be taken that the work is actually applicable to LoWPANs. Charlie Perkins, in the context of work in MANET on DYMO and other protocols, asked for input to the discussion about the tradoff between using power for sending bits vs. using it for processing. Bob Moskowitz pointed to work in 802.11s about Mesh routing, an NRL proposal, and work on sub-second maintenance of the routing table information. Charlie Perkins indicated that this wasn't the complete answer he had hoped for and proposed to take the issue offline for further discussion. Geoff added that he'd rather do less computing than send less bits. Implementation considerations (The slides covered the issues of Embedded Systems, Code Size, Energy Use, Just enough security (what layer), What services (security, service discovery, ...), a Transport layer, and Compatibility.) Geoff noted overlap between the work of this working group and work done in ZigBee Alliance; ZigBee Alliance has announced to make their specification available for academic review but not for commercial use; anything about non-encumbrance has yet to be stated by the alliance. This situation was a reason for not attempting to use the ZigBee format. With respect to routing, Zigbee Alliance have what could be called "AODV junior", so we could try to interoperate, but we also could be ships in the night. A ZigBee study group is just now looking at he feasibility of IPv6 over 15.4, not doing the work yet. Gabriel: back to Charlie's question: typically, a LoWPAN is partitioned into Full Function Devices (FFD) with sufficient power and Reduced Function Devices (RFD) on battery power; RFD won't participate in the control messages (instead they'll send everything to a prefferred neighbor); in one scenario, FFD are always mains-powered; if FFD are battery powered, you want to compute, not transmit. Pekka Savola asked to focus some implementation considerations on AODV sub-ip; there is no security in AODV; there can't be a normative reference it as it is experimental. Geoff: One implementation consideration is that 15.4 defines radios for the whole range of 20-250 kbit/s, which is a big difference. We might have the opportunity to say we only do 2.4 GHz. 15.4b will have differences both in modulation and in security and is about to become an IEEE specification. Gabriel noted that the current drafts don't have much text on 15.4 security -- using that might improve security. Bob Moskowitz stated that doing the 15.4 security cannot be avoided; the risk in a PAN to have non-authorized systems interfering is too great; L3 protection can do some of that, but is not as good a fit; so there is a need for an L2 keying solution. Geoff pointed out that Sub-IP issues are generally not IETF work. Bob Moskowitz agreed and suggested to look where that work is done. IEEE 802 seems to be trying to get all future security work done in 802.1, whether that work fits here remains to be seen. Pekka stated that there needs to be at least some analysis, if not solutions for AODV security, Man in the Middle attacks. Gabriel pointed out that every draft needs a security considerations section Nandu proposed writing an informational document that describes what kind of threats are relevant to 6LOWPAN. The security of any adaptation layer needs to be addressed as well. It was pointed out that link-local addresses provide some form of isolation from link-external threads. Gabriel pointed to work on group keys. Charlie Perkins asked about the scale of the network we are envisioning -- is this about PANs or larger? Geoff said that his company was looking at home networks, with maybe 100s of nodes, as well as building networks with 1000s, but that additional input was required. One solution might be a network of meshes (30-50 node LowPANs, IP routing between them). It was pointed out that there are a lot more factors than just number of nodes; e.g., traffic characteristics. There is a need to come up with some common use cases. Geoff asked about strict vs. loose source routing (carrying the MAC layer address for the next hop vs. the final destination), but then proposed to take this offline. _______________________________________________ 6lowpan mailing list 6lowpan@lists.ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Apr 14 21:03:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17553; Thu, 14 Apr 2005 21:03:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMFOn-0004TM-MU; Thu, 14 Apr 2005 21:13:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMFE9-0005zi-CI; Thu, 14 Apr 2005 21:02:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMFE5-0005vb-Ac for 6lowpan@megatron.ietf.org; Thu, 14 Apr 2005 21:02:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17488 for <6lowpan@ietf.org>; Thu, 14 Apr 2005 21:02:27 -0400 (EDT) Received: from web80402.mail.yahoo.com ([66.218.79.57]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMFO9-0004RX-OF for 6lowpan@ietf.org; Thu, 14 Apr 2005 21:12:55 -0400 Message-ID: <20050415010214.61971.qmail@web80402.mail.yahoo.com> Received: from [192.18.42.10] by web80402.mail.yahoo.com via HTTP; Thu, 14 Apr 2005 18:02:14 PDT Date: Thu, 14 Apr 2005 18:02:14 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Draft minutes of Minneapolis 6lowpan meeting To: Carsten Bormann , 6lowpan@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: 6lowpan@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: itijibox-6lowpan@yahoo.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.lists.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Status: O [You might want to leave minutes@ietf.org out of the cc-list until such time as the minutes are deemed to be finalized.] Thanks Carsten, good minutes. Minor comment below. --- Carsten Bormann wrote: > IPv6 over 15.4 -- draft-montenegro-lowpan-ipv6-over-802.15.4-01.txt > ... > During the presentation of the frame format and adaptation layer, > Carsten Bormann asked how compatible this format was with > transporting LLC packets as well. This had not been examined. I believe what I responded was that yes, indeed it had been examined and that there is a note to this effect in the draft. Basically, no, the two formats are not compatible. The LLC format wastes a lot of space. the lowpan format does not, but is not LLC compatible. Assuming this was not a major issue, we opted for efficiency when examining the tradeoff. -gabriel _______________________________________________ 6lowpan mailing list 6lowpan@lists.ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Apr 15 00:52:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01665; Fri, 15 Apr 2005 00:52:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMIyy-0003zC-5T; Fri, 15 Apr 2005 01:03:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMIoB-0005Ji-QF; Fri, 15 Apr 2005 00:51:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMIo9-0005Io-U2 for 6lowpan@megatron.ietf.org; Fri, 15 Apr 2005 00:51:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01642 for <6lowpan@ietf.org>; Fri, 15 Apr 2005 00:51:46 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMIy9-0003yk-RH for 6lowpan@ietf.org; Fri, 15 Apr 2005 01:02:18 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j3F4phIS022665; Fri, 15 Apr 2005 06:51:44 +0200 (MEST) In-Reply-To: <20050415010214.61971.qmail@web80402.mail.yahoo.com> References: <20050415010214.61971.qmail@web80402.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5d6c1d5186c4c97f67c910bbffa2644c@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [6lowpan] Draft minutes of Minneapolis 6lowpan meeting Date: Fri, 15 Apr 2005 06:51:43 +0200 To: itijibox-6lowpan@yahoo.com X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , 6lowpan@ietf.org X-BeenThere: 6lowpan@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.lists.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Status: O >> During the presentation of the frame format and adaptation layer, >> Carsten Bormann asked how compatible this format was with >> transporting LLC packets as well. This had not been examined. At a minimum, I should have written "The need for this had not been examined"... Let me try this paragraph again: During the presentation of the frame format and adaptation layer, Carsten Bormann asked how compatible this format was with transporting LLC packets as well. Gabriel answered that the more efficient 6LOWPAN format is not compatible with LLC, assuming that there is no need for LLC/SNAP compatibility. Now, back to the technical issue: "compatible" may mean a lot of things here. My question was really about allowing both LLC and 6LOWPAN packets in the LoWPAN, which is a different kind of "compatible" than mandating the use of LLC or even LLC/SNAP for 6LOWPAN (which I agree we don't want to do for efficiency reasons). My assumption for an 802 network would be that there is a multiplexing layer below the IP-over-X layer that allows using the same network for other types of packets. In other word, the 802 network is not "ours", there may be a need for other traffic. I don't know whether any thought has been expended in the 15.4 committee at doing this more efficiently than with LLC. Of course, the multiplexing layer will need bits (at least one!). Not having it seems short-sighted, though -- other uses (even other encapsulations!) will come along. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@lists.ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@lists.ietf.org Thu Apr 21 12:35:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOeeY-0002Gj-C6; Thu, 21 Apr 2005 12:35:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOeeW-0002GW-Rl for 6lowpan@megatron.ietf.org; Thu, 21 Apr 2005 12:35:44 -0400 Received: from sapo.pt (relay1.ptmail.sapo.pt [212.55.154.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14921 for <6lowpan@lists.ietf.org>; Thu, 21 Apr 2005 12:35:41 -0400 (EDT) Message-Id: <200504211635.MAA14921@ietf.org> Received: (qmail 9179 invoked from network); 21 Apr 2005 16:35:08 -0000 Received: from unknown (HELO sapo.pt) (10.134.35.157) by relay1 with SMTP; 21 Apr 2005 16:35:08 -0000 Received: (qmail 22805 invoked from network); 21 Apr 2005 16:34:54 -0000 Received: from unknown (HELO mobilmoon) ([81.193.37.247]) (envelope-sender ) by mta7 (qmail-ldap-1.03) with SMTP for <6lowpan@lists.ietf.org>; 21 Apr 2005 16:34:54 -0000 From: "Tiago" To: <6lowpan@ietf.org> Date: Thu, 21 Apr 2005 17:34:53 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVGkAvM6iHQwfqqRXCmzyu87wf9eg== Cc: andre@iscac.pt Subject: [6lowpan] Service Discovery and Mobility X-BeenThere: 6lowpan@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.lists.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0614481270==" Sender: 6lowpan-bounces@lists.ietf.org Errors-To: 6lowpan-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0614481270== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C54698.7230C7E0" This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C54698.7230C7E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am a PhD student working in the Department of Informatics Engineering at the University of Coimbra. The main topic of my research work is the integration of WSN into 4G systems. In my opinion, this integration must be supported by IPv6. I have been following this recent group, mainly the two drafts produced. However, I would like to put you two questions: 1) In draft-kushalnagar-lowpan-goals-assumptions-00, on section 4.5 Service Discovery, this subject is not deeply explored, and I would like to know what you mean by Service Discovery. Are you talking about protocols? Is it possible the network know which kind of service it must support? Can this type of service be only provided at application layer? 2) In both drafts you do not explore mobility issues. Is this a concern to the group? Thanks and regards, Tiago Camilo ------=_NextPart_000_0030_01C54698.7230C7E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am = a PhD student working in the Department of Informatics Engineering at the = University of Coimbra.

The = main topic of my research work is the integration of WSN into 4G systems. In my = opinion, this integration must be supported by IPv6.

I = have been following this recent group, mainly the two drafts produced. However, I = would like to put you two questions:

 

1) = In draft-kushalnagar-lowpan-goals-assumptions-00, on section 4.5 Service Discovery, this subject is not deeply = explored, and I would like to know what you mean by Service Discovery. Are you = talking about protocols? Is it possible the network know which kind of service = it must support? Can this type of service be only provided at application = layer?

 

2) = In both drafts you do not explore mobility issues. Is this a concern to the group? =

 

Thanks and regards,

 

Tiago Camilo

 

------=_NextPart_000_0030_01C54698.7230C7E0-- --===============0614481270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@lists.ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0614481270==--