From manet-bounces@ietf.org Mon Oct 01 11:08:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcMmm-0006lP-6X; Mon, 01 Oct 2007 11:02:16 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IcMmk-0006gZ-9p for manet-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 11:02:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcMmj-0006Yu-Vw for manet@ietf.org; Mon, 01 Oct 2007 11:02:13 -0400 Received: from mailer.cacs.louisiana.edu ([130.70.72.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcMmZ-0003Sr-Oj for manet@ietf.org; Mon, 01 Oct 2007 11:02:09 -0400 Received: from pwserver.cacs.louisiana.edu (pwserver.cacs.louisiana.edu [130.70.77.78]) by mailer.cacs.louisiana.edu (8.13.1/8.13.1) with ESMTP id l91F12t9003655; Mon, 1 Oct 2007 10:01:04 -0500 Date: Mon, 1 Oct 2007 10:01:02 -0500 (CDT) From: "Dr. Hongyi Wu" To: tccc@cs.columbia.edu, manet@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on mailer.cacs.louisiana.edu X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Subject: [manet] CFPs: ICDCS'08 Workshop on Delay/Disruption-Tolerant Mobile Networks X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org [Apologies if you receive multiple copies of this CFP] CALL FOR PAPERS The 3rd International Workshop on Delay/Disruption-Tolerant Mobile Networks (In conjunction with ICDCS 2008), Beijing, China, June 20, 2008. http://www.cacs.louisiana.edu/~wu/DTMN08/. Mobile communication has experienced an explosive growth since close to quarter of a century. In particular, the mobile ad hoc network technology has attracted significant attention in the last decade or so due its challenging research problems, and span off such new research areas as mesh-based mobile networks and sensor networks. What characterizes nearly all of those mobile technologies is that during the exchange of information between the source and destination terminals, there exists a set of links which constitutes an end-to-end path over which the information is communicated. In some application scenarios, however, the connectivity between the mobile stations is poor due to very sparse network conditions (low node density) or due to unstable connectivity conditions (interference, fading, etc), and thus it is difficult to form a well-connected mesh network for transmitting data through end-to-end connections. In fact, even if there temporarily exists a path in the network for some portion of the communication, it is likely that the terminals will only be intermittently connected due to mobility. As a result, data are delivered in a store-carry and forward paradigm in such networks. Examples include vehicular networks, mobile sensor networks, deep space communications, etc. In this workshop we aim to explore novel research issues related to Delay (or Disruption)-Tolerant Mobile Networks (DTMN) and bringing together state-of-the-art contributions in this emerging area. Topics of interest include but are not limited to: - New Network Architectures and Applications * Mobile sensor networks * Vehicular networks * Heterogeneous mobile networks * Delay-tolerant applications - Protocol Design and Optimization * Delay-tolerant transport protocols * Mobility/disruption-aware routing protocols * Reliability and fault tolerance * Energy, processing power and storage requirement * Mobility modeling and mobility management * Localization and location management * Nodal synchronization * Security, privacy and incentives for co-operation * Resource allocation and QoS support - Performance Analysis and Evaluation - Testbed Implementation and Experimental Results Important Dates: - Paper Submissions: Dec. 15, 2007 - Notification: Feb. 11, 2008 - Final Version: March 9, 2008 - Workshop date: June 20, 2008 Submission Instructions: Papers are solicited in the IEEE proceedings format with up to eight (8) pages. Blinded submissions in PDF format must be sent to wu@cacs.louisiana.edu no later than December 15, 2008. Please include the authors' names and affiliations in the email body only. You will receive a confirmation within 24 hours. All submissions must be original prior unpublished work and not under review elsewhere. All papers will be reviewed blindly and selected based on their originality, merit, and relevance to the workshop. Accepted papers must be presented at the workshop, and will appear in the ICDCS workshop proceedings. Please email wu@cacs.louisiana.edu if you have any questions. Program Co-Chairs: - Liviu Iftode, Rutgers University - Hongyi Wu, University of Louisiana at Lafayette - Ichiro Satoh, National Institute of Informatics, Japan Program Committee: - Mostafa Ammar, Georgia Institute of Technology - Guohong Cao, Pennsylvania State University - Jiming Chen, Zhejiang University - Mooi Choo Chuah, Lehigh University - Jon Crowcroft, University of Cambridge - Cecilia Mascolo, University College of London - Tamer Nadeem, Siemens Corporate Research - Dmitri Perkins, University of Louisiana at Lafayette - Chunming Qiao, State University of New York at Buffalo - Konstantinos Psounis, University of Southern California - Kun Tan, Microsoft Research Asia - Nian-Feng Tzeng, University of Louisiana at Lafayette - Yu Wang, Microsoft - Jie Wu, Florida Atlantic University - Zhensheng Zhang, San Diego Research Center --Hongyi ======================================================================== Dr. Hongyi Wu, Associate Professor The Center for Advanced Computer Studies (CACS) University of Louisiana (UL) at Lafayette P.O. Box 44330, Lafayette, LA 70504-4330, U.S.A. Tel: 337-482-5779, Fax: 337-482-5791 E-mail: wu@cacs.louisiana.edu http://www.cacs.louisiana.edu/~wu ======================================================================== _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Oct 04 08:26:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdPiT-0003OS-9i; Thu, 04 Oct 2007 08:22:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IdPiQ-0003Mf-CQ for manet-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 08:22:06 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IdPiO-0003Ke-As for manet@ietf.org; Thu, 04 Oct 2007 08:22:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdPhP-0001I4-T4 for manet@ietf.org; Thu, 04 Oct 2007 08:21:03 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdPhJ-0005uw-N4 for manet@ietf.org; Thu, 04 Oct 2007 08:21:03 -0400 Received: by nf-out-0910.google.com with SMTP id d21so111745nfb for ; Thu, 04 Oct 2007 05:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; bh=A8N49hc4NEnUGIpQh9BXiX9eyW6MWAkbO0DY71l1CYc=; b=Uk+OKSKR1GZ5zyPedjWc7XCO9LxUTVJi2H+kqmriyzY4uZTTIfcWHnuNkzQyU3/Gjyks34e3P0WbmlY6TEL4VqHk9aScjn10GFYe/BWyBZz+7QEOYj182A76/d2V/UVcB9o2bWQj/Ut8kKc+ADYfkr4EwGFyaL4UAZu/cVxE/HA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=g+wOSN4XTfO4uzPr8JRZshI1hDoD4/NVyHQJ6a6NvUn0yQmjZGGLplohIOso28ybUdf5WciVbVFOKfPtPG/3Nxxi0aApZdOGLzLF8ZOC9/YMlYjzNSgNZjomKAQ3edm6DIw5DzTTDLkWmwxHmpGvJact/f9hofRbJWDmHsXdqVU= Received: by 10.78.130.6 with SMTP id c6mr6826494hud.1191500440321; Thu, 04 Oct 2007 05:20:40 -0700 (PDT) Received: from ?145.94.37.117? ( [145.94.37.117]) by mx.google.com with ESMTPS id c9sm2177935nfi.2007.10.04.05.20.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Oct 2007 05:20:39 -0700 (PDT) Message-ID: <4704DA91.2000403@gmail.com> Date: Thu, 04 Oct 2007 14:20:33 +0200 From: "(Jasper) Zhen Qin" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-TMDA-Confirmed: Thu, 04 Oct 2007 08:22:04 -0400 Subject: [manet] [Help] NIST's kernel AODV ver 1.5 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello everyone, I'm trying to compile and run an AODV monitoring software available at http://w3.antd.nist.gov/wctg/aodv_kernel/aodv_mon_download.htm for Sharp Zaurus PDA. According to the author, the AODV monitor software would only work with kernel AODV version 1.5, however on its webpage: http://w3.antd.nist.gov/wctg/aodv_kernel/index.html only version 2.x are available. The author's email account at klenb@nist.gov seems to be no longer valid. Could anyone please tell me where to download the Kernel AODV 1.5? or if you have it, please send to me. Thanks. Best Regards (Jasper) Zhen Qin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Oct 08 17:06:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iezgm-0007hP-V9; Mon, 08 Oct 2007 16:58:56 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iezgl-0007eX-CG for manet-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 16:58:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iezgl-0007cP-12 for manet@ietf.org; Mon, 08 Oct 2007 16:58:55 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iezge-0004WZ-Rb for manet@ietf.org; Mon, 08 Oct 2007 16:58:55 -0400 Received: by nf-out-0910.google.com with SMTP id d21so969241nfb for ; Mon, 08 Oct 2007 13:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=dlBo/Fd3iitY5V5ur1z0+MFRg17ULn/exXrHZ8oV/90=; b=mzcp2zGY1Wvrc/7B/EdJNS1YzvTtjx+8J8E+begm9FjggDw0zFP9oYHlKMZOxUpcvZPPdJgrr/5CzidUuQPARtj0EQLQ/ixKTVnBIsye8QS4amEUaFdaEd8+EiEDqCoYjMcB9h4C6F5xW7/SR1D3GrU1OM/75KCbbiNcusMmxLA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ioWEQ8xUlVOpRblGo70ZY4f2cFj2bQuTACXcfF9mnsL2KFzvoF2X/1MlWXAbHfHhIp3u79riv6w7iauzOLlwEBi064+oGY7mQvoU2j8H4WBMeldwHm1cf4NmOAPxFWWKjawQF1lid8fRECA9XqXucYGBN6YnMBA1RSZWHF/C3Iw= Received: by 10.82.138.6 with SMTP id l6mr6319673bud.1191877103437; Mon, 08 Oct 2007 13:58:23 -0700 (PDT) Received: by 10.82.117.11 with HTTP; Mon, 8 Oct 2007 13:58:23 -0700 (PDT) Message-ID: <7a1385300710081358y248f8eddg985c68c8295d51df@mail.gmail.com> Date: Mon, 8 Oct 2007 22:58:23 +0200 From: "Ron Lee" To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [manet] Implementation of ad-hoc routing protocols in Linux X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi all, I would like to write a survey about currently available implementations of ad-hoc routing protocols in Linux and compare them with each other. Could you please let me know what implementations are currently available? Thanks, Ron _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Oct 08 18:15:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If0oj-00019F-7u; Mon, 08 Oct 2007 18:11:13 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1If0oh-00018x-DJ for manet-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 18:11:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If0oh-00018p-3i for manet@ietf.org; Mon, 08 Oct 2007 18:11:11 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1If0oa-0006RL-PV for manet@ietf.org; Mon, 08 Oct 2007 18:11:11 -0400 Received: (qmail invoked by alias); 08 Oct 2007 22:10:55 -0000 Received: from e179158204.adsl.alicedsl.de (EHLO localhost) [85.179.158.204] by mail.gmx.net (mp054) with SMTP; 09 Oct 2007 00:10:55 +0200 X-Authenticated: #2746672 X-Provags-ID: V01U2FsdGVkX1/JNZ032obJraydXedZn2NLR3NH8sfo1VonU5BlkO j7rHKppKiamhUe From: elektra Organization: kein logo To: manet@ietf.org Subject: Re: [manet] Implementation of ad-hoc routing protocols in Linux Date: Tue, 9 Oct 2007 00:10:54 +0200 User-Agent: KMail/1.9.6 References: <7a1385300710081358y248f8eddg985c68c8295d51df@mail.gmail.com> In-Reply-To: <7a1385300710081358y248f8eddg985c68c8295d51df@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710090010.54786.onelektra@gmx.net> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Apart from academic research OLSR from olsr.org is the most widespread ATM in practise, it runs on Linux, Open-WRT capable devices, any version of BSD and Mac-OSX, even Microsoft Windows (98 or newer). Make sure to use the configuration file olsrd.conf.default.lq-fisheye in the "files" subdirectory if you want to use the network for real-life applications. This will load and utilize the Freifunk extensions. Freifunk-OLSR is not RFC3626 compliant, but it works (even with 600 low-cost boxes and thousands of actual users stressing the meshes in Berlin, Leipzig...) Some people reinvented/copied some of the Freifunk improvements to RFC3626 and named the whole thing RA-OLSR (Radio-Aware OLSR). I was told it shall become the second routing protocol of choice in 802.11s Note that there are several implementations of RFC3626. B.A.T.M.A.N. is relatively new and is developed by community network activists from Freifunk in Germany. It is intended to replace Freifunk-OLSR in community meshes. There are several versions for Layer 2.5 and 3, Linux only. You can get it at open-mesh.net. Mobilemesh is very, very old. And I know nobody that is actually using it anymore. Works also on Windows. AODV has received a lot of attention - you'll find several implementations for Linux (as kernel module as well as user space programs). Nobody I know is actually using it for real life projects, but it shall become the preferred protocol in 802.11s. I doubt it will do anything useful outside of simulations. Everybody I know that has tried it is now using Freifunk-OLSR or B.A.T.M.A.N. SRCRR has been developed at MIT Roofnet and is written in Click (interpreted routing language). The click modular router (the interpreter) works on Linux, but I guess it may be slow / unsuitable for small embedded routers. It comes with Meraki routers, however. SRCRR is a modifikation of DSR using linkstate informations. BABEL is working on Linux and Mac-OSX. According to Juliusz: "It is a loop-avoiding distance-vector routing protocol roughly based on HSDV and AODV, but with provisions for link cost estimation and redistribution of routes from other routing protocols." IPv6 only. LUNAR is also working on Layer 2.5 And there are probably more I just forgot to mention. cu elektra > Hi all, > > I would like to write a survey about currently available implementations of > ad-hoc routing protocols in Linux and compare them with each other. > Could you please let me know what implementations are currently > available? > > Thanks, > Ron > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Oct 09 01:38:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If7kJ-0008B9-4O; Tue, 09 Oct 2007 01:35:07 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1If7kH-00088X-Dh for manet-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 01:35:05 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1If7kG-00087a-Uf for manet@ietf.org; Tue, 09 Oct 2007 01:35:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If7ih-0006me-RQ for manet@ietf.org; Tue, 09 Oct 2007 01:33:27 -0400 Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1If7iS-0000yw-RF for manet@ietf.org; Tue, 09 Oct 2007 01:33:19 -0400 Received: by wa-out-1112.google.com with SMTP id k40so2694253wah for ; Mon, 08 Oct 2007 22:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=+QKHDFzp9gMMnWDlGX9yG5SCjSGToPGHBmcAV9NXElc=; b=P8W5A21e30zk11rxqXwZC/ygk9dYvVDwTk6wmJdEWyrd/ntM4uUSeJ0oy2wwQ5iZuBDoTWc6ghwrUkDB4oTEA+/75ePEMQQfHakzvI5R8xl/tV3EWlWq9Pk19xujSEa4QY2YrwLVY3kLXbVLt8gwuMXAVX1q/KuFG1Xw3Fkg1SU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Q1NwbSeG+SFzOvm5aYwU6zf7vSHTWLniaGh5lC5lUI+07TkmzusDNnYifR3DF7nIg8/EAj2g7XL0qJHtrQdWSs4ILSWSWEtFzAjtUTzPazdU0EaU4SzkcZgnFqGcqPpXJpzicLt2mLdX+8Kom+WatStXk10U//b00uWt41acf0w= Received: by 10.115.49.16 with SMTP id b16mr3929121wak.1191907972110; Mon, 08 Oct 2007 22:32:52 -0700 (PDT) Received: by 10.114.160.5 with HTTP; Mon, 8 Oct 2007 22:32:52 -0700 (PDT) Message-ID: <3e75b160710082232x7d964c0epbbbd6569225074ba@mail.gmail.com> Date: Tue, 9 Oct 2007 01:32:52 -0400 From: "Srikanth Hariharan" To: manet@ietf.org In-Reply-To: <3e75b160710081956p78c4d93flbbacce9edaa9279a@mail.gmail.com> MIME-Version: 1.0 References: <3e75b160710081956p78c4d93flbbacce9edaa9279a@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-TMDA-Confirmed: Tue, 09 Oct 2007 01:35:04 -0400 Subject: [manet] Jist SWANS - Illegal Constant Pool Index Help X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1634631750==" Errors-To: manet-bounces@ietf.org --===============1634631750== Content-Type: multipart/alternative; boundary="----=_Part_3221_16327985.1191907972103" ------=_Part_3221_16327985.1191907972103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I am trying to run a modified version of the Heartbeat example in Jist SWANS. The program compiles properly but when i execute the class file, secureNDP, I get the following error message. Could you please give me some suggestions on how I can fix this? The original Heartbeat example which uses the class, AppHeartbeat, runs fine without giving this error. I am unable to figure out what kind of mistakes result in such an error. Creating simulation nodes... Simulation exception! java.lang.VerifyError: (class: secureNDPNormal, method: signature: (Ljist /swans/net/NetAddress;)V) Illegal constant pool index at secureNDP.createNode (secureNDP.java:76) at secureNDP.createSim(secureNDP.java:161) at secureNDP.main(secureNDP.java:197) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at jist.runtime.Bootstrap$JavaMain.startSimulation (Bootstrap.java :163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at jist.runtime.Controller.processEvent(Controller.java:650) at jist.runtime.Controller.eventLoop (Controller.java:428) at jist.runtime.Controller.run(Controller.java:457) at java.lang.Thread.run(Thread.java:619) Thanks a lot, Srikanth ------=_Part_3221_16327985.1191907972103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,

I am trying to run a modified version of the Heartbeat example in Jist SWANS. The program compiles properly but when i execute the class file, secureNDP,  I get the following error message. Could you please give me some suggestions on how I can fix this?

The original Heartbeat example which uses the class, AppHeartbeat, runs fine without giving this error. I am unable to figure out what kind of mistakes result in such an error.

Creating simulation nodes... Simulation exception!
java.lang.VerifyError: (class: secureNDPNormal, method: <init> signature: (Ljist
/swans/net/NetAddress;)V) Illegal constant pool index
        at secureNDP.createNode (secureNDP.java:76)
        at secureNDP.createSim(secureNDP.java:161)
        at secureNDP.main(secureNDP.java:197)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at jist.runtime.Bootstrap$JavaMain.startSimulation (Bootstrap.java:163)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at jist.runtime.Controller.processEvent(Controller.java:650)
        at jist.runtime.Controller.eventLoop (Controller.java:428)
        at jist.runtime.Controller.run(Controller.java:457)
        at java.lang.Thread.run(Thread.java:619)


Thanks a lot,
Srikanth
 ------=_Part_3221_16327985.1191907972103-- --===============1634631750== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1634631750==-- From manet-bounces@ietf.org Tue Oct 09 19:36:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfOXC-0005UQ-3M; Tue, 09 Oct 2007 19:30:42 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IfOXA-0005UL-JT for manet-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 19:30:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfOXA-0005MQ-8m for manet@ietf.org; Tue, 09 Oct 2007 19:30:40 -0400 Received: from tema.lo-res.org ([193.238.157.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfOX5-00031j-NW for manet@ietf.org; Tue, 09 Oct 2007 19:30:36 -0400 Received: from localhost (localhost [127.0.0.1]) by tema.lo-res.org (Postfix) with ESMTP id A20633440D9 for ; Wed, 10 Oct 2007 01:29:54 +0200 (CEST) Received: from tema.lo-res.org ([127.0.0.1]) by localhost (tema.lo-res.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvtazdQeC-br for ; Wed, 10 Oct 2007 01:29:54 +0200 (CEST) Received: from [192.168.1.77] (zhaus [213.47.53.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: aaron) by tema.lo-res.org (Postfix) with ESMTP id 2782D3440D3 for ; Wed, 10 Oct 2007 01:29:54 +0200 (CEST) Subject: Re: [manet] Implementation of ad-hoc routing protocols in Linux From: aaron To: manet In-Reply-To: <200710090010.54786.onelektra@gmx.net> References: <7a1385300710081358y248f8eddg985c68c8295d51df@mail.gmail.com> <200710090010.54786.onelektra@gmx.net> Content-Type: text/plain Date: Wed, 10 Oct 2007 01:29:31 +0200 Message-Id: <1191972571.9193.6.camel@uhu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On Tue, 2007-10-09 at 00:10 +0200, elektra wrote: > Apart from academic research OLSR from olsr.org is the most widespread ATM in > practise, it runs on Linux, Open-WRT capable devices, any version of BSD and > Mac-OSX, even Microsoft Windows (98 or newer). Make sure to use the > configuration file olsrd.conf.default.lq-fisheye in the "files" subdirectory > if you want to use the network for real-life applications. This will load and > utilize the Freifunk extensions. Freifunk-OLSR is not RFC3626 compliant, but > it works (even with 600 low-cost boxes and thousands of actual users > stressing the meshes in Berlin, Leipzig...) Some people reinvented/copied > some of the Freifunk improvements to RFC3626 and named the whole thing I would like to add a few things: you can find the current development of what elektra called "Freifunk-OLSR" in the OLSR-NG branch: blog - http://olsr.funkfeuer.at discussion wiki - http://wiki.funkfeuer.at/index.php/OLSR-NG main page - http://www.olsr.org (includes pointers to the mailinglists) Current targets for OLSR-NG are to massively reduce the load (packets/cpu) and thus to make it highly scalable. In case anybody from the manet community knows any good simulators (in order to simulate the CPU load of the *actual* implementation (I don't want to re-implement in some NS-2 code or so)) I would be very interested by the way (UML - usermode linux is to weak). Any contributions are welcome. > RA-OLSR (Radio-Aware OLSR). I was told it shall become the second routing > protocol of choice in 802.11s Note that there are several implementations of > RFC3626. best, aaron. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 10 05:58:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfYHS-0001zK-Sc; Wed, 10 Oct 2007 05:55:06 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IfYHQ-0001yB-1y for manet-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 05:55:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfYHP-0001y3-OT for manet@ietf.org; Wed, 10 Oct 2007 05:55:03 -0400 Received: from web56704.mail.re3.yahoo.com ([66.196.97.63]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfYHG-0002ex-Ni for manet@ietf.org; Wed, 10 Oct 2007 05:55:03 -0400 Received: (qmail 85230 invoked by uid 60001); 10 Oct 2007 09:54:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=3ZH+N+YQ8FGY+mqyqfp+VLavB4CinGdQfuvdDmONyiHlOteM8EB1hBdokvQExf5jzFjBveAD6B4z9OO53N9JWvHI7h9YFBfk6Mmr5Qo9Le2pn9AIrpYnXd39CPKT/77MFEeiBNdFP62/1Xw68VyvP4moDUDEnd5U7FxxdKS2uhE=; X-YMail-OSG: FElJ7sIVM1lmoDvpf9Q8s_H4sJUjlkKL28.NAiaf_J23KwJ4pPY3tPLM9jCJbDzM7.kl0CrojLUfK12A3xRbIAl_t88qi8e_XCcWielFn1I_mmrh_gG89EMoStwJWg-- Received: from [217.218.101.34] by web56704.mail.re3.yahoo.com via HTTP; Wed, 10 Oct 2007 02:54:43 PDT Date: Wed, 10 Oct 2007 02:54:43 -0700 (PDT) From: naimeh karbalaei To: manet@ietf.org MIME-Version: 1.0 Message-ID: <527191.84932.qm@web56704.mail.re3.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [manet] Have AMROUTE, CAMP, AMRIS or any multicast protocols expects for ODMRP been implemented by using GLOMOSIM X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0672730138==" Errors-To: manet-bounces@ietf.org --===============0672730138== Content-Type: multipart/alternative; boundary="0-533315850-1192010083=:84932" Content-Transfer-Encoding: 8bit --0-533315850-1192010083=:84932 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi all Have AMROUTE, CAMP, AMRIS or any multicast protocols expects for ODMRP been implemented by using GLOMOSIM best regard karbalaei --------------------------------- Shape Yahoo! in your own image. Join our Network Research Panel today! --0-533315850-1192010083=:84932 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi all

Have AMROUTE, CAMP, AMRIS or any multicast protocols expects for ODMRP been implemented by using GLOMOSIM


best regard
karbalaei

Shape Yahoo! in your own image. Join our Network Research Panel today! --0-533315850-1192010083=:84932-- --===============0672730138== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0672730138==-- From manet-bounces@ietf.org Wed Oct 10 12:25:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfeK9-00043K-8n; Wed, 10 Oct 2007 12:22:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IfeK8-00042F-2j for manet-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 12:22:16 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IfeK7-000426-Pm for manet@ietf.org; Wed, 10 Oct 2007 12:22:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfeGs-0005eg-4L for manet@ietf.org; Wed, 10 Oct 2007 12:18:54 -0400 Received: from giorria.dit.ie ([147.252.28.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfeGr-0001RS-QX for manet@ietf.org; Wed, 10 Oct 2007 12:18:54 -0400 Received: by giorria.dit.ie (Postfix, from userid 1002) id 03C377DC92D; Wed, 10 Oct 2007 17:18:53 +0100 (IST) Received: from localhost (localhost.test.com [127.0.0.1]) by giorria.dit.ie (Postfix) with ESMTP id EC2967DC921 for ; Wed, 10 Oct 2007 17:18:52 +0100 (IST) X-Virus-Scanned: by Copperfasten Mail Firewall at dit.ie Received: from mustafa (wireless2.cnri.dit.ie [147.252.67.24]) by giorria.dit.ie (Postfix) with ESMTP id AF0547DC90B for ; Wed, 10 Oct 2007 17:18:49 +0100 (IST) From: "Mustafa Ramadhan" To: Date: Wed, 10 Oct 2007 17:16:51 +0100 Message-ID: <000501c80b58$f7a1e8f0$1843fc93@mustafa> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgLWPeEj1/5M0EiSMabVXubNQS/ig== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-TMDA-Confirmed: Wed, 10 Oct 2007 12:22:15 -0400 Subject: [manet] information X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1003814056==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1003814056== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C80B61.596650F0" This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C80B61.596650F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear sir/madam Is it possible to ask some questions related to MANET as I'm trying to develop a protocol. and if so, what is the right to follow ? Regards Mustafa ------=_NextPart_000_0006_01C80B61.596650F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear sir/madam

Is it possible to ask some questions related = to MANET as I’m trying to develop a protocol. and if so, what is the right = to follow ?

 

Regards

 

Mustafa

------=_NextPart_000_0006_01C80B61.596650F0-- --===============1003814056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1003814056==-- From manet-bounces@ietf.org Tue Oct 16 05:40:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihipp-0003cK-M7; Tue, 16 Oct 2007 05:35:33 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ihipn-0003XS-NM for manet-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 05:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihipm-0003VI-Or for manet@ietf.org; Tue, 16 Oct 2007 05:35:30 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihipg-0003fN-IR for manet@ietf.org; Tue, 16 Oct 2007 05:35:30 -0400 Received: by an-out-0708.google.com with SMTP id c17so146939anc for ; Tue, 16 Oct 2007 02:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=EA+jwD/rhIoWcHurk2h3mXTVHNlBoRq7j6eZwhO019A=; b=Gtk2qODsnBJE4aLBk6hlT8F3awTUUK1sGcBbO7/JlF1xQ4Fk6AhXOtHysUnhdKRPc8+N5SyocqSzuI7iKLWm1PvM7QqBfch3lb0qoxEZE1VqvWw3cBHO2qqL8vanvNPRP8GOaNAKP9uFCmD/KLR5oQsZVO4pwaip+WmrzcudKAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=T6lNEEn4sbzpyavnJWkVdJnOTo3SupsjgRRIT2ihVteM+MpM6VMcXO1GpWxkRCiaUrXSFXToYv5UbRmiJAC9ax4GkvMj0QKZWmieqYxc6bcOT/O8qno9FGhFVjb/s+lDrduE6OEilK7pxP9OxjJXZB+RY83VgxYA4z6cvlNLnwU= Received: by 10.142.253.21 with SMTP id a21mr1859847wfi.1192527308245; Tue, 16 Oct 2007 02:35:08 -0700 (PDT) Received: by 10.142.179.19 with HTTP; Tue, 16 Oct 2007 02:35:08 -0700 (PDT) Message-ID: Date: Tue, 16 Oct 2007 11:35:08 +0200 From: "Michael Bahr" To: manet@ietf.org Subject: Re: [manet] Implementation of ad-hoc routing protocols in Linux In-Reply-To: MIME-Version: 1.0 References: <7a1385300710081358y248f8eddg985c68c8295d51df@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1534109734==" Errors-To: manet-bounces@ietf.org --===============1534109734== Content-Type: multipart/alternative; boundary="----=_Part_17577_1482882.1192527308228" ------=_Part_17577_1482882.1192527308228 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Ron, There are many implementations of many ad hoc mesh routing protocols (or manet routing protocols or whatever you might call them) around. A very useful AODV implementation is aodv-uu by Uppsala University. The University of California Santa Barbara has an AODV website with links to other AODV implementations. HWMP, the default routing protocol of the upcoming IEEE 802.11s WLAN mesh networking standard, is based on AODV but has proactive extensions. If you configure HWMP in such a way that it does not use these proactive extensions, you get AODV. The "one laptop per child" project uses actually HWMP on their devices. The original developers of OLSR (T.H.Clausen, P. M=FChlethaler, et al) from INRIA have a website where you can find links to OLSR implementations. T.H. Clausen was also involved in the development of RA-OLSR which was part of 802.11s. And there is always to find more. Hope this helps, Michael On 10/8/07, Ron Lee < ronberlin@googlemail.com> wrote: > > Hi all, > > I would like to write a survey about currently available implementations > of > ad-hoc routing protocols in Linux and compare them with each other. > Could you please let me know what implementations are currently > available? > > Thanks, > Ron > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > ------=_Part_17577_1482882.1192527308228 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Ron,

There are many implem= entations of many ad hoc mesh routing protocols (or manet routing protocols= or whatever you might call them) around.

A very useful AODV impleme= ntation is aodv-uu by Uppsala University. The University of California Sant= a Barbara has an AODV website with links to other AODV implementations.

HWMP, the default routing protocol of the upcoming IEEE 802.11s WLA= N mesh networking standard, is based on AODV but has proactive extensions. = If you configure HWMP in such a way that it does not use these proactive ex= tensions, you get AODV. The "one laptop per child" project uses a= ctually HWMP on their devices.

The original developers of OLSR (T.H.Clausen, P. M=FChlethaler, et = al) from INRIA have a website where you can find links to OLSR implementati= ons. T.H. Clausen was also involved in the development of RA-OLSR which was= part of=20 802.11s.

And there is always <add your favorite web search here&g= t; to find more.

Hope this helps,
Michael



On 10/8/07, Ron Lee < ronberlin@googlemail.com>= ; wrote:
Hi all,

I would like to write a survey about currently available implementa= tions of
ad-hoc routing protocols in Linux and compare them with each ot= her.
Could you please let me know what implementations are currently
available?

Thanks,
Ron


___________________________= ____________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

------=_Part_17577_1482882.1192527308228-- --===============1534109734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1534109734==-- From manet-bounces@ietf.org Thu Oct 18 09:31:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiVOY-0000Iz-9J; Thu, 18 Oct 2007 09:26:38 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IiVOW-0000Io-Aq for manet-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 09:26:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiVOV-0000GW-Hk for manet@ietf.org; Thu, 18 Oct 2007 09:26:35 -0400 Received: from daimi.au.dk ([130.225.16.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiVOP-0001fl-6M for manet@ietf.org; Thu, 18 Oct 2007 09:26:29 -0400 Received: from grenada (dhcp-11-23-160 [10.11.23.160]) by daimi.au.dk (8.12.11.20060308/8.12.11) with ESMTP id l9IDQQ8R008664; Thu, 18 Oct 2007 15:26:26 +0200 From: "Lars Kristensen" To: Date: Thu, 18 Oct 2007 15:24:42 +0200 Message-ID: <002a01c8118a$3ebe3130$a0170b0a@w2kserver.daimi.au.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcgRij4Z8lwVNY3ARxKOwJQldJV60Q== X-Scanned-By: MIMEDefang 2.63 on 130.225.16.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: 'dat1 Mads' , 'Kristian Leth Espensen' Subject: [manet] Some functional issues concerning DYMO protocol operation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org We have recently been working with formal modelling and verification of the DYMO protocol. Our aim is to construct a complete model of the protocol version 10 and verify key behavioural properties related to the operation of the protocol As part of our initial modelling and verification, we have come across the following issues in version 10 the DYMO Internet draft. 1) When processing a routing message and the node is a DYMO router for the target node (draft, Sect. 5.3.4, page 20), it may respond with a RREQ flood (a RREQ addressed to oneself). It is not clear to us which information to put in the RREQ message, e.g., the originator address, hop limit, and sequence number of the RREQ. Also, it is unclear to us why this option is available? 2) When retransmitting a RREQ message (draft, Sect. 5.4, page 20), it is not explicitly stated whether the node sequence number is increased. If the sequence number is not increased when retransmitting it could cause a problem in the following way: A RREQ R1 is sent and lost before it reaches its target. Prior to retransmitting R1 another RREQ R2 (for a different target) with a higher sequence number is sent. When R1 is retransmitted, nodes who have seen R2 will consider R1 to be stale. This means that a route to the target of R1 will not be established. It might be a solution to simply create a new RREQ when retransmitting. In this case, the last sentence in the second paragraph of section 5.4: "If a route is not created within RREQ_WAIT_TIME, ThisNode may again try to discover a route by issuing another RREQ." can be replaced by: "If a route is not created within RREQ_WAIT_TIME, ThisNode may again try to discover a route by incrementing OwnSeqNum by one and retransmitting the RREQ with OrigNode.AddTLV.SeqNum set to the new OwnSeqNum. 3) In the description of the data structure route table entry (draft, Sect. 4.1) it is suggested that the address field can contain more than one node. It is not clear to us why this is the case. 4) The DYMO draft 10th revision introduces the concept of distance in addition to hop count. As we understand it, the idea is that distance is a more general metric, but in the routing message processing (draft, Sect. 5.3.4) it is always incremented by one. Why is the distance incremented by one and not by some general metric? 5) When judging the usefulness of routing information (draft, Sect. 5.2.1, the node being targeted is not taken into account. To us it looks like a new request with a higher sequence number can make an older request for another target node stale. This is because the sequence number in the old message is less than the sequence number found in the routing table. It might be a problem when two requests for different target nodes are sent (almost) simultaneously since they might overtake each other. A concrete example the following: Consider two RREQs R1 and R2 for two different target nodes and assume R2 has a higher sequence number than R1. The two RREQs are sent (almost) simultaneously. It might be the case that R2 arrives first at the surrounding nodes, e.g., because of overtaking on the network. If this is the case, R1 (arriving after R2) will be considered stale because R2 has a higher sequence number than R1. If they both use the same timeout this might keep happening, and the route being requested via R1 will not be discovered. We have not been able to find a mechanism in the current DYMO specification that copes with this issue. 6) We have investigated the judgement of routing information. We found that it is possible for a routing message to be both inferior and loop-possible at the same time e.g. if you have a RREQ with Node.Dist=3 and Route.Dist=1. It is not a major problem since both messages are discarded (draft, sect. 5.3.4), but it shows that the classification of routing information is not exclusive. A paper describing our initial work in more detail can be found via: http://www.daimi.au.dk/CPnets/workshop07/cpn/papers/Paper13.pdf /Lars Lars Michael Kristensen Associate Professor, PhD Department of Computer Science, University of Aarhus, Denmark Tel: +45 8942 5686 WWW: www.daimi.au.dk/~kris/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Oct 20 03:35:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij8mg-0001wo-0t; Sat, 20 Oct 2007 03:30:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ij8md-0001v2-Bo for manet-confirm+ok@megatron.ietf.org; Sat, 20 Oct 2007 03:30:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij8mc-0001hf-54 for manet@ietf.org; Sat, 20 Oct 2007 03:30:06 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij8mM-0004QI-7M for manet@ietf.org; Sat, 20 Oct 2007 03:29:57 -0400 Received: by nf-out-0910.google.com with SMTP id d21so584900nfb for ; Sat, 20 Oct 2007 00:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=F2Pts6N1cO2Em9XoReSeHq5OARV//3jhD+/c3FDgDI4=; b=sdJPUAAqTeE3RLQ3ObfIhvIzJM6uit5ptbZsD4OPBeFUhMzZVdpfdpWtQJmj/YsVXkF2pWV6s3m5NtI2g9P6ayJhmypPG4tJn04H/R1Lu72FolXEDPuibwko/uMRxL6PWW1IDAvcH1gZ6g4qGwtRGjXtgz/zw0a90ew3YNMaAzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cfiG9nf9D6CJtNoH6e8tug/2FqfNdzxfUiO4mP1CkqmhF1BjyMtm+zwmpjDpNo7OkdOPj7JPzroPprwUK0rX7AxWXkwPAM7RuBZdY1UOqT3H72/i83W5Yq2HSrvclkDGdAnRpZbnbfCb8HUjfsMc7zv69u5uJRYnpOevAPx+HnQ= Received: by 10.78.150.7 with SMTP id x7mr1875219hud.1192865364974; Sat, 20 Oct 2007 00:29:24 -0700 (PDT) Received: by 10.78.53.8 with HTTP; Sat, 20 Oct 2007 00:29:24 -0700 (PDT) Message-ID: <374005f30710200029o4fdcc627o725630ff6ebb5cd3@mail.gmail.com> Date: Sat, 20 Oct 2007 12:59:24 +0530 From: "Ian Chakeres" To: "Lars Kristensen" Subject: Re: [manet] Some functional issues concerning DYMO protocol operation In-Reply-To: <002a01c8118a$3ebe3130$a0170b0a@w2kserver.daimi.au.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <002a01c8118a$3ebe3130$a0170b0a@w2kserver.daimi.au.dk> X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: manet@ietf.org, dat1 Mads , Kristian Leth Espensen X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Thank you very much for the comments on the DYMO draft. You have supplied lots of good suggestions. More comments inline. On 10/18/07, Lars Kristensen wrote: > > We have recently been working with formal modelling and verification of the > DYMO protocol. Our aim is to construct a complete model of the protocol > version 10 and verify key behavioural properties related to the operation of > the protocol > > As part of our initial modelling and verification, we have come across the > following issues in version 10 the DYMO Internet draft. > > 1) When processing a routing message and the node is a DYMO router for the > target node (draft, Sect. 5.3.4, page 20), it may respond with a RREQ flood > (a RREQ addressed to oneself). It is not clear to us which information to > put in the RREQ message, e.g., the originator address, hop limit, and > sequence number of the RREQ. Also, it is unclear to us why this option is > available? Using a RREQ will flood routing information throughout the network on how to reach the RREQ originator (which in this case would be the TargetNode). Using a RREQ instead of a RREP will still get the principal RREQ originator information about ThisNode (the principal RREQ target). I have reversed the order (since RREP would likely be the preferred operation), and added to the text to indicate the target address of the RREQ. When I submit the next revision, please review this text (and others below) and provide additional suggestions. > 2) When retransmitting a RREQ message (draft, Sect. 5.4, page 20), it is not > explicitly stated whether the node sequence number is increased. If the > sequence number is not increased when retransmitting it could cause a > problem in the following way: > > A RREQ R1 is sent and lost before it reaches its target. Prior to > retransmitting R1 another RREQ R2 (for a different target) with a higher > sequence number is sent. When R1 is retransmitted, nodes who have seen R2 > will consider R1 to be stale. This means that a route to the target of R1 > will not be established. > > It might be a solution to simply create a new RREQ when retransmitting. In > this case, the last sentence in the second paragraph of section 5.4: > > "If a route is not created within RREQ_WAIT_TIME, ThisNode may again try to > discover a route by issuing another RREQ." > > can be replaced by: > > "If a route is not created within RREQ_WAIT_TIME, ThisNode may again try to > discover a route by incrementing OwnSeqNum by one and retransmitting the > RREQ with OrigNode.AddTLV.SeqNum set to the new OwnSeqNum. Instead of the above suggested text, I directly refer the reader to the section titled "RREQ Creation", which discusses incrementing of OwnSeqNum. > 3) In the description of the data structure route table entry (draft, Sect. > 4.1) it is suggested that the address field can contain more than one node. > It is not clear to us why this is the case. If the route is a prefix route, it denotes a subnet of addresses (nodes). If the text is unclear, can you please suggest a fix? > 4) The DYMO draft 10th revision introduces the concept of distance in > addition to hop count. As we understand it, the idea is that distance is a > more general metric, but in the routing message processing (draft, Sect. > 5.3.4) it is always incremented by one. Why is the distance incremented by > one and not by some general metric? DYMO-10 does not state that the distance be incremented by one, but by "more than one" or "at least one". I believe the current text leaves sufficient room for implementors to choose a larger distance increments to influence the routes chosen. If you have a specific suggestion for text changes, just email them to me. > 5) When judging the usefulness of routing information (draft, Sect. 5.2.1, > the node being targeted is not taken into account. To us it looks like a new > request with a higher sequence number can make an older request for another > target node stale. This is because the sequence number in the old message is > less than the sequence number found in the routing table. It might be a > problem when two requests for different target nodes are sent (almost) > simultaneously since they might overtake each other. > > A concrete example the following: Consider two RREQs R1 and R2 for two > different target nodes and assume R2 has a higher sequence number than R1. > The two RREQs are sent (almost) simultaneously. It might be the case that R2 > arrives first at the surrounding nodes, e.g., because of overtaking on the > network. If this is the case, R1 (arriving after R2) will be considered > stale because R2 has a higher sequence number than R1. If they both use the > same timeout this might keep happening, and the route being requested via R1 > will not be discovered. We have not been able to find a mechanism in the > current DYMO specification that copes with this issue. If you have a simple suggestion to solve this problem, please provide it. In practice I have not run into this issue too much, but I agree it could happen. > 6) We have investigated the judgement of routing information. We found that > it is possible for a routing message to be both inferior and loop-possible > at the same time e.g. if you have a RREQ with Node.Dist=3 and Route.Dist=1. > It is not a major problem since both messages are discarded (draft, sect. > 5.3.4), but it shows that the classification of routing information is not > exclusive. Excellent catch. The exact text for each these classifications is challenging. Can you see a simple way to exclude the loop-possible case from the inferior case while not complicating the loop-possible case dramatically (text or pseudo-code)? > A paper describing our initial work in more detail can be found via: > > http://www.daimi.au.dk/CPnets/workshop07/cpn/papers/Paper13.pdf > > /Lars > > Lars Michael Kristensen > Associate Professor, PhD > Department of Computer Science, > University of Aarhus, Denmark > Tel: +45 8942 5686 > WWW: www.daimi.au.dk/~kris/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Oct 22 08:36:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjwQr-00041E-TG; Mon, 22 Oct 2007 08:30:57 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IjsuC-0002ZG-60 for manet-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 04:45:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjsuB-0002Yd-Fx for manet@ietf.org; Mon, 22 Oct 2007 04:44:59 -0400 Received: from smtp.ee.ethz.ch ([129.132.2.219]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijsu5-0003xE-7Z for manet@ietf.org; Mon, 22 Oct 2007 04:44:59 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 38FD3D9357; Mon, 22 Oct 2007 10:44:32 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id G0aBZLYwAXX8; Mon, 22 Oct 2007 10:44:31 +0200 (MEST) Received: from [152.96.240.122] (unknown [152.96.240.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ee.ethz.ch (Postfix) with ESMTP id B8868D9338; Mon, 22 Oct 2007 10:44:31 +0200 (MEST) Message-ID: <471C5F1C.1010802@tik.ee.ethz.ch> Date: Mon, 22 Oct 2007 10:28:12 +0200 From: Rainer Baumann User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 To: undisclosed-recipients:; Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-Mailman-Approved-At: Mon, 22 Oct 2007 08:30:55 -0400 Subject: [manet] Generic Mobility Simulation Framework for VANETS (web interface online) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org We are glad to announce the public release of GMSF -- a Generic Mobility Simulation Framework -- dedicated to the generation of vehicular traces for VANETS. GMSF proposes two new models: MMTS and GIS-based models Features: - Supports classical mobility models (Random Waypoint, Manhattan) and two new models (MMTS and GIS-based models) - Different scenario are supported to represent three classes of topology: Rural, Urban, and City - Output to various formats: Ns-2, Qualnet/GlomoSim, Nam format, XML (generic trace format) - No installation required. GMSF is accessible through a public web interface where you can set parameters. Supported models: - Random Waypoint - Manhattan - MMTS: a multi-agent microscopic traffic simulator from Kai Nagel (at ETH Zurich and now at the Technical University at Berlin, Germany) - GIS: based on road topologies from the Swiss Geographic Information Sys= tem GMSF along with its documentation (Technical Report and more) is available at: http://gmsf.hypert.net Keywords: performance evaluation, simulation, vanets, vehicular motion, realistic mobility model. ---------------------------------------------------------------------- Rainer Baumann Dr. sc. ETH Zurich, MSc ETH CS, MAS SHE Lecturer and Research Fellow Computer Engineering and Network Laboratory ETH Zurich ETZ G 88 Gloriastrasse 35 8092 Zurich, Switzerland phone +41 44 632 51 87 mobile +41 79 263 81 40 fax +41 44 632 10 35 baumann@tik.ee.ethz.ch www.rainer.baumann.info ---------------------------------------------------------------------- Dr. Franck Legendre ETH Z=FCrich - Swiss Federal Institute of Technology Inst.f.Techn.Informatik u.Kommunik.Netze ETZ G 95 Gloriastrasse 35 8092 Z=FCrich Phone: +41 44 632 54 47 Mobile: +33 611 73 69 56 (de/von France) +41 76 217 69 56 (de/von Suisse) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Oct 23 06:27:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkGwH-0000RE-1x; Tue, 23 Oct 2007 06:24:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IkGvw-0008Pi-P3 for manet-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 06:24:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkGvu-0008M1-Kw for manet@ietf.org; Tue, 23 Oct 2007 06:24:22 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkGvs-0008LG-PE for manet@ietf.org; Tue, 23 Oct 2007 06:24:22 -0400 Received: from aste-genev-bois-153-1-35-230.w83-200.abo.wanadoo.fr ([83.200.25.230] helo=[192.168.147.106]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1IkGvr-000CKr-Mz; Tue, 23 Oct 2007 06:24:20 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.200.25.230 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/T3+GsInUQhyg1Sa0UCzLC Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8194AB5B-34B3-4AB7-BC6D-005449F2448B@computer.org> Content-Transfer-Encoding: 7bit From: Thomas Clausen Date: Tue, 23 Oct 2007 12:24:15 +0200 To: Manet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c Subject: [manet] Regarding packetbb constraints on ordering and uniqueness. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear all, As Ian hinted in his previous email, the issues regarding the constraints on TLV ordering and uniqueness may not have been expressed in a way which was clear to everybody. I will try to do my best to remedy that in this email, and I am sure that my co-authors will help supplement me where I am insufficient. I should add as a disclaimer that I am using a couple of examples in this email, and that these are chosen explicitly to show the ideas and principles -- to be illustrative only. I think that it is important to up-front recall what packetbb is and is not. Designed as a packet format for initially OLSRv2, since generalised based on discussions within the MANET wg, its goal is to efficiently encode the information exchanged as part of MANET routing protocols. Essentially, this means encode IP addresses (IPv4 and IPv6 both) in a compact way, associating attributes to such IP addresses, and encoding other information, specified by and exchanged as part of, a MANET routing protocol. Other than efficiently encoding what is being sent "on the wire" or "over the air", an additional goal has been to ensure that this encoding can be efficiently and uniquely parsed (I will define exactly what I mean by "parsing" later in this email) upon being received -- to put in simple terms: that addresses and associated attributes can be extracted efficiently. packetbb is not, however, a specification of a protocol and so does not specify or mandate any interpretation of or response to what is being exchanged. It is purely an encoding format, to be used by a protocol or protocols which will specify or mandate such interpretation or responses. While the issue being discussed at present is one of the constraints on TLVs in TLV blocks, I will take a step back and describe briefly some of the basics of packetbb, before discussing the specifics of TLVs and TLB constraints. IP addresses as commonly deployed, v6 and v4 indiscriminately, have a basic structure. In IPv4, for example, addresses deployed within the same administrative structure commonly share the same prefix, for example, 192.168.1/24, with each configured interface within that administrative structure having an unique last-octet. This is also true in IPv6 where, additionally, IP addresses assigned to the same interface commonly will share the same "host ID" (last 64 bits), with different prefixes. For example, an interface configured with a Link Local Address as well as a Global Addresses will use the same host ID as the latter 64 bits of either address. As specified, packetbb allows a protocol to exploit this by allowing addresses which have common parts to be represented together without repetition of the common part. Such addresses with common parts in them are grouped together in an "address block". Consider the following, simple, example. One has 10 IPv4 addresses and, considering a classic Link State protocol, a LS message may wish to advertise these as directly adjacent: 192.168.1.1, 192.168.1.10, 192.168.1.20, 192.168.1.30, 192.168.1.40 62.168.1.1, 62.168.1.10, 62.168.1.20, 62.168.1.30, 62.168.1.40 Explicitly representing these as above will "cost" 40 octets. The encoding structure in packetbb allows a protocol implementation to encode these addresses explicitly, or aggregated in two address blocks as follows: 192.168.1.{1,10,20,30,40} 62.168.1.{1,10,20,30,40} Which "costs" only 16 octets. Obviously, for IPv6 where addresses are larger, the gain may potentially be more significant. What is important to extract from the above is that, concerning packetbb: o an address being included in one or another address block is not, by packetbb, given any specific meaning. A protocol may or may not assign a specific meaning to addresses being in one or another address block; o packetbb allows representing addresses with "common bits" in an aggregated fashion; o specifically, packetbb does not state that "thou shall process these addresses in a specific order". It is up to the protocol to decide such -- packetbb is, on this matter, only concerned with an efficient way of encoding addresses for exchange over the wire/air. Now, assuming that our Link State protocol wants to say "Up" or "Down" for a links to adjacent nodes. Such information would be an attribute associated with an address, and in packetbb such are represented by TLVs. Assuming that the TLV concept in general is well understood, I will here focus only on that which is specific to packetbb. Still, TLVs have a type and a value (hence, the T and V), and so for the sake of this example we consider a TLV with type "STATE" and possible values of "UP" and "DOWN". Rather than having to include one explicit TLV for each address (which would again imply repetition of information -- something packetbb is intended to avoid, although packetbb also allows doing this if a protocol should so desire), TLVs associated to addresses in packetbb can be associated in different ways: o to a single address o to a range of addresses o to all addresses in an address block Finally, TLVs in packetbb can be of the "multivalue" kind -- which I will come back to shortly. So, in a subset of the example above, assuming that the attributes "STATE=UP" and "STATE=DOWN" is to be encoded for the following addresses according to the following: UP: 192.168.1.1, 192.168.1.20, 192.168.1.30 DOWN: 192.168.1.10, 192.168.1.40 packetbb allows that this can be done thus: Address Block: 192.168.1.{1,20,30,10,40} TLV Block T=STATE, V=UP, START=1, STOP=3 T=STATE, V=DOWN, START=4, STOP=5 Note that the order of the addresses within the address block is chosen such that only two TLVs (with start and stop indices) are needed. An alternative encoding, also supported by packetbb, could be to separate the addresses into two address blocks thus: Address Block: 192.168.1.{1,20,30} TLV Block T=STATE, V=UP, START=1, STOP=3 Address Block: 192.168.1.{10,40} TLV Block T=STATE, V=DOWN, START=1, STOP=2 What is important to extract from the above is that, concerning packetbb: o addresses can be collected into address blocks, and the addresses within an address block ordered such that it will allow the most efficient (compact) representation of the information exchanged by a given protocol; o packetbb provides structure which a protocol can optimise the use of, and packetbb does not mandate or suggest a specific usage; o the choice as to how addresses are collected into address blocks, and how TLVs are associated with these is a matter for the specification of the protocol(s) using packetbb. I promised to return to the "multivalue" TLV kind, which I will do now. Assuming that, in the example above, we wanted to also associate a value -- say, cost -- to each address, and assuming that these costs would be different for each address, such as this: 100: 192.168.1.1 2: 192.168.1.10 42: 192.168.1.20 1: 192.168.1.30 4: 192.168.1.40 Rather than to have to include five different TLVs, the multivalue TLV allows us to define a "COST" TLV and do the following: Address Block: 192.168.1.{1,20,30,10,40} TLV Block T=STATE, V=UP, START=1, STOP=3 T=STATE, V=DOWN, START=4, STOP=5 T=COST, V={100, 42, 1, 2, 4}, START=1, STOP=5 Notice that I included the start and stop indices also on the COST TLV. While this is not necessary since the TLV applies to all addresses in the TLV block, I included it in this example to show that also multivalue TLVs of course can apply to ranges of addresses. It should be noted that the choice of which TLV "kind" to use (multivalue, range-indexed, ....) when generating a message is not mandated by packetbb, since it depends on the given deployment, the protocol(s) etc. A final note on the structure of packetbb (simplified): o a set of address blocks, plus their associated address-block-tlv- blocks are included in a message. A message has a header (for controlled-scoped forwarding etc), and contains optionally a message TLV block. o a set of messages are included for transmission in a packet -- which also has an optional packet TLV block. The idea of collecting multiple messages in a packet and transmit these in one transmission is to reduce the MAC overhead -- something which has been observed to have a measurable impact when running MANETs -- but which will not be discussed further in this email. Now, let us look at the constraints. The specification of packetbb lists a number of constraints that must be satisfied when including TLVs in a given TLV block. For now, I will only discuss address block TLV blocks (i.e. TLV blocks associated to addres-blocks), but I will get back to message- and packet-TLV blocks later. The constraints as given and as discussed in recent emails on this mailing list are, essentially, that within an address block TLV block: o TLVs must be sorted in non-descending order according to their type; o no two TLVs of the same type may be associated with the same address. I will discuss these in the context of address block tlv blocks, however first I think that it is important to note one thing -- which is essentially a repeat from the above part of this email: o packetbb is concerned only with the encoding, not with the processing, specifically o the processing of entities (addresses) and attributes (that which is associated to addresses through TLVs), including the order of processing, is neither suggested nor mandated by packetbb. I want at this point to be very clear on one additional thing, which is that when in this email I talk about "parsing", I simply mean extracting entities and their associated attributes. For example, if I receive and parse a message as the following: Address Block: 192.168.1.{1,20,30,10,40} TLV Block T=STATE, V=UP, START=1, STOP=3 T=STATE, V=DOWN, START=4, STOP=5 T=COST, V={100, 42, 1, 2, 4}, START=1, STOP=5 the result of parsing is a data structure containing: 192.168.1.1 STATE=UP COST=100 192.168.1.10 STATE=DOWN COST=2 192.168.1.20 STATE=UP COST=42 192.168.1.30 STATE=UP COST=1 192.168.1.40 STATE=DOWN COST=4 Which may (of course) be represented and interpreted by the protocol in any which way and/or order it desires. This, in a way, is the crux of this discussion: packetbb is concerned only with encoding a data structure as the one above for transmitting over the wire/air and decoding the data structure at the receiver -- not with how or in which order the data structure is processed. So, in that sense, packetbb parsing comes before protocol processing, and protocol processing is concerned only with the decoded data structure -- not how this data structure happened to be encoded for transmission. Consider two protocols using identical TLVs -- say "STATE" and "COST" as above. Protocol A may, for correct functioning, require that receivers process the STATE TLV before the COST TLV. Protocol B, however, requires for correct functioning that COST TLVs be processed before STATE TLVs. The specification of each protocol would state exactly which order is required (and the implementations, correspondingly, doing exactly that), and this would be entirely independent of how these are encoded for transmission. What is important to extract from the above is that, concerning packetbb: o the order in which TLVs are encoded by packetbb for transmission is independent from the order in which TLVs are processed by a protocol specification; o a protocol specification SHOULD specify, assuming that the processing order is important, what this processing order is. I will touch upon the benefits of mandating an encoding-order in packetbb a bit later in this email, since it should become clearer what they are once the second constraint -- uniqueness -- has been discussed. The second constraint for address-block tlv-blocks is that: o no two TLVs of the same type may be associated with the same address. If we consider the previous example with one small modification: Address Block: 192.168.1.{1,20,30,10,40} TLV Block T=STATE, V=UP, START=1, STOP=3 T=STATE, V=DOWN, START=3, STOP=5 T=COST, V={100, 42, 1, 2, 4}, START=1, STOP=5 the result of parsing is a data structure containing: 192.168.1.1 STATE=UP COST=100 192.168.1.10 STATE=DOWN COST=2 192.168.1.20 STATE=UP COST=42 192.168.1.30 STATE=UP/DOWN COST=1 192.168.1.40 STATE=DOWN COST=4 we note that the address 192.168.1.30 now has both UP and DOWN associated. Clearly, the sending node transmitted ambiguous information -- and while a discussion as to what this means and how to treat that belongs elsewhere (i.e. not in packetbb), it suffices to simply observe this to be the case. On the mailing-list, a number of suggestions as to how to handle this have been suggested, as alternatives to the constraint in packetbb. While diverse, these suggestions essentially come down to something like the following: - pick the first/last TLV and ignore the other(s) to disambiguify; Now, on the "pick the last/first TLV and ignore the other(s), this won't work. Consider the following example: Address Block: 192.168.1.{1,20,30,10,40} TLV Block T=STATE, V=UP, START=1, STOP=2 (i) T=STATE, V=DOWN, START=2, STOP=4 (ii) T=STATE, V=UP, START=4, STOP=5 (iii) T=COST, V=10, START=1, STOP=2 (iv) T=COST, V=1, START=3, STOP=5 (v) This address-block-TLV-block has three TLVs of type STATE which are overlapping. The roman numbers to the right is to allow references to an exact TLV in the following discussion. The result of parsing is a data structure containing: 192.168.1.1 STATE=UP COST=100 192.168.1.10 STATE=DOWN COST=2 192.168.1.20 STATE=UP/DOWN COST=42 192.168.1.30 STATE=UP/DOWN COST=1 192.168.1.40 STATE=UP COST=4 Ok, ambiguous information, let's apply the "Last TLV wins" rule. How do we do that? For the address 192.168.1.20, the first TLV with type STATE is (i) and the last is (ii) For the address 192.168.1.30, the first TLV with type STATE is (ii) and the last is (iii) So, which TLV is "last"? If we go by "last TLV per address", then we will end up using some of (i) and some of (ii), but certainly not all of (i) nor all of (ii) -- leading to partial and incoherent use of the information in the TLVs. So, the "pick the first/last TLV" solution, while perhaps disambiguifying matters for a single address do not solve the problem -- the protocol receiving the data structure resulting from parsing still becomes exposed to incoherent information. The constraint of "no two TLVs of the same type may be associated with the same address" does solve this. Now, I carefully mentioned that I would discuss this for address- block-tlv-blocks, and then return to message-tlv-blocks and packet- tlv-blocks later. As can be noted from the packetbb I-D, the constraint of uniqueness is relaxed for message- and packet- tlv- blocks, noting that: o Packet and message TLVs MUST be defined so as to indicate whether two TLVs with the same tlv-fulltype are, or are not, allowed in the same packet or message TLV block, respectively. The reason that this is permissible in message- and packet- tlv- blocks is, that tlvs in those tlv-blocks associate to one and only one entity: the message or the packet. As such, while ambiguity still may persist, the risk of "partial" or "incoherent" association (and, thus, usage) of part of one and part of another tlv does not exist. I promised to touch upon the benefits of these constraints, which I will do in the following -- but will otherwise refer to the emails from Chris Dearlove, Justin Dean and myself on the list for more details. The "uniqueness" constraint of address block TLVs is there for the reason of ensuring non-ambiguity and coherence in the data structure resulting from parsing an incoming message. Keeping the TLVs within a TLV block ordered by TLV type means that verifying (at both the sending side, prior to transmitting a message, and on the receiving side during parsing but prior to presenting the resulting data structure to the protocol) this uniqueness criteria can be done in a single linear pass. Having the TLVs unordered would imply backtracking and maintaining additional data structures. I want to emphasise that the order of inclusion of TLVs in a TLV block is not indicative or suggestive of the order of processing of the TLVs within that TLV block, just as the order of inclusion of addresses within an address block (or address blocks) is not indicative or suggestive of the order of processing of these addresses. Indeed, such is, if processing order is important, to be specified by the protocol using packetbb. An additional advantage of the ordering is, that if one is looking for a specific TLV (e.g. a protocol or protocol extension where processing the message is not worth it unless tlv type XXX is included) then one can terminate parsing the message (or packet or address block) early, i.e. once parsing encounters a tlv with type >XXX. A clear example hereof would be "do not process this message unless a signature TLV is included". It has been pointed out that for that reason it would be helpful if a range of TLV types were allocated which "comes before everything else", and that guidelines be provided to IANA as to how types from that range are assigned -- and this point has been updated in the I-D. A new I-D (draft-ietf-manet-packetbb-10.txt) has been submitted to the IETF, in which: o a range of (the numerically first, in order to retain the benefits of ordering) address-block-, message- and packet- TLV types are reserved for assignment where it is important that these "come before anything else", as indicated in the preceding paragraph) is specified; o clarifications have been provided regarding the ordering of TLV inclusion in TLV blocks being a matter of encoding-order only, not processing order. The I-D should appear shortly (there were some issues with the I-D submission tool slowing things down, but thanks to Michael, the tool- man at the IETF, I believe that these have been resolved and the I-Ds started flowing). I hope that this email clarifies these issues, and that otherwise you will not hesitate to ask clarifying questions. Sincerely, Thomas -- Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Oct 23 13:13:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkNG4-0004YP-EU; Tue, 23 Oct 2007 13:09:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IkNG1-0004M8-Os for manet-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 13:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkNG0-0004KX-Fy for manet@ietf.org; Tue, 23 Oct 2007 13:09:32 -0400 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkNFv-0002Zk-5W for manet@ietf.org; Tue, 23 Oct 2007 13:09:32 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1375346rvb for ; Tue, 23 Oct 2007 10:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=Q47HuADClp072qjtz87MBxrNtLUlPbhOIQm/2WMkK3k=; b=cQQSXEqFxyEz+l9IiA6eGpY8PRSrEZTlxYE+FxNqqWa766IU5Y/vRxhjD3A+vhSHHWReu8fuH+QUJ3kP1k+uLdH9YZ9/SlJHhswDq9jZrGiR53Uccs8lQDSEzzTxUm623e8ILg1vFgk/H0EFTZVrCRPYS10LZH5My2ooM1MeKSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=EsvuYdphnUWdPzAeNPGwt93O61stNb67j4IMPFsU3c/8SRH6qUk7mKrdDTyJJMRNrdzRBzrOREc9p0yvbepH9J7qNR1JOrYcDja1bNz3EyDVh+k9gOIz1xqrUFNlbxGq8q5CgAT6vcMzYJNAEBYzC8iiz7+d849q5GZokmqh59A= Received: by 10.141.202.12 with SMTP id e12mr3225545rvq.1193159339544; Tue, 23 Oct 2007 10:08:59 -0700 (PDT) Received: by 10.141.15.18 with HTTP; Tue, 23 Oct 2007 10:08:59 -0700 (PDT) Message-ID: <13786f330710231008h2e10ed48vf45944a0ff1aba6@mail.gmail.com> Date: Tue, 23 Oct 2007 13:08:59 -0400 From: "Joseph Kopena" To: Manet Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. In-Reply-To: <8194AB5B-34B3-4AB7-BC6D-005449F2448B@computer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8194AB5B-34B3-4AB7-BC6D-005449F2448B@computer.org> X-Google-Sender-Auth: 042018ecd7446678 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On 10/23/07, Thomas Clausen wrote: > As Ian hinted in his previous email, the issues regarding the > constraints on TLV ordering and uniqueness may not have been > expressed in a way which was clear to everybody. I will try to do my > best to remedy that in this email, and I am sure that my co-authors > will help supplement me where I am insufficient. Hi Thomas, Thank you for the email. It is very clear & informative, and the examples simple & useful. Some questions inline, with text snipped: > The "uniqueness" constraint of address block TLVs is there for the > reason of ensuring non-ambiguity and coherence in the data structure > resulting from parsing an incoming message. Keeping the TLVs within a > TLV block ordered by TLV type means that verifying (at both the > sending side, prior to transmitting a message, and on the receiving > side during parsing but prior to presenting the resulting data > structure to the protocol) this uniqueness criteria can be done in a > single linear pass. Having the TLVs unordered would imply > backtracking and maintaining additional data structures. What is the consensus on the best way to represent a graph in PacketBB? This seems very simple & reasonably efficient if non-unique TLVs are allowed, simply list all addresses and have a set of possibly non-unique TLVs reporting edge pairs. The only solution I've come up with off-hand which maintains uniqueness is having 1 TLV per node and stuffing all neighbor indexes into that value. That's admittedly slightly more efficient bit-wise, but requires the parent object to do more of its own parsing and requires tighter interaction with PacketBB (because the parent object is now operating on indexes of this address block, rather than asserting & retrieving addresses). What's the recommended idiom for this, if there is one? > I want to emphasise that the order of inclusion of TLVs in a TLV > block is not indicative or suggestive of the order of processing of > the TLVs within that TLV block, just as the order of inclusion of > addresses within an address block (or address blocks) is not > indicative or suggestive of the order of processing of these > addresses. Indeed, such is, if processing order is important, to be > specified by the protocol using packetbb. If processing order is actually important, which I could believe is a fairly common scenario, doesn't sorting the TLVs for parsing actually slow things down in many cases? For example, suppose I need to process STATE before COST. If the TLVs are not sorted, the parent object can place them in that order, and then simply parse & process them linearly on the receiver end. If PacketBB sorts those TLVs however, the protocol designer may have no control over the order if they're following IANA numbers or mixing protocol elements/existing code. They could quite possibly wind up in the wrong order from the processing perspective. Necessarily sorting all TLVs therefore avoids the aforementioned possible costs in parsing (discussed later), only to incur them in processing. > An additional advantage of the ordering is, that if one is looking > for a specific TLV (e.g. a protocol or protocol extension where > processing the message is not worth it unless tlv type XXX is > included) then one can terminate parsing the message (or packet or > address block) early, i.e. once parsing encounters a tlv with type > >XXX. A clear example hereof would be "do not process this message > unless a signature TLV is included". It has been pointed out that for > that reason it would be helpful if a range of TLV types were > allocated which "comes before everything else", and that guidelines > be provided to IANA as to how types from that range are assigned -- > and this point has been updated in the I-D. This shortcut-parsing advantage is worth keeping in mind, but ultimately not a very strong argument because it works contrary to an important supporting argument for the constraints---that they don't effect processing order. It should likely also be cause for concern that there is already extra management effort & resource costs (restrictions on the number space) being incurred by the necessity of having to carefully choose identifiers for at least this feature. It seems like this same shortcutting can be achieved if PacketBB simply has to preserve the ordering generated by the parent object. In addition to being simpler & more flexible from protocol designers' perspectives, that has the additional benefit that the parent can ensure the signature is first, allowing the receiver to shortcircuit all of the parsing if it's not there. In the current scheme it has to parse any TLVs which just happen to have an identifier lower than whatever the signature fulltype happens to be. But, in general, I think this whole discussion hinges on the importance of uniqueness and how costly it can be to detect non-uniqueness. I'm curious to hear opinions on representing graphs, as that seems to be a reasonable example which is naturally represented with non-unique TLVs. It also seems to me that the costs of sorting the TLVs are no better than determining uniqueness given unsorted TLVs, while also making the spec less flexible & forcing everyone to incur that cost (which is not true for unsorted, possibly non-unique TLVs). Even if that weren't true, the costs for detecting non-uniqueness over unsorted TLVs if required by some protocol only seem to be an issue for the most severely limited devices. Based on my experiences developing for a number of PDA platforms, I would not be overly concerned about incurring that cost in return for a simpler, more flexible spec. Uniqueness and/or sorting also could, and maybe should, be left up to the system or client protocols, system-wide or child-protocol specification amenable to compile-time inclusion/exclusion, rather than mandated on everyone. Thx! -- - joe kopena right here and now. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Oct 23 13:15:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkNLX-0006tT-Uk; Tue, 23 Oct 2007 13:15:16 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IkNLR-0006qh-5e for manet-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 13:15:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkNLQ-0006qT-AO; Tue, 23 Oct 2007 13:15:08 -0400 Received: from ns1.neustar.com ([156.154.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkNLP-0002nT-6g; Tue, 23 Oct 2007 13:15:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E686826E74; Tue, 23 Oct 2007 17:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IkNLJ-0001Uw-Qr; Tue, 23 Oct 2007 13:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 23 Oct 2007 13:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Generalized MANET Packet/Message Format Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-packetbb-10.txt Pages : 56 Date : 2007-10-23 This document specifies a multi-message packet format that may be used by mobile ad hoc network routing and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-packetbb-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-packetbb-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-23122313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-packetbb-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-packetbb-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-23122313.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Wed Oct 24 09:18:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikg2i-0005r1-Vm; Wed, 24 Oct 2007 09:13:04 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ikg2g-0005ZR-Q5 for manet-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 09:13:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikg2g-0005Xk-7q for manet@ietf.org; Wed, 24 Oct 2007 09:13:02 -0400 Received: from daimi.au.dk ([130.225.16.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikg2f-0004H4-GD for manet@ietf.org; Wed, 24 Oct 2007 09:13:02 -0400 Received: from grenada (dhcp-11-23-160 [10.11.23.160]) by daimi.au.dk (8.12.11.20060308/8.12.11) with ESMTP id l9ODCwMf022870; Wed, 24 Oct 2007 15:12:58 +0200 From: "Lars Kristensen" To: "'Ian Chakeres'" References: <002a01c8118a$3ebe3130$a0170b0a@w2kserver.daimi.au.dk> <374005f30710200029o4fdcc627o725630ff6ebb5cd3@mail.gmail.com> Subject: RE: [manet] Some functional issues concerning DYMO protocol operation Date: Wed, 24 Oct 2007 15:11:12 +0200 Message-ID: <000001c8163f$5a6f6660$a0170b0a@w2kserver.daimi.au.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <374005f30710200029o4fdcc627o725630ff6ebb5cd3@mail.gmail.com> Thread-Index: AcgS8DH6YqKQp/KCRciL5jW19DdMXQDTKQQg X-Scanned-By: MIMEDefang 2.63 on 130.225.16.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: manet@ietf.org, 'dat1 Mads' , 'Kristian Leth Espensen' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian, >Using a RREQ will flood routing information throughout the network on >how to reach the RREQ originator (which in this case would be the >TargetNode). Using a RREQ instead of a RREP will still get the >principal RREQ originator information about ThisNode (the principal >RREQ target). >I have reversed the order (since RREP would likely be the preferred >operation), and added to the text to indicate the target address of the >RREQ. When I submit the next revision, please review this text (and >others below) and provide additional suggestions. OK. We will take a closer look at the text in the next version and try to incorporate this into our model. >Instead of the above suggested text, I directly refer the reader to the >section titled "RREQ Creation", which discusses incrementing of >OwnSeqNum. We considered making a reference to section 5.3.1 (as you propose). We decided to propose the more direct formulation since 5.3.1 specifies how to set all fields of the RREQ - and it is only the originators sequence number that has to be modified when retransmitting. Hence, 5.3.1 contains a lot of text that is not required for implementing the retransmission. >If the route is a prefix route, it denotes a subnet of addresses >(nodes). If the text is unclear, can you please suggest a fix? Your comment clarifies it. A suggestion for making this more explicit would be to describe Route.Address by: "The IP (host or network) destination address of the node(s) associated with the routing table entry" >DYMO-10 does not state that the distance be incremented by one, but by >"more than one" or "at least one". I believe the current text leaves >sufficient room for implementors to choose a larger distance increments >to influence the routes chosen. If you have a specific suggestion for >text changes, just email them to me. Having checked DYMO-10, we see that the description of Node.AddTLV.Dist is: "A metric of the distance to reach the associated Node.Address. This field is incremented by at least one at each intermediate DYMO router, except the TargetNode.AddTLV.Dist. The TargetNode's distance information is not modified." This is fine, but seems be inconsistent with the description in Sect 3.4 on RM processing which states the following: "For each address (except the TargetNode) in the RM that includes AddTLV.Dist information, the AddTLV.Dist information is incremented by one (1)." >If you have a simple suggestion to solve this problem, please provide >it. In practice I have not run into this issue too much, but I agree it >could happen. At the moment we do not have a simple suggestion for solving this problem. The problem is also less likely to occur now that OwnSeqNum is incremented when a RREQ is retransmitted. >The exact text for each these classifications is challenging. Can you >see a simple way to exclude the loop-possible case from the inferior >case while not complicating the loop-possible case dramatically (text >or pseudo-code)? We currently do not have sufficient intuition on the classification in order to suggest a good solution to this. It is of course easy to rewrite the formulas to ensure that the classes become disjoint, but that defeats the purpose of having the classification. Perhaps it is such that there is routing information which is rightly considered both inferior and loop-possible. As long as it is ensured that routing information that falls into more than one class is treated in the same way this is not a problem in practice. Lars _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 24 11:51:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiT6-0007ok-3n; Wed, 24 Oct 2007 11:48:28 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IkiT3-0007ew-Ef for manet-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 11:48:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiT3-0006lx-3S for manet@ietf.org; Wed, 24 Oct 2007 11:48:25 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkiSZ-0000Yd-IJ for manet@ietf.org; Wed, 24 Oct 2007 11:47:55 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9OFlskF022893 for ; Wed, 24 Oct 2007 16:47:54 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9OFlrV6014870 for ; Wed, 24 Oct 2007 16:47:53 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 24 Oct 2007 16:47:53 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 24 Oct 2007 16:47:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Oct 2007 16:47:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-manet-jitter-02 Thread-Index: AcgWMSJjZsQSXa2+RCumh2iZrmtgmQAI+jGQ From: "Dearlove, Christopher (UK)" To: X-OriginalArrivalTime: 24 Oct 2007 15:47:54.0616 (UTC) FILETIME=[3DDFAF80:01C81655] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Thomas Clausen Subject: [manet] draft-ietf-manet-jitter-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org As part of the IESG review process for draft-ietf-manet-jitter-02, comments from Ross Callon (supervising AD) and Adrian Farrel suggest that in Section 5 where it is suggested that jitter "MAY be employed" that this is strengthened to "SHOULD be employed". (The possibility of it being "MUST be employed" was also considered.) The authors of the document agree with this suggestion, but it is also appropriate that the WG support this change, and any feedback is welcome. Christopher Dearlove ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 24 11:56:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiZl-0006E9-Fm; Wed, 24 Oct 2007 11:55:21 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IkiZj-0006Dj-F4 for manet-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 11:55:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiZj-0005yX-4o for manet@ietf.org; Wed, 24 Oct 2007 11:55:19 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkiZR-0003Dk-3c for manet@ietf.org; Wed, 24 Oct 2007 11:55:06 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9OFsbtm025758 for ; Wed, 24 Oct 2007 16:54:37 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9OFsbCt018528 for ; Wed, 24 Oct 2007 16:54:37 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 24 Oct 2007 16:54:37 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 24 Oct 2007 16:54:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] draft-ietf-manet-jitter-02 Date: Wed, 24 Oct 2007 16:54:35 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] draft-ietf-manet-jitter-02 Thread-Index: AcgWMSJjZsQSXa2+RCumh2iZrmtgmQAI+jGQAAA+xBA= References: From: "Dearlove, Christopher (UK)" To: X-OriginalArrivalTime: 24 Oct 2007 15:54:37.0360 (UTC) FILETIME=[2DED8B00:01C81656] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Thomas Clausen X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org (Apologies, something went wrong with my CC-ing to both of the other authors.) As part of the IESG review process for draft-ietf-manet-jitter-02, comments from Ross Callon (supervising AD) and Adrian Farrel suggest that in Section 5 where it is suggested that jitter "MAY be employed" that this is strengthened to "SHOULD be employed". (The possibility of it being "MUST be employed" was also considered.) The authors of the document agree with this suggestion, but it is also appropriate that the WG support this change, and any feedback is welcome. Christopher Dearlove ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 24 16:49:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikn5x-0007p3-7o; Wed, 24 Oct 2007 16:44:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ikn5v-0007mA-OG for manet-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 16:44:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikn5v-0007bE-0w for manet@ietf.org; Wed, 24 Oct 2007 16:44:51 -0400 Received: from hpsmtp-eml18.kpnxchange.com ([213.75.38.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikn5m-0005Ru-Qc for manet@ietf.org; Wed, 24 Oct 2007 16:44:49 -0400 Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 22:44:19 +0200 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 22:44:18 +0200 From: "Teco Boot" To: "'Thomas Clausen'" References: <8194AB5B-34B3-4AB7-BC6D-005449F2448B@computer.org> In-Reply-To: <8194AB5B-34B3-4AB7-BC6D-005449F2448B@computer.org> Subject: RE: [manet] Regarding packetbb constraints on ordering and uniqueness. Date: Wed, 24 Oct 2007 22:44:16 +0200 Message-ID: <004e01c8167e$a5e1ace0$f1a506a0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgVYySYOuSq1frpRyeFcFdWG3Bv/ABFFvMA Content-Language: nl X-OriginalArrivalTime: 24 Oct 2007 20:44:18.0993 (UTC) FILETIME=[A6304210:01C8167E] X-Spam-Score: -1.0 (-) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Thomas, thanks for the clarification. Comments and questions inline. Teco. > The encoding structure in packetbb allows a protocol implementation > to encode these addresses explicitly, or aggregated in two address > blocks as follows: > 192.168.1.{1,10,20,30,40} > 62.168.1.{1,10,20,30,40} > Which "costs" only 16 octets. This is marketing specs. The compact representation needs additional fields providing information for decoding. Generally spoken, I agree that when large ranges of addresses are sent, compressing helps a lot. > Now, on the "pick the last/first TLV and ignore the other(s), this > won't work. Consider the following example: > > Address Block: 192.168.1.{1,20,30,10,40} > TLV Block T=STATE, V=UP, START=1, STOP=2 (i) > T=STATE, V=DOWN, START=2, STOP=4 (ii) > T=STATE, V=UP, START=4, STOP=5 (iii) > T=COST, V=10, START=1, STOP=2 (iv) > T=COST, V=1, START=3, STOP=5 (v) > > This address-block-TLV-block has three TLVs of type STATE which are > overlapping. The roman numbers to the right is to allow references > to an exact TLV in the following discussion. > > The result of parsing is a data structure containing: > > 192.168.1.1 STATE=UP COST=100 > 192.168.1.10 STATE=DOWN COST=2 > 192.168.1.20 STATE=UP/DOWN COST=42 > 192.168.1.30 STATE=UP/DOWN COST=1 > 192.168.1.40 STATE=UP COST=4 > I can't follow. I would come up with something very different: 192.168.1.1 STATE=UP COST=10 192.168.1.10 STATE=UP/DOWN COST=1 192.168.1.20 STATE=UP/DOWN COST=10 192.168.1.30 STATE=DOWN COST=1 192.168.1.40 STATE=UP COST=1 Can you provide all encoding to decoding to encoding info for this example? I can't come up with an example where real problems are introduced. When ambiguous info is being transported using packetbb, I do not expect packetbb "repairing" the garbage. Can you suggest how repeating information is transported? Assume for example DOWN/UP timestamps: 192.168.1.1 STATE=UP COST=10 DU=8.20-8.44 DU=9.00-9.06 192.168.1.10 STATE=DOWN COST=1 192.168.1.20 STATE=DOWN COST=10 DU=9.30-9.45 192.168.1.30 STATE=DOWN COST=1 192.168.1.40 STATE=UP COST=1 Don't ask why sending this info. It is just an example. (hint: think of forecasted outages). _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 24 18:13:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkoQW-0003Nh-Ma; Wed, 24 Oct 2007 18:10:12 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IkoQU-0003FJ-OP for manet-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 18:10:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkoQU-0003Dt-CO for manet@ietf.org; Wed, 24 Oct 2007 18:10:10 -0400 Received: from mho-01-bos.mailhop.org ([63.208.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkoQO-0007iF-7w for manet@ietf.org; Wed, 24 Oct 2007 18:10:10 -0400 Received: from aste-genev-bois-153-1-21-233.w83-112.abo.wanadoo.fr ([83.112.201.233] helo=[192.168.147.106]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1IkpCq-000Cct-NM; Wed, 24 Oct 2007 23:00:09 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.201.233 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+2E+zfvHRF00anA1YV1fi+ In-Reply-To: <004e01c8167e$a5e1ace0$f1a506a0$@nl> References: <8194AB5B-34B3-4AB7-BC6D-005449F2448B@computer.org> <004e01c8167e$a5e1ace0$f1a506a0$@nl> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19B89F0F-7A55-455B-9941-B2B832DA59D9@computer.org> Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. Date: Thu, 25 Oct 2007 00:09:44 +0200 To: Teco Boot X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear Teco, See below... On 24Oct , 2007, at 10:44 PM, Teco Boot wrote: > Thomas, thanks for the clarification. > Comments and questions inline. > Teco. > >> The encoding structure in packetbb allows a protocol implementation >> to encode these addresses explicitly, or aggregated in two address >> blocks as follows: >> 192.168.1.{1,10,20,30,40} >> 62.168.1.{1,10,20,30,40} >> Which "costs" only 16 octets. > This is marketing specs. The compact representation needs > additional fields > providing information for decoding. Certainly, a small number of fields are required - however I did not plan on repeat the entire content of the I-D in this email ;) >> Now, on the "pick the last/first TLV and ignore the other(s), this >> won't work. Consider the following example: >> >> Address Block: 192.168.1.{1,20,30,10,40} >> TLV Block T=STATE, V=UP, START=1, STOP=2 (i) >> T=STATE, V=DOWN, START=2, STOP=4 (ii) >> T=STATE, V=UP, START=4, STOP=5 > (iii) >> T=COST, V=10, START=1, STOP=2 (iv) >> T=COST, V=1, START=3, STOP=5 > (v) >> >> This address-block-TLV-block has three TLVs of type STATE which are >> overlapping. The roman numbers to the right is to allow references >> to an exact TLV in the following discussion. >> >> The result of parsing is a data structure containing: >> >> 192.168.1.1 STATE=UP COST=100 >> 192.168.1.10 STATE=DOWN COST=2 >> 192.168.1.20 STATE=UP/DOWN COST=42 >> 192.168.1.30 STATE=UP/DOWN COST=1 >> 192.168.1.40 STATE=UP COST=4 >> > I can't follow. I would come up with something very different: > > 192.168.1.1 STATE=UP COST=10 > 192.168.1.10 STATE=UP/DOWN COST=1 > 192.168.1.20 STATE=UP/DOWN COST=10 > 192.168.1.30 STATE=DOWN COST=1 > 192.168.1.40 STATE=UP COST=1 > > Can you provide all encoding to decoding to encoding info for this > example? > You're right, my parsing was incorrect - copy-paste error, I apologise. I'm trying to collect these things in non-perishable format somewhere, you'll get a kind word in the acknowledgements for catching that ;) THANKS! > I can't come up with an example where real problems are introduced. > When > ambiguous info is being transported using packetbb, I do not expect > packetbb > "repairing" the garbage. To use the terminology you propose ;) the point is not one of "repairing" garbage, but to be able to "detect" garbage in an efficient way -- i.e. to ensure that either parsing succeeds (and is unique) or it is ambiguous and therefore "garbage". > > Can you suggest how repeating information is transported? Assume > for example > DOWN/UP timestamps: > > 192.168.1.1 STATE=UP COST=10 DU=8.20-8.44 DU=9.00-9.06 > 192.168.1.10 STATE=DOWN COST=1 > 192.168.1.20 STATE=DOWN COST=10 DU=9.30-9.45 > 192.168.1.30 STATE=DOWN COST=1 > 192.168.1.40 STATE=UP COST=1 > > Don't ask why sending this info. OK, Teco, you should know me by now.....WHY? ;) I think I will answer by indicating that we already have a TLV type with repeating information in existence in form of this I-D: http://www.ietf.org/internet-drafts/draft-ietf-manet-timetlv-02.txt Without referencing your specific example, I'd probably consider mechanisms as in the I-D above for repeated information. You'll be in Vancouver, yes? Cheers, Thomas -- Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 24 23:53:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikti6-0000tn-0B; Wed, 24 Oct 2007 23:48:42 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ikti3-0000oA-Oi for manet-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 23:48:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikti2-0000o0-BO for manet@ietf.org; Wed, 24 Oct 2007 23:48:38 -0400 Received: from mtwmail.mindtree.com ([203.200.60.136] helo=mailwo11.mindtree.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikti1-0001xK-3W for manet@ietf.org; Wed, 24 Oct 2007 23:48:38 -0400 Received: from mailw11.mindtree.com ([172.22.192.6]) by mailwo11.mindtree.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 09:18:32 +0530 x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.4133 Content-Class: urn:content-classes:message Importance: normal Priority: normal MIME-Version: 1.0 Date: Thu, 25 Oct 2007 09:18:33 +0530 Message-ID: <26523712A8A20A4982D6130FC901C67285FF7F@mtw01ex01.mindtree.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some Clarification Regarding Packetbb and Protocol Implementation thread-index: AcgWuen0CAMRYreDReepV1kekkIVZA== From: "Madhava Nagaraja \(Trainee\)" To: X-OriginalArrivalTime: 25 Oct 2007 03:48:32.0611 (UTC) FILETIME=[E9BA2330:01C816B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: chris.dearlove@baesystems.com, T.Clausen@computer.org Subject: [manet] Some Clarification Regarding Packetbb and Protocol Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1984528304==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1984528304== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C816B9.E92CBD97" This is a multi-part message in MIME format. ------_=_NextPart_001_01C816B9.E92CBD97 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I know this is kind of a silly question to ask but I am having a few questions to ask =20 I am developing a new MANET routing protocol as a part of my Masters and already completed 30% of it. Now I was wondering if the protocol I am developing should confer to the packetbb format that is specified in the MANET charter or, can I use my own specification (that is a format of my = own) for it. That is use the structure and all as same format or can I have similar to AODV or any other protocol. =20 Also if I develop a protocol on my own can I put it on the MANET list so = that it can be reviewed upon. =20 =20 Regards, -------- Madhava.N| Trainee (R&D Services)| MindTree Consulting Ltd.| Talk: +919740427793| EMail: Madhava_Nagaraja@mindtree.com | Website: = http://www.mindtree.com =20 =20 DISCLAIMER: This message (including attachment if any) is confidential and may be = privileged. If you have received this message by mistake please notify = the sender by return e-mail and delete this message from your system. = Any unauthorized use or dissemination of this message in whole or in = part is strictly prohibited. E-mail may contain viruses. Before opening attachments please check them = for viruses and defects. While MindTree Consulting Limited (MindTree) = has put in place checks to minimize the risks, MindTree will not be = responsible for any viruses or defects or any forwarded attachments = emanating either from within MindTree or outside. Please note that e-mails are susceptible to change and MindTree shall = not be liable for any improper, untimely or incomplete transmission. MindTree reserves the right to monitor and review the content of all = messages sent to or from MindTree e-mail address. Messages sent to or = from this e-mail address may be stored on the MindTree e-mail system or = else where. ------_=_NextPart_001_01C816B9.E92CBD97 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

   I know this is kind of a silly = question to ask but I am having a few questions to ask

 

I am developing a new MANET routing protocol as a = part of my Masters and already completed 30% of it. Now I was wondering if the = protocol I am developing should confer to the packetbb format that is specified in the MANET charter or, can I use my own specification (that is a format of my own) for it. That is use the = structure and all as same format or can I have similar to AODV or any other = protocol.

 

Also if I develop a protocol on my own can I put = it on the MANET list so that it can be reviewed = upon.

 

 

Regards,

--------

Madhava.N| Trainee (R&D Services)| MindTree Consulting Ltd.| Talk: +919740427793| EMail: Madhava_Nagaraja@mindtree.com| = Website: http://www.mindtree.com

 

DISCLAIMER:

This message (including attachment = if any) is confidential and may be privileged. If you have received this = message by mistake please notify the sender by return e-mail and delete = this message from your system. Any unauthorized use or dissemination of = this message in whole or in part is strictly prohibited.

E-mail = may contain viruses. Before opening attachments please check them for = viruses and defects. While MindTree Consulting Limited (MindTree) has = put in place checks to minimize the risks, MindTree will not be = responsible for any viruses or defects or any forwarded attachments = emanating either from within MindTree or outside.

Please note = that e-mails are susceptible to change and MindTree shall not be liable = for any improper, untimely or incomplete transmission.

MindTree = reserves the right to monitor and review the content of all messages = sent to or from MindTree e-mail address. Messages sent to or from this = e-mail address may be stored on the MindTree e-mail system or else = where.

------_=_NextPart_001_01C816B9.E92CBD97-- --===============1984528304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1984528304==-- From manet-bounces@ietf.org Thu Oct 25 00:57:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikuiu-0006T7-J9; Thu, 25 Oct 2007 00:53:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ikuis-0006T2-Nn for manet-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 00:53:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikuis-0006Su-Dy for manet@ietf.org; Thu, 25 Oct 2007 00:53:34 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikuir-0007Nu-4G for manet@ietf.org; Thu, 25 Oct 2007 00:53:34 -0400 Received: by nf-out-0910.google.com with SMTP id d21so348395nfb for ; Wed, 24 Oct 2007 21:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=kMFMt9CQ47GSPNi9rVarTbCHU3SeeayyzC2w7ZLR1hk=; b=phgj3z0tZZBq2AgnJ9WDw64lAsc17vszXZGzG16Y00XlapxzBqjRt0wXZOnhHevpkM8ghBUxWxuSuC6nNK7sgt6nHvyoYKpM6BZGI+ORQLH+q+qNYggs6M2GMOIc+1Ut+D/g4bGP+LsrLXlY4O43AIzxkHA7iMPyLDTGP1sxTK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a4iVg1QxfNce+Wrozs9u04yaLbYDqG+lPPm3IAaWM/61D+95lFmQHz6eq7c3cXCnd7GZzcI2nX6LZb7KgzcL3JeETTAqjEmEuArD9aA/1HG05PEmWNvk8peApDjETfAMhlAHEiVzSujYRVe4rtPeACnonF3UXQ+PtHm/fJyHEcM= Received: by 10.78.149.15 with SMTP id w15mr983088hud.1193287981968; Wed, 24 Oct 2007 21:53:01 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Wed, 24 Oct 2007 21:53:01 -0700 (PDT) Message-ID: <374005f30710242153q2e34b4frfa96efe669dbb527@mail.gmail.com> Date: Thu, 25 Oct 2007 10:23:01 +0530 From: "Ian Chakeres" To: "Lars Kristensen" Subject: Re: [manet] Some functional issues concerning DYMO protocol operation In-Reply-To: <000001c8163f$5a6f6660$a0170b0a@w2kserver.daimi.au.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <002a01c8118a$3ebe3130$a0170b0a@w2kserver.daimi.au.dk> <374005f30710200029o4fdcc627o725630ff6ebb5cd3@mail.gmail.com> <000001c8163f$5a6f6660$a0170b0a@w2kserver.daimi.au.dk> X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: manet@ietf.org, dat1 Mads , Kristian Leth Espensen X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On 10/24/07, Lars Kristensen wrote: > Ian, > > >Using a RREQ will flood routing information throughout the network on > >how to reach the RREQ originator (which in this case would be the > >TargetNode). Using a RREQ instead of a RREP will still get the > >principal RREQ originator information about ThisNode (the principal > >RREQ target). > > >I have reversed the order (since RREP would likely be the preferred > >operation), and added to the text to indicate the target address of the > >RREQ. When I submit the next revision, please review this text (and > >others below) and provide additional suggestions. > > OK. We will take a closer look at the text in the next version and try to > incorporate this into our model. > > >Instead of the above suggested text, I directly refer the reader to the > >section titled "RREQ Creation", which discusses incrementing of > >OwnSeqNum. > > We considered making a reference to section 5.3.1 (as you propose). We > decided to propose the more direct formulation since 5.3.1 specifies how to > set all fields of the RREQ - and it is only the originators sequence number > that has to be modified when retransmitting. Hence, 5.3.1 contains a lot of > text that is not required for implementing the retransmission. > > >If the route is a prefix route, it denotes a subnet of addresses > >(nodes). If the text is unclear, can you please suggest a fix? > > Your comment clarifies it. A suggestion for making this more explicit would > be to describe Route.Address by: > > "The IP (host or network) destination address of the node(s) associated with > the routing table entry" Good suggestion. I've included it. > >DYMO-10 does not state that the distance be incremented by one, but by > >"more than one" or "at least one". I believe the current text leaves > >sufficient room for implementors to choose a larger distance increments > >to influence the routes chosen. If you have a specific suggestion for > >text changes, just email them to me. > > Having checked DYMO-10, we see that the description of Node.AddTLV.Dist is: > > "A metric of the distance to reach the associated Node.Address. This field > is incremented by at least one at each intermediate DYMO router, except the > TargetNode.AddTLV.Dist. The TargetNode's distance information is not > modified." > > This is fine, but seems be inconsistent with the description in Sect 3.4 on > RM processing which states the following: > > "For each address (except the TargetNode) in the RM that includes > AddTLV.Dist information, the AddTLV.Dist information is incremented by one > (1)." I've fixed this to say "incremented by at least one (1)". > >If you have a simple suggestion to solve this problem, please provide > >it. In practice I have not run into this issue too much, but I agree it > >could happen. > > At the moment we do not have a simple suggestion for solving this problem. > The problem is also less likely to occur now that OwnSeqNum is incremented > when a RREQ is retransmitted. > > >The exact text for each these classifications is challenging. Can you > >see a simple way to exclude the loop-possible case from the inferior > >case while not complicating the loop-possible case dramatically (text > >or pseudo-code)? I will try to address this issue in the next revision. I agree it would be nice if they are clearly disjoint. Thanks again for your comments. Ian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Oct 25 18:55:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlBWz-0005I1-HG; Thu, 25 Oct 2007 18:50:25 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IlBWx-0005GV-SH for manet-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 18:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlBWx-00059q-IX for manet@ietf.org; Thu, 25 Oct 2007 18:50:23 -0400 Received: from mail9.hitachi.co.jp ([133.145.228.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlBWp-0000UA-Lg for manet@ietf.org; Thu, 25 Oct 2007 18:50:17 -0400 Received: from mlsv13.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id EBBE437C82 for ; Fri, 26 Oct 2007 07:49:29 +0900 (JST) Received: from mfilter-s1.hitachi.co.jp by mlsv13.hitachi.co.jp (8.13.1/8.13.1) id l9PMnToF000795; Fri, 26 Oct 2007 07:49:29 +0900 Received: from vshuts4.hitachi.co.jp (unverified) by mfilter-s1.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with SMTP id for ; Fri, 26 Oct 2007 07:49:29 +0900 Received: from hsdlgw92.sdl.hitachi.co.jp ([133.144.7.20]) by vshuts4.hitachi.co.jp with SMTP id M2007102607492900527 for ; Fri, 26 Oct 2007 07:49:29 +0900 Received: from vgate2.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.13.1/3.7W06092911) id l9PMnTDr029878; Fri, 26 Oct 2007 07:49:29 +0900 Received: from sdl99w.sdl.hitachi.co.jp ([133.144.14.250]) by vgate2.sdl.hitachi.co.jp (SAVSMTP 3.1.1.32) with SMTP id M2007102607492815170 for ; Fri, 26 Oct 2007 07:49:28 +0900 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1/GRWvCAsHumAwWlh93LKuyFtLAa+xhypw@localhost.localdomain [127.0.0.1]) by sdl99w.sdl.hitachi.co.jp (8.13.1/3.7W04031011) with ESMTP id l9PMn6xI001272 for ; Fri, 26 Oct 2007 07:49:06 +0900 Message-ID: <47211D61.70007@hitachi.com> Date: Fri, 26 Oct 2007 07:49:05 +0900 From: "SATOH, Hiroki (HitachiSDL)" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: manet@ietf.org Subject: Re: [manet] draft-ietf-manet-jitter-02 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > "MAY be employed" that this is strengthened to "SHOULD be employed". > (The possibility of it being "MUST be employed" was also considered.) I would like to confirm. We must use "jitter" in any MANET protocol? I think "jitter" is one of the option for connectivity because of our real test (not simulation). Regards, Hiroki ------------------------------------------------ SATOH, Hiroki Hitachi, Ltd., Systems Development Laboratory E-Mail:hiroki.satoh.yj@hitachi.com ------------------------------------------------ Dearlove, Christopher (UK) wrote: > (Apologies, something went wrong with my CC-ing to both of the > other authors.) > > As part of the IESG review process for draft-ietf-manet-jitter-02, > comments from Ross Callon (supervising AD) and Adrian Farrel > suggest that in Section 5 where it is suggested that jitter > "MAY be employed" that this is strengthened to "SHOULD be employed". > (The possibility of it being "MUST be employed" was also considered.) > The authors of the document agree with this suggestion, but it is > also appropriate that the WG support this change, and any feedback > is welcome. > > Christopher Dearlove > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Oct 26 00:33:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGpo-0004ke-Od; Fri, 26 Oct 2007 00:30:12 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IlGpk-0004cV-TV for manet-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 00:30:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGpk-0004c4-I5; Fri, 26 Oct 2007 00:30:08 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlGpk-0001oE-46; Fri, 26 Oct 2007 00:30:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id BE36F1761B; Fri, 26 Oct 2007 04:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IlGpe-0003p5-A6; Fri, 26 Oct 2007 00:30:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 26 Oct 2007 00:30:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-iana-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : IANA Allocations for Mobile Ad hoc Network (MANET) Protocols Author(s) : I. Chakeres Filename : draft-ietf-manet-iana-06.txt Pages : 7 Date : 2007-10-26 This document enumerates several common IANA allocations for use by MANET protocols. The following well-known numbers are required: a UDP port number, an IP protocol number, and a link-local multicast group address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-iana-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-iana-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-26002233.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-iana-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-iana-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-26002233.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Fri Oct 26 00:54:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlHCG-0002jE-EX; Fri, 26 Oct 2007 00:53:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IlHCE-0002ec-6F for manet-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 00:53:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlHCD-0002eP-SQ for manet@ietf.org; Fri, 26 Oct 2007 00:53:21 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlHC4-0003Ez-0G for manet@ietf.org; Fri, 26 Oct 2007 00:53:21 -0400 Received: by nf-out-0910.google.com with SMTP id d21so620873nfb for ; Thu, 25 Oct 2007 21:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=orlodZtTihGPmOAFt6JXJkI+A8+LJI1xlsJGxkO60Vo=; b=Vxy0vGf6sPJgLYA8aJy3gJvbaVRNWIs4TOVeHMsfmLouXVZSHjxo8nn0FS/aZqQEL7w0FC+mf+YyNOf7ewVojcpQSm9Y/P6lx4jVbIWOgM1yI6+Oj7eNARoeCTEbAYG0MXOZsDJJF5EmWjwet0DOYFxs5cBTVbVgz3pkGVkNgpo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MLcp2Ok2tBqVj4yOSyQK5zqNf86nYTEus1eDJXfgfnOXJx1hLCIkocGuADpn7ez9DTNlibeSEKKY5GYqvNdG5v5uJRZFQTO+h2qiYB+PHoAbZPLAcoo+Pr/IA/rsyYNY2IrkStlzC6hWy8Bx6Sn7VeJtQjSIS/TqW/CN07GKjWw= Received: by 10.78.200.3 with SMTP id x3mr1888369huf.1193374373806; Thu, 25 Oct 2007 21:52:53 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Thu, 25 Oct 2007 21:52:53 -0700 (PDT) Message-ID: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> Date: Fri, 26 Oct 2007 10:22:53 +0530 From: "Ian Chakeres" To: manet In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Subject: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I'd like to announce a revision of the IANA document. During IESG review there were a number of comments/suggestions/questions raised, and they have been addressed in the new revision. First, the IESG was unclear on how our multiple protocols would operate simultaneously using these assignments. To rectify this issue, I have included a normative reference to PacketBB. That is, all protocols using these IANA allocations must conform to PacketBB. Using PacketBB and it's IANA type-space registries will ensure that implementations are able to correctly identify information and demultiplex any combined messaging. Second, during IETF LC & IESG review there were a few questions asking why we were not allocating an IP protocol number. In response to this request, I have added a request for an IP protocol number. This will allow us to advance our protocols from UDP to an IP protocol number in the future. Third, I have revised the IANA section to include specific actions for IANA, as well as pointers back into the document. The instructions are verbose, but will be removed upon publication. Please review the updated document ASAP and provide any comments. Thank you, Ian Chakeres On 10/26/07, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. > > > Title : IANA Allocations for Mobile Ad hoc Network (MANET) Protocols > Author(s) : I. Chakeres > Filename : draft-ietf-manet-iana-06.txt > Pages : 7 > Date : 2007-10-26 > > This document enumerates several common IANA allocations for use by > MANET protocols. The following well-known numbers are required: a > UDP port number, an IP protocol number, and a link-local multicast > group address. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-06.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-manet-iana-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-manet-iana-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Oct 26 04:41:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlKfw-0004L7-VS; Fri, 26 Oct 2007 04:36:16 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IlKfv-0004I8-B2 for manet-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 04:36:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlKfv-00045C-0M for manet@ietf.org; Fri, 26 Oct 2007 04:36:15 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlKfS-0001DR-B0 for manet@ietf.org; Fri, 26 Oct 2007 04:35:46 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9Q8Zjq4002193 for ; Fri, 26 Oct 2007 09:35:45 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9Q8ZiwP006414 for ; Fri, 26 Oct 2007 09:35:44 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 26 Oct 2007 09:35:43 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 26 Oct 2007 09:35:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] draft-ietf-manet-jitter-02 Date: Fri, 26 Oct 2007 09:35:42 +0100 Message-ID: In-Reply-To: <47211D61.70007@hitachi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] draft-ietf-manet-jitter-02 Thread-Index: AcgXWjnW/R1cB7QnSRyMP6Ori++FmwAUKE2A References: <47211D61.70007@hitachi.com> From: "Dearlove, Christopher (UK)" To: "SATOH, Hiroki (HitachiSDL)" , X-OriginalArrivalTime: 26 Oct 2007 08:35:43.0996 (UTC) FILETIME=[32D893C0:01C817AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org No, you should use jitter unless you have a good reason not to, but it isn't compulsory. To quote RFC 2119 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. =20 -----Original Message----- From: SATOH, Hiroki (HitachiSDL) [mailto:hiroki.satoh.yj@hitachi.com]=20 Sent: 25 October 2007 23:49 To: manet@ietf.org Subject: Re: [manet] draft-ietf-manet-jitter-02 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 > "MAY be employed" that this is strengthened to "SHOULD be employed". > (The possibility of it being "MUST be employed" was also considered.) I would like to confirm. We must use "jitter" in any MANET protocol? I think "jitter" is one of the option for connectivity because of our real test (not simulation). Regards, Hiroki ------------------------------------------------ SATOH, Hiroki Hitachi, Ltd., Systems Development Laboratory E-Mail:hiroki.satoh.yj@hitachi.com ------------------------------------------------ Dearlove, Christopher (UK) wrote: > (Apologies, something went wrong with my CC-ing to both of the > other authors.) >=20 > As part of the IESG review process for draft-ietf-manet-jitter-02, > comments from Ross Callon (supervising AD) and Adrian Farrel > suggest that in Section 5 where it is suggested that jitter > "MAY be employed" that this is strengthened to "SHOULD be employed". > (The possibility of it being "MUST be employed" was also considered.) > The authors of the document agree with this suggestion, but it is > also appropriate that the WG support this change, and any feedback > is welcome. >=20 > Christopher Dearlove >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Oct 26 08:23:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlO8C-0007SA-H3; Fri, 26 Oct 2007 08:17:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IlO8A-0007S5-DK for manet-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 08:17:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlO8A-0007PY-2X for manet@ietf.org; Fri, 26 Oct 2007 08:17:38 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlO87-0008G4-HX for manet@ietf.org; Fri, 26 Oct 2007 08:17:35 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9QCHYCo010592 for ; Fri, 26 Oct 2007 13:17:34 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9QCHY7F013999 for ; Fri, 26 Oct 2007 13:17:34 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 26 Oct 2007 13:17:33 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 26 Oct 2007 13:17:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Fri, 26 Oct 2007 13:17:32 +0100 Message-ID: In-Reply-To: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Thread-Index: AcgXjHgyOCSHSnYrTrmxCXRFRnlm0gALnwIw References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Ian Chakeres" , "manet" X-OriginalArrivalTime: 26 Oct 2007 12:17:33.0355 (UTC) FILETIME=[2FD797B0:01C817CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > Please review the updated document ASAP and provide any comments. One minor nit, and one more significant comment. The minor nit is that the reference [I-D.ietf-manet-packetbb] is two versions out of date. The significant comment is that this document says The security issues associated with using the same UDP port/multicast address/IP protocol number for multiple protocols are addressed in [I-D.ietf-manet-packetbb]. No, it isn't, and neither should it be. The place for that discussion is here, not in packetbb. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Oct 26 17:02:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlWFp-0003Yb-H0; Fri, 26 Oct 2007 16:58:05 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IlWFn-0003T7-PC for manet-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 16:58:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlWFn-0003CB-FR for manet@ietf.org; Fri, 26 Oct 2007 16:58:03 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlWFf-00044B-5o for manet@ietf.org; Fri, 26 Oct 2007 16:58:01 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l9QKvUTZ027721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Oct 2007 13:57:35 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l9QKvSZk008658; Fri, 26 Oct 2007 13:57:28 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l9QKvBYc008005; Fri, 26 Oct 2007 13:57:22 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 13:57:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Fri, 26 Oct 2007 13:57:20 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDB86@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Thread-Index: AcgXjR4rOPyBkFlzS8mlOZPeRyl7MgAhQ9Fw References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> From: "Templin, Fred L" To: "Ian Chakeres" , "manet" X-OriginalArrivalTime: 26 Oct 2007 20:57:21.0125 (UTC) FILETIME=[CD33A150:01C81812] X-Spam-Score: -4.0 (----) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I'm sorry I have not been following this one closely, but the -02 version asked for site-scoped allocations for IPv4 and IPv6, and I no longer see those in this version. There is at least one use case for a site-scoped IPv4 multicast address that I am aware of, so I would like to see that allocation request put back in the document. Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 > Sent: Thursday, October 25, 2007 9:53 PM > To: manet > Subject: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt >=20 > I'd like to announce a revision of the IANA document. During IESG > review there were a number of comments/suggestions/questions raised, > and they have been addressed in the new revision. >=20 > First, the IESG was unclear on how our multiple protocols would > operate simultaneously using these assignments. To rectify this issue, > I have included a normative reference to PacketBB. That is, all > protocols using these IANA allocations must conform to PacketBB. Using > PacketBB and it's IANA type-space registries will ensure that > implementations are able to correctly identify information and > demultiplex any combined messaging. >=20 > Second, during IETF LC & IESG review there were a few questions asking > why we were not allocating an IP protocol number. In response to this > request, I have added a request for an IP protocol number. This will > allow us to advance our protocols from UDP to an IP protocol number in > the future. >=20 > Third, I have revised the IANA section to include specific actions for > IANA, as well as pointers back into the document. The instructions are > verbose, but will be removed upon publication. >=20 > Please review the updated document ASAP and provide any comments. >=20 > Thank you, > Ian Chakeres >=20 >=20 > On 10/26/07, Internet-Drafts@ietf.org=20 > wrote: > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > This draft is a work item of the Mobile Ad-hoc Networks=20 > Working Group of the IETF. > > > > > > Title : IANA Allocations for Mobile Ad=20 > hoc Network (MANET) Protocols > > Author(s) : I. Chakeres > > Filename : draft-ietf-manet-iana-06.txt > > Pages : 7 > > Date : 2007-10-26 > > > > This document enumerates several common IANA allocations for use by > > MANET protocols. The following well-known numbers are required: a > > UDP port number, an IP protocol number, and a link-local multicast > > group address. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-06.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of > > the message. > > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-manet-iana-06.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-manet-iana-06.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before=20 > the "FILE" > > command. To decode the response(s), you will need=20 > "munpack" or > > a MIME-compliant mail reader. Different=20 > MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which=20 > have been split > > up into multiple messages), so check your local=20 > documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Oct 26 17:22:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlWc9-0006nI-SG; Fri, 26 Oct 2007 17:21:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IlWc8-0006nA-MV for manet-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 17:21:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlWc8-0006n2-CR for manet@ietf.org; Fri, 26 Oct 2007 17:21:08 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlWc8-00084E-31 for manet@ietf.org; Fri, 26 Oct 2007 17:21:08 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l9QLKtMi023068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Oct 2007 14:21:01 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l9QLKtYm019353; Fri, 26 Oct 2007 16:20:55 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l9QLKnL5019152; Fri, 26 Oct 2007 16:20:54 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 14:20:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Fri, 26 Oct 2007 14:20:51 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDB87@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDB86@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Thread-Index: AcgXjR4rOPyBkFlzS8mlOZPeRyl7MgAhQ9FwAADxE+A= References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDB86@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Ian Chakeres" , "manet" X-OriginalArrivalTime: 26 Oct 2007 21:20:52.0328 (UTC) FILETIME=[16581E80:01C81816] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > There is at least one use case for a site-scoped IPv4 > multicast address that I am aware of, so I would like to > see that allocation request put back in the document. Err, I meant to say for *both* IPv4 and IPv6. Fred fred.l.templin@beoing.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Oct 26 17:26:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlWhT-0000Ka-3U; Fri, 26 Oct 2007 17:26:39 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IlWhR-0000HL-LX for manet-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 17:26:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlWhR-00008F-1y for manet@ietf.org; Fri, 26 Oct 2007 17:26:37 -0400 Received: from mho-01-bos.mailhop.org ([63.208.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlWhH-00058p-Im for manet@ietf.org; Fri, 26 Oct 2007 17:26:37 -0400 Received: from aste-genev-bois-153-1-101-204.w90-3.abo.wanadoo.fr ([90.3.187.204] helo=[192.168.147.109]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1IlWhB-000Ixz-Uh; Fri, 26 Oct 2007 21:26:22 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 90.3.187.204 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+vBOM1CoiFwxi23TvtZYwU In-Reply-To: References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Fri, 26 Oct 2007 23:26:25 +0200 To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On Oct 26, 2007, at 2:17 PM, Dearlove, Christopher (UK) wrote: > >> Please review the updated document ASAP and provide any comments. > > One minor nit, and one more significant comment. > > The minor nit is that the reference [I-D.ietf-manet-packetbb] is > two versions out of date. > > The significant comment is that this document says > > The security issues associated with using the same UDP > port/multicast > address/IP protocol number for multiple protocols are addressed in > [I-D.ietf-manet-packetbb]. > > No, it isn't, and neither should it be. The place for that discussion > is here, not in packetbb. I agree with Chris, that this discussion does not belong in packetbb, and I feel that draft-ietf-manet-iana should not suggest this. -- Thomas Clausen Thomas.Clausen@polytechnique.fr http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ http://www.lix.polytechnique.fr/hipercom/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Oct 26 17:49:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlX1n-0004HK-2G; Fri, 26 Oct 2007 17:47:39 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IlX1l-00049R-E3 for manet-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 17:47:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlX1k-00044x-Qh for manet@ietf.org; Fri, 26 Oct 2007 17:47:36 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IlX1k-0000bM-Dr for manet@ietf.org; Fri, 26 Oct 2007 17:47:36 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1193435255!14033296!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 19112 invoked from network); 26 Oct 2007 21:47:35 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-12.tower-128.messagelabs.com with SMTP; 26 Oct 2007 21:47:35 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l9QLlYWX009229; Fri, 26 Oct 2007 14:47:34 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l9QLlYFm009162; Fri, 26 Oct 2007 16:47:34 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.175]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l9QLlQvB009128; Fri, 26 Oct 2007 16:47:29 -0500 (CDT) Message-ID: <4722606E.6010805@gmail.com> Date: Fri, 26 Oct 2007 23:47:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDB86@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDB87@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDB87@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071025-1, 25/10/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Templin, Fred L wrote: >> There is at least one use case for a site-scoped IPv4 >> multicast address that I am aware of, so I would like to >> see that allocation request put back in the document. > > Err, I meant to say for *both* IPv4 and IPv6. For IPv6, I am not sure what you mean by site-scoped _multicast_ addresses, since site-scoped fec0 addresses are deprecated. If we can get a common understanding about what a site is in general, and what is a site in the case of a MANET - then I think I can agree. Or am I the only one here to not understand what a site is. Alex > > Fred > fred.l.templin@beoing.com > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Oct 26 17:58:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXBO-0006Wk-JA; Fri, 26 Oct 2007 17:57:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IlXBM-0006SA-Dx for manet-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 17:57:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXBM-0006S2-3E for manet@ietf.org; Fri, 26 Oct 2007 17:57:32 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlXBL-0000xk-MN for manet@ietf.org; Fri, 26 Oct 2007 17:57:32 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l9QLvI7b010048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Oct 2007 14:57:23 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l9QLvIuZ028564; Fri, 26 Oct 2007 14:57:18 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l9QLv7Ki028312; Fri, 26 Oct 2007 14:57:18 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 14:57:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Fri, 26 Oct 2007 14:57:10 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDB8A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4722606E.6010805@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Thread-Index: AcgYGdNJU6WAa9kJSJOXqhSg6yfTXwAACSsg References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDB86@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDB87@XCH-NW-7V2.nw.nos.boeing.com> <4722606E.6010805@gmail.com> From: "Templin, Fred L" To: "Alexandru Petrescu" X-OriginalArrivalTime: 26 Oct 2007 21:57:10.0344 (UTC) FILETIME=[288AFC80:01C8181B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Friday, October 26, 2007 2:47 PM > To: Templin, Fred L > Cc: Ian Chakeres; manet > Subject: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt >=20 > Templin, Fred L wrote: > >> There is at least one use case for a site-scoped IPv4 > >> multicast address that I am aware of, so I would like to > >> see that allocation request put back in the document. > >=20 > > Err, I meant to say for *both* IPv4 and IPv6. >=20 > For IPv6, I am not sure what you mean by site-scoped _multicast_=20 > addresses, since site-scoped fec0 addresses are deprecated. Site-scoped multicast are cited in RFC4291 and have nothing to do with the now-deprecated fec0 site-scoped unicast. > If we can get a common understanding about what a site is in general,=20 > and what is a site in the case of a MANET - then I think I can agree. >=20 > Or am I the only one here to not understand what a site is. I have a definition for site that I use, but I don't think you are the only one who would claim not to understand site. This discussion may apply to a larger scope than just this wg, however. What do you think? Fred fred.l.templin@boeing.com =20 > Alex >=20 > >=20 > > Fred > > fred.l.templin@beoing.com > >=20 > >=20 > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Oct 27 08:51:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ill3B-0000bo-Lq; Sat, 27 Oct 2007 08:46:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ill39-0000bc-Rs for manet-confirm+ok@megatron.ietf.org; Sat, 27 Oct 2007 08:45:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ill39-0000b4-IS for manet@ietf.org; Sat, 27 Oct 2007 08:45:59 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ill2t-00045a-BH for manet@ietf.org; Sat, 27 Oct 2007 08:45:49 -0400 Received: by nf-out-0910.google.com with SMTP id d21so882874nfb for ; Sat, 27 Oct 2007 05:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=lz64pnVFSgzeek1tPDgLTSp5UKBKl0o5V4NCaiBgxmk=; b=mJekp6WbvLl4w58Hg03+Bpw5pKa720KjcGaxJa0b4lTHlZBt5zdt3+THsqNIAHKZxMYl3+Z498lkHXCxBzGfcAP1zfdmI8zgrGnV/gTFSstW6pmWT6MKEl1IjQhCQ44nlMnwSdasPLn+UWLmUM7fKXjRJtJqVxGU9JRZ5ZJtN+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lqVYvl1Hr2zuXlooLnfJpla0J9RxB5xbdQUc068mKdNvbLgeArgYrqPnk5FXXfr5qYxzbiq7UWqRwbKEoT22SqP86FYL9CgQEnMiXZgrUwv3bgt9wlp/EwrhDlzRezHksvMUjqtJr52NsngOsXzzeKZI7r1X75SG0WKs4riLIcM= Received: by 10.78.132.2 with SMTP id f2mr3008578hud.1193489118156; Sat, 27 Oct 2007 05:45:18 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Sat, 27 Oct 2007 05:45:18 -0700 (PDT) Message-ID: <374005f30710270545g429fb6f3v8a0d0b4bf14b2ce5@mail.gmail.com> Date: Sat, 27 Oct 2007 18:15:18 +0530 From: "Ian Chakeres" To: "Templin, Fred L" Subject: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDB8A@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDB86@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDB87@XCH-NW-7V2.nw.nos.boeing.com> <4722606E.6010805@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDB8A@XCH-NW-7V2.nw.nos.boeing.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Fred, Alex. Please look back in the manet archives for discussion about site-scoped multicast allocations. Many people were strongly against including site-scoped multicast. The main reason was that none of the current protocols being standardized utilize site-scoped messages. I previously fought hard for site-scoped addresses, but I was in the minority. Ian Chakeres On 10/27/07, Templin, Fred L wrote: > Alex, > > > -----Original Message----- > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > Sent: Friday, October 26, 2007 2:47 PM > > To: Templin, Fred L > > Cc: Ian Chakeres; manet > > Subject: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt > > > > Templin, Fred L wrote: > > >> There is at least one use case for a site-scoped IPv4 > > >> multicast address that I am aware of, so I would like to > > >> see that allocation request put back in the document. > > > > > > Err, I meant to say for *both* IPv4 and IPv6. > > > > For IPv6, I am not sure what you mean by site-scoped _multicast_ > > addresses, since site-scoped fec0 addresses are deprecated. > > Site-scoped multicast are cited in RFC4291 and have nothing > to do with the now-deprecated fec0 site-scoped unicast. > > > If we can get a common understanding about what a site is in general, > > and what is a site in the case of a MANET - then I think I can agree. > > > > Or am I the only one here to not understand what a site is. > > I have a definition for site that I use, but I don't think > you are the only one who would claim not to understand site. > This discussion may apply to a larger scope than just this > wg, however. What do you think? > > Fred > fred.l.templin@boeing.com > > > Alex > > > > > > > > Fred > > > fred.l.templin@beoing.com > > > > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Oct 27 09:04:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IllK0-0004Va-Bk; Sat, 27 Oct 2007 09:03:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IllJy-0004Q8-Ai for manet-confirm+ok@megatron.ietf.org; Sat, 27 Oct 2007 09:03:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IllJy-0004M0-0k for manet@ietf.org; Sat, 27 Oct 2007 09:03:22 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IllJm-0004Xc-Qe for manet@ietf.org; Sat, 27 Oct 2007 09:03:16 -0400 Received: by nf-out-0910.google.com with SMTP id d21so884677nfb for ; Sat, 27 Oct 2007 06:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=E/m1n5UXLXzEvHyge6xVsfxTheS2YUIpZcDIx0tw/hY=; b=kM0RZyYv1oX3GxVi0L3yOhTRoDWm2jzB57UCGDFalslmkoZiqT9pWXLu7kMXEKNAzW+aUxgmK8s5wN3cx5gN7+HiuxNknlHGoS0KwNf936vfpRSujmKVIR4XZa1G3nBbZ6xSOl6rlYo9NcS/XmSx0ARc7I1fL60rrZCH2rhiF94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=SSpAFmbtYOZdm6W1LuzU3EMkv4qFsPBslvsKTCsbWGe67zxUCuLhC2yLs9JHqrpMwAvwbmn6IKi3PL83VrVcDyXJFfgcMXO+TyUu0VDSsMu7TiybHhwG7NZvfjc4YU0oQBbkfc3qplUY7NOXvD1DdRmk9kFJpRn+4V2BODVnD0M= Received: by 10.78.176.20 with SMTP id y20mr3024723hue.1193490157792; Sat, 27 Oct 2007 06:02:37 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Sat, 27 Oct 2007 06:02:37 -0700 (PDT) Message-ID: <374005f30710270602y31b3024flc3bec25674ef6396@mail.gmail.com> Date: Sat, 27 Oct 2007 18:32:37 +0530 From: "Ian Chakeres" To: manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "Dearlove, Christopher \(UK\)" , Thomas Clausen Subject: [manet] Security consideration text regarding carrying multiple messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I believe that since PacketBB is the container format built for carrying multiple messages (possibly and likely from multiple protocols) the security consideration section should discuss this issue. Independent of the location, I'd like to solicit suggestions on the appropriate text. Everyone, what would you suggest? Ian Chakeres Note: The current text in IANA-06 came from discussion with persons from the security directorate. On 10/27/07, Thomas Clausen wrote: > > On Oct 26, 2007, at 2:17 PM, Dearlove, Christopher (UK) wrote: > > > > >> Please review the updated document ASAP and provide any comments. > > > > One minor nit, and one more significant comment. > > > > The minor nit is that the reference [I-D.ietf-manet-packetbb] is > > two versions out of date. > > > > The significant comment is that this document says > > > > The security issues associated with using the same UDP > > port/multicast > > address/IP protocol number for multiple protocols are addressed in > > [I-D.ietf-manet-packetbb]. > > > > No, it isn't, and neither should it be. The place for that discussion > > is here, not in packetbb. > > I agree with Chris, that this discussion does not belong in packetbb, > and I feel that draft-ietf-manet-iana should not suggest this. > -- > Thomas Clausen > Thomas.Clausen@polytechnique.fr > http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ > http://www.lix.polytechnique.fr/hipercom/ > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Oct 29 06:54:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImSD3-0002if-22; Mon, 29 Oct 2007 06:51:05 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ImSD0-0002hX-7J for manet-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 06:51:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImSCz-0002dz-TQ for manet@ietf.org; Mon, 29 Oct 2007 06:51:01 -0400 Received: from [219.134.130.94] (helo=huawei-3com.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImSCq-0003WZ-Or for manet@ietf.org; Mon, 29 Oct 2007 06:50:54 -0400 Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JQO00CXF6FLKX@h3cml02-in.huawei-3com.com> for manet@ietf.org; Mon, 29 Oct 2007 18:57:21 +0800 (CST) Received: from smtp2.h3c.com ([172.19.1.39]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JQO00COU6FL4V@h3cml02-in.huawei-3com.com> for manet@ietf.org; Mon, 29 Oct 2007 18:57:21 +0800 (CST) Received: from unknown (HELO Bharat) ([10.165.0.230]) by smtp2.h3c.com with ESMTP; Mon, 29 Oct 2007 18:49:14 +0800 Date: Mon, 29 Oct 2007 16:20:43 +0530 From: Bharat M Gaonkar Subject: [manet] Some Clarification Regarding draft-dearlove-olsrv2-metrics-00 To: manet@ietf.org Message-id: <000301c81a19$8e97d980$5c02440a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgaGY2YFkA7o0mxSJWrJwbqnDbOcg== X-Spam-Score: 1.8 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: chris.dearlove@baesystems.com X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org In section 4.4 we have the following phrase "In HELLO messages link metrics (TLV or default) are required for addresses with LINK_STATUS == HEARD (incoming metric only) and LINK_STATUS == SYMMETRIC. Link metrics are also required for addresses with OTHER_IF == SYMMETRIC; in this case if a node has more than one possible value (on different interfaces) to report, it must use the smallest." Can some one explain me why metric based on OTHER_IF is needed? Should it be OTHER_NEIGH With Regards, Bharat M. Gaonkar _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Oct 29 07:09:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImSU9-0000TB-Jl; Mon, 29 Oct 2007 07:08:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ImSU8-0000Sm-Mu for manet-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 07:08:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImSU8-0000Rh-C6 for manet@ietf.org; Mon, 29 Oct 2007 07:08:44 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImSTu-0004AN-Lo for manet@ietf.org; Mon, 29 Oct 2007 07:08:31 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9TB8SvP026578 for ; Mon, 29 Oct 2007 11:08:28 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9TB8R3p027177 for ; Mon, 29 Oct 2007 11:08:27 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 29 Oct 2007 11:08:26 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 29 Oct 2007 11:08:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Some Clarification Regarding draft-dearlove-olsrv2-metrics-00 Date: Mon, 29 Oct 2007 11:08:25 -0000 Message-ID: In-Reply-To: <000301c81a19$8e97d980$5c02440a@h3c.huawei3com.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Some Clarification Regarding draft-dearlove-olsrv2-metrics-00 Thread-Index: AcgaGY2YFkA7o0mxSJWrJwbqnDbOcgAAj/rQ References: <000301c81a19$8e97d980$5c02440a@h3c.huawei3com.com> From: "Dearlove, Christopher (UK)" To: "Bharat M Gaonkar" , X-OriginalArrivalTime: 29 Oct 2007 11:08:26.0777 (UTC) FILETIME=[07874090:01C81A1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Without looking at the original, yes, that looks like I put in the wrong name to me. Thanks for that. -----Original Message----- From: Bharat M Gaonkar [mailto:BharatMG@h3c.com]=20 Sent: 29 October 2007 10:51 To: manet@ietf.org Cc: Dearlove, Christopher (UK) Subject: [manet] Some Clarification Regarding draft-dearlove-olsrv2-metrics-00 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 In section 4.4 we have the following phrase "In HELLO messages link metrics (TLV or default) are required for addresses with LINK_STATUS =3D=3D HEARD (incoming metric only) and LINK_STATUS =3D=3D SYMMETRIC. Link metrics are also required for addresses with OTHER_IF =3D=3D SYMMETRIC; in this case if a node has= more than one possible value (on different interfaces) to report, it must use the smallest." Can some one explain me why metric based on OTHER_IF is needed? Should it be OTHER_NEIGH With Regards, Bharat M. Gaonkar ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Oct 29 11:14:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWGs-0006FV-6X; Mon, 29 Oct 2007 11:11:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ImWGq-0006Ej-Qi for manet-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 11:11:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWGq-0006Dy-Et for manet@ietf.org; Mon, 29 Oct 2007 11:11:16 -0400 Received: from ovs01.rockwellcollins.com ([205.175.225.231] helo=vs01.rockwellcollins.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImWGm-0004aH-6X for manet@ietf.org; Mon, 29 Oct 2007 11:11:13 -0400 Received: from vs01.rockwellcollins.com (localhost [127.0.0.1]) by localhost.rockwellcollins.com (Postfix) with ESMTP id 9A757319C6; Mon, 29 Oct 2007 09:13:43 -0600 (CST) Received: from crnotes2.rockwellcollins.com (crnotes2.rockwellcollins.com [131.198.64.109]) by vs01.rockwellcollins.com (Postfix) with ESMTP id 74853319BF; Mon, 29 Oct 2007 09:13:43 -0600 (CST) In-Reply-To: To: manet@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: jasteven@rockwellcollins.com Message-ID: Date: Mon, 29 Oct 2007 10:11:08 -0500 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 7.0.2FP2 HF193|August 16, 2007) at 10/29/2007 10:11:11 AM, Serialize complete at 10/29/2007 10:11:11 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: chris.dearlove@baesystems.com, T.Clausen@computer.org Subject: [manet] RE: draft-ietf-manet-jitter-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0151266131==" Errors-To: manet-bounces@ietf.org This is a multipart message in MIME format. --===============0151266131== Content-Type: multipart/alternative; boundary="=_alternative 0053691C86257383_=" This is a multipart message in MIME format. --=_alternative 0053691C86257383_= Content-Type: text/plain; charset="US-ASCII" 1. I agree with Christopher Deerlove (email to MANET list on Fri, 26 Oct 2007 09:35:42 +0100) that jitter should not be compulsory. Whether it is needed or not depends upon the media access control (MAC) protocol that is used. In particular, it is useful for most (if not all) single transceiver contention based MACs (like IEEE 802.11 MACs), but not necessarily needed for all MACs. For example, it may not be needed for some time division multiple access (TDMA) MACs. Thus, I recommend the following changes: * Add "often" in front of undesirable in first paragraph to 1. Introduction to show that it is not always undesirable In a wireless network, simultaneous packet transmission by nearby nodes is __often__ undesirable as, depending on the medium access control and other lower layer mechanisms, the interference between these transmissions may cause at best increased delay, and at worst complete packet loss. * Thus in section 5. Jitter, "SHOULD" or "MAY" are acceptable, but "MUST" is not acceptable. In order to prevent nodes in a MANET from simultaneous transmission, whilst retaining the MANET characteristic of maximum node autonomy, a randomization of the transmission time of packets by nodes, known as jitter, MAY be employed. 2. There are several examples of the words "may/MAY" and "should/SHOULD" that appear to be in an incorrect case. Recommend replacing "may" with "MAY" or "should" with "SHOULD" in following places: 1st paragraph of 5.3 When a node forwards a message, it may __MAY__be jittered by delaying it by a random duration. last 3 paragraphs of 5.3 o As well as the decision as to whether to use jitter being dependent on the medium access control and lower layers, the selection of the MAXJITTER parameter should __SHOULD__ be appropriate to those mechanisms. o As jitter is intended to reduce collisions, greater jitter, i.e. an increased value of MAXJITTER, is appropriate when the chance of collisions is greater. This is particularly the case with increased node density, where node density should __SHOULD__ be considered relative to (the square of) the interference range rather than useful signal range. o The choice of MAXJITTER used when forwarding messages may __MAY__ also take into account the expected number of times that the message may be sequentially forwarded, up to the network diameter in hops. Recommend replacing "MAY" with "may" in following places: 1st paragraph of 5.2 An internal or external condition or event MAY __may__ trigger message generation by a node. Depending upon the protocol, this condition MAY __may__ trigger generation of a single message, initiation of a new periodic message schedule, or rescheduling of existing periodic messaging. Collision between externally triggered messages is made more likely if more than one node is likely to respond to the same event. Recommend reviewing last 4 paragraphs of 5.3 to determine whether "may" or "MAY" and "should" or "SHOULD" should be used. 3. Section 5 discusses the 3 cases where jitter may be applied: o Periodic message generation; o Externally triggered message generation; o Message forwarding. The first and second cases appear to be related to the generation of control messages while the third case would apply to traffic as well as forwarded control messages. This appears to be two different things: the first two relate to network control processes while the third relate to network forwarding. By including all three cases, this draft protocol appears to go beyond the issues arising from synchronization of MANET routing protocol messages and address the more general problem of mitigating against synchronization problems in general that can occur with some channel access protocols. Is that the intent of this Internet Draft? Similarly the discussion in section 5.3 about combining multiple packets into one transmission seems more relevant to a MAC discussion than a network layer discussion. Since some MANETS are used for process control with very low latency constraints and have MACs that support simultaneous transmission and receptions (e.g. are not sensitive to simultaneous transmissions), I would prefer that the word "MAY" stay with respect to Message forwarding (e.g. in section 5.3). In fact, I would even like to insert some sort of text to discuss the difference between the first 2 cases and the third case. For example, the following paragraph in section 5.4 on whether to use jitter could also mention application for case 3 as well as MAC and lower layers: o As well as the decision as to whether to use jitter being dependent on the medium access control and lower layers, the selection of the MAXJITTER parameter should be appropriate to those mechanisms. ___The decision on using jitter for Message Forwarding should also be appropriate to the application.___ Jim Stevens --=_alternative 0053691C86257383_= Content-Type: text/html; charset="US-ASCII"
1.  I agree with Christopher Deerlove (email to MANET list on Fri, 26 Oct 2007 09:35:42 +0100) that jitter should not be compulsory.  Whether it is needed or not depends upon the media access control (MAC) protocol that is used.  In particular, it is useful for most (if not all) single transceiver contention based MACs (like IEEE 802.11 MACs), but not necessarily needed for all MACs. For example, it may not be needed for some time division multiple access (TDMA) MACs.  Thus, I recommend the following changes:

* Add "often" in front of undesirable in first paragraph to 1. Introduction to show that it is not always undesirable

   In a wireless network, simultaneous packet transmission by nearby
  nodes is __often__ undesirable as, depending on the medium access control and
  other lower layer mechanisms, the interference between these
  transmissions may cause at best increased delay, and at worst
  complete packet loss.

* Thus in section 5. Jitter, "SHOULD" or "MAY" are acceptable, but "MUST" is not acceptable.

  In order to prevent nodes in a MANET from simultaneous transmission,
  whilst retaining the MANET characteristic of maximum node autonomy, a
  randomization of the transmission time of packets by nodes, known as
  jitter, MAY be employed.

2.  There are several examples of the words "may/MAY" and "should/SHOULD" that appear to be in an incorrect case.

Recommend replacing "may" with "MAY" or "should" with "SHOULD" in following places:

1st paragraph of 5.3
  When a node forwards a message, it may __MAY__be jittered by delaying it by
  a random duration.

last 3 paragraphs of 5.3
   o  As well as the decision as to whether to use jitter being
     dependent on the medium access control and lower layers, the
     selection of the MAXJITTER parameter should __SHOULD__ be appropriate to
     those mechanisms.

  o  As jitter is intended to reduce collisions, greater jitter, i.e.
     an increased value of MAXJITTER, is appropriate when the chance of
     collisions is greater.  This is particularly the case with
     increased node density, where node density should __SHOULD__ be considered
     relative to (the square of) the interference range rather than
     useful signal range.

  o  The choice of MAXJITTER used when forwarding messages may __MAY__ also
     take into account the expected number of times that the message
     may be sequentially forwarded, up to the network diameter in hops.

Recommend replacing "MAY" with "may" in following places:

1st paragraph of 5.2
   An internal or external condition or event MAY __may__ trigger message
  generation by a node.  Depending upon the protocol, this condition
  MAY __may__ trigger generation of a single message, initiation of a new
  periodic message schedule, or rescheduling of existing periodic
  messaging.  Collision between externally triggered messages is made
  more likely if more than one node is likely to respond to the same
  event.

Recommend reviewing last 4 paragraphs of 5.3 to determine whether "may" or "MAY" and "should" or "SHOULD" should be used.

3.  Section 5 discusses the 3 cases where jitter may be applied:

  o  Periodic message generation;

  o  Externally triggered message generation;

  o  Message forwarding.

The first and second cases appear to be related to the generation of control messages while the third case would apply to traffic as well as forwarded control messages.  This appears to be two different things:  the first two relate to network control processes while the third relate to network forwarding.  By including all three cases, this draft protocol appears to go beyond the issues arising from synchronization of MANET routing protocol messages and address the more general problem of mitigating against synchronization problems in general that can occur with some channel access protocols.  Is that the intent of this Internet Draft?

Similarly the discussion in section 5.3 about combining multiple packets into one transmission seems more relevant to a MAC discussion than a network layer discussion.  

Since some MANETS are used for process control with very low latency constraints and have MACs that support simultaneous transmission and receptions (e.g. are not sensitive to simultaneous transmissions), I would prefer that the word "MAY" stay with respect to Message forwarding (e.g. in section 5.3).  In fact, I would even like to insert some sort of text to discuss the difference between the first 2 cases and the third case.  

For example, the following paragraph in section 5.4 on whether to use jitter could also mention application for case 3 as well as MAC and lower layers:

   o  As well as the decision as to whether to use jitter being
     dependent on the medium access control and lower layers, the
     selection of the MAXJITTER parameter should be appropriate to
     those mechanisms.  ___The decision on using jitter for
      Message Forwarding should also be appropriate to the application.___
Jim Stevens
--=_alternative 0053691C86257383_=-- --===============0151266131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0151266131==-- From manet-bounces@ietf.org Mon Oct 29 11:35:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWdf-0003lT-1g; Mon, 29 Oct 2007 11:34:51 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ImWdd-0003hu-0I for manet-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 11:34:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWdc-0003Gn-LC for manet@ietf.org; Mon, 29 Oct 2007 11:34:48 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImWdE-0005jF-Aa for manet@ietf.org; Mon, 29 Oct 2007 11:34:26 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9TFYMYf028973 for ; Mon, 29 Oct 2007 15:34:22 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9TFYO07014522 for ; Mon, 29 Oct 2007 15:34:24 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 29 Oct 2007 15:34:22 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 29 Oct 2007 15:34:22 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Oct 2007 15:34:21 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-manet-jitter-02 Thread-Index: AcgaPfOWN+jywt6QQ9unavrPJ2Wy+wAAaADg References: From: "Dearlove, Christopher (UK)" To: , X-OriginalArrivalTime: 29 Oct 2007 15:34:22.0268 (UTC) FILETIME=[2DBDF7C0:01C81A41] X-Spam-Score: -4.0 (----) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: T.Clausen@computer.org Subject: [manet] RE: draft-ietf-manet-jitter-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Thank you for your comments. Some responses below, indicated with >>. ________________________________ From: jasteven@rockwellcollins.com [mailto:jasteven@rockwellcollins.com] Sent: 29 October 2007 15:11 To: manet@ietf.org Cc: T.Clausen@computer.org; Dearlove, Christopher (UK); adamson@itd.nrl.navy.mil Subject: RE: draft-ietf-manet-jitter-02 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 =09 1. I agree with Christopher Deerlove (email to MANET list on Fri, 26 Oct 2007 09:35:42 +0100) that jitter should not be compulsory. Whether it is needed or not depends upon the media access control (MAC) protocol that is used. In particular, it is useful for most (if not all) single transceiver contention based MACs (like IEEE 802.11 MACs), but not necessarily needed for all MACs. For example, it may not be needed for some time division multiple access (TDMA) MACs. Thus, I recommend the following changes:=20 * Add "often" in front of undesirable in first paragraph to 1. Introduction to show that it is not always undesirable=20 In a wireless network, simultaneous packet transmission by nearby nodes is __often__ undesirable as, depending on the medium access control and other lower layer mechanisms, the interference between these transmissions may cause at best increased delay, and at worst complete packet loss.=20 * Thus in section 5. Jitter, "SHOULD" or "MAY" are acceptable, but "MUST" is not acceptable.=20 In order to prevent nodes in a MANET from simultaneous transmission, whilst retaining the MANET characteristic of maximum node autonomy, a randomization of the transmission time of packets by nodes, known as jitter, MAY be employed.=20 2. There are several examples of the words "may/MAY" and "should/SHOULD" that appear to be in an incorrect case.=20 Recommend replacing "may" with "MAY" or "should" with "SHOULD" in following places:=20 1st paragraph of 5.3 When a node forwards a message, it may __MAY__be jittered by delaying it by a random duration.=20 last 3 paragraphs of 5.3=20 o As well as the decision as to whether to use jitter being dependent on the medium access control and lower layers, the selection of the MAXJITTER parameter should __SHOULD__ be appropriate to those mechanisms. o As jitter is intended to reduce collisions, greater jitter, i.e. an increased value of MAXJITTER, is appropriate when the chance of collisions is greater. This is particularly the case with increased node density, where node density should __SHOULD__ be considered relative to (the square of) the interference range rather than useful signal range. o The choice of MAXJITTER used when forwarding messages may __MAY__ also take into account the expected number of times that the message may be sequentially forwarded, up to the network diameter in hops.=20 Recommend replacing "MAY" with "may" in following places:=20 1st paragraph of 5.2=20 An internal or external condition or event MAY __may__ trigger message generation by a node. Depending upon the protocol, this condition MAY __may__ trigger generation of a single message, initiation of a new periodic message schedule, or rescheduling of existing periodic messaging. Collision between externally triggered messages is made more likely if more than one node is likely to respond to the same event.=20 Recommend reviewing last 4 paragraphs of 5.3 to determine whether "may" or "MAY" and "should" or "SHOULD" should be used.=20 3. Section 5 discusses the 3 cases where jitter may be applied:=20 o Periodic message generation; o Externally triggered message generation; o Message forwarding.=20 The first and second cases appear to be related to the generation of control messages while the third case would apply to traffic as well as forwarded control messages. This appears to be two different things: the first two relate to network control processes while the third relate to network forwarding. By including all three cases, this draft protocol appears to go beyond the issues arising from synchronization of MANET routing protocol messages and address the more general problem of mitigating against synchronization problems in general that can occur with some channel access protocols. Is that the intent of this Internet Draft? >> The primary purpose here is forwarding control messages, >> not traffic (for which I wouldn't use the word messages). >> The principal issues addressed are relevant to flooded >> (possibly by an optimised mechanism) messages, not to >> unicast traffic. Of course there may be circumstances you >> might jitter traffic, but that's not what we are considering >> here. Similarly the discussion in section 5.3 about combining multiple packets into one transmission seems more relevant to a MAC discussion than a network layer discussion. >> I think it's highly relevant, if you consider in the >> context of the packetbb draft from the WG. That is >> combining messages into packets at the network layer, >> and has an interaction with jitter as discussed here. =20 Since some MANETS are used for process control with very low latency constraints and have MACs that support simultaneous transmission and receptions (e.g. are not sensitive to simultaneous transmissions), I would prefer that the word "MAY" stay with respect to Message forwarding (e.g. in section 5.3). In fact, I would even like to insert some sort of text to discuss the difference between the first 2 cases and the third case. >> I think the difference isn't as you have indicated, because >> traffic isn't our consideration. When considering control >> traffic generation, this is as much a SHOULD as the other >> cases. For example, the following paragraph in section 5.4 on whether to use jitter could also mention application for case 3 as well as MAC and lower layers:=20 o As well as the decision as to whether to use jitter being dependent on the medium access control and lower layers, the selection of the MAXJITTER parameter should be appropriate to those mechanisms. ___The decision on using jitter for=20 Message Forwarding should also be appropriate to the application.___ >> Consequently I think that's not a distinction I would make. Jim Stevens=20 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Oct 29 14:11:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZ3D-0001eW-8L; Mon, 29 Oct 2007 14:09:23 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ImZ3B-0001eO-QA for manet-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 14:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZ3B-0001dg-GK for manet@ietf.org; Mon, 29 Oct 2007 14:09:21 -0400 Received: from ovs02.rockwellcollins.com ([205.175.225.232] helo=vs02.rockwellcollins.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImZ2y-0005Km-6E for manet@ietf.org; Mon, 29 Oct 2007 14:09:19 -0400 Received: from vs02.rockwellcollins.com (localhost [127.0.0.1]) by localhost.rockwellcollins.com (Postfix) with ESMTP id 9987F31950; Mon, 29 Oct 2007 12:09:59 -0600 (CST) Received: from crnotes2.rockwellcollins.com (crnotes2.rockwellcollins.com [131.198.64.109]) by vs02.rockwellcollins.com (Postfix) with ESMTP id 6CE863194F; Mon, 29 Oct 2007 12:09:59 -0600 (CST) In-Reply-To: To: "Dearlove, Christopher (UK)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: jasteven@rockwellcollins.com Message-ID: Date: Mon, 29 Oct 2007 13:08:45 -0500 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 7.0.2FP2 HF193|August 16, 2007) at 10/29/2007 01:08:47 PM, Serialize complete at 10/29/2007 01:08:47 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Cc: manet@ietf.org, T.Clausen@computer.org Subject: [manet] RE: draft-ietf-manet-jitter-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1068037697==" Errors-To: manet-bounces@ietf.org This is a multipart message in MIME format. --===============1068037697== Content-Type: multipart/related; boundary="=_related 00633B3A86257383_=" This is a multipart message in MIME format. --=_related 00633B3A86257383_= Content-Type: multipart/alternative; boundary="=_alternative 00633B3E86257383_=" --=_alternative 00633B3E86257383_= Content-Type: text/plain; charset="US-ASCII" Chris, in response to your response to my comments about Message Forwarding in section 5.3: Now that I understand that the Draft Internet is talking about control messages (e.g. like the one-hop forwarding of broadcast link control messages) instead of more general traffic forwarding; I agree with your comments to my comments on Message Forwarding (the extract of your response below). Note that distinction (between control messages and general network traffic) was not clear to me when I read the Internet Draft. Thus, I recommend that some additional clarification is needed. Either in section 5.3 (preferrably) but possibly as a definition of a message in section 2. Jim "Dearlove, Christopher (UK)" 10/29/2007 10:34 AM To , cc , Subject RE: draft-ietf-manet-jitter-02 Thank you for your comments. Some responses below, indicated with >>. ________________________________ From: jasteven@rockwellcollins.com [mailto:jasteven@rockwellcollins.com] Sent: 29 October 2007 15:11 To: manet@ietf.org Cc: T.Clausen@computer.org; Dearlove, Christopher (UK); adamson@itd.nrl.navy.mil Subject: RE: draft-ietf-manet-jitter-02 [text deleted] 3. Section 5 discusses the 3 cases where jitter may be applied: o Periodic message generation; o Externally triggered message generation; o Message forwarding. The first and second cases appear to be related to the generation of control messages while the third case would apply to traffic as well as forwarded control messages. This appears to be two different things: the first two relate to network control processes while the third relate to network forwarding. By including all three cases, this draft protocol appears to go beyond the issues arising from synchronization of MANET routing protocol messages and address the more general problem of mitigating against synchronization problems in general that can occur with some channel access protocols. Is that the intent of this Internet Draft? >> The primary purpose here is forwarding control messages, >> not traffic (for which I wouldn't use the word messages). >> The principal issues addressed are relevant to flooded >> (possibly by an optimised mechanism) messages, not to >> unicast traffic. Of course there may be circumstances you >> might jitter traffic, but that's not what we are considering >> here. Similarly the discussion in section 5.3 about combining multiple packets into one transmission seems more relevant to a MAC discussion than a network layer discussion. >> I think it's highly relevant, if you consider in the >> context of the packetbb draft from the WG. That is >> combining messages into packets at the network layer, >> and has an interaction with jitter as discussed here. Since some MANETS are used for process control with very low latency constraints and have MACs that support simultaneous transmission and receptions (e.g. are not sensitive to simultaneous transmissions), I would prefer that the word "MAY" stay with respect to Message forwarding (e.g. in section 5.3). In fact, I would even like to insert some sort of text to discuss the difference between the first 2 cases and the third case. >> I think the difference isn't as you have indicated, because >> traffic isn't our consideration. When considering control >> traffic generation, this is as much a SHOULD as the other >> cases. For example, the following paragraph in section 5.4 on whether to use jitter could also mention application for case 3 as well as MAC and lower layers: o As well as the decision as to whether to use jitter being dependent on the medium access control and lower layers, the selection of the MAXJITTER parameter should be appropriate to those mechanisms. ___The decision on using jitter for Message Forwarding should also be appropriate to the application.___ >> Consequently I think that's not a distinction I would make. Jim Stevens ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --=_alternative 00633B3E86257383_= Content-Type: text/html; charset="US-ASCII"
Chris, in response to your response to my comments about Message Forwarding in section 5.3:

Now that I understand that the Draft Internet is talking about control messages (e.g. like the one-hop forwarding of broadcast link control messages) instead of more general traffic forwarding; I agree with your comments to my comments on Message Forwarding (the extract of your response below).

Note that distinction (between control messages and general network traffic)  was not clear to me when I read the Internet Draft. Thus, I recommend that some additional clarification is needed.  Either in section 5.3 (preferrably) but possibly as a definition of a message in section 2.

Jim



"Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>

10/29/2007 10:34 AM
 Encrypted

To
<jasteven@rockwellcollins.com>, <manet@ietf.org>
cc
<T.Clausen@computer.org>, <adamson@itd.nrl.navy.mil>
Subject
RE: draft-ietf-manet-jitter-02






Thank you for your comments. Some responses below,
indicated with >>.

________________________________

From: jasteven@rockwellcollins.com [mailto:jasteven@rockwellcollins.com]

Sent: 29 October 2007 15:11
To: manet@ietf.org
Cc: T.Clausen@computer.org; Dearlove, Christopher (UK);
adamson@itd.nrl.navy.mil
Subject: RE: draft-ietf-manet-jitter-02


[text deleted]

3.  Section 5 discusses the 3 cases where jitter may be applied:

 o  Periodic message generation;

 o  Externally triggered message generation;

 o  Message forwarding.

The first and second cases appear to be related to the generation of
control messages while the third case would apply to traffic as well as
forwarded control messages.  This appears to be two different things:
the first two relate to network control processes while the third relate
to network forwarding.  By including all three cases, this draft
protocol appears to go beyond the issues arising from synchronization of
MANET routing protocol messages and address the more general problem of
mitigating against synchronization problems in general that can occur
with some channel access protocols.  Is that the intent of this Internet
Draft?

>> The primary purpose here is forwarding control messages,
>> not traffic (for which I wouldn't use the word messages).
>> The principal issues addressed are relevant to flooded
>> (possibly by an optimised mechanism) messages, not to
>> unicast traffic. Of course there may be circumstances you
>> might jitter traffic, but that's not what we are considering
>> here.

Similarly the discussion in section 5.3 about combining multiple packets
into one transmission seems more relevant to a MAC discussion than a
network layer discussion.

>> I think it's highly relevant, if you consider in the
>> context of the packetbb draft from the WG. That is
>> combining messages into packets at the network layer,
>> and has an interaction with jitter as discussed here.  

Since some MANETS are used for process control with very low latency
constraints and have MACs that support simultaneous transmission and
receptions (e.g. are not sensitive to simultaneous transmissions), I
would prefer that the word "MAY" stay with respect to Message forwarding
(e.g. in section 5.3).  In fact, I would even like to insert some sort
of text to discuss the difference between the first 2 cases and the
third case.

>> I think the difference isn't as you have indicated, because
>> traffic isn't our consideration. When considering control
>> traffic generation, this is as much a SHOULD as the other
>> cases.

For example, the following paragraph in section 5.4 on whether to use
jitter could also mention application for case 3 as well as MAC and
lower layers:

  o  As well as the decision as to whether to use jitter being
    dependent on the medium access control and lower layers, the
    selection of the MAXJITTER parameter should be appropriate to
    those mechanisms.  ___The decision on using jitter for
     Message Forwarding should also be appropriate to the
application.___

>> Consequently I think that's not a distinction I would make.

Jim Stevens


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
--=_alternative 00633B3E86257383_=-- --=_related 00633B3A86257383_=-- --===============1068037697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1068037697==-- From manet-bounces@ietf.org Tue Oct 30 00:36:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImikX-0005vZ-PO; Tue, 30 Oct 2007 00:30:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ImikW-0005vT-0A for manet-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 00:30:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImikV-0005vL-LP for manet@ietf.org; Tue, 30 Oct 2007 00:30:43 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImikV-0002ne-AL for manet@ietf.org; Tue, 30 Oct 2007 00:30:43 -0400 Received: by nf-out-0910.google.com with SMTP id d21so1349261nfb for ; Mon, 29 Oct 2007 21:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=vejvEgEdqYTKJtSfe8LeKMHiJ0wEoJRnt3bQnD6HR6s=; b=ByYQTpfts2EBhl+a3G30uFBBV2h44hfAZR6friVTzS3vBy/HQq7y/9DTxhmMlwk0oX9YptCkHqPUU4HyO3UDx+5H3NeDBkTyhWkukEZ8IhtNdjTSXnrIBWboEwdndCEXhgIlGhwTaiscFpiEOsL7Jzl1ux+1PP5QitmMaIJkMzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eJyjDeBCZIP+1I4SdtG9h93mlLBEKuqLMMpUXICvr5gOSQjV8S9nfA2WIAK/qamUI9j0M6hN6AN9MtmW+QwP9+T/F93Y2yc6E8NGDvWtDwwzZw8ikujzeGcsTZF0G96bbKYOVKNa2+z6tMd8LKDF0oL80g6N53ebNF6lcCZtNEM= Received: by 10.78.204.20 with SMTP id b20mr4726563hug.1193717079509; Mon, 29 Oct 2007 21:04:39 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Mon, 29 Oct 2007 21:04:39 -0700 (PDT) Message-ID: <374005f30710292104k3062eb16m28dc82e2576f26e2@mail.gmail.com> Date: Tue, 30 Oct 2007 09:34:39 +0530 From: "Ian Chakeres" To: manet In-Reply-To: <374005f30710270602y31b3024flc3bec25674ef6396@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30710270602y31b3024flc3bec25674ef6396@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "Dearlove, Christopher \(UK\)" , Thomas Clausen Subject: [manet] Re: Security consideration text regarding carrying multiple messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org How do you feel about the following text being placed in the security considerations section of the IANA document? """ The security issues associated with operating multiple cooperating MANET protocols on same IANA assignments (e.g. UDP port) are addressed in each protocols' specification, as are each protocols' particular security considerations. """ Please provide comments and suggestions. Ian Chakeres On 10/27/07, Ian Chakeres wrote: > I believe that since PacketBB is the container format built for > carrying multiple messages (possibly and likely from multiple > protocols) the security consideration section should discuss this > issue. > > Independent of the location, I'd like to solicit suggestions on the > appropriate text. > > Everyone, what would you suggest? > > Ian Chakeres > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Oct 30 04:59:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Immsx-0005g0-FH; Tue, 30 Oct 2007 04:55:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Immsu-0005cI-Sx for manet-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 04:55:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Immsu-0005bO-86 for manet@ietf.org; Tue, 30 Oct 2007 04:55:40 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Immst-0002hV-0g for manet@ietf.org; Tue, 30 Oct 2007 04:55:39 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1193734537!19348437!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 29375 invoked from network); 30 Oct 2007 08:55:37 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-9.tower-128.messagelabs.com with SMTP; 30 Oct 2007 08:55:37 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l9U8tbNJ015081; Tue, 30 Oct 2007 01:55:37 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l9U8tabW028187; Tue, 30 Oct 2007 03:55:36 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l9U8tXvu028149; Tue, 30 Oct 2007 03:55:34 -0500 (CDT) Message-ID: <4726F184.7060705@gmail.com> Date: Tue, 30 Oct 2007 09:55:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Re: Security consideration text regarding carrying multiple messages References: <374005f30710270602y31b3024flc3bec25674ef6396@mail.gmail.com> <374005f30710292104k3062eb16m28dc82e2576f26e2@mail.gmail.com> In-Reply-To: <374005f30710292104k3062eb16m28dc82e2576f26e2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071029-0, 29/10/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "Dearlove, Christopher \(UK\)" , manet , Thomas Clausen X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > How do you feel about the following text being placed in the security > considerations section of the IANA document? > > """ > The security issues associated with operating multiple > cooperating MANET protocols on same IANA assignments (e.g. UDP > port) are addressed in each protocols' specification, as are > each protocols' particular security considerations. > """ > > Please provide comments and suggestions. If you're asking members on this group as well... I am not sure into how much depth do we want to discuss this... One first wonders are those MANET protocols cooperating or competing? You're saying cooperating. If they were truly cooperating I don't see any risk. If they're competing is there a risk that two competing protocols compute different paths leading to a deadlocking deadend looping situation? Is this a security risk? What kind of security risk do you mean by "using same UDP port/mcastaddr/IPprotocolnumber associates security issues"? I see some operational headaches (at least: tough to write a meaningful Ethereal/Wireshark dissector), but what are the security issues and risks? Alex > Ian Chakeres > > On 10/27/07, Ian Chakeres wrote: >> I believe that since PacketBB is the container format built for >> carrying multiple messages (possibly and likely from multiple >> protocols) the security consideration section should discuss this >> issue. >> >> Independent of the location, I'd like to solicit suggestions on the >> appropriate text. >> >> Everyone, what would you suggest? >> >> Ian Chakeres >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Oct 30 05:36:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImnU3-0008V8-Jp; Tue, 30 Oct 2007 05:34:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ImnU1-0008SO-41 for manet-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 05:34:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImnU0-0008SG-Qr for manet@ietf.org; Tue, 30 Oct 2007 05:34:00 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImnTu-0000vf-Ki for manet@ietf.org; Tue, 30 Oct 2007 05:34:00 -0400 Received: by nf-out-0910.google.com with SMTP id d21so1393233nfb for ; Tue, 30 Oct 2007 02:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=fxvWk0l75KdhO3y0niGhnm91kw/0I+vLmig7WIN13PY=; b=tLSlj5pedGf+TYo8t0ibZO0kN7GlbF15fc/frQI34iavCsQqW09iOkeNw1TLbLHCJSOnkx661xCvjya26zWfZ8gR5j1d11zrw04kTgnypGtPPQ3zi/UZYw0JltXXw9SLVAfSoe8LLijWMk+qMG7y74lzvXcnALe4bycoahX6xmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UfBR8rTnRtui5IwTTK5pC+DA2qfCmgyF+8GQJY4lRVVVK0PUtjk+54nY5P4f7MKaLyRQsHEso5Dx6n8+PPWG4WxsGkXqR22SOJgaKzrCkQn7CF9tMuTJjbzLWL3nIwaRqZM2Vd8hlqjyG39NvY5eDtzsFM2uZng/dR5zLwaxRJw= Received: by 10.78.170.6 with SMTP id s6mr4962574hue.1193736817291; Tue, 30 Oct 2007 02:33:37 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Tue, 30 Oct 2007 02:33:37 -0700 (PDT) Message-ID: <374005f30710300233l5af9e70eu93e40b2aa4a4d158@mail.gmail.com> Date: Tue, 30 Oct 2007 15:03:37 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Re: Security consideration text regarding carrying multiple messages In-Reply-To: <4726F184.7060705@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30710270602y31b3024flc3bec25674ef6396@mail.gmail.com> <374005f30710292104k3062eb16m28dc82e2576f26e2@mail.gmail.com> <4726F184.7060705@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Dearlove, Christopher \(UK\)" , manet , Thomas Clausen X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On 10/30/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > > How do you feel about the following text being placed in the security > > considerations section of the IANA document? > > > > """ > > The security issues associated with operating multiple > > cooperating MANET protocols on same IANA assignments (e.g. UDP > > port) are addressed in each protocols' specification, as are > > each protocols' particular security considerations. > > """ > > > > Please provide comments and suggestions. > > If you're asking members on this group as well... I am not sure into how > much depth do we want to discuss this... I think we should try to stay within the context of what the MANET-IANA document should say. > One first wonders are those MANET protocols cooperating or competing? > You're saying cooperating. If they were truly cooperating I don't see > any risk. > > If they're competing is there a risk that two competing protocols > compute different paths leading to a deadlocking deadend looping > situation? Is this a security risk? The general case will be one of cooperation. For example, NHDP with DYMO or OLSRv2. The competing issue you described would be associated with routing protocols, not necessarily the IANA allocations or combined messaging. The situation you described is no different from today's routing suites where multiple routing protocols run simultaneously. Mechanisms exist to handle this type of competition/redundancy. > What kind of security risk do you mean by "using same UDP > port/mcastaddr/IPprotocolnumber associates security issues"? I see some > operational headaches (at least: tough to write a meaningful > Ethereal/Wireshark dissector), but what are the security issues and risks? DISCLAIMER: I'm not a security expert either. Therefore, I do not see a big issue with our scenarios and the IANA allocations. That said, I am doing my best to identify the possible security complications and propose a solution. Ian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Oct 30 05:39:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImnYe-0007HG-04; Tue, 30 Oct 2007 05:38:48 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ImnYa-0007Gi-Sb for manet-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 05:38:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImnYa-0007Ga-Is for manet@ietf.org; Tue, 30 Oct 2007 05:38:44 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImnYT-0001Ba-SV for manet@ietf.org; Tue, 30 Oct 2007 05:38:44 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9U9cNaH007280 for ; Tue, 30 Oct 2007 09:38:23 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9U9cNmt015535 for ; Tue, 30 Oct 2007 09:38:23 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 30 Oct 2007 09:38:23 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 30 Oct 2007 09:38:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Oct 2007 09:38:22 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-manet-jitter-02 Thread-Index: AcgaVsLuKT6akaVrTbu0kCJIV5bf5QAgTXuQ References: From: "Dearlove, Christopher (UK)" To: X-OriginalArrivalTime: 30 Oct 2007 09:38:23.0178 (UTC) FILETIME=[9D253AA0:01C81AD8] X-Spam-Score: -4.0 (----) X-Scan-Signature: da41e01217ab11ad82db577473e913ae Cc: manet@ietf.org, T.Clausen@computer.org Subject: [manet] RE: draft-ietf-manet-jitter-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1395762027==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1395762027== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81AD8.9CF9BAA7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81AD8.9CF9BAA7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I need to look at the draft to work out where/what to add, but some clarification can be added (by whoever edits it next). Partly that can be a (non-normative) reference to packetbb, which has that organisation, but this document is not specific to packetbb, and a wider comment (with packetbb as an example) should work I think. Thanks again for the comments (the MAY/may, SHOULD/should ones as well). ________________________________ From: jasteven@rockwellcollins.com [mailto:jasteven@rockwellcollins.com] Sent: 29 October 2007 18:09 To: Dearlove, Christopher (UK) Cc: adamson@itd.nrl.navy.mil; manet@ietf.org; T.Clausen@computer.org Subject: RE: draft-ietf-manet-jitter-02 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 =09 Chris, in response to your response to my comments about Message Forwarding in section 5.3:=20 Now that I understand that the Draft Internet is talking about control messages (e.g. like the one-hop forwarding of broadcast link control messages) instead of more general traffic forwarding; I agree with your comments to my comments on Message Forwarding (the extract of your response below).=20 Note that distinction (between control messages and general network traffic) was not clear to me when I read the Internet Draft. Thus, I recommend that some additional clarification is needed. Either in section 5.3 (preferrably) but possibly as a definition of a message in section 2.=20 Jim=20 "Dearlove, Christopher (UK)" =20 10/29/2007 10:34 AM=20 Encrypted=20 To , =20 cc , =20 Subject RE: draft-ietf-manet-jitter-02 =09 Thank you for your comments. Some responses below, indicated with >>. ________________________________ From: jasteven@rockwellcollins.com [mailto:jasteven@rockwellcollins.com] Sent: 29 October 2007 15:11 To: manet@ietf.org Cc: T.Clausen@computer.org; Dearlove, Christopher (UK); adamson@itd.nrl.navy.mil Subject: RE: draft-ietf-manet-jitter-02 [text deleted]=20 3. Section 5 discusses the 3 cases where jitter may be applied:=20 o Periodic message generation; o Externally triggered message generation; o Message forwarding.=20 The first and second cases appear to be related to the generation of control messages while the third case would apply to traffic as well as forwarded control messages. This appears to be two different things: the first two relate to network control processes while the third relate to network forwarding. By including all three cases, this draft protocol appears to go beyond the issues arising from synchronization of MANET routing protocol messages and address the more general problem of mitigating against synchronization problems in general that can occur with some channel access protocols. Is that the intent of this Internet Draft? >> The primary purpose here is forwarding control messages, >> not traffic (for which I wouldn't use the word messages). >> The principal issues addressed are relevant to flooded >> (possibly by an optimised mechanism) messages, not to >> unicast traffic. Of course there may be circumstances you >> might jitter traffic, but that's not what we are considering >> here. Similarly the discussion in section 5.3 about combining multiple packets into one transmission seems more relevant to a MAC discussion than a network layer discussion. >> I think it's highly relevant, if you consider in the >> context of the packetbb draft from the WG. That is >> combining messages into packets at the network layer, >> and has an interaction with jitter as discussed here. =20 Since some MANETS are used for process control with very low latency constraints and have MACs that support simultaneous transmission and receptions (e.g. are not sensitive to simultaneous transmissions), I would prefer that the word "MAY" stay with respect to Message forwarding (e.g. in section 5.3). In fact, I would even like to insert some sort of text to discuss the difference between the first 2 cases and the third case. >> I think the difference isn't as you have indicated, because >> traffic isn't our consideration. When considering control >> traffic generation, this is as much a SHOULD as the other >> cases. For example, the following paragraph in section 5.4 on whether to use jitter could also mention application for case 3 as well as MAC and lower layers:=20 o As well as the decision as to whether to use jitter being dependent on the medium access control and lower layers, the selection of the MAXJITTER parameter should be appropriate to those mechanisms. ___The decision on using jitter for=20 Message Forwarding should also be appropriate to the application.___ >> Consequently I think that's not a distinction I would make. Jim Stevens=20 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** ------_=_NextPart_001_01C81AD8.9CF9BAA7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I need to look at the draft to work out = where/what to add,=20 but some
clarification can be added (by whoever edits it = next). Partly that can be
a (non-normative) reference to=20 packetbb, which has that organisation,
but this document is not specific=20 to packetbb, and a wider comment
(with packetbb as an example)=20 should work I think. Thanks again for
 the comments (the MAY/may,=20 SHOULD/should ones as well).

From: jasteven@rockwellcollins.com=20 [mailto:jasteven@rockwellcollins.com]
Sent: 29 October 2007=20 18:09
To: Dearlove, Christopher (UK)
Cc:=20 adamson@itd.nrl.navy.mil; manet@ietf.org;=20 T.Clausen@computer.org
Subject: RE:=20 draft-ietf-manet-jitter-02

*** WARNING = ***

This mail=20 has originated outside your organization,
either from an = external=20 partner or the Global Internet.
Keep this in mind if you = answer this=20 message.

Chris, in response to your response to my comments about = Message=20 Forwarding in section 5.3:

Now that=20 I understand that the Draft Internet is talking about control messages = (e.g.=20 like the one-hop forwarding of broadcast link control messages) instead = of more=20 general traffic forwarding; I agree with your comments to my comments on = Message=20 Forwarding (the extract of your response below).

Note that distinction (between control = messages and=20 general network traffic)  was not clear to me when I read the = Internet=20 Draft. Thus, I recommend that some additional clarification is needed.=20  Either in section 5.3 (preferrably) but possibly as a definition = of a=20 message in section 2.

Jim=20



"Dearlove, = Christopher=20 (UK)" <Chris.Dearlove@baesystems.com>

10/29/2007 10:34 AM =
 3DEncrypted=20

To
<jasteven@rockwellcollins.com>,=20 <manet@ietf.org>=20
cc
<T.Clausen@computer.org>,=20 <adamson@itd.nrl.navy.mil>=20
Subject
RE:=20 draft-ietf-manet-jitter-02

=





Thank you for your comments. Some responses = below,
indicated=20 with >>.

________________________________

From:=20 jasteven@rockwellcollins.com = [mailto:jasteven@rockwellcollins.com]

Sent:=20 29 October 2007 15:11
To: manet@ietf.org
Cc: = T.Clausen@computer.org;=20 Dearlove, Christopher (UK);
adamson@itd.nrl.navy.mil
Subject: RE:=20 draft-ietf-manet-jitter-02


[text deleted]=20

3.  Section 5 discusses = the 3=20 cases where jitter may be applied:

 o  Periodic = message=20 generation;

 o  Externally triggered message=20 generation;

 o  Message forwarding.

The first = and=20 second cases appear to be related to the generation of
control = messages while=20 the third case would apply to traffic as well as
forwarded control = messages.=20  This appears to be two different things:
the first two relate = to=20 network control processes while the third relate
to network = forwarding.=20  By including all three cases, this draft
protocol appears to go = beyond=20 the issues arising from synchronization of
MANET routing protocol = messages=20 and address the more general problem of
mitigating against = synchronization=20 problems in general that can occur
with some channel access = protocols.=20  Is that the intent of this Internet
Draft?

>> The = primary=20 purpose here is forwarding control messages,
>> not traffic = (for which=20 I wouldn't use the word messages).
>> The principal issues = addressed=20 are relevant to flooded
>> (possibly by an optimised mechanism) = messages, not to
>> unicast traffic. Of course there may be=20 circumstances you
>> might jitter traffic, but that's not what = we are=20 considering
>> here.

Similarly the discussion in section = 5.3=20 about combining multiple packets
into one transmission seems more = relevant to=20 a MAC discussion than a
network layer discussion.

>> I = think=20 it's highly relevant, if you consider in the
>> context of the = packetbb=20 draft from the WG. That is
>> combining messages into packets = at the=20 network layer,
>> and has an interaction with jitter as = discussed here.=20  

Since some MANETS are used for process control with very = low=20 latency
constraints and have MACs that support simultaneous = transmission=20 and
receptions (e.g. are not sensitive to simultaneous = transmissions),=20 I
would prefer that the word "MAY" stay with respect to Message=20 forwarding
(e.g. in section 5.3).  In fact, I would even like to = insert=20 some sort
of text to discuss the difference between the first 2 cases = and=20 the
third case.

>> I think the difference isn't as you = have=20 indicated, because
>> traffic isn't our consideration. When = considering=20 control
>> traffic generation, this is as much a SHOULD as the=20 other
>> cases.

For example, the following paragraph in = section=20 5.4 on whether to use
jitter could also mention application for case = 3 as=20 well as MAC and
lower layers:

  o  As well as the = decision=20 as to whether to use jitter being
    dependent on the = medium=20 access control and lower layers, the
    selection of the = MAXJITTER=20 parameter should be appropriate to
    those mechanisms.=20  ___The decision on using jitter for
    =  Message=20 Forwarding should also be appropriate to = the
application.___

>>=20 Consequently I think that's not a distinction I would make.

Jim = Stevens=20


*************************************************************= *******
This=20 email and any attachments are confidential to the intended
recipient = and may=20 also be privileged. If you are not the intended
recipient please = delete it=20 from your system and notify the sender.
You should not copy it or use = it for=20 any purpose nor disclose or
distribute its contents to any other=20 person.
**************************************************************= ******


------_=_NextPart_001_01C81AD8.9CF9BAA7-- --===============1395762027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1395762027==-- From manet-bounces@ietf.org Tue Oct 30 09:52:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImrTK-0006G6-2A; Tue, 30 Oct 2007 09:49:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ImrTI-0006Fw-SB for manet-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 09:49:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImrTI-0006FT-H6 for manet@ietf.org; Tue, 30 Oct 2007 09:49:32 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImrT9-0003uX-JG for manet@ietf.org; Tue, 30 Oct 2007 09:49:28 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9UDnLZ6018520 for ; Tue, 30 Oct 2007 13:49:21 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9UDnKVV020686 for ; Tue, 30 Oct 2007 13:49:20 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 30 Oct 2007 13:49:21 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 30 Oct 2007 13:49:21 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] draft-ietf-manet-olsrv2-04 Date: Tue, 30 Oct 2007 13:49:19 -0000 Message-ID: In-Reply-To: <001f01c81afb$5e03cd00$4a02440a@h3c.huawei3com.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] draft-ietf-manet-olsrv2-04 Thread-Index: Acga+1xdZAobLJ4fQOyNyTceIlXATwAACLNQ References: <001f01c81afb$5e03cd00$4a02440a@h3c.huawei3com.com> From: "Dearlove, Christopher (UK)" To: "Yogdutt Sonivadia" , X-OriginalArrivalTime: 30 Oct 2007 13:49:21.0338 (UTC) FILETIME=[AC8219A0:01C81AFB] X-Spam-Score: -4.0 (----) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: "Thomas Heide Clausen \(work\)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org The correct length is 16 bits. Thanks for the catch, we'll correct it in the next version. -----Original Message----- From: Yogdutt Sonivadia [mailto:yogduttHS@h3c.com]=20 Sent: 30 October 2007 13:47 To: manet@ietf.org Cc: Dearlove, Christopher (UK) Subject: [manet] draft-ietf-manet-olsrv2-04 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 In section 8.2.1 it's mentioned that the length of CONT_SEQ_NUM is 8 bits only while in the example of TC message (Appendix D.3) it's mentioned that it's a 16 bits value. Can you tell me which is the correct length for the CONT_SEQ_NUM? 8.2.1. TC Message TLVs In a TC message, a node MUST include a CONT_SEQ_NUM message TLV, and MAY contain an INCOMPLETE message TLV, as specified in Table 3. A node MUST NOT include more than one CONT_SEQ_NUM message TLV or INCOMPLETE message TLV. +--------------+------+---------+--------+--------------------------+ | Name | Type | Subtype | Length | Value | +--------------+------+---------+--------+--------------------------+ | CONT_SEQ_NUM | TBD | 0 | 8 bits | The ANSN contained in | | | | | | the Advertised Neighbor | | | | | | Set | | | | | | | | INCOMPLETE | TBD | 0 | 0 bits | None | +--------------+------+---------+--------+--------------------------+ Appendix D.3. Example TC Message An example TC message, using IPv4 (four octet) addresses, is as follows. The overall message length is 67 octets. The message has a message TLV block with content length 13 octets containing three TLVs. The first two TLVs are validity and interval times as for the HELLO message above. The third TLV is a content sequence number TLV used to carry the 2 octet ANSN. The semantics value is also 8. . . . 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TC |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1| VALIDITY_TIME |0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1| Value | INTERVAL_TIME |0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1| Value | CONT_SEQ_NUM |0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 0| Value (ANSN) |0 0 0 0 0 0 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x02 |0 0 0 0 0 0 1 0| Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Regards, Yogdutt Sonivadia ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Oct 30 09:52:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImrSq-0005X4-0K; Tue, 30 Oct 2007 09:49:04 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ImrSo-0005Qu-98 for manet-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 09:49:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImrSn-0002kU-Ty for manet@ietf.org; Tue, 30 Oct 2007 09:49:01 -0400 Received: from [219.134.130.94] (helo=huawei-3com.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImrRu-0003oG-Bc for manet@ietf.org; Tue, 30 Oct 2007 09:48:07 -0400 Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JQQ00IZI99P0H@h3cml02-in.huawei-3com.com> for manet@ietf.org; Tue, 30 Oct 2007 21:53:49 +0800 (CST) Received: from smtp1.h3c.com ([172.19.1.38]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JQQ00HYP99P6Y@h3cml02-in.huawei-3com.com> for manet@ietf.org; Tue, 30 Oct 2007 21:53:49 +0800 (CST) Received: from unknown (HELO Yogdutt) ([10.165.0.230]) by smtp1.h3c.com with ESMTP; Tue, 30 Oct 2007 21:41:25 +0800 Date: Tue, 30 Oct 2007 19:17:07 +0530 From: Yogdutt Sonivadia Subject: [manet] draft-ietf-manet-olsrv2-04 To: manet@ietf.org Message-id: <001f01c81afb$5e03cd00$4a02440a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acga+1xdZAobLJ4fQOyNyTceIlXATw== X-Spam-Score: 1.8 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: chris.dearlove@baesystems.com X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org In section 8.2.1 it's mentioned that the length of CONT_SEQ_NUM is 8 bits only while in the example of TC message (Appendix D.3) it's mentioned that it's a 16 bits value. Can you tell me which is the correct length for the CONT_SEQ_NUM? 8.2.1. TC Message TLVs In a TC message, a node MUST include a CONT_SEQ_NUM message TLV, and MAY contain an INCOMPLETE message TLV, as specified in Table 3. A node MUST NOT include more than one CONT_SEQ_NUM message TLV or INCOMPLETE message TLV. +--------------+------+---------+--------+--------------------------+ | Name | Type | Subtype | Length | Value | +--------------+------+---------+--------+--------------------------+ | CONT_SEQ_NUM | TBD | 0 | 8 bits | The ANSN contained in | | | | | | the Advertised Neighbor | | | | | | Set | | | | | | | | INCOMPLETE | TBD | 0 | 0 bits | None | +--------------+------+---------+--------+--------------------------+ Appendix D.3. Example TC Message An example TC message, using IPv4 (four octet) addresses, is as follows. The overall message length is 67 octets. The message has a message TLV block with content length 13 octets containing three TLVs. The first two TLVs are validity and interval times as for the HELLO message above. The third TLV is a content sequence number TLV used to carry the 2 octet ANSN. The semantics value is also 8. . . . 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TC |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1| VALIDITY_TIME |0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1| Value | INTERVAL_TIME |0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1| Value | CONT_SEQ_NUM |0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 0| Value (ANSN) |0 0 0 0 0 0 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x02 |0 0 0 0 0 0 1 0| Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Regards, Yogdutt Sonivadia _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Oct 30 13:20:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imuhr-000072-JB; Tue, 30 Oct 2007 13:16:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Imuhp-0008QV-7A for manet-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 13:16:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imuho-0008HF-SH for manet@ietf.org; Tue, 30 Oct 2007 13:16:44 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imuhj-0002RO-93 for manet@ietf.org; Tue, 30 Oct 2007 13:16:39 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l9UHGPRO015929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Oct 2007 10:16:30 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l9UHGOm1004004; Tue, 30 Oct 2007 10:16:24 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l9UHGJPU003701; Tue, 30 Oct 2007 10:16:23 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 10:16:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Tue, 30 Oct 2007 10:16:01 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDB9C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <374005f30710270545g429fb6f3v8a0d0b4bf14b2ce5@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Thread-Index: AcgYlzyOcHPzXN6PQ0OBP3qBCUoZkACfUvLw References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDB86@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDB87@XCH-NW-7V2.nw.nos.boeing.com> <4722606E.6010805@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDB8A@XCH-NW-7V2.nw.nos.boeing.com> <374005f30710270545g429fb6f3v8a0d0b4bf14b2ce5@mail.gmail.com> From: "Templin, Fred L" To: "Ian Chakeres" X-OriginalArrivalTime: 30 Oct 2007 17:16:18.0732 (UTC) FILETIME=[95DA0EC0:01C81B18] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian, Sorry for the delay; didn't see this until now. I also missed the list archive discussion thread you're referring to - I guess that was the one that took place ~5/10/07? Based on what I saw in the archives, two frequent posters to this list were saying to keep the allocations, one frequent poster to the list was asking to remove them, and two new posters to the list asked about the use case. Were there other comments/opinions registered that didn't show up on the list? Fred fred.l.templin@boeing.com > -----Original Message----- > From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 > Sent: Saturday, October 27, 2007 5:45 AM > To: Templin, Fred L > Cc: Alexandru Petrescu; manet > Subject: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt >=20 > Fred, Alex. >=20 > Please look back in the manet archives for discussion about > site-scoped multicast allocations. Many people were strongly against > including site-scoped multicast. The main reason was that none of the > current protocols being standardized utilize site-scoped messages. >=20 > I previously fought hard for site-scoped addresses, but I was=20 > in the minority. >=20 > Ian Chakeres >=20 > On 10/27/07, Templin, Fred L wrote: > > Alex, > > > > > -----Original Message----- > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > > Sent: Friday, October 26, 2007 2:47 PM > > > To: Templin, Fred L > > > Cc: Ian Chakeres; manet > > > Subject: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt > > > > > > Templin, Fred L wrote: > > > >> There is at least one use case for a site-scoped IPv4 > > > >> multicast address that I am aware of, so I would like to > > > >> see that allocation request put back in the document. > > > > > > > > Err, I meant to say for *both* IPv4 and IPv6. > > > > > > For IPv6, I am not sure what you mean by site-scoped _multicast_ > > > addresses, since site-scoped fec0 addresses are deprecated. > > > > Site-scoped multicast are cited in RFC4291 and have nothing > > to do with the now-deprecated fec0 site-scoped unicast. > > > > > If we can get a common understanding about what a site is=20 > in general, > > > and what is a site in the case of a MANET - then I think=20 > I can agree. > > > > > > Or am I the only one here to not understand what a site is. > > > > I have a definition for site that I use, but I don't think > > you are the only one who would claim not to understand site. > > This discussion may apply to a larger scope than just this > > wg, however. What do you think? > > > > Fred > > fred.l.templin@boeing.com > > > > > Alex > > > > > > > > > > > Fred > > > > fred.l.templin@beoing.com > > > > > > > > > > > > _______________________________________________ > > > > manet mailing list > > > > manet@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > > > > > > >=20 > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email=20 > Security System. > > > For more information please visit http://www.messagelabs.com/email > > >=20 > ______________________________________________________________________ > > > > > >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Oct 30 13:20:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imulf-0005gR-Pd; Tue, 30 Oct 2007 13:20:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Imuld-0005gH-QF for manet-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 13:20:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imuld-0005eQ-G5 for manet@ietf.org; Tue, 30 Oct 2007 13:20:41 -0400 Received: from hpsmtp-eml16.kpnxchange.com ([213.75.38.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImulX-0002Yk-PL for manet@ietf.org; Tue, 30 Oct 2007 13:20:36 -0400 Received: from hpsmtp-eml07.kpnxchange.com ([213.75.38.107]) by hpsmtp-eml16.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 18:20:34 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 18:20:34 +0100 From: "Teco Boot" To: "'Ian Chakeres'" , "'manet'" References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> In-Reply-To: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Tue, 30 Oct 2007 18:20:26 +0100 Message-ID: <009401c81b19$29a04200$7ce0c600$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgXjL1eyBpNgua4SoG8t5A9wZHSuQDi36PA Content-Language: nl X-OriginalArrivalTime: 30 Oct 2007 17:20:34.0589 (UTC) FILETIME=[2E5ABCD0:01C81B19] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > Second, during IETF LC & IESG review there were a few questions asking > why we were not allocating an IP protocol number. In response to this > request, I have added a request for an IP protocol number. This will > allow us to advance our protocols from UDP to an IP protocol number in > the future. Teco: 1) I think this topic was discussed on MANET ML and the outcome was there was no need for requesting an IP_PROTO number. 2) I do not like requesting an UDP port number AND an IP_PROTO number. A STD protocol shall pick one and shall not leave this open to . _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Oct 30 15:43:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImwxA-00028j-V9; Tue, 30 Oct 2007 15:40:44 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Imwx8-00028W-KF for manet-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 15:40:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imwx8-0001yj-AQ for manet@ietf.org; Tue, 30 Oct 2007 15:40:42 -0400 Received: from hpsmtp-eml16.kpnxchange.com ([213.75.38.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imwwx-0001Wu-2T for manet@ietf.org; Tue, 30 Oct 2007 15:40:37 -0400 Received: from hpsmtp-eml05.kpnxchange.com ([213.75.38.105]) by hpsmtp-eml16.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 20:40:19 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 20:40:19 +0100 From: "Teco Boot" To: "'manet'" References: In-Reply-To: Subject: RE: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt Date: Tue, 30 Oct 2007 20:40:11 +0100 Message-ID: <009801c81b2c$af35d1b0$0da17510$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgVmnkLyTv50GFMTReUot9V41CHRQFitk5g Content-Language: nl X-OriginalArrivalTime: 30 Oct 2007 19:40:19.0532 (UTC) FILETIME=[B42B80C0:01C81B2C] X-Spam-Score: -1.0 (-) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org The packetbb-10 version is updated for type/fulltype/type-extension. Recap: - msg-type is 8-bit field - tlv-type is 8-bit, the thastypeext indicates the 8-bit tlv-type-ext is present - tlv-fulltype = 256 * + tlv-type-ext Now the text could be somewhat confusing, when the word type is being used. In the msg-type context, there is no problem. In the tlv-type or tlv-fulltype context, the text needs some reviewing. For example, the IANA section is not clear to me (or it could be old text for type/subtype that needs editing). I found some other ambiguous text, e.g. 5.5. page 19 line 7: "TLV with a specific type" It should be fulltype and not type (I guess). On tlv-type-ext, page 17 line 5 mentions " is specifying an extension of the TLV type (???), specific to the TLV type (???) and kind (i.e. packet, message, or address block TLV)". I don't know what is meant here, I hope we kicked out subtypes. Another issue is that we have gaps in the tlv-fulltypes: 0: reserved 1 - 255: ??? 256: some constraints 257 - 511: ??? 512: some constraints .. .. .. - 2047: ??? 2048: other constraints 2049 - 2303: ??? 2404: other constraints ... I could have made some mistakes here, but that is what is wrong here. A solution would be using tlv-fulltype = tlv-type + 256 * < tlv-type-ext >. Now the text in the IANA section doesn't need that much updates. All tlv-types are an overlay of lower 256 tlv-fulltypes (range: 0 to 255) and have the specified constraints. I think usage of the higher numbers are less restricted (to be verified). But IANA should register the full range, unless specified otherwise. Maybe this proposal has some unwanted effects on the ordering issue. Teco. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 06:50:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InB5x-000499-4u; Wed, 31 Oct 2007 06:46:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InB5v-00048o-CY for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 06:46:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InB5u-00048K-VR for manet@ietf.org; Wed, 31 Oct 2007 06:46:42 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InB5j-0006C6-18 for manet@ietf.org; Wed, 31 Oct 2007 06:46:40 -0400 Received: by nf-out-0910.google.com with SMTP id d21so77695nfb for ; Wed, 31 Oct 2007 03:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Gsr5mwlDxTJzYADZSR1mv69L3u5QPziOCOGcpzI/JCw=; b=PrUZ8Fx3g0Bi/8IuvPwf1+Z114KEu/1lFL2lYbXHOV6oEtlTP7Mqzws5oNkrFvB6c7YMe5y04wDbZ6kZ5zLLHvbVHuVoYYtw7jiGsUSVaReC+ZwpCp+crYZYKoFo6bOmEudZDo5/ZQWbyy5+2PF/Rmrul9pDnKrA9LlLqmgXaV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ODbMxQSxjNTk2SFAjpnpo7CXjKEMZZ/IMtxCwxBBei5ktlOb2LoMu4dvVBuWr+QiuOQ+RCnpctzNFyG0U3HI2KunrWi+ssGnk9jvLBAehC+1nl64e8eq+AUA/6/1P5wzKOFiz67m7KpOKe4IZmk6+tTqRYrH2gQyA+NYX71eoMg= Received: by 10.78.147.6 with SMTP id u6mr5992954hud.1193827544757; Wed, 31 Oct 2007 03:45:44 -0700 (PDT) Received: by 10.78.33.7 with HTTP; Wed, 31 Oct 2007 03:45:44 -0700 (PDT) Message-ID: <374005f30710310345x432a6a6dk82546060d6a2b2a7@mail.gmail.com> Date: Wed, 31 Oct 2007 16:15:44 +0530 From: "Ian Chakeres" To: "Teco Boot" Subject: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt In-Reply-To: <009401c81b19$29a04200$7ce0c600$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <009401c81b19$29a04200$7ce0c600$@nl> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org All our WG protocols currently use UDP, but several people have expressed that in the future we might want to migrate the protocols to use an IP protocol number. I see these two options as complementary and not necessarily competing. Teco & everyone, do you have a strong preference to NOT allocate an IP_PROTO number? I have added the IP_PROTO allocation on behalf of the several parties (including an AD) who have expressed interest. Thanks. Ian On 10/30/07, Teco Boot wrote: > > Second, during IETF LC & IESG review there were a few questions asking > > why we were not allocating an IP protocol number. In response to this > > request, I have added a request for an IP protocol number. This will > > allow us to advance our protocols from UDP to an IP protocol number in > > the future. > Teco: > 1) I think this topic was discussed on MANET ML and the outcome was there > was no need for requesting an IP_PROTO number. > 2) I do not like requesting an UDP port number AND an IP_PROTO number. A STD > protocol shall pick one and shall not leave this open to . _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 08:16:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InCRK-0004he-8f; Wed, 31 Oct 2007 08:12:54 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InCRI-0004hO-1Y for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 08:12:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InCRH-0004Ws-89 for manet@ietf.org; Wed, 31 Oct 2007 08:12:51 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InCR7-0001Zy-Sf for manet@ietf.org; Wed, 31 Oct 2007 08:12:47 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9VCBu9t007949 for ; Wed, 31 Oct 2007 12:11:56 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9VCBuTW023990 for ; Wed, 31 Oct 2007 12:11:56 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 31 Oct 2007 12:11:55 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Oct 2007 12:11:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Wed, 31 Oct 2007 12:11:54 -0000 Message-ID: In-Reply-To: <009401c81b19$29a04200$7ce0c600$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Thread-Index: AcgXjL1eyBpNgua4SoG8t5A9wZHSuQDi36PAACezBhA= References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <009401c81b19$29a04200$7ce0c600$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ian Chakeres" , "manet" X-OriginalArrivalTime: 31 Oct 2007 12:11:55.0714 (UTC) FILETIME=[3AA86A20:01C81BB7] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Teco: > 1) I think this topic was discussed on MANET ML and the outcome was there > was no need for requesting an IP_PROTO number. As I recall, it was the ADs who suggested this. Ian, is that correct? ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 08:22:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InCZA-00042r-AG; Wed, 31 Oct 2007 08:21:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InCZ7-00042R-Uh for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 08:20:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InCZ7-0003n1-Kd for manet@ietf.org; Wed, 31 Oct 2007 08:20:57 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InCYr-00021h-K9 for manet@ietf.org; Wed, 31 Oct 2007 08:20:48 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9VCKImH019434 for ; Wed, 31 Oct 2007 12:20:18 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9VCKI45022904 for ; Wed, 31 Oct 2007 12:20:18 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 31 Oct 2007 12:20:18 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Oct 2007 12:20:17 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt Date: Wed, 31 Oct 2007 12:20:17 -0000 Message-ID: In-Reply-To: <009801c81b2c$af35d1b0$0da17510$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt Thread-Index: AcgVmnkLyTv50GFMTReUot9V41CHRQFitk5gACSKqoA= References: <009801c81b2c$af35d1b0$0da17510$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "manet" X-OriginalArrivalTime: 31 Oct 2007 12:20:17.0849 (UTC) FILETIME=[65F42290:01C81BB8] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > In the tlv-type or tlv-fulltype context, the text needs some reviewing. Thanks for those comments. I don't have the draft in front of me, but we'll take a look. > I hope we kicked out subtypes. Type extension is subtype. There was a preference for changing the name (actually I preferred subtype, but not strongly). > Another issue is that we have gaps in the tlv-fulltypes: I really don't understand what you are suggesting here. I don't recognise what you are saying at all. > A solution would be using tlv-fulltype =3D tlv-type + 256 * < tlv-type-ext >. No, that's exactly what we don't want to do. What we have is exactly what we mean. When you allocate a type you get a sequence of 256 continuous fulltypes. Typically you only want one, and reserve the rest. Sometimes you want more. But these are not meant to be 65536 independent types, they are 256 types, each allowing up to 256 possibilities. > Maybe this proposal has some unwanted effects on the ordering issue. What we have is what we intend. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 09:03:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDCs-00069G-8E; Wed, 31 Oct 2007 09:02:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InDCq-000699-1r for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 09:02:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDCp-00068z-7K for manet@ietf.org; Wed, 31 Oct 2007 09:01:59 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InDCj-0003s9-0v for manet@ietf.org; Wed, 31 Oct 2007 09:01:59 -0400 Received: by nf-out-0910.google.com with SMTP id d21so104805nfb for ; Wed, 31 Oct 2007 06:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=BulzVtX/u/nS7aRyClQJCZ41hsCO4n5YzSlZwDoZv9Y=; b=SmM1Y736JhL3p3Mwk8zLdXFnKfoZsiMfs//wphQve6sfXAybmyBCxoTrPMOUW6Np9Wdovd3sP7rUmVmyBToEXls8ati/XMxvkv1qNWGkPIXWLGEmRc+T2D3rwsl/Ct2PzfCd6JeKBtyYzG+urZP5a/X1Dp2ReS3C47p+VkH/oY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rNLYa1FwX3OPiyeX3N0Jk2ucsQI1rasYcIooHj8JiYrmfWqztXFV9mrIlB4OKHN/fpFV/6xNzGx3hu/i/MTX4PDdSdOyX6VeKHFAVOEATeFm+OoiiOKwTqUGPZZ4nIO0OyrEOmtjGm/EoLtRBg21BUuhqYKkjRKj0lx5zeb7IJc= Received: by 10.78.97.7 with SMTP id u7mr6094303hub.1193835684863; Wed, 31 Oct 2007 06:01:24 -0700 (PDT) Received: by 10.78.33.7 with HTTP; Wed, 31 Oct 2007 06:01:24 -0700 (PDT) Message-ID: <374005f30710310601p2c106b4o1b084428f1d9ce3f@mail.gmail.com> Date: Wed, 31 Oct 2007 18:31:24 +0530 From: "Ian Chakeres" To: "Dearlove, Christopher (UK)" Subject: Re: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <009801c81b2c$af35d1b0$0da17510$@nl> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Chris, I was under the impression that in the future we could allocate a larger number of explicit types, although our current specifications would use the rule you described (1type and 256reserved extended types). Please correct me if I'm wrong. Ian On 10/31/07, Dearlove, Christopher (UK) wrote: > > > In the tlv-type or tlv-fulltype context, the text needs some > reviewing. > > Thanks for those comments. I don't have the draft in front of me, > but we'll take a look. > > > I hope we kicked out subtypes. > > Type extension is subtype. There was a preference for changing the > name (actually I preferred subtype, but not strongly). > > > Another issue is that we have gaps in the tlv-fulltypes: > > I really don't understand what you are suggesting here. I don't > recognise what you are saying at all. > > > A solution would be using tlv-fulltype = tlv-type + 256 * < > tlv-type-ext >. > > No, that's exactly what we don't want to do. What we have is exactly > what we mean. When you allocate a type you get a sequence of 256 > continuous > fulltypes. Typically you only want one, and reserve the rest. Sometimes > you want more. But these are not meant to be 65536 independent types, > they > are 256 types, each allowing up to 256 possibilities. > > > Maybe this proposal has some unwanted effects on the ordering issue. > > What we have is what we intend. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 09:14:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDNa-0004fP-N3; Wed, 31 Oct 2007 09:13:06 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InDNY-0004cB-NT for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 09:13:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDNY-0004Xb-Cq for manet@ietf.org; Wed, 31 Oct 2007 09:13:04 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InDNU-0003he-Fj for manet@ietf.org; Wed, 31 Oct 2007 09:13:00 -0400 Received: (qmail 4128 invoked from network); 31 Oct 2007 14:12:57 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 31 Oct 2007 14:12:57 +0100 From: "Teco Boot" To: "'Ian Chakeres'" References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <009401c81b19$29a04200$7ce0c600$@nl> <374005f30710310345x432a6a6dk82546060d6a2b2a7@mail.gmail.com> In-Reply-To: <374005f30710310345x432a6a6dk82546060d6a2b2a7@mail.gmail.com> Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Wed, 31 Oct 2007 14:12:17 +0100 Message-ID: <003001c81bbf$bbbb31d0$33319570$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgbqzCs20MFYBTCQ2+Ck1bC55jYEQAEJl/g Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > Teco & everyone, do you have a strong preference to NOT allocate an > IP_PROTO number? I have added the IP_PROTO allocation on behalf of the > several parties (including an AD) who have expressed interest. I do NOT have any objections to requesting an IP_PROTO. I am STRONGLY AGAINST not defining which transport is to be used for "MANET". I think using UDP is acceptable. In RFC2119 wording, MANET protocols SHOULD use the "manet" UDP port and MANET protocols MAY use the "manet" IP protocol. When using the "manet" IP protocol, we have to add transport functionality in packetbb that was provided by UDP. Especially the datagram Length and Checksum fields in the UDP header shall have their replacements in packetbb pkt-header. Packet length can be signaled in pkt-size. I cannot find something for Checksum. In the packetbb specification, it MUST be noted that the MANET protocol MUST include and use the pkt-size and "pkt-checksum" fields when using native IP as transport. When adding a "pkt-checksum", we should discuss using a 32-bit field. On allocation, we could request the TCP_PORT also, although today no one needs it. Obviously, TCP is not a candidate for MANET; especially for the multicast part of it. But maybe someone needs this in the future. (e.g. ad-hoc BGP) Teco. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 09:16:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDP0-000643-EV; Wed, 31 Oct 2007 09:14:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InDOz-0005yY-2T for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 09:14:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDOy-0005yQ-Om for manet@ietf.org; Wed, 31 Oct 2007 09:14:32 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InDOs-0004VU-FT for manet@ietf.org; Wed, 31 Oct 2007 09:14:32 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9VDE6Ud012322 for ; Wed, 31 Oct 2007 13:14:10 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9VDE6wN026037 for ; Wed, 31 Oct 2007 13:14:06 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 31 Oct 2007 13:14:06 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Oct 2007 13:14:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt Date: Wed, 31 Oct 2007 13:14:02 -0000 Message-ID: In-Reply-To: <374005f30710310601p2c106b4o1b084428f1d9ce3f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt Thread-Index: AcgbvidSAQy7pLkwQQGcGh2t6lZ8zAAALDMg References: <009801c81b2c$af35d1b0$0da17510$@nl> <374005f30710310601p2c106b4o1b084428f1d9ce3f@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Ian Chakeres" X-OriginalArrivalTime: 31 Oct 2007 13:14:04.0598 (UTC) FILETIME=[E93EF560:01C81BBF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian, yes. You are right we can do either. But we need it the way round it is in order to be able to do either. The basic rule is that you ask for a type, that defines a new 256 table. Each such table can have its own allocation rule. So yes, you could ask for a set of 256 type for miscellaneous functions, and use it for 256 separate things. But you can also allocate it for 256 related things. or (as we currently have) allocate 0 and leave 1-255 reserved. =20 -----Original Message----- From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 Sent: 31 October 2007 13:01 To: Dearlove, Christopher (UK) Cc: Teco Boot; manet Subject: Re: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Chris, I was under the impression that in the future we could allocate a larger number of explicit types, although our current specifications would use the rule you described (1type and 256reserved extended types). Please correct me if I'm wrong. Ian On 10/31/07, Dearlove, Christopher (UK) wrote: > > > In the tlv-type or tlv-fulltype context, the text needs some > reviewing. > > Thanks for those comments. I don't have the draft in front of me, > but we'll take a look. > > > I hope we kicked out subtypes. > > Type extension is subtype. There was a preference for changing the > name (actually I preferred subtype, but not strongly). > > > Another issue is that we have gaps in the tlv-fulltypes: > > I really don't understand what you are suggesting here. I don't > recognise what you are saying at all. > > > A solution would be using tlv-fulltype =3D tlv-type + 256 * < > tlv-type-ext >. > > No, that's exactly what we don't want to do. What we have is exactly > what we mean. When you allocate a type you get a sequence of 256 > continuous > fulltypes. Typically you only want one, and reserve the rest. Sometimes > you want more. But these are not meant to be 65536 independent types, > they > are 256 types, each allowing up to 256 possibilities. > > > Maybe this proposal has some unwanted effects on the ordering issue. > > What we have is what we intend. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 09:23:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDWl-0004Ce-7E; Wed, 31 Oct 2007 09:22:35 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InDWk-0004B6-9n for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 09:22:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDWj-0003zw-WC for manet@ietf.org; Wed, 31 Oct 2007 09:22:34 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InDWU-00052F-VY for manet@ietf.org; Wed, 31 Oct 2007 09:22:25 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9VDLlkM027948 for ; Wed, 31 Oct 2007 13:21:47 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9VDLkXu031106 for ; Wed, 31 Oct 2007 13:21:46 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 31 Oct 2007 13:21:47 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Oct 2007 13:21:47 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Wed, 31 Oct 2007 13:21:46 -0000 Message-ID: In-Reply-To: <003001c81bbf$bbbb31d0$33319570$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Thread-Index: AcgbqzCs20MFYBTCQ2+Ck1bC55jYEQAEJl/gAAEYi4A= References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <009401c81b19$29a04200$7ce0c600$@nl><374005f30710310345x432a6a6dk82546060d6a2b2a7@mail.gmail.com> <003001c81bbf$bbbb31d0$33319570$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ian Chakeres" X-OriginalArrivalTime: 31 Oct 2007 13:21:47.0107 (UTC) FILETIME=[FCEC3B30:01C81BC0] X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Just to be clear, I don't have any strong feelings about this either way (UDP or native IP). > When using the "manet" IP protocol, we have to add transport functionality > in packetbb that was provided by UDP. Especially the datagram Length and > Checksum fields in the UDP header shall have their replacements in packetbb > pkt-header. Packet length can be signaled in pkt-size. I cannot find > something for Checksum. If you need a checksum (which is a pretty crude form of error detection code) at the network or transport layer then UDP will do. But there are plenty of data link layers that do a much better job in this are, making this a bit redundant at the transport layer. > In the packetbb specification, it MUST be noted that the MANET protocol MUST > include and use the pkt-size and "pkt-checksum" fields when using native IP > as transport. I do not agree with putting a checksum into packetbb. If you need it, do it with UDP. You may not need it, even without UDP. And > When adding a "pkt-checksum", we should discuss using a 32-bit field. That's one very good reason why it doesn't belong in packetbb. 16 bits or 32? Checksum or CRC? Which generator polynomial? Which way to shift? ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 09:30:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDdm-0003t5-CB; Wed, 31 Oct 2007 09:29:50 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InDdl-0003rx-0c for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 09:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDdk-0003jw-Fj for manet@ietf.org; Wed, 31 Oct 2007 09:29:48 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InDdV-0005Ln-P4 for manet@ietf.org; Wed, 31 Oct 2007 09:29:39 -0400 Received: by nf-out-0910.google.com with SMTP id d21so111902nfb for ; Wed, 31 Oct 2007 06:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=G2rap7/NT7LC16dr26tee9fsn+EI4vQ0n/r1K+artus=; b=CShN/Xh3PHLWmqm7o31JnAWbeSQQHcf2gZcdOvUdZk4YjKwLE7frO3h7RrLlzhs0tR4tu18MuncdAix6paVJiiykAsSJObfvr+Z9nU1FLKYgA4EglnPiWTgxsr8Ds0KM7DVC4iIEknRRIqjYzzSc9SKnrQIVE63oAoDj6EBo8Uw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UTlik/RVFsbUcv5YO9RJypu3Wk8JrZESZUNBzfJOJZMFag3Rc7Ry2LCiZAoLZ5fnL8cZavz43iPUVFvvHbIxV17WCPLwk8n888VjCSQ2svR9sXXdR2oWQGkrraoIVOucwIoZwRh2I2y8UGD97KLXTUKp+ho9NH0/cod2BygZbSo= Received: by 10.78.185.15 with SMTP id i15mr6125743huf.1193837353781; Wed, 31 Oct 2007 06:29:13 -0700 (PDT) Received: by 10.78.33.7 with HTTP; Wed, 31 Oct 2007 06:29:13 -0700 (PDT) Message-ID: <374005f30710310629i3224ed8cy4cc94dc3c71f491e@mail.gmail.com> Date: Wed, 31 Oct 2007 18:59:13 +0530 From: "Ian Chakeres" To: "Dearlove, Christopher (UK)" Subject: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <009401c81b19$29a04200$7ce0c600$@nl> <374005f30710310345x432a6a6dk82546060d6a2b2a7@mail.gmail.com> <003001c81bbf$bbbb31d0$33319570$@nl> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org In the future when we specify operation using an IP_PROTO, we will likely need some additional TLV-types to assist. For example, a pkt-TLV-type for CRC or FEC. I do not think these need to go into the PacketBB spec. They can be written in the future and normatively reference PacketBB, like TimeTLV. Ian On 10/31/07, Dearlove, Christopher (UK) wrote: > > Just to be clear, I don't have any strong feelings about this > either way (UDP or native IP). > > > When using the "manet" IP protocol, we have to add transport > functionality > > in packetbb that was provided by UDP. Especially the datagram Length > and > > Checksum fields in the UDP header shall have their replacements in > packetbb > > pkt-header. Packet length can be signaled in pkt-size. I cannot find > > something for Checksum. > > If you need a checksum (which is a pretty crude form of error detection > code) at the network or transport layer then UDP will do. But there are > plenty of data link layers that do a much better job in this are, making > this a bit redundant at the transport layer. > > > In the packetbb specification, it MUST be noted that the MANET > protocol MUST > > include and use the pkt-size and "pkt-checksum" fields when using > native IP > > as transport. > > I do not agree with putting a checksum into packetbb. If you need > it, do it with UDP. You may not need it, even without UDP. And > > > When adding a "pkt-checksum", we should discuss using a 32-bit field. > > That's one very good reason why it doesn't belong in packetbb. > 16 bits or 32? Checksum or CRC? Which generator polynomial? > Which way to shift? > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 09:32:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDgB-0005mq-VI; Wed, 31 Oct 2007 09:32:19 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InDg9-0005me-QS for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 09:32:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDg8-0005mG-IQ for manet@ietf.org; Wed, 31 Oct 2007 09:32:16 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InDg7-0004g2-R2 for manet@ietf.org; Wed, 31 Oct 2007 09:32:16 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9VDWC8x004629 for ; Wed, 31 Oct 2007 13:32:12 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9VDWBvx005830 for ; Wed, 31 Oct 2007 13:32:11 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 31 Oct 2007 13:32:12 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Oct 2007 13:32:11 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt Date: Wed, 31 Oct 2007 13:32:11 -0000 Message-ID: In-Reply-To: <009801c81b2c$af35d1b0$0da17510$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt Thread-Index: AcgVmnkLyTv50GFMTReUot9V41CHRQFitk5gACbudyA= References: <009801c81b2c$af35d1b0$0da17510$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "manet" X-OriginalArrivalTime: 31 Oct 2007 13:32:11.0853 (UTC) FILETIME=[714CE7D0:01C81BC2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres gave me an interpretation of what he thinks you were meaning here. This is my interpretation of his interpretation, hopefully it will be useful. We reserve a block of types (a type is 8 bits) for TLVs that there's a good reason to go first. But the ordering constraints are in terms of fulltype (16 bits) as it explicitly says. So obviously when we are allocating 8 types to go early, that's allowing for a possible 8x256 fulltypes to go early. A specific example may be a packet or message authentication TLV. Here I would expect the natural approach to be that IANA is asked to allocate (say) type 1 for this. Of course there are many possible signature algorithms, and that's exactly what the type extension would obviously be used for, building up a table of those algorithms. Note that such a TLV doesn't absolutely need to go early. But there's an argument that this would be good to verify before parsing (or absolutely minimal parsing) - type 0 might be better, you can find TLV type 0 in a TLV block, or whether it is absent, really easily (an argument for sorting). I just used 1 rather than 0 above as an illustration. This would be to minimise certain DOS attacks. -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 30 October 2007 19:40 To: 'manet' Subject: RE: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt=20 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 The packetbb-10 version is updated for type/fulltype/type-extension. Recap: - msg-type is 8-bit field - tlv-type is 8-bit, the thastypeext indicates the 8-bit tlv-type-ext is present - tlv-fulltype =3D 256 * + tlv-type-ext Now the text could be somewhat confusing, when the word type is being used. In the msg-type context, there is no problem.=20 In the tlv-type or tlv-fulltype context, the text needs some reviewing. For example, the IANA section is not clear to me (or it could be old text for type/subtype that needs editing). I found some other ambiguous text, e.g. 5.5. page 19 line 7: "TLV with a specific type" It should be fulltype and not type (I guess). On tlv-type-ext, page 17 line 5 mentions " is specifying an extension of the TLV type (???), specific to the TLV type (???) and kind (i.e. packet, message, or address block TLV)". I don't know what is meant here, I hope we kicked out subtypes. Another issue is that we have gaps in the tlv-fulltypes: 0: reserved 1 - 255: ??? 256: some constraints 257 - 511: ??? 512: some constraints .. .. .. - 2047: ??? 2048: other constraints 2049 - 2303: ??? 2404: other constraints ... I could have made some mistakes here, but that is what is wrong here. A solution would be using tlv-fulltype =3D tlv-type + 256 * < tlv-type-ext >. Now the text in the IANA section doesn't need that much updates. All tlv-types are an overlay of lower 256 tlv-fulltypes (range: 0 to 255) and have the specified constraints. I think usage of the higher numbers are less restricted (to be verified). But IANA should register the full range, unless specified otherwise. Maybe this proposal has some unwanted effects on the ordering issue. Teco. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 09:37:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDkH-0007N0-LY; Wed, 31 Oct 2007 09:36:33 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InDkF-0007Ms-UO for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 09:36:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDkF-00079s-3H for manet@ietf.org; Wed, 31 Oct 2007 09:36:31 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InDk5-0005f5-Ps for manet@ietf.org; Wed, 31 Oct 2007 09:36:23 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9VDZvH2008027 for ; Wed, 31 Oct 2007 13:35:57 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9VDZuqm015257 for ; Wed, 31 Oct 2007 13:35:56 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 31 Oct 2007 13:35:57 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Oct 2007 13:35:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Wed, 31 Oct 2007 13:35:56 -0000 Message-ID: In-Reply-To: <374005f30710310629i3224ed8cy4cc94dc3c71f491e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Thread-Index: AcgbwguF10vvXNuZTRmEWXM6X9NIBAAAG9sg References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <009401c81b19$29a04200$7ce0c600$@nl> <374005f30710310345x432a6a6dk82546060d6a2b2a7@mail.gmail.com> <003001c81bbf$bbbb31d0$33319570$@nl> <374005f30710310629i3224ed8cy4cc94dc3c71f491e@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Ian Chakeres" X-OriginalArrivalTime: 31 Oct 2007 13:35:57.0295 (UTC) FILETIME=[F7AC9FF0:01C81BC2] X-Spam-Score: -4.0 (----) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I agree with Ian. When I said not in packetbb, I didn't mean not in the packetbb structure, just not in the packetbb base specification. In TLVs, very little is not allowed. Although it would be good to find out how much use the UDP checksum really is these days. In practice is it essentially redundant based on link layer error control, or is it still a valuable part of the IP protocol stack? (I have no idea, but would find any data on the subject interesting.) =20 -----Original Message----- From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 Sent: 31 October 2007 13:29 To: Dearlove, Christopher (UK) Cc: Teco Boot; manet Subject: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 In the future when we specify operation using an IP_PROTO, we will likely need some additional TLV-types to assist. For example, a pkt-TLV-type for CRC or FEC. I do not think these need to go into the PacketBB spec. They can be written in the future and normatively reference PacketBB, like TimeTLV. Ian On 10/31/07, Dearlove, Christopher (UK) wrote: > > Just to be clear, I don't have any strong feelings about this > either way (UDP or native IP). > > > When using the "manet" IP protocol, we have to add transport > functionality > > in packetbb that was provided by UDP. Especially the datagram Length > and > > Checksum fields in the UDP header shall have their replacements in > packetbb > > pkt-header. Packet length can be signaled in pkt-size. I cannot find > > something for Checksum. > > If you need a checksum (which is a pretty crude form of error detection > code) at the network or transport layer then UDP will do. But there are > plenty of data link layers that do a much better job in this are, making > this a bit redundant at the transport layer. > > > In the packetbb specification, it MUST be noted that the MANET > protocol MUST > > include and use the pkt-size and "pkt-checksum" fields when using > native IP > > as transport. > > I do not agree with putting a checksum into packetbb. If you need > it, do it with UDP. You may not need it, even without UDP. And > > > When adding a "pkt-checksum", we should discuss using a 32-bit field. > > That's one very good reason why it doesn't belong in packetbb. > 16 bits or 32? Checksum or CRC? Which generator polynomial? > Which way to shift? > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 10:26:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InESy-00073A-4U; Wed, 31 Oct 2007 10:22:44 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InESw-00072U-C8 for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 10:22:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InESv-00072L-W3 for manet@ietf.org; Wed, 31 Oct 2007 10:22:42 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InESu-00079f-Ip for manet@ietf.org; Wed, 31 Oct 2007 10:22:41 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9VELtfg012404; Wed, 31 Oct 2007 16:22:26 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 16:22:22 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 09:22:20 -0500 Received: from [172.18.141.138] ([172.18.141.138]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 09:22:20 -0500 Message-ID: <47288F9B.20903@nokia.com> Date: Wed, 31 Oct 2007 07:22:19 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Thomas Clausen Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. References: <8194AB5B-34B3-4AB7-BC6D-005449F2448B@computer.org> In-Reply-To: <8194AB5B-34B3-4AB7-BC6D-005449F2448B@computer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 14:22:20.0198 (UTC) FILETIME=[7269EC60:01C81BC9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Thomas, Thanks for the long email. I have some follow-up comments... ext Thomas Clausen wrote: > > It should be noted that the choice of which TLV "kind" to use > (multivalue, range-indexed, ....) when generating a message is not > mandated by packetbb, since it depends on the given deployment, the > protocol(s) etc. Yes, noted and agreed. > The idea of collecting multiple messages in a packet and transmit > these in one transmission is to reduce the MAC overhead -- something > which has been observed to have a measurable impact when running > MANETs -- but which will not be discussed further in this email. I reckon this function would be better situated in the MAC layer itself, but I understand this topic is not the main point of your email. However, I do think the solution as currently specified is a layer violation and relatively difficult to put into practice. One might ask why aggregation is better for relatively sparse control packet when it does not admit the more likely gains from bundling with data traffic. > > Now, let us look at the constraints. The specification of packetbb > lists a number of constraints that must be satisfied when including > TLVs in a given TLV block. For now, I will only discuss address block > TLV blocks (i.e. TLV blocks associated to addres-blocks), but I will > get back to message- and packet-TLV blocks later. > > The constraints as given and as discussed in recent emails on this > mailing list are, essentially, that within an address block TLV block: > > o TLVs must be sorted in non-descending order according to their > type; > o no two TLVs of the same type may be associated with the same > address. Up until this point in your note, there has not been a shred of discussion to support the need for this. Reading through the rest of it, one still does not find any supportive discussion. > > I will discuss these in the context of address block tlv blocks, > however first I think that it is important to note one thing -- which > is essentially a repeat from the above part of this email: > > o packetbb is concerned only with the encoding, not with the > processing, specifically > o the processing of entities (addresses) and attributes (that > which is associated to > addresses through TLVs), including the order of processing, is > neither suggested > nor mandated by packetbb. Noted. Does not support ordering requirement. > > ... packetbb parsing comes before protocol processing, and protocol > processing is concerned only with the decoded data structure -- not > how this data structure happened to be encoded for transmission. Noted. Does not support ordering requirement. > > > > What is important to extract from the above is that, concerning packetbb: > > o the order in which TLVs are encoded by packetbb for transmission is > independent from the order in which TLVs are processed by a > protocol > specification; > > o a protocol specification SHOULD specify, assuming that the > processing > order is important, what this processing order is. Noted. Does not support ordering requirement. > > I will touch upon the benefits of mandating an encoding-order in > packetbb a bit later in this email, since it should become clearer > what they are once the second constraint -- uniqueness -- has been > discussed. > > The second constraint for address-block tlv-blocks is that: > > o no two TLVs of the same type may be associated with the same > address. > > <... example elided ...> > > So, which TLV is "last"? If we go by "last TLV per address", then we > will end up using some of (i) and some of (ii), but certainly not all > of (i) nor all of (ii) -- leading to partial and incoherent use of the > information in the TLVs. This is because the type values in the TLVs you define in the example are mutually exclusive. A node may occupy only one of the STATEs in your TLV, and it may only have a single cost [presumably the cost metric has already been previously agreed upon, and so on...] > > So, the "pick the first/last TLV" solution, while perhaps > disambiguifying matters for a single address do not solve the problem > -- the protocol receiving the data structure resulting from parsing > still becomes exposed to incoherent information. The constraint of "no > two TLVs of the same type may be associated with the same address" > does solve this. Great! Then you should enable this to be used for TLVs where it is needed, without mandating it for all address TLVs. For instance, as has been suggested many times, some typed values for addresses would NOT have the uniqueness requirement. Some addresses may need to be described by multiple values from the same type space, for some types of information. > > Now, I carefully mentioned that I would discuss this for > address-block-tlv-blocks, and then return to message-tlv-blocks and > packet-tlv-blocks later. As can be noted from the packetbb I-D, the > constraint of uniqueness is relaxed for message- and packet- > tlv-blocks, noting that: > > o Packet and message TLVs MUST be defined so as to indicate whether > two TLVs with the same tlv-fulltype are, or are not, allowed in > the same packet or message TLV block, respectively. > > The reason that this is permissible in message- and packet- tlv-blocks > is, that tlvs in those tlv-blocks associate to one and only one > entity: the message or the packet. As such, while ambiguity still may > persist, the risk of "partial" or "incoherent" association (and, thus, > usage) of part of one and part of another tlv does not exist. As I understand it, this really destroys your point. For one thing, consider the follow sentence fragment, slightly reworded to refer to addresses: > tlvs in those tlv-blocks associate to one and only one entity: the address So, if I apply the same logic, any such tlv where the value is to be associated with a single address, is a good candidate for allowing a multiplicity of values. Also note that up until now, no justification has been provided for the ordering constraint. But, in point of fact, the constraint for applicability to a single address is quite arbitrary already and not necessary -- except, of course, for TLVs where the values are from a domain where uniqueness is sensible. > > The "uniqueness" constraint of address block TLVs is there for the > reason of ensuring non-ambiguity and coherence in the data structure > resulting from parsing an incoming message. These are characteristics that are _not_ naturally applicable to all types of information that would be of interest for addresses. > Keeping the TLVs within a TLV block ordered by TLV type means that > verifying (at both the sending side, prior to transmitting a message, > and on the receiving side during parsing but prior to presenting the > resulting data structure to the protocol) this uniqueness criteria can > be done in a single linear pass. ... fine, when uniqueness is desired, except of course unless the effort of sorting typically outweighs the effort of parsing. And, even so, it was never shown that sorting on the sending side is "better" than sorting on the receiving side! > Having the TLVs unordered would imply backtracking and maintaining > additional data structures. ... in fact, very similar to sorting... ... but all postulating that uniqueness is drastically important, which is, of course, unsupported by the evidence provided except for selected boolean or single-valued types. And even the evidence shown does not imply the need for sorting. > > I want to emphasise that the order of inclusion of TLVs in a TLV block > is not indicative or suggestive of the order of processing of the TLVs > within that TLV block, just as the order of inclusion of addresses > within an address block (or address blocks) is not indicative or > suggestive of the order of processing of these addresses. Indeed, such > is, if processing order is important, to be specified by the protocol > using packetbb. Noted. Does not support ordering requirement. > > An additional advantage of the ordering is, that if one is looking for > a specific TLV (e.g. a protocol or protocol extension where processing > the message is not worth it unless tlv type XXX is included) then one > can terminate parsing the message (or packet or address block) early, > i.e. once parsing encounters a tlv with type >XXX. While true, I have never seen this in practice (for valid TLVs). In fact, if such were the case, it would be a _lot_ smarter for the sender to just not send the superfluous data. In fact, if I were writing the protocol, sending such superfluous data would be strongly discouraged if not outright prohibited. It is difficult to make a general statement for this since there may indeed be cases where decorative/advisory TLVs are useful, but usually, by the time the packet has been received, the major costs have been incurred and scanning the TLVs is really in the noise. > A clear example hereof would be "do not process this message unless a > signature TLV is included". It has been pointed out that for that > reason it would be helpful if a range of TLV types were allocated > which "comes before everything else", and that guidelines be provided > to IANA as to how types from that range are assigned -- and this point > has been updated in the I-D. That signature block ought to be the last TLV anyway. > > A new I-D (draft-ietf-manet-packetbb-10.txt) has been submitted to the > IETF, in which: > > o a range of (the numerically first, in order to retain the > benefits of ordering) Basically, you still have not shown the benefits. > address-block-, message- and packet- TLV types are reserved for > assignment > where it is important that these "come before anything else", > as indicated in the > preceding paragraph) is specified; Such ordering can be imposed regardless of the numerical value of the type. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 11:10:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFA6-0000kr-8s; Wed, 31 Oct 2007 11:07:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InFA5-0000km-4V for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 11:07:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFA4-0000ke-Qi for manet@ietf.org; Wed, 31 Oct 2007 11:07:16 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InFA4-00018d-C3 for manet@ietf.org; Wed, 31 Oct 2007 11:07:16 -0400 Received: (qmail 13900 invoked from network); 31 Oct 2007 16:07:15 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 31 Oct 2007 16:07:14 +0100 From: "Teco Boot" To: "'Ian Chakeres'" , "'Dearlove, Christopher \(UK\)'" References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <009401c81b19$29a04200$7ce0c600$@nl> <374005f30710310345x432a6a6dk82546060d6a2b2a7@mail.gmail.com> <003001c81bbf$bbbb31d0$33319570$@nl> <374005f30710310629i3224ed8cy4cc94dc3c71f491e@mail.gmail.com> In-Reply-To: <374005f30710310629i3224ed8cy4cc94dc3c71f491e@mail.gmail.com> Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Wed, 31 Oct 2007 16:06:34 +0100 Message-ID: <004501c81bcf$b3169140$1943b3c0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgbwgdKrXPIjYVyRSyeNUAJnSPzMAADVEsw Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > In the future when we specify operation using an IP_PROTO, we will > likely need some additional TLV-types to assist. For example, a > pkt-TLV-type for CRC or FEC. I do not think these need to go into the > PacketBB spec. They can be written in the future and normatively > reference PacketBB, like TimeTLV. Anyway, we have to update the packetbb document for it. Right now, it is tailored for UDP and not for IP. Teco _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 11:13:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFFa-0005iU-3O; Wed, 31 Oct 2007 11:12:58 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InFFX-0005hP-VK for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 11:12:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFFX-0005h4-Kt for manet@ietf.org; Wed, 31 Oct 2007 11:12:55 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InFFX-0001Ne-6b for manet@ietf.org; Wed, 31 Oct 2007 11:12:55 -0400 Received: (qmail 18281 invoked from network); 31 Oct 2007 16:12:53 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 31 Oct 2007 16:12:52 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Ian Chakeres'" References: <009801c81b2c$af35d1b0$0da17510$@nl> <374005f30710310601p2c106b4o1b084428f1d9ce3f@mail.gmail.com> In-Reply-To: Subject: RE: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt Date: Wed, 31 Oct 2007 16:12:12 +0100 Message-ID: <004601c81bd0$7c92c480$75b84d80$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgbvidSAQy7pLkwQQGcGh2t6lZ8zAAALDMgAADdxCA= Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org More on type / fulltype: Why can't I get allocated just a few fulltypes? (less than 256) What if many others request this? What will happen when we all use some random numbers in the 128-255 range (private/local) for different purposes, in the same MANET? Teco. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 11:40:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFcb-0002Uk-Ei; Wed, 31 Oct 2007 11:36:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InFca-0002Tt-Lm for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 11:36:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFca-0002OW-C2 for manet@ietf.org; Wed, 31 Oct 2007 11:36:44 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InFcL-0003rp-Aj for manet@ietf.org; Wed, 31 Oct 2007 11:36:35 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9VFZcZr018641 for ; Wed, 31 Oct 2007 15:35:38 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9VFZdwe026569 for ; Wed, 31 Oct 2007 15:35:39 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 31 Oct 2007 15:35:38 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Oct 2007 15:35:38 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Wed, 31 Oct 2007 15:35:37 -0000 Message-ID: In-Reply-To: <004501c81bcf$b3169140$1943b3c0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Thread-Index: AcgbwgdKrXPIjYVyRSyeNUAJnSPzMAADVEswAAEDQ2A= References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <009401c81b19$29a04200$7ce0c600$@nl> <374005f30710310345x432a6a6dk82546060d6a2b2a7@mail.gmail.com> <003001c81bbf$bbbb31d0$33319570$@nl> <374005f30710310629i3224ed8cy4cc94dc3c71f491e@mail.gmail.com> <004501c81bcf$b3169140$1943b3c0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ian Chakeres" X-OriginalArrivalTime: 31 Oct 2007 15:35:38.0370 (UTC) FILETIME=[AFEDB620:01C81BD3] X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > Anyway, we have to update the packetbb document for it. Right now, it is > tailored for UDP and not for IP. Actually, no it isn't. The letters "UDP" do not appear anywhere in it. They used to (but only as an example), now they don't appear at all. This was for this very reason. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 11:44:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFix-0001YW-Dq; Wed, 31 Oct 2007 11:43:19 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InFiv-0001V3-Nf for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 11:43:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFiv-0001T0-Ar for manet@ietf.org; Wed, 31 Oct 2007 11:43:17 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InFiu-0002gS-PB for manet@ietf.org; Wed, 31 Oct 2007 11:43:17 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9VFhFde015124 for ; Wed, 31 Oct 2007 15:43:15 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9VFhF49031719 for ; Wed, 31 Oct 2007 15:43:15 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 31 Oct 2007 15:43:14 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Oct 2007 15:43:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt Date: Wed, 31 Oct 2007 15:43:13 -0000 Message-ID: In-Reply-To: <004601c81bd0$7c92c480$75b84d80$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt Thread-Index: AcgbvidSAQy7pLkwQQGcGh2t6lZ8zAAALDMgAADdxCAABFqecA== References: <009801c81b2c$af35d1b0$0da17510$@nl> <374005f30710310601p2c106b4o1b084428f1d9ce3f@mail.gmail.com> <004601c81bd0$7c92c480$75b84d80$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ian Chakeres" X-OriginalArrivalTime: 31 Oct 2007 15:43:14.0254 (UTC) FILETIME=[BFA816E0:01C81BD4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > Why can't I get allocated just a few fulltypes? (less than 256) You can. You request a new type registry to be open, with rules on how to allocate further fulltypes in it. You will probably only actually want some (often only one, but maybe more) right now, with rules on how to get more. We could pack logically unrelated fulltypes together under one type. We'd do that if we were running short. But single octet types are more efficient, and while we have a limited number of protocols, we can afford to use them as we are. > What if many others request this? If packetbb is so successful that we run into shortage of TLV types/fulltypes, I will be gratifyingly surprised. > What will happen when we all use some random numbers in the 128-255 range > (private/local) for different purposes, in the same MANET? There's an inherent contradiction between "private/local" and "we all". You could ask the same question about any private/local set of allocations (UDP ports, IP addresses etc.). If you are clashing with someone else it's not private/local. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 11:51:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFpg-0001ma-WF; Wed, 31 Oct 2007 11:50:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InFpb-0001eC-8c for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 11:50:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFpa-0001ZI-SC for manet@ietf.org; Wed, 31 Oct 2007 11:50:10 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InFpL-0002xJ-7o for manet@ietf.org; Wed, 31 Oct 2007 11:49:55 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9VFnrRq018250 for ; Wed, 31 Oct 2007 15:49:53 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9VFnsgh003749 for ; Wed, 31 Oct 2007 15:49:54 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 31 Oct 2007 15:49:53 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Oct 2007 15:49:53 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Regarding packetbb constraints on ordering and uniqueness. Date: Wed, 31 Oct 2007 15:49:52 -0000 Message-ID: In-Reply-To: <47288F9B.20903@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Regarding packetbb constraints on ordering and uniqueness. Thread-Index: AcgbyfqrCYIbdPEDSby6OhR0TQ8jNQACtipQ References: <8194AB5B-34B3-4AB7-BC6D-005449F2448B@computer.org> <47288F9B.20903@nokia.com> From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , "ext Thomas Clausen" X-OriginalArrivalTime: 31 Oct 2007 15:49:53.0447 (UTC) FILETIME=[AD981B70:01C81BD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org >> The idea of collecting multiple messages in a packet and transmit=20 >> these in one transmission is to reduce the MAC overhead > I do think the solution as currently > specified is a layer violation and relatively difficult to put into > practice. We do it in OLSRv1. It works, lots of people use it. OLSRv2, and hence since we spun it out, packetbb, is using already proven technology. This is self-evidently therefore not difficult to put into practice. As for the rest of your points, I'm not going to go through it all again. It has been pointed out many times how ordering permits one-pass easy verification of non-duplication. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 12:16:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InGE2-0008RR-MG; Wed, 31 Oct 2007 12:15:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InGE0-0008R0-R5 for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 12:15:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InGE0-0008Qs-HY for manet@ietf.org; Wed, 31 Oct 2007 12:15:24 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InGDv-0005ob-1M for manet@ietf.org; Wed, 31 Oct 2007 12:15:24 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9VGEnVC032617; Wed, 31 Oct 2007 18:15:08 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 18:14:55 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 11:14:49 -0500 Received: from [172.18.141.138] ([172.18.141.138]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 11:14:48 -0500 Message-ID: <4728A9F5.5040204@nokia.com> Date: Wed, 31 Oct 2007 09:14:45 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "ext Dearlove, Christopher (UK)" Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. References: <8194AB5B-34B3-4AB7-BC6D-005449F2448B@computer.org> <47288F9B.20903@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 16:14:48.0937 (UTC) FILETIME=[28F9C590:01C81BD9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Chris, ext Dearlove, Christopher (UK) wrote: > >> I do think the solution as currently >> specified is a layer violation and relatively difficult to put into >> practice. >> > > We do it in OLSRv1. It works, lots of people use it. OLSRv2, > and hence since we spun it out, packetbb, is using already > proven technology. This is self-evidently therefore not > difficult to put into practice. > The issue is whether or not one has protocol packets of dissimilar varieties to collect together into the bundle. This is a matter of timing, or perhaps delaying some messages. It is not a comment on the ability to write the code taking the packets as input parameters. I would be curious to read about performance studies using realistic data traces, comparing the bundling vs. non-bundling approach during "normal" web traffic. I note that the IPv6 working group already rejected such an approach. Perhaps you claim to know better somehow. I feel that your responses are, more than almost anyone else's, quite dismissive of concerns that have been raised. > As for the rest of your points, I'm not going to go through > it all again. I do not find this surprising. It takes a long time. It took me a long time to compose the message. It would take you a long time to present any realistic and engaging response. You have to decide whether it is worth the effort. > It has been pointed out many times how ordering > permits one-pass easy verification of non-duplication. > It has been pointed out many times that this feature is not universally applicable, most likely not economical, and certainly not inspired by current IETF practice. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 13:35:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHR6-0008EZ-UY; Wed, 31 Oct 2007 13:33:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InHR4-0008EM-Sn for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 13:32:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHR4-0008Ae-I4 for manet@ietf.org; Wed, 31 Oct 2007 13:32:58 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InHR0-00074x-IS for manet@ietf.org; Wed, 31 Oct 2007 13:32:55 -0400 Received: (qmail 14382 invoked from network); 31 Oct 2007 18:32:51 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 31 Oct 2007 18:32:51 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Ian Chakeres'" References: <009801c81b2c$af35d1b0$0da17510$@nl> <374005f30710310601p2c106b4o1b084428f1d9ce3f@mail.gmail.com> <004601c81bd0$7c92c480$75b84d80$@nl> In-Reply-To: Subject: RE: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt Date: Wed, 31 Oct 2007 18:32:11 +0100 Message-ID: <006901c81be4$0a5b53f0$1f11fbd0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgbvidSAQy7pLkwQQGcGh2t6lZ8zAAALDMgAADdxCAABFqecAADdXkA Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. Teco. > > Why can't I get allocated just a few fulltypes? (less than 256) > > You can. You request a new type registry to be open, with > rules on how to allocate further fulltypes in it. You will > probably only actually want some (often only one, but maybe > more) right now, with rules on how to get more. We could > pack logically unrelated fulltypes together under one type. > We'd do that if we were running short. But single octet types > are more efficient, and while we have a limited number of > protocols, we can afford to use them as we are. Great. Can you add this instruction in the IANA considerations section? Now we touch the "gaps" issue in the number space. IANA has to register fulltypes or an (unmanageable) number of sub-registries. > > What if many others request this? > > If packetbb is so successful that we run into shortage of > TLV types/fulltypes, I will be gratifyingly surprised. We better prepare for it. In the past, I was involved in costly projects expanding fields (money, addressing). > > What will happen when we all use some random numbers in the 128-255 > range > > (private/local) for different purposes, in the same MANET? > > There's an inherent contradiction between "private/local" and > "we all". You could ask the same question about any private/local > set of allocations (UDP ports, IP addresses etc.). If you are > clashing with someone else it's not private/local. The problem here is that we design an "ad-hoc" protocol. We do not have control how these protocols are being used. Protocol designers using the private/local tlv-types could need a tool protecting their own tlv-type numberspace. I prefer adding a really long identifier for it, as long as standard types do not carry large overhead. For example, using 128-255 (high order bit) MUST use a OUI (tlv-type-oui). Then, each organization can maintain their own registry. As an alternative, it could be specified that using private/local is not allowed on public infrastructures. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 13:45:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHb2-0004u2-DZ; Wed, 31 Oct 2007 13:43:16 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InHb0-0004qv-Hr for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 13:43:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHb0-0004qk-62 for manet@ietf.org; Wed, 31 Oct 2007 13:43:14 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InHaz-0007U3-JC for manet@ietf.org; Wed, 31 Oct 2007 13:43:14 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9VHhC1X026275 for ; Wed, 31 Oct 2007 17:43:12 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9VHhBmo003381 for ; Wed, 31 Oct 2007 17:43:11 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 31 Oct 2007 17:43:11 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Oct 2007 17:43:12 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Regarding packetbb constraints on ordering and uniqueness. Date: Wed, 31 Oct 2007 17:43:10 -0000 Message-ID: In-Reply-To: <4728A9F5.5040204@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Regarding packetbb constraints on ordering and uniqueness. Thread-Index: Acgb2WVqtCc8gwyeRTu/gpYGFileAQAClmIw References: <8194AB5B-34B3-4AB7-BC6D-005449F2448B@computer.org><47288F9B.20903@nokia.com> <4728A9F5.5040204@nokia.com> From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" X-OriginalArrivalTime: 31 Oct 2007 17:43:12.0002 (UTC) FILETIME=[81D94620:01C81BE5] X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > The issue is whether or not one has protocol packets of > dissimilar varieties to collect together into the bundle. This is > a matter of timing, or perhaps delaying some messages. Which of course we do using jitter. There's a useful synergy between the two, even though they are for different reasons. > I would be curious to > read about performance studies using realistic data traces, > comparing the bundling vs. non-bundling approach during > "normal" web traffic. When being used for OLSRv2, one case that packetbb supports, normal web traffic is a red herring. OLSRv2 is a proactive protocol, what it does is independent of that traffic, except insofar as the two get in each other's way. And reducing the number of packets is a step in that direction. And I have done simulations that compare the numbers of OLSR packets with and without piggybacking, and found a significant reduction in OLSR control packets, without increasing the jitter delay that we want anyway. > I note that the IPv6 working group > already rejected such an approach. Perhaps you claim to > know better somehow. I just claim to know that what's appropriate to a wireless ad hoc network may be slightly different from a general IPv6 consideration. > I feel that your responses are, more than almost anyone > else's, quite dismissive of concerns that have been raised. When the concerns are that something that's been done for several years is "relatively difficult to put into practice" and which has been in packetbb for years without a whisper suddenly becomes an issue when we are trying to get the document finished, a long over-due step, then yes, my answer will be short, and may appear dismissive. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 13:51:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHig-0007gg-UC; Wed, 31 Oct 2007 13:51:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InHig-0007cK-3L for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 13:51:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHif-0007aH-Py for manet@ietf.org; Wed, 31 Oct 2007 13:51:09 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InHiU-0001xX-1V for manet@ietf.org; Wed, 31 Oct 2007 13:51:03 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9VHoELi000162 for ; Wed, 31 Oct 2007 17:50:15 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9VHoEeB007645 for ; Wed, 31 Oct 2007 17:50:14 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 31 Oct 2007 17:50:14 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Oct 2007 17:50:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt Date: Wed, 31 Oct 2007 17:50:13 -0000 Message-ID: In-Reply-To: <006901c81be4$0a5b53f0$1f11fbd0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] I-D ACTION:draft-ietf-manet-packetbb-10.txt Thread-Index: AcgbvidSAQy7pLkwQQGcGh2t6lZ8zAAALDMgAADdxCAABFqecAADdXkAAAD9/AA= References: <009801c81b2c$af35d1b0$0da17510$@nl> <374005f30710310601p2c106b4o1b084428f1d9ce3f@mail.gmail.com> <004601c81bd0$7c92c480$75b84d80$@nl> <006901c81be4$0a5b53f0$1f11fbd0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ian Chakeres" X-OriginalArrivalTime: 31 Oct 2007 17:50:14.0463 (UTC) FILETIME=[7DA7B4F0:01C81BE6] X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > Great. Can you add this instruction in the IANA considerations section? It'a already there. "If a packet TLV type is allocated then a new registry for type extensions of that type must be created." "If a message TLV type is allocated then a new registry for type extensions of that type must be created." "If an address block TLV type is allocated then a new registry for type extensions of that type must be created." =20 > Now we touch the "gaps" issue in the number space. IANA has to register > fulltypes or an (unmanageable) number of sub-registries. That's certainly not unmanageable. > We better prepare for it. In the past, I was involved in costly projects > expanding fields (money, addressing). We have a packetbb version mechanism. That will allow us any such freedom we need. > As an alternative, it could be specified that > using private/local is not allowed on public infrastructures. Well, I'm no expert, but isn't this implicit in what private/local means? ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 13:52:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHjS-0008Ox-MU; Wed, 31 Oct 2007 13:51:58 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InHjQ-0008Oj-Nj for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 13:51:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHjQ-0008Oa-Ck for manet@ietf.org; Wed, 31 Oct 2007 13:51:56 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InHjQ-0007t3-3o for manet@ietf.org; Wed, 31 Oct 2007 13:51:56 -0400 X-IronPort-AV: E=Sophos;i="4.21,352,1188792000"; d="scan'208";a="75033103" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2007 13:51:53 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9VHpqZF011689; Wed, 31 Oct 2007 13:51:52 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9VHpcg8022929; Wed, 31 Oct 2007 17:51:51 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 13:51:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Regarding packetbb constraints on ordering and uniqueness. Date: Wed, 31 Oct 2007 13:51:43 -0400 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76404D5410D@xmb-rtp-208.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Regarding packetbb constraints on ordering and uniqueness. Thread-Index: AcgbyfqrCYIbdPEDSby6OhR0TQ8jNQACtipQAARmykA= From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" , "Charles E. Perkins" , "ext Thomas Clausen" X-OriginalArrivalTime: 31 Oct 2007 17:51:45.0803 (UTC) FILETIME=[B41915B0:01C81BE6] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15516.002 X-TM-AS-Result: No--3.320400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=645; t=1193853112; x=1194717112; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[manet]=20Regarding=20packetbb=20constraints=20on=20o rdering=20and=20uniqueness. |Sender:=20 |To:=20=22Dearlove, =20Christopher=20(UK)=22=20, =0A=20=20=20=20=20=20=20=20=22Charles=20E.=20Perkins=22=20, =0A=20=20=20=20=20=20=20=20=22ext=20Thomas=20Clausen=22=2 0; bh=HcSBtN/fBjSWnIAd5RB43ikhOZilGyj3UsJIkHAVaFw=; b=TDuYxE2hX/RFW10ofFRDK37+mIkegX6xbgcUlLLrkshS6B7pNa4lQPj8GniXxCiiY3Mh5e9f bVMicw7juHN9f8pLHcJmGxBqj5sTjXCmDrP6yTt0zLbJvFGBvU7u3nHR; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org =20 >-----Original Message----- >From: Dearlove, Christopher (UK)=20 >[mailto:Chris.Dearlove@baesystems.com]=20 >Sent: Wednesday, October 31, 2007 11:50 AM >To: Charles E. Perkins; ext Thomas Clausen >Cc: Manet >Subject: RE: [manet] Regarding packetbb constraints on=20 >ordering and uniqueness. > [snip] > >As for the rest of your points, I'm not going to go through >it all again. It has been pointed out many times how ordering >permits one-pass easy verification of non-duplication. > Ditto on the "not going through it all again". Suffice it to say that there are still dissenting opinions out here. Regards, Stan _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 14:01:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHrz-0001Uw-6e; Wed, 31 Oct 2007 14:00:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InHrw-0001CC-RQ for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 14:00:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHrw-0001C3-Hx for manet@ietf.org; Wed, 31 Oct 2007 14:00:44 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InHrq-0002Rf-6K for manet@ietf.org; Wed, 31 Oct 2007 14:00:44 -0400 Received: (qmail 29622 invoked from network); 31 Oct 2007 19:00:21 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 31 Oct 2007 19:00:21 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Ian Chakeres'" References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <009401c81b19$29a04200$7ce0c600$@nl> <374005f30710310345x432a6a6dk82546060d6a2b2a7@mail.gmail.com> <003001c81bbf$bbbb31d0$33319570$@nl> <374005f30710310629i3224ed8cy4cc94dc3c71f491e@mail.gmail.com> <004501c81bcf$b3169140$1943b3c0$@nl> In-Reply-To: Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Wed, 31 Oct 2007 18:59:41 +0100 Message-ID: <007301c81be7$e1cdb7d0$a5692770$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgbwgdKrXPIjYVyRSyeNUAJnSPzMAADVEswAAEDQ2AABD53UA== Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > > Anyway, we have to update the packetbb document for it. Right now, it > is > > tailored for UDP and not for IP. > > Actually, no it isn't. The letters "UDP" do not appear anywhere > in it. They used to (but only as an example), now they don't > appear at all. This was for this very reason. Partly agreed: UDP is not mentioned in packetbb. Partly not agreed: OLSR, NHDP and DYMO mentions UDP. My main concern is that if someone wants to use the manet IP_PROTO and packetbb, something is missing. I don't like a transport protocol that does not implement some kind of error detection. Ian's proposal that it can be added in a future extension is acceptable for me. Can we add some words on this in packetbb? I prefer text specifying that it is required that lower layers MUST fulfill needs for integrity in case packetbb does not provide such. Otherwise, I am against requesting IP_PROTO. Teco. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 14:06:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHwk-0000Du-Dd; Wed, 31 Oct 2007 14:05:42 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InHwc-00008F-B3 for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 14:05:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHwb-00006b-Be for manet@ietf.org; Wed, 31 Oct 2007 14:05:33 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InHwP-0002ky-Vx for manet@ietf.org; Wed, 31 Oct 2007 14:05:30 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l9VI448E028492 for ; Wed, 31 Oct 2007 18:04:04 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l9VI44Y7016676 for ; Wed, 31 Oct 2007 18:04:04 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 31 Oct 2007 18:04:02 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Oct 2007 18:04:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Wed, 31 Oct 2007 18:04:01 -0000 Message-ID: In-Reply-To: <007301c81be7$e1cdb7d0$a5692770$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Thread-Index: AcgbwgdKrXPIjYVyRSyeNUAJnSPzMAADVEswAAEDQ2AABD53UAAA6A6Q References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <009401c81b19$29a04200$7ce0c600$@nl> <374005f30710310345x432a6a6dk82546060d6a2b2a7@mail.gmail.com> <003001c81bbf$bbbb31d0$33319570$@nl> <374005f30710310629i3224ed8cy4cc94dc3c71f491e@mail.gmail.com> <004501c81bcf$b3169140$1943b3c0$@nl> <007301c81be7$e1cdb7d0$a5692770$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ian Chakeres" X-OriginalArrivalTime: 31 Oct 2007 18:04:02.0713 (UTC) FILETIME=[6B54A090:01C81BE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > Partly not agreed: OLSR, NHDP and DYMO mentions UDP. The former two have not been updated to correspond to the latest draft-iana yet, they pre-date it. The same may well be true of DYMO, but I'll let someone else answer that. > Ian's proposal that it can be added in a future extension is acceptable for > me. Can we add some words on this in packetbb? packetbb is not the place for this. draft-iana might be, or some potential future document. packetbb has removed all such considerations. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 14:39:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InIPe-0001lg-43; Wed, 31 Oct 2007 14:35:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InIPc-0001jY-4F for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 14:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InIPb-0001jK-Qr for manet@ietf.org; Wed, 31 Oct 2007 14:35:31 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InIPV-0004Ht-FA for manet@ietf.org; Wed, 31 Oct 2007 14:35:31 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9VIYulh018861; Wed, 31 Oct 2007 20:35:07 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 20:34:30 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 13:34:02 -0500 Received: from [172.18.141.138] ([172.18.141.138]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 13:34:02 -0500 Message-ID: <4728CA99.9060703@nokia.com> Date: Wed, 31 Oct 2007 11:34:01 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "ext Dearlove, Christopher (UK)" Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. References: <8194AB5B-34B3-4AB7-BC6D-005449F2448B@computer.org><47288F9B.20903@nokia.com> <4728A9F5.5040204@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 18:34:02.0595 (UTC) FILETIME=[9C24D330:01C81BEC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Chris, You wrote: >> I would be curious to >> read about performance studies using realistic data traces, >> comparing the bundling vs. non-bundling approach during >> "normal" web traffic. >> > > When being used for OLSRv2, one case that packetbb supports, > normal web traffic is a red herring. OLSRv2 is a proactive > protocol, what it does is independent of that traffic, > except insofar as the two get in each other's way. And > reducing the number of packets is a step in that direction. > And I have done simulations that compare the numbers of OLSR > packets with and without piggybacking, and found a significant > reduction in OLSR control packets, without increasing the > jitter delay that we want anyway. > To be clear, I am not lobbying for removal of the bundling feature. As you describe it, bundling is useful for reducing the number of proactive packets periodically produced by particular protocols. Besides having lots of 'p's, anything that reduces a significant fraction of the network-layer load on the system is to be 'p'refered. My intuition is more shaped by the case where the network signaling is less of a fraction of the total traffic. > >> I note that the IPv6 working group >> already rejected such an approach. Perhaps you claim to >> know better somehow. >> > > I just claim to know that what's appropriate to a wireless > ad hoc network may be slightly different from a general > IPv6 consideration. > This is more debatable, but it is true that reducing network load is probably not so urgent in wired networks. > > When the concerns are that something that's been done for > several years is "relatively difficult to put into practice" > and which has been in packetbb for years without a whisper > suddenly becomes an issue when we are trying to get the > document finished, a long over-due step, then yes, my > answer will be short, and may appear dismissive. > Your discussion in this message was a lot more what I was looking for until this last sentence. Maybe a brief but responsive answer to issues that have been raised would in the end be more economical with your time and that of the working group, under the assumption that people really want to understand and make progress. There is little or no reason to create a divisive atmosphere. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 22:22:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InPd6-0003IO-3H; Wed, 31 Oct 2007 22:17:56 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InPd4-0003Fk-9C for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 22:17:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InPd3-0003Fa-VR for manet@ietf.org; Wed, 31 Oct 2007 22:17:53 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InPcx-00005d-PU for manet@ietf.org; Wed, 31 Oct 2007 22:17:53 -0400 Received: by nf-out-0910.google.com with SMTP id d21so275532nfb for ; Wed, 31 Oct 2007 19:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=jUFWQXcILUig5BnSpMcRsBYY3m4FUtiow3GtyAjACdE=; b=EsVRzPJOBPwI7bXFHZFOJmaH+nobpgBRcqOUcSrv3WX91Uiru7JTLCHU0iWbIFFSiIoKcDGX+Bgok8R3P8TkAy775EcwUv5eLEsb9SYLTcAJl8pEqu09KxCQG3UKmN721+TbYY5BEh7nrBaoRr6TwFz9oPzrStxdrRevoyM+BsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MfQ7QT7znh1caS0V9Ei3b6EvBhta8q8sCwPWSK8sXZsxcy18/zgqJoB6P/8GN72gKtuCRIYAWvjtpLjybVAL771hMcwqPj66YniRZCAzzMMofoftD+6sqinPALCjgRVCu5BtTCKbZg1lZZUffWanj4QQskB/yfOXxOS4x2t5fps= Received: by 10.78.149.15 with SMTP id w15mr18017hud.1193883451886; Wed, 31 Oct 2007 19:17:31 -0700 (PDT) Received: by 10.78.33.7 with HTTP; Wed, 31 Oct 2007 19:17:31 -0700 (PDT) Message-ID: <374005f30710311917j6ec5d75bi5a16564105de1947@mail.gmail.com> Date: Thu, 1 Nov 2007 07:47:31 +0530 From: "Ian Chakeres" To: "Teco Boot" Subject: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt In-Reply-To: <007301c81be7$e1cdb7d0$a5692770$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <009401c81b19$29a04200$7ce0c600$@nl> <374005f30710310345x432a6a6dk82546060d6a2b2a7@mail.gmail.com> <003001c81bbf$bbbb31d0$33319570$@nl> <374005f30710310629i3224ed8cy4cc94dc3c71f491e@mail.gmail.com> <004501c81bcf$b3169140$1943b3c0$@nl> <007301c81be7$e1cdb7d0$a5692770$@nl> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "Dearlove, Christopher \(UK\)" , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I do not think any modification needs to be made to PacketBB regarding this matter. In the future, we can specify additional behavior/protocols if/when it is needed. As Chris stated, transport and integrety are not handled in PacketBB. I could see the possible insertion of some text in NHDP, DYMO, OLSRv2, and potentially another draft specifying an integrity TLV. Ian On 10/31/07, Teco Boot wrote: > > > Anyway, we have to update the packetbb document for it. Right now, it > > is > > > tailored for UDP and not for IP. > > > > Actually, no it isn't. The letters "UDP" do not appear anywhere > > in it. They used to (but only as an example), now they don't > > appear at all. This was for this very reason. > > Partly agreed: UDP is not mentioned in packetbb. > Partly not agreed: OLSR, NHDP and DYMO mentions UDP. > > My main concern is that if someone wants to use the manet IP_PROTO and > packetbb, something is missing. I don't like a transport protocol that does > not implement some kind of error detection. > Ian's proposal that it can be added in a future extension is acceptable for > me. Can we add some words on this in packetbb? I prefer text specifying that > it is required that lower layers MUST fulfill needs for integrity in case > packetbb does not provide such. > Otherwise, I am against requesting IP_PROTO. > > Teco. > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Oct 31 22:34:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InPqx-0007Jg-KS; Wed, 31 Oct 2007 22:32:15 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InPqv-0007Hl-Ul for manet-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 22:32:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InPqv-0007H5-Ko for manet@ietf.org; Wed, 31 Oct 2007 22:32:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InPqp-0000Wq-F8 for manet@ietf.org; Wed, 31 Oct 2007 22:32:13 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1396550uge for ; Wed, 31 Oct 2007 19:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=r342NmpFg22ydtLcA9d22OOkGuRgqE6ifUw+eBqXV+I=; b=QtDuqbJEHssM2plgItIJqC0/xCAwhIYGAxBpOTg+Bm/6KHnNHINwtAudYXLldIvwV1ED1WYwy1mAZjzZTJyLfRE/uF8Bmqea3tKm/5MERICEvm08s600EBigVzacrHRoAa4lrMMekPGzLFnGx8S6USRh8GnTvQccZxmqKiykxPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=b7ryz2SMlEboXLATuYfhG0fenIDOYmKJ2LMUoQJ1+hrvL3Tqps2nddGYvElDpD7ZV6ljk5UeJMBTV7DgqdaUrh4EzIwwM9yYZHp1lUX2mXt0uEkzjwpPIN0QWrMckgFRiLQH1rWj49ANcnj9AH2A2Nk3ghjOMekU5peyVQm2cQY= Received: by 10.78.170.17 with SMTP id s17mr28158hue.1193884293450; Wed, 31 Oct 2007 19:31:33 -0700 (PDT) Received: by 10.78.33.7 with HTTP; Wed, 31 Oct 2007 19:31:33 -0700 (PDT) Message-ID: <374005f30710311931o319f2288p9041c4942652009@mail.gmail.com> Date: Thu, 1 Nov 2007 08:01:33 +0530 From: "Ian Chakeres" To: "Charles E. Perkins" Subject: Re: [manet] PacketBB multimessage format MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: "ext Dearlove, Christopher \(UK\)" , Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org >> The idea of collecting multiple messages in a packet and transmit >> these in one transmission is to reduce the MAC overhead The multimessage format incurs no overhead for messages/implementations that do not make use of it. Therefore, I see little reason to debate this issue. Let's try to keep our discussion on improving and finishing PacketBB. Ian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet