From manet-bounces@ietf.org Wed Aug 01 14:09: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 1IGId4-0003bB-W9; Wed, 01 Aug 2007 14:09:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IG8TW-0005PE-9z for manet-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 03:18:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IG8TW-0005P6-0a for manet@ietf.org; Wed, 01 Aug 2007 03:18:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG8Rh-0004CG-Np for manet@ietf.org; Wed, 01 Aug 2007 03:16:37 -0400 Received: from m13-31.163.com ([220.181.13.31]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IG8Rf-0004Fv-As for manet@ietf.org; Wed, 01 Aug 2007 03:16:37 -0400 Received: from 211.167.77.67 ( 211.167.77.67 [211.167.77.67] ) by ajax-webmail-wmsvr31 (Coremail) ; Wed, 1 Aug 2007 15:16:26 +0800 (CST) Date: Wed, 1 Aug 2007 15:16:26 +0800 (CST) From: =?GBK?B?u8bOsA==?= To: manet@ietf.org Message-ID: <28995361.236421185952586458.JavaMail.coremail@bj163app31.163.com> MIME-Version: 1.0 X-Originating-IP: [192.168.208.56 (211.167.77.67)] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT_070725 build 070725(3676.1195.1194) Copyright (c) 2002-2007 www.mailtech.cn 163com X-Spam-Score: 2.6 (++) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f X-TMDA-Confirmed: Wed, 01 Aug 2007 03:18:29 -0400 X-Mailman-Approved-At: Wed, 01 Aug 2007 14:09:00 -0400 Subject: [manet] Question about basic access procedure of 802.11-DCF 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="===============0419853658==" Errors-To: manet-bounces@ietf.org --===============0419853658== Content-Type: multipart/Alternative; boundary="----=_Part_25580_4995933.1185952586456" ------=_Part_25580_4995933.1185952586456 Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: quoted-printable Hi Byung-Jae, =20 I have seen your post onhttp://www1.ietf.org/mail-archive/web/manet/current= /msg03272.html, where you mentioned the basic procedure of DCF as following= : =20 STA A Tx a packet; STA A receives an ACK; STA A waits for DIFS; STA A choose a random number for backoff and counts down to zero; If (STA A has a packet in the queue) then STA A Tx the packet; else STA A waits until a packet arrives; switch (channel idle time) case (the channel has been idle for more than DIFS): STA A Tx the packet right away; case (the channel has been idle for T_idle < DIFS): STA A waits for DIFS - T_idle; STA A enters a normal backoff procedure; case (the channel is busy) STA A waits until the channel becomes idle; STA A waits DIFS; STA A enters a normal backoff procedure; endswitch endif =20 =20 It is very clear. But I still have one question: If MAC has no packet in queue, does it ignore the state of the channel and = arrived packets will be transmitted immediately IF it senses the channel to= be IDLE for longer than DIFS? Or, if it has no packet in the queue, it sti= ll initialize a contention window when the medium becomes busy and count do= wn when medium becomes IDLE again for longer than DIFS? =20 I think the 2nd is more reasonable. Because if it does follow the 1st, cons= ider this condition: =20 STA A Tx a packet; STA A receives an ACK; STA A waits for DIFS; STA A choose a random number for backoff and counts down to zero; STAA has no packet in queue=A1=AD=A1=AD =A1=AD=A1=AD STAB transmit a packet STAC wants to transmit a packet but the medium is busy so it defers and bac= k-off STAB finish transmitting STAC finishes defer DIFS and enters contention window STAA get a packet just when the medium is IDLE for DIFS STAA transmit=A1=AD.. =20 Is this some kind of unfair, because STAC wants to transmit earlier but STA= A grasp the medium. Any comment on this? I am looking for your reply. Thank you very much. =20 Best regards, Huang Wei ------=_Part_25580_4995933.1185952586456 Content-Type: text/html; charset=gbk Content-Transfer-Encoding: quoted-printable

Hi Byung-Jae,

 

I have seen your post on http= ://www1.ietf.org/mail-archive/web/manet/current/msg03272.html, where yo= u mentioned the basic procedure of DCF as following:

 

STA A Tx a packet;

STA A receives an ACK;

STA A waits for DIFS;

STA A choose a random number for ba= ckoff and counts down to zero;

If (STA A has a packet in the queue= )

  then

    STA A Tx the pac= ket;

  else

    STA A waits unti= l a packet arrives;

    switch (channel = idle time)

      = ;  case (the channel has been idle for more than DIFS):

      = ;    STA A Tx the packet right away;

      = ;  case (the channel has been idle for T_idle < DIFS):

      = ;    STA A waits for DIFS - T_idle;=

      = ;    STA A enters a normal backoff procedure;

      = ;  case (the channel is busy)

      = ;    STA A waits until the channel becomes idle;<= /SPAN>

      = ;    STA A waits DIFS;

      = ;    STA A enters a normal backoff procedure;

    endswitch

endif

 

 

It is very clear. But I still have = one question:

If MAC has no packet in queue, does= it ignore the state of the channel and arrived packets will be transmitted= immediately IF it senses the channel to be IDLE for longer than DIFS? Or, = if it has no packet in the queue, it still initialize a contention window w= hen the medium becomes busy and count down when medium becomes IDLE again f= or longer than DIFS?

 

I think the 2nd is more = reasonable. Because if it does follow the 1st, consider this con= dition:

 

STA A Tx a packet;

STA A receives an ACK;

STA A waits for DIFS;

STA A choose a random number for ba= ckoff and counts down to zero;

STAA has no packet in queue=A1=AD= =A1=AD

=A1=AD=A1=AD

STAB transmit a packet

STAC wants to transmit a packet but= the medium is busy so it defers and back-off

STAB finish transmitting=

STAC finishes defer DIFS and enters= contention window

STAA get a packet just when the med= ium is IDLE for DIFS

STAA transmit=A1=AD..

 

Is this some kind of unfair, becaus= e STAC wants to transmit earlier but STAA grasp the medium. Any comment on = this?

I am looking for your reply. Thank = you very much.

 

Best regards,

Huang Wei<= /P>

 
 
 


=B2=C6 =B8=BB =D2=BB =F7=BB =BC=E4=A3=BA=BA=C3 =CD=E6 =B4=CC =BC=A4 = =B5=C4 =CD=F8 =C2=E7 =B4=F3 =B8=BB =CE=CC =C0=B4 =C0=B2=A3=A1=BF=EC =C8=A5 = =BF=B4 =BF=B4 ------=_Part_25580_4995933.1185952586456-- --===============0419853658== 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 --===============0419853658==-- From manet-bounces@ietf.org Wed Aug 01 20:54: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 1IGOxI-0001vc-Bg; Wed, 01 Aug 2007 20:54:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IGOxG-0001vV-T9 for manet-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 20:54:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGOxG-0001uf-IP for manet@ietf.org; Wed, 01 Aug 2007 20:54:18 -0400 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGOxF-0006Hk-BM for manet@ietf.org; Wed, 01 Aug 2007 20:54:18 -0400 Received: by rv-out-0910.google.com with SMTP id f1so255357rvb for ; Wed, 01 Aug 2007 17:54:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=glk7HWgYdlmvNzqQUKJ3Ht2jkzP/O1UJuTov/8paXo4dOIBmlUtuSFKReNjJPfTLpB2V9onDFwEa+cEK5pQlj4vB1NUpl98w1UMr1APe9IjiGGGrusWLx82jpzTYN+TQcSvsyMWwoxAjUoOZD7QeVFcVO2IzQHdOLUhqVVXIpS0= 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=mZvA4JhkMPPBF1NESlQFLC5QiAY+Cwguyf4onMWrPUL3NRBVI0ZQ2EMqQ4ckVB1nSTB4JgrzOSnOaoPre06k9HfFsXbdTMgLhhSaut0e9kENWRLTn6yGz9V7mJamCMDuyBgX+Wphm7bmrnLayeyqAMxEk0bUkTumAPTUi5R2EOE= Received: by 10.141.132.8 with SMTP id j8mr464862rvn.1186016056191; Wed, 01 Aug 2007 17:54:16 -0700 (PDT) Received: by 10.141.98.2 with HTTP; Wed, 1 Aug 2007 17:54:16 -0700 (PDT) Message-ID: <2a3692de0708011754l1755047ej85711c057144e3cb@mail.gmail.com> Date: Thu, 2 Aug 2007 09:54:16 +0900 From: "Dominik Kaspar" To: jdean@itd.nrl.navy.mil 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: 7aefe408d50e9c7c47615841cb314bed Cc: manet@ietf.org Subject: [manet] Small question to draft-dean-manet-metriclv-00 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 Justin, In Step 2 of the algorithm for computing the exponential metric (Section 5.2), what is the variable "t"? Regards, Dominik _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Aug 02 14:50: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 1IGfk2-0004EI-6D; Thu, 02 Aug 2007 14:49:46 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IGfjz-0004E6-Sa for manet-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 14:49:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGfjz-0004Dy-Hz for manet@ietf.org; Thu, 02 Aug 2007 14:49:43 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGfjy-0007lN-Cs for manet@ietf.org; Thu, 02 Aug 2007 14:49:43 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l72Inb6n005927; Thu, 2 Aug 2007 14:49:37 -0400 (EDT) Message-Id: <200708021849.l72Inb6n005927@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007080214493627804 ; Thu, 02 Aug 2007 14:49:36 -0400 From: "Justin Dean" To: "'Dominik Kaspar'" Date: Thu, 2 Aug 2007 14:54:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfUn6gw3uYdzXDJQwmCmP9ODRWAwQAlqGxw In-Reply-To: <2a3692de0708011754l1755047ej85711c057144e3cb@mail.gmail.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: manet@ietf.org Subject: [manet] RE: Small question to draft-dean-manet-metriclv-00 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 t should be a v and the "time value" should just be value. Sorry for missing that change and thanks for pointing it out. The method of representation is the same that the time tlv document uses. Justin -----Original Message----- From: Dominik Kaspar [mailto:dokaspar.ietf@gmail.com] Sent: Wednesday, August 01, 2007 8:54 PM To: jdean@itd.nrl.navy.mil Cc: manet@ietf.org Subject: Small question to draft-dean-manet-metriclv-00 Hi Justin, In Step 2 of the algorithm for computing the exponential metric (Section 5.2), what is the variable "t"? Regards, Dominik _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Aug 02 15:51: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 1IGghv-0001b2-VL; Thu, 02 Aug 2007 15:51:39 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IGghu-0001W6-1I for manet-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 15:51:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGght-0001Sx-K8 for manet@ietf.org; Thu, 02 Aug 2007 15:51:37 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGghs-0001ce-Q3 for manet@ietf.org; Thu, 02 Aug 2007 15:51:37 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l72JpXEg008520; Thu, 2 Aug 2007 15:51:33 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007080215513228077 ; Thu, 02 Aug 2007 15:51:32 -0400 From: "Joe Macker" To: "'Teco_Boot'" References: <000001c7d349$0cac24b0$b500800a@Teco> Date: Thu, 2 Aug 2007 15:51:30 -0400 Message-ID: <000301c7d53e$858234a0$165cfa84@SEXTANT> 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.3138 Thread-Index: AcfTSMRyptaS15goS3+0XUYt67Qh2gB6OpZw In-Reply-To: <000001c7d349$0cac24b0$b500800a@Teco> X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: manet@ietf.org Subject: [manet] RE: DPD for IPv6 - fragmentation support 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 Teco: Yes, IPv6 source fragmentation packets will be supported at least that is the plan for now. Yes the identification field is helpful in that case and can be used. Re. hashing, yes we are adding hashing for IPv4 as well as an option. Mutable fields need to be skipped as you point out. Document changes planned in -06: - Revise IPv4 SMF DPD, expand tuple processing, no ID field modification, support fragmentation, support optional hashing as per IPv6 - Revise IPv6 SMF DPD to support IPv6 source-based fragmentation (no header option should be needed) - Editorial changes throughout (Templin's comments/others) - Provide clearer discussion of implementation requirements for interoperability. >-----Original Message----- >From: Teco_Boot [mailto:teco@inf-net.nl] >Sent: Tuesday, July 31, 2007 4:01 AM >To: 'Joe Macker' >Cc: manet@ietf.org >Subject: DPD for IPv6 - fragmentation support > >Hi Joe, > > > >As fragmentation with IPv4 is to be supported, IPv6 >fragmentation support can be considered too. > >It even brings efficiency, as adding the DPD header is >eliminated if a fragment header was included by the source. > >Draft algorithm below. I am not sure about the optional >tagging *), this depends on the --to be written-- rules for >used SMF mechanisms in a MANET. > > > >I am not a protocol implementer. But if, I would consider a >single hash table for IPv4 and IPv6 and run the hash algorithm >over those fields that guarantee uniqueness, or over the first >N octets of a frame with blanked fields TTL, TOS and >hop-by-hop & routing headers. Code maintaining the table and >performing fast lookups would be shared for all types of traffic. > > > >Teco. > > > > > >+-------------+-----------------+-------------+---------------- >--------------------------+ > >|IPsec header | Fragment header | DPD header | action > | > >+-------------+-----------------+-------------+---------------- >--------------------------+ > >| present | * | * | IPsec header >DPD check and forward | > >| not present | present | not present | Fragment >header DPD check and forward (1)| > >| not present | present | present | invalid, do >not forward (2) | > >| not present | not present | not present | Optionally tag >and forward (3) | > >| not present | not present | present | DPD header DPD >check and forward | > >+-------------+-----------------+-------------+---------------- >--------------------------+ > > > >1: DPD check based on > > > > >2: SMF shall use fragment header if present. Adding DPD header >should never occur. > > > >3: Received packets are sent by connected hosts or forwarded >by MANET SMF routers implementing DPD based on hashing. >Tagging is optional *). > > > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Aug 03 03:42: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 1IGrnB-0000Yf-22; Fri, 03 Aug 2007 03:41:49 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IGrn8-0000YY-6h for manet-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 03:41:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGrn7-0000YP-SK for manet@ietf.org; Fri, 03 Aug 2007 03:41:45 -0400 Received: from fauern.informatik.uni-erlangen.de ([131.188.34.45] helo=faui45.informatik.uni-erlangen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGrn7-0000Mr-56 for manet@ietf.org; Fri, 03 Aug 2007 03:41:45 -0400 Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTP id 0CCC04D34 for ; Fri, 3 Aug 2007 09:40:26 +0200 (MEST) Received: from [131.188.37.96] (faui7m16 [131.188.37.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTP id DEE85B0038 for ; Fri, 3 Aug 2007 09:40:25 +0200 (CEST) Message-ID: <46B2DBE9.1000407@informatik.uni-erlangen.de> Date: Fri, 03 Aug 2007 09:40:25 +0200 From: Christoph Sommer User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [manet] draft-ietf-manet-dymo-10 open questions 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 All, Updating a draft-06-implementation of DYMO to draft version 10, some=20 points were not immediately clear to me after reading the latest=20 specification. In some cases, DYMO implementations interpreting the draft differently=20 could lead to interoperability issues. But while most of the time, one=20 alternative way of implementing DYMO is clearly superior to the other, I=20 list these points anyway, as I might just have missed something. 4.2.2. Routing Messages (RM) - RREQ & RREP Other than entries associated with "TargetNode" or "OrigNode", both of=20 which have been defined in the section on terminology (as well as=20 "AdditionalNode", which is explained later on), the list of elements=20 associates entries with a generic entity called "Node". If this intended as a superclass of TargetNode and OrigNode,=20 Node.AddTLV.Dist is a duplicate of TargetNode.AddTLV.Dist. If it is not,=20 OrigNode.AddTLV.Dist seems to be missing. In any case, it would probably make things much clearer, if the complete=20 set of properties was given for each of TargetNode, OrigNode and=20 AdditionalNode. Also, the list seems to be missing IP.SourceAddress, which is referenced=20 in "5.2.2. Creating or Updating a Route Table Entry with New Routing",=20 "5.5.2. Updating Route Lifetimes During Packet Forwarding" and "5.5.4.=20 RERR Processing". IP.SourceAddress is also missing in the list of section "4.2.3. Route=20 Error (RERR)". 5.1.4. Actions After OwnSeqNum Loss Should a node assume OwnSeqNum loss when starting up for the very first=20 time? 5.3.1. RREQ Creation The statement "If this DYMO router is performing route discovery on=20 behalf of an attached node ... it MUST advertise it's address and prefix=20 that contain the source address.", leaves it a bit unclear exactly which=20 node=92s address and prefix have to be advertised. 5.3.2. RREP Creation This section should probably not be relevant to the case described in=20 "5.3.3. Intermediate DYMO Router RREP Creation", because the requirement=20 "If ... TargetNode.SeqNum from the RM is less than OwnSeqNum, OwnSeqNum=20 SHOULD be incremented" doesn=92t seem to make much sense if the TargetNod= e=20 is not ThisNode. Also, in the sentence "If ... TargetNode.SeqNum from the RM is less than=20 OwnSeqNum, OwnSeqNum SHOULD be incremented", the comparison of SeqNums=20 here should probably also be based on signed integer arithmetics, not=20 just a comparison. Section "5.3.4. RM Processing" also uses "greater=20 than" for comparison where signed integer arithmetics should make more=20 sense. It might prove beneficial to only once state that SeqNums are to be=20 compared by the special method given later on, then only use the terms=20 "newer" and "older" instead of "greater than" and "smaller than" in the=20 remaining text. 5.3.3. Intermediate DYMO Router RREP Creation The draft seems to be unclear about whether to increment OwnSeqNum when=20 creating intermediate RREPs. 5.3.4. RM Processing In this section, it is allowed that to a RREQ "ThisNode responds with a=20 RREQ flood (a RREQ addressed to oneself) or a RREP to the RREQ=20 OrigNode". If a node always chooses to start an RREQ flood rather than=20 send a RREP, couldn't intermediate node RREP creation completely stop=20 the RREQ flood from ever reaching the node that is searching for a route? 5.5.4. RERR Processing Setting a Route.Broken flag here does not seem to trigger the=20 ROUTE_DELETE timer to be started, which seems to be required in other=20 cases. Also, it might be beneficial to update UnreachableNode.SeqNum with more=20 recent information during processing. The original RERR sender will=20 often not know UnreachableNode.SeqNum because it deleted the route,=20 while a node relaying the RERR will probably still know about the SeqNum. Also, after processing, MsgHdr.HopLimit should probably be decreased.=20 This section does not seem to require this, but checks MsgHdr.HopLimit=20 anyway. Regards, Christoph _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Aug 03 07:31: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 1IGvN5-0000we-9Q; Fri, 03 Aug 2007 07:31:07 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IGvN3-0000wY-22 for manet-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 07:31:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGvN2-0000wQ-Mp for manet@ietf.org; Fri, 03 Aug 2007 07:31:04 -0400 Received: from smtp5-g19.free.fr ([212.27.42.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGvN2-0007PQ-5n for manet@ietf.org; Fri, 03 Aug 2007 07:31:04 -0400 Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 79EA644FCC for ; Fri, 3 Aug 2007 13:30:27 +0200 (CEST) Received: from lri.fr (ras75-2-82-224-51-215.fbx.proxad.net [82.224.51.215]) by smtp5-g19.free.fr (Postfix) with ESMTP id 452D544D06 for ; Fri, 3 Aug 2007 13:30:27 +0200 (CEST) Message-ID: <46B311B8.2090603@lri.fr> Date: Fri, 03 Aug 2007 13:30:00 +0200 From: Khaldoun Al Agha User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: manet@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Subject: [manet] 1st Home Networking Conference 2007 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="===============2142118050==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============2142118050== Content-Type: multipart/alternative; boundary="------------020000060903040507050500" This is a multi-part message in MIME format. --------------020000060903040507050500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable CALL FOR PAPERS 1st Home Networking Conference 2007 IFIP TC6 Conference IEEE (Under request) Paris - France - December 12-14, 2007 GENERAL CHAIRS Guy Pujolle (LIP6, France) PROGRAM CO-CHAIRS K. Al Agha (University of Paris XI, FR) X. Carcelle (EDF, FR) STEERING COMMITTEE G. Carle (U. Tubingen) A. Karmouch (U. Ottawa, Canada) D. Ga=EFti (UTT, France) G. Pujolle (LIP6, France) H. Zimmermann (Ginkgo Networks, France) PROGRAM COMMITTEE N. Achir (U. Paris North, France) H. Afifi (INT, France) I. Akyildiz (Georgia Tech, USA) G. Carle (U. Tubingen) P. Cuenca (U. Castilla-La Mancha, Spain) C. Chatellier (U Poitiers, Fr) O. Duarte (UFRJ, Brazil) D. Ga=EFti (UTT, France) M. Gerla (UCLA, USA) W. Grote (UTFSM, Chile) U. K=F6rner (U. Lund, Sweden) S. Jiang (SCUT, China) H. Latchman (U Florida, US) S. Lohier (U. Paris East) T. Luckenbach (FOKUS, Germany) K. Mase (Nigata Univerity, Japan S. Meyer (FTR&D, France) P. Muhletaler (INRIA, France) I.G. Niemegeers (TUD, Netherland) C. Niedermeier (Siemens, Germany) J. Nogueira (UFMG, Brazil) C. Petrioli (La Sapienza, Italy) S.V. Raghavan (IIT, India) L. Reynaud (FTR&D, France) T. Ritzau (Sony-Ericsson, Sweden) J.J. Rodriguez (U Vigo, Spain) F. Souchkoff (Microsoft) S. Tabbane (SupCom, Tunisia) Y. Takahashi (Kyoto University, Japan) S. Ubeda (INSA Lyon, France) P. Urien (ENST, France) G. Vivier (Motorola, China) M. Wright (BT, UK) ORGANISING COMMITTEE Aziza Lounis Aziza.Lounis@rp.lip6.fr AIM and SCOPE The Home networking conference 2007 will provide an international technical forum for experts from industry and academia everywhere in the world to exchange ideas and present results of ongoing researches in home networking. Topics include, but are not limited to: Home Networking Wireless networks (Wi-Fi, UWB, ZigBee, 6LowPAN) PLC (HomePlug, OPERA, UPA, CEPCA, IEEE, etc.) DLNA, UPnP, Rally, etc. Home sensor networks Mesh networks in the home Ad hoc networks for the home Internet-Box, set-top-box, bridge, gateway, etc. Access Networks (ADSL, VDSL, optical, EPON, cable, etc.) Home Gateway DSL Forum, HGI, Home DVB QoS Management Home Network Security Autonomic Home Networking Mobility in the Home Applications (telecom, energy, consumer electronics) Performance Experiment SUBMISSION Submissions should be original and limited to 20 double spaced 12 point pages in length. Authors are requested to submit their manuscripts electronically through the EDAS web site. PROCEEDINGS AND AWARDS The proceedings of the conference will be published by SPRINGER IFIP Series and the best papers will be published in the Annals of Telecommunications (ISI indexed journal). A best paper award will be distributed. IMPORTANT DEADLINES September 5, 2007 Papers due September 30, 2007 Authors notified of acceptance October 15, 2007 Final papers due FURTHER INFORMATION For more information please visit the web site at=20 http://www.homenetworking.org --------------020000060903040507050500 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
CALL FOR PAPERS

1st Home Networking Conference 2007
IFIP TC6 Conference
IEEE (Under request)

Paris - France – December 12-14, 2007

GENERAL CHAIRS
Guy Pujolle (LIP6, France)

PROGRAM CO-CHAIRS
K. Al Agha (University of Paris XI, FR)
X. Carcelle (EDF, FR)

STEERING COMMITTEE
G. Carle (U. Tubingen)
A. Karmouch (U. Ottawa, Canada)
D. Gaïti (UTT, France)
G. Pujolle (LIP6, France)
H. Zimmermann (Ginkgo Networks, France)
PROGRAM COMMITTEE
N. Achir (U. Paris North, France)
H. Afifi (INT, France)
I. Akyildiz (Georgia Tech, USA)
G. Carle (U. Tubingen)
P. Cuenca (U. Castilla-La Mancha, Spain)
C. Chatellier (U Poitiers, Fr)
O. Duarte (UFRJ, Brazil)
D. Gaïti (UTT, France)
M. Gerla (UCLA, USA)
W. Grote (UTFSM, Chile)
U. Körner (U. Lund, Sweden)
S. Jiang (SCUT, China)
H. Latchman (U Florida, US)
S. Lohier (U. Paris East)
T. Luckenbach (FOKUS, Germany)
K. Mase (Nigata Univerity, Japan
S. Meyer (FTR&D, France)
P. Muhletaler (INRIA, France)
I.G. Niemegeers (TUD, Netherland)
C. Niedermeier (Siemens, Germany)
J. Nogueira (UFMG, Brazil)
C. Petrioli (La Sapienza, Italy)
S.V. Raghavan (IIT, India)
L. Reynaud (FTR&D, France)
T. Ritzau (Sony-Ericsson, Sweden)
J.J. Rodriguez (U Vigo, Spain)
F. Souchkoff (Microsoft)
S. Tabbane (SupCom, Tunisia)
Y. Takahashi (Kyoto University, Japan)
S. Ubeda (INSA Lyon, France)
P. Urien (ENST, France)
G. Vivier (Motorola, China)
M. Wright (BT, UK)

ORGANISING COMMITTEE
Aziza Lounis
Aziza.Lounis@rp.lip6.fr

AIM and SCOPE
The Home networking conference 2007 will provide an international
technical forum for experts from industry and academia everywhere
in the world to exchange ideas and present results of ongoing
researches in home networking. Topics include, but are not limited to:
Home Networking
Wireless networks (Wi-Fi, UWB, ZigBee, 6LowPAN)
PLC (HomePlug, OPERA, UPA, CEPCA, IEEE, etc.)
DLNA, UPnP, Rally, etc.
Home sensor networks
Mesh networks in the home
Ad hoc networks for the home
Internet-Box, set-top-box, bridge, gateway, etc.
Access Networks (ADSL, VDSL, optical, EPON, cable, etc.)
Home Gateway
DSL Forum, HGI, Home DVB
QoS Management
Home Network Security
Autonomic Home Networking
Mobility in the Home
Applications (telecom, energy, consumer electronics)
Performance
Experiment

SUBMISSION
Submissions should be original and limited to 20 double spaced 12
point pages in length. Authors are requested to submit their
manuscripts electronically through the EDAS web site.
PROCEEDINGS AND AWARDS
The proceedings of the conference will be published by SPRINGER
IFIP Series and the best papers will be published in the Annals of
Telecommunications (ISI indexed journal).
A best paper award will be distributed.

IMPORTANT DEADLINES
September 5, 2007 Papers due
September 30, 2007 Authors notified of acceptance
October 15, 2007 Final papers due

FURTHER INFORMATION
For more information please visit the web site at http://www.homenetworking.org

--------------020000060903040507050500-- --===============2142118050== 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 --===============2142118050==-- From manet-bounces@ietf.org Fri Aug 03 08:01: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 1IGvqs-0005Jk-5F; Fri, 03 Aug 2007 08:01:54 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IGvqp-0005J0-Fz for manet-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 08:01:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGvqo-0005IT-5q for manet@ietf.org; Fri, 03 Aug 2007 08:01:51 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGvqn-0000Ar-Gf for manet@ietf.org; Fri, 03 Aug 2007 08:01:50 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 03 Aug 2007 05:01:49 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANu1skarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.19,217,1183359600"; d="scan'208"; a="510011369:sNHT29241762" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l73C1mk1011098; Fri, 3 Aug 2007 05:01:48 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l73C1bPp029570; Fri, 3 Aug 2007 12:01:48 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 08:01:17 -0400 Received: from [10.81.246.130] ([10.81.246.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 08:01:17 -0400 Message-ID: <46B31903.2020304@cisco.com> Date: Fri, 03 Aug 2007 08:01:07 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Justin Dean References: <200708021849.l72Inb6n005927@s2.itd.nrl.navy.mil> In-Reply-To: <200708021849.l72Inb6n005927@s2.itd.nrl.navy.mil> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2007 12:01:17.0310 (UTC) FILETIME=[FF5FF1E0:01C7D5C5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4059; t=1186142508; x=1187006508; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bberry@cisco.com; z=From:=20Bo=20Berry=20 |Subject:=20comments=20on=20draft-dean-manet-metriclv-00 |Sender:=20; bh=v2TAZFa9AAXOxvxH94zMuXN6rzRKVtBMZ2+eZvgnoOo=; b=fSBMGU+sOpEb+u3aaf0Ir2UOltVF+He6I5FNu/ief50SDltWOu6r7WuOXfsDqaVCXLcO4+zR AgrJ51BZ7RaSszuNU5ZH9v8e+VK/viKcwEIvqwBtiWVAAFtWRZRR2t1t; Authentication-Results: sj-dkim-4; header.From=bberry@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: manet@ietf.org Subject: [manet] comments on draft-dean-manet-metriclv-00 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 Justin: Could you please provide a few message/TLV node/link examples showing the use of the metric TLV in the context of packetbb. It is not clear (yet) how to put it all together given the two drafts. It appears that there is substantial overhead if a node only needs to send one or two (8-bit) metric values as defined in the drafts. It would help to see the metric data as compared to the TLV data, and how the metric TLVs fit within the packetbb format. Thanks in advance -Bo draft-dean-manet-metriclv-00 ===================================== 6. Metric TLVs This document defines one message block TLV and one address block metric TLV. Address block TLVs are broken down further into four different generalized types; node, outbound, inbound, and symmetric. 6.1. Message TLV The message block TLV is used for signaling values associated with the local node. If a metric message TLV is to be included in a message, the 0 bit of the msg-semantics field MUST be cleared and the originator-address MUST be included in the msg-header-info as defined in [1] . 6.2. Address Block TLV The address block TVL is used for signaling values associated with addresses contained within the address block. 6.2.1. Other Node Metric TLV The cost value carried by the metric is associated with the appropriate address contained in the address block. 6.2.2. Outbound Link Metric TLV The cost value carried by the metric is associated with the directional link originating from the originator address and ending at the associated address contained in the address block. 6.2.3. Inbound Link Metric TLV The cost value carried by the metric is associated with the directional link originating from the originator address and ending at the associated address contained in the address block. 6.2.4. Symmetric Link Metric TLV The cost value carried by the metric is associated with the bi- directional link formed from the originator address and the associated address contained in the address block. 7. Metric Subtype TLVs defined in this document MUST have the hassubtype bit set to 1 in the tlv-semantics field as defined in [1] . The subtype field of a metric TLV as defined in this document is comprised of two parts, the metric representation and the value type. The three upper bits define which metric representation the values represent. Usage of these bits is defined below. The five lower bits allow for differing value types (delay and power being examples of differing value types) Usage and definitions for values included in this field is not defined in this document. >From packetbb ====================================== 5.3. TLVs and TLV Blocks A TLV block is defined by: = * where: is a 16 bit field, which contains the total length (in octets) of all of the immediately following elements. is defined in Section 5.3.1. 5.3.1. TLVs There are three kinds of TLV, each represented by an element : o A packet TLV, included in a packet header. o A message TLV, included in a message before all address blocks. o An address block TLV, included in a TLV block following an address block. An address block TLV applies to: * all addresses in the address block; OR * any continuous sequence of addresses in the address block; OR * a single address in the address block. is defined by: = ? ? ? ? ? where: is an 8 bit field, specifying the type of the TLV, specific to the TLV kind (i.e. packet, message, or address block TLV). _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Aug 04 08:25: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 1IHIhD-0000Zy-8H; Sat, 04 Aug 2007 08:25:27 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IHIhB-0000Zo-IZ for manet-confirm+ok@megatron.ietf.org; Sat, 04 Aug 2007 08:25:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHIhB-0000Zg-8e for manet@ietf.org; Sat, 04 Aug 2007 08:25:25 -0400 Received: from kuber.nabble.com ([216.139.236.158]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHIhA-0007W2-Vr for manet@ietf.org; Sat, 04 Aug 2007 08:25:25 -0400 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IHIhA-0007hv-FM for manet@ietf.org; Sat, 04 Aug 2007 05:25:24 -0700 Message-ID: <11996160.post@talk.nabble.com> Date: Sat, 4 Aug 2007 05:25:24 -0700 (PDT) From: Saleemsheikh To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: shm_saleem@yahoo.com X-Spam-Score: 1.4 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [manet] Script required 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 , i want to simulate MANET , i am new user to the field of MANET & NS2 , any body have any idea how i start , i also want to make them in the form of clusters, did any one have any simple script plz forwarded me. Thanks in advance Regards, Saleem -- View this message in context: http://www.nabble.com/Script-required-tf4216619.html#a11996160 Sent from the IETF - manet mailing list archive at Nabble.com. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Aug 04 15:42: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 1IHPVc-0002Sw-R5; Sat, 04 Aug 2007 15:41:56 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IHPVb-0002MW-9m for manet-confirm+ok@megatron.ietf.org; Sat, 04 Aug 2007 15:41:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHPVa-0002Lp-Vs; Sat, 04 Aug 2007 15:41:54 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHPVa-0007O3-OV; Sat, 04 Aug 2007 15:41:54 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A30C326E72; Sat, 4 Aug 2007 19:41:54 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IHPVa-0001p4-IY; Sat, 04 Aug 2007 15:41:54 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Sat, 04 Aug 2007 15:41:54 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: manet@ietf.org Subject: [manet] Last Call: draft-ietf-manet-iana (Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group) to Proposed Standard X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-08-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15731&rfc_flag=0 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 06 04:33: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 1IHy1p-0008IV-Dq; Mon, 06 Aug 2007 04:33:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IHy1o-0008IO-9O for manet-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 04:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHy1n-0008IG-W8 for manet@ietf.org; Mon, 06 Aug 2007 04:33:27 -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 1IHy1k-0008MH-Lp for manet@ietf.org; Mon, 06 Aug 2007 04:33:27 -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 l768XNsV006983 for ; Mon, 6 Aug 2007 09:33:23 +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 l768XNUj023597 for ; Mon, 6 Aug 2007 09:33:23 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Aug 2007 09:33:23 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 09:33:22 +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] How to distinguish MANET interfaces and other interfaces? Date: Mon, 6 Aug 2007 09:33:22 +0100 Message-ID: In-Reply-To: <1716228e0707231533k36f542b9v57cdd01b08b30f20@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] How to distinguish MANET interfaces and other interfaces? Thread-Index: AcfNeYoJsYWsa5ZRSN6BimZ/0wPSCgKill+w References: <1716228e0707231529u659df9dcs294cc6689336fc9c@mail.gmail.com> <1716228e0707231533k36f542b9v57cdd01b08b30f20@mail.gmail.com> From: "Dearlove, Christopher \(UK\)" To: "?????" , X-OriginalArrivalTime: 06 Aug 2007 08:33:22.0876 (UTC) FILETIME=[73459FC0:01C7D804] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 From: yowada@net.ie.niigata-u.ac.jp > In the NHDP-04, 10.1.1, OTHER_IF is used for distinguish MANET interface or not. Not quite. OTHER_IF is used to distinguish addresses which are not from this MANET interface. Addresses from non-MANET interfaces will be signalled as OTHER_IF on all MANET interfaces, addresses from a MANET interface will be signalled as OTHER_IF on other MANET interfaces. For example if a node has MANET interfaces with addresses A and B, and a non-MANET interface with address C, then on interface A, addresses B and C will use OTHER_IF. ******************************************************************** 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 Aug 06 04:40: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 1IHy8l-0003Vr-Pe; Mon, 06 Aug 2007 04:40:39 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IHy8k-0003Vm-P1 for manet-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 04:40:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHy8k-0003Ve-Fc for manet@ietf.org; Mon, 06 Aug 2007 04:40:38 -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 1IHy8i-0008WD-OT for manet@ietf.org; Mon, 06 Aug 2007 04:40:38 -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 l768eaQC012071 for ; Mon, 6 Aug 2007 09:40:36 +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 l768eZbD018021 for ; Mon, 6 Aug 2007 09:40:35 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Aug 2007 09:40:35 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 09:40:35 +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] Comments on draft-ietf-manet-packetbb-08 Date: Mon, 6 Aug 2007 09:40:34 +0100 Message-ID: In-Reply-To: <46AB2EAD.7020708@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Comments on draft-ietf-manet-packetbb-08 Thread-Index: AcfRDkim4OVTVZQ0SrKiAJoGAHOurQG9mmjw References: <46AB2EAD.7020708@cisco.com> From: "Dearlove, Christopher \(UK\)" To: "Bo Berry" , X-OriginalArrivalTime: 06 Aug 2007 08:40:35.0250 (UTC) FILETIME=[74FCA920:01C7D805] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 From: Bo Berry [mailto:bberry@cisco.com]=20 >From a routing perspective, it could be beneficial to run >the MANET protocol directly over IP. This would require >the allocation of an IP Protocol Type and definition >of supporting headers. IP protocol types are rather precious, there are only 256 of them, a lot already taken. I know DSR got one, but DSR has a rather complicated interaction with IP, and the authors successfully argued that they needed one. Is it important enough to do so here? Of course as far as packetbb is concerned, fine. I believe we intend to remove the one reference to UDP in packetbb on the grounds that there is no reason, in packetbb, to favour UDP. (In protocols using packetbb, that's a different issue.) ******************************************************************** 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 Aug 06 12:17: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 1II5HB-0008ME-7h; Mon, 06 Aug 2007 12:17:49 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1II5H6-0008Lk-Mx for manet-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 12:17:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II5H6-0008KS-4K for manet@ietf.org; Mon, 06 Aug 2007 12:17:44 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II5H5-0003xB-MS for manet@ietf.org; Mon, 06 Aug 2007 12:17:44 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Aug 2007 12:17:44 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANLmtkZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.19,225,1183348800"; d="scan'208"; a="67201177:sNHT29173490" 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 l76GHh9Q001304; Mon, 6 Aug 2007 12:17:43 -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 l76GHhmd011441; Mon, 6 Aug 2007 16:17:43 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 12:17:42 -0400 Received: from [10.81.246.166] ([10.81.246.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 12:17:42 -0400 Message-ID: <46B749A5.6070809@cisco.com> Date: Mon, 06 Aug 2007 12:17:41 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Comments on draft-ietf-manet-packetbb-08 References: <46AB2EAD.7020708@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Aug 2007 16:17:42.0683 (UTC) FILETIME=[5102CEB0:01C7D845] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2615; t=1186417063; x=1187281063; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bberry@cisco.com; z=From:=20Bo=20Berry=20 |Subject:=20Re=3A=20[manet]=20Comments=20on=20draft-ietf-manet-packetbb-0 8 |Sender:=20 |To:=20=22Dearlove, =20Christopher=20\(UK\)=22=20; bh=qSbTnd71ffDM81pf9trOp7rKPaL4xukIrFjromKsiCg=; b=Nz3z16ueS8FPEl5NCDAeUZu0ZmPrcYY9XuzmOvUR/voK3plACPiPW7aMaUI/EfI7/l7E+Ap3 wC+tH4MrZ+T+UirjaUM1r8KLthpzSqXjs/slca2lebHuqV7FkL9jRMSQ; Authentication-Results: rtp-dkim-2; header.From=bberry@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: manet@ietf.org 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 Dearlove, Christopher (UK) wrote: > From: Bo Berry [mailto:bberry@cisco.com] >>From a routing perspective, it could be beneficial to run >> the MANET protocol directly over IP. This would require >> the allocation of an IP Protocol Type and definition >> of supporting headers. > > IP protocol types are rather precious, there are only 256 > of them, a lot already taken. I know DSR got one, but DSR > has a rather complicated interaction with IP, and the > authors successfully argued that they needed one. Is it > important enough to do so here? I think there is value defining the MANET protocol at the IP layer and adjusting packetbb to account for it. For example, the 6loWPAN draft made several simplification changes to support fixed packets and run at the link layer. Perhaps adjustments for a MANET protocol at the IP layer could bring a common solution for the two WGs, specifically since the two WGs need to consider similar problems. Packet Building Block and DYMO Applicability for 6LoWPAN draft-oh-6lowpan-packetbb-dymoapp-01 ""This can be achieved by applying existing routing protocols or designing new ones, if necessary. A number of experimental protocols have been developed in the Mobile Ad-hoc Networks (MANET) working group, such as AODV [RFC3561], OLSR [RFC3626], or DYMO [I-D.ietf-manet-dymo]. These protocols, however, are designed to use IP-based addresses and impose large overhead on LoWPAN devices. LoWPAN devices are characterized by short range, low bit rate, low power and low cost [ieee802.15.4], and it is required that the routing packets fit within a single IEEE 802.15.4 frame to reduce packet overhead and energy consumption. Thus, simplification of routing packets and operations must be done in order to reuse the existing solutions in below IP layer."" > > Of course as far as packetbb is concerned, fine. I believe > we intend to remove the one reference to UDP in packetbb > on the grounds that there is no reason, in packetbb, to > favour UDP. (In protocols using packetbb, that's a different > issue.) > > ******************************************************************** > 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 Aug 06 21:06:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIDWL-0004u3-67; Mon, 06 Aug 2007 21:06:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IIDWK-0004ty-28 for manet-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 21:06:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIDWJ-0004tq-Oo for manet@ietf.org; Mon, 06 Aug 2007 21:05:59 -0400 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIDWJ-00085p-5M for manet@ietf.org; Mon, 06 Aug 2007 21:05:59 -0400 Received: by rv-out-0910.google.com with SMTP id f1so1153830rvb for ; Mon, 06 Aug 2007 18:05:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=rgxOEfpb18BQeivnKdm5X/onRuyLQLdOvOFxxp+iiMh+7B2WOROOQ7+uMBwZhmm5AmhdO/uku0Cqu6Q1u2UrXZIozpg67+HHWNnT7VCj+SdVsNEz9fs1G3A6b47mJ1fW6acnYCJ56NP8PfvC2MvCbEvaZ0FpbPDX5UNzT+7QwnE= 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=eO4G/fEviZaKKSPkrE8RsKQERtT2wgh4zB29EPy1aahKrI7rg/LPdPmKVfVm9/LzrhTDYpMyxNWXwT+YyxYx9qKXbz+YfOY34a8gHllpLScjWTMLBy87/NaXXwvtLPFJmI9rK8aHYeCNhmd049qGURn0goO3sONDdaxxeerOGoo= Received: by 10.141.70.18 with SMTP id x18mr2337338rvk.1186448758505; Mon, 06 Aug 2007 18:05:58 -0700 (PDT) Received: by 10.141.98.2 with HTTP; Mon, 6 Aug 2007 18:05:58 -0700 (PDT) Message-ID: <2a3692de0708061805q312997c3q67d3decc0b0589a2@mail.gmail.com> Date: Tue, 7 Aug 2007 10:05:58 +0900 From: "Dominik Kaspar" To: "Bo Berry" Subject: Re: [manet] Comments on draft-ietf-manet-packetbb-08 In-Reply-To: <46B749A5.6070809@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46AB2EAD.7020708@cisco.com> <46B749A5.6070809@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org 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, Speaking on behalf of the draft "Packet Building Block and DYMO Applicability for 6LoWPAN" (draft-oh-6lowpan-packetbb-dymoapp-01), I agree that there is no reason for packetbb to favor UDP (or any transport protocol) for the diffusion mechanism. And I'm not sure how widespread the usage of DSR is... but I certainly see that MANET could also justify its importance in the routing area, in order to obtain an IANA Protocol Number. Dominik On 8/7/07, Bo Berry wrote: > > > Dearlove, Christopher (UK) wrote: > > From: Bo Berry [mailto:bberry@cisco.com] > >>From a routing perspective, it could be beneficial to run > >> the MANET protocol directly over IP. This would require > >> the allocation of an IP Protocol Type and definition > >> of supporting headers. > > > > IP protocol types are rather precious, there are only 256 > > of them, a lot already taken. I know DSR got one, but DSR > > has a rather complicated interaction with IP, and the > > authors successfully argued that they needed one. Is it > > important enough to do so here? > > I think there is value defining the MANET protocol at the IP > layer and adjusting packetbb to account for it. For example, > the 6loWPAN draft made several simplification changes to > support fixed packets and run at the link layer. Perhaps > adjustments for a MANET protocol at the IP layer could bring > a common solution for the two WGs, specifically since the > two WGs need to consider similar problems. > > > Packet Building Block and DYMO Applicability for 6LoWPAN > draft-oh-6lowpan-packetbb-dymoapp-01 > ""This can be achieved by applying existing routing protocols or > designing new ones, if necessary. A number of experimental protocols > have been developed in the Mobile Ad-hoc Networks (MANET) working > group, such as AODV [RFC3561], OLSR [RFC3626], or DYMO > [I-D.ietf-manet-dymo]. These protocols, however, are designed to use > IP-based addresses and impose large overhead on LoWPAN devices. > LoWPAN devices are characterized by short range, low bit rate, low > power and low cost [ieee802.15.4], and it is required that the > routing packets fit within a single IEEE 802.15.4 frame to reduce > packet overhead and energy consumption. Thus, simplification of > routing packets and operations must be done in order to reuse the > existing solutions in below IP layer."" > > > > > Of course as far as packetbb is concerned, fine. I believe > > we intend to remove the one reference to UDP in packetbb > > on the grounds that there is no reason, in packetbb, to > > favour UDP. (In protocols using packetbb, that's a different > > issue.) > > > > ******************************************************************** > > 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 Tue Aug 07 00:35:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIGmQ-0007iX-IM; Tue, 07 Aug 2007 00:34:50 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IIGmO-0007iR-NA for manet-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 00:34:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIGmO-0007iI-Db for manet@ietf.org; Tue, 07 Aug 2007 00:34:48 -0400 Received: from fk-out-0910.google.com ([209.85.128.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIGmO-0003Bo-3U for manet@ietf.org; Tue, 07 Aug 2007 00:34:48 -0400 Received: by fk-out-0910.google.com with SMTP id z23so1574838fkz for ; Mon, 06 Aug 2007 21:34:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=AEt8TnCS4TDxuvW1yIciYgneeH+3vbzY4RY3g27RIxBBdVe67Hwuse2b7XAut2r/yTLoPYm+m2GLtPnREt3TLbEt47v8VoDVsKMNnRFYO0TOupPNVQKm6dvElkJNwIb23sEgoWVORHLzYAAEjAIimVRqFSr1NGU81zhyLBGD4Io= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=X7WAoHoaHzBdRyjg0VLIGE3I4fYji0WxQlYzoPgtPVSJGAvdrSWEFELhpfxSoPNIEluOs9dZ3CMt6Is8zX/yNVcAYxskFLV7Hl8k9cbXzpOWpU88PC3a4hvwcqsVM/bk/ygXRIvcU6de+qRrUI/ArSEzuDLcKwUvJqc/DhpdeCc= Received: by 10.82.136.4 with SMTP id j4mr6252930bud.1186461287214; Mon, 06 Aug 2007 21:34:47 -0700 (PDT) Received: by 10.82.105.20 with HTTP; Mon, 6 Aug 2007 21:34:47 -0700 (PDT) Message-ID: <87082b010708062134q46f62e0dqa8f0f9ed89998146@mail.gmail.com> Date: Tue, 7 Aug 2007 06:34:47 +0200 From: "wafa Berrayana" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [manet] QoS AODV 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="===============1813722153==" Errors-To: manet-bounces@ietf.org --===============1813722153== Content-Type: multipart/alternative; boundary="----=_Part_174793_30880895.1186461287191" ------=_Part_174793_30880895.1186461287191 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, Please did someone have an implementation of QoS AODV under NS or J-SIM simulators ? I would be very grateful if you send it me. Have a nice day. Wafa ------=_Part_174793_30880895.1186461287191 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,
Please did someone have an implementation of QoS AODV under NS or J-SIM simulators ? I would be very grateful if you send it me.
Have a nice day.
Wafa
------=_Part_174793_30880895.1186461287191-- --===============1813722153== 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 --===============1813722153==-- From manet-bounces@ietf.org Wed Aug 08 11:06: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 1IIn5n-0000I6-1i; Wed, 08 Aug 2007 11:04:59 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IIn5k-0000Ht-IP for manet-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 11:04:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIn5k-0000Hk-5T; Wed, 08 Aug 2007 11:04:56 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IIn5j-0002ei-3C; Wed, 08 Aug 2007 11:04:56 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmc46ba246b; Wed, 08 Aug 2007 23:16:49 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm4f46b5424f; Sun, 05 Aug 2007 05:16:30 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sun, 05 Aug 2007 05:16:30 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHPVf-0002d9-3N; Sat, 04 Aug 2007 15:41:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHPVa-0002Lp-Vs; Sat, 04 Aug 2007 15:41:54 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHPVa-0007O3-OV; Sat, 04 Aug 2007 15:41:54 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A30C326E72; Sat, 4 Aug 2007 19:41:54 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IHPVa-0001p4-IY; Sat, 04 Aug 2007 15:41:54 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Sat, 04 Aug 2007 15:41:54 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 4.0 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: manet@ietf.org Subject: [manet] Last Call: draft-ietf-manet-iana (Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group) to Proposed Standard X-BeenThere: manet@ietf.org Reply-To: ietf@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-08-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15731&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Aug 08 15:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIreA-00045r-TC; Wed, 08 Aug 2007 15:56:46 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IIre9-0003zH-5r for manet-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 15:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIre8-0003xd-Rh for manet@ietf.org; Wed, 08 Aug 2007 15:56:44 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIre7-0001Gp-Fz for manet@ietf.org; Wed, 08 Aug 2007 15:56:44 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 08 Aug 2007 12:56:36 -0700 X-IronPort-AV: i="4.19,237,1183359600"; d="scan'208"; a="196645556:sNHT25097212350" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l78JuZ1o025696; Wed, 8 Aug 2007 12:56:35 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l78JtZWT011456; Wed, 8 Aug 2007 19:56:35 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 15:56:15 -0400 Received: from [64.102.55.188] ([64.102.55.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 15:56:15 -0400 In-Reply-To: <000301c7d53e$858234a0$165cfa84@SEXTANT> References: <000001c7d349$0cac24b0$b500800a@Teco> <000301c7d53e$858234a0$165cfa84@SEXTANT> 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: "Edward J. Paradise" Subject: Re: [manet] RE: DPD for IPv6 - fragmentation support Date: Wed, 8 Aug 2007 15:56:16 -0400 To: Joe Macker X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 Aug 2007 19:56:15.0951 (UTC) FILETIME=[2DF435F0:01C7D9F6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3922; t=1186602995; x=1187466995; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pdice@cisco.com; z=From:=20=22Edward=20J.=20Paradise=22=20 |Subject:=20Re=3A=20[manet]=20RE=3A=20DPD=20for=20IPv6=20-=20fragmentatio n=20support |Sender:=20; bh=dV7e5WCfj4gw8xFJszQbHOXDpTjaoO/i31bz4Fhqk8c=; b=WcpbJRpyNZ3L8rGXiTgkOlEI2XMHFugb/dtG2ZrwG9X+NvBMZsPWWkeZoDgLMGtVT/5SOdUP kh6i3ZCwcZzI3qbU9NxI+sxFz04gD3Q4F59A4uqG2MticgDH6eEz+mtF; Authentication-Results: sj-dkim-2; header.From=pdice@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: manet@ietf.org 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 Do you think it would be possible in the 06 draft to include a flow chart in appendix A, "Source-based Multipoint Relay (S-MPR)", that describes the forwarding algorithm for implementations using S-MPR? I found it hard to follow when a packet should be marked and what decisions should be made based on those markings with respect to multiple interfaces. Also, you referenced border gateway experiments with PIM in the draft and during your IETF presentation. Do you have any examples you could share? -ed On Aug 2, 2007, at 3:51 PM, Joe Macker wrote: > Hi Teco: > > Yes, IPv6 source fragmentation packets will be supported at least > that is > the plan for now. Yes the identification field is helpful in that > case and > can be used. > > Re. hashing, yes we are adding hashing for IPv4 as well as an option. > Mutable fields need to be skipped as you point out. > > Document changes planned in -06: > > - Revise IPv4 SMF DPD, expand tuple processing, no ID field > modification, > support fragmentation, support optional hashing as per IPv6 > - Revise IPv6 SMF DPD to support IPv6 source-based fragmentation > (no header > option should be needed) > - Editorial changes throughout (Templin's comments/others) > - Provide clearer discussion of implementation requirements for > interoperability. > > >> -----Original Message----- >> From: Teco_Boot [mailto:teco@inf-net.nl] >> Sent: Tuesday, July 31, 2007 4:01 AM >> To: 'Joe Macker' >> Cc: manet@ietf.org >> Subject: DPD for IPv6 - fragmentation support >> >> Hi Joe, >> >> >> >> As fragmentation with IPv4 is to be supported, IPv6 >> fragmentation support can be considered too. >> >> It even brings efficiency, as adding the DPD header is >> eliminated if a fragment header was included by the source. >> >> Draft algorithm below. I am not sure about the optional >> tagging *), this depends on the --to be written-- rules for >> used SMF mechanisms in a MANET. >> >> >> >> I am not a protocol implementer. But if, I would consider a >> single hash table for IPv4 and IPv6 and run the hash algorithm >> over those fields that guarantee uniqueness, or over the first >> N octets of a frame with blanked fields TTL, TOS and >> hop-by-hop & routing headers. Code maintaining the table and >> performing fast lookups would be shared for all types of traffic. >> >> >> >> Teco. >> >> >> >> >> >> +-------------+-----------------+-------------+---------------- >> --------------------------+ >> >> |IPsec header | Fragment header | DPD header | action >> | >> >> +-------------+-----------------+-------------+---------------- >> --------------------------+ >> >> | present | * | * | IPsec header >> DPD check and forward | >> >> | not present | present | not present | Fragment >> header DPD check and forward (1)| >> >> | not present | present | present | invalid, do >> not forward (2) | >> >> | not present | not present | not present | Optionally tag >> and forward (3) | >> >> | not present | not present | present | DPD header DPD >> check and forward | >> >> +-------------+-----------------+-------------+---------------- >> --------------------------+ >> >> >> >> 1: DPD check based on >> >> >> >> >> 2: SMF shall use fragment header if present. Adding DPD header >> should never occur. >> >> >> >> 3: Received packets are sent by connected hosts or forwarded >> by MANET SMF routers implementing DPD based on hashing. >> Tagging is optional *). >> >> >> >> >> >> >> >> > > > > > _______________________________________________ > 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 Aug 08 17:10: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 1IIsln-00038N-24; Wed, 08 Aug 2007 17:08:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IIsll-00037t-Nf for manet-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 17:08:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIsll-00037R-Ar for manet@ietf.org; Wed, 08 Aug 2007 17:08:41 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIslk-0002UL-M0 for manet@ietf.org; Wed, 08 Aug 2007 17:08:41 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l78L7quj023810; Wed, 8 Aug 2007 17:07:52 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007080817075118504 ; Wed, 08 Aug 2007 17:07:51 -0400 From: "Joe Macker" To: "'Edward J. Paradise'" References: <000001c7d349$0cac24b0$b500800a@Teco> <000301c7d53e$858234a0$165cfa84@SEXTANT> Subject: RE: [manet] RE: DPD for IPv6 - fragmentation support Date: Wed, 8 Aug 2007 17:07:49 -0400 Message-ID: <008b01c7da00$2cf4e2d0$165cfa84@SEXTANT> 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.3138 Thread-Index: AcfZ9j9Ew/6Xp0o7SMS2AezB5xfCAwABTy+w In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: manet@ietf.org 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 Ed: The PIM gateway we have running simple proxy approach at the gateway Ethernet interface in our experiment. SMF supports forwarding between the interfaces (MANET wireless on one side and Ethernet in this case). This was a simple stub network configuration and was used in our wireless-based emulator. We did some international IPv6 lab-to-lab with this at one point. I might delete this from the ID, but it does provide a basic example of interfacing SMF to a backbone PIM-cloud. There are multiple considerations and methods to accomplish this obviously and is ongoing work. S-MPR question obviously the previous-hop dependency is an issue and is pointed out. OLSRv2 spec discusses multiple interface S-MPR issues and we reference it. I hope that's a start. It's a good comment and has some implementation specific issues that may be done multiple ways but the expected behavior for interoperability should be understood. -Joe >-----Original Message----- >From: Edward J. Paradise [mailto:pdice@cisco.com] >Sent: Wednesday, August 08, 2007 3:56 PM >To: Joe Macker >Cc: 'Teco_Boot'; manet@ietf.org >Subject: Re: [manet] RE: DPD for IPv6 - fragmentation support > >Do you think it would be possible in the 06 draft to include a >flow chart in appendix A, "Source-based Multipoint Relay >(S-MPR)", that >describes the forwarding algorithm for implementations using S-MPR? >I found it hard to follow when a packet should be marked and >what decisions should be made based on those markings with >respect to multiple interfaces. Also, you referenced border >gateway experiments with PIM in the draft and during your IETF >presentation. Do you have any examples you could share? -ed > >On Aug 2, 2007, at 3:51 PM, Joe Macker wrote: > >> Hi Teco: >> >> Yes, IPv6 source fragmentation packets will be supported at >least that >> is the plan for now. Yes the identification field is helpful in that >> case and can be used. >> >> Re. hashing, yes we are adding hashing for IPv4 as well as an option. >> Mutable fields need to be skipped as you point out. >> >> Document changes planned in -06: >> >> - Revise IPv4 SMF DPD, expand tuple processing, no ID field >> modification, support fragmentation, support optional hashing as per >> IPv6 >> - Revise IPv6 SMF DPD to support IPv6 source-based fragmentation (no >> header option should be needed) >> - Editorial changes throughout (Templin's comments/others) >> - Provide clearer discussion of implementation requirements for >> interoperability. >> >> >>> -----Original Message----- >>> From: Teco_Boot [mailto:teco@inf-net.nl] >>> Sent: Tuesday, July 31, 2007 4:01 AM >>> To: 'Joe Macker' >>> Cc: manet@ietf.org >>> Subject: DPD for IPv6 - fragmentation support >>> >>> Hi Joe, >>> >>> >>> >>> As fragmentation with IPv4 is to be supported, IPv6 >>> fragmentation support can be considered too. >>> >>> It even brings efficiency, as adding the DPD header is >>> eliminated if a fragment header was included by the source. >>> >>> Draft algorithm below. I am not sure about the optional >>> tagging *), this depends on the --to be written-- rules for >>> used SMF mechanisms in a MANET. >>> >>> >>> >>> I am not a protocol implementer. But if, I would consider a >>> single hash table for IPv4 and IPv6 and run the hash algorithm >>> over those fields that guarantee uniqueness, or over the first >>> N octets of a frame with blanked fields TTL, TOS and >>> hop-by-hop & routing headers. Code maintaining the table and >>> performing fast lookups would be shared for all types of traffic. >>> >>> >>> >>> Teco. >>> >>> >>> >>> >>> >>> +-------------+-----------------+-------------+---------------- >>> --------------------------+ >>> >>> |IPsec header | Fragment header | DPD header | action >>> | >>> >>> +-------------+-----------------+-------------+---------------- >>> --------------------------+ >>> >>> | present | * | * | IPsec header >>> DPD check and forward | >>> >>> | not present | present | not present | Fragment >>> header DPD check and forward (1)| >>> >>> | not present | present | present | invalid, do >>> not forward (2) | >>> >>> | not present | not present | not present | Optionally tag >>> and forward (3) | >>> >>> | not present | not present | present | DPD header DPD >>> check and forward | >>> >>> +-------------+-----------------+-------------+---------------- >>> --------------------------+ >>> >>> >>> >>> 1: DPD check based on >>> >>> >>> >>> >>> 2: SMF shall use fragment header if present. Adding DPD header >>> should never occur. >>> >>> >>> >>> 3: Received packets are sent by connected hosts or forwarded >>> by MANET SMF routers implementing DPD based on hashing. >>> Tagging is optional *). >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> _______________________________________________ >> 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 Thu Aug 09 11:16: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 1IJ9iJ-0007Wk-Mu; Thu, 09 Aug 2007 11:14:15 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJ9iH-0007WY-Rc for manet-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 11:14:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ9iH-0007WQ-Gq; Thu, 09 Aug 2007 11:14:13 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ9iH-0005pf-4d; Thu, 09 Aug 2007 11:14:13 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Aug 2007 11:14:13 -0400 X-IronPort-AV: i="4.19,240,1183348800"; d="scan'208"; a="67545215:sNHT55101202" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l79FECxj030862; Thu, 9 Aug 2007 11:14:12 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l79FEAmt003672; Thu, 9 Aug 2007 15:14:12 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 11:13:44 -0400 Received: from [10.81.246.170] ([10.81.246.170]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 11:13:44 -0400 Message-ID: <46BB2F27.2010408@cisco.com> Date: Thu, 09 Aug 2007 11:13:43 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: [manet] Last Call: draft-ietf-manet-iana (Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group) to Proposed Standard References: In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2007 15:13:44.0150 (UTC) FILETIME=[E04E6760:01C7DA97] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2125; t=1186672452; x=1187536452; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bberry@cisco.com; z=From:=20Bo=20Berry=20 |Subject:=20Re=3A=20[manet]=20Last=20Call=3A=20draft-ietf-manet-iana=20(I nternet=20Assigned=20Numbers=0A=20Authority=20(IANA)=20Allocations=20for=2 0the=20Mobile=20Ad=20hoc=20Networks=20=20(MANET)=20Working=0A=20Group)=20t o=20Proposed=20Standard |Sender:=20 |To:=20ietf@ietf.org; bh=qkwwHJ+FDmDgrRpi/NUcOCZHFz0DS7rehzYdBPz+afg=; b=MyVxXu4B8U1Ds0huMprQXEIXE17ZASjc8keVpnil2AKfY1sKbHj0aauVb/Bkdc9GwTxLzjVA fuO+TUssXUD8TpPX0UvSSoZj1baApm6A3LBR0wfBBPW8M1jTRaI6eOb7; Authentication-Results: rtp-dkim-1; header.From=bberry@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: manet@ietf.org, IETF-Announce 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 Given that the WG is working to define two standards - Reactive MANET Protocol (RMP) - Proactive MANET Protocol (PMP) that may or may not converge, do we need to allocate two port numbers so these protocols can co-exist? There has also been a suggestion to allocate an IP protocol number for a MANET routing protocol. Should this be included in this draft? The various MANET protocols are moving to packetbb which will require the definition of several/many TLV identifiers. Where are these type IDs going to be allocated and tracked? If in the separate protocol drafts, is there a potential problem with overlap if IDs? If so, perhaps the MANET type IDs should be defined here. draft-ietf-manet-packetbb-08 currently reserves IDs "Message type 0 MUST NOT be allocated because a zero-octet signifies a packet header and zero-octets are used for padding. Message types 1 to 4 are reserved because they are used by OLSR [4], which uses a compatible packet/message header format." Thanks -Bo The IESG wrote: > The IESG has received a request from the Mobile Ad-hoc Networks WG > (manet) to consider the following document: > > - 'Internet Assigned Numbers Authority (IANA) Allocations for the > Mobile Ad hoc Networks (MANET) Working Group ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2007-08-18. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-05.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15731&rfc_flag=0 > > > > _______________________________________________ > 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 Thu Aug 09 13:56:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCDO-0001uO-7n; Thu, 09 Aug 2007 13:54:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJCDM-0001tM-Ac for manet-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 13:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCDL-0001sk-W2 for manet@ietf.org; Thu, 09 Aug 2007 13:54:28 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJCDJ-00081S-MV for manet@ietf.org; Thu, 09 Aug 2007 13:54:27 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1342814uge for ; Thu, 09 Aug 2007 10:54:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=Cuw0FqIEQKCvZMUgiahlqp5t1c4HgVGPx+PG9d3MFUp6+GUpTQtvV+6AX4grLx4Jez+WFZAn+fE5LFDXjTmPdfoor+ZBWJplgzWxqXefFUf9vMa2CH7YCpA5swvfVQyCetczbCNa3LF3J86l9Rh0DsvPO54rtO1fjo3Ul1tqmkw= 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=DKbnM7sifmEFVsptPPW06HHrDojEmThzMqIpPlqmK74I1drK4Rg4bQMGHx9w+drxUD1UhdtmEKtubo86S/aD1eh9k9fiI5/J6sq/N7mq45iVDqz/ZuHfSYVA2iEBKa0jfoHqKFOQUvh9wIN9i7QzVRigAApz4mpNgQDNR+BdyXc= Received: by 10.78.159.7 with SMTP id h7mr620388hue.1186682062371; Thu, 09 Aug 2007 10:54:22 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Thu, 9 Aug 2007 10:54:21 -0700 (PDT) Message-ID: <374005f30708091054u56210464o4319f88f9a4d3867@mail.gmail.com> Date: Thu, 9 Aug 2007 23:24:21 +0530 From: "Ian Chakeres" To: "Bo Berry" Subject: Re: [manet] Last Call: draft-ietf-manet-iana (Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group) to Proposed Standard In-Reply-To: <46BB2F27.2010408@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46BB2F27.2010408@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: manet@ietf.org, ietf@ietf.org 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 decision to allocate one port was discussed in the MANET group. We chose to reserve a single port to allow multiple protocols to be used together. For example, it is extremely likely that NHDP will be used with both DYMO and OLSRv2. Before you voiced your suggestion to allocate an IP protocol number, the issue has never arisen. Unless there is WG support to allocate an IP protocol number, I do not think it will be allocated. Regarding packetbb IANA considerations and other MANET WG protocols additional IANA needs they are addressed in their documents. For example, see packetbb's IANA section. Ian On 8/9/07, Bo Berry wrote: > > Given that the WG is working to define two standards > - Reactive MANET Protocol (RMP) > - Proactive MANET Protocol (PMP) > that may or may not converge, do we need to allocate > two port numbers so these protocols can co-exist? > > There has also been a suggestion to allocate an IP protocol > number for a MANET routing protocol. Should this be > included in this draft? > > The various MANET protocols are moving to packetbb which > will require the definition of several/many TLV identifiers. > Where are these type IDs going to be allocated and tracked? > If in the separate protocol drafts, is there a potential > problem with overlap if IDs? If so, perhaps the MANET > type IDs should be defined here. > > draft-ietf-manet-packetbb-08 currently reserves IDs > "Message type 0 MUST NOT be allocated because a zero-octet signifies a > packet header and zero-octets are used for padding. Message types 1 > to 4 are reserved because they are used by OLSR [4], which uses a > compatible packet/message header format." > > > > Thanks > -Bo > > > > The IESG wrote: > > The IESG has received a request from the Mobile Ad-hoc Networks WG > > (manet) to consider the following document: > > > > - 'Internet Assigned Numbers Authority (IANA) Allocations for the > > Mobile Ad hoc Networks (MANET) Working Group ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2007-08-18. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either case, please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-05.txt > > > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15731&rfc_flag=0 > > > > > > > > _______________________________________________ > > 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 Thu Aug 09 14:11:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCSX-0008Uq-4H; Thu, 09 Aug 2007 14:10:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJCSV-0008MV-7Y for manet-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 14:10:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCSU-0008LR-Pn; Thu, 09 Aug 2007 14:10:06 -0400 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJCSU-0002L3-5d; Thu, 09 Aug 2007 14:10:06 -0400 Received: from hpsmtp-eml05.kpnxchange.com ([213.75.38.105]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 20:10:05 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Aug 2007 20:09:21 +0200 From: "Teco Boot" To: "'Ian Chakeres'" , "'Bo Berry'" Subject: RE: [manet] Last Call: draft-ietf-manet-iana (Internet AssignedNumbers Authority (IANA) Allocations for the Mobile Ad hocNetworks (MANET) Working Group) to Proposed Standard Date: Thu, 9 Aug 2007 20:09:50 +0200 Message-ID: <000001c7dab0$7b32bb10$0202a8c0@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <374005f30708091054u56210464o4319f88f9a4d3867@mail.gmail.com> Thread-Index: AcfarucdFtSPIKqkTcyP3I73qICEwgAAOBsg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 09 Aug 2007 18:09:22.0024 (UTC) FILETIME=[695E5E80:01C7DAB0] X-Spam-Score: 2.7 (++) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: manet@ietf.org, ietf@ietf.org 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 wrote: > Before you voiced your suggestion to allocate an IP protocol number, > the issue has never arisen. Unless there is WG support to allocate an > IP protocol number, I do not think it will be allocated. > [Teco] I did rise this question before, see below. Maybe the issue is not that important; UDP overhead is 8 octets, brings checksum and could take advantage of header compression for UDP. But using a native IP protocol is more in line with other IETF routing protocols. -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl] Sent: woensdag 25 april 2007 13:28 To: 'Ian Chakeres' Cc: manet@ietf.org Subject: [manet] manet-iana WG Last Call: site-local address and UDP only Hi Ian, You request a site-local multicast address. I cannot find any usage of it in the current I-Ds. Do we need this? Or always perform hop-by-hop forwarding using a link-local address? I think the latter is used by OLSRv2 and DYMO protocols, but I can miss something. You also do not request an IP protocol number. Maybe I missed a discussion before and the outcome could be using UDP only, (may be TCP also). I cannot find any reference. Using UDP checksum is a reason. Regards, Teco _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > Regarding packetbb IANA considerations and other MANET WG protocols > additional IANA needs they are addressed in their documents. For > example, see packetbb's IANA section. > > Ian > > On 8/9/07, Bo Berry wrote: > > > > Given that the WG is working to define two standards > > - Reactive MANET Protocol (RMP) > > - Proactive MANET Protocol (PMP) > > that may or may not converge, do we need to allocate > > two port numbers so these protocols can co-exist? > > > > There has also been a suggestion to allocate an IP protocol > > number for a MANET routing protocol. Should this be > > included in this draft? > > > > The various MANET protocols are moving to packetbb which > > will require the definition of several/many TLV identifiers. > > Where are these type IDs going to be allocated and tracked? > > If in the separate protocol drafts, is there a potential > > problem with overlap if IDs? If so, perhaps the MANET > > type IDs should be defined here. > > > > draft-ietf-manet-packetbb-08 currently reserves IDs > > "Message type 0 MUST NOT be allocated because a zero-octet signifies > a > > packet header and zero-octets are used for padding. Message types 1 > > to 4 are reserved because they are used by OLSR [4], which uses a > > compatible packet/message header format." > > > > > > > > Thanks > > -Bo > > > > > > > > The IESG wrote: > > > The IESG has received a request from the Mobile Ad-hoc Networks WG > > > (manet) to consider the following document: > > > > > > - 'Internet Assigned Numbers Authority (IANA) Allocations for the > > > Mobile Ad hoc Networks (MANET) Working Group ' > > > as a Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, and solicits > > > final comments on this action. Please send substantive comments to > the > > > ietf@ietf.org mailing lists by 2007-08-18. Exceptionally, > > > comments may be sent to iesg@ietf.org instead. In either case, please > > > retain the beginning of the Subject line to allow automated sorting. > > > > > > The file can be obtained via > > > http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-05.txt > > > > > > > > > IESG discussion can be tracked via > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15 > 731&rfc_flag=0 > > > > > > > > > > > > _______________________________________________ > > > 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 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Aug 09 16:59: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 1IJF51-0004DC-3V; Thu, 09 Aug 2007 16:58:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJF4z-0004Au-0G for manet-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 16:58:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJF4y-0004Aj-MR; Thu, 09 Aug 2007 16:58:00 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJF4x-0005DI-BS; Thu, 09 Aug 2007 16:58:00 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Aug 2007 16:57:59 -0400 X-IronPort-AV: i="4.19,242,1183348800"; d="scan'208"; a="67589702:sNHT53234796" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l79KvwbI002978; Thu, 9 Aug 2007 16:57:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l79KvwjI023432; Thu, 9 Aug 2007 20:57:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 16:57:58 -0400 Received: from [10.81.246.161] ([10.81.246.161]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 16:57:58 -0400 Message-ID: <46BB7FD0.2050308@cisco.com> Date: Thu, 09 Aug 2007 16:57:52 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Last Call: draft-ietf-manet-iana (Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group) to Proposed Standard References: <46BB2F27.2010408@cisco.com> <374005f30708091054u56210464o4319f88f9a4d3867@mail.gmail.com> In-Reply-To: <374005f30708091054u56210464o4319f88f9a4d3867@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2007 20:57:58.0165 (UTC) FILETIME=[F70EFC50:01C7DAC7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3890; t=1186693078; x=1187557078; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bberry@cisco.com; z=From:=20Bo=20Berry=20 |Subject:=20Re=3A=20[manet]=20Last=20Call=3A=20draft-ietf-manet-iana=20(I nternet=20Assigned=20Numbers=0A=20Authority=20(IANA)=20Allocations=20for=2 0the=20Mobile=20Ad=20hoc=20Networks=20(MANET)=20Working=0A=20Group)=20to=2 0Proposed=20Standard |Sender:=20 |To:=20Ian=20Chakeres=20; bh=bcLUxFqsysx3fQZAgZWjd24osrbp8oFkJE+A7/etX3Q=; b=Jm4GMM6leJjQ1iwNpp9FGIM8x5Ns2HFnfjrQTXQ2TGlB2lpqQ6103kCkJPB0XelWR2L7txOy sqolC2GjbR1IfhBK1lQBubIx24osfd+dLlw6CxfKgIRI24YqMpE+LfZ6; Authentication-Results: rtp-dkim-2; header.From=bberry@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: manet@ietf.org, ietf@ietf.org 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 Thanks for the responses Teco (separate email) and Ian. Ian Chakeres wrote: > The decision to allocate one port was discussed in the MANET group. We > chose to reserve a single port to allow multiple protocols to be used > together. For example, it is extremely likely that NHDP will be used > with both DYMO and OLSRv2. > > Before you voiced your suggestion to allocate an IP protocol number, > the issue has never arisen. Unless there is WG support to allocate an > IP protocol number, I do not think it will be allocated. OK. Perhaps the WG should discuss it before we discount it. > > Regarding packetbb IANA considerations and other MANET WG protocols > additional IANA needs they are addressed in their documents. For > example, see packetbb's IANA section. I have. It appears to suggest three different IANAs. A new registry for message types must be created A new registry for packet TLV types must be created, A new registry for address block TLV types must be created. Can these be in one draft, the MANET IANA doc, or is the plan to have three separate drafts. Or is the plan for each protocol to track its own? I went back through the archives and did not see such discussion. I am suggesting that the MANET IANA draft may be a good place, specifically if multiple protocols will co-exist, sharing TLVs and ports. Sorry if I missed the discussions on these. > > Ian > > On 8/9/07, Bo Berry wrote: >> Given that the WG is working to define two standards >> - Reactive MANET Protocol (RMP) >> - Proactive MANET Protocol (PMP) >> that may or may not converge, do we need to allocate >> two port numbers so these protocols can co-exist? >> >> There has also been a suggestion to allocate an IP protocol >> number for a MANET routing protocol. Should this be >> included in this draft? >> >> The various MANET protocols are moving to packetbb which >> will require the definition of several/many TLV identifiers. >> Where are these type IDs going to be allocated and tracked? >> If in the separate protocol drafts, is there a potential >> problem with overlap if IDs? If so, perhaps the MANET >> type IDs should be defined here. >> >> draft-ietf-manet-packetbb-08 currently reserves IDs >> "Message type 0 MUST NOT be allocated because a zero-octet signifies a >> packet header and zero-octets are used for padding. Message types 1 >> to 4 are reserved because they are used by OLSR [4], which uses a >> compatible packet/message header format." >> >> >> >> Thanks >> -Bo >> >> >> >> The IESG wrote: >>> The IESG has received a request from the Mobile Ad-hoc Networks WG >>> (manet) to consider the following document: >>> >>> - 'Internet Assigned Numbers Authority (IANA) Allocations for the >>> Mobile Ad hoc Networks (MANET) Working Group ' >>> as a Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2007-08-18. Exceptionally, >>> comments may be sent to iesg@ietf.org instead. In either case, please >>> retain the beginning of the Subject line to allow automated sorting. >>> >>> The file can be obtained via >>> http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-05.txt >>> >>> >>> IESG discussion can be tracked via >>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15731&rfc_flag=0 >>> >>> >>> >>> _______________________________________________ >>> 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 Thu Aug 09 17:33:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJFbm-0001UI-LS; Thu, 09 Aug 2007 17:31:54 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJFbk-0001UC-To for manet-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 17:31:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJFbk-0001U3-Ij for manet@ietf.org; Thu, 09 Aug 2007 17:31:52 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJFbk-0000bq-9K for manet@ietf.org; Thu, 09 Aug 2007 17:31:52 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l79LVnlh010337 for ; Thu, 9 Aug 2007 17:31:49 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007080917314924050 for ; Thu, 09 Aug 2007 17:31:49 -0400 From: "Joe Macker" To: Date: Thu, 9 Aug 2007 17:31:46 -0400 Message-ID: <003c01c7dacc$b027a440$165cfa84@SEXTANT> 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.3138 Thread-Index: AcfazLANgokcTOR1TmeOVLUX2BnT8A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [manet] Additional MANET Page and Personal Ids,etc 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 MANET WG: (Message stimulated to add clarifcation based upon some recent feedback) The additional MANET Page linked at http://www.ietf.org/html.charters/manet-charter.html is not the official place for IETF MANET WG information but is a place for useful additional information. The charter page, IETF minutes, WG list are the official WG methods. The http://tools.ietf.org/wg/manet/ provides a breakdown of WG documents including expired and has list of personal submission that have manet in the extension therefore potentially related, but as you may or may not know these personal submissions are just that (personal submission) so keep that in mind. At meetings and within minutes the WG MAY discuss personal submissions that are being considered for WG inclusion and some transition. Our intent to supplement the minutes and WG discussion will be to also announce these documents that may be under consideration. One such case from the last meeting are the personal metric-oriented TLV drafts that are packetbb related. draft-dean-manet-metriclv-00 draft-dearlove-olsrv2-metrics-00 Please read and comment if you are interested as was discussed at the recent WG or see the minutes. The first draft concentrates on a container format for metrics and the second draft begins to also discuss function within a specific protocol. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Aug 09 19:07: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 1IJH4O-00010W-0y; Thu, 09 Aug 2007 19:05:32 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJH4J-00010L-Uc for manet-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 19:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJH4J-00010B-6z for manet@ietf.org; Thu, 09 Aug 2007 19:05:27 -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 1IJH4H-0008Bg-NY for manet@ietf.org; Thu, 09 Aug 2007 19:05:27 -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 l79N5JAW026540 for ; Fri, 10 Aug 2007 02:05:23 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 02:05:19 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 18:05:09 -0500 Received: from [172.18.141.151] ([172.18.141.151]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 18:05:08 -0500 Message-ID: <46BB9D9F.2060002@nokia.com> Date: Thu, 09 Aug 2007 16:05:03 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Manet" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2007 23:05:08.0660 (UTC) FILETIME=[BB301F40:01C7DAD9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [manet] Comments about draft-ietf-manet-packetbb-08 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 folks, Here are some comments about the newer revision. In section 5.3.2, there is the following constraint: > Two or more TLVs with the same tlv-fulltype in the same address block > TLV block MUST NOT be associated with the same copy of an address > (i.e. they must not have overlapping index ranges). I don't think this is right. Suppose I have a TLV type that associates sets of values to a set of addresses (for instance, sequence numbers or values for stability). To my understanding, I could not include this TLV type twice in a message, because the address ranges would overlap. I don't see any advantage in imposing this constraint, and it seems to me that it should be removed. Also, these constraints: > TLVs in the same TLV block MUST be sorted in non-descending tlv- > fulltype order. and > TLVs with the same tlv-fulltype associated with the same address > block MUST be sorted in ascending index-start order. while probably harmless otherwise, seem to serve little purpose other than requiring protocol parsers to perform additional sorting operations and creating new error conditions that might need to be checked on the receiving ends. What is the specification for offending packets? Would the packet be silently dropped, or would each protocol be free to handle the unsorted TLVs in protocol-specific fashion? As I had mentioned previously (before the last IETF meeting), it would be a good idea if we could have 8-bit fields, in order to minimize the TLV overhead. This can be done without adding new fields to the definition (e.g., no vector), and thus (I reckon) not significantly impacting the parseability of the result. For instance, we could just say that 16-bit cannot exceed 32,767 bytes in length, and use the leading bit of the element of the to signify that has only 7 bits. More later... Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Aug 09 19:57: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 1IJHqx-0003ch-87; Thu, 09 Aug 2007 19:55:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJHqt-0003cV-9p for manet-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 19:55:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJHqs-0003cM-UU for manet@ietf.org; Thu, 09 Aug 2007 19:55:39 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJHqr-0004q0-84 for manet@ietf.org; Thu, 09 Aug 2007 19:55:38 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l79NtY9o002548 for ; Fri, 10 Aug 2007 02:55:35 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 02:55:33 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 18:55:32 -0500 Received: from [172.18.141.151] ([172.18.141.151]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 18:55:31 -0500 Message-ID: <46BBA971.30403@nokia.com> Date: Thu, 09 Aug 2007 16:55:29 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Manet" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2007 23:55:31.0914 (UTC) FILETIME=[C53012A0:01C7DAE0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Subject: [manet] NHDP "Hello" packet too big 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 folks, Here is some text that I wrote up at the last IETF to compare the existing NHDP message to a smaller format, roughly taken from the SMURF protocol specification with some more fields added so that it would have additional functionality as specified by NHDP. The bottom line: NHDP example in Appendix A: 50 bytes SMURF-like packet format: 14 bytes TLV version of SMURF-like format: 15 bytes. Plus the NHDP overhead will get worse as more neighbors are counted. This is important because the example shown has only 4 neighbors, and for good connectivity it is usually recommended to have at least 6 (or 5.7 or something like that). For a lot of published papers (maybe even most of them), the number of neighbors is quite a bit higher. I would like to suggest that either that we encourage the development of some alternative HELLO packet format, or else that the basic NHDP format should be substantially revised. Here is my text with examples, derived from Appendix A of NHDP: ===================================== octet) addresses without prefix TLVs. The message is transmitted with a full message header (message semantics octet is 0) with a hop limit of 1 and a hop count of 0. The overall message length is 50 octets. The message contains a message TLV block with content length 8 octets containing two message TLVs, of types VALIDITY_TIME and INTERVAL_TIME. Each uses a TLV with semantics value 8, indicating that no start and stop indexes are included, and each has a value length of 1 octet. The values included (0x68 and 0x50) are time codes representing the default values of parameters H_HOLD_TIME and HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the default value of constant C (0.0625 second). The first address block contains 1 local interface address. The semantics octet value 2 indicates no address tail, and the head length of 4 octets indicates no address mid sections. This address block has no TLVs (TLV block content length 0 octets). The second, and last, address block contains 4 neighbor interface addresses. The semantics octet value 2 indicates no address tail, the head length of 3 octets indicates address mid sections of one octet each. The following TLV block (content length 7 octets) includes one LINK_STATUS TLV which reports the link status values of all reported neighbors in a single multivalue TLV: the first two addresses are HEARD, the third address is SYMMETRIC and the fourth address is LOST. The TLV semantics value of 40 indicates, in addition to that this is a multivalue TLV, that no start and stop indexes are included, since values for all addresses are included. The TLV value length of 4 octets indicates one octet per value per address. 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 full message header (message semantics octet is 0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HELLO |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ hop limit of 1 and a hop count of 0: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The message contains a message TLV block with content length 8 octets containing two message TLVs, of types VALIDITY_TIME and INTERVAL_TIME. Each uses a TLV with semantics value 8, indicating that no start and stop indexes are included, and each has a value length of 1 octet. The values included (0x68 and 0x50) are time codes representing the default values of parameters H_HOLD_TIME and HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the default value of constant C (0.0625 second). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VALIDITY_TIME |0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 1 1 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INTERVAL_TIME |0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 1 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first address block contains 1 local interface address. The semantics octet value 2 indicates no address tail, and the head length of 4 octets indicates no address mid sections. This address block has no TLVs (TLV block content length 0 octets). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 0| Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | +-+-+-+-+-+-+-+-+ The second, and last, address block contains 4 neighbor interface addresses. The semantics octet value 2 indicates no address tail, the head length of 3 octets indicates address mid sections of one octet each. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1| Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | Mid | Mid | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | +-+-+-+-+-+-+-+-+ The following TLV block (content length 7 octets) includes one LINK_STATUS TLV which reports the link status values of all reported neighbors in a single multivalue TLV: the first two addresses are HEARD, the third address is SYMMETRIC and the fourth address is LOST. The TLV semantics value of 40 indicates, in addition to that this is a multivalue TLV, that no start and stop indexes are included, since values for all addresses are included. The TLV value length of 4 octets indicates one octet per value per address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 1 0 0 0|0 0 0 0 0 1 0 0| HEARD | HEARD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SYMMETRIC | LOST | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Alternative layout [14 bytes] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HELLO | flags |#Selves|#Heard | #Sym | #Lost | Seq# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address(es) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | Mid | ..... extensions .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Or, new TLV def "Hello data element" [15 bytes = 5 bytes + 10 bytes data] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=HELLO | Length | flags |#Selves|#Heard | #Sym | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | #Lost | Seq# | ..... data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where, "data" is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address(es) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | Mid | ..... extensions .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===================================== Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Aug 09 21:33: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 1IJJLf-0006m9-6X; Thu, 09 Aug 2007 21:31:31 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJJLc-0006m2-FU for manet-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 21:31:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJJLc-0006lp-5U for manet@ietf.org; Thu, 09 Aug 2007 21:31:28 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJJLb-0003kR-CB for manet@ietf.org; Thu, 09 Aug 2007 21:31:28 -0400 Received: by nf-out-0910.google.com with SMTP id c10so188560nfd for ; Thu, 09 Aug 2007 18:31:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=dNsxklIMAoN2zwWvlh8ArIFiMu61FMa47OoYkZS84lWWV0cbnR0mL4JhO1DFk0v5Wp4nRg049761eUb65rXZvQVQV2/GJb04YHtvrCUCkQhb7mNWK6edjbX3mrKojdNj72QOGaJ+2G0BfCbsjtQ1XMD1uqnyy0cka6vTCM+MdwI= 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=rJCdrJ4jDvXSqz2VefjUKNrMPiP7ihvZmzCok/sK9TaQPnDUrxf3c1eIXLitrIjR9YM65mCtaoyykvfGe9dmZvtF3CvIjrDNR7SSENblVLkZB/pgKrn90b6R4HNSIRwKbLNeLRSxPMdEFOf8jtRb+pDTpHExucH6SZJo4VnajJc= Received: by 10.78.204.20 with SMTP id b20mr1171864hug.1186709485976; Thu, 09 Aug 2007 18:31:25 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Thu, 9 Aug 2007 18:31:25 -0700 (PDT) Message-ID: <374005f30708091831p1ff1b989qc0bf5d3fa6be3b4d@mail.gmail.com> Date: Fri, 10 Aug 2007 07:01:25 +0530 From: "Ian Chakeres" To: "Teco Boot" Subject: Re: [manet] Last Call: draft-ietf-manet-iana (Internet AssignedNumbers Authority (IANA) Allocations for the Mobile Ad hocNetworks (MANET) Working Group) to Proposed Standard In-Reply-To: <000001c7dab0$7b32bb10$0202a8c0@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30708091054u56210464o4319f88f9a4d3867@mail.gmail.com> <000001c7dab0$7b32bb10$0202a8c0@Teco> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: manet@ietf.org, ietf@ietf.org 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 think that supporting both UDP and an IP protocol number would make ensuring interoperability more difficult. If I hear from the WG that there is a leaning toward leaving UDP and switching to an IP protocol number, then we can consider it. As of today, I have not heard enough support for this change. Ian Chakeres On 8/9/07, Teco Boot wrote: > > Ian wrote: > > Before you voiced your suggestion to allocate an IP protocol number, > > the issue has never arisen. Unless there is WG support to allocate an > > IP protocol number, I do not think it will be allocated. > > > [Teco] > I did rise this question before, see below. > Maybe the issue is not that important; UDP overhead is 8 octets, brings > checksum and could take advantage of header compression for UDP. But using a > native IP protocol is more in line with other IETF routing protocols. > > > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: woensdag 25 april 2007 13:28 > To: 'Ian Chakeres' > Cc: manet@ietf.org > Subject: [manet] manet-iana WG Last Call: site-local address and UDP only > > Hi Ian, > > You request a site-local multicast address. I cannot find any usage of it in > the current I-Ds. Do we need this? Or always perform hop-by-hop forwarding > using a link-local address? I think the latter is used by OLSRv2 and DYMO > protocols, but I can miss something. > > You also do not request an IP protocol number. Maybe I missed a discussion > before and the outcome could be using UDP only, (may be TCP also). I cannot > find any reference. Using UDP checksum is a reason. > > Regards, Teco > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > Regarding packetbb IANA considerations and other MANET WG protocols > > additional IANA needs they are addressed in their documents. For > > example, see packetbb's IANA section. > > > > Ian > > > > On 8/9/07, Bo Berry wrote: > > > > > > Given that the WG is working to define two standards > > > - Reactive MANET Protocol (RMP) > > > - Proactive MANET Protocol (PMP) > > > that may or may not converge, do we need to allocate > > > two port numbers so these protocols can co-exist? > > > > > > There has also been a suggestion to allocate an IP protocol > > > number for a MANET routing protocol. Should this be > > > included in this draft? > > > > > > The various MANET protocols are moving to packetbb which > > > will require the definition of several/many TLV identifiers. > > > Where are these type IDs going to be allocated and tracked? > > > If in the separate protocol drafts, is there a potential > > > problem with overlap if IDs? If so, perhaps the MANET > > > type IDs should be defined here. > > > > > > draft-ietf-manet-packetbb-08 currently reserves IDs > > > "Message type 0 MUST NOT be allocated because a zero-octet signifies > > a > > > packet header and zero-octets are used for padding. Message types 1 > > > to 4 are reserved because they are used by OLSR [4], which uses a > > > compatible packet/message header format." > > > > > > > > > > > > Thanks > > > -Bo > > > > > > > > > > > > The IESG wrote: > > > > The IESG has received a request from the Mobile Ad-hoc Networks WG > > > > (manet) to consider the following document: > > > > > > > > - 'Internet Assigned Numbers Authority (IANA) Allocations for the > > > > Mobile Ad hoc Networks (MANET) Working Group ' > > > > as a Proposed Standard > > > > > > > > The IESG plans to make a decision in the next few weeks, and solicits > > > > final comments on this action. Please send substantive comments to > > the > > > > ietf@ietf.org mailing lists by 2007-08-18. Exceptionally, > > > > comments may be sent to iesg@ietf.org instead. In either case, please > > > > retain the beginning of the Subject line to allow automated sorting. > > > > > > > > The file can be obtained via > > > > http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-05.txt > > > > > > > > > > > > IESG discussion can be tracked via > > > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15 > > 731&rfc_flag=0 > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Aug 09 21:40: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 1IJJSw-0006E7-Bu; Thu, 09 Aug 2007 21:39:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJJSt-0006Dl-SP for manet-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 21:38:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJJSt-0006Dc-HQ for manet@ietf.org; Thu, 09 Aug 2007 21:38:59 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJJSs-0007pb-N4 for manet@ietf.org; Thu, 09 Aug 2007 21:38:59 -0400 Received: by nf-out-0910.google.com with SMTP id c10so189051nfd for ; Thu, 09 Aug 2007 18:38:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=gFY2TVWGcE2QjSSIdU4cf/VcdWD0nlXpfSibqOHK17Udk5zdB8C5mhcSS7doOrwQaK6hqpMr7/I81ecADfAJhn+vMxzQHwdmi6/dpXMgRDBrssv0ibsUaHFMjPr9Jq5JR9W9RnXeOCOsDdPBM6drh6TppUDuTLE/RylN0JUyLB4= 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=gE/Quk0kuxac+m5eDzk7IZf2LdkHh+1XLo5CappkqpefvwjNGCf3I9i/wSfGJ0Zzcq6FB+oM+UKrApTGgecbEHetXnR1H6UzCASQgJlZk1prlqt6zpI54WCi5VQ50oWFr1vY69W+aBeI6ZayfQwpma0GKEdAc5/pZJ+NS12TNCo= Received: by 10.78.140.17 with SMTP id n17mr1164636hud.1186709935524; Thu, 09 Aug 2007 18:38:55 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Thu, 9 Aug 2007 18:38:55 -0700 (PDT) Message-ID: <374005f30708091838w2c2b127dh5f5f05b7fdb70c5f@mail.gmail.com> Date: Fri, 10 Aug 2007 07:08:55 +0530 From: "Ian Chakeres" To: "Bo Berry" Subject: Re: [manet] Last Call: draft-ietf-manet-iana (Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group) to Proposed Standard In-Reply-To: <46BB7FD0.2050308@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46BB2F27.2010408@cisco.com> <374005f30708091054u56210464o4319f88f9a4d3867@mail.gmail.com> <46BB7FD0.2050308@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: manet@ietf.org, ietf@ietf.org 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 8/10/07, Bo Berry wrote: > > Thanks for the responses Teco (separate email) and Ian. > > Ian Chakeres wrote: > > The decision to allocate one port was discussed in the MANET group. We > > chose to reserve a single port to allow multiple protocols to be used > > together. For example, it is extremely likely that NHDP will be used > > with both DYMO and OLSRv2. > > > > Before you voiced your suggestion to allocate an IP protocol number, > > the issue has never arisen. Unless there is WG support to allocate an > > IP protocol number, I do not think it will be allocated. > > OK. Perhaps the WG should discuss it before we discount it. This issue is open for discussion, but as I mentioned I do not think there is sufficient WG support. I personally do not think asking for both a UDP port and an IP protocol number is good for ensuring interoperability - and this is the main reason we have requested the IANA allocations in this document. Regarding packetbb's IANA needs, I think they are best served in the PacketBB document. PacketBB requests the registries associated with its type spaces. The other documents (e.g. TimeTLV, NHDP, DYMO, OLSRv2, and metrics documents under consideration) then request IANA allocations from the spaces created by the packet BB document. Ian Chakeres > > Regarding packetbb IANA considerations and other MANET WG protocols > > additional IANA needs they are addressed in their documents. For > > example, see packetbb's IANA section. > > I have. It appears to suggest three different IANAs. > A new registry for message types must be created > A new registry for packet TLV types must be created, > A new registry for address block TLV types must be created. > > Can these be in one draft, the MANET IANA doc, or is the plan to have > three separate drafts. Or is the plan for each protocol to track > its own? I went back through the archives and did not see such > discussion. > > I am suggesting that the MANET IANA draft may be a good place, > specifically if multiple protocols will co-exist, sharing TLVs > and ports. > > Sorry if I missed the discussions on these. > > > > > Ian > > > > On 8/9/07, Bo Berry wrote: > >> Given that the WG is working to define two standards > >> - Reactive MANET Protocol (RMP) > >> - Proactive MANET Protocol (PMP) > >> that may or may not converge, do we need to allocate > >> two port numbers so these protocols can co-exist? > >> > >> There has also been a suggestion to allocate an IP protocol > >> number for a MANET routing protocol. Should this be > >> included in this draft? > >> > >> The various MANET protocols are moving to packetbb which > >> will require the definition of several/many TLV identifiers. > >> Where are these type IDs going to be allocated and tracked? > >> If in the separate protocol drafts, is there a potential > >> problem with overlap if IDs? If so, perhaps the MANET > >> type IDs should be defined here. > >> > >> draft-ietf-manet-packetbb-08 currently reserves IDs > >> "Message type 0 MUST NOT be allocated because a zero-octet signifies a > >> packet header and zero-octets are used for padding. Message types 1 > >> to 4 are reserved because they are used by OLSR [4], which uses a > >> compatible packet/message header format." > >> > >> > >> > >> Thanks > >> -Bo > >> > >> > >> > >> The IESG wrote: > >>> The IESG has received a request from the Mobile Ad-hoc Networks WG > >>> (manet) to consider the following document: > >>> > >>> - 'Internet Assigned Numbers Authority (IANA) Allocations for the > >>> Mobile Ad hoc Networks (MANET) Working Group ' > >>> as a Proposed Standard > >>> > >>> The IESG plans to make a decision in the next few weeks, and solicits > >>> final comments on this action. Please send substantive comments to the > >>> ietf@ietf.org mailing lists by 2007-08-18. Exceptionally, > >>> comments may be sent to iesg@ietf.org instead. In either case, please > >>> retain the beginning of the Subject line to allow automated sorting. > >>> > >>> The file can be obtained via > >>> http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-05.txt > >>> > >>> > >>> IESG discussion can be tracked via > >>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15731&rfc_flag=0 > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 Thu Aug 09 22:21: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 1IJK5u-0006cA-90; Thu, 09 Aug 2007 22:19:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJK5s-0006c2-Gc for manet-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 22:19:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJK5s-0006bt-78 for manet@ietf.org; Thu, 09 Aug 2007 22:19:16 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJK5r-0004vZ-00 for manet@ietf.org; Thu, 09 Aug 2007 22:19:16 -0400 Received: by nf-out-0910.google.com with SMTP id c10so191669nfd for ; Thu, 09 Aug 2007 19:19:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=WHjM7WhDcFwxmiV//29p7Fzy41Yx3OaXmd846EVw0D7AFmJ6dvxvspyzF6dcaCDCtq18r00dsq4HS1qjAbniQ3qiX6HoLg2BfbNiHAxPvTehQevruAF/45bVUvkcFzwLFNIThAkgm08RplIMT36QEWjJVom3QmGTsk2+qU2GpbA= 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=Kg9CArKJiAG995xEbYGysSdg4NoENYtM8FGeZK8krHuGbwgUWcnfAAa461oBZCunqLyJO/YXS/+vXN+Tqcgm2iyZHqPA2iuBm6sQMBYTyeCUpP6/Qxg/IzCD6HUDBCGG10DjF5hZUDOOXjxDqrQrl3LHfEJWgpdBq0PfWbKu04I= Received: by 10.78.195.9 with SMTP id s9mr1153032huf.1186712353315; Thu, 09 Aug 2007 19:19:13 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Thu, 9 Aug 2007 19:19:13 -0700 (PDT) Message-ID: <374005f30708091919l5ad6daecw71a487996685842b@mail.gmail.com> Date: Fri, 10 Aug 2007 07:49:13 +0530 From: "Ian Chakeres" To: "Charles E. Perkins" Subject: Re: [manet] Comments about draft-ietf-manet-packetbb-08 In-Reply-To: <46BB9D9F.2060002@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46BB9D9F.2060002@nokia.com> 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 Comments inline. On 8/10/07, Charles E. Perkins wrote: > > Hello folks, > > Here are some comments about the newer revision. > > In section 5.3.2, there is the following constraint: > > > Two or more TLVs with the same tlv-fulltype in the same address block > > TLV block MUST NOT be associated with the same copy of an address > > (i.e. they must not have overlapping index ranges). > > I don't think this is right. Suppose I have a TLV type > that associates sets of values to a set of addresses > (for instance, sequence numbers or values for stability). > To my understanding, I could not include this TLV > type twice in a message, because the address ranges > would overlap. > > I don't see any advantage in imposing this constraint, > and it seems to me that it should be removed. The same tlv type can be twice included, but not for the same address. I believe this requirement is to disallow there being multiple TLVs of the exact same type associated with one address. For example, if you have address Z and it has two tlvs of the same type with different values, then what is the value associated with this tlv? By explicitly disallowing multiple values with the same tlv type, we can ensure this does not occur. Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Aug 10 11:55: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 1IJWny-0005Lh-Hd; Fri, 10 Aug 2007 11:53:38 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJWnw-0005DO-FC for manet-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 11:53:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJWnv-0005CT-Ir; Fri, 10 Aug 2007 11:53:35 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJWnu-0006qt-Ku; Fri, 10 Aug 2007 11:53:35 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 10 Aug 2007 08:53:34 -0700 X-IronPort-AV: i="4.19,245,1183359600"; d="scan'208"; a="170402496:sNHT54943020" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7AFrXjx010376; Fri, 10 Aug 2007 08:53:33 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l7AFrEa9015913; Fri, 10 Aug 2007 15:53:33 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 11:53:22 -0400 Received: from [10.81.246.141] ([10.81.246.141]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 11:53:21 -0400 Message-ID: <46BC89ED.6030009@cisco.com> Date: Fri, 10 Aug 2007 11:53:17 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Last Call: draft-ietf-manet-iana (Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group) to Proposed Standard References: <46BB2F27.2010408@cisco.com> <374005f30708091054u56210464o4319f88f9a4d3867@mail.gmail.com> <46BB7FD0.2050308@cisco.com> <374005f30708091838w2c2b127dh5f5f05b7fdb70c5f@mail.gmail.com> In-Reply-To: <374005f30708091838w2c2b127dh5f5f05b7fdb70c5f@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 15:53:21.0848 (UTC) FILETIME=[93F01380:01C7DB66] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5825; t=1186761213; x=1187625213; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bberry@cisco.com; z=From:=20Bo=20Berry=20 |Subject:=20Re=3A=20[manet]=20Last=20Call=3A=20draft-ietf-manet-iana=20(I nternet=20Assigned=20Numbers=0A=20Authority=20(IANA)=20Allocations=20for=2 0the=20Mobile=20Ad=20hoc=20Networks=20(MANET)=20Working=0A=20Group)=20to=2 0Proposed=20Standard |Sender:=20; bh=9JuPmS2Xc8MQwj+BMorg9yOGL9Pw+Z/9i5QHyhJ+TZk=; b=nPh07LxWilyP5j/WVLI5KxHwIX1frK/WNxzfeNcIua+OWA63pL7Xzn01LiOpnjj1bGAQIrJv GCfiIPLNffhUjDYNOag9roSfCjEgkd51ZFRFi++FEd5ngL1HM65mWNn8; Authentication-Results: sj-dkim-3; header.From=bberry@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: manet@ietf.org, ietf@ietf.org 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: > Comments inline. > > On 8/10/07, Bo Berry wrote: >> Thanks for the responses Teco (separate email) and Ian. >> >> Ian Chakeres wrote: >>> The decision to allocate one port was discussed in the MANET group. We >>> chose to reserve a single port to allow multiple protocols to be used >>> together. For example, it is extremely likely that NHDP will be used >>> with both DYMO and OLSRv2. >>> >>> Before you voiced your suggestion to allocate an IP protocol number, >>> the issue has never arisen. Unless there is WG support to allocate an >>> IP protocol number, I do not think it will be allocated. >> OK. Perhaps the WG should discuss it before we discount it. > > This issue is open for discussion, but as I mentioned I do not think > there is sufficient WG support. I personally do not think asking for > both a UDP port and an IP protocol number is good for ensuring > interoperability - and this is the main reason we have requested the > IANA allocations in this document. I think running a routing protocol over UDP is less efficient than directly over IP. As long as the rough consensus is happy w/ UDP, I'll chill-out. If the MANET protocols will be UDP and packetbb based, should the text in packetbb be modified to be more specific? ""The packets defined by this specification are designed to carry a number of messages between in a single transmission. The packets may be unicast or multicast and may use any transport protocol (TCP, UDP, ...) appropriate to the protocol using this specification and may travel over a single logical hop which might consist of one or more IP hops. When the diffusion mechanism enabled by this specification is employed, UDP may be most appropriate."" >From my read, there is confusion when a draft trys to remain so generic in one sense and then specific in another. Perhaps it is just me and the pieces will come together in due time. > Regarding packetbb's IANA needs, I think they are best served in the > PacketBB document. PacketBB requests the registries associated with > its type spaces. The other documents (e.g. TimeTLV, NHDP, DYMO, > OLSRv2, and metrics documents under consideration) then request IANA > allocations from the spaces created by the packet BB document. > > Ian Chakeres > >>> Regarding packetbb IANA considerations and other MANET WG protocols >>> additional IANA needs they are addressed in their documents. For >>> example, see packetbb's IANA section. >> I have. It appears to suggest three different IANAs. >> A new registry for message types must be created >> A new registry for packet TLV types must be created, >> A new registry for address block TLV types must be created. >> >> Can these be in one draft, the MANET IANA doc, or is the plan to have >> three separate drafts. Or is the plan for each protocol to track >> its own? I went back through the archives and did not see such >> discussion. >> >> I am suggesting that the MANET IANA draft may be a good place, >> specifically if multiple protocols will co-exist, sharing TLVs >> and ports. >> >> Sorry if I missed the discussions on these. >> >>> Ian >>> >>> On 8/9/07, Bo Berry wrote: >>>> Given that the WG is working to define two standards >>>> - Reactive MANET Protocol (RMP) >>>> - Proactive MANET Protocol (PMP) >>>> that may or may not converge, do we need to allocate >>>> two port numbers so these protocols can co-exist? >>>> >>>> There has also been a suggestion to allocate an IP protocol >>>> number for a MANET routing protocol. Should this be >>>> included in this draft? >>>> >>>> The various MANET protocols are moving to packetbb which >>>> will require the definition of several/many TLV identifiers. >>>> Where are these type IDs going to be allocated and tracked? >>>> If in the separate protocol drafts, is there a potential >>>> problem with overlap if IDs? If so, perhaps the MANET >>>> type IDs should be defined here. >>>> >>>> draft-ietf-manet-packetbb-08 currently reserves IDs >>>> "Message type 0 MUST NOT be allocated because a zero-octet signifies a >>>> packet header and zero-octets are used for padding. Message types 1 >>>> to 4 are reserved because they are used by OLSR [4], which uses a >>>> compatible packet/message header format." >>>> >>>> >>>> >>>> Thanks >>>> -Bo >>>> >>>> >>>> >>>> The IESG wrote: >>>>> The IESG has received a request from the Mobile Ad-hoc Networks WG >>>>> (manet) to consider the following document: >>>>> >>>>> - 'Internet Assigned Numbers Authority (IANA) Allocations for the >>>>> Mobile Ad hoc Networks (MANET) Working Group ' >>>>> as a Proposed Standard >>>>> >>>>> The IESG plans to make a decision in the next few weeks, and solicits >>>>> final comments on this action. Please send substantive comments to the >>>>> ietf@ietf.org mailing lists by 2007-08-18. Exceptionally, >>>>> comments may be sent to iesg@ietf.org instead. In either case, please >>>>> retain the beginning of the Subject line to allow automated sorting. >>>>> >>>>> The file can be obtained via >>>>> http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-05.txt >>>>> >>>>> >>>>> IESG discussion can be tracked via >>>>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15731&rfc_flag=0 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Aug 10 12:00: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 1IJWsx-0000Km-BN; Fri, 10 Aug 2007 11:58:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJWsv-0000KA-GV for manet-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 11:58:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJWsv-0000K2-6x for manet@ietf.org; Fri, 10 Aug 2007 11:58:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJWk8-0001GS-0F for manet@ietf.org; Fri, 10 Aug 2007 11:49:40 -0400 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJWk6-0000Ko-DW for manet@ietf.org; Fri, 10 Aug 2007 11:49:39 -0400 Received: by rv-out-0910.google.com with SMTP id f1so635728rvb for ; Fri, 10 Aug 2007 08:49:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nq4hGbNd+wJOLDODeBNETYg3p6LcEROK8dHDsSFTAKaIqqQ/fvEKBLFOg99wlRIkiPwja/QElCV4j3NelWTlUhEC9N6sDoLxo4ek1metHYTqcJdxf2usLkw6zAq21LyTzxRe7JxSmmYpMdvUSOyv34810vAz/Hz1jEsXvPM41PM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=TM4cFnFETVeSiN7MtNUO7FbkVUY+IxzBX3KhaPXtKP/bq/nn9OgRjJSfGlk6WfPLzAnNmGoPO3VnBnKiKpLrRd59a+bMCQRnynbkNMGHk/LI3AqvWRzz9l5TPnZg4jAqbUzExVr8FxQvmzP8T8jT/v9QuglLX0qUnKUaQVDdErg= Received: by 10.115.17.1 with SMTP id u1mr333146wai.1186760977476; Fri, 10 Aug 2007 08:49:37 -0700 (PDT) Received: by 10.115.19.13 with HTTP; Fri, 10 Aug 2007 08:49:37 -0700 (PDT) Message-ID: <5d8f06bb0708100849h4488424fh7d3ad5e3d9acfa54@mail.gmail.com> Date: Fri, 10 Aug 2007 18:49:37 +0300 From: "Gezahegne Mannegerew" 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: 68c8cc8a64a9d0402e43b8eee9fc4199 X-TMDA-Confirmed: Fri, 10 Aug 2007 11:58:45 -0400 Subject: [manet] QoS-AODV Request 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 am doing my thesis which involves performance comparison of QoS-aodv and AODV for different parameters for various scenarios. I saw a posting dated on June 3, 2004 which says that implementation of qos aodv under ns-2 was under test and results would be available soon. Currently I am in need of the modified AODV code on ns-2. I would be very thankful if anyone could give me this code or tell me what else I can do. Thank you, GG. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Aug 10 13:13: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 1IJY1c-0008Od-0X; Fri, 10 Aug 2007 13:11:48 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IJY1a-0008OX-Ct for manet-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 13:11:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJY1a-0008OP-3L for manet@ietf.org; Fri, 10 Aug 2007 13:11:46 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJY1Y-00028v-K3 for manet@ietf.org; Fri, 10 Aug 2007 13:11:46 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7AHBBOe008082; Fri, 10 Aug 2007 20:11:39 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 20:11:16 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 12:11:04 -0500 Received: from [172.18.141.151] ([172.18.141.151]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 12:11:04 -0500 Message-ID: <46BC9C27.7020404@nokia.com> Date: Fri, 10 Aug 2007 10:11:03 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Ian Chakeres Subject: Re: [manet] Comments about draft-ietf-manet-packetbb-08 References: <46BB9D9F.2060002@nokia.com> <374005f30708091919l5ad6daecw71a487996685842b@mail.gmail.com> In-Reply-To: <374005f30708091919l5ad6daecw71a487996685842b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 17:11:04.0307 (UTC) FILETIME=[6EFADC30:01C7DB71] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Ian, ext Ian Chakeres wrote: >> >>> Two or more TLVs with the same tlv-fulltype in the same address block >>> TLV block MUST NOT be associated with the same copy of an address >>> (i.e. they must not have overlapping index ranges). >>> >> I don't think this is right. Suppose I have a TLV type >> that associates sets of values to a set of addresses >> (for instance, sequence numbers or values for stability). >> To my understanding, I could not include this TLV >> type twice in a message, because the address ranges >> would overlap. >> >> I don't see any advantage in imposing this constraint, >> and it seems to me that it should be removed. >> > > The same tlv type can be twice included, but not for the same address. > That is what packetbb says, but I am certain that nodes in an ad hoc network can have more than one "characteristic", and we need to have a way to put those multiple characteristics into messages. > I believe this requirement is to disallow there being multiple TLVs of > the exact same type associated with one address. For example, if you > have address Z and it has two tlvs of the same type with different > values, then what is the value associated with this tlv? By explicitly > disallowing multiple values with the same tlv type, we can ensure this > does not occur. > It is a nonfatal protocol error to include two incompatible values or characteristics for the same node. Usually in cases like this there is a specification that mandates acceptance of the last incompatible value, or the first one -- as long as all protocol entities do the same thing. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Aug 11 23: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 1IK4CM-0001Wu-BA; Sat, 11 Aug 2007 23:33:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IK4CK-0001Wo-Hg for manet-confirm+ok@megatron.ietf.org; Sat, 11 Aug 2007 23:33:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK4CK-0001Wf-8D for manet@ietf.org; Sat, 11 Aug 2007 23:33:00 -0400 Received: from fk-out-0910.google.com ([209.85.128.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IK4CJ-0001ed-TZ for manet@ietf.org; Sat, 11 Aug 2007 23:33:00 -0400 Received: by fk-out-0910.google.com with SMTP id z23so1094873fkz for ; Sat, 11 Aug 2007 20:32:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=thdqOSQKv4dMlgzhN1DQQu91laWZByUWTSrACQFFTohAlp71JvDFb9E50FrYX6eIujNbqqittDc8v2y3vwW+WEDE1UpZsF9N20JgOV+DV0cubnoA1yyb+VH3W5FRYTmQlpwroFo8wvkMx3ubpf7e+MwQnRR5PkDHzLfY7GDgqa4= 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=MHFFaaa2vmxDvx+8I9G3bG4j9Z2tBBWJfFE60STw3Cg4eS1+M4V7lkh1nN+zlMRc8OVzai+tr4rEl6gsGHI4G3Qvj4u1aIwMw6OO4iA8sdA1xVztqYP/nI7Pw1te9H08RyLaTIgeixoewxsT9UqA0NgzZq24ypybS6o451RL+hc= Received: by 10.78.159.7 with SMTP id h7mr1373855hue.1186889578952; Sat, 11 Aug 2007 20:32:58 -0700 (PDT) Received: by 10.78.53.8 with HTTP; Sat, 11 Aug 2007 20:32:58 -0700 (PDT) Message-ID: <374005f30708112032g5b37cdf5i692b1c068e6b0e32@mail.gmail.com> Date: Sun, 12 Aug 2007 09:02:58 +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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [manet] IETF 69 MANET Minutes Posted 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've posted the minutes from the IETF 69 MANET meeting online. They can be found at http://www3.ietf.org/proceedings/07jul/minutes/manet.txt. Please review them and send me any updates. Please be prepared to comment on PacketBB and Jitter, as I expect updated IDs and a new WGLC within the next week. Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 13 06:40: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 1IKXJp-0002xN-Cu; Mon, 13 Aug 2007 06:38:41 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKXJn-0002xH-9J for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 06:38:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKXJm-0002x9-Ue for manet@ietf.org; Mon, 13 Aug 2007 06:38:38 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKXJm-0000XN-91 for manet@ietf.org; Mon, 13 Aug 2007 06:38:38 -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 l7DAcZ23002462 for ; Mon, 13 Aug 2007 11:38:35 +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 l7DAcYAl015084 for ; Mon, 13 Aug 2007 11:38:34 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 13 Aug 2007 11:38:34 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 11:38: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 Date: Mon, 13 Aug 2007 11:38:33 +0100 Message-ID: In-Reply-To: <46BB9D9F.2060002@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-manet-packetbb-08 thread-index: Acfa2c63TgKyqjNaTa2GZE9FdUFD7ACu1JKQ References: <46BB9D9F.2060002@nokia.com> From: "Dearlove, Christopher \(UK\)" To: X-OriginalArrivalTime: 13 Aug 2007 10:38:33.0705 (UTC) FILETIME=[18F76D90:01C7DD96] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Thomas Clausen Subject: [manet] Re: draft-ietf-manet-packetbb-08 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 With regard to the constraints in packetbb: - Specifying ordering and non-duplicate TLVs in packetbb looks like it adds complexity, but it really reduces implementation complexity, as the following points indicate. - It may add complexity to the packet/message generation, but very little. Adding no duplication adds no work, it's what you should do. Adding ordering just makes you insert new TLVs in the right place rather than at the end, you don't actually sort. You may even generate them in the appropriate order in the first place, in which case there is no added complexity. - Now at the receiver you can tell a malformed TLV block (and hence message, and if you choose, packet) at the parsing stage, and very easily. - With a duplicate TLV you don't need to force complex decisions as to whether you use the first, or most restrictive, or whatever, choice. It is malformed by definition and you can allow the implementation to do what it considers sensible - and that can be the easy decision to discard the packet/message/block. And note that this can be at parsing, not processing. - Thus receiver processing can be (and probably should be) much simpler. - This is aside from the additional gain in reduced searching for TLVs (stop when not found). - Philosophically, once you get a malformed message, do you trust the sender? Do you want to try to make the best of it? Do you just want to ignore it? The decision is that of the receiver implementor. For these reasons I am strongly against removing any of these contraints. ******************************************************************** 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 Aug 13 09:52: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 1IKaJV-0000XN-AB; Mon, 13 Aug 2007 09:50:33 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKaJT-0000XI-Aq for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 09:50:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKaJS-0000XA-Vl for manet@ietf.org; Mon, 13 Aug 2007 09:50:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKaJS-0005ul-Ed for manet@ietf.org; Mon, 13 Aug 2007 09:50:30 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Aug 2007 09:50:30 -0400 X-IronPort-AV: i="4.19,255,1183348800"; d="scan'208"; a="67837047:sNHT63124176" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7DDoUvT001296; Mon, 13 Aug 2007 09:50:30 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7DDoDji018661; Mon, 13 Aug 2007 13:50:29 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 09:50:23 -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] Re: draft-ietf-manet-packetbb-08 Date: Mon, 13 Aug 2007 09:50:22 -0400 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76404558512@xmb-rtp-208.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: draft-ietf-manet-packetbb-08 Thread-Index: Acfa2c63TgKyqjNaTa2GZE9FdUFD7ACu1JKQAAbOqiA= From: "Stan Ratliff \(sratliff\)" To: "Dearlove, Christopher \(UK\)" , X-OriginalArrivalTime: 13 Aug 2007 13:50:23.0982 (UTC) FILETIME=[E5A050E0:01C7DDB0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3360; t=1187013030; x=1187877030; 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]=20Re=3A=20draft-ietf-manet-packetbb-08 |Sender:=20 |To:=20=22Dearlove, =20Christopher=20\(UK\)=22=20,=0A=20=20=20=20=20=20=20=20; bh=/cmKs4Gu3iZ7ZRrKkTYJqjF1/oRNHeAPjOlwumlawNY=; b=hCTgpsEXgaIeLOW4kDMHM28WpwNYqIn7LD5OTEC6yY0hpI+Zzqf76gmF2zCSPPwGD76ybx4j H3bPWLzPfcBZSHrZo2OXyFNy1zV3JGY9ajKzu/BO1zm/Q3r9pOvnS43Q; 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: 10d3e4e3c32e363f129e380e644649be 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 >It may add complexity to the packet/message generation, >but very little. Adding no duplication adds no work, it's >what you should do. Adding ordering just makes you insert >new TLVs in the right place rather than at the end, you >don't actually sort. You may even generate them in the >appropriate order in the first place, in which case there >is no added complexity. I disagree with this assessment. While it may place no=20 additional complexity on the implementation *now*,=20 it may in the future, depending on what TLV's are=20 added, and what their numbering scheme is.=20 This is something that networking systems have=20 handled for longer than I care to remember. Even (dare I say it?) SNA didn't have this restriction. In sum, I agree with Charlie -- this restriction adds=20 complexity where its not needed, and I think it should be lifted.=20 Regards, Stan -----Original Message----- From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]=20 Sent: Monday, August 13, 2007 6:39 AM To: manet@ietf.org Cc: Thomas Clausen Subject: [manet] Re: draft-ietf-manet-packetbb-08 With regard to the constraints in packetbb: - Specifying ordering and non-duplicate TLVs in packetbb looks like it adds complexity, but it really reduces implementation complexity, as the following points indicate. - It may add complexity to the packet/message generation, but very little. Adding no duplication adds no work, it's what you should do. Adding ordering just makes you insert new TLVs in the right place rather than at the end, you don't actually sort. You may even generate them in the appropriate order in the first place, in which case there is no added complexity. - Now at the receiver you can tell a malformed TLV block (and hence message, and if you choose, packet) at the parsing stage, and very easily. - With a duplicate TLV you don't need to force complex decisions as to whether you use the first, or most restrictive, or whatever, choice. It is malformed by definition and you can allow the implementation to do what it considers sensible - and that can be the easy decision to discard the packet/message/block. And note that this can be at parsing, not processing. - Thus receiver processing can be (and probably should be) much simpler. - This is aside from the additional gain in reduced searching for TLVs (stop when not found). - Philosophically, once you get a malformed message, do you trust the sender? Do you want to try to make the best of it? Do you just want to ignore it? The decision is that of the receiver implementor. For these reasons I am strongly against removing any of these contraints. ******************************************************************** 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 Mon Aug 13 10:01: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 1IKaSd-00080e-AW; Mon, 13 Aug 2007 09:59:59 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKaSa-00080Y-ON for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 09:59:56 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKaSa-00080Q-F7 for manet@ietf.org; Mon, 13 Aug 2007 09:59:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKaQZ-0006IS-34 for manet@ietf.org; Mon, 13 Aug 2007 09:57:51 -0400 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKaQX-0005gk-Uj for manet@ietf.org; Mon, 13 Aug 2007 09:57:51 -0400 Received: by nz-out-0506.google.com with SMTP id n1so452682nzf for ; Mon, 13 Aug 2007 06:57:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=L01Heywf/jG1aFg+kgfZZ363CO6QwDj/BaHE5k3hhFUFcCyYiBKN1Tclt2ktvEk/SwpYuJfowK+cE1Mk2c/cYr72Z3ImtcmEDbnf4/+ZtUULwV9iuy1KzY5F3Sg3GvU/cUB4jAz3EAVfsCt8UwE24fRPjv6hl2TEBdM6FFoJ5ek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=JPswFeISHM2jaqFnucAH2pgvG9soExJ5o6lndyy9Z4KCKw4RJIFFvb/PVSHoFH8esbo8m9sF5h2HTqBruYSvWU1JqT/nzd4FEpwMghBtN6v0HYMAbHxOr9MvxWWZt/ce63ZRijsVKO0Glxg1zqvMzfYdnKUbCnBHW/oYjGzkeyc= Received: by 10.64.201.7 with SMTP id y7mr9452785qbf.1187013468911; Mon, 13 Aug 2007 06:57:48 -0700 (PDT) Received: by 10.65.185.7 with HTTP; Mon, 13 Aug 2007 06:57:48 -0700 (PDT) Message-ID: <3b05f00708130657x532d9f3bj42cd0709908ad292@mail.gmail.com> Date: Mon, 13 Aug 2007 16:57:48 +0300 From: "Mulugeta Berhe" 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: 6d62ab47271805379d7172ee693a45db X-TMDA-Confirmed: Mon, 13 Aug 2007 09:59:56 -0400 Subject: [manet] cluster based routing protocol-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 Hi Everybody, I am currently working on key management scheme for cluster based routing protocol (CBRP). But CBRP is not implemented on NS. Did anybody implement CBRP in NS, please help. Thanks _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 13 10:04:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKaVJ-0000Ao-7I; Mon, 13 Aug 2007 10:02:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKaVG-0000Ah-V1 for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 10:02:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKaVG-0000AY-JV for manet@ietf.org; Mon, 13 Aug 2007 10:02:42 -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 1IKaVF-0006LU-RV for manet@ietf.org; Mon, 13 Aug 2007 10:02:42 -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 l7DE2XNh001778 for ; Mon, 13 Aug 2007 15:02:33 +0100 (BST) Received: from glkas0106.GREENLNK.NET (glkas0106.greenlnk.net [141.245.68.243]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l7DE2Uu0003906 for ; Mon, 13 Aug 2007 15:02:30 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0106.GREENLNK.NET with InterScan Message Security Suite; Mon, 13 Aug 2007 15:02:32 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 15:02:32 +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: draft-ietf-manet-packetbb-08 Date: Mon, 13 Aug 2007 15:02:31 +0100 Message-ID: In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76404558512@xmb-rtp-208.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: draft-ietf-manet-packetbb-08 thread-index: Acfa2c63TgKyqjNaTa2GZE9FdUFD7ACu1JKQAAbOqiAAAFH84A== References: <7FB7EE0A621BA44B8B69E5F0A09DC76404558512@xmb-rtp-208.amer.cisco.com> From: "Dearlove, Christopher \(UK\)" To: "Stan Ratliff \(sratliff\)" , X-OriginalArrivalTime: 13 Aug 2007 14:02:32.0019 (UTC) FILETIME=[9791F230:01C7DDB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 I don't agree. I have general purpose packetbb code that is quite agnostic as to whether it's being used for OLSRv2 (for example) or not, and has no built in knowledge of current or (obviously) future TLVs, and this has minimal impact on generating packetbb messages (when you add a TLV it either slots in, or reports an inconsistency in what you requested, and doesn't add it) and this makes the parsing/reception at the other end much easier. So I'm not just hypothesising, I have (to use a phrase) running code, which does consider the future as well. =20 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 13 August 2007 14:50 To: Dearlove, Christopher (UK); manet@ietf.org Cc: Thomas Clausen Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 *** 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 >It may add complexity to the packet/message generation, >but very little. Adding no duplication adds no work, it's >what you should do. Adding ordering just makes you insert >new TLVs in the right place rather than at the end, you >don't actually sort. You may even generate them in the >appropriate order in the first place, in which case there >is no added complexity. I disagree with this assessment. While it may place no=20 additional complexity on the implementation *now*,=20 it may in the future, depending on what TLV's are=20 added, and what their numbering scheme is.=20 This is something that networking systems have=20 handled for longer than I care to remember. Even (dare I say it?) SNA didn't have this restriction. In sum, I agree with Charlie -- this restriction adds=20 complexity where its not needed, and I think it should be lifted.=20 Regards, Stan -----Original Message----- From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]=20 Sent: Monday, August 13, 2007 6:39 AM To: manet@ietf.org Cc: Thomas Clausen Subject: [manet] Re: draft-ietf-manet-packetbb-08 With regard to the constraints in packetbb: - Specifying ordering and non-duplicate TLVs in packetbb looks like it adds complexity, but it really reduces implementation complexity, as the following points indicate. - It may add complexity to the packet/message generation, but very little. Adding no duplication adds no work, it's what you should do. Adding ordering just makes you insert new TLVs in the right place rather than at the end, you don't actually sort. You may even generate them in the appropriate order in the first place, in which case there is no added complexity. - Now at the receiver you can tell a malformed TLV block (and hence message, and if you choose, packet) at the parsing stage, and very easily. - With a duplicate TLV you don't need to force complex decisions as to whether you use the first, or most restrictive, or whatever, choice. It is malformed by definition and you can allow the implementation to do what it considers sensible - and that can be the easy decision to discard the packet/message/block. And note that this can be at parsing, not processing. - Thus receiver processing can be (and probably should be) much simpler. - This is aside from the additional gain in reduced searching for TLVs (stop when not found). - Philosophically, once you get a malformed message, do you trust the sender? Do you want to try to make the best of it? Do you just want to ignore it? The decision is that of the receiver implementor. For these reasons I am strongly against removing any of these contraints. ******************************************************************** 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 Mon Aug 13 10:35: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 1IKazI-0005uH-E9; Mon, 13 Aug 2007 10:33:44 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKazF-0005uA-Po for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 10:33:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKazF-0005u2-GB for manet@ietf.org; Mon, 13 Aug 2007 10:33:41 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKazE-0006ks-8P for manet@ietf.org; Mon, 13 Aug 2007 10:33:41 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Aug 2007 10:33:41 -0400 X-IronPort-AV: i="4.19,255,1183348800"; d="scan'208"; a="128718261:sNHT59444834" 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 l7DEXdvF026517; Mon, 13 Aug 2007 10:33:40 -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 l7DEWmnF008743; Mon, 13 Aug 2007 14:33:39 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:33:25 -0400 Received: from [10.81.246.136] ([10.81.246.136]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:33:25 -0400 Message-ID: <46C06BB1.2090000@cisco.com> Date: Mon, 13 Aug 2007 10:33:21 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08 References: <7FB7EE0A621BA44B8B69E5F0A09DC76404558512@xmb-rtp-208.amer.cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 14:33:25.0179 (UTC) FILETIME=[E823B8B0:01C7DDB6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5978; t=1187015620; x=1187879620; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bberry@cisco.com; z=From:=20Bo=20Berry=20 |Subject:=20Re=3A=20[manet]=20Re=3A=20draft-ietf-manet-packetbb-08 |Sender:=20 |To:=20=22Dearlove, =20Christopher=20\(UK\)=22=20; bh=mF+wbsm52oELbXtFauBBY3BhRWTp6Ecf/+wU0s/c/qM=; b=Fei0JNytzOOBAav9RvZyT0BrV1aFCQGwdDCsNwGE7tShgHBrkU1d+YkbVCrV1ifX54LbdOKg YtiJzZIY32fkMFOH7E8dFmr0PhVbjKaRBMpsjMGuX3F2rt7VRbX08hgJ; Authentication-Results: rtp-dkim-2; header.From=bberry@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: Thomas Clausen , manet@ietf.org, "Stan Ratliff \(sratliff\)" 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'll have to agree with Stan and Charlie. Parsing TLV and sub TLVs should not require an ordering. While your code may be agnostic, I think the comments are on the draft, not your code (we've not seen the code...). in-line -Bo Dearlove, Christopher (UK) wrote: > I don't agree. I have general purpose packetbb code that > is quite agnostic as to whether it's being used for OLSRv2 > (for example) or not, and has no built in knowledge of > current or (obviously) future TLVs, and this has minimal > impact on generating packetbb messages (when you add a > TLV it either slots in, or reports an inconsistency in > what you requested, and doesn't add it) and this makes > the parsing/reception at the other end much easier. So > I'm not just hypothesising, I have (to use a phrase) > running code, which does consider the future as well. > > > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] > Sent: 13 August 2007 14:50 > To: Dearlove, Christopher (UK); manet@ietf.org > Cc: Thomas Clausen > Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 > > > *** WARNING *** > > This mail has originated outside your organization, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > >> It may add complexity to the packet/message generation, >> but very little. Adding no duplication adds no work, it's >> what you should do. Adding ordering just makes you insert >> new TLVs in the right place rather than at the end, you >> don't actually sort. You may even generate them in the >> appropriate order in the first place, in which case there >> is no added complexity. > > I disagree with this assessment. While it may place no > additional complexity on the implementation *now*, > it may in the future, depending on what TLV's are > added, and what their numbering scheme is. > > This is something that networking systems have > handled for longer than I care to remember. Even > (dare I say it?) SNA didn't have this restriction. > > In sum, I agree with Charlie -- this restriction adds > complexity where its not needed, and I think it should > be lifted. > > Regards, > Stan > > > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Sent: Monday, August 13, 2007 6:39 AM > To: manet@ietf.org > Cc: Thomas Clausen > Subject: [manet] Re: draft-ietf-manet-packetbb-08 > > > With regard to the constraints in packetbb: > > - Specifying ordering and non-duplicate TLVs in packetbb > looks like it adds complexity, but it really reduces > implementation complexity, as the following points > indicate. > > - It may add complexity to the packet/message generation, > but very little. Adding no duplication adds no work, it's > what you should do. Adding ordering just makes you insert > new TLVs in the right place rather than at the end, you > don't actually sort. You may even generate them in the > appropriate order in the first place, in which case there > is no added complexity. > > - Now at the receiver you can tell a malformed TLV block > (and hence message, and if you choose, packet) at the > parsing stage, and very easily. > > - With a duplicate TLV you don't need to force complex > decisions as to whether you use the first, or most > restrictive, or whatever, choice. It is malformed by > definition and you can allow the implementation to > do what it considers sensible - and that can be the > easy decision to discard the packet/message/block. > And note that this can be at parsing, not processing. I think it would be beneficial if the draft provided guidelines on parsing errors vs processing errors. Doing so would facilitate interoperability. There are two sides to the problem, how the originator handles the error and how the receive handles the error. A degree of synergy can only help. is an 8 bit field specifying the interpretation of the remainder of the TLV: ...cut... bit 1 (extended) and bit 2 (novalue): MUST NOT both be set ('1'). ..... For example, what if both bits are set? What MUST the code NOT do? Or WHAT MUST the code do? There are other places that would benefit from some level of guidance. > > - Thus receiver processing can be (and probably should > be) much simpler. This may be case today in your opinion, but may not be the reality if the protocol evolves. It appears this is a concern that deserves more discussion. > > - This is aside from the additional gain in reduced > searching for TLVs (stop when not found). Perhaps this is a parser rule that should be added to the draft. .... stop and discard the message.... ? > > - Philosophically, once you get a malformed message, > do you trust the sender? Do you want to try to make > the best of it? Do you just want to ignore it? The > decision is that of the receiver implementor. > > For these reasons I am strongly against removing any > of these contraints. > > ******************************************************************** > 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 > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 13 10:35: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 1IKazY-0006Qx-F0; Mon, 13 Aug 2007 10:34:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKazW-0006Ib-Fh for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 10:33:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKazW-0006IO-5a for manet@ietf.org; Mon, 13 Aug 2007 10:33:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKazU-0006lN-SH for manet@ietf.org; Mon, 13 Aug 2007 10:33:58 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Aug 2007 10:33:55 -0400 X-IronPort-AV: i="4.19,255,1183348800"; d="scan'208"; a="67842805:sNHT625609214" 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 l7DEXtg2026713; Mon, 13 Aug 2007 10:33:55 -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 l7DEXsml009271; Mon, 13 Aug 2007 14:33:55 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); Mon, 13 Aug 2007 10:33:54 -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] Re: draft-ietf-manet-packetbb-08 Date: Mon, 13 Aug 2007 10:33:54 -0400 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC7640455854D@xmb-rtp-208.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: draft-ietf-manet-packetbb-08 Thread-Index: Acfa2c63TgKyqjNaTa2GZE9FdUFD7ACu1JKQAAbOqiAAAFH84AABQhew From: "Stan Ratliff \(sratliff\)" To: "Dearlove, Christopher \(UK\)" , X-OriginalArrivalTime: 13 Aug 2007 14:33:54.0934 (UTC) FILETIME=[F9DFF960:01C7DDB6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4919; t=1187015635; x=1187879635; 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]=20Re=3A=20draft-ietf-manet-packetbb-08 |Sender:=20 |To:=20=22Dearlove, =20Christopher=20\(UK\)=22=20,=0A=20=20=20=20=20=20=20=20; bh=1/lG687zi5x5jrkPnCK9Tb16gobBW/ZSag9EMuCJyVc=; b=fO33/MdNQxNICC7dXNFCUJxTg/UUxyV/dzkUUnoeJofgUOu+lvvPg+c7O8quUV6rz9UJrCjD 4GKFhEYKnM0McaVvwy671PCZ0DYhEUUjSYjFtd8MkQgC8QhnrdGYeoM8; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 But the problem with your running code is the "reports an inconsistency in what you requested, and doesn't add it"=20 part. That is what may require, as we add TLV's in the future, that a chain of TLV's be re-ordered before it is=20 sent.=20 Regards, Stan =20 -----Original Message----- From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]=20 Sent: Monday, August 13, 2007 10:03 AM To: Stan Ratliff (sratliff); manet@ietf.org Cc: Thomas Clausen Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 I don't agree. I have general purpose packetbb code that is quite agnostic as to whether it's being used for OLSRv2 (for example) or not, and has no built in knowledge of current or (obviously) future TLVs, and this has minimal impact on generating packetbb messages (when you add a TLV it either slots in, or reports an inconsistency in what you requested, and doesn't add it) and this makes the parsing/reception at the other end much easier. So I'm not just hypothesising, I have (to use a phrase) running code, which does consider the future as well. =20 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 13 August 2007 14:50 To: Dearlove, Christopher (UK); manet@ietf.org Cc: Thomas Clausen Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 *** 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 >It may add complexity to the packet/message generation, >but very little. Adding no duplication adds no work, it's >what you should do. Adding ordering just makes you insert >new TLVs in the right place rather than at the end, you >don't actually sort. You may even generate them in the >appropriate order in the first place, in which case there >is no added complexity. I disagree with this assessment. While it may place no=20 additional complexity on the implementation *now*,=20 it may in the future, depending on what TLV's are=20 added, and what their numbering scheme is.=20 This is something that networking systems have=20 handled for longer than I care to remember. Even (dare I say it?) SNA didn't have this restriction. In sum, I agree with Charlie -- this restriction adds=20 complexity where its not needed, and I think it should be lifted.=20 Regards, Stan -----Original Message----- From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]=20 Sent: Monday, August 13, 2007 6:39 AM To: manet@ietf.org Cc: Thomas Clausen Subject: [manet] Re: draft-ietf-manet-packetbb-08 With regard to the constraints in packetbb: - Specifying ordering and non-duplicate TLVs in packetbb looks like it adds complexity, but it really reduces implementation complexity, as the following points indicate. - It may add complexity to the packet/message generation, but very little. Adding no duplication adds no work, it's what you should do. Adding ordering just makes you insert new TLVs in the right place rather than at the end, you don't actually sort. You may even generate them in the appropriate order in the first place, in which case there is no added complexity. - Now at the receiver you can tell a malformed TLV block (and hence message, and if you choose, packet) at the parsing stage, and very easily. - With a duplicate TLV you don't need to force complex decisions as to whether you use the first, or most restrictive, or whatever, choice. It is malformed by definition and you can allow the implementation to do what it considers sensible - and that can be the easy decision to discard the packet/message/block. And note that this can be at parsing, not processing. - Thus receiver processing can be (and probably should be) much simpler. - This is aside from the additional gain in reduced searching for TLVs (stop when not found). - Philosophically, once you get a malformed message, do you trust the sender? Do you want to try to make the best of it? Do you just want to ignore it? The decision is that of the receiver implementor. For these reasons I am strongly against removing any of these contraints. ******************************************************************** 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 Mon Aug 13 10:44: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 1IKb7w-0002ho-6G; Mon, 13 Aug 2007 10:42:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKb7u-0002hX-T3 for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 10:42:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKb7u-0002hP-HX for manet@ietf.org; Mon, 13 Aug 2007 10:42: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 1IKb7t-0007bj-M5 for manet@ietf.org; Mon, 13 Aug 2007 10:42:38 -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 l7DEgaxu021902 for ; Mon, 13 Aug 2007 15:42:36 +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 l7DEgaSR000501 for ; Mon, 13 Aug 2007 15:42:36 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 13 Aug 2007 15:42:36 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 15:42:35 +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: draft-ietf-manet-packetbb-08 Date: Mon, 13 Aug 2007 15:42:35 +0100 Message-ID: In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC7640455854D@xmb-rtp-208.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: draft-ietf-manet-packetbb-08 thread-index: Acfa2c63TgKyqjNaTa2GZE9FdUFD7ACu1JKQAAbOqiAAAFH84AABQhewAAAbcnA= References: <7FB7EE0A621BA44B8B69E5F0A09DC7640455854D@xmb-rtp-208.amer.cisco.com> From: "Dearlove, Christopher \(UK\)" To: "Stan Ratliff \(sratliff\)" , X-OriginalArrivalTime: 13 Aug 2007 14:42:35.0883 (UTC) FILETIME=[30627BB0:01C7DDB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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 If I get that message there's a fault in the code using the packetbb code. Having that in the packetbb code is a "belt and braces" thing. There is never a reason to reorder TLVs. Each TLV has a type. When you add it, insert it in the right place. When you add the next TLV, insert that in the right place. Reorderinf never required. -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 13 August 2007 15:34 To: Dearlove, Christopher (UK); manet@ietf.org Cc: Thomas Clausen Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 But the problem with your running code is the "reports an inconsistency in what you requested, and doesn't add it"=20 part. That is what may require, as we add TLV's in the future, that a chain of TLV's be re-ordered before it is=20 sent.=20 Regards, Stan =20 -----Original Message----- From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]=20 Sent: Monday, August 13, 2007 10:03 AM To: Stan Ratliff (sratliff); manet@ietf.org Cc: Thomas Clausen Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 I don't agree. I have general purpose packetbb code that is quite agnostic as to whether it's being used for OLSRv2 (for example) or not, and has no built in knowledge of current or (obviously) future TLVs, and this has minimal impact on generating packetbb messages (when you add a TLV it either slots in, or reports an inconsistency in what you requested, and doesn't add it) and this makes the parsing/reception at the other end much easier. So I'm not just hypothesising, I have (to use a phrase) running code, which does consider the future as well. =20 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 13 August 2007 14:50 To: Dearlove, Christopher (UK); manet@ietf.org Cc: Thomas Clausen Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 *** 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 >It may add complexity to the packet/message generation, >but very little. Adding no duplication adds no work, it's >what you should do. Adding ordering just makes you insert >new TLVs in the right place rather than at the end, you >don't actually sort. You may even generate them in the >appropriate order in the first place, in which case there >is no added complexity. I disagree with this assessment. While it may place no=20 additional complexity on the implementation *now*,=20 it may in the future, depending on what TLV's are=20 added, and what their numbering scheme is.=20 This is something that networking systems have=20 handled for longer than I care to remember. Even (dare I say it?) SNA didn't have this restriction. In sum, I agree with Charlie -- this restriction adds=20 complexity where its not needed, and I think it should be lifted.=20 Regards, Stan -----Original Message----- From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]=20 Sent: Monday, August 13, 2007 6:39 AM To: manet@ietf.org Cc: Thomas Clausen Subject: [manet] Re: draft-ietf-manet-packetbb-08 With regard to the constraints in packetbb: - Specifying ordering and non-duplicate TLVs in packetbb looks like it adds complexity, but it really reduces implementation complexity, as the following points indicate. - It may add complexity to the packet/message generation, but very little. Adding no duplication adds no work, it's what you should do. Adding ordering just makes you insert new TLVs in the right place rather than at the end, you don't actually sort. You may even generate them in the appropriate order in the first place, in which case there is no added complexity. - Now at the receiver you can tell a malformed TLV block (and hence message, and if you choose, packet) at the parsing stage, and very easily. - With a duplicate TLV you don't need to force complex decisions as to whether you use the first, or most restrictive, or whatever, choice. It is malformed by definition and you can allow the implementation to do what it considers sensible - and that can be the easy decision to discard the packet/message/block. And note that this can be at parsing, not processing. - Thus receiver processing can be (and probably should be) much simpler. - This is aside from the additional gain in reduced searching for TLVs (stop when not found). - Philosophically, once you get a malformed message, do you trust the sender? Do you want to try to make the best of it? Do you just want to ignore it? The decision is that of the receiver implementor. For these reasons I am strongly against removing any of these contraints. ******************************************************************** 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 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 13 11:13:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbZR-0000Op-2b; Mon, 13 Aug 2007 11:11:05 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKbZP-0000Oe-3G for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 11:11:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbZO-0000OV-NR for manet@ietf.org; Mon, 13 Aug 2007 11:11:02 -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 1IKbZN-0000H4-Mc for manet@ietf.org; Mon, 13 Aug 2007 11:11:02 -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 l7DFAvuf005983 for ; Mon, 13 Aug 2007 16:10:57 +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 l7DFAvpQ003441 for ; Mon, 13 Aug 2007 16:10:57 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 13 Aug 2007 16:10:56 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 16:10:56 +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: draft-ietf-manet-packetbb-08 Date: Mon, 13 Aug 2007 16:10:55 +0100 Message-ID: In-Reply-To: <46C06BB1.2090000@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: draft-ietf-manet-packetbb-08 thread-index: Acfdtv849CIiMmCHQymrBWcZbYnCuwAATTvQ References: <7FB7EE0A621BA44B8B69E5F0A09DC76404558512@xmb-rtp-208.amer.cisco.com> <46C06BB1.2090000@cisco.com> From: "Dearlove, Christopher \(UK\)" To: "Bo Berry" X-OriginalArrivalTime: 13 Aug 2007 15:10:56.0706 (UTC) FILETIME=[26277A20:01C7DDBC] X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: manet@ietf.org, "Thomas Heide Clausen \(work\)" , "Stan Ratliff \(sratliff\)" 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 Yes, you've not seen the code. But my point is that I have what I believe is a solid argument why ordering adds trivially to the complexity at the transmitter, and reduces complexity at the receiver. The point of mentioning the code is that my argument is backed by experience doing it, it's not just academic. In addition this was introduced based on a suggestion from one of the contributors other than the authors, who are more driven than I am by complexity considerations. I'm hoping he, or a colleague, will join in this discussion. Your inline comments on erroneous packets. We do address this issue in NHDP/OLSRv2. I think (and note that here I haven't yet discussed this point with the other authors) it is not the place of packetbb to say what a protocol using packetbb must do. It may be the place of packetbb to explicitly say that handling an erroneous packet is up to the protocol. This could include listing the most obvious actions to take (discarding the packet or discarding the message) and possibly noting that in some cases no other options than these are possible. This we could probably add. But packetbb is not itself a protocol, it's not, I think, for it to require a specific single behaviour, in particular not to specify which of the choice of the two discard options is appropriate. (There are also, in some cases, other possible options, such as just discarding a TLV block, although I do not think these appropriate to NHDP/OLSRv2.) (There is also an issue as to when parsing occurs - OLSRv2 has explicit permission for "just in time" parsing, only doing so when necessary, not automatically on reception, but while also permitting that - this allows implementations to trade off different forms of complexity.) In this context an erroneous packet (or message) would be (I think, I need to check) defined as anything which doesn't match the regexp specification, or which violates a MUST. -----Original Message----- From: Bo Berry [mailto:bberry@cisco.com]=20 Sent: 13 August 2007 15:33 To: Dearlove, Christopher (UK) Cc: Stan Ratliff (sratliff); manet@ietf.org; Thomas Clausen Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08 I'll have to agree with Stan and Charlie. Parsing TLV and sub TLVs should not require an ordering. While your code may be agnostic, I think the comments are on the draft, not your code (we've not seen the code...). in-line -Bo Dearlove, Christopher (UK) wrote: > I don't agree. I have general purpose packetbb code that > is quite agnostic as to whether it's being used for OLSRv2 > (for example) or not, and has no built in knowledge of > current or (obviously) future TLVs, and this has minimal > impact on generating packetbb messages (when you add a > TLV it either slots in, or reports an inconsistency in > what you requested, and doesn't add it) and this makes > the parsing/reception at the other end much easier. So > I'm not just hypothesising, I have (to use a phrase) > running code, which does consider the future as well. > =20 >=20 > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 > Sent: 13 August 2007 14:50 > To: Dearlove, Christopher (UK); manet@ietf.org > Cc: Thomas Clausen > Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 >=20 >=20 > *** WARNING *** >=20 > 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 >=20 >> It may add complexity to the packet/message generation, >> but very little. Adding no duplication adds no work, it's >> what you should do. Adding ordering just makes you insert >> new TLVs in the right place rather than at the end, you >> don't actually sort. You may even generate them in the >> appropriate order in the first place, in which case there >> is no added complexity. >=20 > I disagree with this assessment. While it may place no=20 > additional complexity on the implementation *now*,=20 > it may in the future, depending on what TLV's are=20 > added, and what their numbering scheme is.=20 >=20 > This is something that networking systems have=20 > handled for longer than I care to remember. Even > (dare I say it?) SNA didn't have this restriction. >=20 > In sum, I agree with Charlie -- this restriction adds=20 > complexity where its not needed, and I think it should > be lifted.=20 >=20 > Regards, > Stan >=20 >=20 > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]=20 > Sent: Monday, August 13, 2007 6:39 AM > To: manet@ietf.org > Cc: Thomas Clausen > Subject: [manet] Re: draft-ietf-manet-packetbb-08 >=20 >=20 > With regard to the constraints in packetbb: >=20 > - Specifying ordering and non-duplicate TLVs in packetbb > looks like it adds complexity, but it really reduces > implementation complexity, as the following points > indicate. >=20 > - It may add complexity to the packet/message generation, > but very little. Adding no duplication adds no work, it's > what you should do. Adding ordering just makes you insert > new TLVs in the right place rather than at the end, you > don't actually sort. You may even generate them in the > appropriate order in the first place, in which case there > is no added complexity. >=20 > - Now at the receiver you can tell a malformed TLV block > (and hence message, and if you choose, packet) at the > parsing stage, and very easily. >=20 > - With a duplicate TLV you don't need to force complex > decisions as to whether you use the first, or most > restrictive, or whatever, choice. It is malformed by > definition and you can allow the implementation to > do what it considers sensible - and that can be the > easy decision to discard the packet/message/block. > And note that this can be at parsing, not processing. I think it would be beneficial if the draft provided guidelines on parsing errors vs processing errors. Doing so would facilitate interoperability. There are two sides to the problem, how the originator handles the error and how the receive handles the error. A degree of synergy can only help. is an 8 bit field specifying the interpretation of the remainder of the TLV: ...cut... bit 1 (extended) and bit 2 (novalue): MUST NOT both be set ('1'). ..... For example, what if both bits are set? What MUST the code NOT do? Or WHAT MUST the code do? There are other places that would benefit from some level of guidance. >=20 > - Thus receiver processing can be (and probably should > be) much simpler. This may be case today in your opinion, but may not be the reality if the protocol evolves. It appears this is a concern that deserves more discussion. >=20 > - This is aside from the additional gain in reduced > searching for TLVs (stop when not found). Perhaps this is a parser rule that should be added to the draft. .... stop and discard the message.... ? >=20 > - Philosophically, once you get a malformed message, > do you trust the sender? Do you want to try to make > the best of it? Do you just want to ignore it? The > decision is that of the receiver implementor. >=20 > For these reasons I am strongly against removing any > of these contraints. >=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 >=20 >=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 Mon Aug 13 11:35:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbvb-0005wz-9i; Mon, 13 Aug 2007 11:33:59 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKbvZ-0005wn-Fs for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 11:33:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbvZ-0005wf-69 for manet@ietf.org; Mon, 13 Aug 2007 11:33:57 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKbvX-0000B6-OE for manet@ietf.org; Mon, 13 Aug 2007 11:33:56 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l7DFXrTi017795; Mon, 13 Aug 2007 11:33:53 -0400 (EDT) Message-Id: <200708131533.l7DFXrTi017795@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007081311335202916 ; Mon, 13 Aug 2007 11:33:52 -0400 From: "Justin Dean" To: "'Charles E. Perkins'" , "'Manet'" Subject: RE: [manet] NHDP "Hello" packet too big Date: Mon, 13 Aug 2007 11:38:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acfa4N0UT4erGnpFQCGU2mPVqT9t2gC1daGA In-Reply-To: <46BBA971.30403@nokia.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b 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 First thank you for this example. There are a few things I would like to try and clear up and having a solid example will help me do that. First the two samples you are including do not include the same information. Particularly using full message header semantics and the addition of the hold and validity times. If we are to compare the two packet formats suggested they should contain the same information and packetbb allows you to do this. By only including the information included in your smurf-like packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HELLO | flags |#Selves|#Heard | #Sym | #Lost | Seq# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address(es) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hop count and ttl values in the packetbb message header are not needed and they can be turned off using the semantics bits. A 2 byte savings. Validity time and Hold time values are required per NHDP but that's not a packetbb issue so we can remove those as well. An 8 byte savings. (note 2 bytes are still required to set the tlv field to 0). Also one example had 3 addresses an the other 4. A 2 byte savings (mid and tlv linktype) The rest of the information has to be included so that's 38 bytes down from 50 which is still MUCH larger than 14-15. However there are, in my opinion, quite a few VERY limiting features of the suggested alternative. The #of any give type of neighbor is limited to a max of 15. If there are more than 15 symmetric neighbors it can't convey that information. A simple "fix" would be to increase the size to 1 fully octet for each field with a flag. The assumption of a 3 byte head and 1 byte tails may not always hold true, again a "fix" could be to use 2 more bits of your flags to allow the 4 different methods but then what about ipv6 support. The included seq# space is again 15. While this may be sufficient for the requirements you are envisioning it would not be sufficient for a large portion of possible protocols which I envision using packetbb. Which brings me to my main point. This packet format is designed to work very well for ONE protocol not many different possible protocols. Many types of information can not be included without modification of the smurf-like packet format. Information such as; including multiple message types in the same packet (possibly from even differing protocols), including "other" semi standard information such as ttl, hopcount, conveying node information such as willingness, conveying address specific information such as a metric, or mpr status. Packetbb can do all of these things natively without change to the document or packet layout, while supporting a wide range of possible protocol requirements. The alternative as I hope I have demonstrated becomes messy and larger if these things would be incorporated. I would also like to point out how things might grow byte wise in terms of packetbb as this example is a pretty worst case situation. Each new address added to the packetbb format, assuming no new neighbor types and similar headers, would add 2 bytes for each address without changing how the link status tlvs are being used. At some point (didn't do the math right now) using 3 different tlvs with indexes would become more efficient than including 1 byte for each address in the tlv. After this point each additional address would only add one byte of overhead. Also oftentimes the only type of address being included in a hello message after the initial startup is symmetric which would require a 6 bytes (3 less than the given example here when using 4 addresses!) to convey for any number of addresses (if they are all symmetric). The main thing though is the flexibility of the format. The cost in terms of bytes is in my opinion worth it its not orders or magnitude greater. Discussions about a totally different packet format designed around specific protocol requirements with little flexibility are in my opinion not that helpful. Suggested changes to improve compactness while maintaining flexibility is. Justin -----Original Message----- From: Charles E. Perkins [mailto:charles.perkins@nokia.com] Sent: Thursday, August 09, 2007 7:55 PM To: Manet Subject: [manet] NHDP "Hello" packet too big Hello folks, Here is some text that I wrote up at the last IETF to compare the existing NHDP message to a smaller format, roughly taken from the SMURF protocol specification with some more fields added so that it would have additional functionality as specified by NHDP. The bottom line: NHDP example in Appendix A: 50 bytes SMURF-like packet format: 14 bytes TLV version of SMURF-like format: 15 bytes. Plus the NHDP overhead will get worse as more neighbors are counted. This is important because the example shown has only 4 neighbors, and for good connectivity it is usually recommended to have at least 6 (or 5.7 or something like that). For a lot of published papers (maybe even most of them), the number of neighbors is quite a bit higher. I would like to suggest that either that we encourage the development of some alternative HELLO packet format, or else that the basic NHDP format should be substantially revised. Here is my text with examples, derived from Appendix A of NHDP: ===================================== octet) addresses without prefix TLVs. The message is transmitted with a full message header (message semantics octet is 0) with a hop limit of 1 and a hop count of 0. The overall message length is 50 octets. The message contains a message TLV block with content length 8 octets containing two message TLVs, of types VALIDITY_TIME and INTERVAL_TIME. Each uses a TLV with semantics value 8, indicating that no start and stop indexes are included, and each has a value length of 1 octet. The values included (0x68 and 0x50) are time codes representing the default values of parameters H_HOLD_TIME and HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the default value of constant C (0.0625 second). The first address block contains 1 local interface address. The semantics octet value 2 indicates no address tail, and the head length of 4 octets indicates no address mid sections. This address block has no TLVs (TLV block content length 0 octets). The second, and last, address block contains 4 neighbor interface addresses. The semantics octet value 2 indicates no address tail, the head length of 3 octets indicates address mid sections of one octet each. The following TLV block (content length 7 octets) includes one LINK_STATUS TLV which reports the link status values of all reported neighbors in a single multivalue TLV: the first two addresses are HEARD, the third address is SYMMETRIC and the fourth address is LOST. The TLV semantics value of 40 indicates, in addition to that this is a multivalue TLV, that no start and stop indexes are included, since values for all addresses are included. The TLV value length of 4 octets indicates one octet per value per address. 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 full message header (message semantics octet is 0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HELLO |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ hop limit of 1 and a hop count of 0: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The message contains a message TLV block with content length 8 octets containing two message TLVs, of types VALIDITY_TIME and INTERVAL_TIME. Each uses a TLV with semantics value 8, indicating that no start and stop indexes are included, and each has a value length of 1 octet. The values included (0x68 and 0x50) are time codes representing the default values of parameters H_HOLD_TIME and HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the default value of constant C (0.0625 second). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VALIDITY_TIME |0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 1 1 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INTERVAL_TIME |0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 1 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first address block contains 1 local interface address. The semantics octet value 2 indicates no address tail, and the head length of 4 octets indicates no address mid sections. This address block has no TLVs (TLV block content length 0 octets). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 0| Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | +-+-+-+-+-+-+-+-+ The second, and last, address block contains 4 neighbor interface addresses. The semantics octet value 2 indicates no address tail, the head length of 3 octets indicates address mid sections of one octet each. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1| Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | Mid | Mid | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | +-+-+-+-+-+-+-+-+ The following TLV block (content length 7 octets) includes one LINK_STATUS TLV which reports the link status values of all reported neighbors in a single multivalue TLV: the first two addresses are HEARD, the third address is SYMMETRIC and the fourth address is LOST. The TLV semantics value of 40 indicates, in addition to that this is a multivalue TLV, that no start and stop indexes are included, since values for all addresses are included. The TLV value length of 4 octets indicates one octet per value per address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 1 0 0 0|0 0 0 0 0 1 0 0| HEARD | HEARD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SYMMETRIC | LOST | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Alternative layout [14 bytes] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HELLO | flags |#Selves|#Heard | #Sym | #Lost | Seq# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address(es) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | Mid | ..... extensions .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Or, new TLV def "Hello data element" [15 bytes = 5 bytes + 10 bytes data] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=HELLO | Length | flags |#Selves|#Heard | #Sym | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | #Lost | Seq# | ..... data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where, "data" is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address(es) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | Mid | ..... extensions .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===================================== Regards, Charlie P. _______________________________________________ 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 Mon Aug 13 13:00: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 1IKdFo-0001Bj-Uc; Mon, 13 Aug 2007 12:58:56 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKdFn-0001Bc-9u for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 12:58:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdFm-0001BU-VM for manet@ietf.org; Mon, 13 Aug 2007 12:58:55 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKdFm-0004wA-9q for manet@ietf.org; Mon, 13 Aug 2007 12:58:54 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7DGwjvR011827; Mon, 13 Aug 2007 19:58:49 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 19:58:16 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 11:58:14 -0500 Received: from [172.18.141.131] ([172.18.141.131]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 11:58:13 -0500 Message-ID: <46C08DA4.8030704@nokia.com> Date: Mon, 13 Aug 2007 09:58:12 -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] Re: draft-ietf-manet-packetbb-08 References: <46BB9D9F.2060002@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 16:58:13.0920 (UTC) FILETIME=[23086200:01C7DDCB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Thomas Clausen , manet@ietf.org 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: > With regard to the constraints in packetbb: > > - Specifying ordering and non-duplicate TLVs in packetbb > looks like it adds complexity, but it really reduces > implementation complexity, as the following points > indicate. > I just do not believe this, having written one or two such parsers... > - It may add complexity to the packet/message generation, > but very little. Adding no duplication adds no work, it's > what you should do. My message to you was intended to indicate that one SHOULD be allowed to provide duplicate tlv-typed extensions for certain foreseeable cases. > Adding ordering just makes you insert > new TLVs in the right place rather than at the end, you > don't actually sort. You may even generate them in the > appropriate order in the first place, in which case there > is no added complexity. > You cannot know this for all future uses of packetbb. You can know it for OLSRv2 perhaps, although I would even doubt that given some of its foreseeable extensions. > - Now at the receiver you can tell a malformed TLV block > (and hence message, and if you choose, packet) at the > parsing stage, and very easily. > My point is that such packets should not be considered malformed. > - With a duplicate TLV you don't need to force complex > decisions as to whether you use the first, or most > restrictive, or whatever, choice. It is malformed by > definition and you can allow the implementation to > do what it considers sensible - and that can be the > easy decision to discard the packet/message/block. > And note that this can be at parsing, not processing. > With a duplicate TLV you can do whatever the specification indicates, including making use of the valid contents to record more data about nodes and topology. > - Thus receiver processing can be (and probably should > be) much simpler. > Or not, if prohibiting duplicates requires torquing the protocol design unnecessarily. > - This is aside from the additional gain in reduced > searching for TLVs (stop when not found). > Sorry, but this is completely unresponsive to the point. > - Philosophically, once you get a malformed message, > do you trust the sender? Do you want to try to make > the best of it? Do you just want to ignore it? The > decision is that of the receiver implementor. > Please refer to my suggestion that these packets should not be considered malformed. > For these reasons I am strongly against removing any > of these contraints. > I don't think these reasons are responsive to my points, and given recent discussion I think it is more clear that the constraints should be removed. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 13 13:09: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 1IKdOd-0006Y7-TV; Mon, 13 Aug 2007 13:08:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKdOc-0006Xy-Rp for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 13:08:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdOc-0006X2-HU for manet@ietf.org; Mon, 13 Aug 2007 13:08:02 -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 1IKdOb-00044X-2P for manet@ietf.org; Mon, 13 Aug 2007 13:08:02 -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 l7DH7v5c000352 for ; Mon, 13 Aug 2007 18:07:57 +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 l7DH7vq5007073 for ; Mon, 13 Aug 2007 18:07:57 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 13 Aug 2007 18:07:57 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 18:07:57 +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: draft-ietf-manet-packetbb-08 Date: Mon, 13 Aug 2007 18:07:56 +0100 Message-ID: In-Reply-To: <46C08DA4.8030704@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: draft-ietf-manet-packetbb-08 thread-index: Acfdy2BDJ4vg3DBRRoulEaFCI/9IOAAACywQ References: <46BB9D9F.2060002@nokia.com> <46C08DA4.8030704@nokia.com> From: "Dearlove, Christopher \(UK\)" To: "Charles E. Perkins" , X-OriginalArrivalTime: 13 Aug 2007 17:07:57.0499 (UTC) FILETIME=[7EDF78B0:01C7DDCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 >I don't think these reasons are responsive to my points I believe they are responsive in that they argue why the constraints should be retained. I find your position inconsistent. On the one hand you argue for saving every last octet (with which I don't agree, flexibility is important) but here you are arguing for a hypothetical future need (more than one TLV of the same type associated with the same address - note that more than one TLV of the same type in the same TLV block is valid) with no use case and which is against the TLV philosophy in packetbb, despite that it adds complexity, not reduces it, where it matters. I strongly disagree that you have made a good case for removal, let alone that the case is clear, and I strongly oppose removing the constraints. ******************************************************************** 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 Aug 13 13:30:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdiG-0007XB-0S; Mon, 13 Aug 2007 13:28:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKdiE-0007SY-Eo for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 13:28:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdiE-0007SO-4q for manet@ietf.org; Mon, 13 Aug 2007 13:28:18 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKdiC-0005yk-UR for manet@ietf.org; Mon, 13 Aug 2007 13:28:18 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Aug 2007 13:27:44 -0400 X-IronPort-AV: i="4.19,255,1183348800"; d="scan'208"; a="128737741:sNHT4170664736" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7DHRhKm031848; Mon, 13 Aug 2007 13:27:43 -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 l7DHRPmt020021; Mon, 13 Aug 2007 17:27:41 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); Mon, 13 Aug 2007 13:27:34 -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] Re: draft-ietf-manet-packetbb-08 Date: Mon, 13 Aug 2007 13:27:34 -0400 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC7640455861C@xmb-rtp-208.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: draft-ietf-manet-packetbb-08 Thread-Index: Acfdy2BDJ4vg3DBRRoulEaFCI/9IOAAACywQAACaddA= From: "Stan Ratliff \(sratliff\)" To: "Dearlove, Christopher \(UK\)" , "Charles E. Perkins" , X-OriginalArrivalTime: 13 Aug 2007 17:27:34.0962 (UTC) FILETIME=[3CB21120:01C7DDCF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2476; t=1187026063; x=1187890063; c=relaxed/simple; s=rtpdkim1001; 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]=20Re=3A=20draft-ietf-manet-packetbb-08 |Sender:=20 |To:=20=22Dearlove, =20Christopher=20\(UK\)=22=20, =0A=20=20=20=20=20=20=20=20=22Charles=20E.=20Perkins=22=20,=20; bh=Lz9sEPLtGu91+Afa0oAEz5tQVZV/2A/ekMq+wdOO0FU=; b=Fp/G+GhPhB7eZO82oeJy7JJOViZnUBdj4SzQBVFBPspcy1ZFWfpab6esAZCaFhr1AlVb4a/e 6pfJucdT2+iJlvP7TTLmO3mkb84debbzYNCSlXfPi/41/ro4zbzD8Aek; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 =20 >-----Original Message----- >From: Dearlove, Christopher (UK)=20 >[mailto:Chris.Dearlove@baesystems.com]=20 >Sent: Monday, August 13, 2007 1:08 PM >To: Charles E. Perkins; manet@ietf.org >Cc: Thomas Heide Clausen (work) >Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 > > >>I don't think these reasons are responsive to my points > >I believe they are responsive in that they argue why >the constraints should be retained. > >I find your position inconsistent. On the one hand you >argue for saving every last octet (with which I don't >agree, flexibility is important) but here you are >arguing for a hypothetical future need (more than one >TLV of the same type associated with the same address >- note that more than one TLV of the same type in the >same TLV block is valid) with no use case and which is >against the TLV philosophy in packetbb, despite that >it adds complexity, not reduces it, where it matters. > Odd. I don't find the position to be inconsistent; it is simply=20 a case of favoring additional computational complexity over transmission size. I agree with the position, because=20 1. In low-power devices, the transmitter is often the device that consumes the most energy, and=20 2. As packet size goes up, so does probability of error.=20 >I strongly disagree that you have made a good case for >removal, let alone that the case is clear, and I strongly >oppose removing the constraints. > The main case, as Charlie stated, is that you cannot know, for all future uses of packetbb, what processing order the=20 TLV's will need to be inserted in, hence, packets that=20 contain either out-of-order or duplicate TLV's should not=20 be considered malformed. This approach seems to provide=20 the maximum flexibility, and as you state, "flexibility is important". Regards, Stan =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 > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 13 14:31:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKefU-0006eo-GY; Mon, 13 Aug 2007 14:29:32 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKefS-0006ea-Qq for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 14:29:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKefS-0006eS-FV for manet@ietf.org; Mon, 13 Aug 2007 14:29:30 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKefR-0000BY-Ou for manet@ietf.org; Mon, 13 Aug 2007 14:29:30 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l7DIT6ET025839 for ; Mon, 13 Aug 2007 14:29:29 -0400 (EDT) Message-Id: <200708131829.l7DIT6ET025839@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007081314292804040 for ; Mon, 13 Aug 2007 14:29:28 -0400 From: "Justin Dean" To: Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 Date: Mon, 13 Aug 2007 14:34:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acfdy2BDJ4vg3DBRRoulEaFCI/9IOAAACywQAACaddAAAT7yEA== In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC7640455861C@xmb-rtp-208.amer.cisco.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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 My thoughts on the constraint issues. For clarity the text of the document. 1 TLVs in the same TLV block MUST be sorted in non-descending tlv- fulltype order. 2 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. 3 Two or more TLVs with the same tlv-fulltype in the same address block TLV block MUST NOT be associated with the same copy of an address (i.e. they must not have overlapping index ranges). 4 TLVs with the same tlv-fulltype associated with the same address block MUST be sorted in ascending index-start order. 1 and 4 deal with ordering of the tlvs within a packet. I can see how its advantageous to have this ordering but I can also see how it may not be necessary. The major advantage I can see is with 1 is being able to read a lack of a tlv by the ordering without having to read the entire tlv block. If multiple protocols in an integrated system are only looking for specific tlv types they can more quickly decide if the information is there or not, i.e. if I am looking for page 10 and I get to page 11 then its not there no need to read the next 100 pages. It is not NEEDED, however, protocols based off of packetbb MUST know if this constraint is true for all packetbb packets or this advantage is lost. The advantages of 4 are a little bit less clear but the same principle applies. And if the ordering is not stated here for both 1 and 4 no later document can later state ordering constraints and have it work for all packetbb protocols. I think 2 is something everyone can agree on as it allows both types of behaviors for a message/packet tlv. With 3 this was introduced to avoid confusion on which value should be used. I personally would be ok with wording this closer to 2 in mandating that the tlv definitions explicitly disallow or allow. There are issues with allowing this but there may also be an advantages. A hypothetical example; 10 addresses each of which is either bright or dark and blue or red 1 bright red 2 bright blue 3 bright red 4 bright red 5 bright red 6 dark red 7 dark blue 8 dark red 9 dark red 10 dark red Under the current constraints it would require 1 indexed tlv for bright 1 indexed tlv for dark, then either a m-tlv for all the addressed or a mixture of m-tlvs and indexed tlvs for the color. If constraint of more than one was lifted for the color tlv a m-tlv for all nodes being red and then 2 single tlvs for the 2 blue nodes may reduce overhead. My current feelings on these 1. I am in favor if keeping it. 2. Keep. 3. More on the fence and leaning towards revised wording closer to 2. 4. Less in favor of keeping than 1 but still leaning towards keeping it. Justin -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] Sent: Monday, August 13, 2007 1:28 PM To: Dearlove, Christopher (UK); Charles E. Perkins; manet@ietf.org Cc: Thomas Heide Clausen (work) Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 >-----Original Message----- >From: Dearlove, Christopher (UK) >[mailto:Chris.Dearlove@baesystems.com] >Sent: Monday, August 13, 2007 1:08 PM >To: Charles E. Perkins; manet@ietf.org >Cc: Thomas Heide Clausen (work) >Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 > > >>I don't think these reasons are responsive to my points > >I believe they are responsive in that they argue why >the constraints should be retained. > >I find your position inconsistent. On the one hand you >argue for saving every last octet (with which I don't >agree, flexibility is important) but here you are >arguing for a hypothetical future need (more than one >TLV of the same type associated with the same address >- note that more than one TLV of the same type in the >same TLV block is valid) with no use case and which is >against the TLV philosophy in packetbb, despite that >it adds complexity, not reduces it, where it matters. > Odd. I don't find the position to be inconsistent; it is simply a case of favoring additional computational complexity over transmission size. I agree with the position, because 1. In low-power devices, the transmitter is often the device that consumes the most energy, and 2. As packet size goes up, so does probability of error. >I strongly disagree that you have made a good case for >removal, let alone that the case is clear, and I strongly >oppose removing the constraints. > The main case, as Charlie stated, is that you cannot know, for all future uses of packetbb, what processing order the TLV's will need to be inserted in, hence, packets that contain either out-of-order or duplicate TLV's should not be considered malformed. This approach seems to provide the maximum flexibility, and as you state, "flexibility is important". Regards, Stan >******************************************************************** >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 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 13 15:01: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 1IKf8P-0004iC-5R; Mon, 13 Aug 2007 14:59:25 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKf8N-0004i0-3W for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 14:59:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKf8M-0004hs-Q8 for manet@ietf.org; Mon, 13 Aug 2007 14:59:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKf8L-00011U-I1 for manet@ietf.org; Mon, 13 Aug 2007 14:59:22 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Aug 2007 14:59:21 -0400 X-IronPort-AV: i="4.19,256,1183348800"; d="scan'208"; a="67873094:sNHT64175190" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7DIxLG5015851; Mon, 13 Aug 2007 14:59:21 -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 l7DIx8mt028743; Mon, 13 Aug 2007 18:59:21 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 14:59:20 -0400 Received: from [10.81.246.136] ([10.81.246.136]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 14:59:20 -0400 Message-ID: <46C0AA02.4050803@cisco.com> Date: Mon, 13 Aug 2007 14:59:14 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08 References: <7FB7EE0A621BA44B8B69E5F0A09DC76404558512@xmb-rtp-208.amer.cisco.com> <46C06BB1.2090000@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 18:59:20.0052 (UTC) FILETIME=[0DFC2340:01C7DDDC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9312; t=1187031561; x=1187895561; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bberry@cisco.com; z=From:=20Bo=20Berry=20 |Subject:=20Re=3A=20[manet]=20Re=3A=20draft-ietf-manet-packetbb-08 |Sender:=20 |To:=20=22Dearlove, =20Christopher=20\(UK\)=22=20; bh=lCrCmVqr6mLXnoQeqEBaUOCUA6t0jLCsXiA986mHzqA=; b=XVuvUe7dUsq6FjY0CYfc0B0JL5k8/3YgJbE6Y1gNJu5mab+U8OjCOY259wheip7okR/mVOR9 l2ZQ//v82yL3RrI9RMy5SiFD5YmxhSpIsZQX7MZm/ZaH3GpVmPhXRFdP; Authentication-Results: rtp-dkim-1; header.From=bberry@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: manet@ietf.org, "Thomas Heide Clausen \(work\)" , "Stan Ratliff \(sratliff\)" 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-line Dearlove, Christopher (UK) wrote: > Yes, you've not seen the code. But my point is that I > have what I believe is a solid argument why ordering > adds trivially to the complexity at the transmitter, > and reduces complexity at the receiver. The point of > mentioning the code is that my argument is backed by > experience doing it, it's not just academic. In addition > this was introduced based on a suggestion from one of the > contributors other than the authors, who are more driven > than I am by complexity considerations. I'm hoping he, or > a colleague, will join in this discussion. But several of us have and are speaking up from our experience and perspectives in designing & developing TLV based protocols, routing, metrics. I think what's required is an open mind to consider the feedback and experience of others. Perhaps the WG Chairs can help moderate. > > Your inline comments on erroneous packets. We do address > this issue in NHDP/OLSRv2. I think (and note that here I > haven't yet discussed this point with the other authors) > it is not the place of packetbb to say what a protocol > using packetbb must do. It may be the place of packetbb > to explicitly say that handling an erroneous packet is > up to the protocol. This could include listing the most > obvious actions to take (discarding the packet or discarding > the message) and possibly noting that in some cases no other > options than these are possible. This we could probably add. That comment should be added. I also think there is room to add guidance for specific cases that are designed in packetbb. > But packetbb is not itself a protocol, it's not, I think, for > it to require a specific single behaviour, in particular not > to specify which of the choice of the two discard options is > appropriate. (There are also, in some cases, other possible > options, such as just discarding a TLV block, although I do > not think these appropriate to NHDP/OLSRv2.) OK, packetbb is not itself a protocol. It is the basis from which manet protocols are to be designed and developed. That being the case there are specific error cases as result of the design. It seems logical that rules/guidance be included. > > (There is also an issue as to when parsing occurs - OLSRv2 > has explicit permission for "just in time" parsing, only > doing so when necessary, not automatically on reception, but > while also permitting that - this allows implementations to > trade off different forms of complexity.) > > In this context an erroneous packet (or message) would > be (I think, I need to check) defined as anything which > doesn't match the regexp specification, or which violates > a MUST. Yes, implementations may format and parse messages differently. All the more reasons why some rules/guidance would be helpful. > > > -----Original Message----- > From: Bo Berry [mailto:bberry@cisco.com] > Sent: 13 August 2007 15:33 > To: Dearlove, Christopher (UK) > Cc: Stan Ratliff (sratliff); manet@ietf.org; Thomas Clausen > Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08 > > > I'll have to agree with Stan and Charlie. Parsing > TLV and sub TLVs should not require an ordering. > While your code may be agnostic, I think the > comments are on the draft, not your code (we've not > seen the code...). > > in-line > > -Bo > > > > Dearlove, Christopher (UK) wrote: >> I don't agree. I have general purpose packetbb code that >> is quite agnostic as to whether it's being used for OLSRv2 >> (for example) or not, and has no built in knowledge of >> current or (obviously) future TLVs, and this has minimal >> impact on generating packetbb messages (when you add a >> TLV it either slots in, or reports an inconsistency in >> what you requested, and doesn't add it) and this makes >> the parsing/reception at the other end much easier. So >> I'm not just hypothesising, I have (to use a phrase) >> running code, which does consider the future as well. >> >> >> -----Original Message----- >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] >> Sent: 13 August 2007 14:50 >> To: Dearlove, Christopher (UK); manet@ietf.org >> Cc: Thomas Clausen >> Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 >> >> >> *** WARNING *** >> >> This mail has originated outside your organization, >> either from an external partner or the Global Internet. >> Keep this in mind if you answer this message. >> >>> It may add complexity to the packet/message generation, >>> but very little. Adding no duplication adds no work, it's >>> what you should do. Adding ordering just makes you insert >>> new TLVs in the right place rather than at the end, you >>> don't actually sort. You may even generate them in the >>> appropriate order in the first place, in which case there >>> is no added complexity. >> I disagree with this assessment. While it may place no >> additional complexity on the implementation *now*, >> it may in the future, depending on what TLV's are >> added, and what their numbering scheme is. >> >> This is something that networking systems have >> handled for longer than I care to remember. Even >> (dare I say it?) SNA didn't have this restriction. >> >> In sum, I agree with Charlie -- this restriction adds >> complexity where its not needed, and I think it should >> be lifted. >> >> Regards, >> Stan >> >> >> -----Original Message----- >> From: Dearlove, Christopher (UK) > [mailto:Chris.Dearlove@baesystems.com] >> Sent: Monday, August 13, 2007 6:39 AM >> To: manet@ietf.org >> Cc: Thomas Clausen >> Subject: [manet] Re: draft-ietf-manet-packetbb-08 >> >> >> With regard to the constraints in packetbb: >> >> - Specifying ordering and non-duplicate TLVs in packetbb >> looks like it adds complexity, but it really reduces >> implementation complexity, as the following points >> indicate. >> >> - It may add complexity to the packet/message generation, >> but very little. Adding no duplication adds no work, it's >> what you should do. Adding ordering just makes you insert >> new TLVs in the right place rather than at the end, you >> don't actually sort. You may even generate them in the >> appropriate order in the first place, in which case there >> is no added complexity. >> >> - Now at the receiver you can tell a malformed TLV block >> (and hence message, and if you choose, packet) at the >> parsing stage, and very easily. >> >> - With a duplicate TLV you don't need to force complex >> decisions as to whether you use the first, or most >> restrictive, or whatever, choice. It is malformed by >> definition and you can allow the implementation to >> do what it considers sensible - and that can be the >> easy decision to discard the packet/message/block. >> And note that this can be at parsing, not processing. > > I think it would be beneficial if the draft provided > guidelines on parsing errors vs processing errors. > Doing so would facilitate interoperability. There > are two sides to the problem, how the originator > handles the error and how the receive handles the > error. A degree of synergy can only help. > > > is an 8 bit field specifying the interpretation of > the remainder of the TLV: > ...cut... > bit 1 (extended) and bit 2 (novalue): MUST NOT both be set ('1'). > ..... > > For example, what if both bits are set? What MUST the code > NOT do? Or WHAT MUST the code do? There are other places > that would benefit from some level of guidance. > > >> - Thus receiver processing can be (and probably should >> be) much simpler. > > This may be case today in your opinion, but may not be the > reality if the protocol evolves. It appears this is a > concern that deserves more discussion. > >> - This is aside from the additional gain in reduced >> searching for TLVs (stop when not found). > > Perhaps this is a parser rule that should be added to the > draft. .... stop and discard the message.... ? > >> - Philosophically, once you get a malformed message, >> do you trust the sender? Do you want to try to make >> the best of it? Do you just want to ignore it? The >> decision is that of the receiver implementor. >> >> For these reasons I am strongly against removing any >> of these contraints. >> >> ******************************************************************** >> 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 >> > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 13 15:51: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 1IKfuZ-0006Xg-Vu; Mon, 13 Aug 2007 15:49:11 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKfuY-0006Xb-En for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 15:49:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKfuY-0006XS-4L for manet@ietf.org; Mon, 13 Aug 2007 15:49:10 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKfuX-00048h-Gq for manet@ietf.org; Mon, 13 Aug 2007 15:49:10 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7DJmt5H007514; Mon, 13 Aug 2007 22:49:03 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 22:48:59 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 14:48:58 -0500 Received: from [172.18.141.131] ([172.18.141.131]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 14:48:57 -0500 Message-ID: <46C0B590.5010808@nokia.com> Date: Mon, 13 Aug 2007 12:48:32 -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] Re: draft-ietf-manet-packetbb-08 References: <46BB9D9F.2060002@nokia.com> <46C08DA4.8030704@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 19:48:57.0642 (UTC) FILETIME=[FCC450A0:01C7DDE2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: manet@ietf.org 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, I am trying to understand your point of view, but ... ext Dearlove, Christopher (UK) wrote: >> I don't think these reasons are responsive to my points >> > > I believe they are responsive in that they argue why > the constraints should be retained. > The body of your message characterized such TLVs as "malformed", and then concluded that malformed packets should not be allowed by the protocol. That is not responsive. > I find your position inconsistent. On the one hand you > argue for saving every last octet Not by any means. I guess you haven't seen me in my "minimal implementation" mode... > (with which I don't > agree, flexibility is important) So far, none of my suggestions would have decreased flexibility. Even my suggestions from before the IETF would not have done this. > but here you are > arguing for a hypothetical future need (more than one > TLV of the same type associated with the same address > - note that more than one TLV of the same type in the > same TLV block is valid) with no use case Do you mean that I didn't submit a protocol specification? That's placing the bar pretty high... I did explain the need, but I can do it again if need be. > and which is > against the TLV philosophy in packetbb, I somehow did not find any point within the specification which elucidated packetbb's TLV "philosophy". Could you be more explicit? Or else maybe it is in some e-mail I didn't read yet... I will look. > despite that > it adds complexity, not reduces it, where it matters. > But I claim and believe that my suggestions reduce complexity. The argument from complexity in the case of allowing overlapping address ranges is a trade-off, but the other suggestions seem to me to clearly enable less complicated protocol operations. For overlapping address ranges, I guess one would have to define multiple TLV types (with the attendant additional packet overhead and specification complexity) in order to "allow" multiple descriptors for some but not all addresses in a range. Or maybe whole new messages -- a real botch since it would require either very complicated bundling arrangements or else whole new packets and medium access operations. > I strongly disagree that you have made a good case for > removal, let alone that the case is clear, and I strongly > oppose removing the constraints. > Well, you have certainly made that clear enough. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 13 16:01:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKg58-0003uI-9V; Mon, 13 Aug 2007 16:00:06 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKg55-0003uD-T8 for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 16:00:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKg55-0003u5-JZ for manet@ietf.org; Mon, 13 Aug 2007 16:00:03 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKg54-0003a0-4Y for manet@ietf.org; Mon, 13 Aug 2007 16:00:03 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7DJxgmD025533; Mon, 13 Aug 2007 22:59:59 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 22:59:56 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 14:59:53 -0500 Received: from [172.18.141.131] ([172.18.141.131]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 14:59:53 -0500 Message-ID: <46C0B836.9010209@nokia.com> Date: Mon, 13 Aug 2007 12:59:50 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Justin Dean Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08 References: <200708131829.l7DIT6ET025839@s2.itd.nrl.navy.mil> In-Reply-To: <200708131829.l7DIT6ET025839@s2.itd.nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 19:59:53.0162 (UTC) FILETIME=[837CBAA0:01C7DDE4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: manet@ietf.org 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 Justin, I have some follow-on comments on the points you raise. ext Justin Dean wrote: > The major advantage I can see is with 1 is being able to read a lack of a > tlv by the ordering without having to read the entire tlv block. If > multiple protocols in an integrated system are only looking for specific tlv > types they can more quickly decide if the information is there or not, i.e. > if I am looking for page 10 and I get to page 11 then its not there no need > to read the next 100 pages. It is not NEEDED, however, protocols based off > of packetbb MUST know if this constraint is true for all packetbb packets or > this advantage is lost. > Actually, I think that any protocol using packetbb should make any such necessary constraints in the individual protocol document. Since other protocols may not have the same requirement, it is not needed to impose the constraints globally for all time. Perhaps, if it is needed to expedite the information lookup as you are suggesting, packetbb could recommend that individual protocol specifications include a relevant section near the front of the document (just after the protocol applicability statement?). > The advantages of 4 are a little bit less clear but the same principle > applies. And if the ordering is not stated here for both 1 and 4 no later > document can later state ordering constraints and have it work for all > packetbb protocols. > But any individual protocol can do so, and that is, I think, all that is needed. > With 3 this was introduced to avoid confusion on which value should be used. > I personally would be ok with wording this closer to 2 in mandating that the > tlv definitions explicitly disallow or allow. I am also O.K. with wording closer to (2). Regards, Charlie P. PS. I should have included the four cases, I guess... so here they are. > 1 TLVs in the same TLV block MUST be sorted in non-descending tlv- > fulltype order. > > 2 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. > > 3 Two or more TLVs with the same tlv-fulltype in the same address block > TLV block MUST NOT be associated with the same copy of an address > (i.e. they must not have overlapping index ranges). > > 4 TLVs with the same tlv-fulltype associated with the same address > block MUST be sorted in ascending index-start order. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 13 18:20:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKiF8-00015v-D7; Mon, 13 Aug 2007 18:18:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKiF7-00015o-AY for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 18:18:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKiF7-00015c-0g for manet@ietf.org; Mon, 13 Aug 2007 18:18:33 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKiF5-0007Ye-CP for manet@ietf.org; Mon, 13 Aug 2007 18:18:32 -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 l7DMIPu1019692; Tue, 14 Aug 2007 01:18:28 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 01:18:25 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 17:18:22 -0500 Received: from [172.18.141.131] ([172.18.141.131]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 17:18:22 -0500 Message-ID: <46C0D8AD.9020000@nokia.com> Date: Mon, 13 Aug 2007 15:18:21 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Justin Dean Subject: Re: [manet] NHDP "Hello" packet too big References: <200708131533.l7DFXrTi017795@s2.itd.nrl.navy.mil> In-Reply-To: <200708131533.l7DFXrTi017795@s2.itd.nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 22:18:22.0090 (UTC) FILETIME=[DBFE86A0:01C7DDF7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 Justin, You are right that the examples do not contain the same information, and I agree with many points of your analysis. A few other comments below... ext Justin Dean wrote: > First the two samples you are including do not include the same information. > Particularly using full message header semantics and the addition of the > hold and validity times. If we are to compare the two packet formats > suggested they should contain the same information and packetbb allows you > to do this. > > By only including the information included in your smurf-like packet > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | HELLO | flags |#Selves|#Heard | #Sym | #Lost | Seq# | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Originator Address(es) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Head | Mid | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Mid | Mid | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Hop count and ttl values in the packetbb message header are not needed and > they can be turned off using the semantics bits. A 2 byte savings. > Validity time and Hold time values are required per NHDP but that's not a > packetbb issue so we can remove those as well. I would suggest that these values not be sent in every Hello message. I'd rather (a) have default values and (b) allow nodes to send the values out only occasionally as desired. I know that there are not any universally valid values for the timers, but that hasn't stopped other protocols from having default values anyway. > The #of any give type of neighbor is limited to a max of 15. Yes. That is O.K., because graphs with more than 15 neighbors are pretty dense graphs. I like dense graphs too, but minimal systems will endeavor to avoid them and we should allow parsimonious operation while still allowing for more general operation as well. We can allow for more neighbors in several easy ways. For instance the same TLV could be entered multiple times. > If there are > more than 15 symmetric neighbors it can't convey that information. A simple > "fix" would be to increase the size to 1 fully octet for each field with a > flag. I don't think that is needed for the common cases, though. > ... Which brings me to my main > point. This packet format is designed to work very well for ONE protocol > not many different possible protocols. I did not mean to say that the message format that I indicated was the final answer -- far from it. In fact, it was just the product of an hour's work, or two, motivated at the IETF as I finally had made time to read NHDP. I think this is important because neighborhood discovery messages can be a major source of congestion, especially if they are broadcast (thus, no RTS/CTS). > Many types of information can not be > included without modification of the smurf-like packet format. Information > such as; including multiple message types in the same packet (possibly from > even differing protocols), including "other" semi standard information such > as ttl, hopcount, conveying node information such as willingness, conveying > address specific information such as a metric, or mpr status. Packetbb can > do all of these things natively without change to the document or packet > layout, while supporting a wide range of possible protocol requirements. > The packet format as presented is equally amenable to extensions as packetbb is. In fact, the quickie "TLV" format could be wrapped up in packetbb, and still maintain almost all of the savings. > > > I would also like to point out how things might grow byte wise in terms of > packetbb as this example is a pretty worst case situation. Each new address > added to the packetbb format, assuming no new neighbor types and similar > headers, would add 2 bytes for each address without changing how the link > status tlvs are being used. At some point (didn't do the math right now) > using 3 different tlvs with indexes would become more efficient than > including 1 byte for each address in the tlv. ... I am pretty sure this isn't right. Unless I am missing your point... I think the difference is that I am assigning counts for the kinds of address information contained in the neighborhood information, and then a list of addresses as indicated by the count fields. There would only have to be one tlv for all of this. Then it is a matter of how to define the contents (and semantics) of the "v" part of the tlv. > After this point each > additional address would only add one byte of overhead. Also oftentimes the > only type of address being included in a hello message after the initial > startup is symmetric which would require a 6 bytes (3 less than the given > example here when using 4 addresses!) to convey for any number of addresses > (if they are all symmetric). > So we could have a flag to control the presence of some of the other fields. This would be fine with me, as you may guess. > The main thing though is the flexibility of the format. The cost in terms > of bytes is in my opinion worth it its not orders or magnitude greater. > I hope you are exaggerating. Surely a 190 byte packet is far less preferable than a 20 byte. On the other hand, some people define "order of magnitude" to be only a factor of three, or else sqrt(10), sigh. But, to the point, I think that going from 38 down to 15 is pretty good and worthwhile. Alternatively, we could have the NHDP format and a "streamlined" format that would be useful for implementations where size matters. > Discussions about a totally different packet format designed around specific > protocol requirements with little flexibility are in my opinion not that > helpful. I think that with some fine tuning I could turn my quickie suggestion into a format that has equal flexibility and functionality as the given NHDP format. What I presented was really for the purpose of jump-starting the discussion. > Suggested changes to improve compactness while maintaining > flexibility is. > Please try to see my current recommendation in exactly that light. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 13 22:55: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 1IKmXI-0003PQ-BJ; Mon, 13 Aug 2007 22:53:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKmXG-0003CO-71 for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 22:53:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKmXF-0003CD-TJ for manet@ietf.org; Mon, 13 Aug 2007 22:53:33 -0400 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKmXF-0001B6-DG for manet@ietf.org; Mon, 13 Aug 2007 22:53:33 -0400 Received: by rv-out-0910.google.com with SMTP id f1so1204314rvb for ; Mon, 13 Aug 2007 19:53:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=LiFaQCg0gLaW8JfI+4UrwrasvdGYORmq2DvmHKsXy/dakPfGSIgrypBolO7P15LkoVy0ndhqI3KdXU+AnUi7WBvG+TdB87pMkYgKsvuVgkhXljzEtx+ETjwWNXSwkFCSwCbrPR/YGBuSuILq+/q2Zan1CrDaH2+KxzlBWQPDI9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=NtOfN0D38UFAdFnuvGvHpdE6ir7p/RgtM3I7QjmGs8IdnC8k9a3Hn5MLhjlx33r/vCRPUGXFS+gExiWLGSOv6FkGaUg33kMXODGqDFVrrFCmdToUSmsHQooIM+htju5SD+c8qdb3YI3NHR7MXHZDdK0P/4wl/CgCZhxXGzEMDXI= Received: by 10.140.141.15 with SMTP id o15mr2843349rvd.1187060012507; Mon, 13 Aug 2007 19:53:32 -0700 (PDT) Received: by 10.141.53.2 with HTTP; Mon, 13 Aug 2007 19:53:32 -0700 (PDT) Message-ID: <13786f330708131953l133ad9d0k5b8c743b544c371e@mail.gmail.com> Date: Mon, 13 Aug 2007 22:53:32 -0400 From: "Joseph Kopena" To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 677f0dbb09e7524a X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [manet] Notes on draft-ietf-manet-smf-05 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 For what it's worth, some comments after a read-through of the current SMF document follow. Thx! ------- Notes on draft-ietf-manet-smf-05 [ Technical Notes ] fragmentation: While I understand reasons for not including fragmentation support, I think it is something that should be considered. It doesn't seem to be difficult or expensive to add, requiring just the inclusion of the fragment offset in the DPD (am I missing something?). Fragmented datagrams probably aren't the best idea, but I have been "given" several applications to run over a MANET that faced problems because of this. It might be nice, if it indeed doesn't cost much, if these programs would at least work in relatively benign settings, which they currently don't. However, my feelings aren't very strong about this. [ Document Notes ] general: The document is pretty clear, although perhaps not as much without some familiarity with MPR (i.e. papers in the literature). Just one line saying what these algorithms are trying to do (i.e. reduce forwarded traffic) might address that. For example, immediately after the sentence "The main goals of the SMF specification... and to adapt efficient reduced relay set designs in MANET environments." in the abstract, it could be noted that "SMF implementations and sites may use a number of such algorithms, each varying in factors such as retransmission traffic volume, processing complexity, control requirements, and delivery reliability." This is be a non-issue if it the document is not aimed toward people without some MANET/broadcast background info. appendix d: It would be nice if there was a 1-line summary or statement of what these algorithms attempt to accomplish, or the intuition behind them. Several of the are not discussed earlier in the draft, and just something quick would be useful. NS-MPR in particular stands out for this. pg 40: This section closes on "Further algorithm examples and details are covered in the Appendices," but we are already in the Appendices and there aren't many more details coming up. Perhaps change to note that pseudo-code is in Appendix D? pg 40: This seemed to be the first place the SMF_HELLO symbol was used. Although it's pretty clear what this is talking about, it is somewhat odd. I assume the text was taken from another source or any earlier version that included more details about the actual NHDP process/messages. [ Typographic Notes ] pg 19: "operate in concert" should be "operating in concert." pg 23: "Appendices.z" should be "Appendices." ------- -- - joe kopena right here and now _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 13 23:39: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 1IKnE9-0001b7-Hl; Mon, 13 Aug 2007 23:37:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKnE8-0001aw-3V for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 23:37:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKnE7-0001ak-Pr for manet@ietf.org; Mon, 13 Aug 2007 23:37:51 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKnE6-0002GX-UL for manet@ietf.org; Mon, 13 Aug 2007 23:37:51 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.109]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IKnE6-0003dW-1U; Mon, 13 Aug 2007 23:37:50 -0400 X-MHO-User: U2FsdGVkX1+iiXmmfypr42a1ljO3w2iz X-MHO-User: U2FsdGVkX1/l9sfXFmnvG4cMPGTgWAxc X-MHO-User: U2FsdGVkX1/FTgDVjqQhODHQtZQuvT1J X-MHO-User: U2FsdGVkX18O0zgxZdq+8DDj/38PzCKM X-MHO-User: U2FsdGVkX1+jabuiGvnDFtyUOBOM6v3F X-MHO-User: U2FsdGVkX1+SSo3I0fNNDSPGf6f335xT X-MHO-User: U2FsdGVkX1/Hcv7ave6Te5zKt0LcTvgx X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18Rwa6pG7SnPzRe0TJSy3p8 In-Reply-To: <46C0B836.9010209@nokia.com> References: <200708131829.l7DIT6ET025839@s2.itd.nrl.navy.mil> <46C0B836.9010209@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83F747AA-3CFE-4F82-9E45-E6713B16CFCE@polytechnique.fr> Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08 Date: Tue, 14 Aug 2007 05:37:44 +0200 To: "Charles E. Perkins" , "Stan Ratliff ((sratliff))" , Bo Berry X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: Christopher Dearlove , manet 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 Charlie, Bo, Stan, Justin, all. I'm an insomniac today (it's 5AM here), so I'll toss in a few thoughts. In general, I agree 100% with Justin's analysis of the situation and his presentation of why the constraints are as they are accurately reflect the reasoning behind the document. The same with the email of Chris where he presents his thoughts on how the constraints serve to reduce complexity. I shall not repeat Justins' and Chris' excellent emails here, but rather add a few thoughts: - Since packetbb is intended to carry, in one packet, a set of messages, and since these messages may be for different protocol instances (and, even, different protocols), then some level of coordination is required in packetbb for this. At least, packet-tlv's would have to either have or not have the constraints, and these constraints would have to be specified somewhere, that an implementation can correctly deal with incoming packets. packetbb seems the logical place. - Having a set of constraints for packet-tlv's and then different constraints for message TLVs and address-block TLVs (and, possibly, different constraints for TLV blocks in different message types) is messy: it'd break the ability to have one piece of code constructing (or parsing) all TLV blocks identically and sanity- checking of all things packetbb. That is: it'd dramatically increase the code footprint required to make a packetbb parser/generator, and any such would no longer be generic. I should add that going from RFC3626 (which doesn't use packetbb) to OLSRv2 (which uses packetbb) not only resulted in a dramatic net reduction of the control message size but also roughly cut the size of the packet/message parsing/generating code by 2/3. Since the packetbb structure is intended exactly for making general components, I can (and, indeed, have) reuse the same code for other protocols or for protocol extensions. So I second also Chris' comment that having these constraints reduces the complexity, but in a different way than what he indicates: it allows me to write code that consistency checks packets/messages once, rather than having to do so for each protocol/extension I think up. Obviously, I agree with Chris' issues on how it reduces complexity in the receiving end without adding to the complexity of the sending end - One of the requirements (and now I am repeating Justin's argument) for packetbb that has been brought forward at least as early as the Paris IETF (when these constraints were introduced and formalized) was to be able to terminate processing of a TLV block early -- i.e. as Justin say, if you're looking for page 10 and you get to page 11, then you can stop without reading the next 100 pages if you know that the pages appear in order. We had intense discussions on this in Paris and Vancouver, and I was convinced that there was/is rough consensus behind this. I shall not be speaking on behalf of the participants in these discussions (which, btw., were open to anyone caring to join them), but very clear requirements from real deployments and real customers and manufacturers were presented for this, and were throughly discussed at that point already. While the discussion as to if we can or cannot or should or should not do something based on some hypothetical future is interesting, I am more concerned with the fact that we are operating within a design- space where we've got companies providing real stuff to real customers having real requirements, presenting these requirements and participating in the specification that has now become packetbb. I think that our goal is to satisfy that concrete and real design-space. In conclusion, I'm strongly in favor of retaining the constraints as they are, since I've seen a strong case for them and I have seen no solid case for removing them. Thomas On Aug 13, 2007, at 9:59 PM, Charles E. Perkins wrote: > > Hello Justin, > > I have some follow-on comments on the points you raise. > > ext Justin Dean wrote: >> The major advantage I can see is with 1 is being able to read a >> lack of a >> tlv by the ordering without having to read the entire tlv block. If >> multiple protocols in an integrated system are only looking for >> specific tlv >> types they can more quickly decide if the information is there or >> not, i.e. >> if I am looking for page 10 and I get to page 11 then its not >> there no need >> to read the next 100 pages. It is not NEEDED, however, protocols >> based off >> of packetbb MUST know if this constraint is true for all packetbb >> packets or >> this advantage is lost. >> > Actually, I think that any protocol using packetbb should make any > such > necessary constraints in the individual protocol document. Since > other > protocols may not have the same requirement, it is not needed to > impose > the constraints globally for all time. Perhaps, if it is needed to > expedite the > information lookup as you are suggesting, packetbb could recommend > that > individual protocol specifications include a relevant section near > the front > of the document (just after the protocol applicability statement?). >> The advantages of 4 are a little bit less clear but the same >> principle >> applies. And if the ordering is not stated here for both 1 and 4 >> no later >> document can later state ordering constraints and have it work for >> all >> packetbb protocols. >> > But any individual protocol can do so, and that is, I think, all > that is needed. >> With 3 this was introduced to avoid confusion on which value >> should be used. >> I personally would be ok with wording this closer to 2 in >> mandating that the >> tlv definitions explicitly disallow or allow. > I am also O.K. with wording closer to (2). > > Regards, > Charlie P. > > PS. I should have included the four cases, I guess... so here they > are. >> 1 TLVs in the same TLV block MUST be sorted in non-descending tlv- >> fulltype order. >> >> 2 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. >> >> 3 Two or more TLVs with the same tlv-fulltype in the same address >> block >> TLV block MUST NOT be associated with the same copy of an address >> (i.e. they must not have overlapping index ranges). >> >> 4 TLVs with the same tlv-fulltype associated with the same address >> block MUST be sorted in ascending index-start order. > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > -- 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 Aug 13 23:51: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 1IKnPK-0001Yu-9L; Mon, 13 Aug 2007 23:49:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKnPI-0001Yo-4y for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 23:49:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKnPH-0001Yg-Rb for manet@ietf.org; Mon, 13 Aug 2007 23:49:23 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKnPH-0002XO-FE for manet@ietf.org; Mon, 13 Aug 2007 23:49:23 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.109]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IKnPG-0005qo-Mc; Mon, 13 Aug 2007 23:49:23 -0400 X-MHO-User: U2FsdGVkX1/wbjrvkjoJ3VNTebMPz1XK X-MHO-User: U2FsdGVkX19v45DLLNKhgrqHw7Xi5KpD X-MHO-User: U2FsdGVkX19EeacnNenwBDMYlgXYwYqy X-MHO-User: U2FsdGVkX18obLn7mdDCG4IkLToKFP1l X-MHO-User: U2FsdGVkX19ZBy4ufmE95PSwRnikz8iV X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/CQrjfG5wWzsdbL0SeI6Qz In-Reply-To: <46C0AA02.4050803@cisco.com> References: <7FB7EE0A621BA44B8B69E5F0A09DC76404558512@xmb-rtp-208.amer.cisco.com> <46C06BB1.2090000@cisco.com> <46C0AA02.4050803@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47EDBE10-A789-407D-9AB6-9A15AB415287@computer.org> Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08 Date: Tue, 14 Aug 2007 05:49:18 +0200 To: Bo Berry X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, "Stan Ratliff \(sratliff\)" 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 Bo, Comments below. On Aug 13, 2007, at 8:59 PM, Bo Berry wrote: > > in-line > > Dearlove, Christopher (UK) wrote: >> Yes, you've not seen the code. But my point is that I >> have what I believe is a solid argument why ordering >> adds trivially to the complexity at the transmitter, >> and reduces complexity at the receiver. The point of >> mentioning the code is that my argument is backed by >> experience doing it, it's not just academic. In addition >> this was introduced based on a suggestion from one of the >> contributors other than the authors, who are more driven >> than I am by complexity considerations. I'm hoping he, or >> a colleague, will join in this discussion. > > But several of us have and are speaking up from > our experience and perspectives in designing & developing > TLV based protocols, routing, metrics. > > I think what's required is an open mind to consider the > feedback and experience of others. All due respect, but I think that if anything then packetbb and related protocols have been developed with "an open mind" -- at least, the specification has evolved substantially from what was originally presented in Paris ('05) due to the feedback received since then and until the WGLC was issued. Also, I think that keeping an open mind when reading and evaluating the packetbb specification would be helpful: the requirements and constraints are there for a reason, as I think the emails from Chris and Justin both have explained. > Perhaps the WG Chairs > can help moderate. I think that Joe/Ian have done so well in the past, and are doing so well at the present. See the quote below: > This note starts the WG Last Call for comments on > draft-ietf-manet-packetbb-07.txt, "Generalized MANET Packet/Message > Format". > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-07.txt > > The document is intended to be submitted for publication as an > proposed standard document. > > Please review the document carefully and send your comments to the > MANET list and document authors. > > This last call will end Friday July 20th. > Thanks, > Ian Chakeres Thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 14 00:57:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKoRn-0008Hw-EF; Tue, 14 Aug 2007 00:56:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKoRl-0008Hp-E5 for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 00:56:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKoRl-0008Hh-4S for manet@ietf.org; Tue, 14 Aug 2007 00:56:01 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKoRk-0004IA-2U for manet@ietf.org; Tue, 14 Aug 2007 00:56:01 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.109]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IKoRh-000Lkp-ML; Tue, 14 Aug 2007 00:55:59 -0400 X-MHO-User: U2FsdGVkX1+f3/NV1GsF8X/0s24QGxKT X-MHO-User: U2FsdGVkX18gxLihgxaAYrelfCWVL+7F X-MHO-User: U2FsdGVkX195a1kYR+fJniE0iwvWD/r2 X-MHO-User: U2FsdGVkX1/ppuApqaZ7mW55Z8Um+fvL X-MHO-User: U2FsdGVkX1+GxyB83SSfGdhxkgCTbpL/ X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+1+BdQoXmIxW7ueFIk6oIG In-Reply-To: <46C0D8AD.9020000@nokia.com> References: <200708131533.l7DFXrTi017795@s2.itd.nrl.navy.mil> <46C0D8AD.9020000@nokia.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] NHDP "Hello" packet too big Date: Tue, 14 Aug 2007 06:55:54 +0200 To: Charles E. Perkins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: Christopher Dearlove , 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 Charlie, Please see comments embedded below. On Aug 14, 2007, at 12:18 AM, Charles E. Perkins wrote: > > Hello Justin, > > You are right that the examples do not contain the same information, > and I agree with many points of your analysis. A few other comments > below... > > ext Justin Dean wrote: >> First the two samples you are including do not include the same >> information. >> Particularly using full message header semantics and the addition >> of the >> hold and validity times. If we are to compare the two packet formats >> suggested they should contain the same information and packetbb >> allows you >> to do this. >> >> By only including the information included in your smurf-like >> packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | HELLO | flags |#Selves|#Heard | #Sym | #Lost | Seq# | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Originator Address(es) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Head | Mid | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Mid | Mid | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Hop count and ttl values in the packetbb message header are not >> needed and >> they can be turned off using the semantics bits. A 2 byte savings. >> Validity time and Hold time values are required per NHDP but >> that's not a >> packetbb issue so we can remove those as well. > I would suggest that these values not be sent in every Hello message. > I'd rather (a) have default values and (b) allow nodes to send the > values > out only occasionally as desired. I know that there are not any > universally valid values for the timers, but that hasn't stopped other > protocols from having default values anyway. So just to understand what you are suggesting, you want to specify "absent a VALIDITY_TIME TLV, the validity time for information contained in a HELLO message is XX seconds" -- same for Interval time? >> The #of any give type of neighbor is limited to a max of 15. > Yes. That is O.K., because graphs with more than 15 neighbors are > pretty dense > graphs. I like dense graphs too, but minimal systems will endeavor > to avoid them > and we should allow parsimonious operation while still allowing for > more general > operation as well. We can allow for more neighbors in several easy > ways. For > instance the same TLV could be entered multiple times. Sorry, you lost me. What TLV are you talking about that you want to include multiple times? Assuming that you do not mean "TLV" but "block of bits in your previous ascii-diagram", then I'll then say that in case where you have more than 15 addresses in your message, your suggested scheme is not optimal in that (i) it doesn't allow for optimal aggregation and (ii) a lot of information is repeated. I point out that intelligent use of packetbb will allow you to not repeat information and attain optimal aggregation. In Packetbb, TLVs are associated to addresses and express information about addresses, they do not contain addresses. The above ascii-art that your original message contained does not suggest any TLVs present. Maybe I am missing something fundamental from what you're suggesting, but I do not see the benefit of it. >> If there are >> more than 15 symmetric neighbors it can't convey that >> information. A simple >> "fix" would be to increase the size to 1 fully octet for each >> field with a >> flag. > I don't think that is needed for the common cases, though. Nonetheless, Charlie, I *have* situations where I need to report >15 addresses, and I *want* to be able to do so without having to resort to hacks and patches. Why? Because hacks and patches increase the code complexity and code footprint and parsing complexity. Not to mention the requirements to verify many different parsing and encoding algorithms -- something which I know that at least some people are VERY concerned about, especially in embedded devices. (I'm concerned too...although for me, it's simply because it's easier to write correctly and test one general block of code than it is to write a dozen or so different ones for a given protocol. In a different email I stated how the use of packetbb substantially reduced the code footprint of OLSRv2 vs OLSR) Notice that NHDP messages are based on packetbb, and that packetbb is designed for a much larger scope than just nhdp. For example. OLSRv2 and DYMO. In at least OLSRv2, I know of common scenarios where I want to transmit >15 addresses in a message. And, I want to be able to do so without having to have to write a special parser/parsing logic, but rather use the same as in NHDP....and DYMO...or otherwise said, as specified in packetbb. I know that you consider saving a bit here and there as more important than being able to reduce the code footprint and/or processing complexity, but as we discussed in Chicago, there're conflicting requirements and I feel that packetbb (and, thus, NHDP) represents a decent compromise. >> ... Which brings me to my main >> point. This packet format is designed to work very well for ONE >> protocol >> not many different possible protocols. > I did not mean to say that the message format that I indicated was > the final answer -- far from it. In fact, it was just the product > of an > hour's work, or two, motivated at the IETF as I finally had made > time to read NHDP. I think this is important because neighborhood > discovery messages can be a major source of congestion, especially > if they are broadcast (thus, no RTS/CTS). And, as I also pointed out in Chicago, FLOODING is the major source of congestion in MANETs, and in comparison to FLOODING, any overhead by a HELLO protocol is noise. Thus, the prime task is to reduce the overhead of conducting a flooding operation. I believe that SMF and even your own efforts in SMURF indicate that you share this opinion? Second task is to reduce the number of flooding operations required by a protocol. Doing those two is, in my experience, the overwhelmingly largest and most important part of MANET protocol design. Reducing the size of a given message by a few tens of octets or an order of magnitude isn't really buying much, if anything at all. Experience shows that the MAC overhead and the MAC contention [with most/all MACs I know] is the bigger cost than the payload of a transmission, and so that actually when making a transmission, stuffing s much useful information into that transmission is beneficial. Hence, the multi-message packet format of packetbb. Here's an example of a real test I ran: running OLSR with "minimal" link state information in the TC messages vs. with "full" link state information in the TC messages (the avg. TC message size difference was 1:2.4) doesn't make a significant dent in the performance of a 50 node network in the real world. This was over basic 802.11 cards, btw. It does make a difference in a simulation or analysis, when you're counting octets of overhead. It doesn't make a difference in the real world when you're concerned with getting data traffic from a to b, it doesn't in this test. These statements are, btw., based on experience from actually building and running MANETs (and are backed up by analysis and simulation, but that's an aside, what's interesting is how things actually run). > I think that with some fine tuning I could turn my quickie > suggestion into a format that has equal flexibility and functionality > as the given NHDP format. What I presented was really for the > purpose of jump-starting the discussion. >> Suggested changes to improve compactness while maintaining >> flexibility is. >> > Please try to see my current recommendation in exactly that light. > Charlie, I appreciate your effort but I am not able to see your recommendation in that light....because.......it's not. As you'll note, numerous suggestions and comments have been taken on board and have made their way into packetbb: modular message headers (that was suggested by yourself), head:mid:tail rather than head:tail (that was initiated by Simone, I think, refined by Chris), optional packet headers and packet TLV (you + Satoh-san), to name a few. These all added some savings on the expense of slightly more complex parsing code -- without impeding on the format flexibility and within the general format/paradigm being discussed. Just to recapitulate (a 3-second run-down), the general format/ paradigm is: message header scopes distribution. addresses are expressed in aggregated address blocks. Attributes of addresses are expressed as TLVs associated to identified addresses. The suggestions above -- which are welcome and which we are grateful to you and others for having made -- helped improve and refine packetbb to its current form What you're proposing now is not a "suggestion to improve compactness while maintaining flexibility" (to cite Justin), but is to scrap essentially all of packetbb, which has been developed carefully over >2 years by the MANET wg (including you, as indicated above and in previous emails), implemented by numerous independent parties, fine- tuned over those two years to allow for address aggregation in an efficient way, flexibility in an efficient way, reasonably straight- forward AND general parsing logic, verified to satisfy the requirements of multiple parties and WGLCed ..... in favor of a yet- to-be-specified-and-fine-tuned, not implemented, not evaluated format which has as-yet undetermined features and flexibility. That, to me, is an easy choice to make. I second 100% what Justin said in his email: > Discussions about a totally different packet format designed around > specific > protocol requirements with little flexibility are in my opinion not > that > helpful. Cheers, Thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 14 04:39:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKruL-0007QJ-VZ; Tue, 14 Aug 2007 04:37:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKruK-0007QC-To for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 04:37:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKruK-0007Q4-Iy for manet@ietf.org; Tue, 14 Aug 2007 04:37:44 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKruK-0002bo-2z for manet@ietf.org; Tue, 14 Aug 2007 04:37: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 l7E8bgVY010519 for ; Tue, 14 Aug 2007 09:37:42 +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 l7E8bgBI014226 for ; Tue, 14 Aug 2007 09:37:42 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 14 Aug 2007 09:37:41 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 09:37:41 +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: draft-ietf-manet-packetbb-08 Date: Tue, 14 Aug 2007 09:37:40 +0100 Message-ID: In-Reply-To: <46C0AA02.4050803@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: draft-ietf-manet-packetbb-08 thread-index: Acfd3BIh6bNrj4xFR+Ccj4NhSAE0ngAcbiyA References: <7FB7EE0A621BA44B8B69E5F0A09DC76404558512@xmb-rtp-208.amer.cisco.com> <46C06BB1.2090000@cisco.com> <46C0AA02.4050803@cisco.com> From: "Dearlove, Christopher \(UK\)" To: "Bo Berry" X-OriginalArrivalTime: 14 Aug 2007 08:37:41.0470 (UTC) FILETIME=[60B5EFE0:01C7DE4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: manet@ietf.org, "Thomas Heide Clausen \(work\)" , "Stan Ratliff \(sratliff\)" 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 has said most of what I would say, but I would just like to stress > I think what's required is an open mind to consider the > feedback and experience of others. And that is exactly what these constraints are. I didn't invent them, nor did Thomas. They came precisely out of other people's experience. ******************************************************************** 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 Aug 14 06:13: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 1IKtNf-0004YM-IX; Tue, 14 Aug 2007 06:12:07 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKtNd-0004Q4-Hx for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 06:12:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKtNd-0004Pv-8H for manet@ietf.org; Tue, 14 Aug 2007 06:12:05 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKtNb-0002h1-NK for manet@ietf.org; Tue, 14 Aug 2007 06:12:05 -0400 Received: (qmail 29030 invoked from network); 14 Aug 2007 12:12:02 +0200 Received: from unknown (HELO Teco) (217.169.232.206) by server9.hosting2go.nl with SMTP; 14 Aug 2007 12:12:01 +0200 From: "Teco_Boot" To: , , "'Thomas Clausen'" , Date: Tue, 14 Aug 2007 12:11:54 +0200 Message-ID: <000c01c7de5b$9e198010$b800800a@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfeW4nCBsZ3N+OLRdWzAchSY7qFQA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: manet@ietf.org Subject: [manet] Comments on Metric TLV 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, I studied the proposals for a metric TLV representation. Here some comments: 1) I don't like fractional values. Elimination circumvents rounding or truncating. So I prefer (16 + a) * 2^b over (1 + a/16) * 2^b. It also extents the number of distinct values, from 207 to 256. 2) I prefer enlarging the range between lowest and highest value. A simple method is to subtract 15: (16 + a) * 2^b - 15. Lowest value is 1, followed by 2, 3, ... 950.272, 983.040, 1.015.808. Linear from 1 to 17, hereafter the exponential characteristic starts. I my day-to-day work I deal with extremely low-speed radio links and high-speed wired links; think of a data radio with shared 1kbps over the radio interface and 1Gbps over the cable interface. Others could come up with more extreme ends of the spectrum. I evaluated using (16 + a) * 2^(b+4) - 255. Values are 1, 17, 33, 49, ... 15.204.097, 15.728.385, 16.252.673. Although the range is enlarged with factor 16, I think it doesn't bring that much value. 3) I see no reason for having a compact linear metric representation. I suggest using an uncompressed 24-bit link metric. And use a 32-bit path metric in all cases. The 24-bit link metric could be assigned a TLV type or subtype. This enlarges the metric range to 1 - 16.777.216 without loss of resolution. Using this TLV can be made fully compatible with the compressed exponential metric; both may be used in the same MANET region. Linear metric representations could be needed by distance vector mechanisms, as path metric is computed hop by hop and loosing resolution could introduce bad behavior. See comment#8 related to DYMO below. 4) I prefer defining a Do_Not_Use metric value, to be specified as the binary all_ones value: 255 for the single octet exponential TLV, 16.777.216 for a 24-bit linear TLV. Advertising such a value is useful for some scenarios, e.g. graceful shutdown of interface or router. 5) I do not see a reason for having a node metric (dean-manet-metriclv). A node is free to add whatever offset on metrics for its links. The result of the SPF path selection is equivalent. 6) I like the idea having metrics for a link generated by both the transmitter and the receiver on a link. This result in three cases for path metric calculation: - no link metric - one metric only, generated by transmitter (outbound) or receiver (inbound) - two metrics, generated by both transmitter and receiver First case: use a default metric; second case: use the metric that is available and the third case: use the average, that is add the metrics and divide by two, truncate to get an integer. Metrics shall be direction sensitive. A link A <--> B may have four metrics, A inbound, A outbound, B inbound and B outbound. Metrics for opposite directions may not be used for path metric calculation, e.g. default metric is to be used for A -> B when only A inbound and B outbound metrics are available. Effects caused by unsynchronized path computations are to be verified. 7) When using a factor 16 as proposed above, the suggested default value 4096 (dearlove-olsrv2-metrics) is fairly low. A value 6.5536 is to be used. Note that in my "-15" suggestion, this default value cannot be stored in a compressed exponential value. If default-value explicit signaling is preferred, a default value of 65.521 is to be used. 8) In DYMO, a path metric is used, it is called distance. Behavior is similar to distance vector. The distance field is one octet. Intermediate routers increment distance, minimum increment is 1. Adding a higher cost value is fully acceptable. Personally, I prefer a uniform link metric / uniform path metric in MANET and even to be used in other IETF protocols. - Enlarge the distance to 32-bit field? - Accept some kind of mixed mode? For the latter, the required incremented-by-1 update could get lost by the compress mechanism. This is circumvented by incrementing the compressed metric, by 1 or by setting to outbound link metric when link metric value is higher than the to-be-forwarded distance. In short: we could use two distance formats, a short 8-bit path metric and a large 32-bit path metric. Conversion is allowed, but special attention is required for incrementing the distance hop-by-hop. 9) In PacketBB, hop based fields are used: MsgHdr.HopLimit - noHopLimit bit MsgHdr.HopCount - noHopCount bit We could discuss allowing high decrements (HopLimit) and high increments (HopCount) during forwarding the messages. Rules for decrementing and incrementing are to be determined. DYMO uses HopLimit. During analysis I used the following formulas: Lin_Metric = (16+MOD(Exp_Metric;16))*2^INT(Exp_Metric/16) - 15 Exp_Metric = 16*FLOOR(LOG((Lin_Metric+15)/16;2);1) + INT(16*(((Lin_Metric+15)/16)/2^FLOOR(LOG((Lin_Metric+15)/16;2);1)-1)) Teco _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 14 06:41:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKtnq-00034Y-3W; Tue, 14 Aug 2007 06:39:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKtno-00034J-Bf for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 06:39:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKtno-00033C-1B for manet@ietf.org; Tue, 14 Aug 2007 06:39:08 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKtnm-0003FJ-Ek for manet@ietf.org; Tue, 14 Aug 2007 06:39:08 -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 l7EAd2ga026565 for ; Tue, 14 Aug 2007 11:39:02 +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 l7EAd2fL028287 for ; Tue, 14 Aug 2007 11:39:02 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 14 Aug 2007 11:39:01 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 11:39:01 +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: Tue, 14 Aug 2007 11:39:00 +0100 Message-ID: In-Reply-To: <000c01c7de5b$9e198010$b800800a@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Metric TLV thread-index: AcfeW4nCBsZ3N+OLRdWzAchSY7qFQAAAQLGg References: <000c01c7de5b$9e198010$b800800a@Teco> From: "Dearlove, Christopher \(UK\)" To: "Teco_Boot" , , "Thomas Clausen" , X-OriginalArrivalTime: 14 Aug 2007 10:39:01.0142 (UTC) FILETIME=[53BBBB60:01C7DE5F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: manet@ietf.org Subject: [manet] RE: Comments on Metric TLV 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=20 -----Original Message----- From: Teco_Boot [mailto:teco@inf-net.nl]=20 Sent: 14 August 2007 11:12 To: jdean@itd.nrl.navy.mil; Dearlove, Christopher (UK); 'Thomas Clausen'; Philippe.Jacquet@inria.fr Cc: manet@ietf.org Subject: Comments on Metric TLV *** 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 Hi, I studied the proposals for a metric TLV representation. Here some comments: 1) I don't like fractional values. Elimination circumvents rounding or truncating. So I prefer (16 + a) * 2^b over (1 + a/16) * 2^b. It also extents the number of distinct values, from 207 to 256. >>> Having less tham 256 values is only because you've chosen to >>> use the fractional representation but prohibit fractions. >>> That I don't think is sensible, so it's 256 either way. The >>> scaling is also actually irrelevant, it's just an implementation >>> detail that has no actual consequences (you send the same octets, >>> and get the same results). 2) I prefer enlarging the range between lowest and highest value. A simple method is to subtract 15: (16 + a) * 2^b - 15. >>> Interesting, but it messes up later values as the 15 is only >>> right in the first octave. So I don't like this at all. Lowest value is 1, followed by 2, 3, ... 950.272, 983.040, 1.015.808. Linear from 1 to 17, hereafter the exponential characteristic starts. I my day-to-day work I deal with extremely low-speed radio links and high-speed wired links; think of a data radio with shared 1kbps over the radio interface and 1Gbps over the cable interface. Others could come up with more extreme ends of the spectrum. I evaluated using (16 + a) * 2^(b+4) - 255. Values are 1, 17, 33, 49, ... 15.204.097, 15.728.385, 16.252.673. Although the range is enlarged with factor 16, I think it doesn't bring that much value. 3) I see no reason for having a compact linear metric representation.=20 >>> I agree with you here. Note that it's not in the proposal I >>> presented. I suggest using an uncompressed 24-bit link metric. >>> But not here. I think there's no need for anything but the 4/4 >>> bit value. And use a 32-bit path metric in all cases. The 24-bit link metric could be assigned a TLV type or subtype. This enlarges the metric range to 1 - 16.777.216 without loss of resolution. Using this TLV can be made fully compatible with the compressed exponential metric; both may be used in the same MANET region. Linear metric representations could be needed by distance vector mechanisms, as path metric is computed hop by hop and loosing resolution could introduce bad behavior. See comment#8 related to DYMO below. 4) I prefer defining a Do_Not_Use metric value, to be specified as the binary all_ones value: 255 for the single octet exponential TLV, 16.777.216 for a 24-bit linear TLV. Advertising such a value is useful for some scenarios, e.g. graceful shutdown of interface or router. >>> We don't need this in OLSRv2 - we have the concept of a LOST link. 5) I do not see a reason for having a node metric (dean-manet-metriclv). A node is free to add whatever offset on metrics for its links. The result of the SPF path selection is equivalent. >>> Also agreed. 6) I like the idea having metrics for a link generated by both the transmitter and the receiver on a link. This result in three cases for path metric calculation:=20 - no link metric - one metric only, generated by transmitter (outbound) or receiver (inbound) - two metrics, generated by both transmitter and receiver First case: use a default metric; second case: use the metric that is available and the third case: use the average, that is add the metrics and divide by two, truncate to get an integer. >>> I don't like this case, it defeats the whole motivation of >>> bidirectional metrics - that there is no ambiguity. With >>> lossy messages there is ambiguity using two node's values >>> (in an average or whatever). Metrics shall be direction sensitive. A link A <--> B may have four metrics, A inbound, A outbound, B inbound and B outbound. >>> I don't see the point of this. Metrics for opposite directions may not be used for path metric calculation, e.g. default metric is to be used for A -> B when only A inbound and B outbound metrics are available. Effects caused by unsynchronized path computations are to be verified. 7) When using a factor 16 as proposed above, the suggested default value 4096 (dearlove-olsrv2-metrics) is fairly low. A value 6.5536 is to be used. Note that in my "-15" suggestion, this default value cannot be stored in a compressed exponential value. If default-value explicit signaling is preferred, a default value of 65.521 is to be used. >>> OK, took me a second to realise . is what I'd write as comma, except >>> I wouldn't. But I don't agree with the revision, 4096 is in the centre >>> of the range logarithmically, and I think that is right. (I also think >>> this is another argument against -15.) 8) In DYMO, a path metric is used, it is called distance. Behavior is similar to distance vector. The distance field is one octet. Intermediate routers increment distance, minimum increment is 1. Adding a higher cost value is fully acceptable. Personally, I prefer a uniform link metric / uniform path metric in MANET and even to be used in other IETF protocols.=20 - Enlarge the distance to 32-bit field?=20 >>> While I've been on the other end of efficiency arguments, I really >>> don't want to use more than one octet for a metric, and certainly >>> not four. I want to just use a single, exponent/mantissa, octet. >>> (Note that I'm not committed to the 4/4 bit split - in fact in the >>> motivating timetlv we're about to change to 5/3. I think 4/4 is >>> better here, but an argument for 5/3 or 3/5 could be made I'm sure.) >>> Of course I'm not considering DYMO directly. - Accept some kind of mixed mode?=20 For the latter, the required incremented-by-1 update could get lost by the compress mechanism. This is circumvented by incrementing the compressed metric, by 1 or by setting to outbound link metric when link metric value is higher than the to-be-forwarded distance.=20 In short: we could use two distance formats, a short 8-bit path metric and a large 32-bit path metric. Conversion is allowed, but special attention is required for incrementing the distance hop-by-hop.=20 9) In PacketBB, hop based fields are used: MsgHdr.HopLimit - noHopLimit bit MsgHdr.HopCount - noHopCount bit We could discuss allowing high decrements (HopLimit) and high increments (HopCount) during forwarding the messages. Rules for decrementing and incrementing are to be determined. DYMO uses HopLimit. >>> I think these are definitely intended to be hops, not metrics, >>> and definitely should remain so. During analysis I used the following formulas: Lin_Metric =3D (16+MOD(Exp_Metric;16))*2^INT(Exp_Metric/16) - 15 Exp_Metric =3D 16*FLOOR(LOG((Lin_Metric+15)/16;2);1) +=20 =20 INT(16*(((Lin_Metric+15)/16)/2^FLOOR(LOG((Lin_Metric+15)/16;2);1)-1)) Teco ******************************************************************** 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 Aug 14 08:06: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 1IKv8u-0007HU-Uk; Tue, 14 Aug 2007 08:05:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKqEn-000283-1h for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 02:50:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKqEm-00027v-OW for manet@ietf.org; Tue, 14 Aug 2007 02:50:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKqDk-0000ac-AN for manet@ietf.org; Tue, 14 Aug 2007 02:49:40 -0400 Received: from rv-out-0910.google.com ([209.85.198.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKqDj-0006MC-Rd for manet@ietf.org; Tue, 14 Aug 2007 02:49:40 -0400 Received: by rv-out-0910.google.com with SMTP id f1so1238982rvb for ; Mon, 13 Aug 2007 23:49:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=O1jpvNUjH8t2ruNNMhteO+lNrfp4GMiS/5XHJ4vS9rd/fhm2p4sOO1+qn59jHQyaYxJN/7oIBL+1cZJT/oJhNJjKmeBxH0GxGwaf1wTgdw2JrEsGadqNYnacQkod7uOROgJ91hfuGrqmVaTDFDso16ad+pm5RxewA91B64VujFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=fm4zr73WGeQJvinPD+e5QSdvgsFjgWyiYHKFC4v0K3DC1TjOFOXtqW9pr47hq+IofvNTHixPgzWqIYdXbmdqjNQLKiykOtGQDCHamKTu1sYTP/xfHI/urK3Tx+9qVglOpU9OaBLTUrA9kpvPq8wjBC2JZKT2Xii48qdmkNThuRs= Received: by 10.142.103.6 with SMTP id a6mr720402wfc.1187074179062; Mon, 13 Aug 2007 23:49:39 -0700 (PDT) Received: by 10.142.115.16 with HTTP; Mon, 13 Aug 2007 23:49:39 -0700 (PDT) Message-ID: <1550ad2c0708132349i3a9dd0dbu5ce281759cc9ac1b@mail.gmail.com> Date: Tue, 14 Aug 2007 03:49:39 -0300 From: "Lucas Guardalben" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-TMDA-Confirmed: Tue, 14 Aug 2007 02:50:44 -0400 X-Mailman-Approved-At: Tue, 14 Aug 2007 08:04:59 -0400 Subject: [manet] MMRP - Ad-Hoc protocol simulation code 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="===============0568458970==" Errors-To: manet-bounces@ietf.org --===============0568458970== Content-Type: multipart/alternative; boundary="----=_Part_57447_26655991.1187074179039" ------=_Part_57447_26655991.1187074179039 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Friends, I needed the implementation code of the MMRP to evaluate on set of routing protocols. And only lacks the MMRP, to concluded my research. Somebody know where i can find the implementation code in any simulator? Please help me. Thanks, by advice. Lucas ------=_Part_57447_26655991.1187074179039 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear Friends,
 
I needed the implementation code of the MMRP to evaluate on set of routing protocols. And only lacks the MMRP, to concluded my research. Somebody know where i can find the implementation code in any simulator?
 
Please help me.
 
Thanks, by advice.
 
Lucas
------=_Part_57447_26655991.1187074179039-- --===============0568458970== 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 --===============0568458970==-- From manet-bounces@ietf.org Tue Aug 14 08:07:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKv9I-0007h6-GT; Tue, 14 Aug 2007 08:05:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKZqm-0004b1-LH for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 09:20:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKZqm-0004at-BI; Mon, 13 Aug 2007 09:20:52 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKZql-0004ie-5N; Mon, 13 Aug 2007 09:20:52 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BCACA86AFF; Mon, 13 Aug 2007 09:20:50 -0400 (EDT) To: ietf@ietf.org, manet@ietf.org Subject: RE: [manet] Last Call: draft-ietf-manet-iana (Internet AssignedNumbers Authority (IANA) Allocations for the Mobile Ad hocNetworks (MANET) Working Group) to Proposed Standard Message-Id: <20070813132050.BCACA86AFF@mercury.lcs.mit.edu> Date: Mon, 13 Aug 2007 09:20:50 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Tue, 14 Aug 2007 08:05:22 -0400 Cc: jnc@mercury.lcs.mit.edu 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 > From: "Teco Boot" Without taking any position on whether the protocol should be run over IP directly, or over UDP: > UDP overhead is 8 octets, brings checksum Your wording is a little unclear, so perhaps this comment is not needed, but UDP does have a way of sending packets without a checksum, so you don't necessarily have the computational overhead of computing/checking it (although of course the field is always there - 2 bytes). > using a native IP protocol is more in line with other IETF routing > protocols. Like BGP? :-) Noel _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 14 08:23: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 1IKvPM-0003vM-1o; Tue, 14 Aug 2007 08:22:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKvPL-0003tq-0E for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 08:21:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvPK-0003ot-KU for manet@ietf.org; Tue, 14 Aug 2007 08:21:58 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKvPI-0001t6-Lp for manet@ietf.org; Tue, 14 Aug 2007 08:21:58 -0400 Received: (qmail 9982 invoked from network); 14 Aug 2007 14:21:54 +0200 Received: from unknown (HELO Teco) (217.169.232.206) by server9.hosting2go.nl with SMTP; 14 Aug 2007 14:21:51 +0200 From: "Teco_Boot" To: "'Dearlove, Christopher \(UK\)'" Date: Tue, 14 Aug 2007 14:21:38 +0200 Message-ID: <001b01c7de6d$bd06f5e0$b800800a@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfeW4nCBsZ3N+OLRdWzAchSY7qFQAAAQLGgAAI6pyA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: Philippe.Jacquet@inria.fr, manet@ietf.org, 'Thomas Clausen' Subject: [manet] RE: Comments on Metric TLV 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 Chris, Thanks for your quick response! Comments inline. Teco. > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Sent: dinsdag 14 augustus 2007 12:39 > To: Teco_Boot; jdean@itd.nrl.navy.mil; Thomas Clausen; > Philippe.Jacquet@inria.fr > Cc: manet@ietf.org > Subject: RE: Comments on Metric TLV > > > Comments >>> inline > > -----Original Message----- > From: Teco_Boot [mailto:teco@inf-net.nl] > Sent: 14 August 2007 11:12 > To: jdean@itd.nrl.navy.mil; Dearlove, Christopher (UK); 'Thomas > Clausen'; Philippe.Jacquet@inria.fr > Cc: manet@ietf.org > Subject: Comments on Metric TLV > > > *** WARNING *** > > This mail has originated outside your organization, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > Hi, > > I studied the proposals for a metric TLV representation. > Here some comments: > > 1) > I don't like fractional values. Elimination circumvents rounding or > truncating. So I prefer (16 + a) * 2^b over (1 + a/16) * 2^b. > It also extents the number of distinct values, from 207 to 256. > > >>> Having less tham 256 values is only because you've chosen to > >>> use the fractional representation but prohibit fractions. > >>> That I don't think is sensible, so it's 256 either way. The > >>> scaling is also actually irrelevant, it's just an implementation > >>> detail that has no actual consequences (you send the same octets, > >>> and get the same results). [Teco] Agreed it is mainly representation. But still I like using integers. For example, the "-15" would be "-0,9375". Sorry for using "decimal point is comma". I am just using the official ISO standards. And I am Dutch, so it is not that difficult for me:-) Another argument on not using fractions. Fractions introduce friction. > > 2) > I prefer enlarging the range between lowest and highest value. A simple > method is to subtract 15: (16 + a) * 2^b - 15. > > >>> Interesting, but it messes up later values as the 15 is only > >>> right in the first octave. So I don't like this at all. [Teco] The "-15" should be used in all cases. I think it is a minor adjustment and it provides an important increase in the range. > > Lowest value is 1, followed by 2, 3, ... 950.272, 983.040, 1.015.808. > Linear from 1 to 17, hereafter the exponential characteristic starts. > I my day-to-day work I deal with extremely low-speed radio links and > high-speed wired links; think of a data radio with shared 1kbps over the > radio interface and 1Gbps over the cable interface. Others could come up > with more extreme ends of the spectrum. > I evaluated using (16 + a) * 2^(b+4) - 255. Values are 1, 17, 33, 49, > ... > 15.204.097, 15.728.385, 16.252.673. Although the range is enlarged with > factor 16, I think it doesn't bring that much value. > > 3) > I see no reason for having a compact linear metric representation. > > >>> I agree with you here. Note that it's not in the proposal I > >>> presented. > > I suggest using an uncompressed 24-bit link metric. > > >>> But not here. I think there's no need for anything but the 4/4 > >>> bit value. [Teco] I like compressed metric very much. But forecasting linear metrics are not needed by anyone, also in the future, is precarious. I think it could be used as an escape. > > And use a 32-bit path metric in all cases. > The 24-bit link metric could be assigned a TLV type or subtype. This > enlarges the metric range to 1 - 16.777.216 without loss of resolution. > Using this TLV can be made fully compatible with the compressed > exponential > metric; both may be used in the same MANET region. > Linear metric representations could be needed by distance vector > mechanisms, > as path metric is computed hop by hop and loosing resolution could > introduce > bad behavior. See comment#8 related to DYMO below. > > 4) > I prefer defining a Do_Not_Use metric value, to be specified as the > binary > all_ones value: 255 for the single octet exponential TLV, 16.777.216 for > a > 24-bit linear TLV. Advertising such a value is useful for some > scenarios, > e.g. graceful shutdown of interface or router. > > >>> We don't need this in OLSRv2 - we have the concept of a LOST link. > > 5) > I do not see a reason for having a node metric (dean-manet-metriclv). A > node > is free to add whatever offset on metrics for its links. The result of > the > SPF path selection is equivalent. > > >>> Also agreed. > > 6) > I like the idea having metrics for a link generated by both the > transmitter > and the receiver on a link. This result in three cases for path metric > calculation: > - no link metric > - one metric only, generated by transmitter (outbound) or receiver > (inbound) > - two metrics, generated by both transmitter and receiver > First case: use a default metric; second case: use the metric that is > available and the third case: use the average, that is add the metrics > and > divide by two, truncate to get an integer. > > >>> I don't like this case, it defeats the whole motivation of > >>> bidirectional metrics - that there is no ambiguity. With > >>> lossy messages there is ambiguity using two node's values > >>> (in an average or whatever). [Teco] With the specified rules, there is no ambiguity. During converging, some information could be missing on some nodes. This could introduce problems. But routing loops during converging is a problem with link state protocols in the first place. I think smooth metric updates circumvent micro loops in some cases. So it could be a trade off. Both transmitter and receiver could have a policy or lower layer indication for the metric. I don't like signaling between those for injecting the link metric at a single point. My proposal provides full functionality, at low cost. Only the asymmetric links need the enhancement, and whenever these metrics are available, on both the transmitter and the receiver, why not using them? FYI: inputs for outbound metric: #retransmits, load, transmit power, battery, pricing, policy, etc. > > Metrics shall be direction sensitive. A link A <--> B may have four > metrics, > A inbound, A outbound, B inbound and B outbound. > > >>> I don't see the point of this. [Teco] Node A would be able set the inbound and outbound metric fully independent of what node B is doing. The question is not having a valid requirement, but how to support this without high overhead and without any overhead if some implementation does not use this function. > > Metrics for opposite > directions may not be used for path metric calculation, e.g. default > metric > is to be used for A -> B when only A inbound and B outbound metrics are > available. > Effects caused by unsynchronized path computations are to be verified. > > 7) > When using a factor 16 as proposed above, the suggested default value > 4096 > (dearlove-olsrv2-metrics) is fairly low. A value 6.5536 is to be used. > Note > that in my "-15" suggestion, this default value cannot be stored in a > compressed exponential value. If default-value explicit signaling is > preferred, a default value of 65.521 is to be used. > > >>> OK, took me a second to realise . is what I'd write as comma, except > >>> I wouldn't. But I don't agree with the revision, 4096 is in the > centre > >>> of the range logarithmically, and I think that is right. (I also > think > >>> this is another argument against -15.) [Teco] If we keep using the (1 + a/16) * 2^b, default value 4096 is OK. If we scale up with factor 16, the default should scale up also. It has nothing to do with the -15. > > 8) > In DYMO, a path metric is used, it is called distance. Behavior is > similar > to distance vector. The distance field is one octet. Intermediate > routers > increment distance, minimum increment is 1. Adding a higher cost value > is > fully acceptable. > Personally, I prefer a uniform link metric / uniform path metric in > MANET > and even to be used in other IETF protocols. > - Enlarge the distance to 32-bit field? > > >>> While I've been on the other end of efficiency arguments, I really > >>> don't want to use more than one octet for a metric, and certainly > >>> not four. I want to just use a single, exponent/mantissa, octet. > >>> (Note that I'm not committed to the 4/4 bit split - in fact in the > >>> motivating timetlv we're about to change to 5/3. I think 4/4 is > >>> better here, but an argument for 5/3 or 3/5 could be made I'm sure.) > >>> Of course I'm not considering DYMO directly. [Teco] I never suggested skipping compressed metrics. Again, we do not know what is needed in the future. > > - Accept some kind of mixed mode? > For the latter, the required incremented-by-1 update could get lost by > the > compress mechanism. This is circumvented by incrementing the compressed > metric, by 1 or by setting to outbound link metric when link metric > value is > higher than the to-be-forwarded distance. > In short: we could use two distance formats, a short 8-bit path metric > and a > large 32-bit path metric. Conversion is allowed, but special attention > is > required for incrementing the distance hop-by-hop. > > 9) > In PacketBB, hop based fields are used: > MsgHdr.HopLimit - noHopLimit bit > MsgHdr.HopCount - noHopCount bit > We could discuss allowing high decrements (HopLimit) and high increments > (HopCount) during forwarding the messages. Rules for decrementing and > incrementing are to be determined. > DYMO uses HopLimit. > > >>> I think these are definitely intended to be hops, not metrics, > >>> and definitely should remain so. [Teco] History repeats itself. RIP metric was intended to be hopcount. But real world needed more and tricks using offsets are used frequently. Same for BGP AS-list. In the environment I am working in, some high-speed links can handle whatever signaling load; other links are extremely constrained. The question is how to implement some kind of filtering, based on this requirement. Using the HopLimit is a method. Do you reject such a usage? If so, why? If not, why not writing down it is allowed? > > During analysis I used the following formulas: > Lin_Metric = (16+MOD(Exp_Metric;16))*2^INT(Exp_Metric/16) - 15 > Exp_Metric = 16*FLOOR(LOG((Lin_Metric+15)/16;2);1) + > > INT(16*(((Lin_Metric+15)/16)/2^FLOOR(LOG((Lin_Metric+15)/16;2);1)-1)) > > Teco > > > > ******************************************************************** > 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 Aug 14 08:24:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvQT-0004JH-5q; Tue, 14 Aug 2007 08:23:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKvQS-0004J7-0l for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 08:23:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvQR-0004Iz-NV for manet@ietf.org; Tue, 14 Aug 2007 08:23:07 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKvQQ-0007pL-Ga for manet@ietf.org; Tue, 14 Aug 2007 08:23:07 -0400 Received: by nf-out-0910.google.com with SMTP id c10so688524nfd for ; Tue, 14 Aug 2007 05:23:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=RAHvQExMwWlbfhJqlQKPEoacxp68DlqdjTnzZzs9KDXUvz1qx4w+ZVTf3sGtHA02gOZdG6I7oEBTIsXyHSAnKey1lyxlu3aX2C1kgkLqg5vsmHKWeuJ1yiXkisJr5r086X8bkrTl/bz2hkNEHIb+Brr8FnQfw4bfkFrB7HFX7Rc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ZZ3kwphEMStHiETpdu+JnXpweXl8llCe2HmjWpwPgUIBaz356GCUtjUvvqzWLi5+JOzPMKYOF+jJvIFRCZkYwfLDiHdoqKjl4fb9Wzq8/iPYZbL0ox5FqKN0Glx7/5xrobnZzcgM2xzXpG4sMcRQvLZqtMjgPZ2gOfL44j3Sd5w= Received: by 10.78.131.8 with SMTP id e8mr2716012hud.1187094183953; Tue, 14 Aug 2007 05:23:03 -0700 (PDT) Received: by 10.78.53.8 with HTTP; Tue, 14 Aug 2007 05:23:03 -0700 (PDT) Message-ID: <374005f30708140523p2888a643he7f655b5b1d03c7a@mail.gmail.com> Date: Tue, 14 Aug 2007 17:53:03 +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: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [manet] PacketBB Recent Discussion #1 - Allowing multiple TLVs of the same type 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 focus the discussion around allowing multiple TLVs of the same type to be associated with the one entity in packetbb. If you have a good use case, please provide it and describe why it is useful. Ian Chakeres Note: I would like to quickly finish any remaining PacketBB discussion and move this document forward. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 14 08:28: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 1IKvTv-0006F9-JS; Tue, 14 Aug 2007 08:26:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKvTt-0006A9-PX for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 08:26:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvTt-000696-Fa for manet@ietf.org; Tue, 14 Aug 2007 08:26:41 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKvTs-0007ux-9J for manet@ietf.org; Tue, 14 Aug 2007 08:26:41 -0400 Received: by nf-out-0910.google.com with SMTP id c10so689421nfd for ; Tue, 14 Aug 2007 05:26:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=rlzEFAYTjC0uTx87I5+BFi15LTmloWZ9ymK8KlOhYKU+JymsJaduSoMB1TmzI6t3ioMF/Rl518rQ8n66zKl3pTDVoI/KGNT7Cgdh/dKBfAmh/wrhKCVnmCDbHd/8wFt9MvtMkmiuVj+M6FXUtAd8GVPzOGN8/KnRzMx2k0a/vTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=LhQxa7w/SfCConfId2m+IqhyAVsk51viMWh+zcPGm9ggq+zED/NxHoYNau9HVenOEFWwjXDRth1DGy/IO+hA+TSX83Elc1rdYFGrxz9o5CzNKEl/wmhOZr6I7IhQLsKa1Va/wOde/6hveF/XzBaRHgi5KvFXLvfNjmQbfk1ZUl8= Received: by 10.78.183.8 with SMTP id g8mr2705132huf.1187094398805; Tue, 14 Aug 2007 05:26:38 -0700 (PDT) Received: by 10.78.53.8 with HTTP; Tue, 14 Aug 2007 05:26:38 -0700 (PDT) Message-ID: <374005f30708140526u12378857q5e632236c28e8f7e@mail.gmail.com> Date: Tue, 14 Aug 2007 17:56:38 +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: d17f825e43c9aed4fd65b7edddddec89 Subject: [manet] PacketBB Recent Discussion #2 - Ordering TLVs 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 focus the discussion around ordering of TLV types within TLV blocks. If you have a good reason why we should not consistently order TLVs within a TLV block, please email it to the list. Please provide a clear use case that shows why ordering the TLVs is bad. Thanks. Ian Chakeres Note: I would like to quickly finish any remaining PacketBB discussion and move this document forward. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 14 08:41: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 1IKvgR-0008Jq-Fn; Tue, 14 Aug 2007 08:39:39 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKvgP-0008HD-8Y for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 08:39:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvgO-0008H5-V9 for manet@ietf.org; Tue, 14 Aug 2007 08:39:36 -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 1IKvgK-0008BC-4t for manet@ietf.org; Tue, 14 Aug 2007 08:39:36 -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 l7ECdUtm022076 for ; Tue, 14 Aug 2007 13:39:30 +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 l7ECdV88003760 for ; Tue, 14 Aug 2007 13:39:31 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 14 Aug 2007 13:39:30 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 13:39:30 +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: Tue, 14 Aug 2007 13:39:29 +0100 Message-ID: In-Reply-To: <001b01c7de6d$bd06f5e0$b800800a@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Metric TLV thread-index: AcfeW4nCBsZ3N+OLRdWzAchSY7qFQAAAQLGgAAI6pyAAAl5kAA== References: <001b01c7de6d$bd06f5e0$b800800a@Teco> From: "Dearlove, Christopher \(UK\)" To: "Teco_Boot" X-OriginalArrivalTime: 14 Aug 2007 12:39:30.0484 (UTC) FILETIME=[28C1C740:01C7DE70] X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: Philippe.Jacquet@inria.fr, manet@ietf.org, Thomas Clausen Subject: [manet] RE: Comments on Metric TLV 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 below. (I'm not going to repeat comments, in several cases I've made my point, we don't entirely agree.)=20 -----Original Message----- From: Teco_Boot [mailto:teco@inf-net.nl]=20 Sent: 14 August 2007 13:22 To: Dearlove, Christopher (UK) Cc: manet@ietf.org; jdean@itd.nrl.navy.mil; 'Thomas Clausen'; Philippe.Jacquet@inria.fr Subject: RE: Comments on Metric TLV Hi Chris,=20 Thanks for your quick response! Comments inline. Teco. > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Sent: dinsdag 14 augustus 2007 12:39 > To: Teco_Boot; jdean@itd.nrl.navy.mil; Thomas Clausen; > Philippe.Jacquet@inria.fr > Cc: manet@ietf.org > Subject: RE: Comments on Metric TLV >=20 >=20 > Comments >>> inline >=20 > -----Original Message----- > From: Teco_Boot [mailto:teco@inf-net.nl] > Sent: 14 August 2007 11:12 > To: jdean@itd.nrl.navy.mil; Dearlove, Christopher (UK); 'Thomas > Clausen'; Philippe.Jacquet@inria.fr > Cc: manet@ietf.org > Subject: Comments on Metric TLV >=20 >=20 > *** WARNING *** >=20 > This mail has originated outside your organization, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. >=20 > Hi, >=20 > I studied the proposals for a metric TLV representation. > Here some comments: >=20 > 1) > I don't like fractional values. Elimination circumvents rounding or > truncating. So I prefer (16 + a) * 2^b over (1 + a/16) * 2^b. > It also extents the number of distinct values, from 207 to 256. >=20 > >>> Having less tham 256 values is only because you've chosen to > >>> use the fractional representation but prohibit fractions. > >>> That I don't think is sensible, so it's 256 either way. The > >>> scaling is also actually irrelevant, it's just an implementation > >>> detail that has no actual consequences (you send the same octets, > >>> and get the same results). [Teco]=20 Agreed it is mainly representation. But still I like using integers. For example, the "-15" would be "-0,9375". Sorry for using "decimal point is comma". I am just using the official ISO standards. And I am Dutch, so it is not that difficult for me:-) Another argument on not using fractions. Fractions introduce friction. >=20 > 2) > I prefer enlarging the range between lowest and highest value. A simple > method is to subtract 15: (16 + a) * 2^b - 15. >=20 > >>> Interesting, but it messes up later values as the 15 is only > >>> right in the first octave. So I don't like this at all. [Teco]=20 The "-15" should be used in all cases. I think it is a minor adjustment and it provides an important increase in the range. >=20 > Lowest value is 1, followed by 2, 3, ... 950.272, 983.040, 1.015.808. > Linear from 1 to 17, hereafter the exponential characteristic starts. > I my day-to-day work I deal with extremely low-speed radio links and > high-speed wired links; think of a data radio with shared 1kbps over the > radio interface and 1Gbps over the cable interface. Others could come up > with more extreme ends of the spectrum. > I evaluated using (16 + a) * 2^(b+4) - 255. Values are 1, 17, 33, 49, > ... > 15.204.097, 15.728.385, 16.252.673. Although the range is enlarged with > factor 16, I think it doesn't bring that much value. >=20 > 3) > I see no reason for having a compact linear metric representation. >=20 > >>> I agree with you here. Note that it's not in the proposal I > >>> presented. >=20 > I suggest using an uncompressed 24-bit link metric. >=20 > >>> But not here. I think there's no need for anything but the 4/4 > >>> bit value. [Teco]=20 I like compressed metric very much. But forecasting linear metrics are not needed by anyone, also in the future, is precarious. I think it could be used as an escape. >=20 > And use a 32-bit path metric in all cases. > The 24-bit link metric could be assigned a TLV type or subtype. This > enlarges the metric range to 1 - 16.777.216 without loss of resolution. > Using this TLV can be made fully compatible with the compressed > exponential > metric; both may be used in the same MANET region. > Linear metric representations could be needed by distance vector > mechanisms, > as path metric is computed hop by hop and loosing resolution could > introduce > bad behavior. See comment#8 related to DYMO below. >=20 > 4) > I prefer defining a Do_Not_Use metric value, to be specified as the > binary > all_ones value: 255 for the single octet exponential TLV, 16.777.216 for > a > 24-bit linear TLV. Advertising such a value is useful for some > scenarios, > e.g. graceful shutdown of interface or router. >=20 > >>> We don't need this in OLSRv2 - we have the concept of a LOST link. >=20 > 5) > I do not see a reason for having a node metric (dean-manet-metriclv). A > node > is free to add whatever offset on metrics for its links. The result of > the > SPF path selection is equivalent. >=20 > >>> Also agreed. >=20 > 6) > I like the idea having metrics for a link generated by both the > transmitter > and the receiver on a link. This result in three cases for path metric > calculation: > - no link metric > - one metric only, generated by transmitter (outbound) or receiver > (inbound) > - two metrics, generated by both transmitter and receiver > First case: use a default metric; second case: use the metric that is > available and the third case: use the average, that is add the metrics > and > divide by two, truncate to get an integer. >=20 > >>> I don't like this case, it defeats the whole motivation of > >>> bidirectional metrics - that there is no ambiguity. With > >>> lossy messages there is ambiguity using two node's values > >>> (in an average or whatever). [Teco]=20 With the specified rules, there is no ambiguity. During converging, some information could be missing on some nodes. This could introduce problems. But routing loops during converging is a problem with link state protocols in the first place. I think smooth metric updates circumvent micro loops in some cases. So it could be a trade off. Both transmitter and receiver could have a policy or lower layer indication for the metric. I don't like signaling between those for injecting the link metric at a single point. My proposal provides full functionality, at low cost. Only the asymmetric links need the enhancement, and whenever these metrics are available, on both the transmitter and the receiver, why not using them? FYI: inputs for outbound metric: #retransmits, load, transmit power, battery, pricing, policy, etc. >=20 > Metrics shall be direction sensitive. A link A <--> B may have four > metrics, > A inbound, A outbound, B inbound and B outbound. >=20 > >>> I don't see the point of this. [Teco]=20 Node A would be able set the inbound and outbound metric fully independent of what node B is doing. The question is not having a valid requirement, but how to support this without high overhead and without any overhead if some implementation does not use this function. >=20 > Metrics for opposite > directions may not be used for path metric calculation, e.g. default > metric > is to be used for A -> B when only A inbound and B outbound metrics are > available. > Effects caused by unsynchronized path computations are to be verified. >=20 > 7) > When using a factor 16 as proposed above, the suggested default value > 4096 > (dearlove-olsrv2-metrics) is fairly low. A value 6.5536 is to be used. > Note > that in my "-15" suggestion, this default value cannot be stored in a > compressed exponential value. If default-value explicit signaling is > preferred, a default value of 65.521 is to be used. >=20 > >>> OK, took me a second to realise . is what I'd write as comma, except > >>> I wouldn't. But I don't agree with the revision, 4096 is in the > centre > >>> of the range logarithmically, and I think that is right. (I also > think > >>> this is another argument against -15.) [Teco]=20 If we keep using the (1 + a/16) * 2^b, default value 4096 is OK. If we scale up with factor 16, the default should scale up also. It has nothing to do with the -15. >>>>> No, the 4096 is with the x16. Without it it's 256. In the >>>>> centre of the range - logarithmically. > 8) > In DYMO, a path metric is used, it is called distance. Behavior is > similar > to distance vector. The distance field is one octet. Intermediate > routers > increment distance, minimum increment is 1. Adding a higher cost value > is > fully acceptable. > Personally, I prefer a uniform link metric / uniform path metric in > MANET > and even to be used in other IETF protocols. > - Enlarge the distance to 32-bit field? >=20 > >>> While I've been on the other end of efficiency arguments, I really > >>> don't want to use more than one octet for a metric, and certainly > >>> not four. I want to just use a single, exponent/mantissa, octet. > >>> (Note that I'm not committed to the 4/4 bit split - in fact in the > >>> motivating timetlv we're about to change to 5/3. I think 4/4 is > >>> better here, but an argument for 5/3 or 3/5 could be made I'm sure.) > >>> Of course I'm not considering DYMO directly. [Teco]=20 I never suggested skipping compressed metrics. Again, we do not know what is needed in the future. >>>>> There's an issue that unless you are prepared to put a major >>>>> delay in, and I emphatically am not, there are constraints on >>>>> what's sensible to do right now. See presentation at IETF. > - Accept some kind of mixed mode? > For the latter, the required incremented-by-1 update could get lost by > the > compress mechanism. This is circumvented by incrementing the compressed > metric, by 1 or by setting to outbound link metric when link metric > value is > higher than the to-be-forwarded distance. > In short: we could use two distance formats, a short 8-bit path metric > and a > large 32-bit path metric. Conversion is allowed, but special attention > is > required for incrementing the distance hop-by-hop. >=20 > 9) > In PacketBB, hop based fields are used: > MsgHdr.HopLimit - noHopLimit bit > MsgHdr.HopCount - noHopCount bit > We could discuss allowing high decrements (HopLimit) and high increments > (HopCount) during forwarding the messages. Rules for decrementing and > incrementing are to be determined. > DYMO uses HopLimit. >=20 > >>> I think these are definitely intended to be hops, not metrics, > >>> and definitely should remain so. [Teco]=20 History repeats itself. RIP metric was intended to be hopcount. But real world needed more and tricks using offsets are used frequently. Same for BGP AS-list. >>>>> But sometimes it's the other way. IP TTL was meant to be time, >>>>> with a minimum value, but became hops (hop limit in IPv6). In the environment I am working in, some high-speed links can handle whatever signaling load; other links are extremely constrained. The question is how to implement some kind of filtering, based on this requirement. Using the HopLimit is a method. Do you reject such a usage? If so, why? If not, why not writing down it is allowed? >>>>> I was just indicating that I think that the hop count/limit >>>>> in the packetbb header are intended to be, and I believe >>>>> should remain, hops. But that doesn't stop you from using >>>>> other things in other places. > During analysis I used the following formulas: > Lin_Metric =3D (16+MOD(Exp_Metric;16))*2^INT(Exp_Metric/16) - 15 > Exp_Metric =3D 16*FLOOR(LOG((Lin_Metric+15)/16;2);1) + >=20 > INT(16*(((Lin_Metric+15)/16)/2^FLOOR(LOG((Lin_Metric+15)/16;2);1)-1)) >=20 > Teco >=20 >=20 >=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 Tue Aug 14 08:58: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 1IKvx4-0002oQ-4C; Tue, 14 Aug 2007 08:56:50 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKvx2-0002nH-3S for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 08:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvx1-0002m1-Pn for manet@ietf.org; Tue, 14 Aug 2007 08:56:47 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKvx0-0000ZL-9u for manet@ietf.org; Tue, 14 Aug 2007 08:56:47 -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 l7ECuipW011290 for ; Tue, 14 Aug 2007 13:56:44 +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 l7ECuiti015652 for ; Tue, 14 Aug 2007 13:56:44 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 14 Aug 2007 13:56:44 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 13:56:44 +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] PacketBB Recent Discussion #1 - Allowing multiple TLVs ofthe same type Date: Tue, 14 Aug 2007 13:56:43 +0100 Message-ID: In-Reply-To: <374005f30708140523p2888a643he7f655b5b1d03c7a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] PacketBB Recent Discussion #1 - Allowing multiple TLVs ofthe same type thread-index: AcfebeWsD4nDpR5LTg6Avu+AuzlnoAAA9ZwA References: <374005f30708140523p2888a643he7f655b5b1d03c7a@mail.gmail.com> From: "Dearlove, Christopher \(UK\)" To: "Ian Chakeres" , X-OriginalArrivalTime: 14 Aug 2007 12:56:44.0588 (UTC) FILETIME=[912186C0:01C7DE72] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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've attached both of Ian's messages, this is really a reply to both. I don't regard these as separate, they are linked. If you have multiple TLVs then useful ordering is difficult with indexes. (Packet/message TLVs can still be ordered.) Ordering however is what allows non-multiple TLVs to be efficiently recognised. That makes the non-unique case the critical one. And I regard having a use case as necessary, but not sufficient to consider a change, given the real, rather than hypothetical, gains that are currently available. -----Original Message----- From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 Sent: 14 August 2007 13:23 To: manet Subject: [manet] PacketBB Recent Discussion #1 - Allowing multiple TLVs ofthe same type *** 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 I'd like to focus the discussion around allowing multiple TLVs of the same type to be associated with the one entity in packetbb. If you have a good use case, please provide it and describe why it is useful. Ian Chakeres Note: I would like to quickly finish any remaining PacketBB discussion and move this document forward. *** 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 I'd like to focus the discussion around ordering of TLV types within TLV blocks. If you have a good reason why we should not consistently order TLVs within a TLV block, please email it to the list. Please provide a clear use case that shows why ordering the TLVs is bad. Thanks. Ian Chakeres Note: I would like to quickly finish any remaining PacketBB discussion and move this document forward. _______________________________________________ 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 ******************************************************************** 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 Aug 14 10:33: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 1IKxQK-0006q0-I3; Tue, 14 Aug 2007 10:31:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKxQI-0006pr-E7 for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 10:31:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKxQI-0006pi-4V for manet@ietf.org; Tue, 14 Aug 2007 10:31:06 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKxQG-000354-U7 for manet@ietf.org; Tue, 14 Aug 2007 10:31:06 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l7EEUtl3023575 for ; Tue, 14 Aug 2007 10:31:02 -0400 (EDT) Message-Id: <200708141431.l7EEUtl3023575@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007081410305807368 for ; Tue, 14 Aug 2007 10:30:58 -0400 From: "Justin Dean" To: Subject: RE: [manet] Re: draft-ietf-manet-packetbb-08 Date: Tue, 14 Aug 2007 10:35:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acfd5I63ZIDets6ES/SjPGPAz3umKwAmvnJg In-Reply-To: <46C0B836.9010209@nokia.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 reason I say protocols can not make ordering requirements on their own is for an envisioned system where two protocols are using the same packetbb "code engine". This would save duplicate packets and become more efficent than both protocols opperating seperatly. If the first of these protocols requires ordering but the 2nd does not the first may make the wrong assumption that the tlv/address is not present when it is just out of order because the 2nd added some out of order tlv/address. Actually nhdp/olsr nhdp/smf are an example of this and they would break if nhdp requires ordering but olsr does not. Justin -----Original Message----- From: Charles E. Perkins [mailto:charles.perkins@nokia.com] Sent: Monday, August 13, 2007 4:00 PM To: ext Justin Dean Cc: manet@ietf.org Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08 Hello Justin, I have some follow-on comments on the points you raise. ext Justin Dean wrote: > The major advantage I can see is with 1 is being able to read a lack > of a tlv by the ordering without having to read the entire tlv block. > If multiple protocols in an integrated system are only looking for > specific tlv types they can more quickly decide if the information is there or not, i.e. > if I am looking for page 10 and I get to page 11 then its not there no > need to read the next 100 pages. It is not NEEDED, however, protocols > based off of packetbb MUST know if this constraint is true for all > packetbb packets or this advantage is lost. > Actually, I think that any protocol using packetbb should make any such necessary constraints in the individual protocol document. Since other protocols may not have the same requirement, it is not needed to impose the constraints globally for all time. Perhaps, if it is needed to expedite the information lookup as you are suggesting, packetbb could recommend that individual protocol specifications include a relevant section near the front of the document (just after the protocol applicability statement?). > The advantages of 4 are a little bit less clear but the same principle > applies. And if the ordering is not stated here for both 1 and 4 no > later document can later state ordering constraints and have it work > for all packetbb protocols. > But any individual protocol can do so, and that is, I think, all that is needed. > With 3 this was introduced to avoid confusion on which value should be used. > I personally would be ok with wording this closer to 2 in mandating > that the tlv definitions explicitly disallow or allow. I am also O.K. with wording closer to (2). Regards, Charlie P. PS. I should have included the four cases, I guess... so here they are. > 1 TLVs in the same TLV block MUST be sorted in non-descending tlv- > fulltype order. > > 2 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. > > 3 Two or more TLVs with the same tlv-fulltype in the same address block > TLV block MUST NOT be associated with the same copy of an address > (i.e. they must not have overlapping index ranges). > > 4 TLVs with the same tlv-fulltype associated with the same address > block MUST be sorted in ascending index-start order. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 14 11:04: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 1IKxv8-0003Yx-PO; Tue, 14 Aug 2007 11:02:58 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKxv6-0003Yr-MJ for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 11:02:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKxv6-0003Yi-Cj for manet@ietf.org; Tue, 14 Aug 2007 11:02:56 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKxv5-0003vH-4o for manet@ietf.org; Tue, 14 Aug 2007 11:02:56 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 14 Aug 2007 08:02:54 -0700 X-IronPort-AV: i="4.19,260,1183359600"; d="scan'208"; a="199850368:sNHT47817684" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7EF2s32017939; Tue, 14 Aug 2007 08:02:54 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7EF2sVp024465; Tue, 14 Aug 2007 15:02:54 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); Tue, 14 Aug 2007 11:02:47 -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] PacketBB Recent Discussion #1 - Allowing multiple TLVs ofthe same type Date: Tue, 14 Aug 2007 11:02:46 -0400 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC7640455889E@xmb-rtp-208.amer.cisco.com> In-Reply-To: <374005f30708140523p2888a643he7f655b5b1d03c7a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] PacketBB Recent Discussion #1 - Allowing multiple TLVs ofthe same type Thread-Index: AcfebeKJTfcvCZ4dTWmg+qKZsRQObgAFiF9g From: "Stan Ratliff \(sratliff\)" To: "Ian Chakeres" , "manet" X-OriginalArrivalTime: 14 Aug 2007 15:02:47.0528 (UTC) FILETIME=[2CFE9680:01C7DE84] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1812; t=1187103774; x=1187967774; c=relaxed/simple; s=sjdkim4002; 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]=20PacketBB=20Recent=20Discussion=20#1=20-=20A llowing=20multiple=20TLVs=20ofthe=20same=20type |Sender:=20; bh=B2tRxVdUOOqwbTWu9asYtqsHKsctEv3AV6pas9bWxoo=; b=D4eddpdVkjrCEsfAT5g/U6iEjTUQ00sREaakrP7cPPg1jopLMb4mYSVGcqBCWeJajAPeWtyJ FZ+C/sH3VSC9T8D6JrheYQw9LaV3w1rD7xzVCS6iqojIlvvLpmM1pejn; Authentication-Results: sj-dkim-4; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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,=20 I think that Justin provided a use case in his email:=20 --------------------Included email---------------------- With 3 this was introduced to avoid confusion on which value should be used. I personally would be ok with wording this closer to 2 in mandating that the tlv definitions explicitly disallow or allow. There are issues with allowing this but there may also be an advantages. A hypothetical example; 10 addresses each of which is either bright or dark and blue or red 1 bright red 2 bright blue 3 bright red 4 bright red 5 bright red 6 dark red 7 dark blue 8 dark red 9 dark red 10 dark red Under the current constraints it would require 1 indexed tlv for bright 1 indexed tlv for dark, then either a m-tlv for all the addressed or a mixture of m-tlvs and indexed tlvs for the color. If constraint of more than one was lifted for the color tlv a m-tlv for all nodes being red and then 2 single tlvs for the 2 blue nodes may reduce overhead.=20 -------------------End of inclusion---------------------- Regards, Stan >-----Original Message----- >From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 >Sent: Tuesday, August 14, 2007 8:23 AM >To: manet >Subject: [manet] PacketBB Recent Discussion #1 - Allowing=20 >multiple TLVs ofthe same type > >I'd like to focus the discussion around allowing multiple TLVs of the >same type to be associated with the one entity in packetbb. > >If you have a good use case, please provide it and describe=20 >why it is useful. > >Ian Chakeres > >Note: I would like to quickly finish any remaining PacketBB discussion >and move this document forward. > > >_______________________________________________ >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 Aug 14 11: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 1IKyHN-00044a-Tp; Tue, 14 Aug 2007 11:25:57 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKyHL-00044H-Nt for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 11:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKyHL-000449-EE for manet@ietf.org; Tue, 14 Aug 2007 11:25:55 -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 1IKyHJ-0004Yh-SV for manet@ietf.org; Tue, 14 Aug 2007 11:25:55 -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 l7EFPq2L014368 for ; Tue, 14 Aug 2007 16:25:52 +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 l7EFPq2O010999 for ; Tue, 14 Aug 2007 16:25:52 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 14 Aug 2007 16:25:52 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 16:25:51 +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] PacketBB Recent Discussion #1 - Allowing multiple TLVsofthe same type Date: Tue, 14 Aug 2007 16:25:50 +0100 Message-ID: In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC7640455889E@xmb-rtp-208.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] PacketBB Recent Discussion #1 - Allowing multiple TLVsofthe same type thread-index: AcfebeKJTfcvCZ4dTWmg+qKZsRQObgAFiF9gAACTuiA= References: <374005f30708140523p2888a643he7f655b5b1d03c7a@mail.gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC7640455889E@xmb-rtp-208.amer.cisco.com> From: "Dearlove, Christopher \(UK\)" To: "Stan Ratliff \(sratliff\)" , "Ian Chakeres" , "manet" X-OriginalArrivalTime: 14 Aug 2007 15:25:51.0792 (UTC) FILETIME=[66148300:01C7DE87] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 wouldn't regard that as a real use case - when was the last time you actually wanted to declare a node as bright red? In addition I don't actually think it is a good example. What is the relationship between bright and red? - If bright red is a colour, why not simply encode bright red, bright blue, dark red etc. as separate colours in a single value space? What's the advantage of separating them but also regarding them as the same TLV - one with values including red, blue, bright and dark, a definite apples and oranges sort of value list? - If bright is something quite separate from red, we have two TLVs, and putting them in a single value space makes no sense at all. - If you consider bright to be a modifier of colour, then a natural encoding is to use TLV subtypes, one for colour, one for brightness. Note that you can have two TLVs of the same type but different subtypes (i.e different full types) associated with the same information. -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 14 August 2007 16:03 To: Ian Chakeres; manet Subject: RE: [manet] PacketBB Recent Discussion #1 - Allowing multiple TLVsofthe same type *** 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 Ian,=20 I think that Justin provided a use case in his email:=20 --------------------Included email---------------------- With 3 this was introduced to avoid confusion on which value should be used. I personally would be ok with wording this closer to 2 in mandating that the tlv definitions explicitly disallow or allow. There are issues with allowing this but there may also be an advantages. A hypothetical example; 10 addresses each of which is either bright or dark and blue or red 1 bright red 2 bright blue 3 bright red 4 bright red 5 bright red 6 dark red 7 dark blue 8 dark red 9 dark red 10 dark red Under the current constraints it would require 1 indexed tlv for bright 1 indexed tlv for dark, then either a m-tlv for all the addressed or a mixture of m-tlvs and indexed tlvs for the color. If constraint of more than one was lifted for the color tlv a m-tlv for all nodes being red and then 2 single tlvs for the 2 blue nodes may reduce overhead.=20 -------------------End of inclusion---------------------- Regards, Stan >-----Original Message----- >From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 >Sent: Tuesday, August 14, 2007 8:23 AM >To: manet >Subject: [manet] PacketBB Recent Discussion #1 - Allowing=20 >multiple TLVs ofthe same type > >I'd like to focus the discussion around allowing multiple TLVs of the >same type to be associated with the one entity in packetbb. > >If you have a good use case, please provide it and describe=20 >why it is useful. > >Ian Chakeres > >Note: I would like to quickly finish any remaining PacketBB discussion >and move this document forward. > > >_______________________________________________ >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 ******************************************************************** 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 Aug 14 11:43: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 1IKyWp-0006bx-4W; Tue, 14 Aug 2007 11:41:55 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKyWn-0006bp-DE for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 11:41:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKyWn-0006bc-3b for manet@ietf.org; Tue, 14 Aug 2007 11:41:53 -0400 Received: from cliff.cs.toronto.edu ([128.100.3.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKyWl-000585-SC for manet@ietf.org; Tue, 14 Aug 2007 11:41:53 -0400 Received: from [192.168.70.107] (alexander.syslab.sandbox [192.168.70.107]) by cliff.cs.toronto.edu (Postfix) with ESMTP id EE45A5FD29; Tue, 14 Aug 2007 11:41:54 -0400 (EDT) Message-ID: <46C1CD30.1030407@cs.toronto.edu> Date: Tue, 14 Aug 2007 11:41:36 -0400 From: Alex Varshavsky User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: tccc@lists.cs.columbia.edu, manet@ietf.org, MOBISYS@LISTSERV.ACM.ORG, MOBICOM@LISTSERV.ACM.ORG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Subject: [manet] HotMobile 2008: Call for Papers 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 +-------------------------------------------------------------+ HotMobile 2008 The Ninth Workshop on Mobile Computing, Systems and Applications Silverado Resort, Napa Valley, CA, USA February 25-26, 2008 http://www.cs.umass.edu/hotmobile2008 +-------------------------------------------------------------+ HotMobile 2008, the Ninth Workshop on Mobile Computing Systems and Applications continues the series of highly selective, interactive workshops focused on mobile applications, systems, and environments, as well as their underlying state-of-the-art technologies. HotMobile's small workshop format makes it ideal for presenting and discussing new directions or controversial approaches. We solicit submissions of position papers that focus primarily on applications and systems and that propose new directions of research, advocate non-traditional approaches to old (or new) ideas, or generate controversy and discussion. We particularly look for position papers containing highly original ideas in the following topic areas, although papers describing other challenges unique to or exacerbated by mobility are also welcome: * Operating system and distributed systems support for mobile computing * Coordination, aggregation, and spontaneous interaction of mobile devices * Novel applications and environments supporting mobility * HCI issues related to mobile computing * Security and privacy of mobile computing * Management, configuration, and deployment of systems supporting mobility Submissions describing new lower-level technologies are welcome if they focus on how the technology is being used or integrated into a system or application. HotMobile 2008 will be a highly interactive workshop. Submissions will be judged based upon originality, technical merit, topical relevance, and likelihood of leading to insightful discussion at the workshop. To encourage an atmosphere conducive to participation, attendance will be limited to 70 participants. Authors of submitted papers and accepted demo proposals will be given first priority, with others able to register on a space-available basis. Paper submissions are due on Oct 16, 2007 at 23:59:59 EST. Submissions should contain 6 or fewer U.S. letter pages in PDF format. Papers should be single column using 12pt font. The conference proceedings will be published by the ACM. Preliminary proceedings will be made available to workshop participants online ahead of the workshop. Printed proceedings will be published and mailed to participants after the workshop. As is customary, papers must not have been published elsewhere and may not be simultaneously under submission at another venue. Poster and demo submissions are due on January 14th, 2008 at 23:59:59 EST. Submissions must include an extended abstract limited to one 8.5x11-inch page in 12pt font. The important dates, as well as the organizing and program committee members are listed below. We look forward to seeing you at HotMobile 2008. Sincerely, Alex Varshavsky HotMobile 2008 Publicity Chair Important Dates --------------- Paper submissions due: October 16, 2007, 23:59 EST Poster and demo submissions due: January 14, 2008, 23:59 EST Acceptance notification: January 8, 2008 Revised position papers due: January 23, 2008 Workshop: February 25-26, 2008 Final position papers due: 1 month after workshop Organizing Committee -------------------- General Chair: Mirjana Spasojevic, Nokia Research Palo Alto, USA Program Chair: Mark Corner, University of Massachusetts Amherst, USA Posters Chair: Frank Bentley, Motorola Labs, USA Finance Chair: April Slayden Mitchell, HP Laboratories, USA Publicity Chair: Alex Varshavsky, University of Toronto, Canada Program Committee ----------------- Victor Bahl, MSR Redmond, USA Gaetano Borriello, University of Washington, USA Ramon Caceres, IBM Research, USA John Canny, Berkeley, USA Landon Cox, Duke University, USA Maria Ebling, IBM Research, USA Jason Flinn, University of Michigan, USA Adrian Friday, Lancaster University, UK Jason Hong, CMU, USA Ravi Jain, Google, USA Scott Klemmer, Stanford University, USA Tadayoshi Kohno, University of Washington, USA Anthony LaMarca, Intel Research Seattle, USA Bhaskaran Raman, IIT Kanpur, India Mahadev Satyanarayanan, CMU, USA Roy Want, Intel Research Santa Clara, USA Ellen Zegura, Georgia Tech, USA _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 14 12:19:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKz5t-0001vg-Te; Tue, 14 Aug 2007 12:18:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKz5s-0001vB-Aq for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 12:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKz5s-0001v3-0u for manet@ietf.org; Tue, 14 Aug 2007 12:18:08 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKz5q-0007b6-Ql for manet@ietf.org; Tue, 14 Aug 2007 12:18:08 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l7EGH0Do029391; Tue, 14 Aug 2007 12:17:00 -0400 (EDT) Message-Id: <200708141617.l7EGH0Do029391@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007081412170007971 ; Tue, 14 Aug 2007 12:17:00 -0400 From: "Justin Dean" To: "'Dearlove, Christopher \(UK\)'" , "'Stan Ratliff \(sratliff\)'" , "'Ian Chakeres'" , "'manet'" Subject: RE: [manet] PacketBB Recent Discussion #1 - Allowing multipleTLVsofthe same type Date: Tue, 14 Aug 2007 12:21:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfebeKJTfcvCZ4dTWmg+qKZsRQObgAFiF9gAACTuiAAAVsusA== In-Reply-To: X-Spam-Score: 1.5 (+) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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 Well those were just two attributes which came to mind when writing the example. Having say link type of symmetric/asymmetric as one type and then another orthogonal attribute lets say willingness where most nodes have willingness of default and 2 are never illustrates this with a more reasonable way. They are separate disjoint attributes apples to oranges yes and they should be. There is, however, value in having them associated with the same address block and there is no clear way to order the addresses to allow for aggregation of both sets of information within the same address block. Having said that though the gains given in this example are minimal. In the current case the two fixed size tlvs can advertise all of the first attributes. The second tlv most likely would use a single m-tlv to assign the mixed up attributes to all of the nodes. Relaxing this restraint would allow for some gains in terms of the size of representation of the second attribute in some cases (not all dependant on how jumbled the values were). Size of current restrained packetbb = tlvoverhead*3+#addresses. (worst case) Optional size of unrestrained packetbb = tlvoverhead*3+tlvoverhead*#ofdisjointattirbutes. There are many different ways to represent different attributes with the current draft already. And it isn't always clear on what the best encoding scheme is for any given case as it is. Relaxing this restriction would allow another option to try and further reduce overhead but only in the case where the second attribute is mostly the same with small number of different values. I don't often think this will be the case. Please correct me if I am wrong but I don't see a big issue with allow derived protocols to decide on this behavior. It doesn't seem like it would break any further protocols by not having it in packetbb. So my question to you guys is, what are the tradeoffs with changing the wording to more closely reflect the issues with regard to multiple message/packet tlvfulltypes? The ordering restriction I am still very strongly in favor of keeping. Justin -----Original Message----- From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] Sent: Tuesday, August 14, 2007 11:26 AM To: Stan Ratliff (sratliff); Ian Chakeres; manet Subject: RE: [manet] PacketBB Recent Discussion #1 - Allowing multipleTLVsofthe same type I wouldn't regard that as a real use case - when was the last time you actually wanted to declare a node as bright red? In addition I don't actually think it is a good example. What is the relationship between bright and red? - If bright red is a colour, why not simply encode bright red, bright blue, dark red etc. as separate colours in a single value space? What's the advantage of separating them but also regarding them as the same TLV - one with values including red, blue, bright and dark, a definite apples and oranges sort of value list? - If bright is something quite separate from red, we have two TLVs, and putting them in a single value space makes no sense at all. - If you consider bright to be a modifier of colour, then a natural encoding is to use TLV subtypes, one for colour, one for brightness. Note that you can have two TLVs of the same type but different subtypes (i.e different full types) associated with the same information. -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] Sent: 14 August 2007 16:03 To: Ian Chakeres; manet Subject: RE: [manet] PacketBB Recent Discussion #1 - Allowing multiple TLVsofthe same type *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Ian, I think that Justin provided a use case in his email: --------------------Included email---------------------- With 3 this was introduced to avoid confusion on which value should be used. I personally would be ok with wording this closer to 2 in mandating that the tlv definitions explicitly disallow or allow. There are issues with allowing this but there may also be an advantages. A hypothetical example; 10 addresses each of which is either bright or dark and blue or red 1 bright red 2 bright blue 3 bright red 4 bright red 5 bright red 6 dark red 7 dark blue 8 dark red 9 dark red 10 dark red Under the current constraints it would require 1 indexed tlv for bright 1 indexed tlv for dark, then either a m-tlv for all the addressed or a mixture of m-tlvs and indexed tlvs for the color. If constraint of more than one was lifted for the color tlv a m-tlv for all nodes being red and then 2 single tlvs for the 2 blue nodes may reduce overhead. -------------------End of inclusion---------------------- Regards, Stan >-----Original Message----- >From: Ian Chakeres [mailto:ian.chakeres@gmail.com] >Sent: Tuesday, August 14, 2007 8:23 AM >To: manet >Subject: [manet] PacketBB Recent Discussion #1 - Allowing >multiple TLVs ofthe same type > >I'd like to focus the discussion around allowing multiple TLVs of the >same type to be associated with the one entity in packetbb. > >If you have a good use case, please provide it and describe >why it is useful. > >Ian Chakeres > >Note: I would like to quickly finish any remaining PacketBB discussion >and move this document forward. > > >_______________________________________________ >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 ******************************************************************** 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 Tue Aug 14 12:25: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 1IKzBE-0003yn-6f; Tue, 14 Aug 2007 12:23:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKzBC-0003yK-SW for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 12:23:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzBC-0003yC-Ir for manet@ietf.org; Tue, 14 Aug 2007 12:23:38 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKzB8-0007pP-5Z for manet@ietf.org; Tue, 14 Aug 2007 12:23:38 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Aug 2007 12:23:34 -0400 X-IronPort-AV: i="4.19,260,1183348800"; d="scan'208"; a="67970302:sNHT72556062" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7EGNXSa022997; Tue, 14 Aug 2007 12:23:33 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7EGN6jo001963; Tue, 14 Aug 2007 16:23:29 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 12:23:13 -0400 Received: from [10.81.246.164] ([10.81.246.164]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 12:23:12 -0400 Message-ID: <46C1D6EE.8050203@cisco.com> Date: Tue, 14 Aug 2007 12:23:10 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] RE: Comments on Metric TLV References: <001b01c7de6d$bd06f5e0$b800800a@Teco> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2007 16:23:12.0917 (UTC) FILETIME=[69268450:01C7DE8F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14403; t=1187108613; x=1187972613; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bberry@cisco.com; z=From:=20Bo=20Berry=20 |Subject:=20Re=3A=20[manet]=20RE=3A=20Comments=20on=20Metric=20TLV |Sender:=20 |To:=20=22Dearlove, =20Christopher=20\(UK\)=22=20; bh=Um7bCy5lcrePmyBpaWfETMh4LyERpHMlSfgy0cIW3mY=; b=AwKpSpA8ya4uFlJwivNm7Zk3jvCMOHxBWNC2KI2Tv2i+GPQEgXoqo9ZqUIF5+6GXgeXazPvC 9Xl7USfQ+eSJAGA2xqGXUAWIE6+kiA/u5CASP+sUig5pk1momGwerGTK; Authentication-Results: rtp-dkim-2; header.From=bberry@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Cc: manet@ietf.org, Philippe.Jacquet@inria.fr, 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 in-line. -Bo Dearlove, Christopher (UK) wrote: > Comments >>>>> inline below. (I'm not going to repeat comments, > in several cases I've made my point, we don't entirely > agree.) > > -----Original Message----- > From: Teco_Boot [mailto:teco@inf-net.nl] > Sent: 14 August 2007 13:22 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; jdean@itd.nrl.navy.mil; 'Thomas Clausen'; > Philippe.Jacquet@inria.fr > Subject: RE: Comments on Metric TLV > > Hi Chris, > Thanks for your quick response! > Comments inline. > Teco. > >> -----Original Message----- >> From: Dearlove, Christopher (UK) > [mailto:Chris.Dearlove@baesystems.com] >> Sent: dinsdag 14 augustus 2007 12:39 >> To: Teco_Boot; jdean@itd.nrl.navy.mil; Thomas Clausen; >> Philippe.Jacquet@inria.fr >> Cc: manet@ietf.org >> Subject: RE: Comments on Metric TLV >> >> >> Comments >>> inline >> >> -----Original Message----- >> From: Teco_Boot [mailto:teco@inf-net.nl] >> Sent: 14 August 2007 11:12 >> To: jdean@itd.nrl.navy.mil; Dearlove, Christopher (UK); 'Thomas >> Clausen'; Philippe.Jacquet@inria.fr >> Cc: manet@ietf.org >> Subject: Comments on Metric TLV >> >> >> *** WARNING *** >> >> This mail has originated outside your organization, >> either from an external partner or the Global Internet. >> Keep this in mind if you answer this message. >> >> Hi, >> >> I studied the proposals for a metric TLV representation. >> Here some comments: >> >> 1) >> I don't like fractional values. Elimination circumvents rounding or >> truncating. So I prefer (16 + a) * 2^b over (1 + a/16) * 2^b. >> It also extents the number of distinct values, from 207 to 256. >> >>>>> Having less tham 256 values is only because you've chosen to >>>>> use the fractional representation but prohibit fractions. >>>>> That I don't think is sensible, so it's 256 either way. The >>>>> scaling is also actually irrelevant, it's just an implementation >>>>> detail that has no actual consequences (you send the same octets, >>>>> and get the same results). > [Teco] > Agreed it is mainly representation. But still I like using integers. For > example, the "-15" would be "-0,9375". > > Sorry for using "decimal point is comma". I am just using the official > ISO > standards. And I am Dutch, so it is not that difficult for me:-) > Another argument on not using fractions. Fractions introduce friction. > > >> 2) >> I prefer enlarging the range between lowest and highest value. A > simple >> method is to subtract 15: (16 + a) * 2^b - 15. >> >>>>> Interesting, but it messes up later values as the 15 is only >>>>> right in the first octave. So I don't like this at all. > [Teco] > The "-15" should be used in all cases. I think it is a minor adjustment > and > it provides an important increase in the range. > > >> Lowest value is 1, followed by 2, 3, ... 950.272, 983.040, 1.015.808. >> Linear from 1 to 17, hereafter the exponential characteristic starts. >> I my day-to-day work I deal with extremely low-speed radio links and >> high-speed wired links; think of a data radio with shared 1kbps over > the >> radio interface and 1Gbps over the cable interface. Others could come > up >> with more extreme ends of the spectrum. >> I evaluated using (16 + a) * 2^(b+4) - 255. Values are 1, 17, 33, 49, >> ... >> 15.204.097, 15.728.385, 16.252.673. Although the range is enlarged > with >> factor 16, I think it doesn't bring that much value. I suggest that the metrics/cost design not be based upon low speed (kbps) radio links. The metrics/cost should also handle high speed (gbps) radio links. The design should also be capable of distinguishing the difference in the two extremes of radio links when comparing link costs and route selections. Perhaps we should define the cost value as a full 16-bit unsigned range (or 32-bit) so all cost factors can be fairly compared. If this is done then the constraints on the equations can be relaxed. For example, using one type of radio may require a different set of equations than the ones listed here. With the standard cost range the computed costs can be fairly compared to other costs. I don't think we want to corner the radios into these equations. >> >> 3) >> I see no reason for having a compact linear metric representation. >> >>>>> I agree with you here. Note that it's not in the proposal I >>>>> presented. >> I suggest using an uncompressed 24-bit link metric. >> >>>>> But not here. I think there's no need for anything but the 4/4 >>>>> bit value. > [Teco] > I like compressed metric very much. But forecasting linear metrics are > not > needed by anyone, also in the future, is precarious. I think it could be > used as an escape. > > >> And use a 32-bit path metric in all cases. >> The 24-bit link metric could be assigned a TLV type or subtype. This >> enlarges the metric range to 1 - 16.777.216 without loss of > resolution. >> Using this TLV can be made fully compatible with the compressed >> exponential >> metric; both may be used in the same MANET region. >> Linear metric representations could be needed by distance vector >> mechanisms, >> as path metric is computed hop by hop and loosing resolution could >> introduce >> bad behavior. See comment#8 related to DYMO below. >> >> 4) >> I prefer defining a Do_Not_Use metric value, to be specified as the >> binary >> all_ones value: 255 for the single octet exponential TLV, 16.777.216 > for >> a >> 24-bit linear TLV. Advertising such a value is useful for some >> scenarios, >> e.g. graceful shutdown of interface or router. >> >>>>> We don't need this in OLSRv2 - we have the concept of a LOST link. If the node is to send a Do_Not_use metric, it is better that the metric not be sent. >> 5) >> I do not see a reason for having a node metric (dean-manet-metriclv). > A >> node >> is free to add whatever offset on metrics for its links. The result of >> the >> SPF path selection is equivalent. >> >>>>> Also agreed. If the node is battery powered, it may be useful to send an indication that its battery is running low and traffic should be routed around this node if possible. This indication would be applied to all links (radio and wired) on the reporting node. >> 6) >> I like the idea having metrics for a link generated by both the >> transmitter >> and the receiver on a link. This result in three cases for path metric >> calculation: >> - no link metric >> - one metric only, generated by transmitter (outbound) or receiver >> (inbound) >> - two metrics, generated by both transmitter and receiver >> First case: use a default metric; second case: use the metric that is >> available and the third case: use the average, that is add the metrics >> and >> divide by two, truncate to get an integer. >> >>>>> I don't like this case, it defeats the whole motivation of >>>>> bidirectional metrics - that there is no ambiguity. With >>>>> lossy messages there is ambiguity using two node's values >>>>> (in an average or whatever). > [Teco] > With the specified rules, there is no ambiguity. During converging, some > information could be missing on some nodes. This could introduce > problems. > But routing loops during converging is a problem with link state > protocols > in the first place. I think smooth metric updates circumvent micro loops > in > some cases. So it could be a trade off. > Both transmitter and receiver could have a policy or lower layer > indication > for the metric. I don't like signaling between those for injecting the > link > metric at a single point. > My proposal provides full functionality, at low cost. Only the > asymmetric > links need the enhancement, and whenever these metrics are available, on > both the transmitter and the receiver, why not using them? > FYI: inputs for outbound metric: #retransmits, load, transmit power, > battery, pricing, policy, etc. If we define a lengthy set of metrics how would >> Metrics shall be direction sensitive. A link A <--> B may have four >> metrics, >> A inbound, A outbound, B inbound and B outbound. >> >>>>> I don't see the point of this. > [Teco] > Node A would be able set the inbound and outbound metric fully > independent > of what node B is doing. > The question is not having a valid requirement, but how to support this > without high overhead and without any overhead if some implementation > does > not use this function. This capability is dependent upon the radio. Some may be able to provide such metrics and others not. We need to be sure to allow for this. > > >> Metrics for opposite >> directions may not be used for path metric calculation, e.g. default >> metric >> is to be used for A -> B when only A inbound and B outbound metrics > are >> available. >> Effects caused by unsynchronized path computations are to be verified. >> >> 7) >> When using a factor 16 as proposed above, the suggested default value >> 4096 >> (dearlove-olsrv2-metrics) is fairly low. A value 6.5536 is to be used. >> Note >> that in my "-15" suggestion, this default value cannot be stored in a >> compressed exponential value. If default-value explicit signaling is >> preferred, a default value of 65.521 is to be used. >> >>>>> OK, took me a second to realise . is what I'd write as comma, > except >>>>> I wouldn't. But I don't agree with the revision, 4096 is in the >> centre >>>>> of the range logarithmically, and I think that is right. (I also >> think >>>>> this is another argument against -15.) > [Teco] > If we keep using the (1 + a/16) * 2^b, default value 4096 is OK. > If we scale up with factor 16, the default should scale up also. > It has nothing to do with the -15. > >>>>>> No, the 4096 is with the x16. Without it it's 256. In the >>>>>> centre of the range - logarithmically. > >> 8) >> In DYMO, a path metric is used, it is called distance. Behavior is >> similar >> to distance vector. The distance field is one octet. Intermediate >> routers >> increment distance, minimum increment is 1. Adding a higher cost value >> is >> fully acceptable. >> Personally, I prefer a uniform link metric / uniform path metric in >> MANET >> and even to be used in other IETF protocols. >> - Enlarge the distance to 32-bit field? >> >>>>> While I've been on the other end of efficiency arguments, I really >>>>> don't want to use more than one octet for a metric, and certainly >>>>> not four. I want to just use a single, exponent/mantissa, octet. >>>>> (Note that I'm not committed to the 4/4 bit split - in fact in the >>>>> motivating timetlv we're about to change to 5/3. I think 4/4 is >>>>> better here, but an argument for 5/3 or 3/5 could be made I'm > sure.) >>>>> Of course I'm not considering DYMO directly. > [Teco] > I never suggested skipping compressed metrics. > Again, we do not know what is needed in the future. > >>>>>> There's an issue that unless you are prepared to put a major >>>>>> delay in, and I emphatically am not, there are constraints on >>>>>> what's sensible to do right now. See presentation at IETF. > >> - Accept some kind of mixed mode? >> For the latter, the required incremented-by-1 update could get lost by >> the >> compress mechanism. This is circumvented by incrementing the > compressed >> metric, by 1 or by setting to outbound link metric when link metric >> value is >> higher than the to-be-forwarded distance. >> In short: we could use two distance formats, a short 8-bit path metric >> and a >> large 32-bit path metric. Conversion is allowed, but special attention >> is >> required for incrementing the distance hop-by-hop. >> >> 9) >> In PacketBB, hop based fields are used: >> MsgHdr.HopLimit - noHopLimit bit >> MsgHdr.HopCount - noHopCount bit >> We could discuss allowing high decrements (HopLimit) and high > increments >> (HopCount) during forwarding the messages. Rules for decrementing and >> incrementing are to be determined. >> DYMO uses HopLimit. >> >>>>> I think these are definitely intended to be hops, not metrics, >>>>> and definitely should remain so. > [Teco] > History repeats itself. RIP metric was intended to be hopcount. But real > world needed more and tricks using offsets are used frequently. Same for > BGP > AS-list. I think we should clarify the meaning of metric vs cost. As written I find the use of the terms some what confusing. Once we clarify the use of these two terms a lot of the discussion above becomes easier. I see a uniform cost being computed from the metric. > >>>>>> But sometimes it's the other way. IP TTL was meant to be time, >>>>>> with a minimum value, but became hops (hop limit in IPv6). > > In the environment I am working in, some high-speed links can handle > whatever signaling load; other links are extremely constrained. The > question > is how to implement some kind of filtering, based on this requirement. > Using > the HopLimit is a method. Do you reject such a usage? If so, why? If > not, > why not writing down it is allowed? > >>>>>> I was just indicating that I think that the hop count/limit >>>>>> in the packetbb header are intended to be, and I believe >>>>>> should remain, hops. But that doesn't stop you from using >>>>>> other things in other places. > >> During analysis I used the following formulas: >> Lin_Metric = (16+MOD(Exp_Metric;16))*2^INT(Exp_Metric/16) - 15 >> Exp_Metric = 16*FLOOR(LOG((Lin_Metric+15)/16;2);1) + >> >> INT(16*(((Lin_Metric+15)/16)/2^FLOOR(LOG((Lin_Metric+15)/16;2);1)-1)) >> >> Teco >> >> >> >> ******************************************************************** >> 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 Tue Aug 14 13:51:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0WI-0001kd-M1; Tue, 14 Aug 2007 13:49:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IL0WG-0001kX-Dr for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 13:49:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0WG-0001kP-1g for manet@ietf.org; Tue, 14 Aug 2007 13:49:28 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL0WE-00055J-Uy for manet@ietf.org; Tue, 14 Aug 2007 13:49:27 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 14 Aug 2007 10:49:24 -0700 X-IronPort-AV: i="4.19,260,1183359600"; d="scan'208"; a="199948511:sNHT61801200" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7EHnOiZ014244; Tue, 14 Aug 2007 10:49:24 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7EHnJiT019809; Tue, 14 Aug 2007 17:49:23 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); Tue, 14 Aug 2007 13:49:11 -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] Re: draft-ietf-manet-packetbb-08 Date: Tue, 14 Aug 2007 13:49:10 -0400 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC7640455893D@xmb-rtp-208.amer.cisco.com> In-Reply-To: <83F747AA-3CFE-4F82-9E45-E6713B16CFCE@polytechnique.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: draft-ietf-manet-packetbb-08 Thread-Index: AcfeJIHfhZZ2zg+gRXSRMfTu2eMaCAAdj6RA From: "Stan Ratliff \(sratliff\)" To: "Thomas Clausen" , "Charles E. Perkins" , "Bo Berry \(bberry\)" X-OriginalArrivalTime: 14 Aug 2007 17:49:11.0224 (UTC) FILETIME=[6BBDB380:01C7DE9B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8627; t=1187113764; x=1187977764; c=relaxed/simple; s=sjdkim2002; 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]=20Re=3A=20draft-ietf-manet-packetbb-08 |Sender:=20; bh=HXIAgxRwLJq961ZDg747iYArpSxXnYKA4dF5d7iT3Ws=; b=uJXAV62g01SFb5UUFFCRR3LuLk9VvknK0gXH9tIlQLyxYyQRl1eBTmdx94AOemmvKDI0CeXt m6mqOrzdYwt/U58dKhskExDpVg/TObfV8dBavhUIfmCSwNZ61uRyem1q; Authentication-Results: sj-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: Christopher Dearlove , manet 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, > I should add that going from RFC3626 (which doesn't use packetbb) =20 >to OLSRv2 (which uses packetbb) not only resulted in a dramatic net =20 >reduction of the control message size but also roughly cut the size of the=20 >packet/message parsing/generating code by 2/3. Since the packetbb=20 >structure is intended exactly for making general components, I can=20 >(and, indeed, have) reuse the same code for other protocols or for >protocol extensions. Do you have any data that you'd be willing to share that compares the=20 path length and latency to generate a control plane message using=20 OLSRv2+packetbb versus RFC3626?=20 Regards, Stan >-----Original Message----- >From: Thomas Clausen [mailto:Thomas.Clausen@polytechnique.fr]=20 >Sent: Monday, August 13, 2007 11:38 PM >To: Charles E. Perkins; Stan Ratliff (sratliff); Bo Berry (bberry) >Cc: ext Justin Dean; manet manet; Christopher Dearlove >Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08 > >Charlie, Bo, Stan, Justin, all. > >I'm an insomniac today (it's 5AM here), so I'll toss in a few thoughts. > >In general, I agree 100% with Justin's analysis of the situation and =20 >his presentation of why the constraints are as they are accurately =20 >reflect the reasoning behind the document. The same with the email of =20 >Chris where he presents his thoughts on how the constraints serve to =20 >reduce complexity. I shall not repeat Justins' and Chris' excellent =20 >emails here, but rather add a few thoughts: > > - Since packetbb is intended to carry, in one packet, a set of =20 >messages, and since > these messages may be for different protocol=20 >instances (and, even, =20 >different > protocols), then some level of coordination is required in =20 >packetbb for this. At least, > packet-tlv's would have to either have or not have the =20 >constraints, and these > constraints would have to be specified somewhere, that an =20 >implementation can > correctly deal with incoming packets. packetbb seems=20 >the logical =20 >place. > > - Having a set of constraints for packet-tlv's and then=20 >different =20 >constraints for message > TLVs and address-block TLVs (and, possibly, different=20 >constraints =20 >for TLV blocks in > different message types) is messy: it'd break the=20 >ability to have =20 >one piece of code > constructing (or parsing) all TLV blocks identically=20 >and sanity-=20 >checking of all things > packetbb. That is: it'd dramatically increase the=20 >code footprint =20 >required to make a > packetbb parser/generator, and any such would no=20 >longer be generic. > > I should add that going from RFC3626 (which doesn't=20 >use packetbb) =20 >to OLSRv2 > (which uses packetbb) not only resulted in a dramatic net =20 >reduction of the control > message size but also roughly cut the size of the=20 >packet/message =20 >parsing/generating > code by 2/3. Since the packetbb structure is intended=20 >exactly for =20 >making general > components, I can (and, indeed, have) reuse the same=20 >code for =20 >other protocols or for > protocol extensions. > > So I second also Chris' comment that having these=20 >constraints =20 >reduces the complexity, > but in a different way than what he indicates: it=20 >allows me to =20 >write code that consistency > checks packets/messages once, rather than having to=20 >do so for each =20 >protocol/extension > I think up. Obviously, I agree with Chris' issues on how it =20 >reduces complexity in the receiving > end without adding to the complexity of the sending end > > - One of the requirements (and now I am repeating=20 >Justin's argument) =20 >for packetbb > that has been brought forward at least as early as=20 >the Paris IETF =20 >(when these > constraints were introduced and formalized) was to be=20 >able to =20 >terminate processing > of a TLV block early -- i.e. as Justin say, if you're=20 >looking for =20 >page 10 and you get to > page 11, then you can stop without reading the next=20 >100 pages if =20 >you know that > the pages appear in order. > > We had intense discussions on this in Paris and=20 >Vancouver, and I =20 >was convinced that > there was/is rough consensus behind this. I shall not=20 >be speaking =20 >on behalf of the > participants in these discussions (which, btw., were open to =20 >anyone caring to join them), > but very clear requirements from real deployments and real =20 >customers and manufacturers > were presented for this, and were throughly discussed=20 >at that =20 >point already. > >While the discussion as to if we can or cannot or should or should =20 >not do something based on some hypothetical future is interesting, I =20 >am more concerned with the fact that we are operating within a design-=20 >space where we've got companies providing real stuff to real =20 >customers having real requirements, presenting these requirements and =20 >participating in the specification that has now become packetbb. I =20 >think that our goal is to satisfy that concrete and real design-space. > >In conclusion, I'm strongly in favor of retaining the constraints as =20 >they are, since I've seen a strong case for them and I have seen no =20 >solid case for removing them. > >Thomas > > >On Aug 13, 2007, at 9:59 PM, Charles E. Perkins wrote: > >> >> Hello Justin, >> >> I have some follow-on comments on the points you raise. >> >> ext Justin Dean wrote: >>> The major advantage I can see is with 1 is being able to read a =20 >>> lack of a >>> tlv by the ordering without having to read the entire tlv block. If >>> multiple protocols in an integrated system are only looking for =20 >>> specific tlv >>> types they can more quickly decide if the information is there or =20 >>> not, i.e. >>> if I am looking for page 10 and I get to page 11 then its not =20 >>> there no need >>> to read the next 100 pages. It is not NEEDED, however, protocols =20 >>> based off >>> of packetbb MUST know if this constraint is true for all packetbb =20 >>> packets or >>> this advantage is lost. >>> >> Actually, I think that any protocol using packetbb should make any =20 >> such >> necessary constraints in the individual protocol document. Since =20 >> other >> protocols may not have the same requirement, it is not needed to =20 >> impose >> the constraints globally for all time. Perhaps, if it is needed to =20 >> expedite the >> information lookup as you are suggesting, packetbb could recommend =20 >> that >> individual protocol specifications include a relevant section near =20 >> the front >> of the document (just after the protocol applicability statement?). >>> The advantages of 4 are a little bit less clear but the same =20 >>> principle >>> applies. And if the ordering is not stated here for both 1 and 4 =20 >>> no later >>> document can later state ordering constraints and have it work for =20 >>> all >>> packetbb protocols. >>> >> But any individual protocol can do so, and that is, I think, all =20 >> that is needed. >>> With 3 this was introduced to avoid confusion on which value =20 >>> should be used. >>> I personally would be ok with wording this closer to 2 in =20 >>> mandating that the >>> tlv definitions explicitly disallow or allow. >> I am also O.K. with wording closer to (2). >> >> Regards, >> Charlie P. >> >> PS. I should have included the four cases, I guess... so here they =20 >> are. >>> 1 TLVs in the same TLV block MUST be sorted in non-descending tlv- >>> fulltype order. >>> >>> 2 Packet and message TLVs MUST be defined so as to indicate =20 >>> whether two >>> TLVs with the same tlv-fulltype are, or are not, allowed in the =20 >>> same >>> packet or message TLV block, respectively. >>> >>> 3 Two or more TLVs with the same tlv-fulltype in the same address =20 >>> block >>> TLV block MUST NOT be associated with the same copy of an address >>> (i.e. they must not have overlapping index ranges). >>> >>> 4 TLVs with the same tlv-fulltype associated with the same address >>> block MUST be sorted in ascending index-start order. >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> > >--=20 >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 Tue Aug 14 15:13: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 1IL1nX-000051-7V; Tue, 14 Aug 2007 15:11:23 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IL1nV-00004w-KI for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 15:11:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1nV-0008WU-8U for manet@ietf.org; Tue, 14 Aug 2007 15:11:21 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL1nU-0006ow-Av for manet@ietf.org; Tue, 14 Aug 2007 15:11:21 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.109]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IL1nP-000GNb-Ms; Tue, 14 Aug 2007 15:11:16 -0400 X-MHO-User: U2FsdGVkX1+tMGpc5hrX4ul9YG5R64hG X-MHO-User: U2FsdGVkX19DbmsmMrssgSCfZh2uzT/M X-MHO-User: U2FsdGVkX19Z0jmjzuoY3822WnUpvlwp X-MHO-User: U2FsdGVkX1+A8yp3iSZPa0Yk35CeMjgo X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/KCRTxX/x5i9oNZvv2vHFN In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC7640455893D@xmb-rtp-208.amer.cisco.com> References: <7FB7EE0A621BA44B8B69E5F0A09DC7640455893D@xmb-rtp-208.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <586FFF1E-969F-4355-9811-522259BB328A@computer.org> Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08 Date: Tue, 14 Aug 2007 21:11:11 +0200 To: Stan Ratliff ((sratliff)) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: Christopher Dearlove , manet 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 Aug 14, 2007, at 7:49 PM, Stan Ratliff ((sratliff)) wrote: > Thomas, > >> I should add that going from RFC3626 (which doesn't use packetbb) >> to OLSRv2 (which uses packetbb) not only resulted in a dramatic net >> reduction of the control message size but also roughly cut the >> size of > the >> packet/message parsing/generating code by 2/3. Since the packetbb >> structure is intended exactly for making general components, I can >> (and, indeed, have) reuse the same code for other protocols or for >> protocol extensions. > > Do you have any data that you'd be willing to share that compares the > path length and latency to generate a control plane message using > OLSRv2+packetbb versus RFC3626? > I've got some data -- path lengths obtained are the same (anything else would surprise me) between OLSRv2 and RFC3626. If by "latency to generate a control plane message" you mean the time it takes for a router to construct a mesage....then that's something I've never measured in either of the two. It should, however, be obvious that this is one of the places where one can do various things (make various compromises) and get various results. I do not know if anyone has actually looked at this in any great detail in any of the MANET protocols. Thomas > Regards, > Stan > > > >> -----Original Message----- >> From: Thomas Clausen [mailto:Thomas.Clausen@polytechnique.fr] >> Sent: Monday, August 13, 2007 11:38 PM >> To: Charles E. Perkins; Stan Ratliff (sratliff); Bo Berry (bberry) >> Cc: ext Justin Dean; manet manet; Christopher Dearlove >> Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08 >> >> Charlie, Bo, Stan, Justin, all. >> >> I'm an insomniac today (it's 5AM here), so I'll toss in a few >> thoughts. >> >> In general, I agree 100% with Justin's analysis of the situation and >> his presentation of why the constraints are as they are accurately >> reflect the reasoning behind the document. The same with the email of >> Chris where he presents his thoughts on how the constraints serve to >> reduce complexity. I shall not repeat Justins' and Chris' excellent >> emails here, but rather add a few thoughts: >> >> - Since packetbb is intended to carry, in one packet, a set of >> messages, and since >> these messages may be for different protocol >> instances (and, even, >> different >> protocols), then some level of coordination is required in >> packetbb for this. At least, >> packet-tlv's would have to either have or not have the >> constraints, and these >> constraints would have to be specified somewhere, that an >> implementation can >> correctly deal with incoming packets. packetbb seems >> the logical >> place. >> >> - Having a set of constraints for packet-tlv's and then >> different >> constraints for message >> TLVs and address-block TLVs (and, possibly, different >> constraints >> for TLV blocks in >> different message types) is messy: it'd break the >> ability to have >> one piece of code >> constructing (or parsing) all TLV blocks identically >> and sanity- >> checking of all things >> packetbb. That is: it'd dramatically increase the >> code footprint >> required to make a >> packetbb parser/generator, and any such would no >> longer be generic. >> >> I should add that going from RFC3626 (which doesn't >> use packetbb) >> to OLSRv2 >> (which uses packetbb) not only resulted in a dramatic net >> reduction of the control >> message size but also roughly cut the size of the >> packet/message >> parsing/generating >> code by 2/3. Since the packetbb structure is intended >> exactly for >> making general >> components, I can (and, indeed, have) reuse the same >> code for >> other protocols or for >> protocol extensions. >> >> So I second also Chris' comment that having these >> constraints >> reduces the complexity, >> but in a different way than what he indicates: it >> allows me to >> write code that consistency >> checks packets/messages once, rather than having to >> do so for each >> protocol/extension >> I think up. Obviously, I agree with Chris' issues on how it >> reduces complexity in the receiving >> end without adding to the complexity of the sending end >> >> - One of the requirements (and now I am repeating >> Justin's argument) >> for packetbb >> that has been brought forward at least as early as >> the Paris IETF >> (when these >> constraints were introduced and formalized) was to be >> able to >> terminate processing >> of a TLV block early -- i.e. as Justin say, if you're >> looking for >> page 10 and you get to >> page 11, then you can stop without reading the next >> 100 pages if >> you know that >> the pages appear in order. >> >> We had intense discussions on this in Paris and >> Vancouver, and I >> was convinced that >> there was/is rough consensus behind this. I shall not >> be speaking >> on behalf of the >> participants in these discussions (which, btw., were open to >> anyone caring to join them), >> but very clear requirements from real deployments and real >> customers and manufacturers >> were presented for this, and were throughly discussed >> at that >> point already. >> >> While the discussion as to if we can or cannot or should or should >> not do something based on some hypothetical future is interesting, I >> am more concerned with the fact that we are operating within a >> design- >> space where we've got companies providing real stuff to real >> customers having real requirements, presenting these requirements and >> participating in the specification that has now become packetbb. I >> think that our goal is to satisfy that concrete and real design- >> space. >> >> In conclusion, I'm strongly in favor of retaining the constraints as >> they are, since I've seen a strong case for them and I have seen no >> solid case for removing them. >> >> Thomas >> >> >> On Aug 13, 2007, at 9:59 PM, Charles E. Perkins wrote: >> >>> >>> Hello Justin, >>> >>> I have some follow-on comments on the points you raise. >>> >>> ext Justin Dean wrote: >>>> The major advantage I can see is with 1 is being able to read a >>>> lack of a >>>> tlv by the ordering without having to read the entire tlv >>>> block. If >>>> multiple protocols in an integrated system are only looking for >>>> specific tlv >>>> types they can more quickly decide if the information is there or >>>> not, i.e. >>>> if I am looking for page 10 and I get to page 11 then its not >>>> there no need >>>> to read the next 100 pages. It is not NEEDED, however, protocols >>>> based off >>>> of packetbb MUST know if this constraint is true for all packetbb >>>> packets or >>>> this advantage is lost. >>>> >>> Actually, I think that any protocol using packetbb should make any >>> such >>> necessary constraints in the individual protocol document. Since >>> other >>> protocols may not have the same requirement, it is not needed to >>> impose >>> the constraints globally for all time. Perhaps, if it is needed to >>> expedite the >>> information lookup as you are suggesting, packetbb could recommend >>> that >>> individual protocol specifications include a relevant section near >>> the front >>> of the document (just after the protocol applicability statement?). >>>> The advantages of 4 are a little bit less clear but the same >>>> principle >>>> applies. And if the ordering is not stated here for both 1 and 4 >>>> no later >>>> document can later state ordering constraints and have it work for >>>> all >>>> packetbb protocols. >>>> >>> But any individual protocol can do so, and that is, I think, all >>> that is needed. >>>> With 3 this was introduced to avoid confusion on which value >>>> should be used. >>>> I personally would be ok with wording this closer to 2 in >>>> mandating that the >>>> tlv definitions explicitly disallow or allow. >>> I am also O.K. with wording closer to (2). >>> >>> Regards, >>> Charlie P. >>> >>> PS. I should have included the four cases, I guess... so here they >>> are. >>>> 1 TLVs in the same TLV block MUST be sorted in non-descending tlv- >>>> fulltype order. >>>> >>>> 2 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. >>>> >>>> 3 Two or more TLVs with the same tlv-fulltype in the same address >>>> block >>>> TLV block MUST NOT be associated with the same copy of an >>>> address >>>> (i.e. they must not have overlapping index ranges). >>>> >>>> 4 TLVs with the same tlv-fulltype associated with the same address >>>> block MUST be sorted in ascending index-start order. >>> _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 14 15:56: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 1IL2T3-00025q-L8; Tue, 14 Aug 2007 15:54:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IL2T1-00025a-QV for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 15:54:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL2T1-00025S-Ga for manet@ietf.org; Tue, 14 Aug 2007 15:54:15 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL2Sz-0004jS-TO for manet@ietf.org; Tue, 14 Aug 2007 15:54:15 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7EJs7Kh006129; Tue, 14 Aug 2007 22:54:11 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 22:54:09 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 14:54:05 -0500 Received: from [172.18.141.139] ([172.18.141.139]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 14:54:05 -0500 Message-ID: <46C2085E.7060304@nokia.com> Date: Tue, 14 Aug 2007 12:54:06 -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] Re: draft-ietf-manet-packetbb-08 References: <200708131829.l7DIT6ET025839@s2.itd.nrl.navy.mil> <46C0B836.9010209@nokia.com> <83F747AA-3CFE-4F82-9E45-E6713B16CFCE@polytechnique.fr> In-Reply-To: <83F747AA-3CFE-4F82-9E45-E6713B16CFCE@polytechnique.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2007 19:54:05.0246 (UTC) FILETIME=[DE86B5E0:01C7DEAC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: manet 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, I deleted the other respondents to your previous email. To some extent, we could compare the TLV ordering constraint to imposing an ordering on command-line options. Of course it is do-able, but a good way to make people angry. We do not know all the future protocol designers, and so it is easy to validate making them angry since one can claim ignorance of their needs. Maybe, after all, they are just weird by packetbb standards. To respond to your points: ext Thomas Clausen wrote: > In general, I agree 100% with Justin's analysis of the situation and > his presentation of why the constraints are as they are accurately > reflect the reasoning behind the document. Solidarity is good in many cases... > - Since packetbb is intended to carry, in one packet, a set of > messages, and since > these messages may be for different protocol instances (and, > even, different > protocols), then some level of coordination is required in > packetbb for this. I think this feature will be more valuable for some systems than for others, and I don't see that it is relevant to the discussion about the constraints, but ... > At least, > packet-tlv's would have to either have or not have the > constraints, and these > constraints would have to be specified somewhere, that an > implementation can > correctly deal with incoming packets. packetbb seems the logical > place. That is debatable, and I do not think it is logical to place such constraints for all future designs. > > - Having a set of constraints for packet-tlv's and then different > constraints for message > TLVs and address-block TLVs (and, possibly, different > constraints for TLV blocks in > different message types) is messy: it'd break the ability to > have one piece of code > constructing (or parsing) all TLV blocks identically and > sanity-checking of all things > packetbb. That is: it'd dramatically increase the code footprint > required to make a > packetbb parser/generator, and any such would no longer be generic. Maybe you are right, and that all the different types of protocol element blocks should not have any ordering constraints. But it seems to me that you are broadening the discussion unnecessarily. I don't fully understand your point about different constraints. If I had to write a single subroutine for parsing the TLVs, it would have a type-dependent boolean flag specifying the existence of an ordering constraint. That is not "dramatic". And, it serves also to validate my belief that the objections are really based on exaggerated claims about difficulty. > > > I should add that going from RFC3626 (which doesn't use > packetbb) to OLSRv2 > (which uses packetbb) not only resulted in a dramatic net > reduction of the control > message size but also roughly cut the size of the packet/message > parsing/generating > code by 2/3. Since the packetbb structure is intended exactly > for making general > components, I can (and, indeed, have) reuse the same code for > other protocols or for > protocol extensions. You didn't explicitly mention the second-system effect, which any good programmer knows is (in fact!) dramatic. > > So I second also Chris' comment that having these constraints > reduces the complexity, > but in a different way than what he indicates: it allows me to > write code that consistency > checks packets/messages once, rather than having to do so for > each protocol/extension > I think up. Obviously, I agree with Chris' issues on how it > reduces complexity in the receiving > end without adding to the complexity of the sending end Solidarity is good, but in this case I really think you are claiming more difficulty than exists. You either check the ordering or you don't! O.K., there are a few more braces in the source code... > > - One of the requirements (and now I am repeating Justin's > argument) for packetbb > that has been brought forward at least as early as the Paris > IETF (when these > constraints were introduced and formalized) was to be able to > terminate processing > of a TLV block early -- i.e. as Justin say, if you're looking > for page 10 and you get to > page 11, then you can stop without reading the next 100 pages if > you know that > the pages appear in order. Here I would compare to command-line processing. And, by the way, the pages in many books are unnumbered. Sometimes it matters, sometimes not. > > We had intense discussions on this in Paris and Vancouver, and I > was convinced that > there was/is rough consensus behind this. I shall not be > speaking on behalf of the > participants in these discussions (which, btw., were open to > anyone caring to join them), > but very clear requirements from real deployments and real > customers and manufacturers > were presented for this, and were throughly discussed at that > point already. I guess you mean the discussions did not occur in the working group meetings or on the mailing list. Anyway it sailed clear past me without leaving any discernable memory or impression. > > While the discussion as to if we can or cannot or should or should not > do something based on some hypothetical future is interesting, I am > more concerned with the fact that we are operating within a > design-space where we've got companies providing real stuff to real > customers having real requirements, presenting these requirements and > participating in the specification that has now become packetbb. I > think that our goal is to satisfy that concrete and real design-space. Did you want to talk about how companies cite experimental RFCs in their in their RFPs and even in standards documents? I'm a big fan of real customers. I am having a hard time believing any company would tell you "We _need_ monotonically increasing TLV types". I can believe they would tell you "We need slim parsers". Of course we all do. But my suggestions are NOT increasing the size of the parser. In fact, if you completely eliminate the ordering, the parser would be smaller. Moreover, you would really need to allocate the TLV types with a lot of spaces in between the numbering, to avoid having types with fractional or irrational values. But maybe anyway we should have more transcendental types :-) [ommmmm] For designs that want to have early termination, _that_ really does belong in the protocol specification, and presumably would be trivial to check. These are very general remarks, supplied just in response to your points. I'll try to be more specific in response to other more specific emails. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 14 16:38: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 1IL37s-0000FJ-4p; Tue, 14 Aug 2007 16:36:28 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IL37q-0000FE-Rl for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 16:36:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL37q-0000F6-Hx for manet@ietf.org; Tue, 14 Aug 2007 16:36:26 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL37o-0005h7-Pg for manet@ietf.org; Tue, 14 Aug 2007 16:36:26 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7EKa6Mg004369; Tue, 14 Aug 2007 23:36:11 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 23:36:05 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 15:36:03 -0500 Received: from [172.18.141.139] ([172.18.141.139]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 15:36:02 -0500 Message-ID: <46C21231.1020802@nokia.com> Date: Tue, 14 Aug 2007 13:36:01 -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] NHDP "Hello" packet too big References: <200708131533.l7DFXrTi017795@s2.itd.nrl.navy.mil> <46C0D8AD.9020000@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2007 20:36:02.0809 (UTC) FILETIME=[BB1C5690:01C7DEB2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb 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 again Thomas, You are making me work very hard today. ext Thomas Clausen wrote: >> I would suggest that these values not be sent in every Hello message. >> I'd rather (a) have default values and (b) allow nodes to send the >> values >> out only occasionally as desired. I know that there are not any >> universally valid values for the timers, but that hasn't stopped other >> protocols from having default values anyway. > > > So just to understand what you are suggesting, you want to specify > "absent a VALIDITY_TIME TLV, the validity time for information > contained in a HELLO message is XX seconds" -- same for Interval time? That would be the formulation for a default value, yes. > >>> The #of any give type of neighbor is limited to a max of 15. >> Yes. That is O.K., because graphs with more than 15 neighbors are >> pretty dense >> graphs. I like dense graphs too, but minimal systems will endeavor >> to avoid them >> and we should allow parsimonious operation while still allowing for >> more general >> operation as well. We can allow for more neighbors in several easy >> ways. For >> instance the same TLV could be entered multiple times. > > Sorry, you lost me. What TLV are you talking about that you want to > include multiple times? Assuming that you do not mean "TLV" but "block > of bits in your previous ascii-diagram", Well, I did make a TLV-oriented formulation in my previous email... see below > then I'll then say that in case where you have more than 15 addresses > in your message, your suggested scheme is not optimal in that (i) it > doesn't allow for optimal aggregation and (ii) a lot of information is > repeated. I point out that intelligent use of packetbb will allow you > to not repeat information and attain optimal aggregation. O.K. If you feel strongly about this, then we should have a "small" version and a "big" version. I suggest that the overhead from duplicated TLVs for the "small version" is still quite small in comparison with the "big" version. > > In Packetbb, TLVs are associated to addresses and express information > about addresses, they do not contain addresses. The above ascii-art > that your original message contained does not suggest any TLVs present. Here it is again, from my first message. But please note that this needs some more tuning in order to duplicate all the functionality in NHDP -- if, in fact, all of the functionality is needed. However, I am not debating that issue just right here... > ... new TLV def "Hello data element" [15 bytes = 5 bytes + 10 bytes data] > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=HELLO | Length | flags |#Selves|#Heard | #Sym | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | #Lost | Seq# | ..... data .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > where, "data" is as follows: > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Originator Address(es) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Head | Mid | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Mid | Mid | ..... extensions .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================================================================== > > Maybe I am missing something fundamental from what you're suggesting, > but I do not see the benefit of it. It is just the benefit of eliminating over half of the overhead from the NHDP formulation. > >>> If there are >>> more than 15 symmetric neighbors it can't convey that information. >>> A simple >>> "fix" would be to increase the size to 1 fully octet for each field >>> with a >>> flag. >> I don't think that is needed for the common cases, though. > > Nonetheless, Charlie, I *have* situations where I need to report >15 > addresses, and I *want* to be able to do so without having to resort > to hacks and patches. Why? Because hacks and patches increase the code > complexity and code footprint and parsing complexity. Please, Thomas, be nice. I don't call your designs hacks and patches. I remember from my days at IBM a lot of analogies about kicking dead whales down the beach, but I am really avoiding making any such analogies here. > > Notice that NHDP messages are based on packetbb, and that packetbb is > designed for a much larger scope than just nhdp. For example. OLSRv2 > and DYMO. In at least OLSRv2, I know of common scenarios where I want > to transmit >15 addresses in a message. And, I want to be able to do > so without having to have to write a special parser/parsing logic, but > rather use the same as in NHDP....and DYMO...or otherwise said, as > specified in packetbb. I think what you are saying is that we have to be constantly on guard, because packetbb is liable to substantially increase the packet overhead for any design that isn't sufficiently "like" OLSR. When do I begin to get more scared and go into panic mode? > > I know that you consider saving a bit here and there as more important > than being able to reduce the code footprint and/or processing > complexity, but as we discussed in Chicago, there're conflicting > requirements and I feel that packetbb (and, thus, NHDP) represents a > decent compromise. Well, I don't think so, pure and simple. I mean, jeez, more than _double_ the packet size??!! > > >>> ... Which brings me to my main >>> point. This packet format is designed to work very well for ONE >>> protocol >>> not many different possible protocols. >> I did not mean to say that the message format that I indicated was >> the final answer -- far from it. In fact, it was just the product of an >> hour's work, or two, motivated at the IETF as I finally had made >> time to read NHDP. I think this is important because neighborhood >> discovery messages can be a major source of congestion, especially >> if they are broadcast (thus, no RTS/CTS). > > And, as I also pointed out in Chicago, FLOODING is the major source of > congestion in MANETs, I certainly agree with this. Furthermore, I suggest that the small packet size does not in any way reduce the applicability of the protocol. > and in comparison to FLOODING, any overhead by a HELLO protocol is noise. I do NOT agree with this. > Thus, the prime task is to reduce the overhead of conducting a > flooding operation. I believe that SMF and even your own efforts in > SMURF indicate that you share this opinion? Second task is to reduce > the number of flooding operations required by a protocol. Doing those > two is, in my experience, the overwhelmingly largest and most > important part of MANET protocol design. In fact, our follow-on work has indicated that the performance of the protocols really, _really_ depends on HELLO intervals and neighborhood sizes. When MAC-layer acknowledgements can eliminate some of the need for the functionality of a HELLO message, we can see the benefit. I am not prone to make such extreme statements as you are in the recent notes, but I do believe that local neighborhood advertisements matter and that size matters. For just one reason, broadcast damages throughput for hidden terminals which are not detected by the sender (and won't be for the foreseeable future in 802.11-land). It is a matter of interest to find out all of the other reasons, but I disagree with your manner of dismissing them out of hand. > > Reducing the size of a given message by a few tens of octets or an > order of magnitude isn't really buying much, if anything at all. > Experience shows that the MAC overhead and the MAC contention [with > most/all MACs I know] is the bigger cost than the payload of a > transmission, and so that actually when making a transmission, > stuffing s much useful information into that transmission is > beneficial. Hence, the multi-message packet format of packetbb. I didn't want to get into the issues of reducing packet size for the routing protocol here, sigh... > > Here's an example of a real test I ran: running OLSR with "minimal" > link state information in the TC messages vs. with "full" link state > information in the TC messages (the avg. TC message size difference > was 1:2.4) doesn't make a significant dent in the performance of a 50 > node network in the real world. This was over basic 802.11 cards, btw. > > It does make a difference in a simulation or analysis, when you're > counting octets of overhead. It doesn't make a difference in the real > world when you're concerned with getting data traffic from a to b, it > doesn't in this test. > > These statements are, btw., based on experience from actually building > and running MANETs (and are backed up by analysis and simulation, but > that's an aside, what's interesting is how things actually run). I can fully believe you in an unloaded network. However, bigger packets more quickly drive a network into congestive behavior, and more quickly use up battery power. Whether the effect is 10%, 20%, or more is system-dependent. We agree on many points -- for instance, that flooding is the main culprit, and that sending multiple packets is to be avoided when one medium access can do the same job. I guess I ought to be happy for at least that much. In the meantime, I'll try to use small packets as rarely as possible to achieve results that in every way help to avoid flooding. >> >>> Suggested changes to improve compactness while maintaining >>> flexibility is. >>> >> Please try to see my current recommendation in exactly that light. >> > > Charlie, I appreciate your effort but I am not able to see your > recommendation in that light....because.......it's not. Thomas -- it IS! > > What you're proposing now is not a "suggestion to improve compactness > while maintaining flexibility" (to cite Justin), but is to scrap > essentially all of packetbb, No! I am proposing to maintain the address TLV structure, and construct a TLV that contains data needed for maintaining neighborhood structures. > which has been developed carefully over >2 years by the MANET wg > (including you, as indicated above and in previous emails), > implemented by numerous independent parties, fine-tuned over those two > years to allow for address aggregation in an efficient way, > flexibility in an efficient way, reasonably straight-forward AND > general parsing logic, verified to satisfy the requirements of > multiple parties and WGLCed ..... in favor of a > yet-to-be-specified-and-fine-tuned, not implemented, not evaluated > format which has as-yet undetermined features and flexibility. You are comparing packetbb to SMURF here. I am comparing NHDP to SMURF. Perhaps NHDP exposes the tendency for packetbb designs to split every last data item into separate TLVs (which causes huge overhead). That is some matter of concern, but it isn't absolutely necessary to misuse packetbb in that way, and I would hope this particular discussion could be taken as a case in point. Furthermore, I wish you would not use such extreme language. We had submitted SMURF a while back, and were told that we were not doing that stuff in [manet] at that time. Your name was on that document. I didn't press the point, and then NHDP happened, presumably influenced by packetbb which was itself undergoing steady evolution. SMURF uses MPRs (a known technique) and the INRIA algorithm with which you are very familiar. The fine-tuning has to do with things that need fine-tuning in NHDP also -- like time-outs and so on. Plus we should discuss how much it matters about whether two-hop link information has to be segregated into symmetric vs. non-symmetric varieties. But if it matters, it will be a simple matter to use the algorithm already presented in NHDP to do this work. I really think there is a middle ground here and see no reason that we cannot step into it. > > That, to me, is an easy choice to make. I second 100% what Justin said > in his email: Solidarity is good, sometimes... > >> Discussions about a totally different packet format designed around >> specific >> protocol requirements with little flexibility are in my opinion not that >> helpful. > I guess flexibility is in the eye of the beholder. Adding 20 kg to a soldier's backpack may increase flexibility at the price of endurance. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 14 16:50:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL3KB-0001le-Vj; Tue, 14 Aug 2007 16:49:12 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IL3K9-0001iH-Fj for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 16:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL3K9-0001g5-5a for manet@ietf.org; Tue, 14 Aug 2007 16:49:09 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL3K7-0005w6-BL for manet@ietf.org; Tue, 14 Aug 2007 16:49:09 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7EKmemb029402; Tue, 14 Aug 2007 23:49:04 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 23:48:58 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 15:48:56 -0500 Received: from [172.18.141.139] ([172.18.141.139]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 15:48:55 -0500 Message-ID: <46C21536.8040308@nokia.com> Date: Tue, 14 Aug 2007 13:48:54 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Justin Dean Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08 References: <200708141431.l7EEUtl3023575@s2.itd.nrl.navy.mil> In-Reply-To: <200708141431.l7EEUtl3023575@s2.itd.nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2007 20:48:55.0907 (UTC) FILETIME=[87E9BB30:01C7DEB4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: manet@ietf.org 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 Justin, Your argument can be drawn to extremes that would, for instance, require all TLVs to have exactly the same structure. But I know you did not mean that. As a practical matter, though, it seems to me that what you are really asking for is to have available a toolkit for protocol processing that is at the same time sufficient for getting the work done but not too large to fit in the cabinet. I am suggesting that relaxing the ordering mandate does not substantially increase the footprint of the toolkit. I reckon we could both write the code in a minute or so that allows the inclusion of a boolean flag parameter to the TLV parsing subroutine. Regards, Charlie P. ext Justin Dean wrote: > The reason I say protocols can not make ordering requirements on their own > is for an envisioned system where two protocols are using the same packetbb > "code engine". This would save duplicate packets and become more efficent > than both protocols opperating seperatly. If the first of these protocols > requires ordering but the 2nd does not the first may make the wrong > assumption that the tlv/address is not present when it is just out of order > because the 2nd added some out of order tlv/address. Actually nhdp/olsr > nhdp/smf are an example of this and they would break if nhdp requires > ordering but olsr does not. > > Justin > > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > Sent: Monday, August 13, 2007 4:00 PM > To: ext Justin Dean > Cc: manet@ietf.org > Subject: Re: [manet] Re: draft-ietf-manet-packetbb-08 > > > Hello Justin, > > I have some follow-on comments on the points you raise. > > ext Justin Dean wrote: > >> The major advantage I can see is with 1 is being able to read a lack >> of a tlv by the ordering without having to read the entire tlv block. >> If multiple protocols in an integrated system are only looking for >> specific tlv types they can more quickly decide if the information is >> > there or not, i.e. > >> if I am looking for page 10 and I get to page 11 then its not there no >> need to read the next 100 pages. It is not NEEDED, however, protocols >> based off of packetbb MUST know if this constraint is true for all >> packetbb packets or this advantage is lost. >> >> > Actually, I think that any protocol using packetbb should make any such > necessary constraints in the individual protocol document. Since other > protocols may not have the same requirement, it is not needed to impose the > constraints globally for all time. Perhaps, if it is needed to expedite the > information lookup as you are suggesting, packetbb could recommend that > individual protocol specifications include a relevant section near the front > of the document (just after the protocol applicability statement?). > >> The advantages of 4 are a little bit less clear but the same principle >> applies. And if the ordering is not stated here for both 1 and 4 no >> later document can later state ordering constraints and have it work >> for all packetbb protocols. >> >> > But any individual protocol can do so, and that is, I think, all that is > needed. > >> With 3 this was introduced to avoid confusion on which value should be >> > used. > >> I personally would be ok with wording this closer to 2 in mandating >> that the tlv definitions explicitly disallow or allow. >> > I am also O.K. with wording closer to (2). > > Regards, > Charlie P. > > PS. I should have included the four cases, I guess... so here they are. > >> 1 TLVs in the same TLV block MUST be sorted in non-descending tlv- >> fulltype order. >> >> 2 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. >> >> 3 Two or more TLVs with the same tlv-fulltype in the same address block >> TLV block MUST NOT be associated with the same copy of an address >> (i.e. they must not have overlapping index ranges). >> >> 4 TLVs with the same tlv-fulltype associated with the same address >> block MUST be sorted in ascending index-start order. >> > > > > _______________________________________________ > 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 Aug 14 17:10: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 1IL3d1-0006Sj-OF; Tue, 14 Aug 2007 17:08:39 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IL3d0-0006SY-6v for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 17:08:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL3cz-0006SQ-S1 for manet@ietf.org; Tue, 14 Aug 2007 17:08:37 -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 1IL3cz-0001Zq-A2 for manet@ietf.org; Tue, 14 Aug 2007 17:08:37 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7EL7rON013079; Wed, 15 Aug 2007 00:08:34 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 00:08:12 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 16:08:07 -0500 Received: from [172.18.141.139] ([172.18.141.139]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 16:08:06 -0500 Message-ID: <46C219B5.4050606@nokia.com> Date: Tue, 14 Aug 2007 14:08:05 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Ian Chakeres Subject: Re: [manet] PacketBB Recent Discussion #2 - Ordering TLVs References: <374005f30708140526u12378857q5e632236c28e8f7e@mail.gmail.com> In-Reply-To: <374005f30708140526u12378857q5e632236c28e8f7e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2007 21:08:06.0602 (UTC) FILETIME=[35C7DAA0:01C7DEB7] X-Nokia-AV: Clean X-Spam-Score: 0.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 Hello Ian, Some people claim that there is no need for the restriction, and the authors claim that they have gotten input to support the restriction. I myself do not see that it is needed for OLSR, or DYMO, or for NHDP or SMURF. The arguments from implementability stem from claimed code explosion in the body of the parser, but I don't automatically see why and we do not have the details to study. I would have thought it was as complicated as having a flag. Given that no existing use cases support the need for ordering, I think that it should not be mandated. Plus, if we imagine that new protocol revisions might insert new TLV blocks into the message body, then there is a renumbering problem which would suggest leaving wide spaces within the existing tlv-type numbering spaces. That really is a known bad and messy problem. Or else we are saying that no such future revisions will be encouraged, or that we'll have a lot of redundant tlv-type allocation. Regards, Charlie P. ext Ian Chakeres wrote: > I'd like to focus the discussion around ordering of TLV types within TLV blocks. > > If you have a good reason why we should not consistently order TLVs > within a TLV block, please email it to the list. Please provide a > clear use case that shows why ordering the TLVs is bad. > > Thanks. > Ian Chakeres > > Note: I would like to quickly finish any remaining PacketBB discussion > and move this document forward. > > > _______________________________________________ > 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 Aug 14 17:56: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 1IL4LF-0005gW-Py; Tue, 14 Aug 2007 17:54:21 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IL4LC-0005gR-J0 for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 17:54:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL4LC-0005gI-80 for manet@ietf.org; Tue, 14 Aug 2007 17:54:18 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL4LB-0002b1-Ln for manet@ietf.org; Tue, 14 Aug 2007 17:54:18 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l7ELsAFF015021; Tue, 14 Aug 2007 17:54:15 -0400 (EDT) Message-Id: <200708142154.l7ELsAFF015021@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007081417541509685 ; Tue, 14 Aug 2007 17:54:15 -0400 From: "Justin Dean" To: "'Charles E. Perkins'" , "'ext Ian Chakeres'" Subject: RE: [manet] PacketBB Recent Discussion #2 - Ordering TLVs Date: Tue, 14 Aug 2007 17:58:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acfet2DuNPg4eK1ZTkSWjJCM1PLzvQABN+gw In-Reply-To: <46C219B5.4050606@nokia.com> X-Spam-Score: 1.5 (+) 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 A couple of comments before I head out. The packet sizes of olsrv2/nhdp are generally smaller than those in olsrv1. At least that was the case during the olsrv2 interop in Japan. Furthermore the most gains happen with the larger packet sizes as more aggregation will occur. An IPv6 olsr v1 packet is going grow much faster with than an OLSRv2 packet when using packetbb. I would very much like to stress this point of growth in size as even with the example discussed earlier the growth at the higher end is the same (1 byte per address) for both examples. Having a bit for ordering would allow for both behaviors but at this point I don't see where it would be cleanly added. I do however think the suggestion has some merit if there is a bit someplace which makes sense. Two examples of a need for the restriction or at the very least clarity in packetbb are: A fragmentation type tlv which would need to be first to allow the parser to correctly read/store the message in one pass. Piggybacking protocols in one packetbb packet if any protocols mandated ordering and the others did not it would break the one mandating ordering. Justin -----Original Message----- From: Charles E. Perkins [mailto:charles.perkins@nokia.com] Sent: Tuesday, August 14, 2007 5:08 PM To: ext Ian Chakeres Cc: manet Subject: Re: [manet] PacketBB Recent Discussion #2 - Ordering TLVs Hello Ian, Some people claim that there is no need for the restriction, and the authors claim that they have gotten input to support the restriction. I myself do not see that it is needed for OLSR, or DYMO, or for NHDP or SMURF. The arguments from implementability stem from claimed code explosion in the body of the parser, but I don't automatically see why and we do not have the details to study. I would have thought it was as complicated as having a flag. Given that no existing use cases support the need for ordering, I think that it should not be mandated. Plus, if we imagine that new protocol revisions might insert new TLV blocks into the message body, then there is a renumbering problem which would suggest leaving wide spaces within the existing tlv-type numbering spaces. That really is a known bad and messy problem. Or else we are saying that no such future revisions will be encouraged, or that we'll have a lot of redundant tlv-type allocation. Regards, Charlie P. ext Ian Chakeres wrote: > I'd like to focus the discussion around ordering of TLV types within TLV blocks. > > If you have a good reason why we should not consistently order TLVs > within a TLV block, please email it to the list. Please provide a > clear use case that shows why ordering the TLVs is bad. > > Thanks. > Ian Chakeres > > Note: I would like to quickly finish any remaining PacketBB discussion > and move this document forward. > > > _______________________________________________ > 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 Tue Aug 14 23:06: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 1IL9Bo-0006iR-ES; Tue, 14 Aug 2007 23:04:56 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IL9Bn-0006iG-6M for manet-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 23:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL9Bl-0006i7-2y for manet@ietf.org; Tue, 14 Aug 2007 23:04:53 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL9Bj-00078Q-PR for manet@ietf.org; Tue, 14 Aug 2007 23:04:53 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 14 Aug 2007 20:04:51 -0700 X-IronPort-AV: i="4.19,262,1183359600"; d="scan'208"; a="513596948:sNHT46490944" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7F34p39018097; Tue, 14 Aug 2007 20:04:51 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7F34oF4017360; Wed, 15 Aug 2007 03:04:50 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 23:04:50 -0400 Received: from [10.81.246.165] ([10.81.246.165]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 23:04:49 -0400 Message-ID: <46C26D32.1090404@cisco.com> Date: Tue, 14 Aug 2007 23:04:18 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] PacketBB Recent Discussion #2 - Ordering TLVs References: <374005f30708140526u12378857q5e632236c28e8f7e@mail.gmail.com> In-Reply-To: <374005f30708140526u12378857q5e632236c28e8f7e@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Aug 2007 03:04:49.0832 (UTC) FILETIME=[0B199280:01C7DEE9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1102; t=1187147091; x=1188011091; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bberry@cisco.com; z=From:=20Bo=20Berry=20 |Subject:=20Re=3A=20[manet]=20PacketBB=20Recent=20Discussion=20#2=20-=20O rdering=20TLVs |Sender:=20; bh=PGXNXhgXg6fhPmbIJ/yfx4W7LZkl81Qys/r4sUYF9+w=; b=f2AS2EF5Y6y7IgsQwhrtfxy5UJIcprqfScBBBuw3zW/KvTg5QPmv7iMwefBhtmViMULu5vk9 4Ma9hV4dIVHXk3Uuq9f2ypkOncA7YwTcDpaQ91u6TXbqG57QQiKz1/VcAC2OA62Fd+yeUJy/DP h/n4pft6bXE54WtJ8I7EvRUc4=; Authentication-Results: sj-dkim-1; header.From=bberry@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: As the protocol evolves, TLVs will be added and need to be inserted or worst the list reordered. TLV values can also be obsoleted, leaving holes in the ordered list of values or forcing another reorder. Over time the number of TLVs will change. In this same time products will be running different versions of the protocol with supporting parsers. I think the requirement for an ordered list of TLVs in this context will be problematic. Thanks for moderating. -Bo Ian Chakeres wrote: > I'd like to focus the discussion around ordering of TLV types within TLV blocks. > > If you have a good reason why we should not consistently order TLVs > within a TLV block, please email it to the list. Please provide a > clear use case that shows why ordering the TLVs is bad. > > Thanks. > Ian Chakeres > > Note: I would like to quickly finish any remaining PacketBB discussion > and move this document forward. > > > _______________________________________________ > 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 Aug 15 03:46:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILDYm-00040r-JO; Wed, 15 Aug 2007 03:44:56 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILDYk-00040m-So for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 03:44:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILDYk-00040d-3w for manet@ietf.org; Wed, 15 Aug 2007 03:44:54 -0400 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILDYj-0001gD-3R for manet@ietf.org; Wed, 15 Aug 2007 03:44:53 -0400 Received: from hpsmtp-eml05.kpnxchange.com ([213.75.38.105]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 09:44:51 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Aug 2007 09:44:51 +0200 From: "Teco Boot" To: "'Bo Berry'" Subject: RE: [manet] RE: Comments on Metric TLV Date: Wed, 15 Aug 2007 09:45:17 +0200 Message-ID: <000801c7df10$399252b0$0202a8c0@Teco> 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.3138 Thread-Index: Acfej4gxZBgO3/fmTm+3DJL4KIjoRwAdxIQg In-Reply-To: <46C1D6EE.8050203@cisco.com> X-OriginalArrivalTime: 15 Aug 2007 07:44:51.0260 (UTC) FILETIME=[298807C0:01C7DF10] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: "'Dearlove, Christopher \(UK\)'" , Philippe.Jacquet@inria.fr, manet@ietf.org, '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. Some text removed to reduce size. Thanks, Teco > >> Lowest value is 1, followed by 2, 3, ... 950.272, 983.040, 1.015.808. > >> Linear from 1 to 17, hereafter the exponential characteristic starts. > >> I my day-to-day work I deal with extremely low-speed radio links and > >> high-speed wired links; think of a data radio with shared 1kbps over > > the > >> radio interface and 1Gbps over the cable interface. Others could come > > up > >> with more extreme ends of the spectrum. > >> I evaluated using (16 + a) * 2^(b+4) - 255. Values are 1, 17, 33, 49, > >> ... > >> 15.204.097, 15.728.385, 16.252.673. Although the range is enlarged > > with > >> factor 16, I think it doesn't bring that much value. > > I suggest that the metrics/cost design not be based upon low > speed (kbps) radio links. The metrics/cost should also handle > high speed (gbps) radio links. The design should also be > capable of distinguishing the difference in the two extremes > of radio links when comparing link costs and route selections. > Perhaps we should define the cost value as a full 16-bit > unsigned range (or 32-bit) so all cost factors > can be fairly compared. If this is done then the constraints > on the equations can be relaxed. For example, using one type > of radio may require a different set of equations than the > ones listed here. With the standard cost range the computed > costs can be fairly compared to other costs. I don't think we > want to corner the radios into these equations. > [Teco] Dimensionless metrics/cost was implicitly assumed. My example provides a real world requirement, discussing the need for a 10^6 range or more. Linear 16-bits (like OSPF) are not sufficient here. 24-bit linear fits much better. I suggest using the mechanism defined by IS-IS extensions for Traffic Engineering (RFC3784). Path calculation is performed with 32-bit unsigned integers. This provides support for 255 hops with 24-bit link costs. Also interesting concept in RFC3784: TLV for a default metric. > >>>>> We don't need this in OLSRv2 - we have the concept of a LOST link. > > If the node is to send a Do_Not_use metric, it is better that the > metric not be sent. [Teco] Not sending a metric leads to using the default metric. RFC3784 also defines the Do_Not_Use metric. Why not adopt OSPF and ISIS behavior in OLSR? > If the node is battery powered, it may be useful to send > an indication that its battery is running low and traffic > should be routed around this node if possible. This indication > would be applied to all links (radio and wired) on the > reporting node. [Teco] Why not adding a large value on the metric? SPF path selection will use an alternative path, if available. Using metrics is much more smoothly than a battery-low bit. > > FYI: inputs for outbound metric: #retransmits, load, transmit power, > > battery, pricing, policy, etc. > > If we define a lengthy set of metrics how would [Teco] (response on fragment of a comment) The inputs are for generating a dimensionless metric value. Inputs shall not be signaled to other routers. > > Node A would be able set the inbound and outbound metric fully > > independent > > of what node B is doing. > > The question is not having a valid requirement, but how to support this > > without high overhead and without any overhead if some implementation > > does > > not use this function. > > This capability is dependent upon the radio. Some > may be able to provide such metrics and others not. > We need to be sure to allow for this. [Teco] The requirement is supporting radios that provide the information. I think cross-layering will be evolving in coming years. Let's prepare for this. > I think we should clarify the meaning of metric vs cost. As written > I find the use of the terms some what confusing. Once we clarify > the use of these two terms a lot of the discussion above becomes > easier. I see a uniform cost being computed from the metric. [Teco] I think the context was clear; we discuss uniform costs or metrics (without a dimension). ISIS uses term metric; costs have to do with money. OSPF uses term cost and metric, "The cost of a route is described by a single dimensionless metric." The term metrics could also be used for certain link characteristics (with or without a dimension), like you did in PPPoE with Credit Flow and Metrics (RFC4938). You are right the terms are somewhat confusing. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Aug 15 04:28: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 1ILEDH-0001aA-BY; Wed, 15 Aug 2007 04:26:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILEDE-0001a1-LJ for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 04:26:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILEDE-0001Zt-BU for manet@ietf.org; Wed, 15 Aug 2007 04:26:44 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILEDC-0005uq-S1 for manet@ietf.org; Wed, 15 Aug 2007 04:26: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 l7F8QfDj018624 for ; Wed, 15 Aug 2007 09:26:41 +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 l7F8QfZJ021641 for ; Wed, 15 Aug 2007 09:26:41 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 15 Aug 2007 09:26:40 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 09:26:40 +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: Comments on Metric TLV Date: Wed, 15 Aug 2007 09:26:39 +0100 Message-ID: In-Reply-To: <46C1D6EE.8050203@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] RE: Comments on Metric TLV thread-index: Acfej5QS4Nls47+dTrGa8+uMzGy/FQAhh/1w References: <001b01c7de6d$bd06f5e0$b800800a@Teco> <46C1D6EE.8050203@cisco.com> From: "Dearlove, Christopher \(UK\)" To: "Bo Berry" X-OriginalArrivalTime: 15 Aug 2007 08:26:40.0622 (UTC) FILETIME=[013A48E0:01C7DF16] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Philippe.Jacquet@inria.fr, manet@ietf.org, 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 > I suggest that the metrics/cost design not be based upon low > speed (kbps) radio links. I don't see the relevance of this comment at all. Where is there any suggestion that the design is so based? ******************************************************************** 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 Aug 15 04:36:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILEL9-0007Hd-2n; Wed, 15 Aug 2007 04:34:55 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILEL6-0007HY-GZ for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 04:34:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILEL6-0007HQ-5l for manet@ietf.org; Wed, 15 Aug 2007 04:34:52 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILEL5-00033s-MR for manet@ietf.org; Wed, 15 Aug 2007 04:34:52 -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 l7F8YoHY025665 for ; Wed, 15 Aug 2007 09:34:50 +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 l7F8YoLA027780 for ; Wed, 15 Aug 2007 09:34:50 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 15 Aug 2007 09:34:50 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 09:34:49 +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] PacketBB Recent Discussion #2 - Ordering TLVs Date: Wed, 15 Aug 2007 09:34:48 +0100 Message-ID: In-Reply-To: <46C219B5.4050606@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] PacketBB Recent Discussion #2 - Ordering TLVs thread-index: Acfet02lB7V7DjoPRdKRnFCBAKwuZgAX6p9g References: <374005f30708140526u12378857q5e632236c28e8f7e@mail.gmail.com> <46C219B5.4050606@nokia.com> From: "Dearlove, Christopher \(UK\)" To: "Charles E. Perkins" , "ext Ian Chakeres" X-OriginalArrivalTime: 15 Aug 2007 08:34:50.0113 (UTC) FILETIME=[24FCAF10:01C7DF17] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 > Given that no existing use cases support the need for > ordering, I think that it should not be mandated. It has been repeatedly pointed out that ordering allows trivial confirmation of non-duplication, and non-duplication allows cleaner protocol specification and message processing. ******************************************************************** 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 Aug 15 04:40:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILEOO-0007wY-JD; Wed, 15 Aug 2007 04:38:16 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILEON-0007wS-2e for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 04:38:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILEOM-0007wK-PO for manet@ietf.org; Wed, 15 Aug 2007 04:38:14 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILEOL-00069l-Du for manet@ietf.org; Wed, 15 Aug 2007 04:38: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 l7F8cBZ4027438 for ; Wed, 15 Aug 2007 09:38:11 +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 l7F8cBZ6030193 for ; Wed, 15 Aug 2007 09:38:11 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 15 Aug 2007 09:38:11 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 09:38:11 +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] PacketBB Recent Discussion #2 - Ordering TLVs Date: Wed, 15 Aug 2007 09:38:10 +0100 Message-ID: In-Reply-To: <46C26D32.1090404@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] PacketBB Recent Discussion #2 - Ordering TLVs thread-index: Acfe6ReGCXA4OlFhRPaiOM2RP3L5VwALiGLg References: <374005f30708140526u12378857q5e632236c28e8f7e@mail.gmail.com> <46C26D32.1090404@cisco.com> From: "Dearlove, Christopher \(UK\)" To: "Bo Berry" , "manet" X-OriginalArrivalTime: 15 Aug 2007 08:38:11.0600 (UTC) FILETIME=[9D152900:01C7DF17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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's no problem in ordering no matter how TLVs are defined. They are ordered according to their numbers in this actual TLV block being transmitted. Easy as that. If numbering changes so that meanings change you've broken compatibility anyway. This is no sort of argument at all. =20 -----Original Message----- From: Bo Berry [mailto:bberry@cisco.com]=20 Sent: 15 August 2007 04:04 To: Ian Chakeres Cc: manet Subject: Re: [manet] PacketBB Recent Discussion #2 - Ordering TLVs *** 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 Ian: As the protocol evolves, TLVs will be added and need to be inserted or worst the list reordered. TLV values can also be obsoleted, leaving holes in the ordered list of values or forcing another reorder. Over time the number of TLVs will change. In this same time products will be running different versions of the protocol with supporting parsers. I think the requirement for an ordered list of TLVs in this context will be problematic. Thanks for moderating. -Bo Ian Chakeres wrote: > I'd like to focus the discussion around ordering of TLV types within TLV blocks. >=20 > If you have a good reason why we should not consistently order TLVs > within a TLV block, please email it to the list. Please provide a > clear use case that shows why ordering the TLVs is bad. >=20 > Thanks. > Ian Chakeres >=20 > Note: I would like to quickly finish any remaining PacketBB discussion > and move this document forward. >=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 ******************************************************************** 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 Aug 15 04:43: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 1ILERs-0003Gr-NK; Wed, 15 Aug 2007 04:41:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILERq-0003GQ-E8 for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 04:41:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILERo-0003Fu-Eo for manet@ietf.org; Wed, 15 Aug 2007 04:41:48 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILERm-0003Hj-JR for manet@ietf.org; Wed, 15 Aug 2007 04:41:47 -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 l7F8fjOf029335 for ; Wed, 15 Aug 2007 09:41:45 +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 l7F8fjbO032717 for ; Wed, 15 Aug 2007 09:41:45 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 15 Aug 2007 09:41:45 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 09:41:44 +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: Comments on Metric TLV Date: Wed, 15 Aug 2007 09:41:44 +0100 Message-ID: In-Reply-To: <000801c7df10$399252b0$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] RE: Comments on Metric TLV thread-index: Acfej4gxZBgO3/fmTm+3DJL4KIjoRwAdxIQgAARDpGA= References: <46C1D6EE.8050203@cisco.com> <000801c7df10$399252b0$0202a8c0@Teco> From: "Dearlove, Christopher \(UK\)" To: "Teco Boot" , "Bo Berry" X-OriginalArrivalTime: 15 Aug 2007 08:41:45.0196 (UTC) FILETIME=[1C6552C0:01C7DF18] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Philippe.Jacquet@inria.fr, manet@ietf.org, 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 > I suggest using the mechanism defined by IS-IS extensions for Traffic > Engineering (RFC3784). Path calculation is performed with 32-bit unsigned > integers. While I have been accused of ignoring packet size issues, it's only when I think there's a real reason for it. But here I don't see the need for 4 octets. This suggests metrics can be measured to a fantastic degree of precision for a wireless network. ******************************************************************** 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 Aug 15 04:45:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILETa-0006O5-AD; Wed, 15 Aug 2007 04:43:38 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILETY-0006NP-4a for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 04:43:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILETX-0006NH-R0 for manet@ietf.org; Wed, 15 Aug 2007 04:43:35 -0400 Received: from hpsmtp-eml12.kpnxchange.com ([213.75.38.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILETW-0006HC-Dv for manet@ietf.org; Wed, 15 Aug 2007 04:43:35 -0400 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 10:43:32 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 10:43:30 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" Date: Wed, 15 Aug 2007 10:43:57 +0200 Message-ID: <000c01c7df18$6b735c40$0202a8c0@Teco> 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.3138 Thread-Index: AcfeW4nCBsZ3N+OLRdWzAchSY7qFQAAAQLGgAAI6pyAAAl5kAAAozg7g In-Reply-To: X-OriginalArrivalTime: 15 Aug 2007 08:43:31.0038 (UTC) FILETIME=[5B7B87E0:01C7DF18] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Philippe.Jacquet@inria.fr, manet@ietf.org, 'Thomas Clausen' Subject: [manet] RE: Comments on Metric TLV 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 Some more comments on metric encoding. Teco. > > >>> While I've been on the other end of efficiency arguments, I really > > >>> don't want to use more than one octet for a metric, and certainly > > >>> not four. I want to just use a single, exponent/mantissa, octet. > > >>> (Note that I'm not committed to the 4/4 bit split - in fact in the > > >>> motivating timetlv we're about to change to 5/3. I think 4/4 is > > >>> better here, but an argument for 5/3 or 3/5 could be made I'm > sure.) I checked 5/3 and 3/5. Using 5/3, metric value 172 already overflows a 24-bit field. Value 236 overflows a 32-bit field. It requires 48-bit integers for path calculation. 3/5 provides a very limited range, 32 - 8064. On using (16+a)*2^b, (1+a/16)*2^b or (16+a)*2^b-15: I prefer encoding that supports real world use cases and real world examples. Examples in dearlove-olsrv2-metric use link metrics 1, 2, 3 and 4. Only (1+a/16)*2^b and (16+a)*2^b-15 support these values. Real world use cases are discussed on ML, there is a need for support for a broad range of links. IMHO a 10^6 range is needed, I ever prefer more. (16+a)*2^(b+4)-255 provides the broadest range, 1 to 16.252.673, but it does not support the real world examples. When looking at all options, I think (16+a)*2^b-15 is absolutely a candidate. Maybe not 100% exponential, but it fits real world needs much better than (16+a)*2^b. Can you argument against -15? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Aug 15 04:47:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILEVv-0008Fv-In; Wed, 15 Aug 2007 04:46:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILEVu-00088h-4t for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 04:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILEVt-00087x-R1 for manet@ietf.org; Wed, 15 Aug 2007 04:46:01 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILEVt-0006L3-4s for manet@ietf.org; Wed, 15 Aug 2007 04:46:01 -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 l7F8jxNo001716 for ; Wed, 15 Aug 2007 09:45:59 +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 l7F8jxAn003562 for ; Wed, 15 Aug 2007 09:45:59 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 15 Aug 2007 09:45:58 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 09:45:58 +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] PacketBB Recent Discussion #1 - Allowing multipleTLVsofthe same type Date: Wed, 15 Aug 2007 09:45:57 +0100 Message-ID: In-Reply-To: <200708141617.l7EGH0Do029391@s2.itd.nrl.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] PacketBB Recent Discussion #1 - Allowing multipleTLVsofthe same type thread-index: AcfebeKJTfcvCZ4dTWmg+qKZsRQObgAFiF9gAACTuiAAAVsusAAjLCCw References: <200708141617.l7EGH0Do029391@s2.itd.nrl.navy.mil> From: "Dearlove, Christopher \(UK\)" To: "Justin Dean" , "Stan Ratliff \(sratliff\)" , "Ian Chakeres" , "manet" X-OriginalArrivalTime: 15 Aug 2007 08:45:58.0622 (UTC) FILETIME=[B3730FE0:01C7DF18] 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 > Please correct me if I am wrong but I don't see a big issue with allow > derived protocols to decide on this behavior. I'm afraid I do, for reasons already stated, particularly the complex inter-relation of the protocols using packetbb, and the appropriateness of generic packetbb parsing code. ******************************************************************** 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 Aug 15 05:07: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 1ILEoi-0004d1-02; Wed, 15 Aug 2007 05:05:28 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILEog-0004cs-0I for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 05:05:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILEof-0004ci-IY for manet@ietf.org; Wed, 15 Aug 2007 05:05:25 -0400 Received: from hpsmtp-eml18.kpnxchange.com ([213.75.38.118]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILEoe-0004Uk-OY for manet@ietf.org; Wed, 15 Aug 2007 05:05:25 -0400 Received: from hpsmtp-eml06.kpnxchange.com ([213.75.38.106]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 11:05:23 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 11:05:23 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" Subject: RE: [manet] RE: Comments on Metric TLV Date: Wed, 15 Aug 2007 11:05:48 +0200 Message-ID: <000e01c7df1b$7990eb00$0202a8c0@Teco> 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.3138 Thread-Index: Acfej4gxZBgO3/fmTm+3DJL4KIjoRwAdxIQgAARDpGAAAHszsA== In-Reply-To: X-OriginalArrivalTime: 15 Aug 2007 09:05:23.0324 (UTC) FILETIME=[69AA7BC0:01C7DF1B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: manet@ietf.org 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 did absolutely not intend sending the 32-bits here, I used wording "path calculation". I suggested a 24-bits linear metric TLV, for those who can live with the increased packet sizes and need the "fantastic degree of precision". Don't forget it also extents the range to 1 - 16777215. Usage of this TLV would be optional, the compressed exponential metric would be used were packet size is an issue. What is the point? Teco > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Sent: woensdag 15 augustus 2007 10:42 > To: Teco Boot; Bo Berry > Cc: Philippe.Jacquet@inria.fr; manet@ietf.org; Thomas Clausen > Subject: RE: [manet] RE: Comments on Metric TLV > > > > I suggest using the mechanism defined by IS-IS extensions for Traffic > > Engineering (RFC3784). Path calculation is performed with 32-bit > unsigned > > integers. > > While I have been accused of ignoring packet size issues, > it's only when I think there's a real reason for it. But > here I don't see the need for 4 octets. This suggests > metrics can be measured to a fantastic degree of precision > for a wireless network. > > ******************************************************************** > 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 Aug 15 05:10: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 1ILEs1-0005G5-EU; Wed, 15 Aug 2007 05:08:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILErz-0005Fz-EJ for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 05:08:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILErz-0005Fr-4B for manet@ietf.org; Wed, 15 Aug 2007 05:08: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 1ILErx-0007T9-KS for manet@ietf.org; Wed, 15 Aug 2007 05:08:51 -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 l7F98m3R001562 for ; Wed, 15 Aug 2007 10:08:48 +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 l7F98mtO003615 for ; Wed, 15 Aug 2007 10:08:48 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 15 Aug 2007 10:08:47 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 10:08:47 +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: Comments on Metric TLV Date: Wed, 15 Aug 2007 10:08:46 +0100 Message-ID: In-Reply-To: <000e01c7df1b$7990eb00$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] RE: Comments on Metric TLV thread-index: Acfej4gxZBgO3/fmTm+3DJL4KIjoRwAdxIQgAARDpGAAAHszsAAAfZxQ References: <000e01c7df1b$7990eb00$0202a8c0@Teco> From: "Dearlove, Christopher \(UK\)" To: "Teco Boot" X-OriginalArrivalTime: 15 Aug 2007 09:08:47.0343 (UTC) FILETIME=[E3454FF0:01C7DF1B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: manet@ietf.org 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 > What is the point? Of what? I think you are saying that you suggest a 24 bit "flat" representation as an option, while I'm saying that I think this is unnecessary as the precision is not going to be real, and there's quite enough complexity without adding stuff we don't need. ******************************************************************** 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 Aug 15 05:18: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 1ILEzB-0005bI-9A; Wed, 15 Aug 2007 05:16:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILEz8-0005CQ-FR for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 05:16:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILEz7-00053q-Rh for manet@ietf.org; Wed, 15 Aug 2007 05:16:13 -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 1ILEz7-0007dh-Cf for manet@ietf.org; Wed, 15 Aug 2007 05:16:13 -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 l7F9GCiP007343 for ; Wed, 15 Aug 2007 10:16:12 +0100 (BST) Received: from glkas0106.GREENLNK.NET (glkas0106.greenlnk.net [141.245.68.243]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l7F9GCcq026892 for ; Wed, 15 Aug 2007 10:16:12 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0106.GREENLNK.NET with InterScan Message Security Suite; Wed, 15 Aug 2007 10:16:12 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 10:16:11 +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, 15 Aug 2007 10:16:11 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Using metrics (was RE: Comments on Metric TLV) thread-index: Acfej4gxZBgO3/fmTm+3DJL4KIjoRwAdxIQgAARDpGAAAHszsAAAfZxQAAA4TOA= References: <000e01c7df1b$7990eb00$0202a8c0@Teco> From: "Dearlove, Christopher \(UK\)" To: "Dearlove, Christopher \(UK\)" , "Teco Boot" X-OriginalArrivalTime: 15 Aug 2007 09:16:11.0733 (UTC) FILETIME=[EC25D850:01C7DF1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: manet@ietf.org Subject: [manet] Using metrics (was RE: Comments on Metric TLV) 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 Actually to follow myself up, the details of how exactly metric values are encoded is a detail. Unless we actually go ahead and use them, all the discussion of those details is wasted time, and I'll stop doing so now. =20 Can I urge that discussion focus on whether this (using metrics, not defining a metric TLV) is what we should do, or not. -----Original Message----- From: Dearlove, Christopher (UK)=20 Sent: 15 August 2007 10:09 To: Teco Boot Cc: manet@ietf.org Subject: RE: [manet] RE: Comments on Metric TLV *** 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 > What is the point? Of what? I think you are saying that you suggest a 24 bit "flat" representation as an option, while I'm saying that I think this is unnecessary as the precision is not going to be real, and there's quite enough complexity without adding stuff we don't need. ******************************************************************** 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 Aug 15 08:55: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 1ILINC-000086-VS; Wed, 15 Aug 2007 08:53:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILINA-0008TJ-R2 for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 08:53:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILINA-0008QC-A2 for manet@ietf.org; Wed, 15 Aug 2007 08:53:16 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILIN8-0003tw-Ip for manet@ietf.org; Wed, 15 Aug 2007 08:53:15 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Aug 2007 05:53:11 -0700 X-IronPort-AV: i="4.19,266,1183359600"; d="scan'208"; a="513692118:sNHT50664322" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7FCrBen003951; Wed, 15 Aug 2007 05:53:11 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7FCqoVx010936; Wed, 15 Aug 2007 12:53:07 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 08:52:56 -0400 Received: from [10.81.246.132] ([10.81.246.132]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 08:52:55 -0400 Message-ID: <46C2F726.7050706@cisco.com> Date: Wed, 15 Aug 2007 08:52:54 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Teco Boot Subject: Re: [manet] RE: Comments on Metric TLV References: <000801c7df10$399252b0$0202a8c0@Teco> In-Reply-To: <000801c7df10$399252b0$0202a8c0@Teco> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Aug 2007 12:52:56.0026 (UTC) FILETIME=[334F7BA0:01C7DF3B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2648; t=1187182391; x=1188046391; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bberry@cisco.com; z=From:=20Bo=20Berry=20 |Subject:=20Re=3A=20[manet]=20RE=3A=20Comments=20on=20Metric=20TLV |Sender:=20; bh=L6O+HtOiWzuPZK7oGjLc0UolUzyRJsYwzKf5YrLD2RY=; b=FjWAMsa4rn9d9oHNj2G98hnIbBHT83QHAVQgrxTyKlBeRYcNu8kCZJPk0b5qVWhBVdlWiBbV 5cx3P1TpugqElrhOAYEtLRyxcGrnh6TeGYNM3ztffN4uSVr7sXC1lKNy; Authentication-Results: sj-dkim-4; header.From=bberry@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: "'Dearlove, Christopher \(UK\)'" , Philippe.Jacquet@inria.fr, manet@ietf.org, '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 in-line -B Teco Boot wrote: > Comments inline. > Some text removed to reduce size. > Thanks, Teco > ...cut... > >>>>>>> We don't need this in OLSRv2 - we have the concept of a LOST link. >> If the node is to send a Do_Not_use metric, it is better that the >> metric not be sent. > [Teco] > Not sending a metric leads to using the default metric. > RFC3784 also defines the Do_Not_Use metric. Why not adopt OSPF and ISIS > behavior in OLSR? If we support not sending a metric as you noted, then why is a DNU value needed? Do you envision the receiver taking different actions? > >> If the node is battery powered, it may be useful to send >> an indication that its battery is running low and traffic >> should be routed around this node if possible. This indication >> would be applied to all links (radio and wired) on the >> reporting node. > [Teco] > Why not adding a large value on the metric? SPF path selection will use an > alternative path, if available. Using metrics is much more smoothly than a > battery-low bit. But how large of a metric should the node report? In the case of battery life, I think it would be useful to very the metric as battery life decreases from 100% to 0%? A percentage would also support the battery recharge (100%). ...cut... > >> I think we should clarify the meaning of metric vs cost. As written >> I find the use of the terms some what confusing. Once we clarify >> the use of these two terms a lot of the discussion above becomes >> easier. I see a uniform cost being computed from the metric. > [Teco] > I think the context was clear; we discuss uniform costs or metrics (without > a dimension). > ISIS uses term metric; costs have to do with money. > OSPF uses term cost and metric, "The cost of a route is described by a > single dimensionless metric." > > The term metrics could also be used for certain link characteristics (with > or without a dimension), like you did in PPPoE with Credit Flow and Metrics > (RFC4938). You are right the terms are somewhat confusing. I think of cost as a uniform value used in route selection. I think of metric, radio or otherwise, as a value used to compute a cost value that is used to update the associated route. Metrics exist in a variety of formats and ranges. Metrics have various scopes. A metric may be tied to a specific link and another metric may be nodal which applies to all links on that node. For example, battery life would be nodal, represented as 0-100%, effecting all links. Data rates are link oriented and may be expressed in kbps, mbps, gbps, etc. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Aug 15 09:00: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 1ILISo-0003rm-4G; Wed, 15 Aug 2007 08:59:06 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILISm-0003rf-9h for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 08:59:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILISl-0003rX-WD for manet@ietf.org; Wed, 15 Aug 2007 08:59:04 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILISk-000424-GH for manet@ietf.org; Wed, 15 Aug 2007 08:59:03 -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 l7FCx1lx000558 for ; Wed, 15 Aug 2007 13:59:01 +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 l7FCx0oF014499 for ; Wed, 15 Aug 2007 13:59:00 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 15 Aug 2007 13:59:00 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 13:58:59 +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: Comments on Metric TLV Date: Wed, 15 Aug 2007 13:58:58 +0100 Message-ID: In-Reply-To: <46C2F726.7050706@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] RE: Comments on Metric TLV thread-index: AcffO01oJuZrOyAkQbuZhKMlNy1GdwAADCIQ References: <000801c7df10$399252b0$0202a8c0@Teco> <46C2F726.7050706@cisco.com> From: "Dearlove, Christopher \(UK\)" To: "Bo Berry" , "Teco Boot" X-OriginalArrivalTime: 15 Aug 2007 12:58:59.0733 (UTC) FILETIME=[0C18C450:01C7DF3C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Philippe.Jacquet@inria.fr, manet@ietf.org, 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 > But how large of a metric should the node report? In the case of > battery life, I think it would be useful to very the metric as > battery life decreases from 100% to 0%? A percentage would also > support the battery recharge (100%). Please read draft-dearlove-olsrv2-metrics-00. We're not talking about real world measurements like battery life, we're talking about dimensionless metrics used for route selection. In your terminology a cost value (but use of metric in this sense is also common). ******************************************************************** 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 Aug 15 09:47: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 1ILJBi-0006RZ-5Y; Wed, 15 Aug 2007 09:45:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILJBh-0006RN-Ag for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 09:45:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILJBh-0006Q2-0A for manet@ietf.org; Wed, 15 Aug 2007 09:45:29 -0400 Received: from hpsmtp-eml15.kpnxchange.com ([213.75.38.115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILJBf-0005HY-Cc for manet@ietf.org; Wed, 15 Aug 2007 09:45:28 -0400 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 15:45:24 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 15:45:23 +0200 From: "Teco Boot" To: "'Bo Berry'" Subject: RE: [manet] RE: Comments on Metric TLV Date: Wed, 15 Aug 2007 15:45:48 +0200 Message-ID: <001701c7df42$96e516a0$0202a8c0@Teco> 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.3138 Thread-Index: AcffO1EYDoE9qqa0RFyj4a8DxDPXJwAArZLw In-Reply-To: <46C2F726.7050706@cisco.com> X-OriginalArrivalTime: 15 Aug 2007 13:45:23.0719 (UTC) FILETIME=[877B5170:01C7DF42] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "'Dearlove, Christopher \(UK\)'" , Philippe.Jacquet@inria.fr, manet@ietf.org, '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 > >>>>>>> We don't need this in OLSRv2 - we have the concept of a LOST link. > >> If the node is to send a Do_Not_use metric, it is better that the > >> metric not be sent. > > [Teco] > > Not sending a metric leads to using the default metric. > > RFC3784 also defines the Do_Not_Use metric. Why not adopt OSPF and ISIS > > behavior in OLSR? > > If we support not sending a metric as you noted, then why is > a DNU value needed? Do you envision the receiver taking different > actions? > [Teco] DNU and Default are very, very different. Not sending a metric and using a default reduces packet size. Sending DNU could be used in some cases to signal the link is out-of-service, for whatever reason. Protocols could have another mechanism to signal this condition; Chris noted NHDP has the L_lost status for links. I'll have to check how this condition is signaled in the MANET. I checked ietf-manet-olsrv2-04, but I can't find it. > >> If the node is battery powered, it may be useful to send > >> an indication that its battery is running low and traffic > >> should be routed around this node if possible. This indication > >> would be applied to all links (radio and wired) on the > >> reporting node. > > [Teco] > > Why not adding a large value on the metric? SPF path selection will use > an > > alternative path, if available. Using metrics is much more smoothly than > a > > battery-low bit. > > But how large of a metric should the node report? In the case of > battery life, I think it would be useful to very the metric as > battery life decreases from 100% to 0%? A percentage would also > support the battery recharge (100%). [Teco] Specifying an algorithm for dimensionless metric generation is not needed. Guidelines are fine, for the metric value itself and for dampening and hysteresis. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Aug 15 10:59:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILKJ2-0006ZZ-SN; Wed, 15 Aug 2007 10:57:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILKJ1-0006Z9-4Z for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 10:57:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILKJ0-0006Yp-Pe for manet@ietf.org; Wed, 15 Aug 2007 10:57:06 -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 1ILKIv-0005lX-5a for manet@ietf.org; Wed, 15 Aug 2007 10:57: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 l7FEuxE2014124 for ; Wed, 15 Aug 2007 15:56:59 +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 l7FEuxl0019952 for ; Wed, 15 Aug 2007 15:56:59 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 15 Aug 2007 15:56:59 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 15:56:59 +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: Comments on Metric TLV Date: Wed, 15 Aug 2007 15:56:58 +0100 Message-ID: In-Reply-To: <001701c7df42$96e516a0$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] RE: Comments on Metric TLV thread-index: AcffO1EYDoE9qqa0RFyj4a8DxDPXJwAArZLwAAOQZ9A= References: <46C2F726.7050706@cisco.com> <001701c7df42$96e516a0$0202a8c0@Teco> From: "Dearlove, Christopher \(UK\)" To: "Teco Boot" , "Bo Berry" X-OriginalArrivalTime: 15 Aug 2007 14:56:59.0213 (UTC) FILETIME=[87CBAFD0:01C7DF4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Philippe.Jacquet@inria.fr, manet@ietf.org, 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 > Chris noted > NHDP has the L_lost status for links. I'll have to check how this condition > is signaled in the MANET. I checked ietf-manet-olsrv2-04, but I can't find > it. It's in draft-ietf-manet-nhdp-04 (or whatever we are up to). It's really L_status =3D=3D LOST, of which L_lost =3D=3D true is one case. ******************************************************************** 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 Aug 15 12:17: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 1ILLWZ-0006L9-JM; Wed, 15 Aug 2007 12:15:11 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILLWX-0006Gy-8f for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 12:15:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILLWW-0006Eh-SK for manet@ietf.org; Wed, 15 Aug 2007 12:15:08 -0400 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILLWW-00084T-7L for manet@ietf.org; Wed, 15 Aug 2007 12:15:08 -0400 Received: from dnab423210.stanford.edu ([171.66.50.16]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1ILLWU-0003R3-Iu; Wed, 15 Aug 2007 09:15:07 -0700 In-Reply-To: References: <001b01c7de6d$bd06f5e0$b800800a@Teco> <46C1D6EE.8050203@cisco.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: Philip Levis Subject: Re: [manet] RE: Comments on Metric TLV Date: Wed, 15 Aug 2007 08:54:07 -0700 To: "Dearlove, Christopher ((UK))" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: 3134a374f3853b94094f80bd9e2b84a0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: manet@ietf.org, Philippe.Jacquet@inria.fr, 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 On Aug 15, 2007, at 1:26 AM, Dearlove, Christopher ((UK)) wrote: > >> I suggest that the metrics/cost design not be based upon low >> speed (kbps) radio links. > > I don't see the relevance of this comment at all. Where is there > any suggestion that the design is so based? For the record, sensor network routing protocols, which use low speed radio links, typically have either 8-bit (e.g., Route, MintRoute) or 16-bit (e.g., MultihopLQI/MLQI, CTP) cost values. Note that these protocols typically assume a single link layer, and the cost metric is expected transmissions (ETX) or some variant thereof (e.g., MLQI is a transformation of soft chip decision values). In the case of CTP [1], the 16 bits are a fixed point number with 0.01 precision, thereby allowing ETX values in the range of 0-655.35. We thought 8 bits insufficient because there are existing low-power mesh deployments that are 48 hops long[2], and with 8 bits this would greatly limit the metric precision. That being said -- and with respect to the metrics draft -- I'm wary of exponential metrics, or, indeed, any variable-precision metric. For example, let's say the metric encodes ETT (expected time of transmission) and you have a gigabit mesh with a kilobit uplink (e.g., a disaster response network designed primarily for local communication but also has a channel to the outside world). The ETT of the kilobit uplink is going to overwhelm the ETT within the gigabit network, and so it may be that the gigabit values are lost due to their being less significant bits. While in some ways this makes sense, it will raise problems for routing protocols as it could lead to loops in min-cost routing algorithms (they can't tell if its 1, 2, or 34 gigabit hops). Let me qualify the above concern with the fact that I haven't read all of the drafts out there very closely, and so in the current protocols and intended uses, this may not be an issue. But going forward it may be, and so some protocols may end up placing limitations on what cost metrics they will use (e.g., Foo MUST NOT use an exponential cost metric encoding). So this doesn't mean that there shouldn't be exponential metrics, but rather that some protocols may preclude their use. Phil [1] TEP 123: The Collection Tree Protocol (CTP): http:// www.tinyos.net/tinyos-2.x/doc/html/tep123.html [2] Kim, Pakzad, Culler, Demmel, Fenves, Glaser, Turon, "Health Monitoring of Civil Infrastructures Using Wireless Sensor Networks", IPSN07. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Aug 15 12:25: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 1ILLeS-0003NJ-VF; Wed, 15 Aug 2007 12:23:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILLeR-0003NE-1h for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 12:23:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILLeQ-0003N6-OQ for manet@ietf.org; Wed, 15 Aug 2007 12:23:18 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILLeP-0001iX-9o for manet@ietf.org; Wed, 15 Aug 2007 12:23:18 -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 l7FGNFlv027113 for ; Wed, 15 Aug 2007 17:23:16 +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 l7FGNF3I027037 for ; Wed, 15 Aug 2007 17:23:15 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 15 Aug 2007 17:23:15 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 17:23:15 +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: Comments on Metric TLV Date: Wed, 15 Aug 2007 17:23:14 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] RE: Comments on Metric TLV thread-index: AcffV399Z4cQRgt0Rr257efpbN08gAAACd2w References: <001b01c7de6d$bd06f5e0$b800800a@Teco><46C1D6EE.8050203@cisco.com> From: "Dearlove, Christopher \(UK\)" To: "Philip Levis" X-OriginalArrivalTime: 15 Aug 2007 16:23:15.0654 (UTC) FILETIME=[9531E660:01C7DF58] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Philippe.Jacquet@inria.fr, manet@ietf.org, 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 > While in some ways this =20 > makes sense, it will raise problems for routing protocols as it could > lead to loops in min-cost routing algorithms (they can't tell if its =20 > 1, 2, or 34 gigabit hops). Note that we explicitly note that you can, and must, accumulate in full precision in 20-something (I don't have the draft - I'm referring to draft-dearlove-olsrv2-metrics-00 - in front of me) bits without transmitting 20-something bits, and hence there is no looping issue on this front, and no loss of precision - so you can still differentiate between e.g. one high cost link plus two low cost links and one same high cost link and one low cost link. ******************************************************************** 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 Aug 15 12:33: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 1ILLmt-0002qi-U6; Wed, 15 Aug 2007 12:32:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILLms-0002qb-Ir for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 12:32:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILLms-0002qT-8B for manet@ietf.org; Wed, 15 Aug 2007 12:32:02 -0400 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILLmr-0008VR-Qj for manet@ietf.org; Wed, 15 Aug 2007 12:32:02 -0400 Received: from dnab423210.stanford.edu ([171.66.50.16]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1ILLmp-0004RR-QR; Wed, 15 Aug 2007 09:32:01 -0700 In-Reply-To: References: <001b01c7de6d$bd06f5e0$b800800a@Teco><46C1D6EE.8050203@cisco.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: Philip Levis Subject: Re: [manet] RE: Comments on Metric TLV Date: Wed, 15 Aug 2007 09:32:01 -0700 To: "Dearlove, Christopher ((UK))" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Philippe.Jacquet@inria.fr, manet@ietf.org, 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 On Aug 15, 2007, at 9:23 AM, Dearlove, Christopher ((UK)) wrote: > >> While in some ways this >> makes sense, it will raise problems for routing protocols as it could > >> lead to loops in min-cost routing algorithms (they can't tell if its >> 1, 2, or 34 gigabit hops). > > Note that we explicitly note that you can, and must, accumulate in > full > precision in 20-something (I don't have the draft - I'm referring to > draft-dearlove-olsrv2-metrics-00 - in front of me) bits without > transmitting 20-something bits, and hence there is no looping > issue on this front, and no loss of precision - so you can still > differentiate between e.g. one high cost link plus two low cost links > and one same high cost link and one low cost link. Perhaps I'm missing something here: are the metrics in draft-dean- manet-metriclv-00 intended to only be link metrics, and not route metrics? For example, the text reads: "Node metrics SHOULD represent cost values associated with routing though that node." What you're saying makes sense for link metrics that accumulate to a higher precision node metric. But if the node metric is 8 bits... Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Aug 15 15:16: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 1ILOJv-00022f-Q1; Wed, 15 Aug 2007 15:14:19 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILOJu-0001zZ-CX for manet-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 15:14:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILOJu-0001zR-2B for manet@ietf.org; Wed, 15 Aug 2007 15:14:18 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILOJt-0004nf-Fd for manet@ietf.org; Wed, 15 Aug 2007 15:14:17 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l7FJDxKZ029777 for ; Wed, 15 Aug 2007 15:14:14 -0400 (EDT) Message-Id: <200708151914.l7FJDxKZ029777@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007081515141413991 for ; Wed, 15 Aug 2007 15:14:14 -0400 From: "Justin Dean" To: Subject: RE: [manet] RE: Comments on Metric TLV Date: Wed, 15 Aug 2007 15:18:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcffWeH+ONXtlO6wQbqzZ7jXLHhi/AAD7rIg In-Reply-To: X-Spam-Score: 1.5 (+) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 A few comments on draft-dean-manet-metriclv-00. First I would like to thank everyone for reading and commenting on the document. The discussion about the need for larger precision metrics with uniform precision across the value space is something I am going to try and fit into the next version of the draft 24 bit link metrics and new 32 bit path metrics. I was also playing around with the (16 + a) * 2^b - 15 method of representation as it seems to better match the scale of the flat representation (no fractions). The only issue I don't like with it is the fewer number of linear representations 1-15 to 1-31, but only representing integer values maps better with the linear representation and the trade off may be worth it. The inclusion of a node metric is because of the difference in wireless to wired medium. It may make more sense to transmit a value of say estimated contention on a per node basis rather than a link basis. I am also working on cleaning up the definitions of "cost value" and "metric" used in the dean metric draft. Cost value is the abstract or defined unit to be conveyed. A metric in my draft is just the container and numerical representation of the cost value. Justin -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: Wednesday, August 15, 2007 12:32 PM To: Dearlove, Christopher ((UK)) Cc: Philippe.Jacquet@inria.fr; manet@ietf.org; Thomas Clausen Subject: Re: [manet] RE: Comments on Metric TLV On Aug 15, 2007, at 9:23 AM, Dearlove, Christopher ((UK)) wrote: > >> While in some ways this >> makes sense, it will raise problems for routing protocols as it could > >> lead to loops in min-cost routing algorithms (they can't tell if its >> 1, 2, or 34 gigabit hops). > > Note that we explicitly note that you can, and must, accumulate in > full precision in 20-something (I don't have the draft - I'm referring > to draft-dearlove-olsrv2-metrics-00 - in front of me) bits without > transmitting 20-something bits, and hence there is no looping issue on > this front, and no loss of precision - so you can still differentiate > between e.g. one high cost link plus two low cost links and one same > high cost link and one low cost link. Perhaps I'm missing something here: are the metrics in draft-dean- manet-metriclv-00 intended to only be link metrics, and not route metrics? For example, the text reads: "Node metrics SHOULD represent cost values associated with routing though that node." What you're saying makes sense for link metrics that accumulate to a higher precision node metric. But if the node metric is 8 bits... Phil _______________________________________________ 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 Thu Aug 16 04:45: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 1ILax0-00023v-3m; Thu, 16 Aug 2007 04:43:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILawx-0001tN-Rx for manet-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 04:43:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILawx-0001sm-EI for manet@ietf.org; Thu, 16 Aug 2007 04:43:27 -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 1ILawv-00072G-UW for manet@ietf.org; Thu, 16 Aug 2007 04:43:27 -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 l7G8hO9u010376 for ; Thu, 16 Aug 2007 09:43:24 +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 l7G8hNBm025018 for ; Thu, 16 Aug 2007 09:43:24 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 16 Aug 2007 09:43:22 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.99]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 09:43:22 +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: Comments on Metric TLV Date: Thu, 16 Aug 2007 09:43:21 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] RE: Comments on Metric TLV thread-index: AcffWeVQ9iRTm4lsRN2F46r4XBUG9AAhzpKw References: <001b01c7de6d$bd06f5e0$b800800a@Teco><46C1D6EE.8050203@cisco.com> From: "Dearlove, Christopher \(UK\)" To: "Philip Levis" X-OriginalArrivalTime: 16 Aug 2007 08:43:22.0494 (UTC) FILETIME=[80CD91E0:01C7DFE1] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Philippe.Jacquet@inria.fr, manet@ietf.org, 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 As I noted, I'm referring to draft-dearlove-olsrv2-metrics-00, which doesn't have node metrics. But the node metric you refer to is, I believe, an additional term to be accumulated, not the accumulator. -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: 15 August 2007 17:32 To: Dearlove, Christopher (UK) Cc: Philippe.Jacquet@inria.fr; manet@ietf.org; Thomas Clausen Subject: Re: [manet] RE: Comments on Metric TLV *** 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 On Aug 15, 2007, at 9:23 AM, Dearlove, Christopher ((UK)) wrote: > >> While in some ways this >> makes sense, it will raise problems for routing protocols as it could > >> lead to loops in min-cost routing algorithms (they can't tell if its >> 1, 2, or 34 gigabit hops). > > Note that we explicitly note that you can, and must, accumulate in =20 > full > precision in 20-something (I don't have the draft - I'm referring to > draft-dearlove-olsrv2-metrics-00 - in front of me) bits without > transmitting 20-something bits, and hence there is no looping > issue on this front, and no loss of precision - so you can still > differentiate between e.g. one high cost link plus two low cost links > and one same high cost link and one low cost link. Perhaps I'm missing something here: are the metrics in draft-dean-=20 manet-metriclv-00 intended to only be link metrics, and not route =20 metrics? For example, the text reads: "Node metrics SHOULD represent cost values associated with routing =20 though that node." What you're saying makes sense for link metrics that accumulate to a =20 higher precision node metric. But if the node metric is 8 bits... Phil _______________________________________________ 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 Thu Aug 16 08:13: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 1ILeCS-0007Tm-22; Thu, 16 Aug 2007 08:11:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILeCQ-0007Tg-UB for manet-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 08:11:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILeCQ-0007TY-KW for manet@ietf.org; Thu, 16 Aug 2007 08:11:38 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILeCP-000581-7P for manet@ietf.org; Thu, 16 Aug 2007 08:11:38 -0400 Received: by nf-out-0910.google.com with SMTP id c10so118004nfd for ; Thu, 16 Aug 2007 05:11:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=D4jtpLLZcjfLM7MCuJtC9J+nPEYuf8wGmT3GSDKihG6eUcySoGLFDYwbf/daNkcLA5R8vjhl9PuXGn5oy0XJ1Mghe1KOmZz2S+49muybJsJnV0UubYu9CMtZ/w4mM3qdwmPjY0B4FxoTunZ3Q8ANmyQd5eE98u48iP5BtBGZfGM= 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=ndB0avfXwvnootYORRPQrWYzkXhRKVDYHZbP8xLNMZ2rIxHWxWVvxvPud6XZH1C9x3jCbsNUFV4zj+zw8SCQGaf4hRvYJAfV/vEG4sX7x20lK521fHc1ivXb3y1H3hTIm/qme6OwJbXOVB/vCQbVK0FZqqmBKxHf4xpMB1fZZBI= Received: by 10.78.146.11 with SMTP id t11mr583083hud.1187266295365; Thu, 16 Aug 2007 05:11:35 -0700 (PDT) Received: by 10.78.53.8 with HTTP; Thu, 16 Aug 2007 05:11:35 -0700 (PDT) Message-ID: <374005f30708160511t3ab2132ci607da1a778cb6f7e@mail.gmail.com> Date: Thu, 16 Aug 2007 17:41:35 +0530 From: "Ian Chakeres" To: "Christoph Sommer" Subject: Re: [manet] draft-ietf-manet-dymo-10 open questions In-Reply-To: <46B2DBE9.1000407@informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46B2DBE9.1000407@informatik.uni-erlangen.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: manet@ietf.org 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 Christoph, thank you very much for the detailed comments. I've integrated them into the xml and they will be included in the next ID we submit. Thanks. Ian Chakeres On 8/3/07, Christoph Sommer wrote: > Hello All, > > Updating a draft-06-implementation of DYMO to draft version 10, some > points were not immediately clear to me after reading the latest > specification. > > In some cases, DYMO implementations interpreting the draft differently > could lead to interoperability issues. But while most of the time, one > alternative way of implementing DYMO is clearly superior to the other, I > list these points anyway, as I might just have missed something. > > > > 4.2.2. Routing Messages (RM) - RREQ & RREP > > Other than entries associated with "TargetNode" or "OrigNode", both of > which have been defined in the section on terminology (as well as > "AdditionalNode", which is explained later on), the list of elements > associates entries with a generic entity called "Node". > If this intended as a superclass of TargetNode and OrigNode, > Node.AddTLV.Dist is a duplicate of TargetNode.AddTLV.Dist. If it is not, > OrigNode.AddTLV.Dist seems to be missing. > In any case, it would probably make things much clearer, if the complete > set of properties was given for each of TargetNode, OrigNode and > AdditionalNode. > > Also, the list seems to be missing IP.SourceAddress, which is referenced > in "5.2.2. Creating or Updating a Route Table Entry with New Routing", > "5.5.2. Updating Route Lifetimes During Packet Forwarding" and "5.5.4. > RERR Processing". > > IP.SourceAddress is also missing in the list of section "4.2.3. Route > Error (RERR)". > > > 5.1.4. Actions After OwnSeqNum Loss > > Should a node assume OwnSeqNum loss when starting up for the very first > time? > > > 5.3.1. RREQ Creation > > The statement "If this DYMO router is performing route discovery on > behalf of an attached node ... it MUST advertise it's address and prefix > that contain the source address.", leaves it a bit unclear exactly which > node's address and prefix have to be advertised. > > > 5.3.2. RREP Creation > > This section should probably not be relevant to the case described in > "5.3.3. Intermediate DYMO Router RREP Creation", because the requirement > "If ... TargetNode.SeqNum from the RM is less than OwnSeqNum, OwnSeqNum > SHOULD be incremented" doesn't seem to make much sense if the TargetNode > is not ThisNode. > > Also, in the sentence "If ... TargetNode.SeqNum from the RM is less than > OwnSeqNum, OwnSeqNum SHOULD be incremented", the comparison of SeqNums > here should probably also be based on signed integer arithmetics, not > just a comparison. Section "5.3.4. RM Processing" also uses "greater > than" for comparison where signed integer arithmetics should make more > sense. > > It might prove beneficial to only once state that SeqNums are to be > compared by the special method given later on, then only use the terms > "newer" and "older" instead of "greater than" and "smaller than" in the > remaining text. > > > 5.3.3. Intermediate DYMO Router RREP Creation > > The draft seems to be unclear about whether to increment OwnSeqNum when > creating intermediate RREPs. > > > 5.3.4. RM Processing > > In this section, it is allowed that to a RREQ "ThisNode responds with a > RREQ flood (a RREQ addressed to oneself) or a RREP to the RREQ > OrigNode". If a node always chooses to start an RREQ flood rather than > send a RREP, couldn't intermediate node RREP creation completely stop > the RREQ flood from ever reaching the node that is searching for a route? > > > 5.5.4. RERR Processing > > Setting a Route.Broken flag here does not seem to trigger the > ROUTE_DELETE timer to be started, which seems to be required in other > cases. > > Also, it might be beneficial to update UnreachableNode.SeqNum with more > recent information during processing. The original RERR sender will > often not know UnreachableNode.SeqNum because it deleted the route, > while a node relaying the RERR will probably still know about the SeqNum. > > Also, after processing, MsgHdr.HopLimit should probably be decreased. > This section does not seem to require this, but checks MsgHdr.HopLimit > anyway. > > > Regards, > > Christoph > > > _______________________________________________ > 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 Thu Aug 16 13:08: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 1ILint-0000rE-Ok; Thu, 16 Aug 2007 13:06:37 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILinr-0000lE-Dg for manet-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 13:06:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILinr-0000j0-2h for manet@ietf.org; Thu, 16 Aug 2007 13:06:35 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILinp-0004z1-TX for manet@ietf.org; Thu, 16 Aug 2007 13:06:35 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l7GH6ViU015932 for ; Thu, 16 Aug 2007 13:06:33 -0400 (EDT) Message-Id: <200708161706.l7GH6ViU015932@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007081613063318270 for ; Thu, 16 Aug 2007 13:06:33 -0400 From: "Justin Dean" To: Date: Thu, 16 Aug 2007 13:11:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfgKG8Qp6YejzLITp2fAXiMlUEb7Q== X-Spam-Score: 2.8 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [manet] (no subject) 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 >> [Justin] >> The inclusion of a node metric is because of the difference in >> wireless to wired medium. It may make more sense to transmit a value >> of say estimated contention on a per node basis rather than a link basis. >[Teco] >Can you come up with the advantage over incrementing the costs of all links of the node? >I can think of more efficient signaling, especially in case of high number of neighbors. But if this is the only >one, I am not convinced it is needed. If certain link cost values are symmetric but node costs are different between nodes. An example being max link throughput and node contention. Its may be more efficient to send symmetric link costs from of the nodes and have each node send a node cost, than to have every node send outbound link metrics. #L+#N compared to 2*#L. The number of links will be greater than the number of nodes in almost all cases. The node representation is a better fit for certain cost values in a manet, as a wireless network has different properties than a wired network where orthogonal links metrics generally fit well. >>[Justin] >> I was also playing around with the (16 + a) * 2^b - 15 method of >> representation as it seems to better match the scale of the flat >> representation (no fractions). The only issue I don't like with it is >> the fewer number of linear representations 1-15 to 1-31, but only >> representing integer values maps better with the linear representation >> and the trade off may be worth it. >[Teco] >What do you mean with fewer number of linear representations? >Subtracting does not influence linear behavior. >Compressed values 0-16 result in uncompressed values 1-17 (-15) or 16-32 (no -15). >Am I missing something? The current cost value equation of (1 + a/16) * 2^b allows for 1-32 integer representation. (16 + a) *2^b -15 allows for 1-17.(you are correct there) The -15 is not what is causing this but the removal of the /16. The tradeoff is higher maximum cost value representation. 63488 to 1015793 for the old to new respectively. On a side note I would really like to hear from manet implementers, the ranges of values you have tended to use for experimental metric based routing. Justin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Aug 17 03:34:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILwJk-0004Vb-HH; Fri, 17 Aug 2007 03:32:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ILwJi-0004VW-Si for manet-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 03:32:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILwJf-0004VK-3S for manet@ietf.org; Fri, 17 Aug 2007 03:32:19 -0400 Received: from hpsmtp-eml16.kpnxchange.com ([213.75.38.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILwJe-0006bl-5Q for manet@ietf.org; Fri, 17 Aug 2007 03:32:18 -0400 Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml16.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 09:32:16 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 09:32:15 +0200 From: "Teco Boot" To: "'Justin Dean'" Subject: Re: [manet] RE: Comments on Metric TLV Date: Fri, 17 Aug 2007 09:32:41 +0200 Message-ID: <000901c7e0a0$cbed3c60$0202a8c0@Teco> 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.3138 Thread-Index: AcfgKG8Qp6YejzLITp2fAXiMlUEb7QAbfGAg In-Reply-To: <200708161706.l7GH6ViU015932@s2.itd.nrl.navy.mil> X-OriginalArrivalTime: 17 Aug 2007 07:32:15.0963 (UTC) FILETIME=[BC2A5AB0:01C7E0A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: manet@ietf.org 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 > >>[Justin] > >> I was also playing around with the (16 + a) * 2^b - 15 method of > >> representation as it seems to better match the scale of the flat > >> representation (no fractions). The only issue I don't like with it is > >> the fewer number of linear representations 1-15 to 1-31, but only > >> representing integer values maps better with the linear representation > >> and the trade off may be worth it. > > >[Teco] > >What do you mean with fewer number of linear representations? > >Subtracting does not influence linear behavior. > >Compressed values 0-16 result in uncompressed values 1-17 (-15) or 16-32 > (no -15). > >Am I missing something? > > The current cost value equation of (1 + a/16) * 2^b allows for 1-32 > integer representation. [Teco] Use integers? Chop or rounding? Or use 4 fractional bits as defined in dearlove-olsrv2-metrics? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Aug 17 10:52:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM39j-0006cs-14; Fri, 17 Aug 2007 10:50:31 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IM39g-0006Hp-IO for manet-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 10:50:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM39g-0006E1-4e for manet@ietf.org; Fri, 17 Aug 2007 10:50:28 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM39f-0001Li-LV for manet@ietf.org; Fri, 17 Aug 2007 10:50:28 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l7HEoQBw026377; Fri, 17 Aug 2007 10:50:26 -0400 (EDT) Message-Id: <200708171450.l7HEoQBw026377@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007081710502522441 ; Fri, 17 Aug 2007 10:50:25 -0400 From: "Justin Dean" To: "'Teco Boot'" Subject: RE: [manet] RE: Comments on Metric TLV Date: Fri, 17 Aug 2007 10:55:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfgKG8Qp6YejzLITp2fAXiMlUEb7QAbfGAgABHC3kA= In-Reply-To: <000901c7e0a0$cbed3c60$0202a8c0@Teco> X-Spam-Score: 1.5 (+) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: manet@ietf.org 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 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl] Sent: Friday, August 17, 2007 3:33 AM To: 'Justin Dean' >Cc: manet@ietf.org >Subject: Re: [manet] RE: Comments on Metric TLV >> >>[Justin] >> >> I was also playing around with the (16 + a) * 2^b - 15 method of >> >>representation as it seems to better match the scale of the flat >> >>representation (no fractions). The only issue I don't like with it >> >>is the fewer number of linear representations 1-15 to 1-31, but >> >>only representing integer values maps better with the linear >> >>representation and the trade off may be worth it. >> >> >[Teco] >> >What do you mean with fewer number of linear representations? >> >Subtracting does not influence linear behavior. >> >Compressed values 0-16 result in uncompressed values 1-17 (-15) or >> >16-32 >> (no -15). >> >Am I missing something? >> >> The current cost value equation of (1 + a/16) * 2^b allows for 1-32 >> integer representation. >[Teco] >Use integers? Chop or rounding? Or use 4 fractional bits as defined in dearlove-olsrv2-metrics? The first 80 values for both equations. As you can see the current equation can represent all integers 1-32. The new one can only represent every integer in the 1-17 range. (16 + a) * 2^b - 15 (1 + a/16) * 2^b 1 1 2 1.0625 3 1.125 4 1.1875 5 1.25 6 1.3125 7 1.375 8 1.4375 9 1.5 10 1.5625 11 1.625 12 1.6875 13 1.75 14 1.8125 15 1.875 16 1.9375 17 2 19 2.125 21 2.25 23 2.375 25 2.5 27 2.625 29 2.75 31 2.875 33 3 35 3.125 37 3.25 39 3.375 41 3.5 43 3.625 45 3.75 47 3.875 49 4 53 4.25 57 4.5 61 4.75 65 5 69 5.25 73 5.5 77 5.75 81 6 85 6.25 89 6.5 93 6.75 97 7 101 7.25 105 7.5 109 7.75 113 8 121 8.5 129 9 137 9.5 145 10 153 10.5 161 11 169 11.5 177 12 185 12.5 193 13 201 13.5 209 14 217 14.5 225 15 233 15.5 241 16 257 17 273 18 289 19 305 20 321 21 337 22 353 23 369 24 385 25 401 26 417 27 433 28 449 29 465 30 481 31 497 32 529 34 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Aug 17 13: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 1IM5Uo-0001KE-2A; Fri, 17 Aug 2007 13:20:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IM5Ul-0001Ji-M6 for manet-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 13:20:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM5Ul-0001JZ-Ca for manet@ietf.org; Fri, 17 Aug 2007 13:20:23 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM5Uj-0003O6-Bj for manet@ietf.org; Fri, 17 Aug 2007 13:20:23 -0400 Received: by nf-out-0910.google.com with SMTP id c10so355451nfd for ; Fri, 17 Aug 2007 10:20:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=hFmIZESPxMYSgUCVMHn3NNeMC+dGik6a7ZqT+Wtl43yTm5hOcMktrnDrQBKJarUvuOvbkrLD8ZBmVUKGyVZIlNMyNJ78kwXit9+fC8qWLUZSWJGZtHiIH0lsTNytOP/LjOL5mV0IhWS6iQ/PYi8A4y2KeCEzoqFRJevkCLv/tf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=TnON1nszkFAfpFG5PxNPs58yB79YCQ1sEOjVyCPR7JH051DeTyNutuHohWrrcYbO6JaqlAxnl4425kDTqfxMeIRXYkN5R9JvdBos/C6rHfdWb9LTRrE/NOn7/GKaeK96VngItIFeEi49lWm5izI4oN6RZCp5nmasDy83e5A8/0Y= Received: by 10.78.201.2 with SMTP id y2mr1101726huf.1187371220257; Fri, 17 Aug 2007 10:20:20 -0700 (PDT) Received: by 10.78.53.8 with HTTP; Fri, 17 Aug 2007 10:20:20 -0700 (PDT) Message-ID: <374005f30708171020td7591aam1b64884b1458c07a@mail.gmail.com> Date: Fri, 17 Aug 2007 22:50:20 +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: 08e48e05374109708c00c6208b534009 Subject: [manet] Distance Maximum Size 8-bits or 16-bits? 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 wanted to ask everyone if they have an opinion about the maximum distance size in DYMO. Do you think 8-bits are sufficient (i.e. 256 values)? Or are 16-bits required? Please let me know your opinion. In the absence of responses I will assume 8-bits are enough. Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 20 06:05: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 1IN46G-0004UK-IK; Mon, 20 Aug 2007 06:03:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IN46E-0004UE-P7 for manet-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 06:03:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN46E-0004U6-Ff for manet@ietf.org; Mon, 20 Aug 2007 06:03:06 -0400 Received: from kuber.nabble.com ([216.139.236.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN46D-0007l7-7p for manet@ietf.org; Mon, 20 Aug 2007 06:03:06 -0400 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IN46C-0006Zw-So for manet@ietf.org; Mon, 20 Aug 2007 03:03:04 -0700 Message-ID: <12233093.post@talk.nabble.com> Date: Mon, 20 Aug 2007 03:03:04 -0700 (PDT) From: Saleemsheikh To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: shm_saleem@yahoo.com X-Spam-Score: 1.4 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [manet] CBRP 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: , Errors-To: manet-bounces@ietf.org Hi, i want to work on CBRP . Please help me in getting source code of CBRP and how to installed it it NS2.29. Any one that have good sources of information in this field plz replay. Waiting of prompt responce,which help me alot. Thanks in advance. Regards, Saleem -- View this message in context: http://www.nabble.com/CBRP-Help-tf4297823.html#a12233093 Sent from the IETF - manet mailing list archive at Nabble.com. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Aug 20 23:07: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 1INK40-0007XC-Uh; Mon, 20 Aug 2007 23:05:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INK3y-0007X2-UE for manet-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 23:05:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INK3y-0007Wu-Jz for manet@ietf.org; Mon, 20 Aug 2007 23:05:50 -0400 Received: from web36809.mail.mud.yahoo.com ([209.191.85.60]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1INK3y-0005ly-1N for manet@ietf.org; Mon, 20 Aug 2007 23:05:50 -0400 Received: (qmail 70823 invoked by uid 60001); 21 Aug 2007 03:05:49 -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=u86jMxT9Ueq1zdmjVlHlqxEPZcXXBMEHGRAdy4rpC7KsARZnBRozuW8a5e06KWWvUBLhHz8wGYBHXNA4UKvYbDsvSTc9jFqfmvol4Zur5RBv2a+S7RLpzd1l+X3JHCz8w16IYZBDMN5mUB/xZtN3Lyi75ey8ZnAeYwYXE9OnKiE=; X-YMail-OSG: rkIBk8cVM1k2AHQ87MTarL7PoOpX_RsIOG6tnAxhCy0__k53NZY5GHNQ_ghSqBo7VRI9Q_ufK_WOZh_IekIqcqfvUMABozx1_4xli2aYTR7A0fBL3ZrwwMIMcDbniQ-- Received: from [84.36.24.189] by web36809.mail.mud.yahoo.com via HTTP; Mon, 20 Aug 2007 20:05:49 PDT Date: Mon, 20 Aug 2007 20:05:49 -0700 (PDT) From: ABDAL-MALEK AL-QOBATY To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <554479.70638.qm@web36809.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [manet] CBRP is needed 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 friends, I need CBRP code. could anyone help me in getting source code of CBRP on GLOMOSIM. Thanks in advance. Regards, Qobaty ____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 21 11:17: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 1INVRq-0007WV-Uj; Tue, 21 Aug 2007 11:15:14 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INVRp-0007Vc-69 for manet-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 11:15:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVRo-0007VU-Sl for manet@ietf.org; Tue, 21 Aug 2007 11:15:12 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INVRn-00058J-Lv for manet@ietf.org; Tue, 21 Aug 2007 11:15:12 -0400 Received: by nf-out-0910.google.com with SMTP id c10so918302nfd for ; Tue, 21 Aug 2007 08:15:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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:content-transfer-encoding:content-disposition:references; b=qrsQJF+2T/rpOyEwWVAfeOnk0LLW75jKv1TAXzzlW1GE5CbnMsIYvcRedkApO4hKbLxQ6TxwYpo+htZY/gEOt3vx+n5R8Vmg+3Ah4W1Kqxtyp8/c0FGG1UlXpfPa0ldabIpBUZ3/lFqPiKxeq2zxEbz8QdB1hDDosehY5eZx6XE= 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:content-transfer-encoding:content-disposition:references; b=JTQbQ9X0fHG38SSEsABWH5GZ5506ChWpiWFadHfX7k47+7jad9366ligsrB1hl2EqMGmprbIKvF3NjIyS3vQElZ+s02MWlGpdBqETJgb9RcGrPhRjqHmGBIu+zMy4brlMqnc8rqOOqg/vUOQjthHffXwFgGPZ+XL6hw9g/iHp6k= Received: by 10.78.171.13 with SMTP id t13mr2856431hue.1187709310262; Tue, 21 Aug 2007 08:15:10 -0700 (PDT) Received: by 10.78.53.8 with HTTP; Tue, 21 Aug 2007 08:15:10 -0700 (PDT) Message-ID: <374005f30708210815u5da12b91ga01f9a2bfc2a8215@mail.gmail.com> Date: Tue, 21 Aug 2007 20:45:10 +0530 From: "Ian Chakeres" To: manet In-Reply-To: <374005f30708140523p2888a643he7f655b5b1d03c7a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30708140523p2888a643he7f655b5b1d03c7a@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [manet] Re: PacketBB Recent Discussion #1 - Allowing multiple TLVs of the same type 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 there has been sufficient discussion on this issue, and that there is a good reason to keep the existing restriction to disallow having multiple TLVs of the same type associated with the same entity in PacketBB. If you have additional use cases, please provide them quickly. Otherwise, I will consider this issue closed. Ian On 8/14/07, Ian Chakeres wrote: > I'd like to focus the discussion around allowing multiple TLVs of the > same type to be associated with the one entity in packetbb. > > If you have a good use case, please provide it and describe why it is useful. > > Ian Chakeres > > Note: I would like to quickly finish any remaining PacketBB discussion > and move this document forward. > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 21 11:17:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVRh-0007MA-VJ; Tue, 21 Aug 2007 11:15:05 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INVRf-0007M2-Tz for manet-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 11:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVRf-0007Lu-KO for manet@ietf.org; Tue, 21 Aug 2007 11:15:03 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INVRe-000581-81 for manet@ietf.org; Tue, 21 Aug 2007 11:15:03 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l7LFExRd021124; Tue, 21 Aug 2007 11:15:00 -0400 (EDT) Message-Id: <200708211515.l7LFExRd021124@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007082111145807672 ; Tue, 21 Aug 2007 11:14:58 -0400 From: "Justin Dean" To: "'Ian Chakeres'" Date: Tue, 21 Aug 2007 11:19:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acfjy+fKkapTcP0OTb6hfHbh+9wcTQAN5WuQ In-Reply-To: <374005f30708210118wf4fa1e3mc8b591567bd37656@mail.gmail.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: manet@ietf.org Subject: [manet] RE: Your comments in packetbb thread about #2 (ordering) 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 thought it would be useful to post this and I agree as I feel there is still some confusion on the benefits of some of the restrictions included in packetbb. I am sorry for the jumbled up presentation of information here, it may be helpful to read bottom up (older message first) Justin Further comments are inline. >Thanks for responding Justin. > >Comments inline. > >On 8/21/07, Justin Dean wrote: >> Sending shouldn't be an issue, at least I haven't heard of any issues >> code wise or otherwise. >> >> The issue is on the receiving end when a protocols expects things to >> be ordered but are not. The other way around works fine, receiving >> ordered but expecting unordered. Your example of NHDP not ordering >> but OLSRv2 requiring ordering means that if OLSRv2 accepted a packet >> it could possibly process things wrong and skip over OLSRv2 tlvs >> because they were out of order with regards to the NHDP tlvs included >> in the message. This makes it an all or nothing kind of thing when mixing protocols. > >Ok, when mixing protocols in common messages - NHDP & OLSRv2. Got it. > >> The skipping over of tlvs is not the only advantage as it helps >> support the limiting of one tlv type per address without having to >> "store" in memory all of the tlvs used so far for a given address >> block. Yes this restriction of one tlv per address may be relaxed but >> many protocols can and will reinsert this requirement (one tlvfulltype >> per address) making implementations work significantly harder to >> verify that messages are syntactically correct with out of order tlv >> types. A third point is special tlvs when NEED to come before other >> tlvs of different types, on example of this being a fragmented message >> tlv type. If the fragment tlv isn't included before other tlv types >> then incorrect parsing/action may have to be reversed when the tlv is located. > >I thought fragmentation was removed? Also, why would a fragmentation TLV need to be first? It was but that doesn't mean that some fragmentation type tlv will never be needed in the future. The TLV might need to be first if the protocol using this fragmentation type tlv only processes the message once the entire message has been received. If the tlv in question was at the end it would make parsing work much harder to determine what the protocol should do with the information contained in the message. If the tlv was always at the start the protocol would be able to store the message after reading the first tlv and be done until the rest of the message showed up. > >Can you give me another case of a TLV needing to come first? > Any tlv which would "change" behavior of the following tlvs. One example would be a delay processing tlv. This could pause the reception of a message after it has been received. Again if it was not in near the top (fragmentation type makes sense to be before this kind of tlv), the entire message would have to be read in order to decide on the correct behavior. >> These issues can not be defined easily on a per protocol specification >> as conflicts will arise. Ordering/not, two requiring tlv to be first >> if included. > >If we do not impose any ordering of TLVs, maybe we will have to include some text in PacketBB saying that protocols cannot expect a particular order for >TLVs. That is, trying to encode protocol specific information using the order of TLVs should be discouraged. > Yes and this IMO reduces the flexibility of packetbb while adding nothing to packetbb. There is an advantage in not having to worry about ordering from a document/IANA perspective but in terms of the protocol functionality nothing is being added. I would also like to point out that it allows for easy verification of one TLV_fulltype per address. Which I am still in favor of keeping after some more thought. The benefits are minimal and the possibility of incorrect processing increases greatly when more than one TLV_fulltype can be on one address. An example is a protocol which rebuilds a packetbb packets and includes it own information into the packet/message. If this implementation only ever expects one TLV_fulltype per address it may just throw out the duplicates when rebuilding the packet. Yes you could say that it shouldn't do this but I would expect MANY implementations would do this as they wouldn't ever use the more than one TLV_fulltype per address "feature". >> Justin >> >> Ps if you think it would be helpful I will post this to the list. > >I think posting to the list would be good, if you've got some good arguments to support ordering. > -----Original Message----- > From: Ian Chakeres [mailto:ian.chakeres@gmail.com] > Sent: Friday, August 17, 2007 10:52 PM > To: Justin Dean > Subject: Re:Your comments in packetbb thread about #2 > > In regard to the overall concept, its still unclear to me why ordering > is so important. I'd like to understand this before I try to think > about protocols doing ordering. > > I'm also confused about the text below, is the problem during sending > or receiving? If a particular implementation/protocol does order > things, this would definitely be consumable by implementations that don't order things. > Therefore, if someone had NHDP and it didn't require ordering and > OLSRv2 which did require ordering, then the NHDP implementations > should have no problem communicating even if one NHDP implementation is ordering tlvs. > > I understand the search problem, but I don't really think that is too > important. > > Ian > > On 8/18/07, Justin Dean wrote: > > I thought I had with this message... > > > > "The reason I say protocols can not make ordering requirements on > > their own is for an envisioned system where two protocols are using > > the same packetbb "code engine". This would save duplicate packets > > and become more efficent than both protocols opperating seperatly. > > If the first of these protocols requires ordering but the 2nd does > > not the first may make the wrong assumption that the tlv/address is > > not present when it is just out of order because the 2nd added some > > out of order tlv/address. Actually nhdp/olsr nhdp/smf are an > > example of this and they would break if nhdp requires ordering but olsr does not. > > > > Justin" > > > > I can reword it and resend to the list if you think that would be helpful. > > > > -----Original Message----- > > From: Ian Chakeres [mailto:ian.chakeres@gmail.com] > > Sent: Friday, August 17, 2007 12:17 PM > > To: Justin Dean > > Subject: Re: [manet] PacketBB Recent Discussion #1 - Allowing > > multipleTLVsofthe same type > > > > > > > > Justin, can you please reply to the other thread about ordering? It > > is still unclear to me why the ordering restriction is so important. > > > > Thanks. > > Ian > > > > On 8/14/07, Justin Dean wrote: > > > Well those were just two attributes which came to mind when > > > writing the example. Having say link type of symmetric/asymmetric > > > as one type and then another orthogonal attribute lets say > > > willingness where most nodes have willingness of default and 2 are > > > never illustrates this with a more reasonable way. They are > > > separate disjoint attributes apples to oranges yes and they should > > > be. There is, however, value in having them associated with the > > > same address block and there is no clear way to order the > > > addresses to allow for aggregation of both sets of information within the same address block. > > > > > > Having said that though the gains given in this example are minimal. > > > In the current case the two fixed size tlvs can advertise all of > > > the first attributes. The second tlv most likely would use a > > > single m-tlv to assign the mixed up attributes to all of the nodes. > > > Relaxing this restraint would allow for some gains in terms of the > > > size of representation of the second attribute in some cases (not > > > all dependant on > > how jumbled the values were). > > > > > > > > > Size of current restrained packetbb = tlvoverhead*3+#addresses. > > > (worst > > > case) Optional size of unrestrained packetbb = > > > tlvoverhead*3+tlvoverhead*#ofdisjointattirbutes. > > > > > > There are many different ways to represent different attributes > > > with the current draft already. And it isn't always clear on what > > > the best encoding scheme is for any given case as it is. Relaxing > > > this restriction would allow another option to try and further > > > reduce overhead but only in the case where the second attribute is > > > mostly the same with small number of different values. I don't > > > often think this will > > be the case. > > > > > > Please correct me if I am wrong but I don't see a big issue with > > > allow derived protocols to decide on this behavior. It doesn't > > > seem like it would break any further protocols by not having it in > > > packetbb. So my question to you guys is, what are the tradeoffs > > > with changing the wording to more closely reflect the issues with > > > regard to multiple message/packet tlvfulltypes? > > > > > > The ordering restriction I am still very strongly in favor of keeping. > > > > > > Justin > > > > > > -----Original Message----- > > > From: Dearlove, Christopher (UK) > > > [mailto:Chris.Dearlove@baesystems.com] > > > Sent: Tuesday, August 14, 2007 11:26 AM > > > To: Stan Ratliff (sratliff); Ian Chakeres; manet > > > Subject: RE: [manet] PacketBB Recent Discussion #1 - Allowing > > > multipleTLVsofthe same type > > > > > > > > > I wouldn't regard that as a real use case - when was the last time > > > you actually wanted to declare a node as bright red? > > > > > > In addition I don't actually think it is a good example. What is > > > the relationship between bright and red? > > > > > > - If bright red is a colour, why not simply encode bright red, > > > bright blue, dark red etc. as separate colours in a single > > > value space? What's the advantage of separating them but also > > > regarding them as the same TLV - one with values including > > > red, blue, bright and dark, a definite apples and oranges > > > sort of value list? > > > > > > - If bright is something quite separate from red, we have two > > > TLVs, and putting them in a single value space makes no sense > > > at all. > > > > > > - If you consider bright to be a modifier of colour, then a > > > natural encoding is to use TLV subtypes, one for colour, > > > one for brightness. Note that you can have two TLVs of the > > > same type but different subtypes (i.e different full types) > > > associated with the same information. > > > > > > > > > -----Original Message----- > > > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] > > > Sent: 14 August 2007 16:03 > > > To: Ian Chakeres; manet > > > Subject: RE: [manet] PacketBB Recent Discussion #1 - Allowing > > > multiple TLVsofthe same type > > > > > > > > > *** WARNING *** > > > > > > This mail has originated outside your organization, either from an > > > external partner or the Global Internet. > > > Keep this in mind if you answer this message. > > > > > > Ian, > > > > > > I think that Justin provided a use case in his email: > > > > > > --------------------Included email---------------------- With 3 > > > this was introduced to avoid confusion on which value should be used. > > > I personally would be ok with wording this closer to 2 in > > > mandating that the tlv definitions explicitly disallow or allow. > > > There are issues with allowing this but there may also be an > > > advantages. A hypothetical example; 10 addresses each of which is > > > either bright or dark and blue or red > > > 1 bright red > > > 2 bright blue > > > 3 bright red > > > 4 bright red > > > 5 bright red > > > 6 dark red > > > 7 dark blue > > > 8 dark red > > > 9 dark red > > > 10 dark red > > > > > > Under the current constraints it would require 1 indexed tlv for > > > bright > > > 1 > > > indexed tlv for dark, then either a m-tlv for all the addressed or > > > a mixture of m-tlvs and indexed tlvs for the color. If constraint > > > of more than one was lifted for the color tlv a m-tlv for all > > > nodes being red and then 2 single tlvs for the 2 blue nodes may > > > reduce > overhead. > > > -------------------End of inclusion---------------------- > > > > > > Regards, > > > Stan > > > > > > > > > >-----Original Message----- > > > >From: Ian Chakeres [mailto:ian.chakeres@gmail.com] > > > >Sent: Tuesday, August 14, 2007 8:23 AM > > > >To: manet > > > >Subject: [manet] PacketBB Recent Discussion #1 - Allowing > > > >multiple TLVs ofthe same type > > > > > > > >I'd like to focus the discussion around allowing multiple TLVs of > > > >the same type to be associated with the one entity in packetbb. > > > > > > > >If you have a good use case, please provide it and describe why > > > >it is useful. > > > > > > > >Ian Chakeres > > > > > > > >Note: I would like to quickly finish any remaining PacketBB > > > >discussion and move this document forward. > > > > > > > > > > > >_______________________________________________ > > > >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 > > > > > > > > > ****************************************************************** > > > ** 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 Tue Aug 21 11:26: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 1INVb5-00075i-QH; Tue, 21 Aug 2007 11:24:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INVb3-0006qk-Q5 for manet-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 11:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVb3-0006nD-Bu for manet@ietf.org; Tue, 21 Aug 2007 11:24:45 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INVb2-0005VB-KB for manet@ietf.org; Tue, 21 Aug 2007 11:24:45 -0400 Received: by nf-out-0910.google.com with SMTP id c10so920713nfd for ; Tue, 21 Aug 2007 08:24:43 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=P+ANBJgNnc6RzT1ZuivJseLU7nGOUlXiwUetnK9ykpRLBNcuhBW/HrYK+u+lWb2ZB4xSTk8sU5fD3Wa2/1QAxVG/8gtwHeP2Sg5tFtWAf8O4PHlFuMv4Nv0lJnNRihfXnSb44YV9Ik3isQZbe6rd+7HcCMlhdzS+4oeI8U48/8E= 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=SFCnUZ8Jwdx1AgjGBSRYD6jraqqeSpxVB7duwcimHFQWYJ7PVIB6tt+KrtjQvAR8y64B8z5jiLczOAiueCKrrHIZ83Xj4BvWxgXxRoozLwIO1Zmx866YyuizhpiXopl+AMM2EVt4jJXLxkxb2DtUq5vEouMXSyFWcSLQcxpu4xw= Received: by 10.78.142.14 with SMTP id p14mr2856323hud.1187709883008; Tue, 21 Aug 2007 08:24:43 -0700 (PDT) Received: by 10.78.53.8 with HTTP; Tue, 21 Aug 2007 08:24:42 -0700 (PDT) Message-ID: <374005f30708210824g2318c772keb69cae6febca503@mail.gmail.com> Date: Tue, 21 Aug 2007 20:54:42 +0530 From: "Ian Chakeres" To: "Justin Dean" In-Reply-To: <200708211515.l7LFExRd021124@s2.itd.nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30708210118wf4fa1e3mc8b591567bd37656@mail.gmail.com> <200708211515.l7LFExRd021124@s2.itd.nrl.navy.mil> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: manet@ietf.org Subject: [manet] Re: Your comments in packetbb thread about #2 (ordering) 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 8/21/07, Justin Dean wrote: > Ian thought it would be useful to post this and I agree as I feel there is > still some confusion on the benefits of some of the restrictions included in > packetbb. I am sorry for the jumbled up presentation of information here, > it may be helpful to read bottom up (older message first) > > Justin > > Further comments are inline. > > >Thanks for responding Justin. > > > >Comments inline. > > > >On 8/21/07, Justin Dean wrote: > >> Sending shouldn't be an issue, at least I haven't heard of any issues > >> code wise or otherwise. > >> > >> The issue is on the receiving end when a protocols expects things to > >> be ordered but are not. The other way around works fine, receiving > >> ordered but expecting unordered. Your example of NHDP not ordering > >> but OLSRv2 requiring ordering means that if OLSRv2 accepted a packet > >> it could possibly process things wrong and skip over OLSRv2 tlvs > >> because they were out of order with regards to the NHDP tlvs included > >> in the message. This makes it an all or nothing kind of thing when > mixing protocols. > > > >Ok, when mixing protocols in common messages - NHDP & OLSRv2. Got it. > > > >> The skipping over of tlvs is not the only advantage as it helps > >> support the limiting of one tlv type per address without having to > >> "store" in memory all of the tlvs used so far for a given address > >> block. Yes this restriction of one tlv per address may be relaxed but > >> many protocols can and will reinsert this requirement (one tlvfulltype > >> per address) making implementations work significantly harder to > >> verify that messages are syntactically correct with out of order tlv > >> types. A third point is special tlvs when NEED to come before other > >> tlvs of different types, on example of this being a fragmented message > >> tlv type. If the fragment tlv isn't included before other tlv types > >> then incorrect parsing/action may have to be reversed when the tlv is > located. > > > >I thought fragmentation was removed? Also, why would a fragmentation TLV > need to be first? > > It was but that doesn't mean that some fragmentation type tlv will never be > needed in the future. The TLV might need to be first if the protocol using > this fragmentation type tlv only processes the message once the entire > message has been received. If the tlv in question was at the end it would > make parsing work much harder to determine what the protocol should do with > the information contained in the message. If the tlv was always at the > start the protocol would be able to store the message after reading the > first tlv and be done until the rest of the message showed up. Why is it harder if it isn't first? > > > >Can you give me another case of a TLV needing to come first? > > > Any tlv which would "change" behavior of the following tlvs. I agree with you so far. > One example > would be a delay processing tlv. This could pause the reception of a > message after it has been received. Again if it was not in near the top > (fragmentation type makes sense to be before this kind of tlv), the entire > message would have to be read in order to decide on the correct behavior. I believe the case above (delay processing) actually motivates for NOT requiring a particular order. > >> These issues can not be defined easily on a per protocol specification > >> as conflicts will arise. Ordering/not, two requiring tlv to be first > >> if included. > > > >If we do not impose any ordering of TLVs, maybe we will have to include > some text in PacketBB saying that protocols cannot expect a particular order > for >TLVs. That is, trying to encode protocol specific information using the > order of TLVs should be discouraged. > > > Yes and this IMO reduces the flexibility of packetbb while adding nothing to > packetbb. There is an advantage in not having to worry about ordering from > a document/IANA perspective but in terms of the protocol functionality > nothing is being added. Why is a strict ordering better than any order? > I would also like to point out that it allows for easy verification of one > TLV_fulltype per address. Which I am still in favor of keeping after some > more thought. The benefits are minimal and the possibility of incorrect > processing increases greatly when more than one TLV_fulltype can be on one > address. An example is a protocol which rebuilds a packetbb packets and > includes it own information into the packet/message. If this implementation > only ever expects one TLV_fulltype per address it may just throw out the > duplicates when rebuilding the packet. Yes you could say that it shouldn't > do this but I would expect MANY implementations would do this as they > wouldn't ever use the more than one TLV_fulltype per address "feature". I agree with the easier verification, but implementations will still have to handle the case of a duplicate tlv's attached to the same entity. So I don't consider this sufficient. Here are some more issue with the ordering argument. Who chooses the order? If it goes in IANA assigned order, how should these TYPE values be allocated? I plan to write the list to focus our attention on this issue again. Please feel free to reply there. Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 21 11:30: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 1INVf4-0003VB-1i; Tue, 21 Aug 2007 11:28:54 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INVf1-0003Sy-Q6 for manet-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 11:28:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVf1-0003Sp-Fw for manet@ietf.org; Tue, 21 Aug 2007 11:28:51 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INVf1-0001j8-4h for manet@ietf.org; Tue, 21 Aug 2007 11:28:51 -0400 Received: by nf-out-0910.google.com with SMTP id c10so921681nfd for ; Tue, 21 Aug 2007 08:28:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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:content-transfer-encoding:content-disposition:references; b=GpETU6uTfMoJtGmSWPXyPbfXiW8fh0JaHxsTvICVoQoXlCUwldMCsg3DpuD1mwWk2IRTyTL/CQcR6Lh6cvcl0SKB2PXdXgDjkFpFI3LrEjWs0ZHTcxyWcRrc6qpHKW0+mavm4B3Y1D3Os4Mwqj3DTXuaYno9M6Y0AcA0oKxN1vQ= 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:content-transfer-encoding:content-disposition:references; b=C7rKLN8c06/S+2HXt3SDpNZ77PzntXbZbwQIvRwVCcaVLP2Fkz4CtD3yL5uRTWvyB9dNR3nRqGyuC+nUDM1l9x2hbFbOP6YAqzhqFE7N+rfvDgdNrdgXNxFu9c+T22G7KDdMv25J5t58m+3Pq8t6vSq6r0FDf4kT4t7eLnCKwEI= Received: by 10.78.176.20 with SMTP id y20mr2861420hue.1187710127963; Tue, 21 Aug 2007 08:28:47 -0700 (PDT) Received: by 10.78.53.8 with HTTP; Tue, 21 Aug 2007 08:28:47 -0700 (PDT) Message-ID: <374005f30708210828q32a78db5o68557bdef5495da7@mail.gmail.com> Date: Tue, 21 Aug 2007 20:58:47 +0530 From: "Ian Chakeres" To: manet In-Reply-To: <374005f30708140526u12378857q5e632236c28e8f7e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30708140526u12378857q5e632236c28e8f7e@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [manet] Re: PacketBB Recent Discussion #2 - Ordering TLVs 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 would like to open up the question regarding ordering, as I don't feel there is a clear agreement on this item. What is the main advantage of ordering of TLVs? Please respond if you have an opinion. Also, I would like to keep the discussion limited to ordering, and not the benefits related to finding/detecting duplicates (addressed in another email). Ian Chakeres On 8/14/07, Ian Chakeres wrote: > I'd like to focus the discussion around ordering of TLV types within TLV blocks. > > If you have a good reason why we should not consistently order TLVs > within a TLV block, please email it to the list. Please provide a > clear use case that shows why ordering the TLVs is bad. > > Thanks. > Ian Chakeres > > Note: I would like to quickly finish any remaining PacketBB discussion > and move this document forward. > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 21 11:37: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 1INVlw-0005xs-Ky; Tue, 21 Aug 2007 11:36:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INVlu-0005xf-JC for manet-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 11:35:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVlu-0005xX-9e for manet@ietf.org; Tue, 21 Aug 2007 11:35:58 -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 1INVls-0006BL-PQ for manet@ietf.org; Tue, 21 Aug 2007 11:35:58 -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 l7LFZtAg028347 for ; Tue, 21 Aug 2007 16:35:55 +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 l7LFZt6x001412 for ; Tue, 21 Aug 2007 16:35:55 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 21 Aug 2007 16:35:54 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 16:35: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 Subject: RE: [manet] Re: Your comments in packetbb thread about #2 (ordering) Date: Tue, 21 Aug 2007 16:35:53 +0100 Message-ID: In-Reply-To: <374005f30708210824g2318c772keb69cae6febca503@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: Your comments in packetbb thread about #2 (ordering) thread-index: AcfkB4zZBa9OXxwzTACQet0Z7nohnQAAI2/Q References: <374005f30708210118wf4fa1e3mc8b591567bd37656@mail.gmail.com><200708211515.l7LFExRd021124@s2.itd.nrl.navy.mil> <374005f30708210824g2318c772keb69cae6febca503@mail.gmail.com> From: "Dearlove, Christopher \(UK\)" To: "Ian Chakeres" , "Justin Dean" X-OriginalArrivalTime: 21 Aug 2007 15:35:54.0795 (UTC) FILETIME=[F663B7B0:01C7E408] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: manet@ietf.org 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 > Who chooses the order? Numerical, hence > If it goes in IANA assigned order, Yes > how should > these TYPE values be allocated? I think that for all the cases we have in timetlv/NHDP/OLSRv2/DYMO we can allocate them as the documents go in. That would put the timetlv ones in first. I might suggest we don't allocate packet and message TLV types zero just in case of a major need at some time in the future. Given that it has subtypes, this will answer such as of Justin's point I think matters. We have used address TLV type zero on something that deserves it. ******************************************************************** 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 Aug 21 11:46:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVub-0003Cu-KB; Tue, 21 Aug 2007 11:44:57 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INVuZ-0003Ci-V0 for manet-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 11:44:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVuZ-0003Ca-LO for manet@ietf.org; Tue, 21 Aug 2007 11:44:55 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INVuY-0006gI-3R for manet@ietf.org; Tue, 21 Aug 2007 11:44:55 -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 l7LFiRZ6008429 for ; Tue, 21 Aug 2007 16:44:27 +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 l7LFiREZ023541 for ; Tue, 21 Aug 2007 16:44:27 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 21 Aug 2007 16:44:26 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 16:44:26 +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: PacketBB Recent Discussion #2 - Ordering TLVs Date: Tue, 21 Aug 2007 16:44:25 +0100 Message-ID: In-Reply-To: <374005f30708210828q32a78db5o68557bdef5495da7@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: PacketBB Recent Discussion #2 - Ordering TLVs thread-index: AcfkB/98GHw+uU1vTl2v3OZPuNifRQAAPqIg References: <374005f30708140526u12378857q5e632236c28e8f7e@mail.gmail.com> <374005f30708210828q32a78db5o68557bdef5495da7@mail.gmail.com> From: "Dearlove, Christopher \(UK\)" To: "Ian Chakeres" , "manet" X-OriginalArrivalTime: 21 Aug 2007 15:44:26.0239 (UTC) FILETIME=[273BE0F0:01C7E40A] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 Ordering has two advantages. For me the first I list is more important, but actually the second was the major motivation for the suggestion. - It makes finding/detecting duplicates trivial. Yes, I know Ian just said don't list this, but I think that's to miss the critical point. Verifying non-duplication without sorting is nasty, with it it's trivial. (It also keeps duplicate packet/message TLVs, where permitted, together, which is also a simplifying matter.) - It allows a basic implementation that knows which TLVs it handles to stop and skip TLVs when it has got to one past its range. Note that I regard the first of these as a necessary part of non-duplication. The second of these I personally don't think critical, but I believe others (who proposed it) disagree. If you don't consider verifying non-duplication, then I agree the argument is not strong, which is why I find it necessary to include that aspect here. =20 -----Original Message----- From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 Sent: 21 August 2007 16:29 To: manet Subject: [manet] Re: PacketBB Recent Discussion #2 - Ordering TLVs *** 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 I would like to open up the question regarding ordering, as I don't feel there is a clear agreement on this item. What is the main advantage of ordering of TLVs? Please respond if you have an opinion. Also, I would like to keep the discussion limited to ordering, and not the benefits related to finding/detecting duplicates (addressed in another email). Ian Chakeres On 8/14/07, Ian Chakeres wrote: > I'd like to focus the discussion around ordering of TLV types within TLV blocks. > > If you have a good reason why we should not consistently order TLVs > within a TLV block, please email it to the list. Please provide a > clear use case that shows why ordering the TLVs is bad. > > Thanks. > Ian Chakeres > > Note: I would like to quickly finish any remaining PacketBB discussion > and move this document forward. > _______________________________________________ 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 Tue Aug 21 11:52:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVzz-0008M7-GP; Tue, 21 Aug 2007 11:50:31 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INVzy-0008M1-Fc for manet-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 11:50:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVzy-0008Lt-4i for manet@ietf.org; Tue, 21 Aug 2007 11:50:30 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INVzx-0002wt-8L for manet@ietf.org; Tue, 21 Aug 2007 11:50:29 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l7LFoKiu023377; Tue, 21 Aug 2007 11:50:20 -0400 (EDT) Message-Id: <200708211550.l7LFoKiu023377@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007082111501907945 ; Tue, 21 Aug 2007 11:50:19 -0400 From: "Justin Dean" To: "'Ian Chakeres'" Date: Tue, 21 Aug 2007 11:54:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfkB2cpKqdfdjeTTN6jcrxtYmBC7QAAs1bg In-Reply-To: <374005f30708210824g2318c772keb69cae6febca503@mail.gmail.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: manet@ietf.org Subject: [manet] RE: Your comments in packetbb thread about #2 (ordering) 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 again. -----Original Message----- From: Ian Chakeres [mailto:ian.chakeres@gmail.com] Sent: Tuesday, August 21, 2007 11:25 AM To: Justin Dean Cc: manet@ietf.org Subject: Re: Your comments in packetbb thread about #2 (ordering) Comments inline. On 8/21/07, Justin Dean wrote: > Ian thought it would be useful to post this and I agree as I feel > there is still some confusion on the benefits of some of the > restrictions included in packetbb. I am sorry for the jumbled up > presentation of information here, it may be helpful to read bottom up > (older message first) > > Justin > > Further comments are inline. > > >Thanks for responding Justin. > > > >Comments inline. > > > >On 8/21/07, Justin Dean wrote: > >> Sending shouldn't be an issue, at least I haven't heard of any > >> issues code wise or otherwise. > >> > >> The issue is on the receiving end when a protocols expects things > >> to be ordered but are not. The other way around works fine, > >> receiving ordered but expecting unordered. Your example of NHDP > >> not ordering but OLSRv2 requiring ordering means that if OLSRv2 > >> accepted a packet it could possibly process things wrong and skip > >> over OLSRv2 tlvs because they were out of order with regards to the > >> NHDP tlvs included in the message. This makes it an all or nothing > >> kind of thing when > mixing protocols. > > > >Ok, when mixing protocols in common messages - NHDP & OLSRv2. Got it. > > > >> The skipping over of tlvs is not the only advantage as it helps > >> support the limiting of one tlv type per address without having to > >> "store" in memory all of the tlvs used so far for a given address > >> block. Yes this restriction of one tlv per address may be relaxed > >> but many protocols can and will reinsert this requirement (one > >> tlvfulltype per address) making implementations work significantly > >> harder to verify that messages are syntactically correct with out > >> of order tlv types. A third point is special tlvs when NEED to > >> come before other tlvs of different types, on example of this being > >> a fragmented message tlv type. If the fragment tlv isn't included > >> before other tlv types then incorrect parsing/action may have to be > >> reversed when the tlv is > located. > > > >I thought fragmentation was removed? Also, why would a fragmentation > >TLV > need to be first? > > It was but that doesn't mean that some fragmentation type tlv will > never be needed in the future. The TLV might need to be first if the > protocol using this fragmentation type tlv only processes the message > once the entire message has been received. If the tlv in question was > at the end it would make parsing work much harder to determine what > the protocol should do with the information contained in the message. > If the tlv was always at the start the protocol would be able to store > the message after reading the first tlv and be done until the rest of the message showed up. Why is it harder if it isn't first? Because processing of the message as it is read can not occur if it isn't first. Then the TLVs would have to be internally ordered to see what action would be required. If the TLV is first then the message/packet can be processed and parsed at the same time saving time and memory, with the nice side benefit of easily checking for duplicate tlv_fulltypes. > > > >Can you give me another case of a TLV needing to come first? > > > Any tlv which would "change" behavior of the following tlvs. I agree with you so far. > One example > would be a delay processing tlv. This could pause the reception of a > message after it has been received. Again if it was not in near the > top (fragmentation type makes sense to be before this kind of tlv), > the entire message would have to be read in order to decide on the correct behavior. I believe the case above (delay processing) actually motivates for NOT requiring a particular order. Only if you think reading and "half" processing every tlv to see what action should occur with the rest of the message is better than reading them in order and deciding what is to be done with the rest. > >> These issues can not be defined easily on a per protocol > >> specification as conflicts will arise. Ordering/not, two requiring > >> tlv to be first if included. > > > >If we do not impose any ordering of TLVs, maybe we will have to > >include > some text in PacketBB saying that protocols cannot expect a particular > order for >TLVs. That is, trying to encode protocol specific > information using the order of TLVs should be discouraged. > > > Yes and this IMO reduces the flexibility of packetbb while adding > nothing to packetbb. There is an advantage in not having to worry > about ordering from a document/IANA perspective but in terms of the > protocol functionality nothing is being added. Why is a strict ordering better than any order? I think I have addressed that. Processing and parsing can occur at the same time as you go. The entire message does not need to be read and stored so that the protocol can "find" the "important" tlvs. > I would also like to point out that it allows for easy verification of > one TLV_fulltype per address. Which I am still in favor of keeping > after some more thought. The benefits are minimal and the possibility > of incorrect processing increases greatly when more than one > TLV_fulltype can be on one address. An example is a protocol which > rebuilds a packetbb packets and includes it own information into the > packet/message. If this implementation only ever expects one > TLV_fulltype per address it may just throw out the duplicates when > rebuilding the packet. Yes you could say that it shouldn't do this > but I would expect MANY implementations would do this as they wouldn't ever use the more than one TLV_fulltype per address "feature". I agree with the easier verification, but implementations will still have to handle the case of a duplicate tlv's attached to the same entity. So I don't consider this sufficient. It's a one line check in code and in protocols to decide the behavior of receiving a malformed packet. Drop the tlv, drop the message, drop the packet or override it. I don't think packetbb should make a requirement as to correct receiving behavior but should make a suggestion to drop the message. Here are some more issue with the ordering argument. Who chooses the order? If it goes in IANA assigned order, how should these TYPE values be allocated? I plan to write the list to focus our attention on this issue again. Please feel free to reply there. Ian Chakeres I agree the ordering it not the easiest decision to make but I think it's worthwhile endeavor. Justin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 21 12:07: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 1INWEx-0007qy-Id; Tue, 21 Aug 2007 12:05:59 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INWEw-0007qs-9a for manet-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 12:05:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INWEw-0007qj-02 for manet@ietf.org; Tue, 21 Aug 2007 12:05:58 -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 1INWEv-0007Is-D9 for manet@ietf.org; Tue, 21 Aug 2007 12:05:57 -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 l7LG5u3N016059 for ; Tue, 21 Aug 2007 17:05:56 +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 l7LG5tme023659 for ; Tue, 21 Aug 2007 17:05:55 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 21 Aug 2007 17:05:55 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 17:05:55 +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: Your comments in packetbb thread about #2 (ordering) Date: Tue, 21 Aug 2007 17:05:54 +0100 Message-ID: In-Reply-To: <200708211550.l7LFoKiu023377@s2.itd.nrl.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] RE: Your comments in packetbb thread about #2 (ordering) thread-index: AcfkB2cpKqdfdjeTTN6jcrxtYmBC7QAAs1bgAABJknA= References: <374005f30708210824g2318c772keb69cae6febca503@mail.gmail.com> <200708211550.l7LFoKiu023377@s2.itd.nrl.navy.mil> From: "Dearlove, Christopher \(UK\)" To: "Justin Dean" , "Ian Chakeres" X-OriginalArrivalTime: 21 Aug 2007 16:05:55.0553 (UTC) FILETIME=[27B99510:01C7E40D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: manet@ietf.org 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 Justin > I agree the ordering it not the easiest decision to make but I think it's > worthwhile endeavor.=20 I think if you look at all of the TLVs required by OLSRv2 (including NHDP) the order isn't critical. Packet TLVs - None Message TLVs - VALITITY_TIME - INTERVAL_TIME - WILLINGNESS - MSG_SEQ_NUM - INCOMPLETE The first two are agreed common usage, and in an ID I expect will get finished first (after packetbb) so I'm inclined towards putting them first (skipping zero, just in case). After that if OLSRv2 gets out before DYMO, they could go next (e.g. 3 to 5) but that's not a deal-breaker. Address Block TLVs - Prefix Length - this is zero, defined in packetbb, and should be so. - VALITITY_TIME - to be added to timetlv - INTERVAL_TIME - if added to timetlv as address block TLV - OTHER_IF - LINK_STATUS - OTHER_NEIGHB - MPR - might become more complicated if add metrics to OLSRv2 - GATEWAY - LINK_METRIC - (name TBD) if added Similar comments. ******************************************************************** 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 Aug 21 15:47: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 1INZfj-0001u1-II; Tue, 21 Aug 2007 15:45:51 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INZfh-0001tw-CN for manet-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 15:45:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INZfh-0001to-1f for manet@ietf.org; Tue, 21 Aug 2007 15:45:49 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INZfg-0001vk-Dd for manet@ietf.org; Tue, 21 Aug 2007 15:45:48 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7LJjVNN024383; Tue, 21 Aug 2007 22:45:41 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 22:45:09 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 14:45:06 -0500 Received: from [172.18.141.139] ([172.18.141.139]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 14:45:06 -0500 Message-ID: <46CB40C1.9040700@nokia.com> Date: Tue, 21 Aug 2007 12:45:05 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Ian Chakeres Subject: Re: [manet] Re: PacketBB Recent Discussion #1 - Allowing multiple TLVs of the same type References: <374005f30708140523p2888a643he7f655b5b1d03c7a@mail.gmail.com> <374005f30708210815u5da12b91ga01f9a2bfc2a8215@mail.gmail.com> In-Reply-To: <374005f30708210815u5da12b91ga01f9a2bfc2a8215@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Aug 2007 19:45:06.0479 (UTC) FILETIME=[C649A3F0:01C7E42B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Ian, I think it is quite likely that one will want to associate multiple values to the same range of addresses. Suppose some nodes within the range need to be described by two different characteristics from the range of values for some specific type TLV. Then this restriction would be harmful. Am I missing something? Why isn't this clear? I can see that OLSRv2 does not need this now, but we are discussing a packet template for future [manet] protocols and I really think it would be a mistake to try to mandate this restriction for the indefinite future. Plus, I don't even think it buys us very much now! Furthermore, there are certainly cases where we would want to have the same "type" TLV appear more than once. I am not sure that this fits within the general "case" where multiple TLVs of the same type associated with the same "entity" in PacketBB, because I am not sure what is an "entity" and what is not an "entity". For one example, though, I would like to have a more economical way of describing neighborhoods, as I have mentioned recently, and it would be nice to _allow_ including multiple instances of the same such TLV. Regards, Charlie P. ext Ian Chakeres wrote: > I believe that there has been sufficient discussion on this issue, and > that there is a good reason to keep the existing restriction to > disallow having multiple TLVs of the same type associated with the > same entity in PacketBB. > > If you have additional use cases, please provide them quickly. > Otherwise, I will consider this issue closed. > > Ian > > On 8/14/07, Ian Chakeres wrote: > >> I'd like to focus the discussion around allowing multiple TLVs of the >> same type to be associated with the one entity in packetbb. >> >> If you have a good use case, please provide it and describe why it is useful. >> >> Ian Chakeres >> >> Note: I would like to quickly finish any remaining PacketBB discussion >> and move this document forward. >> >> > > > _______________________________________________ > 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 Aug 21 16:51: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 1INaf2-0002J3-NP; Tue, 21 Aug 2007 16:49:12 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INaf0-0002It-Px for manet-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 16:49:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INaf0-0002Il-GP for manet@ietf.org; Tue, 21 Aug 2007 16:49:10 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INaez-0007Eq-9V for manet@ietf.org; Tue, 21 Aug 2007 16:49:10 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id l7LKn4Ld010781; Tue, 21 Aug 2007 16:49:04 -0400 (EDT) Message-Id: <200708212049.l7LKn4Ld010781@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007082116490409678 ; Tue, 21 Aug 2007 16:49:04 -0400 From: "Justin Dean" To: "'Charles E. Perkins'" Subject: RE: [manet] Re: PacketBB Recent Discussion #1 - Allowing multipleTLVs of the same type Date: Tue, 21 Aug 2007 16:53:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfkLBLkeTOyYKDBRuqjVVELGFJrhAABZa+A In-Reply-To: <46CB40C1.9040700@nokia.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: manet@ietf.org 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 > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > Sent: Tuesday, August 21, 2007 3:45 PM > To: ext Ian Chakeres > Cc: manet > Subject: Re: [manet] Re: PacketBB Recent Discussion #1 - > Allowing multipleTLVs of the same type > > > Hello Ian, > > I think it is quite likely that one will want to associate > multiple values to the same range of addresses. > Suppose some nodes within the range need to be described by > two different characteristics from the range of values for > some specific type TLV. > Then this restriction would be harmful. > > Am I missing something? Why isn't this clear? > You can do this. You can include as many different tlv types (different characteristics) per address as you wish. This restriction is to disallow assigning different values of the same characteristic to the same address, NOT to restrict how many characteristics may be described. Different characteristics should be described with a different tlv type. That being said let me give yet another example: Say the characteristic for a given tlv is link type. Links can be described as symmetric, asymmetric, lost, heard, mpr, or something else entirely. The issue I think is tripping people up is that these particular characteristics are not exclusive; A link can be both symmetric, heard and mpr or asymmetric and heard. There are a few ways to convey this information using the current packetbb with restrictions. Break up the link types into two tlvs who's properties are exclusive within each tlv. So one tlv denoting asymmetric, symmetric, and lost. And another tlv which denotes lost, or mpr. Use a TLV for each trait. This can be useful for large blocks of addresses which have the same information. With the inclusion of tlv subtypes there is a much richer tlv type space to use. Define your value space within the TLV to be exclusive. The first two bits denote symmetric, asymmetric, and lost and the following bits denote heard, or mpr. In this way only one tlv needs to be used to give the data about the trait you are trying to use. Attempting to use one TLV to describe two different attributes is confusing. That being said one could define an "everything" tlv which includes large value fields defining everything about an address. > I can see that OLSRv2 does not need this now, but we are > discussing a packet template for future [manet] protocols and > I really think it would be a mistake to try to mandate this > restriction for the indefinite future. > Plus, I don't even think it buys us very much now! > > Furthermore, there are certainly cases where we would want to > have the same "type" TLV appear more than once. I am not > sure that this fits within the general "case" where multiple > TLVs of the same type associated with the same "entity" in > PacketBB, because I am not sure what is an "entity" and what > is not an "entity". For one example, though, I would like to > have a more economical way of describing neighborhoods, as I > have mentioned recently, and it would be nice to _allow_ > including multiple instances of the same such TLV. One of my above examples for solving this within the current packetbb should be sufficient for what you are trying to do with the restrictions still in place. Justin > > Regards, > Charlie P. > > > > > ext Ian Chakeres wrote: > > I believe that there has been sufficient discussion on this > issue, and > > that there is a good reason to keep the existing restriction to > > disallow having multiple TLVs of the same type associated with the > > same entity in PacketBB. > > > > If you have additional use cases, please provide them quickly. > > Otherwise, I will consider this issue closed. > > > > Ian > > > > On 8/14/07, Ian Chakeres wrote: > > > >> I'd like to focus the discussion around allowing multiple > TLVs of the > >> same type to be associated with the one entity in packetbb. > >> > >> If you have a good use case, please provide it and > describe why it is useful. > >> > >> Ian Chakeres > >> > >> Note: I would like to quickly finish any remaining PacketBB > >> discussion and move this document forward. > >> > >> > > > > > > _______________________________________________ > > 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 Tue Aug 21 18:27: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 1INc9V-0004As-HW; Tue, 21 Aug 2007 18:24:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INc9T-00044s-M5 for manet-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 18:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INc9T-00043Z-Bn for manet@ietf.org; Tue, 21 Aug 2007 18:24:43 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INc9R-0001EF-Nd for manet@ietf.org; Tue, 21 Aug 2007 18:24:43 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7LMO53m005047; Wed, 22 Aug 2007 01:24:38 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 01:24:05 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 17:24:04 -0500 Received: from [172.18.141.139] ([172.18.141.139]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 17:24:04 -0500 Message-ID: <46CB65FB.4060006@nokia.com> Date: Tue, 21 Aug 2007 15:23:55 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Justin Dean Subject: Re: [manet] Re: PacketBB Recent Discussion #1 - Allowing multipleTLVs of the same type References: <200708212049.l7LKn4Ld010781@s2.itd.nrl.navy.mil> In-Reply-To: <200708212049.l7LKn4Ld010781@s2.itd.nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Aug 2007 22:24:04.0129 (UTC) FILETIME=[FB2B8910:01C7E441] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: manet@ietf.org 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 Justin, Your example shows how to segregate type values so that they fall into neat, mutually exclusive bins. But that is not always possible. For instance, I don't see how it applies to my example of the reduced-size neighborhood descriptor TLV; I showed a candidate proposal last week. It should be possible to insert multiple such TLVs of the same type, but with different value fields. The value fields may have substructure, and not be a simple array of slots for scalars. Clearly, in this case it makes very little sense to require the redundant definition of multiple types, just so one could supply different value structures. If I can have multiple such TLVs of the same type, I will be happy on this point. I think, however, this is a good case in point about how restrictions are being made based on a very limited experience with how they fit into the current design of our existing protocols. I think your example also shows that placing this restriction carries with it perhaps unintended consequences -- in this case, that _only_ value ranges with some sort of "Pauli exclusion principle" can be supported under packetbb. I'm pretty sure there are lots of other kinds of value fields that may be needed in the future. Regards, Charlie P. ext Justin Dean wrote: > > > >> -----Original Message----- >> From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >> Sent: Tuesday, August 21, 2007 3:45 PM >> To: ext Ian Chakeres >> Cc: manet >> Subject: Re: [manet] Re: PacketBB Recent Discussion #1 - >> Allowing multipleTLVs of the same type >> >> >> Hello Ian, >> >> I think it is quite likely that one will want to associate >> multiple values to the same range of addresses. >> Suppose some nodes within the range need to be described by >> two different characteristics from the range of values for >> some specific type TLV. >> Then this restriction would be harmful. >> >> Am I missing something? Why isn't this clear? >> >> > You can do this. You can include as many different tlv types (different > characteristics) per address as you wish. > This restriction is to disallow assigning different values of the same > characteristic to the same address, NOT to restrict how many characteristics > may be described. Different characteristics should be described with a > different tlv type. That being said let me give yet another example: > > Say the characteristic for a given tlv is link type. Links can be described > as symmetric, asymmetric, lost, heard, mpr, or something else entirely. The > issue I think is tripping people up is that these particular characteristics > are not exclusive; A link can be both symmetric, heard and mpr or asymmetric > and heard. There are a few ways to convey this information using the > current packetbb with restrictions. > > Break up the link types into two tlvs who's properties are exclusive within > each tlv. So one tlv denoting asymmetric, symmetric, and lost. And another > tlv which denotes lost, or mpr. > > Use a TLV for each trait. This can be useful for large blocks of addresses > which have the same information. With the inclusion of tlv subtypes there > is a much richer tlv type space to use. > > Define your value space within the TLV to be exclusive. The first two bits > denote symmetric, asymmetric, and lost and the following bits denote heard, > or mpr. In this way only one tlv needs to be used to give the data about > the trait you are trying to use. > > Attempting to use one TLV to describe two different attributes is confusing. > That being said one could define an "everything" tlv which includes large > value fields defining everything about an address. > > > >> I can see that OLSRv2 does not need this now, but we are >> discussing a packet template for future [manet] protocols and >> I really think it would be a mistake to try to mandate this >> restriction for the indefinite future. >> Plus, I don't even think it buys us very much now! >> >> Furthermore, there are certainly cases where we would want to >> have the same "type" TLV appear more than once. I am not >> sure that this fits within the general "case" where multiple >> TLVs of the same type associated with the same "entity" in >> PacketBB, because I am not sure what is an "entity" and what >> is not an "entity". For one example, though, I would like to >> have a more economical way of describing neighborhoods, as I >> have mentioned recently, and it would be nice to _allow_ >> including multiple instances of the same such TLV. >> > > One of my above examples for solving this within the current packetbb should > be sufficient for what you are trying to do with the restrictions still in > place. > > Justin > >> Regards, >> Charlie P. >> >> >> >> >> ext Ian Chakeres wrote: >> >>> I believe that there has been sufficient discussion on this >>> >> issue, and >> >>> that there is a good reason to keep the existing restriction to >>> disallow having multiple TLVs of the same type associated with the >>> same entity in PacketBB. >>> >>> If you have additional use cases, please provide them quickly. >>> Otherwise, I will consider this issue closed. >>> >>> Ian >>> >>> On 8/14/07, Ian Chakeres wrote: >>> >>> >>>> I'd like to focus the discussion around allowing multiple >>>> >> TLVs of the >> >>>> same type to be associated with the one entity in packetbb. >>>> >>>> If you have a good use case, please provide it and >>>> >> describe why it is useful. >> >>>> Ian Chakeres >>>> >>>> Note: I would like to quickly finish any remaining PacketBB >>>> discussion and move this document forward. >>>> >>>> >>>> >>> _______________________________________________ >>> 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 Tue Aug 21 23:29: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 1INgsf-0004L7-TS; Tue, 21 Aug 2007 23:27:42 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INgse-0004L1-AR for manet-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 23:27:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INgse-0004Kt-11 for manet@ietf.org; Tue, 21 Aug 2007 23:27:40 -0400 Received: from nz-out-0506.google.com ([64.233.162.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INgsc-0007uy-MF for manet@ietf.org; Tue, 21 Aug 2007 23:27:39 -0400 Received: by nz-out-0506.google.com with SMTP id n1so29552nzf for ; Tue, 21 Aug 2007 20:27:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=piA6/3czpX6rlAfqYiLL9A4NzLsbTEcEshiW8lviWsnNIcp8p4D+2ft49x1R0pgGXES35Eor0Xmjo1bMvysN40ZDWzfrgHTbwU5hIJSLe+i+dewSxW1U2b0kTlUrFxy/dzlICEAikoeVNekAvVVLnsDjTCgmQUsZcz9Ia7hj2ig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=pr1dyMb2/5/oBiYXJQ5V7Dnv01wRSMUdYYT81JMYcwvkJ7qBACahgFFXHa1sx0gv4N9MsuBWZUF3MBZAc2Kl5GtSXGroR1j1V4hDsiUCJ7K+pTLY9zagpFXoRt48Al54lQazsnTNxPIlGurQW86KjHg7DqRYO4yObNGGG04gTTk= Received: by 10.114.109.1 with SMTP id h1mr197309wac.1187753257394; Tue, 21 Aug 2007 20:27:37 -0700 (PDT) Received: by 10.114.144.17 with HTTP; Tue, 21 Aug 2007 20:27:37 -0700 (PDT) Message-ID: <7f253c030708212027o27c05a13i51d9fc7139c64a71@mail.gmail.com> Date: Wed, 22 Aug 2007 11:27:37 +0800 From: "=?GB2312?B?1cW5+sfs?=" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [manet] how to simulate IP address autoconfiguration scheme in ad hoc 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: , Content-Type: multipart/mixed; boundary="===============0749713476==" Errors-To: manet-bounces@ietf.org --===============0749713476== Content-Type: multipart/alternative; boundary="----=_Part_59481_24911773.1187753257357" ------=_Part_59481_24911773.1187753257357 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I want to simulate an IP address autoconfiguration scheme in ad hoc networks,but i have not seen similar simulation codes under any tools(ns or qualnet). I don't have any ideas about that. Can anyone of here give me some help?Thank you very much. -- Best regards with you. ------=_Part_59481_24911773.1187753257357 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I want to simulate an IP address autoconfiguration scheme in ad hoc networks,but i have not seen similar simulation codes under any tools(ns or qualnet). I don't have any ideas about that. Can anyone of here give me some help?Thank you very much.

--
Best regards with you.

------=_Part_59481_24911773.1187753257357-- --===============0749713476== 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 --===============0749713476==-- From manet-bounces@ietf.org Wed Aug 22 04:41: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 1INlkw-0005z9-Kv; Wed, 22 Aug 2007 04:40:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INlkt-0005ys-UZ for manet-confirm+ok@megatron.ietf.org; Wed, 22 Aug 2007 04:39:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INlkt-0005yk-66 for manet@ietf.org; Wed, 22 Aug 2007 04:39:59 -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 1INlks-00034T-G8 for manet@ietf.org; Wed, 22 Aug 2007 04:39:59 -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 l7M8dvPx001761 for ; Wed, 22 Aug 2007 09:39:57 +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 l7M8dvrP028023 for ; Wed, 22 Aug 2007 09:39:57 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 22 Aug 2007 09:39:56 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 09:39:56 +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: Your comments in packetbb thread about #2 (ordering) Date: Wed, 22 Aug 2007 09:39:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] RE: Your comments in packetbb thread about #2 (ordering) thread-index: AcfkB2cpKqdfdjeTTN6jcrxtYmBC7QAAs1bgAABJknAAIySOkA== References: <374005f30708210824g2318c772keb69cae6febca503@mail.gmail.com> <200708211550.l7LFoKiu023377@s2.itd.nrl.navy.mil> From: "Dearlove, Christopher \(UK\)" To: "Dearlove, Christopher \(UK\)" , "Justin Dean" , "Ian Chakeres" X-OriginalArrivalTime: 22 Aug 2007 08:39:56.0614 (UTC) FILETIME=[04914660:01C7E498] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: manet@ietf.org 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 MSG_SEQ_NUM below should be CONT_SEQ_NUM. Doesn't affect the argument. -----Original Message----- From: Dearlove, Christopher (UK)=20 Sent: 21 August 2007 17:06 To: 'Justin Dean'; 'Ian Chakeres' Cc: manet@ietf.org Subject: RE: [manet] RE: Your comments in packetbb thread about #2 (ordering) Justin > I agree the ordering it not the easiest decision to make but I think it's > worthwhile endeavor.=20 I think if you look at all of the TLVs required by OLSRv2 (including NHDP) the order isn't critical. Packet TLVs - None Message TLVs - VALITITY_TIME - INTERVAL_TIME - WILLINGNESS - MSG_SEQ_NUM - INCOMPLETE The first two are agreed common usage, and in an ID I expect will get finished first (after packetbb) so I'm inclined towards putting them first (skipping zero, just in case). After that if OLSRv2 gets out before DYMO, they could go next (e.g. 3 to 5) but that's not a deal-breaker. Address Block TLVs - Prefix Length - this is zero, defined in packetbb, and should be so. - VALITITY_TIME - to be added to timetlv - INTERVAL_TIME - if added to timetlv as address block TLV - OTHER_IF - LINK_STATUS - OTHER_NEIGHB - MPR - might become more complicated if add metrics to OLSRv2 - GATEWAY - LINK_METRIC - (name TBD) if added Similar comments. ******************************************************************** 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 Aug 22 10:21: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 1INr3M-0005uT-UZ; Wed, 22 Aug 2007 10:19:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1INr3L-0005tE-73 for manet-confirm+ok@megatron.ietf.org; Wed, 22 Aug 2007 10:19:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INr3K-0005su-SD for manet@ietf.org; Wed, 22 Aug 2007 10:19:22 -0400 Received: from mail2.hpi.uni-potsdam.de ([141.89.225.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INr3K-0002Xj-7Z for manet@ietf.org; Wed, 22 Aug 2007 10:19:22 -0400 Received: from nowa.dmz.hpi.uni-potsdam.de (h126.225.hpi.uni-potsdam.de [141.89.225.126]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id C748D89460 for ; Wed, 22 Aug 2007 16:19:20 +0200 (CEST) Received: from 3MXMA1R.hpi.uni-potsdam.de ([141.89.224.242]) by nowa.dmz.hpi.uni-potsdam.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 16:19:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Aug 2007 16:19:20 +0200 Message-ID: <5AC0F51A926CD442BC08D55DA7DAB1D406C0FA34@3mxma1r.hpi.uni-potsdam.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Movement of nodes should be modifiable during runtime of an ns-2 simulation Thread-Index: Acfkx24u62Rle/F3Qrq11f0NdjXQ9g== From: "Schuenemann, Bjoern" To: X-OriginalArrivalTime: 22 Aug 2007 14:19:21.0065 (UTC) FILETIME=[6EB9E590:01C7E4C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [manet] Movement of nodes should be modifiable during runtime of an ns-2 simulation 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="===============2062275827==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============2062275827== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E4C7.6E6BC965" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E4C7.6E6BC965 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, =20 I'd like to make a simulation with ns-2 where the movement of the nodes = is modifiable by another program during the runtime of the ns-2 = simulation. How could I realize this? It seems that modifications of = trace and movement files are ignored by ns-2 after the files are read in = by the TCL script. =20 Thank you very much for your help! =20 Regards, Bj=F6rn ------_=_NextPart_001_01C7E4C7.6E6BC965 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
 
I=92d like to make a simulation with = ns-2 where the=20 movement of the nodes is modifiable by another program during the = runtime of the=20 ns-2 simulation. How could I realize this? It seems that modifications = of trace=20 and movement files are ignored by ns-2 after the files are read in by = the TCL=20 script.
 
Thank you very much for your = help!
 
Regards,
Bj=F6rn
------_=_NextPart_001_01C7E4C7.6E6BC965-- --===============2062275827== 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 --===============2062275827==-- From manet-bounces@ietf.org Thu Aug 23 02:04: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 1IO5mH-0006Ne-Qt; Thu, 23 Aug 2007 02:02:46 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IO5mF-0006NZ-C4 for manet-confirm+ok@megatron.ietf.org; Thu, 23 Aug 2007 02:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO5mE-0006NR-Q4 for manet@ietf.org; Thu, 23 Aug 2007 02:02:42 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IO5mD-0005U6-Gt for manet@ietf.org; Thu, 23 Aug 2007 02:02:42 -0400 Received: by nf-out-0910.google.com with SMTP id c10so293015nfd for ; Wed, 22 Aug 2007 23:02:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=BlkQp4ETdyApZ6pnGVBSCI8KRzmHCmYKlzj+b1R7t/F1VmsYiLnOoLnpBKA+bj2SiFzXGUES771NwAPaaljEbY/PcNXWWxKi8O+KJm8MWdZsX6PdRb1X2Mzkz/Cri86c5b1diKpKNshCTHwBRCpUrLCS2okkWalt2BUbHX3xWzs= 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=R5Z8Wj6wk4uFXXgfpHyA+H5csSpwHIoooTGFtb4Q5iFwR9FHgNzqKUfGRLnMW5fJPdUx/0FgTBHVU7bS7BVE9xaSmhKdmE8b8UJHpHMFcn6i6c8oN+1nrixwE1BmBp1cFxbLFf+PgVCnDB0hS9tK0ll1F/rqFd3IkQD1gm4/Bfw= Received: by 10.78.200.20 with SMTP id x20mr969616huf.1187848960355; Wed, 22 Aug 2007 23:02:40 -0700 (PDT) Received: by 10.78.53.8 with HTTP; Wed, 22 Aug 2007 23:02:37 -0700 (PDT) Message-ID: <374005f30708222302t4dbd27f5yd6d586e87efab2c7@mail.gmail.com> Date: Thu, 23 Aug 2007 11:32:39 +0530 From: "Ian Chakeres" To: "Dearlove, Christopher (UK)" Subject: Re: [manet] RE: Your comments in packetbb thread about #2 (ordering) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30708210824g2318c772keb69cae6febca503@mail.gmail.com> <200708211550.l7LFoKiu023377@s2.itd.nrl.navy.mil> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: manet , "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 If we take the argument about processing in IANA assigned order. What happens if later, someone wants something that is processed before one of these TLV types? Alternatively, how can we ensure that the ordering we choose now is right for the future? Ian On 8/21/07, Dearlove, Christopher (UK) wrote: > > Justin > > I agree the ordering it not the easiest decision to make but I think > it's > > worthwhile endeavor. > > I think if you look at all of the TLVs required by OLSRv2 (including > NHDP) the order isn't critical. > > Packet TLVs > - None > > Message TLVs > - VALITITY_TIME > - INTERVAL_TIME > - WILLINGNESS > - MSG_SEQ_NUM > - INCOMPLETE > > The first two are agreed common usage, and in an ID I expect will > get finished first (after packetbb) so I'm inclined towards putting > them first (skipping zero, just in case). After that if OLSRv2 gets > out before DYMO, they could go next (e.g. 3 to 5) but that's not a > deal-breaker. > > Address Block TLVs > - Prefix Length - this is zero, defined in packetbb, and should be so. > - VALITITY_TIME - to be added to timetlv > - INTERVAL_TIME - if added to timetlv as address block TLV > - OTHER_IF > - LINK_STATUS > - OTHER_NEIGHB > - MPR - might become more complicated if add metrics to OLSRv2 > - GATEWAY > - LINK_METRIC - (name TBD) if added > > Similar comments. > > > > > > > > > ******************************************************************** > 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 Thu Aug 23 04:47: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 1IO8Jb-0003gM-Q9; Thu, 23 Aug 2007 04:45:19 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IO8Ja-0003gG-Iy for manet-confirm+ok@megatron.ietf.org; Thu, 23 Aug 2007 04:45:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8Ja-0003g8-56 for manet@ietf.org; Thu, 23 Aug 2007 04:45:18 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IO8JZ-0000Nn-Cj for manet@ietf.org; Thu, 23 Aug 2007 04:45:18 -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 l7N8jF4O006509 for ; Thu, 23 Aug 2007 09:45:16 +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 l7N8jFHe005908 for ; Thu, 23 Aug 2007 09:45:15 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 23 Aug 2007 09:45:15 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 09:45:14 +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: Your comments in packetbb thread about #2 (ordering) Date: Thu, 23 Aug 2007 09:45:13 +0100 Message-ID: In-Reply-To: <374005f30708222302t4dbd27f5yd6d586e87efab2c7@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] RE: Your comments in packetbb thread about #2 (ordering) thread-index: AcflSzlYDHx6gBXNSJ22Uu6irZxtJgAFUn4A References: <374005f30708210824g2318c772keb69cae6febca503@mail.gmail.com> <200708211550.l7LFoKiu023377@s2.itd.nrl.navy.mil> <374005f30708222302t4dbd27f5yd6d586e87efab2c7@mail.gmail.com> From: "Dearlove, Christopher \(UK\)" To: "Ian Chakeres" X-OriginalArrivalTime: 23 Aug 2007 08:45:14.0987 (UTC) FILETIME=[ECBEE3B0:01C7E561] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: manet , "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 There's absolutely no compulsion to process in the order that you store in. Often there is no well-defined processing order in any case. If you consider OLSRv2, for example, INTERVAL_TIME is optional - there's no compulsion to use it, and all its uses are in things you may do. (For example one way to track a poor link is to spot missing HELLO messages, if you know when the next one is expected.) There's no fixed position in when to use that. But even when not optional, you use LINK_STATE and OTHER_IF of an address in a HELLO message together (if both present). And I'm reasonably sure I could organise the processing of a HELLO message to use WILLINGNESS before or after VALIDITY_TIME (it's written one way, but as long as you get the same effect, the processing order doesn't matter. In any case I likely would cache the two values (extracting and converting the time value) while, or just after, parsing the message, and then use them how I choose. (If a message had a long block of information, I might cache a pointer to it instead.) -----Original Message----- From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 Sent: 23 August 2007 07:03 To: Dearlove, Christopher (UK) Cc: Justin Dean; Thomas Heide Clausen (work); manet Subject: Re: [manet] RE: Your comments in packetbb thread about #2 (ordering) *** 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 If we take the argument about processing in IANA assigned order. What happens if later, someone wants something that is processed before one of these TLV types? Alternatively, how can we ensure that the ordering we choose now is right for the future? Ian On 8/21/07, Dearlove, Christopher (UK) wrote: > > Justin > > I agree the ordering it not the easiest decision to make but I think > it's > > worthwhile endeavor. > > I think if you look at all of the TLVs required by OLSRv2 (including > NHDP) the order isn't critical. > > Packet TLVs > - None > > Message TLVs > - VALITITY_TIME > - INTERVAL_TIME > - WILLINGNESS > - MSG_SEQ_NUM > - INCOMPLETE > > The first two are agreed common usage, and in an ID I expect will > get finished first (after packetbb) so I'm inclined towards putting > them first (skipping zero, just in case). After that if OLSRv2 gets > out before DYMO, they could go next (e.g. 3 to 5) but that's not a > deal-breaker. > > Address Block TLVs > - Prefix Length - this is zero, defined in packetbb, and should be so. > - VALITITY_TIME - to be added to timetlv > - INTERVAL_TIME - if added to timetlv as address block TLV > - OTHER_IF > - LINK_STATUS > - OTHER_NEIGHB > - MPR - might become more complicated if add metrics to OLSRv2 > - GATEWAY > - LINK_METRIC - (name TBD) if added > > Similar comments. > > > > > > > > > ******************************************************************** > 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 Aug 24 07:59:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOXnV-0005U2-Vr; Fri, 24 Aug 2007 07:57:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IOXnU-0005Tl-2g for manet-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 07:57:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOXnT-0005SS-ND for manet@ietf.org; Fri, 24 Aug 2007 07:57:51 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOXnS-0006zE-46 for manet@ietf.org; Fri, 24 Aug 2007 07:57:51 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IOXnO-0000Ht-HT for ; Fri, 24 Aug 2007 13:57:49 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps for id 1IOXnN-0004On-3k; Fri, 24 Aug 2007 13:57:46 +0200 Received: from i72numiri.tm.uni-karlsruhe.de ([141.3.71.18]) by irams1.ira.uni-karlsruhe.de with esmtpsa for id 1IOXnM-0005X8-Pa; Fri, 24 Aug 2007 13:57:44 +0200 Message-ID: <46CEC7B7.7050309@tm.uka.de> Date: Fri, 24 Aug 2007 13:57:43 +0200 From: Peter Baumung User-Agent: Thunderbird 1.5.0.10 (X11/20060911) MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -4.8 (----) X-Spam-Report: 1.2 SUBJ_ALL_CAPS Subject is all capitals -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP -4.5 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 1.8 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [manet] CALL FOR PAPERS - WONS 2008 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 ---------------------------------------------------------------------- CALL FOR PAPERS - WONS 2008 The Fifth International Conference on Wireless On-demand Network Systems and Services January 24-25, 2008. Garmisch-Partenkirchen, Germany http://www.tm.uka.de/wons2008 ---------------------------------------------------------------------- Scope of the conference ----------------------- With the increasing variety of wireless technologies, ubiquitous connectivity and service provisioning more and more complements traditional, infrastructure-based cellular networks. WLANs, WiMax, Mobile Ad-hoc networks as well as vehicular networks and sensor networks are popular examples. The goal is to provide services "on demand" with minimal planning and management effort as well as with little dependency on existing network infrastructures. On-demand provisioning of services in such infrastructure-less environments is a challenge in itself. Methods for self-organisation are strongly required to enable this vision. Other challenges are posed by the architectures suited for different networks and applications (e.g., specialized architectures for sensor networks) also raising issues with respect to interoperability. WONS is now at its fifth edition and is still confronted with new technical challenges and new application demands. As such it provides a premier forum for high quality paper presentations and lively discussions. For this conference we request submissions of high quality research papers on "wireless on demand networks" that provide novel insights on protocol and network design, modeling and performance evaluation, pricing and profitability models, QoS models, practical implementations, service level aspects and Internet integration of wireless networks. Topics related to wireless ad hoc networks, mesh networks, vehicular networks and sensor networks comprise, but are not limited to: * Architecture and Design * Analysis through simulation and experimental evaluation * Modeling * Internet integration * Social and economic aspects * Pervasive / ubiquitous computing * Localization and mobility management * Security * Energy-efficient protocols and power management * Applications and Service Support * Data dissemination and Peer-to-Peer systems * Middleware aspects * Self-X and network management Manuscript submissions ---------------------- Submitted papers must not have been published elsewhere nor currently be under review by another conference or journal. Authors are invited to submit double-column full (8 pages) and short papers (4 pages) in PDF format having a font size no smaller than 10pt. Short papers should present future research directions, ongoing work, visionary, innovative ideas. Further submission instructions will be published on the conference web site. Schedule -------- Paper Submission Deadline: October 15, 2007 Notification of Acceptance: November 16, 2007 Camera-Ready Deadline: December 7, 2007 Organization - Executive Committee ---------------------------------- General Chair Martina Zitterbart, University of Karlsruhe Technical Program Co-Chair Bahar Sadeghi, Intel Corporation Hannes Hartenstein, University of Karlsruhe Local Organization Chair Falko Dressler, Friedrich-Alexander University Erlangen-Nuremberg Publicity and Web-Chair Peter Baumung, University of Karlsruhe Moritz Killat, University of Karlsruhe Steering Committee Renato Lo Cigno (Chair), University of Trento Ernst Biersack, Institute EURECOM Edward W. Knightly, Rice University Mario Gerla, UCLA Ioannis Stavrakakis, University of Athens Technical Program Committee (partial list) Ernst Biersack, Institute EURECOM Torsten Braun, University of Bern Sunghyun Choi, Seoul National University Marco Conti, CNR-IIT Andrzej Duda, LSR-IMAG Laboratory Mario Gerla, UCLA Silvia Giordano, SUPSI of Lugano Holger Karl, University of Paderborn Edward W. Knightly, Rice University Renato Lo Cigno, University of Trento Henrik Lundgren, Thomson Research Stefan Mangold, Swisscom Martin Mauve, Heinrich Heine University Düsseldorf Pietro Michiardi, Institute Eurecom Michele Rossi, University of Padova Ioannis Stavrakakis, University of Athens Kurt Tutschku, University of Würzburg Michael Welzl, University of Innsbruck _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Aug 28 15:17:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ6Wt-0006jh-1J; Tue, 28 Aug 2007 15:15:11 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IQ6Wl-0006iQ-6z for manet-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 15:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ6Wk-0006iB-SF; Tue, 28 Aug 2007 15:15:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ6Wk-0005Fu-Cy; Tue, 28 Aug 2007 15:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 2D74D26E6E; Tue, 28 Aug 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQ6Wk-0006vz-1W; Tue, 28 Aug 2007 15:15: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: Tue, 28 Aug 2007 15:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-timetlv-02.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 : Representing multi-value time in MANETs Author(s) : T. Clausen, C. Dearlove Filename : draft-ietf-manet-timetlv-02.txt Pages : 18 Date : 2007-8-28 This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-timetlv-02.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-timetlv-02.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-timetlv-02.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-8-28145654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-timetlv-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-timetlv-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-28145654.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 Tue Aug 28 15:47: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 1IQ70A-0002Kr-Nq; Tue, 28 Aug 2007 15:45:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IQ708-0002J5-K1 for manet-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 15:45:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ708-0002Ix-AV; Tue, 28 Aug 2007 15:45:24 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ707-0006hY-5z; Tue, 28 Aug 2007 15:45:24 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 29C9E3289C; Tue, 28 Aug 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQ6Wk-0006w2-2I; Tue, 28 Aug 2007 15:15: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: Tue, 28 Aug 2007 15:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-jitter-02.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 : Jitter considerations in MANETs Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-jitter-02.txt Pages : 17 Date : 2007-8-28 This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in MANET routing protocols to reduce the probability of packet collisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-jitter-02.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-jitter-02.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-jitter-02.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-8-28145859.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-jitter-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-jitter-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-28145859.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 Thu Aug 30 09:41: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 1IQkFS-00074G-Q9; Thu, 30 Aug 2007 09:39:50 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IQkFR-00074A-4B for manet-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 09:39:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQkFQ-000741-Om for manet@ietf.org; Thu, 30 Aug 2007 09:39:48 -0400 Received: from sf-1.cit.ie ([157.190.22.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQkFP-0000ep-OA for manet@ietf.org; Thu, 30 Aug 2007 09:39:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Aug 2007 14:40:47 +0100 Message-ID: <07C0AAD24E652548B1F528DED7C034FD02572CA6@sf-1.cit.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPR election in standard OLSR and Clusterhead Election in Hierarchical OLSR Thread-Index: AcfrC18JjtKdqbMyQsyUQkRteBzXwg== From: "Aisling ODriscoll" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Subject: [manet] MPR election in standard OLSR and Clusterhead Election in Hierarchical OLSR 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="===============0692992244==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============0692992244== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EB0B.842800A2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EB0B.842800A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I have two queries, one relating to MPR election in OLSR and the other is more a request for advice regarding Cluster Head election for OLSR: =20 1. I read in the OLSR draft that MPR set recalculation should occur when changes are detected in the symmetric and symmetric strict 2 hop neighbourhood. So is it correct to say that during network setup and discovery when HELLO messages are received with asymmetric and subsequently symmetric neighbours in the HELLO message data, that the MPR for that node is computed every time i.e. MPR computation is happening upon receipt of every HELLO msg that causes a neighbourhood change? It continues to do this until a stable set of MPRs are found (assuming no mobility at the moment)? I had originally thought that MPR calculation occurs after a pre-defined period of time.=20 =20 2. I am implementing hierarchical OLSR. I want to elect a cluster head based on a weighted metric transmitted in the HELLO messages. When a node receives this HELLO message it will store the metric along with the originator neighbour IP address in its neighbour table. I thought that after a period of time all nodes would run an algorithm to determine if they had the highest metric compared to that of their neighbours and hence would elect themselves as the CH and notify their neighbours. However I am not sure as to what how I should define this time (or if I should even do it this way since MPRs are computed every time a change is noted if point 1 is correct) - I need to ensure that the network has first converged and that all nodes have communicated their HELLOs and built their neighbour tables before I make the decision to elect the CH- the question is when to make that decision as making the decision too soon could mean its not based on a fully converged neighbour set. =20 Any advice/comments would be greatly appreciated. =20 Kind Regards, Aisling O' Driscoll. =20 =20 ------_=_NextPart_001_01C7EB0B.842800A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have two queries, one relating to MPR = election in OLSR and the other is more a request for advice regarding Cluster Head = election for OLSR:

 

  1. I read in = the OLSR draft that MPR set recalculation should occur when changes are = detected in the symmetric and symmetric strict 2 hop neighbourhood. So is it = correct to say that during network setup and discovery when HELLO messages = are received with asymmetric and subsequently symmetric neighbours in = the HELLO message data, that the MPR for that node is computed every = time i.e. MPR computation is happening upon receipt of every HELLO msg that = causes a neighbourhood change? It continues to do this until a stable set of = MPRs are found (assuming no mobility at the moment)? I had originally = thought that MPR calculation occurs after a pre-defined period of time. =

 

  1. I am = implementing hierarchical OLSR. I want to elect a cluster head based on a = weighted metric transmitted in the HELLO messages. When a node receives this = HELLO message it will store the metric along with the originator = neighbour IP address in its neighbour table. I thought that after a period of = time all nodes would run an algorithm to determine if they had the highest = metric compared to that of their neighbours and hence would elect = themselves as the CH and notify their neighbours. However I am not sure as to = what how I should define this time (or if I should even do it this way since = MPRs are computed every time a change is noted if point 1 is correct) = – I need to ensure that the network has first converged and that all nodes = have communicated their HELLOs and built their neighbour tables before I = make the decision to elect the CH– the question is when to make = that decision as making the decision too soon could mean its not = based on a fully converged neighbour set.

 

Any advice/comments would be greatly = appreciated.

 

Kind Regards,

Aisling O’ = Driscoll.

 

 

------_=_NextPart_001_01C7EB0B.842800A2-- --===============0692992244== 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 --===============0692992244==-- From manet-bounces@ietf.org Thu Aug 30 10:46: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 1IQlGc-0008S5-2O; Thu, 30 Aug 2007 10:45:06 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IQlGa-0008P1-To for manet-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 10:45:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQlGa-0008Ml-Gf for manet@ietf.org; Thu, 30 Aug 2007 10:45:04 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQlGW-0002r3-GM for manet@ietf.org; Thu, 30 Aug 2007 10:45:04 -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 l7UEiwxF010737 for ; Thu, 30 Aug 2007 15:44:58 +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 l7UEixTn004497 for ; Thu, 30 Aug 2007 15:44:59 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 30 Aug 2007 15:44:58 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 15:44:58 +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] MPR election in standard OLSR and Clusterhead Election inHierarchical OLSR Date: Thu, 30 Aug 2007 15:44:57 +0100 Message-ID: In-Reply-To: <07C0AAD24E652548B1F528DED7C034FD02572CA6@sf-1.cit.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] MPR election in standard OLSR and Clusterhead Election inHierarchical OLSR thread-index: AcfrC18JjtKdqbMyQsyUQkRteBzXwgACDyPQ References: <07C0AAD24E652548B1F528DED7C034FD02572CA6@sf-1.cit.ie> From: "Dearlove, Christopher \(UK\)" To: "Aisling ODriscoll" , X-OriginalArrivalTime: 30 Aug 2007 14:44:58.0199 (UTC) FILETIME=[563BEE70:01C7EB14] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Comment with >. I don't have a comment on point 2. =20 1. I read in the OLSR draft that MPR set recalculation should occur when changes are detected in the symmetric and symmetric strict 2 hop neighbourhood. So is it correct to say that during network setup and discovery when HELLO messages are received with asymmetric and subsequently symmetric neighbours in the HELLO message data, that the MPR for that node is computed every time i.e. MPR computation is happening upon receipt of every HELLO msg that causes a neighbourhood change? It continues to do this until a stable set of MPRs are found (assuming no mobility at the moment)? I had originally thought that MPR calculation occurs after a pre-defined period of time.=20 > It is defined as recalculating it every time. But waiting for a (short) period after a node > starts up is, I think, perfectly reasonable behaviour. Note that there's no reason to calculate > an MPR Set other than to report it in a HELLO message, but on the other hand a recalculated > MPR Set may be a reason to send a HELLO message. ******************************************************************** 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 Aug 31 06:23: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 1IR3cy-0004Zn-S3; Fri, 31 Aug 2007 06:21:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IR3cx-0004Ze-N4 for manet-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 06:21:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR3cx-0004ZV-91 for manet@ietf.org; Fri, 31 Aug 2007 06:21:23 -0400 Received: from sf-1.cit.ie ([157.190.22.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR3cv-0007rP-QS for manet@ietf.org; Fri, 31 Aug 2007 06:21:23 -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] MPR election in standard OLSR and Clusterhead Election inHierarchical OLSR Date: Fri, 31 Aug 2007 11:23:24 +0100 Message-ID: <07C0AAD24E652548B1F528DED7C034FD02572DDB@sf-1.cit.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] MPR election in standard OLSR and Clusterhead Election inHierarchical OLSR Thread-Index: AcfrC18JjtKdqbMyQsyUQkRteBzXwgACDyPQAClPUiA= References: <07C0AAD24E652548B1F528DED7C034FD02572CA6@sf-1.cit.ie> From: "Aisling ODriscoll" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Thanks to both Chris and Mathieu for the replies. -----Original Message----- From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]=20 Sent: 30 August 2007 15:45 To: Aisling ODriscoll; manet@ietf.org Subject: RE: [manet] MPR election in standard OLSR and Clusterhead Election inHierarchical OLSR Comment with >. I don't have a comment on point 2. =20 1. I read in the OLSR draft that MPR set recalculation should occur when changes are detected in the symmetric and symmetric strict 2 hop neighbourhood. So is it correct to say that during network setup and discovery when HELLO messages are received with asymmetric and subsequently symmetric neighbours in the HELLO message data, that the MPR for that node is computed every time i.e. MPR computation is happening upon receipt of every HELLO msg that causes a neighbourhood change? It continues to do this until a stable set of MPRs are found (assuming no mobility at the moment)? I had originally thought that MPR calculation occurs after a pre-defined period of time.=20 > It is defined as recalculating it every time. But waiting for a (short) period after a node > starts up is, I think, perfectly reasonable behaviour. Note that there's no reason to calculate > an MPR Set other than to report it in a HELLO message, but on the other hand a recalculated > MPR Set may be a reason to send a HELLO message. ******************************************************************** 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 Aug 31 20:13: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 1IRGak-0007Fg-FT; Fri, 31 Aug 2007 20:11:58 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IRGai-00072T-NW for manet-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 20:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRGai-00070h-CM for manet@ietf.org; Fri, 31 Aug 2007 20:11:56 -0400 Received: from bay0-omc1-s41.bay0.hotmail.com ([65.54.246.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRGag-0006Eb-SR for manet@ietf.org; Fri, 31 Aug 2007 20:11:56 -0400 Received: from hotmail.com ([207.46.10.242]) by bay0-omc1-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Aug 2007 17:11:54 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 31 Aug 2007 17:11:53 -0700 Message-ID: Received: from 207.46.10.254 by by122fd.bay122.hotmail.msn.com with HTTP; Sat, 01 Sep 2007 00:11:51 GMT X-Originating-IP: [87.101.244.7] X-Originating-Email: [najoola_moon@hotmail.com] X-Sender: najoola_moon@hotmail.com In-Reply-To: From: "* najool *" To: manet@ietf.org Bcc: Date: Sat, 01 Sep 2007 03:11:51 +0300 Mime-Version: 1.0 X-OriginalArrivalTime: 01 Sep 2007 00:11:53.0839 (UTC) FILETIME=[B38C6FF0:01C7EC2C] X-Spam-Score: 2.8 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [manet] RE: manet Digest, Vol 40, Issue 37 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="===============0338551243==" Errors-To: manet-bounces@ietf.org --===============0338551243== Content-Type: text/html; format=flowed


 Dear all,
 
I'm beginner in ns-2 simulation.. i would like to use it in my master project to test my new developed energy efficient protocol for WSN
 
I'm interesting in WSN routing protocol simulation on ns-2, and I need to find such code.. my question is about running such code on windows (cygwin) platform?
 
 
 I'm happy to know what you think about this.. also if there is any resources, advices or any other direction about simulation in ns-2 and its result it's will be very useful
 
Best Regards,
-Najla

 


 

From:  manet-request@ietf.org
Reply-To:  manet@ietf.org
To:  manet@ietf.org
Subject:  manet Digest, Vol 40, Issue 37
Date:  Fri, 31 Aug 2007 12:00:23 -0400
>Send manet mailing list submissions to
> manet@ietf.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/manet
>or, via email, send a message with subject or body 'help' to
> manet-request@ietf.org
>
>You can reach the person managing the list at
> manet-owner@ietf.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of manet digest..."
>
>
>Today's Topics:
>
>    1. RE: MPR election in standard OLSR and Clusterhead Election
>       inHierarchical OLSR (Aisling ODriscoll)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 31 Aug 2007 11:23:24 +0100
>From: "Aisling ODriscoll" <Aisling.ODriscoll@cit.ie>
>Subject: RE: [manet] MPR election in standard OLSR and Clusterhead
> Election inHierarchical OLSR
>To: <manet@ietf.org>
>Message-ID: <07C0AAD24E652548B1F528DED7C034FD02572DDB@sf-1.cit.ie>
>Content-Type: text/plain; charset="us-ascii"
>
>Thanks to both Chris and Mathieu for the replies.
>
>-----Original Message-----
>From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]
>Sent: 30 August 2007 15:45
>To: Aisling ODriscoll; manet@ietf.org
>Subject: RE: [manet] MPR election in standard OLSR and Clusterhead
>Election inHierarchical OLSR
>
>
>Comment with >. I don't have a comment on point 2.
>
>1. I read in the OLSR draft that MPR set recalculation should occur
>when changes are detected in the symmetric and symmetric strict 2 hop
>neighbourhood. So is it correct to say that during network setup and
>discovery when HELLO messages are received with asymmetric and
>subsequently symmetric neighbours in the HELLO message data, that the
>MPR for that node is computed every time i.e. MPR computation is
>happening upon receipt of every HELLO msg that causes a neighbourhood
>change? It continues to do this until a stable set of MPRs are found
>(assuming no mobility at the moment)? I had originally thought that MPR
>calculation occurs after a pre-defined period of time.
>
> > It is defined as recalculating it every time. But waiting for a
>(short) period after a node
> > starts up is, I think, perfectly reasonable behaviour. Note that
>there's no reason to calculate
> > an MPR Set other than to report it in a HELLO message, but on the
>other hand a recalculated
> > MPR Set may be a reason to send a HELLO message.
>
>********************************************************************
>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
>
>
>End of manet Digest, Vol 40, Issue 37
>*************************************

Don't just search. Find. MSN Search Check out the new MSN Search! --===============0338551243== 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 --===============0338551243==--