From manet-bounces@ietf.org Sun Jul 01 01:45: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 1I4sFF-0002g2-VZ; Sun, 01 Jul 2007 01:45:13 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I4sFE-0002f5-0w for manet-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 01:45:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4sFD-0002ei-G5 for manet@ietf.org; Sun, 01 Jul 2007 01:45:11 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4sF8-0002v0-WB for manet@ietf.org; Sun, 01 Jul 2007 01:45:11 -0400 Received: by ug-out-1314.google.com with SMTP id u2so951565uge for ; Sat, 30 Jun 2007 22:45:06 -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=qzowhEjtCncyPUq1iiGHU22sr5Xl2xvKutGMAVqLB76xGL/4c+BMN9PGH8zkfnx5EOqYr6tjkEp6xTn+UlmG1EqgQKslgVBUJk2in1CcM20ltob3VvMsWIAwn9wfp0zb5pvpTPnTNknWFVDJVYl++o7NAC3ckJxK/YSTiSy7L6g= 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=ROBO9z8lvhjDHUr2qPDb4NRGf3zgWlNDuaf3TCfFsIpm8mVl4NgeMEng8M6SZTtVYyATtA8s60VMXkLenH2FtmqEiyJwfg+UAw+rTTZEUzx7vIZnbVvbSMFlrVO27rsEeTI6Cv2HPC2igcJYKAXd0MH1AnYEC1IfJFMSU5WakO0= Received: by 10.78.175.14 with SMTP id x14mr2374388hue.1183268706124; Sat, 30 Jun 2007 22:45:06 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Sat, 30 Jun 2007 22:45:06 -0700 (PDT) Message-ID: <374005f30706302245r532ac2bdr821da70cad5e163b@mail.gmail.com> Date: Sun, 1 Jul 2007 11:15:06 +0530 From: "Ian Chakeres" To: manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Christopher Dearlove , "Thomas Heide Clausen \(work\)" Subject: [manet] draft-ietf-manet-jitter - Informational Document - WGLC 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 This note starts the WG Last Call for comments on draft-ietf-manet-jitter-00.txt, "Jitter considerations in MANETs". The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-manet-jitter-00.txt The document is intended to be submitted for publication as an informational document. Please review the document carefully and send your comments to the MANET list and document authors. This last call will end Sunday July 15th. Thanks, Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jul 02 04:31: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 1I5HJW-0000Ld-GV; Mon, 02 Jul 2007 04:31:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I5HJU-0000LU-KS for manet-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 04:31:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5HJU-0000LM-AG for manet@ietf.org; Mon, 02 Jul 2007 04:31:16 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5HIY-0005Og-HG for manet@ietf.org; Mon, 02 Jul 2007 04:31:16 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l628UHnV024599 for ; Mon, 2 Jul 2007 09:30:17 +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 l628UHC5030366 for ; Mon, 2 Jul 2007 09:30:17 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 02 Jul 2007 09:30:17 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 09:30:17 +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, 2 Jul 2007 09:30:16 +0100 Message-ID: In-Reply-To: <374005f30706302245r532ac2bdr821da70cad5e163b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-manet-jitter - Informational Document - WGLC Thread-Index: Ace7ovzEp08s1zKtRaSxbCaZrHKI2wA4AILg References: <374005f30706302245r532ac2bdr821da70cad5e163b@mail.gmail.com> From: "Dearlove, Christopher \(UK\)" To: "Ian Chakeres" , "manet" X-OriginalArrivalTime: 02 Jul 2007 08:30:17.0222 (UTC) FILETIME=[3827D260:01C7BC83] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "Thomas Heide Clausen \(work\)" Subject: [manet] RE: draft-ietf-manet-jitter - Informational Document - WGLC 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 Obviously I support this, but note that this document has a (non-normative) reference to packetbb in it, so I'd like to encourage the chairs to WGLC that too. -----Original Message----- From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 Sent: 01 July 2007 06:45 To: manet Cc: Joe P Macker (home); Thomas Heide Clausen (work); Dearlove, Christopher (UK); Brian Adamson Subject: draft-ietf-manet-jitter - Informational Document - WGLC *** 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 This note starts the WG Last Call for comments on draft-ietf-manet-jitter-00.txt, "Jitter considerations in MANETs". The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-manet-jitter-00.txt The document is intended to be submitted for publication as an informational document. Please review the document carefully and send your comments to the MANET list and document authors. This last call will end Sunday July 15th. Thanks, Ian Chakeres ******************************************************************** 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 Jul 02 04:49: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 1I5HbS-0007AR-D8; Mon, 02 Jul 2007 04:49:50 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I5HbQ-0007AJ-Cg for manet-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 04:49:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5HbQ-0007AB-2E for manet@ietf.org; Mon, 02 Jul 2007 04:49:48 -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 1I5HbH-0000ym-Oi for manet@ietf.org; Mon, 02 Jul 2007 04:49:48 -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 l628nc89008802 for ; Mon, 2 Jul 2007 09:49:38 +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 l628nc3O014635 for ; Mon, 2 Jul 2007 09:49:38 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 02 Jul 2007 09:49:37 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 09:49:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] RE: draft-ietf-manet-jitter - Informational Document - WGLC Date: Mon, 2 Jul 2007 09:49:37 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] RE: draft-ietf-manet-jitter - Informational Document - WGLC Thread-Index: Ace7ovzEp08s1zKtRaSxbCaZrHKI2wA4AILgAACOJtA= References: <374005f30706302245r532ac2bdr821da70cad5e163b@mail.gmail.com> From: "Dearlove, Christopher \(UK\)" To: "Dearlove, Christopher \(UK\)" , "Ian Chakeres" , "manet" X-OriginalArrivalTime: 02 Jul 2007 08:49:37.0698 (UTC) FILETIME=[EBDA6820:01C7BC85] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 My apologies to the chairs, I'd failed to note that the lastest revisions we've submitted last Friday haven't emerged from the system yet. Note that (apart from reference versions, author URLs and stuff like that) there's no technical difference between the jitter ID you have and the one coming. That's not true of the other three IDs (all of ours except OLSRv2 - which needs, wnd will soon get, revisions for these and other reasons) which have technical changes (mainly TLV subtypes). -----Original Message----- From: Dearlove, Christopher (UK)=20 Sent: 02 July 2007 09:30 To: Ian Chakeres; manet Cc: Thomas Heide Clausen (work) Subject: [manet] RE: draft-ietf-manet-jitter - Informational Document - WGLC Obviously I support this, but note that this document has a (non-normative) reference to packetbb in it, so I'd like to encourage the chairs to WGLC that too. -----Original Message----- From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 Sent: 01 July 2007 06:45 To: manet Cc: Joe P Macker (home); Thomas Heide Clausen (work); Dearlove, Christopher (UK); Brian Adamson Subject: draft-ietf-manet-jitter - Informational Document - WGLC *** 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 This note starts the WG Last Call for comments on draft-ietf-manet-jitter-00.txt, "Jitter considerations in MANETs". The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-manet-jitter-00.txt The document is intended to be submitted for publication as an informational document. Please review the document carefully and send your comments to the MANET list and document authors. This last call will end Sunday July 15th. Thanks, Ian Chakeres ******************************************************************** 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 Jul 02 09:23: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 1I5LsP-0007sm-EC; Mon, 02 Jul 2007 09:23:37 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I5LsN-0007sh-W9 for manet-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 09:23:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5LsN-0007sZ-MT for manet@ietf.org; Mon, 02 Jul 2007 09:23:35 -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 1I5LsJ-0002aT-5I for manet@ietf.org; Mon, 02 Jul 2007 09:23:35 -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 l62DNULw006291 for ; Mon, 2 Jul 2007 14:23: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 l62DNTFu019286 for ; Mon, 2 Jul 2007 14:23:29 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 02 Jul 2007 14:23:29 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 14:23:29 +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, 2 Jul 2007 14:23:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on DYMO-09 Thread-Index: Ace8rC16X6gAobViQneHhjEMz4rY+g== From: "Dearlove, Christopher \(UK\)" To: "manet" , "Ian Chakeres" , "Charles E. Perkins" X-OriginalArrivalTime: 02 Jul 2007 13:23:29.0398 (UTC) FILETIME=[2DE8D960:01C7BCAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Subject: [manet] Comments on DYMO-09 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 made these as ink on a paper copy without an electronic copy, so apologies if I missed something where I suggest some thing is missing. I've ignored typos (not that there are many I spotted). What I haven't followed through is some of the details of things like (in particular) comparison of information for which is better. - The example message pictures are based on out of date packetbb - and not just not based on the one in the IETF secretariat queue. But I'm afraid I haven't worked out a correct version. Of particular note is the changed message and TLV semantics and the new(-ish) address block semantics. - On reading the overview my first though is "that doesn't work, it assumes bidirectionality". While the overview isn't the place to spell out a mechanism to only use bidirectional links, I think it needs to make the point there's an issue and refer forwards. Actually what it refers forwards to is an issue, but that's a later point below. - To make DYMO work, you need three things that OLSRv2, for example, doesn't need (though if it had them it could make use of them, especially the last): how to know that a route is needed, how to know a route is still in use, what to do with packets while waiting to find a route. I think at the least these need to be spelled out, even if only to say they aren't part of DYMO as such. (Of course if these are suggestions, e.g. ARP failures, or if you know whose problem they are - IP for packet queuing? - these are good comments.) These seem to me to belong in Section 2. - On the rest of Section 2, can you go beyond stub networks (is this a necessary limitation? - I'm not saying it's not, I'm just not wanting you to underclaim). Also the little routing state comment is dependent on the earlier limited communications poin - and if you do too much path accumulation etc. you can blow it even then. And it's "some" other routing protocols I think - is DYMO much better than DSR (or AODV, but DYMO is really AODVv2). In the last sentence I'd remove the () as the words in it are fundamental - you really don't want to suggest it's true with the whole parenthesis removed! - I wondered if the terminology would be better if under RERR etc. it explicitlty said "a message type". (That's a definite "take it or leave it" comment.) - In 4.2.1 the brief description must be improved by noting that DYMO doesn't need a packet header. But maybe it does, see a later comment. (If it does, that's a comment.) - UDP port TBD hasn't caught up with draft-iana. (Several places.) - When you say IP TTL (IP Hop Limit) I'd insert a v4 and v6. - Final line of 4.2.1. There are two mechanisms in RFC 4291, one is deprecated. We just added to packetbb an extra phrase indicating which one to use in our similar paragraph. It might keep some people happier. - Sequence numbers. If I understand correctly, you start at 1, then when you get to 65535, skip 0 (as it's special) but then go to 256, not 1. I can't see anything saying why, nor do I understand why. (It makes the 16 bit comparison a bit lop-sided, but frankly if you are comparing numbers 30,000 apart there's a problem anyway.) - 5.3.1 just mentions expanding ring search, and refers to AODV for details. Can you (IETF procedure here) delegate details of your Standards Track protocol to an Experimental RFC? I'm also (section 5.4) not sure the exponential backoff is quite as detailed as I would have suggested. But this might not matter if it's not interoperability critical. - 5.3.3 uses gratuitous RREP. Suggest adding that to the terminology. - Later (5.3.4 made me think of it, but it's not specific to there) I wondered does DYMO do network aggregation? What happens if I have a route to A.B.0.0/16 and I get a more, or less, up to date route to A.B.C.0/24? Or the other way round? Would it matter if they had the same next hop? Or are those two routes treated as chalk and cheese and never compared? (I was wondering about the state minimisation and if this helped.) - Last paragraph of 5.4 refers to "the buffer". This ties in with comments on Section 2. Whose buffer? Can we rely on IP doing this? What about that buffering is a two-edged sword, it can really mess up TCP, for example. (The buffer may be seconds long I think.) - Section 5.5. This might be another issue for Section 2, that DYMO needs to be able to manage ICMP. - Section 5.5.1. Interaction of DYMO and NHDP is potentially interesting. If you just want to manage links (and that they are symmetric even) you only need a subset of NHDP. With all of NHDP you could add MPRs (which aren't in NHDP but in OLSRv2) and start optimised flooding. But that's not as reactive as you might like - and there's an interoperability issue (everyone needs to do it - I think). But the point is NHDP is likley to be too much or too little, but not exactly right. (For the "too much" case we could probably work out some words as to what to exclude. Multiple interface issues might matter.) - Section 6. Do you need exponential backoff and expanding ring parameters? - Section 7. Need to discuss subtypes. I suggest using packetbb and TimeTLV as models for what needs saying. - Section 7.2. Have I missed something, or is the text buried in the Value discussion of Table 5 of the IANA considerations section the only text that discusses the unidirectional link issue? If so that really needs to be in the main protocol section, in detail. By being a packet TLV it also suggests you need a packet header, which also needs saying earlier. - I didn't follow some of the Security Considerations discussion. (I know that doesn't actually help.) - Section 9 - DSR is now an RFC. - References - Should draft-iana be normative? ******************************************************************** 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 Jul 02 14:26: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 1I5QbW-0000uO-O6; Mon, 02 Jul 2007 14:26:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I5QbT-0000sa-On for manet-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 14:26:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5QbT-0000sR-FE for manet@ietf.org; Mon, 02 Jul 2007 14:26:27 -0400 Received: from web32704.mail.mud.yahoo.com ([68.142.207.248]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5QbP-0001rp-4R for manet@ietf.org; Mon, 02 Jul 2007 14:26:27 -0400 Received: (qmail 2347 invoked by uid 60001); 2 Jul 2007 18:26:22 -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=zNFm4CxBPYliMuE4fXCP4DYVxC5HJooFsRimaGw3k1vnWQe3gSxRC7APc4G40cHjNnDdCNVGQBYgUmdQm8hdMteFRhjui7I+a9k1dwaOJXI3b3KC216FNKT+WCnoNGtsaEABuGtLLp+8DR5mpH1XYUgh5CgK9eKDllDn04V5EYw=; X-YMail-OSG: jkGgk2EVM1mYJI1EwmA7FQ7ctWY.TPj6liMnVsou7wJY7aQI4ANynGuM1aOcIWhxAtCBn5C4SiZJE3saqGMxUmcH62x4MQU7tvIZsIiM46kTPOz3SqB3bsvHplxTdw-- Received: from [80.191.197.107] by web32704.mail.mud.yahoo.com via HTTP; Mon, 02 Jul 2007 11:26:22 PDT Date: Mon, 2 Jul 2007 11:26:22 -0700 (PDT) From: hamid reza To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <390540.98698.qm@web32704.mail.mud.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [manet] Question about 802.11 Behaviour on its IFS ( SIFS and DIFS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear All, What happend For a node when a node want to send a packet Recieve another Packet on its IFS(SIFS or DIFS) ? Best Regards Hamid Reza ____________________________________________________________________________________ Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jul 03 04:40: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 1I5dvg-0001Qs-Ia; Tue, 03 Jul 2007 04:40:12 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I5dvf-0001Qk-Il for manet-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 04:40:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5dvf-0001Qc-6Q for manet@ietf.org; Tue, 03 Jul 2007 04:40:11 -0400 Received: from web32713.mail.mud.yahoo.com ([68.142.206.26]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5dvX-0003iO-Sa for manet@ietf.org; Tue, 03 Jul 2007 04:40:11 -0400 Received: (qmail 55665 invoked by uid 60001); 3 Jul 2007 08:33:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tg/lmlmfnwHCygI9gbEQCB0p8gBYlEfDRcfoBx/cIkACFu6QowyZqiW+dFW4+/m4GLW0ZBPBDTfQK+6tJtTXxIV44TQQQD0DhI1RRhEKZ6TZjazw9B2WV234NffgjGvAxGBooEiAPzclpbDbSZBN+/Jn3sT4ZqFhOUMp9ps/BRw= ; Message-ID: <20070703083321.55663.qmail@web32713.mail.mud.yahoo.com> X-YMail-OSG: L4KB6JIVM1mwEKBc_pCcaWk0nPObPeHdtRYTf4BhZXZTENpAj.9samY8B6CaCpQm0lCSMtV60X1ZMM7cbJQbzeNz6TcoehDeKV0YYHVEFOKhAWoz0Hd295BniVJqPw-- Received: from [209.190.12.31] by web32713.mail.mud.yahoo.com via HTTP; Tue, 03 Jul 2007 01:33:21 PDT Date: Tue, 3 Jul 2007 01:33:21 -0700 (PDT) From: hamid reza To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [manet] 802.11 Question (About IFS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear All, What happend For a node when a node want to send a packet Recieve another Packet on its IFS(SIFS or DIFS) ? Best Regards Hamid Reza ____________________________________________________________________________________ Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jul 03 14:15: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 1I5muY-0006u5-Eu; Tue, 03 Jul 2007 14:15:38 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I5mu7-0006Nq-92 for manet-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 14:15:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5mu6-0006LR-Ax; Tue, 03 Jul 2007 14:15:10 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5mty-00053O-IY; Tue, 03 Jul 2007 14:15:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 59C0826ED1; Tue, 3 Jul 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5mty-0002H0-0u; Tue, 03 Jul 2007 14: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, 03 Jul 2007 14:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-packetbb-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Generalized MANET Packet/Message Format Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-packetbb-07.txt Pages : 49 Date : 2007-7-3 This document specifies a multi-message packet format that may be used by mobile ad hoc network routing and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-packetbb-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-packetbb-07.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-7-3134801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-packetbb-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-packetbb-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-3134801.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 Jul 03 14:15: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 1I5mui-00079Q-Jm; Tue, 03 Jul 2007 14:15:48 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I5muD-0006VA-2p for manet-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 14:15:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5muB-0006Sx-LL; Tue, 03 Jul 2007 14:15:15 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5mu5-00054L-Jp; Tue, 03 Jul 2007 14:15:15 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5A38126ED4; Tue, 3 Jul 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5mty-0002Gx-08; Tue, 03 Jul 2007 14: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, 03 Jul 2007 14:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-jitter-01.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-01.txt Pages : 16 Date : 2007-7-3 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-01.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-01.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-01.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-7-3134634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-jitter-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-jitter-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-3134634.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 Jul 03 14:15: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 1I5muX-0006tm-ER; Tue, 03 Jul 2007 14:15:37 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I5mu6-0006ND-T4 for manet-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 14:15:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5mu6-0006KD-4n; Tue, 03 Jul 2007 14:15:10 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5mty-00053K-7L; Tue, 03 Jul 2007 14:15:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 31C63328CF; Tue, 3 Jul 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5mty-0002H3-1n; Tue, 03 Jul 2007 14: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, 03 Jul 2007 14:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-timetlv-01.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-01.txt Pages : 16 Date : 2007-7-3 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 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-01.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-01.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-01.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-7-3134955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-timetlv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-timetlv-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-3134955.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 Jul 03 14:16:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5muz-00083v-BY; Tue, 03 Jul 2007 14:16:05 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I5muT-0006oD-MY for manet-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 14:15:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5muT-0006nH-1f; Tue, 03 Jul 2007 14:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5muS-0007DK-RM; Tue, 03 Jul 2007 14:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 868FD1764A; Tue, 3 Jul 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5mty-0002H6-33; Tue, 03 Jul 2007 14: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, 03 Jul 2007 14:15:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-nhdp-04.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 : MANET Neighborhood Discovery Protocol (NHDP) Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-nhdp-04.txt Pages : 55 Date : 2007-7-3 This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-04.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-nhdp-04.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-nhdp-04.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-7-3135107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-nhdp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-nhdp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-3135107.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Wed Jul 04 04:48: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 1I60X6-0000Zy-Q7; Wed, 04 Jul 2007 04:48:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I60X5-0000Zn-3t for manet-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 04:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I60X4-0000Zf-OK for manet@ietf.org; Wed, 04 Jul 2007 04:48:18 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I60Wz-00083S-PY for manet@ietf.org; Wed, 04 Jul 2007 04:48: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 l648mCtJ012668 for ; Wed, 4 Jul 2007 09:48:12 +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 l648mCfe009106 for ; Wed, 4 Jul 2007 09:48:12 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 04 Jul 2007 09:48:12 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 09:48:10 +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, 4 Jul 2007 09:48:10 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Four new Internet Drafts Thread-Index: Ace+GAya3UcyWAIRQL68pIoXll/zEw== From: "Dearlove, Christopher \(UK\)" To: "manet" X-OriginalArrivalTime: 04 Jul 2007 08:48:10.0881 (UTC) FILETIME=[0CEEAF10:01C7BE18] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [manet] Four new Internet Drafts 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 Four of the five Internet Drafts that make up OLSRv2 have just been reissued. (We're working on the fifth one, the actual OLSRv2 draft to catch up with these and other changes - the latest published version is not consistent with these, or their immediate predecessors) Essentially, the changes are adding TLV subtypes to packetbb, and knock on effects to the other documents. (There's a small change to the constraints section of packetbb as well.) ******************************************************************** 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 Jul 05 04:20: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 1I6MZO-0002Np-MF; Thu, 05 Jul 2007 04:20:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I6MZN-0002Nf-OT for manet-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 04:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6MZN-0002MZ-9Z for manet@ietf.org; Thu, 05 Jul 2007 04:20:09 -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 1I6MZI-0004u7-S7 for manet@ietf.org; Thu, 05 Jul 2007 04:20:09 -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 l658K3F0002225 for ; Thu, 5 Jul 2007 09:20:03 +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 l658K3VA002975 for ; Thu, 5 Jul 2007 09:20:03 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 05 Jul 2007 09:20:03 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 09:20:03 +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] I-D ACTION:draft-ietf-manet-packetbb-07.txt Date: Thu, 5 Jul 2007 09:20:02 +0100 Message-ID: In-Reply-To: <374005f30707042056p39cd2420paaaffafa9b3585ed@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] I-D ACTION:draft-ietf-manet-packetbb-07.txt Thread-Index: Ace+uHjYkRBKoDEfSQ+dXE7yqz827QAI/2SQ References: <374005f30707042050s7af46985w945611972dad204e@mail.gmail.com> <374005f30707042056p39cd2420paaaffafa9b3585ed@mail.gmail.com> From: "Dearlove, Christopher \(UK\)" To: "Ian Chakeres" , "Thomas Heide Clausen \(work\)" X-OriginalArrivalTime: 05 Jul 2007 08:20:03.0108 (UTC) FILETIME=[495AB640:01C7BEDD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Bother. Thanks for the catch Ian. Looks like we're going to need a packetbb-08 shortly. -----Original Message----- From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 Sent: 05 July 2007 04:56 To: Thomas Heide Clausen (work); Dearlove, Christopher (UK) Subject: Re: [manet] I-D ACTION:draft-ietf-manet-packetbb-07.txt TYPO =3D ? ? ? ? ? Should have ? following tlv-semantics. Ian ******************************************************************** 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 Jul 05 18:16: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 1I6ZcX-0006EI-Hf; Thu, 05 Jul 2007 18:16:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I6ZcA-0004dw-3m for manet-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 18:15:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Zc9-0004ab-25; Thu, 05 Jul 2007 18:15:53 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6Zc8-0004xg-Ra; Thu, 05 Jul 2007 18:15:52 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A99D72AC97; Thu, 5 Jul 2007 22:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6ZbK-0006HB-Ci; Thu, 05 Jul 2007 18: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: Thu, 05 Jul 2007 18:15:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-dymo-10.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Dynamic MANET On-demand (DYMO) Routing Author(s) : C. Perkins, I. Chakeres Filename : draft-ietf-manet-dymo-10.txt Pages : 34 Date : 2007-7-5 The Dynamic MANET On-demand (DYMO) routing protocol is intended for use by mobile modes in wireless, multihop networks. It offers adaptation to changing network topology and determines unicast routes between DYMO routers within the network in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-dymo-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-dymo-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-5170604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-dymo-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-dymo-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-5170604.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Fri Jul 06 04:35: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 1I6jHh-0004jy-8I; Fri, 06 Jul 2007 04:35:25 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I6jHf-0004jl-BM for manet-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 04:35:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jHe-0004jc-SZ for manet@ietf.org; Fri, 06 Jul 2007 04:35:22 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I6jHe-00043Z-I7 for manet@ietf.org; Fri, 06 Jul 2007 04:35:22 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1183710897!9051577!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 3902 invoked from network); 6 Jul 2007 08:34:57 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-12.tower-128.messagelabs.com with SMTP; 6 Jul 2007 08:34:57 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l668YvnN011328 for ; Fri, 6 Jul 2007 01:34:57 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l668Yujw014308 for ; Fri, 6 Jul 2007 03:34:56 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l668YsDZ014277 for ; Fri, 6 Jul 2007 03:34:55 -0500 (CDT) Message-ID: <468DFEAD.1030109@gmail.com> Date: Fri, 06 Jul 2007 10:34:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000754-2, 05/07/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [manet] intermediate DYMO node as MANEMO Mobile Router 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, thanks for updating the DYMO draft with, among others, updates to the intermediate DYMO node section 5.3.3. I think it still needs updating, because the intermediate DYMO router acting as a MANEMO Mobile Router should not send RREP to the RREQ's Target Node (presumably this is the LFN) because LFN already has a route to the MR (received either by RA as default route, or statically configured) and because LFN doesn't speak DYMO anyways. Currently the DYMO draft says: > The Intermediate DYMO router SHOULD also issue a RREP to the RREQ > TargetNode, so that the RREQ TargetNode receives routing information > on how to reach the RREQ OrigNode. What do you think? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jul 06 04:57: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 1I6jdB-0000CA-4g; Fri, 06 Jul 2007 04:57:37 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I6jd8-0008Nq-Ts for manet-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 04:57:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jd8-0008M9-FF for manet@ietf.org; Fri, 06 Jul 2007 04:57:34 -0400 Received: from hpsmtp-eml16.kpnxchange.com ([213.75.38.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6jd4-0002PU-2q for manet@ietf.org; Fri, 06 Jul 2007 04:57:34 -0400 Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml16.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 10:57:28 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 10:57:28 +0200 From: "Teco Boot" To: "'manet'" Date: Fri, 6 Jul 2007 10:58:21 +0200 Message-ID: <007701c7bfab$ce05d4f0$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: Ace/q82TEbWsrsNAQC2WXhWIiRMtZg== X-OriginalArrivalTime: 06 Jul 2007 08:57:28.0470 (UTC) FILETIME=[AE1B8360:01C7BFAB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [manet] DYMO MANET restriction on using only one Internet gateway 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 Questions on DYMO and stub MANET: Is there a hard limit on using only one Internet attachment? Why? Acceptable? Adding the restriction in Applicability Statement? The outcome would have a large impact on Autoconf and MANEMO work. Teco. > 5.8. Simple Internet Attachment and Gatewaying > > Simple Internet attachment consists of a stub network of MANET router > connected to the Internet via a single Internet gateway node. The > gateway is responsible for responding to RREQs for TargetNodes > outside its configured DYMO prefix, as well as delivering packets to > destinations outside the MANET. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jul 06 05:00: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 1I6jfp-00042U-BW; Fri, 06 Jul 2007 05:00:21 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I6jfo-00042P-Bp for manet-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 05:00:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jfo-00042H-2D for manet@ietf.org; Fri, 06 Jul 2007 05:00:20 -0400 Received: from ik-out-1112.google.com ([66.249.90.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6jfk-0002he-NQ for manet@ietf.org; Fri, 06 Jul 2007 05:00:20 -0400 Received: by ik-out-1112.google.com with SMTP id b32so136469ika for ; Fri, 06 Jul 2007 02:00: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tIf72wiNUhBZA6Oybg0kArTdJ77VlhyXGhKkBEAqoA9ZF5zpXr7TIdCGahHdLELvkT7UJKLHXKzACa3BvA11f5yy91kizaKAQYAFC8tkqB7LlplVg3IqZgA/zbw+tgjbIYCCeNtIClNwHcPfyD7MPAEgyJfCmIBmmz0nlHQziLE= 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=X65sDVgNG5W4/aKsjqbXi0q229gifvXH4i2o1cnsn8aekdgABDuRBagHrAP+GBRM8COyCkBXVrLN1XkvIAqGyfd3pMH/HgI3Kduo6I7xP/ypTx7LZiwyL/JsYzcUUFBvE7UMJh81yOpC1oiUEXw325TQqTZlK7goikf/CXKA3jI= Received: by 10.78.183.8 with SMTP id g8mr198607huf.1183712415774; Fri, 06 Jul 2007 02:00:15 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Fri, 6 Jul 2007 02:00:15 -0700 (PDT) Message-ID: <374005f30707060200v74d78db7lc6c698c87a5d0dfb@mail.gmail.com> Date: Fri, 6 Jul 2007 14:30:15 +0530 From: "Ian Chakeres" To: "Teco Boot" Subject: Re: [manet] DYMO MANET restriction on using only one Internet gateway In-Reply-To: <007701c7bfab$ce05d4f0$0202a8c0@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <007701c7bfab$ce05d4f0$0202a8c0@Teco> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org DYMO is not limited to one gateway, but the base spec only specifies the single gateway case. Ian Chakeres On 7/6/07, Teco Boot wrote: > Questions on DYMO and stub MANET: > Is there a hard limit on using only one Internet attachment? > Why? > Acceptable? > Adding the restriction in Applicability Statement? > > The outcome would have a large impact on Autoconf and MANEMO work. > > Teco. > > > > 5.8. Simple Internet Attachment and Gatewaying > > > > Simple Internet attachment consists of a stub network of MANET router > > connected to the Internet via a single Internet gateway node. The > > gateway is responsible for responding to RREQs for TargetNodes > > outside its configured DYMO prefix, as well as delivering packets to > > destinations outside the 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 Jul 06 05:05: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 1I6jkl-000287-Bv; Fri, 06 Jul 2007 05:05:27 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I6jkh-000265-M3 for manet-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 05:05:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jkh-00025x-Ce for manet@ietf.org; Fri, 06 Jul 2007 05:05:23 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6jkd-0003ai-1V for manet@ietf.org; Fri, 06 Jul 2007 05:05:23 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1745907uge for ; Fri, 06 Jul 2007 02:05:18 -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=XE42H8WH01TEF7wdwCjZ4QTpIW+f5iT3jo6yhXIsLmsSlGorZo5WR5b6mxjsmYzx5V9v2elL8d54wcN5DBhAqlYssgBLSvvnGNyysvi+NIlVaPw86VJA40gj+B4DVX38b3LfzCgMcTIdsz0LIr3DC4VWDB1cVYfVRXIh3376VZs= 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=iCaEfwBBOOKxQTBCGTaHr9qXhfUgVk1kkQqal7smuT5ML6spw1SVmPLTShb/4d4G5QXxIxCtMGGm9qDndTriGm932p27RzUIETzk0ZRWw81GLe55gdgamZtBIiE6SfFwR9J1hAYtPGjXb3ODFtxg337qL39v66AWUGSO7w4gKIc= Received: by 10.78.142.14 with SMTP id p14mr199774hud.1183712717918; Fri, 06 Jul 2007 02:05:17 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Fri, 6 Jul 2007 02:05:17 -0700 (PDT) Message-ID: <374005f30707060205v1e71ae85h3e5f977917d0ad0d@mail.gmail.com> Date: Fri, 6 Jul 2007 14:35:17 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] intermediate DYMO node as MANEMO Mobile Router In-Reply-To: <468DFEAD.1030109@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <468DFEAD.1030109@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I am not understanding the problem. Can you please provide me with the text to "fix" things for you? Ian Chakeres On 7/6/07, Alexandru Petrescu wrote: > Ian, thanks for updating the DYMO draft with, among others, updates to > the intermediate DYMO node section 5.3.3. > > I think it still needs updating, because the intermediate DYMO router > acting as a MANEMO Mobile Router should not send RREP to the RREQ's > Target Node (presumably this is the LFN) because LFN already has a route > to the MR (received either by RA as default route, or statically > configured) and because LFN doesn't speak DYMO anyways. Currently the > DYMO draft says: > > > The Intermediate DYMO router SHOULD also issue a RREP to the RREQ > > TargetNode, so that the RREQ TargetNode receives routing information > > on how to reach the RREQ OrigNode. > > What do you think? > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jul 06 05:39: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 1I6kHP-0002Ex-Qa; Fri, 06 Jul 2007 05:39:11 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I6kHN-0002El-Ob for manet-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 05:39:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6kHL-0002Ed-Ri for manet@ietf.org; Fri, 06 Jul 2007 05:39:08 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I6kHL-00036v-G8 for manet@ietf.org; Fri, 06 Jul 2007 05:39:07 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1183714730!1080631!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9456 invoked from network); 6 Jul 2007 09:38:50 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with SMTP; 6 Jul 2007 09:38:50 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l669cjS5010343; Fri, 6 Jul 2007 02:38:45 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l669cjYA018278; Fri, 6 Jul 2007 04:38:45 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l669ciYx018275; Fri, 6 Jul 2007 04:38:44 -0500 (CDT) Message-ID: <468E0DA3.6060604@gmail.com> Date: Fri, 06 Jul 2007 11:38:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] intermediate DYMO node as MANEMO Mobile Router References: <468DFEAD.1030109@gmail.com> <374005f30707060205v1e71ae85h3e5f977917d0ad0d@mail.gmail.com> In-Reply-To: <374005f30707060205v1e71ae85h3e5f977917d0ad0d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000754-2, 05/07/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > I am not understanding the problem. Can you please provide me with > the text to "fix" things for you? Replace the "SHOULD" with a "MAY" in the paragraph below? >>> The Intermediate DYMO router SHOULD also issue a RREP to the RREQ >>> TargetNode, so that the RREQ TargetNode receives routing >>> information on how to reach the RREQ OrigNode. Alex > > Ian Chakeres > > > On 7/6/07, Alexandru Petrescu wrote: >> Ian, thanks for updating the DYMO draft with, among others, updates >> to the intermediate DYMO node section 5.3.3. >> >> I think it still needs updating, because the intermediate DYMO >> router acting as a MANEMO Mobile Router should not send RREP to the >> RREQ's Target Node (presumably this is the LFN) because LFN already >> has a route to the MR (received either by RA as default route, or >> statically configured) and because LFN doesn't speak DYMO anyways. >> Currently the DYMO draft says: >> >>> The Intermediate DYMO router SHOULD also issue a RREP to the RREQ >>> TargetNode, so that the RREQ TargetNode receives routing >>> information on how to reach the RREQ OrigNode. >> >> What do you think? >> >> Alex >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> >> >> _______________________________________________ manet mailing list >> manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jul 06 05:52:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6kTo-0008WU-Ft; Fri, 06 Jul 2007 05:52:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I6kTn-0008WK-ED for manet-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 05:51:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6kTn-0008WC-4B for manet@ietf.org; Fri, 06 Jul 2007 05:51:59 -0400 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6kTm-0004bE-Sm for manet@ietf.org; Fri, 06 Jul 2007 05:51:59 -0400 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 11:51:41 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 11:51:41 +0200 From: "Teco Boot" To: Date: Fri, 6 Jul 2007 11:52:34 +0200 Message-ID: <008f01c7bfb3$61049550$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 In-Reply-To: <374005f30706210432p40ec0e2ew508a7c2a2b642990@mail.gmail.com> Thread-Index: Acez+C4Y4u5AnkGeSbqtQOLSaQYc0ALuqlTA X-OriginalArrivalTime: 06 Jul 2007 09:51:41.0422 (UTC) FILETIME=[410498E0:01C7BFB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [manet] MANET metric document 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 look forward to seeing the metric document. > Ian [Teco] Is the metric document published? Need any help? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jul 06 06:15: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 1I6kqh-0008Ll-8n; Fri, 06 Jul 2007 06:15:39 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I6kqf-0008Be-Al for manet-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 06:15:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6kqe-00087D-RL for manet@ietf.org; Fri, 06 Jul 2007 06:15:36 -0400 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6kqa-0001b5-H8 for manet@ietf.org; Fri, 06 Jul 2007 06:15:36 -0400 Received: by wx-out-0506.google.com with SMTP id h27so145497wxd for ; Fri, 06 Jul 2007 03:15: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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sENrvlLlOKJk0LC/krdgb7L+t2vOy6NFD9jPDCiX/xYbfYaqVop399VlbWTaqGbcbbz9AGpGf5k0PP1VtoYSWQ7O4XF6V75TFLg5zqSndGQbZUT8XHd88aAkIcBZqaVWg0TfzTP0jVso1fCxHwQwBpub8bRvtyfZkih7TrvXFH8= 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=A+WtnTlrchueCCzfCcGwX78SrBBp2MbXxHhsPRzdbtql0VOJWHHk2i+BGA/i/7u+fukOcEJvxhkYTXr2m3MfxXAE84G77zb1UIFzf6VELvAlKNY6Hb0ePqvvd1GsTolEcqA3/Xx/uPsF+to5jTFnHb0DL2dbllUlyX7eOxJSP4Y= Received: by 10.78.185.15 with SMTP id i15mr237165huf.1183716930889; Fri, 06 Jul 2007 03:15:30 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Fri, 6 Jul 2007 03:15:30 -0700 (PDT) Message-ID: <374005f30707060315g2e13c6c4ve65acb4c2e8d6185@mail.gmail.com> Date: Fri, 6 Jul 2007 15:45:30 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] intermediate DYMO node as MANEMO Mobile Router In-Reply-To: <468E0DA3.6060604@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <468DFEAD.1030109@gmail.com> <374005f30707060205v1e71ae85h3e5f977917d0ad0d@mail.gmail.com> <468E0DA3.6060604@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org In this situation if DYMO router don't issue a RREP, there is a good likelihood that the destination's DYMO router doesn't have a router to the source's DYMO router. If that happens, another route discovery will occur, and route discovery is expensive. I think you are misunderstanding what's going on. I will write you a private email to describe normal routers' behavior while participating in a routing protocol on behalf of their attached nodes. Ian Chakeres On 7/6/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > > I am not understanding the problem. Can you please provide me with > > the text to "fix" things for you? > > Replace the "SHOULD" with a "MAY" in the paragraph below? > > >>> The Intermediate DYMO router SHOULD also issue a RREP to the RREQ > >>> TargetNode, so that the RREQ TargetNode receives routing > >>> information on how to reach the RREQ OrigNode. > > Alex > > > > > Ian Chakeres > > > > > > On 7/6/07, Alexandru Petrescu wrote: > >> Ian, thanks for updating the DYMO draft with, among others, updates > >> to the intermediate DYMO node section 5.3.3. > >> > >> I think it still needs updating, because the intermediate DYMO > >> router acting as a MANEMO Mobile Router should not send RREP to the > >> RREQ's Target Node (presumably this is the LFN) because LFN already > >> has a route to the MR (received either by RA as default route, or > >> statically configured) and because LFN doesn't speak DYMO anyways. > >> Currently the DYMO draft says: > >> > >>> The Intermediate DYMO router SHOULD also issue a RREP to the RREQ > >>> TargetNode, so that the RREQ TargetNode receives routing > >>> information on how to reach the RREQ OrigNode. > >> > >> What do you think? > >> > >> Alex > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security > >> System. For more information please visit > >> http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > >> > >> > >> _______________________________________________ manet mailing list > >> manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > >> > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jul 06 08:40: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 1I6n6r-00038b-1s; Fri, 06 Jul 2007 08:40:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I6n6o-00038U-KO for manet-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 08:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6n6o-00038M-Au for manet@ietf.org; Fri, 06 Jul 2007 08:40:26 -0400 Received: from ik-out-1112.google.com ([66.249.90.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6n6j-0007uv-UX for manet@ietf.org; Fri, 06 Jul 2007 08:40:26 -0400 Received: by ik-out-1112.google.com with SMTP id b32so182019ika for ; Fri, 06 Jul 2007 05:40:21 -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=Mm03tDJDdnhP8pz84fJryD8cDi2B9OF/Z9cPgdlMQxYR95o9THaXyOClAyZpSEklSMvZdgQSIllVaCOJCJHN9v2tBYTDgm0QyLzrL+A3QNgxkTOk4UNvAe/gpGIBR8gHpVwszmg1Z+zPUOQanbT9bBm9UCbhQBpQQa+JdOKNj04= 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=dNycCD5agW3LAa/D/NftvnLOULea3HxlJ0rMB0zMxE7E2uDQAPNFHp9NQGwxdcY0oW7vRh6C92lFjWcU8S8M5xUSnkGu3ibEA7Ub2xKZhBvhwVCZDxYJTOmoL7XmH8H9eI1ssXC/AFq/iEPGFwZvIxI7d+6PGKLDNl4u0nPk91M= Received: by 10.78.156.6 with SMTP id d6mr277428hue.1183725617966; Fri, 06 Jul 2007 05:40:17 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Fri, 6 Jul 2007 05:40:17 -0700 (PDT) Message-ID: <374005f30707060540u514426f0xfd38c33558aff38c@mail.gmail.com> Date: Fri, 6 Jul 2007 18:10:17 +0530 From: "Ian Chakeres" To: manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Christopher Dearlove , Cedric Adjih , "Thomas Heide Clausen \(work\)" Subject: [manet] draft-ietf-manet-packetbb - WG LC 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 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 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Jul 07 08:44: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 1I79dp-0007Rs-6q; Sat, 07 Jul 2007 08:44:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I6tc0-0001zl-L2 for manet-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 15:37:04 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I6tc0-0001yR-BK for manet@ietf.org; Fri, 06 Jul 2007 15:37:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6tKF-00020s-V1 for manet@ietf.org; Fri, 06 Jul 2007 15:18:43 -0400 Received: from out1.smtp.messagingengine.com ([66.111.4.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6tJb-0001hh-5a for manet@ietf.org; Fri, 06 Jul 2007 15:18:43 -0400 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 0A459629D for ; Fri, 6 Jul 2007 15:18:03 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 06 Jul 2007 15:18:03 -0400 X-Sasl-enc: NVM4Py9zFSr/OD2S6bB6dNmPdCrpzXWDRWUShoDrHdbx 1183749482 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 9D4921B97F for ; Fri, 6 Jul 2007 15:18:02 -0400 (EDT) Message-ID: <468E9569.2000402@icir.org> Date: Fri, 06 Jul 2007 20:18:01 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-TMDA-Confirmed: Fri, 06 Jul 2007 15:37:04 -0400 X-Mailman-Approved-At: Sat, 07 Jul 2007 08:43:59 -0400 Subject: [manet] Looking for an RA-OLSR normative reference 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, I am one of the XORP developers: http://www.xorp.org/ I am currently performing initial requirements analysis for an RFC-compliant implementation of the OLSRv1 routing protocol as part of the XORP router architecture. I have noted that the 802.11s TG are investigating the use of OLSR as a link-state protocol for MP-to-MP forwarding in 802.11s ESS Mesh networks, as 'RA-OLSR', and would like to investigate the feasibility of making the XORP implementation capable of performing RA-OLSR routing functions at a later date; focusing on IPv4/IPv6 unicast forwarding initially, with route redistribution capabilities between MANET domains and existing 'Big-I' Internet routing domains (BGP, IS-IS). Whilst I can see some of the comments in the 802.11s ratification process on the IEEE web sites, I have not yet found anything resembling a draft specification for how RA-OLSR is transmitted on the wire, or how it is derived from the existing specification of OLSR. Many thanks for any help you can provide. Kind regards BMS _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jul 09 02:20: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 1I7mbS-0005q5-Mp; Mon, 09 Jul 2007 02:20:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I7mbP-0005pR-TT for manet-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 02:20:07 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I7mbP-0005p7-GR for manet@ietf.org; Mon, 09 Jul 2007 02:20:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7mXw-0004hq-Km for manet@ietf.org; Mon, 09 Jul 2007 02:16:32 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7mXs-0004aK-De for manet@ietf.org; Mon, 09 Jul 2007 02:16:32 -0400 Received: by wx-out-0506.google.com with SMTP id h27so710738wxd for ; Sun, 08 Jul 2007 23:16:28 -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=p1MQs7mzKkXcRKYi3QfuHPiyRMmP2/lhSsWxQcigLFk+ZXsq1XX3kYCr+eJsF0MIrTqyNgjkpUkn61UQhiZWfAm2UR728Mh+xanPdPsDaoP6xfkcHLVmHl4leu2MuNapIswZCRx4LlZNuQ3GA0CLU8U8cv/5BVGFyA9s3faKxtw= 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=bR502WOn1+QX41T9xQheE0oIwAp9u5eEogrQ19SPbcF7qh3cvO5FNeq94IlnK+O8bqgqbUSteGEszrZLfptoMhQ5Trl52bx3HbfITPfzpkbQlA8pgdjok5vHQtj9s/bLMra1ARnPJ4vwfkhVtDtW5gwhvghcInK68MfFgtGgLTY= Received: by 10.90.25.3 with SMTP id 3mr1401278agy.1183961788117; Sun, 08 Jul 2007 23:16:28 -0700 (PDT) Received: by 10.90.75.17 with HTTP; Sun, 8 Jul 2007 23:16:28 -0700 (PDT) Message-ID: <4e1036220707082316l3e9bd8e1hdfaed61cafc8dba7@mail.gmail.com> Date: Mon, 9 Jul 2007 11:16:28 +0500 From: "ambreen SHEIKH" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-TMDA-Confirmed: Mon, 09 Jul 2007 02:20:07 -0400 Subject: [manet] regarding the ns2 patch for 802.11e 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="===============1616560809==" Errors-To: manet-bounces@ietf.org --===============1616560809== Content-Type: multipart/alternative; boundary="----=_Part_186921_21865494.1183961788081" ------=_Part_186921_21865494.1183961788081 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline hello !! can anyone guide me from where i can download the ns2 patch for 802.11 for the ns-allinone-2.29 version i will be very thankful regards ------=_Part_186921_21865494.1183961788081 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
hello !!
 
can anyone guide me from where i can download the ns2 patch for 802.11 for the ns-allinone-2.29 version
 
i will be very thankful
 
 
regards
------=_Part_186921_21865494.1183961788081-- --===============1616560809== 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 --===============1616560809==-- From manet-bounces@ietf.org Mon Jul 09 16:28:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zpw-0005yQ-Qr; Mon, 09 Jul 2007 16:28:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I7zpv-0005yI-Jy for manet-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 16:27:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zpv-0005y7-9v; Mon, 09 Jul 2007 16:27:59 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7zpq-0005hT-Sx; Mon, 09 Jul 2007 16:27:59 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Jul 2007 16:27:54 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAIo2kkZAZnmf/2dsb2JhbACCLzM X-IronPort-AV: i="4.16,518,1175486400"; d="scan'208,217"; a="125605636:sNHT45757256" 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 l69KRsls008909; Mon, 9 Jul 2007 16:27:54 -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 l69KRr6a019341; Mon, 9 Jul 2007 20:27:54 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, 9 Jul 2007 16:27:52 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 16:27:52 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: rsn@ietf.org Message-Id: <0492560A-D76C-4D8D-82E8-E78A4AF2A39C@cisco.com> From: JP Vasseur Date: Mon, 9 Jul 2007 16:27:18 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Jul 2007 20:27:52.0744 (UTC) FILETIME=[A0235A80:01C7C267] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3944; t=1184012874; x=1184876874; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Update |Sender:=20 |To:=20rsn@ietf.org; bh=+QD+NH2/ON4jhQOZWFA7BWMXKdWIDtoYTRIsbUtb0Vw=; b=qS/FU/zlY0V3Qiy1PPeTIiuq85OcQwH1omBVfWCp6A1sWOkZfOdc7uMCtwhKc943KXRAh3mq Fc8pntD5mnShhzwEuBLFnjKAJLFkEHRs5NUgh4aMmq6iLBgLuAeQChZ6; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: manet@ietf.org, manemo@mobileip.jp Subject: [manet] Update 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="===============1791911847==" Errors-To: manet-bounces@ietf.org --===============1791911847== Content-Type: multipart/alternative; boundary=Apple-Mail-9--452791207 --Apple-Mail-9--452791207 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, As agreed on the list some time ago, several new IDs have been posted: 1) The generic requirements ID: "Routing Requirements for Low Power And Lossy Networks" - draft- culler-rl2n-routing-reqs-01 http://www.ietf.org/internet-drafts/draft-culler-rl2n-routing- reqs-01.txt 2) Application-specific routing requirements for L2Ns * Home Automation "Home Automation Routing Requirement in Low Power and Lossy Networks" - draft-brandt-rl2n-home-routing-reqs-01 http://www.ietf.org/internet-drafts/draft-brandt-rl2n-home-routing- reqs-01.txt * Industrial: in the works * Healthcare: TBD 3) Survey on existing protocols. "Overview of Existing Wireless Mesh Routing Protocols for Low Power and Lossy Networks" - draft-levis-rl2n-overview-protocols-01 http://www.ietf.org/internet-drafts/draft-levis-rl2n-overview- protocols-01.txt => This is a **very** first draft that definitely requires more work but a good start. We should be having within a 3-4 weeks timeframe a more fleshed out version. Thanks. JP and David. --Apple-Mail-9--452791207 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

As agreed on the list some = time ago, several new IDs have been posted:

1) The generic requirements = ID:
= "Routing Requirements for Low Power And Lossy Networks" = -=A0draft-culler-rl2n-routing-reqs-01

2) Application-specific = routing requirements for L2Ns
* Home = Automation
"Home Automation Routing = Requirement in Low Power and Lossy Networks" = -=A0draft-brandt-rl2n-home-routing-reqs-01
* Industrial: in the = works
* Healthcare: = TBD

3) = Survey on existing protocols.
"Overview of Existing Wireless = Mesh Routing Protocols for Low Power and Lossy Networks" = -=A0draft-levis-rl2n-overview-protocols-01
=3D> This is a **very** first draft = that definitely requires more work but a good start. We should be having = within a 3-4 weeks timeframe
a more fleshed out = version.

Thanks.

JP and = David.
= --Apple-Mail-9--452791207-- --===============1791911847== 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 --===============1791911847==-- From manet-bounces@ietf.org Tue Jul 10 22:30: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 1I8RyV-0004WE-9Q; Tue, 10 Jul 2007 22:30:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I8RyT-0004Jl-Ay for manet-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 22:30:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8RyS-0004HR-Iy for manet@ietf.org; Tue, 10 Jul 2007 22:30:40 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8RyO-0002H1-86 for manet@ietf.org; Tue, 10 Jul 2007 22:30:40 -0400 Received: by ug-out-1314.google.com with SMTP id u2so34559uge for ; Tue, 10 Jul 2007 19:30:35 -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=nFHD5zz1SZuymjf+/NZw92zg64etTkxj5HbQgzM1lK+kDnq28orBQ3R/PriARLicvlrDwf5/Le1eogYSMaYzM1ORZFuNxtpNZZ5x1DAYiKzQI69eGjY+uLdACTfz4U/W/j9LgmPbuK+HdQ1tM9WStvALIZD5UcCu7vnpFnPeIrY= 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=PvGyeTzVUvlxabHDtxYUuArZN5JNAR58d8Jqj172M3ZZ7/MXh3r5z+ea+U1pPGsdzqcmtHOBjrG7a0exj1d0rKBdJIuoOfTUEG4wZFfpJvMQVNCfGSsoTRpxLgxzh9Qiw1GIMUKM3MCQIHE5nJbm4t2FoHQirS7qoVhqK3Ra5PU= Received: by 10.78.172.20 with SMTP id u20mr2279162hue.1184121035251; Tue, 10 Jul 2007 19:30:35 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Tue, 10 Jul 2007 19:30:35 -0700 (PDT) Message-ID: <374005f30707101930t38b5f465gf707845a60d5544a@mail.gmail.com> Date: Wed, 11 Jul 2007 08:00:35 +0530 From: "Ian Chakeres" To: manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [manet] Draft Agenda for MANET WG at IETF 69 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 MANET meeting is scheduled for Wed March 25th at 9am. I've posted a draft agenda at http://www3.ietf.org/proceedings/07jul/agenda/manet.txt. If you have any other topics you'd like added, please email Joe & I ASAP. I'd also like to use this opportunity to ask you to give a thorough review to http://www.ietf.org/internet-drafts/draft-ietf-manet-jitter-01.txt and http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-07.txt. Both these documents are in working group last call. Please also review the other current WG documents. A complete list with links can be found on our charter page at http://www.ietf.org/html.charters/manet-charter.html. I look forward to seeing you in Chicago. Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jul 11 02:37: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 1I8Vol-0007ZV-KT; Wed, 11 Jul 2007 02:36:55 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I8Voj-0007O7-5G for manet-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 02:36:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Voi-0007Lh-Mi for manet@ietf.org; Wed, 11 Jul 2007 02:36:52 -0400 Received: from eddings.acpub.duke.edu ([152.3.233.76]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Vog-0007ho-EP for manet@ietf.org; Wed, 11 Jul 2007 02:36:52 -0400 Received: from [192.168.1.101] (rrcs-24-199-204-131.midsouth.biz.rr.com [24.199.204.131]) by eddings.acpub.duke.edu (8.12.11.20060308/8.12.10/Duke-5.0.0) with ESMTP id l6B6Xv26015083; Wed, 11 Jul 2007 02:33:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <82F1566C-B01D-4159-87DA-F9D21AA2B512@ee.duke.edu> To: manet@ietf.org, tccc@cs.columbia.edu From: Romit Roy Choudhury Date: Wed, 11 Jul 2007 02:36:19 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Subject: [manet] Registration open for MobiHoc 07 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="===============0113435093==" Errors-To: manet-bounces@ietf.org --===============0113435093== Content-Type: multipart/alternative; boundary=Apple-Mail-3--329850988 --Apple-Mail-3--329850988 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed ------------------------------------------------------------------------ -- REGISTRATION IS NOW OPEN FOR MobiHoc 2007 ------------------------------------------------------------------------ -- MobiHoc 2007 8th ACM International Symposium on Mobile Ad Hoc Networking and Computing Sep 9-14, 2007, Montreal, Canada http://www.sigmobile.org/mobihoc/2007/ Sponsored by ACM SIGMOBILE ACM MobiHoc is the premier international meeting dedicated to addressing challenges emerging from wireless ad hoc networking and computing. This year program will include a highly selective, technical program, as well as hands-on research demonstrations, keynote, panel, and tutorials. --Apple-Mail-3--329850988 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
-------------------------------------------------------= -------------------
REGISTRATION IS = NOW OPEN FOR MobiHoc 2007

MobiHoc 2007
8th ACM International = Symposium on=A0Mobile Ad Hoc Networking and Computing

Sep 9-14, 2007, Montreal, = Canada

Sponsored by ACM SIGMOBILE

ACM MobiHoc is the premier = international meeting dedicated to
addressing challenges = emerging from wireless ad hoc networking and
computing. This year program=A0 will include a = highly
selective, technical program, as well as=A0hands-on = research demonstrations,=A0
keynote, panel, and = tutorials.

= --Apple-Mail-3--329850988-- --===============0113435093== 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 --===============0113435093==-- From manet-bounces@ietf.org Wed Jul 11 02:53: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 1I8W4l-00088n-Ux; Wed, 11 Jul 2007 02:53:27 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I8W4k-00088e-Ex for manet-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 02:53:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8W4h-00088P-50 for manet@ietf.org; Wed, 11 Jul 2007 02:53:23 -0400 Received: from web58911.mail.re1.yahoo.com ([66.196.100.244]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I8W4d-0006ng-Cy for manet@ietf.org; Wed, 11 Jul 2007 02:53:23 -0400 Received: (qmail 70471 invoked by uid 60001); 11 Jul 2007 06:53:19 -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=59Zsve8YlrEPQNjk3Ly+78ynVV7ZA5ZzseXTedrX/HUJMzF70i4rQzAan2zbjx+3MU3QGTDS/yANEiwWOEK2oBBdGGHfoOb3YjPTlfOkagLDIsE/4YVGKWwG+QxXU/wZLvcu1I3bfk5hyw+kMvEnO3vcNqzjfUBvdBBmI5740E4=; X-YMail-OSG: TALvhU4VM1k5xwa9uVDjx96g5fiZTw3EoQ3E1SCmGjZrDP3c1klhU1e4B2QKwjBg2hWXwn3netV4p7i0aFWdQ70r_DOpEVfPtTlkZL2h6PC.kp7Wx8hWXCkvuAdAYHA- Received: from [213.176.96.17] by web58911.mail.re1.yahoo.com via HTTP; Tue, 10 Jul 2007 23:53:19 PDT Date: Tue, 10 Jul 2007 23:53:19 -0700 (PDT) From: allyon feredian To: manet@ietf.org MIME-Version: 1.0 Message-ID: <70219.70027.qm@web58911.mail.re1.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [manet] cluster-based routing algorithm in GLOMOSIM X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1888464832==" Errors-To: manet-bounces@ietf.org --===============1888464832== Content-Type: multipart/alternative; boundary="0-728606490-1184136799=:70027" Content-Transfer-Encoding: 8bit --0-728606490-1184136799=:70027 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hello all ! I need a cluster-based routing algorithm implemented in GLOMOSIM simulator. I searched for it but can not find any file. can anyone help me? thanks all. Allyon feredian --------------------------------- Need a vacation? Get great deals to amazing places on Yahoo! Travel. --0-728606490-1184136799=:70027 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
hello all !
I need a cluster-based routing algorithm implemented in GLOMOSIM simulator. I searched for it but can not find any file.
can anyone help me?
thanks all.
Allyon feredian

Need a vacation? Get great deals to amazing places on Yahoo! Travel. --0-728606490-1184136799=:70027-- --===============1888464832== 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 --===============1888464832==-- From manet-bounces@ietf.org Wed Jul 11 20:23:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8mSO-0005pw-0i; Wed, 11 Jul 2007 20:22:56 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I8mSM-0005pk-Bz for manet-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 20:22:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8mSM-0005pH-24 for manet@ietf.org; Wed, 11 Jul 2007 20:22:54 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8mSI-0004N1-Mh for manet@ietf.org; Wed, 11 Jul 2007 20:22:54 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6C0MnMx015333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 11 Jul 2007 17:22:50 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6C0MnoX027125 for ; Wed, 11 Jul 2007 19:22:49 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6C0MmjE027106 for ; Wed, 11 Jul 2007 19:22:49 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 17:22:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jul 2007 17:22:48 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED901@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <374005f30707101930t38b5f465gf707845a60d5544a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-manet-smf-05.txt Thread-Index: AcfDY6u8BwYK2PIeTheZ1ni4DTugEAAtqzrg References: <374005f30707101930t38b5f465gf707845a60d5544a@mail.gmail.com> From: "Templin, Fred L" To: "manet" X-OriginalArrivalTime: 12 Jul 2007 00:22:48.0876 (UTC) FILETIME=[C6E9E6C0:01C7C41A] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [manet] comments on draft-ietf-manet-smf-05.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 This document is important and needs to go forward soon, but overall comment is that the IPv4 DPD appears tenuous. Specific comments follow: Fred fred.l.templin@boeing.com 1) (editorial) Abstract, s/educed/reduced/ 2) (semi-substantial) Section 4, the term "local host" is used incorrectly in several places. In particular, hosts do not forward packets; routers do. Suggest changing "local host" to one of router/MANET router/SMF router. 3) (substantial) Section 5.1, first paragraph, this text is advocating having network elements rewrite the ip_id field. The ip_id field is specified as to be set in a manner chosen by the source and used by the destination; it is therefore an end-to-end consideration and not something intended for modification by network middleboxes. Even if this were not so, however, the disadvantages listed in the final paragraph of Section 5.1 would seem to offset any perceived benefits in ip_id rewriting, and may preclude a truly general-purpose solution since it may not work well in all environments. 4) (semi-substantial) Sec 5.1, third paragraph, an arbitrary multicast source cannot necessarily determine that it is an "SMF intended source" and as such cannot be counted on to set the DF bit. Suggest dropping this paragraph, as there should be no perceived difference between multicast data plane forwarding in an SMF forwarding region than in any other multicast forwarding region. 5) (semi-editorial) Section 5.2.2, the "Tagger ID" field is variable-length, but Fig. 3 does not show it as such. 6) (semi-editorial) Section 5.2.2, the variable name: "DPD packet identifier" in the text does not match the field name "DPD Sequence Value" in Fig. 3. 7) (semi-editorial) Section 5.2.2, the table of Tagger ID type values, for value 3 change: "IPv4 address" to: "IPv6 address". Also, the table should have a caption. 8) (semi-substantial) Section 5.2.2, the IDLen field length of only 4bits restricts the potential length of the Tagger ID field to at most 16 octets. But, future uses may require a longer field for a different sort of ID such as the tagger's public key, a DNS FQDN, etc. Possible solution is to reserve one ID type (e.g., 7) as an indication that an "extended" IDType/IDLen field follows (reserved for future use is fine). 9) (editorial) Section 5.2.4, s/[RFC1321]hash/[RFC1321] hash/ 10) (editorial) Section 5.2.4, s/is only be/is only being/, and immediately afterward s/reasonable/reasonably/. 11) (editorial) A number of additional editorial items similar to 9) and 10) appear throughout the rest of the document; these will presumably be corrected by RFC editor. 12) (substantial) Section 8.3, suggest dropping re-sequencing of ip_id, i.e., same comment as 3). 13) (suggestion) Instead of having an SMF forwarding node re-sequence an IPv4 multicast packet's ip_id, have it encapsulate the packet in an outer IPv4 hdr with source address set to its own IPv4 address, destination address set to a site-scoped "All_SMF_Routers" and ip_id set in a sequencing fashion (e.g., monotonically-increasing). The outer source address is then a "Tagger ID", and the outer ip_id can be used along with the inner (source, destination, ip_id)-tuple as a DPD tag. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jul 12 03:12: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 1I8sq7-0005Gc-SX; Thu, 12 Jul 2007 03:11:51 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I8sq6-0005GV-6b for manet-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 03:11:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8sq5-0005GJ-PB for manet@ietf.org; Thu, 12 Jul 2007 03:11:49 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8spq-0000wn-AB for manet@ietf.org; Thu, 12 Jul 2007 03:11:49 -0400 Received: (qmail 5793 invoked from network); 12 Jul 2007 09:11:00 +0200 Received: from unknown (HELO Teco) (217.169.232.206) by server9.hosting2go.nl with SMTP; 12 Jul 2007 09:11:00 +0200 From: "Teco_Boot" To: "'Templin, Fred L'" Subject: RE: [manet] comments on draft-ietf-manet-smf-05.txt Date: Thu, 12 Jul 2007 09:11:24 +0200 Message-ID: <000301c7c453$edd9c4b0$fe00800a@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 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED901@XCH-NW-7V2.nw.nos.boeing.com> Thread-Index: AcfDY6u8BwYK2PIeTheZ1ni4DTugEAAtqzrgAA3txyA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Comments inline. > 3) (substantial) Section 5.1, first paragraph, this text > is advocating having network elements rewrite the ip_id field. > The ip_id field is specified as to be set in a manner chosen > by the source and used by the destination; it is therefore an > end-to-end consideration and not something intended for > modification by network middleboxes. Even if this were not so, > however, the disadvantages listed in the final paragraph of > Section 5.1 would seem to offset any perceived benefits in ip_id > rewriting, and may preclude a truly general-purpose solution > since it may not work well in all environments. [Teco] Absolutely right. And the proposal breaks RFC791. I know many IP stacks use ip_id different, but IETF documents defining new roles for ip_id shall at least note the difference with RFC791. And argument why the update is needed. Remember also the idea using DPD as filter for looped unicast packets, when a loop occurs during convergence (draft-boot-manet-nemo-analysis-01.txt, section 6.3). _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jul 12 09:29:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8yjD-0000t7-Mt; Thu, 12 Jul 2007 09:29:07 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I8yjC-0000t0-Ck for manet-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 09:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8yjC-0000ss-30 for manet@ietf.org; Thu, 12 Jul 2007 09:29:06 -0400 Received: from insomnia.liquidweb.com ([64.91.225.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8yj8-00028Y-Ra for manet@ietf.org; Thu, 12 Jul 2007 09:29:06 -0400 Received: from confprom by insomnia.liquidweb.com with local (Exim 4.66) (envelope-from ) id 1I8yj4-0005Le-I9; Thu, 12 Jul 2007 09:28:58 -0400 Received: from 64.208.221.2 ([64.208.221.2]) (SquirrelMail authenticated user vicky@confpromo.com) by confpromo.com with HTTP; Thu, 12 Jul 2007 09:28:58 -0400 (EDT) Message-ID: <16030.64.208.221.2.1184246938.squirrel@confpromo.com> Date: Thu, 12 Jul 2007 09:28:58 -0400 (EDT) From: "Vicky Star" To: manet@ietf.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - insomnia.liquidweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32132 32133] / [47 12] X-AntiAbuse: Sender Address Domain - confpromo.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: pdini@cisco.com Subject: [manet] ICNS 2008 || The Fourth International Conference on Networking and Services || March 16-21, 2008 - Gosier, Guadeloupe 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 Invitation: Please consider to contribute and distribute to the appropriate groups the following CALL FOR PAPERS, TUTORIALS, PANELS The Fourth International Conference on Networking and Services ICNS 2008 March 16-21, 2008 - Gosier, Guadeloupe Site: http://www.iaria.org/conferences2008/ICNS08.html Submit a paper: http://www.iaria.org/conferences2008/SubmitICNS08.html Submissions will be peer-reviewed, published by IEEE CPS, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be invited for specialized journals. Important deadlines: Submission deadline: October 5, 2007 Notification of acceptance: November 15, 2007 Registration/camera ready: December 5, 2007 ICNS 2008 Tracks (details in the CfP on site) * ENCOT: Emerging Network Communications and Technologies * COMAN: Network Control and Management * SERVI: Multi-technology service deployment and assurance * NGNUS: Next Generation Networks and Ubiquitous Services * MPQSI: Multi Provider QoS/SLA Internetworking * GRIDNS: Grid Networks and Services * EDNA: Emergency Services and Disaster Recovery of Networks and Applications * IPv6DFI: Deploying the Future Infrastructure * IPDy: Internet Packet Dynamics * GOBS: GRID over Optical Burst Switching Networks ====================== IARIA Publicity Board ====================== _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jul 12 09:33: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 1I8ynT-00085t-Jn; Thu, 12 Jul 2007 09:33:31 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I8ynR-0007w0-Nl for manet-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 09:33:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ynR-0007uc-Ch for manet@ietf.org; Thu, 12 Jul 2007 09:33:29 -0400 Received: from insomnia.liquidweb.com ([64.91.225.210]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8ynR-00017Z-4U for manet@ietf.org; Thu, 12 Jul 2007 09:33:29 -0400 Received: from confprom by insomnia.liquidweb.com with local (Exim 4.66) (envelope-from ) id 1I8yn7-0005m3-4L; Thu, 12 Jul 2007 09:33:09 -0400 Received: from 64.208.221.2 ([64.208.221.2]) (SquirrelMail authenticated user vicky@confpromo.com) by confpromo.com with HTTP; Thu, 12 Jul 2007 09:33:09 -0400 (EDT) Message-ID: <8701.64.208.221.2.1184247189.squirrel@confpromo.com> Date: Thu, 12 Jul 2007 09:33:09 -0400 (EDT) From: "Vicky Star" To: manet@ietf.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - insomnia.liquidweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32132 32133] / [47 12] X-AntiAbuse: Sender Address Domain - confpromo.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: pdini@cisco.com Subject: [manet] ICAS 2008 || The Fourth International Conference on Autonomic and Autonomous Systems || March 16-21, 2008 - Gosier, Guadeloupe 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 ====================== Invitation: Please consider to contribute and distribute to the appropriate groups the following CALL FOR PAPERS, TUTORIALS, PANELS The Fourth International Conference on Autonomic and Autonomous Systems ICAS 2008 March 16-21, 2008 - Gosier, Guadeloupe Site: http://www.iaria.org/conferences2008/ICAS08.html Submit a paper: http://www.iaria.org/conferences2008/SubmitICAS08.html Submissions will be peer-reviewed, published by IEEE CPS, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be invited for specialized journals. Important deadlines: Submission deadline: October 5, 2007 Notification of acceptance: November 15, 2007 Registration/camera ready: December 5, 2007 ICAS 2008 Tracks (details in the CfP on site) * SYSAT: Advances in system automation * AUTSY: Theory and practice of autonomous systems * AWARE: Design and deployment of context-awareness networks, services, and applications * AUTONOMIC: Autonomic computing: design and management of self-behavioral networks and services * MCMAC: Monitoring, control, and management of autonomous self-aware and context-aware systems * CASES: Automation in specialized mobile environments * ALCOC: Algorithms and theory for control and computation * MODEL: Modeling, virtualization, any-on-demand, MDA, SO * SELF: Self-adaptability and self-management of context-aware systems * KUI: Knowledge-based user interface ====================== IARIA Publicity Board ====================== _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jul 12 09:37:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8yr5-0002Be-DO; Thu, 12 Jul 2007 09:37:15 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I8yr4-00029p-H5 for manet-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 09:37:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8yr3-00028Z-LL for manet@ietf.org; Thu, 12 Jul 2007 09:37:14 -0400 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8yqz-0002MI-Sb for manet@ietf.org; Thu, 12 Jul 2007 09:37:13 -0400 Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 9893F95FA; Thu, 12 Jul 2007 09:37:09 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 12 Jul 2007 09:37:09 -0400 X-Sasl-enc: NZTUpQiAR2Kci68ej9YXyJMvn/yaMTMol5jXtL+fdz+7 1184247428 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id ACC111EB62; Thu, 12 Jul 2007 09:37:07 -0400 (EDT) Message-ID: <46962E82.5060908@incunabulum.net> Date: Thu, 12 Jul 2007 14:37:06 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [manet] comments on draft-ietf-manet-smf-05.txt References: <374005f30707101930t38b5f465gf707845a60d5544a@mail.gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED901@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED901@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: manet , Pavlin Radoslavov X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Templin, Fred L wrote: > 13) (suggestion) Instead of having an SMF forwarding node > re-sequence an IPv4 multicast packet's ip_id, have it > encapsulate the packet in an outer IPv4 hdr with source > address set to its own IPv4 address, destination address > set to a site-scoped "All_SMF_Routers" and ip_id set in a > sequencing fashion (e.g., monotonically-increasing). The > outer source address is then a "Tagger ID", and the outer > ip_id can be used along with the inner (source, destination, > ip_id)-tuple as a DPD tag. > The current state of the SMF memo is such that it says nothing about interoperability with existing PIM routing domains. I like this suggestion as it potentially makes the integration of MANET SMF with existing IP multicast forwarding code in BSD-derived code easier. MANET multicast traffic using the SMF scheme needs to be flooded along the MPR mesh; therefore re-assigning the destination address in the outer header is not such a bad idea. Using All_SMF_Routers as a key could be special-cased in the multicast forwarding input path. Legacy versions of this code had to decapsulate IPIP headers to deal with DVMRP tunnels anyway. regards, BMS _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jul 12 12:15: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 1I91KK-0003kF-OZ; Thu, 12 Jul 2007 12:15:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I91Jt-00036n-SC for manet-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 12:15:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91Jt-000365-6o; Thu, 12 Jul 2007 12:15:09 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I91Js-0007Ka-UG; Thu, 12 Jul 2007 12:15:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D00B932A3B; Thu, 12 Jul 2007 16:15:08 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I91Js-0003Fp-9O; Thu, 12 Jul 2007 12:15:08 -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: Thu, 12 Jul 2007 12:15:08 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-olsrv2-04.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 : The Optimized Link State Routing Protocol version 2 Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-olsrv2-04.txt Pages : 79 Date : 2007-7-12 This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for mobile ad hoc networks. The protocol embodies an optimization of the classical link state algorithm tailored to the requirements of a mobile ad hoc network (MANET). The key optimization of OLSRv2 is that of multipoint relays, providing an efficient mechanism for network-wide broadcast of link state information (i.e. reducing the cost of performing a network- wide link state broadcast). A secondary optimization is that OLSRv2 employs partial link state information: each node maintains information about all destinations, but only a subset of links. Consequently, only selected nodes diffuse link state advertisements (thus reducing the number of network-wide link state broadcasts) and these advertisements contain only a subset of links (thus reducing the size of network-wide link state broadcasts). The partial link state information thus obtained still allows each OLSRv2 node to at all times maintain optimal (in terms of number of hops) routes to all destinations in the network. OLSRv2 imposes minimum requirements on the network by not requiring sequenced or reliable transmission of control traffic. Furthermore, the only interaction between OLSRv2 and the IP stack is routing table management. OLSRv2 is particularly suitable for large and dense networks as the technique of MPRs works well in this context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-04.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-olsrv2-04.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-olsrv2-04.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-7-12111223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-olsrv2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-olsrv2-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12111223.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 Jul 12 12:16: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 1I91LL-0005c6-32; Thu, 12 Jul 2007 12:16:39 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I91K4-0003Lc-Ux for manet-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 12:15:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91K3-0003Jq-NZ; Thu, 12 Jul 2007 12:15:19 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I91K3-0005is-GC; Thu, 12 Jul 2007 12:15:19 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 613692AC79; Thu, 12 Jul 2007 16:15:09 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I91Js-0003Fr-AQ; Thu, 12 Jul 2007 12:15:08 -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: Thu, 12 Jul 2007 12:15:08 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-packetbb-08.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Generalized MANET Packet/Message Format Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-packetbb-08.txt Pages : 49 Date : 2007-7-12 This document specifies a multi-message packet format that may be used by mobile ad hoc network routing and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-packetbb-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-packetbb-08.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-7-12111505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-packetbb-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-packetbb-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12111505.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 Jul 12 14:21: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 1I93IG-0005Fo-9r; Thu, 12 Jul 2007 14:21:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I93IE-0005Eh-UB for manet-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 14:21:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93IE-0005Dr-57 for manet@ietf.org; Thu, 12 Jul 2007 14:21:34 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I93I0-00086K-O7 for manet@ietf.org; Thu, 12 Jul 2007 14:21:34 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6CILJAg010773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Jul 2007 11:21:20 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6CILJiW026953 for ; Thu, 12 Jul 2007 13:21:19 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6CILDQL026727 for ; Thu, 12 Jul 2007 13:21:18 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 11:21:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jul 2007 11:20:40 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED904@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED901@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-manet-nhdp-04.txt Thread-Index: AcfDY6u8BwYK2PIeTheZ1ni4DTugEAAtqzrgACWoYAA= References: <374005f30707101930t38b5f465gf707845a60d5544a@mail.gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED901@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "manet" X-OriginalArrivalTime: 12 Jul 2007 18:21:16.0001 (UTC) FILETIME=[6F5D9D10:01C7C4B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [manet] comments on draft-ietf-manet-nhdp-04.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 Comments on this draft follow. By way of disclaimer, these comments are not to be considered as endorsement of the protocol's correctness and/or its applicability for any use-cases. Fred fred.l.templin@boeing.com 1) (semi-substantial) Section 1, first sentence, reference for "MANET" should be draft-ietf-autoconf-manetarch-04.txt (which in turn cites RFC2501). 2) (substantial) Section 2, definitions for {interface, MANET interface, link, symmetric link} need to be squared with draft-ietf-autoconf-manetarch-04.txt. In particular, there is a tension between "link" as "a communications facility at a layer below IP..." (per [MANETARCH], RFCs 2460/2461/2753, etc.), and "link" as a neighboring relationship between nodes (per this document) that needs to be harmonized. Specific suggestion for "link" is: "Link A communications facility at a layer below IP, over which nodes exchange IP packets directly without decrementing IP TTL (Hop Limit) [MANETARCH]. A pairwise link (aka an adjacency) is said to exists between two nodes X and Y if at least one node is heard by the other on the underlying communications facility. The term "link" in this document is therefore used to refer to the pairwise links between two nodes unless otherwise noted." 3) (semi-substantial) Section 4.1, second bullet, "links to this MANET interface" makes no sense, because an interface is a node's attachment to a link; not vice-versa. Change to: "links associated with this MANET interface". 4) (comment) Section 5.1.1, should: "HELLO_INTERVAL" be called: "HELLO_MAX_INTERVAL" instead? 5) (semi-substantial) Section 5.1.1, last paragraph, the term "responsive" is not previously defined and its use here seems ambiguous, e.g., what exactly is a "responsive HELLO message"? The term is used in 4 places throughout the document and seems ambiguous in all 4. Suggest adding "responsive" to terminology. 6) (semi-editorial) Section 6, last sentence of first paragraph, change: "Two addresses" to: "Two identical addresses". 7) (semi-substantial) Section 7, change: "links to that MANET interface" to: "links associated with that MANET interface". (Same comment as 3) above.) 8) (semi-editorial) Section 7, final sentence, same comment as 6) above. 9) (semi-substantial) Section 15, if this document is to go as standards-track, "proposed" should be changed to: "recommended". 10) (comment) Section 15.1, does the recommended HELLO_INTERVAL (HELLO_MAX_INTERVAL?) of 2 seconds relate in any way to the expected characteristics of the underlying communications facility? If so, maybe add a sentence saying so. 11) (semi-substantial) Section 17, add [MANETARCH] as normative reference.=20 (end of comments) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jul 12 20:33:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I995v-0004B1-LR; Thu, 12 Jul 2007 20:33:15 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I995t-0004At-Fw for manet-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 20:33:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I995t-0004Ai-4t for manet@ietf.org; Thu, 12 Jul 2007 20:33:13 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I995k-0005pa-TW for manet@ietf.org; Thu, 12 Jul 2007 20:33:13 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6D0WVgt016982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Jul 2007 17:32:32 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6D0WVnj007424 for ; Thu, 12 Jul 2007 17:32:31 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6D0WUEh007350 for ; Thu, 12 Jul 2007 17:32:31 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 17:32:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jul 2007 17:31:58 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED907@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED904@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-manet-packetbb-08.txt Thread-Index: AcfDY6u8BwYK2PIeTheZ1ni4DTugEAAtqzrgACWoYAAADOedAA== References: <374005f30707101930t38b5f465gf707845a60d5544a@mail.gmail.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED901@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED904@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "manet" X-OriginalArrivalTime: 13 Jul 2007 00:32:30.0592 (UTC) FILETIME=[4C0E7800:01C7C4E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [manet] comments on draft-ietf-manet-packetbb-08.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 Comments on this draft (mostly editorial and clarifying questions) follow. Overall comment is that this all looks computationally expensive, but I have no way of quantifying. Fred fred.l.templin@boeing.com 1) (semi-editorial) Section 2, the definition for "Address" seems self-referential and never really specifies exactly what an "address" is. Since the meaning of "address" is already well understood in the IETF context and presumably no different here, suggest dropping the definition. 2) (editorial) Section 3, s/between in/in/ 3) (comment) Section 4, is this section really necessary? 4) (comment) Section 5.2 and elsewhere, it strikes me as odd that the inclusion of optional fields is consistently phrased in the negative (e.g., noorig, nohoplimit, nohopcount, etc.) such that setting the bit means that the field is not present. It results in casting things in a "double-negative", e.g. noorig=3D0 means that "there is an orig". Any reason these were=20 not phrased in the positive instead? 5) (comment) Section 5.2, a 2-octet field seems excessive, but I guess it is that way for 32-bit alignment? Otherwise, a flag in could be defined to cast is as either a 1-octet or 2-octet field.=20 6) (comment) Section 5.2.1, I'm not seeing the benefit of requiring all addresses to be the same length (i.e., using IPv4-mapped IPv6 addresses if necessary). Wouldn't it make more sense to define an bit that specifies whether an address block contains all-IPv4 or all-IPv6 addresses? 7) (comment) Section 5.3, a fixed of 2-octets seems excessive, but there seems to be no way to shorten it for TLV blocks that are shorter than 255 bytes? 8) (semi-substantial) Section 5.3.1, bit 0 (hassubtype) has switched to phrasing an optional field selector bit in the positive instead of the negative - see 4) above. To be consistent, it should be renamed as "(nosubtype)" with the bit definitions adjusted accordingly. (But IMHO, better would be to phrase all optional field selector bits in the positive.) 9) (comment) Section 5.3.1, under , why is it that: "If present it MUST NOT be zero.", i.e., it is not immediately apparent why a of 0 with a null "MUST NOT" be included? 10) (semi-editorial) Section 5.4, it should be noted that padding is possible and may be desired for other purposes than just 32-bit alignment, e.g., padding all messages to a common size, MTU probing, etc. (end of comments) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jul 13 05:04: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 1I9H4J-0002TZ-IQ; Fri, 13 Jul 2007 05:04:07 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I9H4H-0002Re-RJ for manet-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 05:04:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9H4H-0002RW-Fz for manet@ietf.org; Fri, 13 Jul 2007 05:04:05 -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 1I9H41-0002It-VF for manet@ietf.org; Fri, 13 Jul 2007 05:04:05 -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 l6D92SbO002341 for ; Fri, 13 Jul 2007 10:02:28 +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 l6D92SFu007388 for ; Fri, 13 Jul 2007 10:02:28 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 13 Jul 2007 10:02:27 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 10:02:27 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [manet] comments on draft-ietf-manet-packetbb-08.txt Date: Fri, 13 Jul 2007 10:02:27 +0100 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED907@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] comments on draft-ietf-manet-packetbb-08.txt Thread-Index: AcfDY6u8BwYK2PIeTheZ1ni4DTugEAAtqzrgACWoYAAADOedAAARbiXw References: <374005f30707101930t38b5f465gf707845a60d5544a@mail.gmail.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED901@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED904@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED907@XCH-NW-7V2.nw.nos.boeing.com> From: "Dearlove, Christopher \(UK\)" To: "Templin, Fred L" , "manet" X-OriginalArrivalTime: 13 Jul 2007 09:02:27.0704 (UTC) FILETIME=[895B3F80:01C7C52C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 Thanks for these. Comments inline below with >>>=20 -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: 13 July 2007 01:32 To: manet Subject: [manet] comments on draft-ietf-manet-packetbb-08.txt *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Comments on this draft (mostly editorial and clarifying questions) follow. Overall comment is that this all looks computationally expensive, but I have no way of quantifying. Fred fred.l.templin@boeing.com 1) (semi-editorial) Section 2, the definition for "Address" seems self-referential and never really specifies exactly what an "address" is. Since the meaning of "address" is already well understood in the IETF context and presumably no different here, suggest dropping the definition. >>> This one I don't agree with. Without it, what's the >>> size of an address? 2) (editorial) Section 3, s/between in/in/ >>> How many times have I read this and missed that. Thanks. 3) (comment) Section 4, is this section really necessary? >>> Here I'd take advice from people more familiar with the >>> process than I am. The logic was that this is Standards >>> Track, and people may be expecting a protocol. I'd happily >>> lose it as long as the IESG or the RFC Editor won't want >>> it back. 4) (comment) Section 5.2 and elsewhere, it strikes me as odd that the inclusion of optional fields is consistently phrased in the negative (e.g., noorig, nohoplimit, nohopcount, etc.) such that setting the bit means that the field is not present. It results in casting things in a "double-negative", e.g. noorig=3D0 means that "there is an orig". Any reason these were=20 not phrased in the positive instead? >>> The logic is from the origin. We designed this for OLSRv2, >>> and only later modified to accommodate others. There is a >>> "backwards to OLSRv1 partial compatibility" and zero is >>> that mode, and the mode mandated by OLSRv2. 5) (comment) Section 5.2, a 2-octet field seems excessive, but I guess it is that way for 32-bit alignment? Otherwise, a flag in could be defined to cast is as either a 1-octet or 2-octet field.=20 >>> That is a possibility. We haven't done it as we >>> haven't seen enough value. 6) (comment) Section 5.2.1, I'm not seeing the benefit of requiring all addresses to be the same length (i.e., using IPv4-mapped IPv6 addresses if necessary). Wouldn't it make more sense to define an bit that specifies whether an address block contains all-IPv4 or all-IPv6 addresses? >>> I don't want an IPv4/IPv6 bit because there is always the >>> possibility of using this structure for other address >>> sizes. And really I'm not seeing this as a real need. >>> How often do we actually mix the two in a single MANET? >>> Also the originator address needs a length. 7) (comment) Section 5.3, a fixed of 2-octets seems excessive, but there seems to be no way to shorten it for TLV blocks that are shorter than 255 bytes? >>> I have come up with two (I think) nasty ways of doing >>> it, but they add to the complexity (especially the >>> parsing complexity) of the specification, for what I >>> haven't viewed as enough win. 8) (semi-substantial) Section 5.3.1, bit 0 (hassubtype) has switched to phrasing an optional field selector bit in the positive instead of the negative - see 4) above. To be consistent, it should be renamed as "(nosubtype)" with the bit definitions adjusted accordingly. (But IMHO, better would be to phrase all optional field selector bits in the positive.) >>> Here I expect the overwhelming majority of uses to be >>> without a subtype (it was debateable whether to even add >>> subtypes) so again the logic is zer =3D default. 9) (comment) Section 5.3.1, under , why is it that: "If present it MUST NOT be zero.", i.e., it is not immediately apparent why a of 0 with a null "MUST NOT" be included? >>> That's a good point. We don't protect against inefficiency >>> in other places (e.g. you can set both indexes to the same >>> value rather than use singleindex) so why here. 10) (semi-editorial) Section 5.4, it should be noted that padding is possible and may be desired for other purposes than just 32-bit alignment, e.g., padding all messages to a common size, MTU probing, etc. >>> Now that's actually the first good thing I've heard >>> about padding. I've never been convinced of its real >>> value. But somebody wanted it, and it was painless in >>> both definition and implementation, so it went in. ******************************************************************** 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 Jul 13 05:21: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 1I9HL1-0000Fe-Ek; Fri, 13 Jul 2007 05:21:23 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I9HKz-0000FV-9Y for manet-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 05:21:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9HKz-0000FN-03 for manet@ietf.org; Fri, 13 Jul 2007 05:21:21 -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 1I9HKu-0008IH-FL for manet@ietf.org; Fri, 13 Jul 2007 05:21:20 -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 l6D9LF5D013950 for ; Fri, 13 Jul 2007 10:21:15 +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 l6D9LFjg022688 for ; Fri, 13 Jul 2007 10:21:15 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 13 Jul 2007 10:21:15 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 10:21:15 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [manet] comments on draft-ietf-manet-nhdp-04.txt Date: Fri, 13 Jul 2007 10:21:14 +0100 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED904@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] comments on draft-ietf-manet-nhdp-04.txt Thread-Index: AcfDY6u8BwYK2PIeTheZ1ni4DTugEAAtqzrgACWoYAAAHuiG4A== References: <374005f30707101930t38b5f465gf707845a60d5544a@mail.gmail.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED901@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED904@XCH-NW-7V2.nw.nos.boeing.com> From: "Dearlove, Christopher \(UK\)" To: "Templin, Fred L" , "manet" X-OriginalArrivalTime: 13 Jul 2007 09:21:15.0108 (UTC) FILETIME=[29577240:01C7C52F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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 Thanks again, and inline comments >>>=20 -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: 12 July 2007 19:21 To: manet Subject: [manet] comments on draft-ietf-manet-nhdp-04.txt *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Comments on this draft follow. By way of disclaimer, these comments are not to be considered as endorsement of the protocol's correctness and/or its applicability for any use-cases. Fred fred.l.templin@boeing.com 1) (semi-substantial) Section 1, first sentence, reference for "MANET" should be draft-ietf-autoconf-manetarch-04.txt (which in turn cites RFC2501). >>> We haven't done this, because this is Standards Track, >>> and that's still only an ID. If it were an RFC (i.e. >>> been accepted) I'd happily reference it. But I'm not >>> sure right now. This we will need to discuss. 2) (substantial) Section 2, definitions for {interface, MANET interface, link, symmetric link} need to be squared with draft-ietf-autoconf-manetarch-04.txt. In particular, there is a tension between "link" as "a communications facility at a layer below IP..." (per [MANETARCH], RFCs 2460/2461/2753, etc.), and "link" as a neighboring relationship between nodes (per this document) that needs to be harmonized. Specific suggestion for "link" is: "Link A communications facility at a layer below IP, over which nodes exchange IP packets directly without decrementing IP TTL (Hop Limit) [MANETARCH]. A pairwise link (aka an adjacency) is said to exists between two nodes X and Y if at least one node is heard by the other on the underlying communications facility. The term "link" in this document is therefore used to refer to the pairwise links between two nodes unless otherwise noted." >>> This one I want to think about. But I don't feel that we >>> automatically have to follow manetarch if it causes us >>> problems here. And that's much too detailed for how we >>> need the word here, and is inconsistent with it - that >>> definition has a link between nodes, we have (and must >>> have) a link as between MANET interfaces. 3) (semi-substantial) Section 4.1, second bullet, "links to this MANET interface" makes no sense, because an interface is a node's attachment to a link; not vice-versa. Change to: "links associated with this MANET interface". >>> That's not right, because it loses the "to". We only record >>> links which are to us, or to and from us (or lost examples >>> thereof). 4) (comment) Section 5.1.1, should: "HELLO_INTERVAL" be called: "HELLO_MAX_INTERVAL" instead? >>> No. Too cumbersome, and HELLO_INTERVAL isn't just the >>> maximum, in normal operation when nothing is changing >>> it is the HELLO interval. 5) (semi-substantial) Section 5.1.1, last paragraph, the term "responsive" is not previously defined and its use here seems ambiguous, e.g., what exactly is a "responsive HELLO message"? The term is used in 4 places throughout the document and seems ambiguous in all 4. Suggest adding "responsive" to terminology. >>> See Section 4.3.1, second and third bullets. 6) (semi-editorial) Section 6, last sentence of first paragraph, change: "Two addresses" to: "Two identical addresses". >>> I see your point, but that actual change doesn't work for >>> me, as at this point what is "identical"? I think if it's >>> necessary to change that sentence (borderline in my >>> opinion) that's not the change I'd make. 7) (semi-substantial) Section 7, change: "links to that MANET interface" to: "links associated with that MANET interface". (Same comment as 3) above.) >>> And see my comment above. 8) (semi-editorial) Section 7, final sentence, same comment as 6) above. >>> Ditto. 9) (semi-substantial) Section 15, if this document is to go as standards-track, "proposed" should be changed to: "recommended". >>> Thanks. 10) (comment) Section 15.1, does the recommended HELLO_INTERVAL (HELLO_MAX_INTERVAL?) of 2 seconds relate in any way to the expected characteristics of the underlying communications facility? If so, maybe add a sentence saying so. >>> It must (which is I think why we have had the proposed there). >>> There should be something. 11) (semi-substantial) Section 17, add [MANETARCH] as normative reference.=20 >>> See above, I'm not entirely happy with this. (end of comments) _______________________________________________ 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 Fri Jul 13 12:22: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 1I9NuH-0002fx-LP; Fri, 13 Jul 2007 12:22:13 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I9NuG-0002fK-5z for manet-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 12:22:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9NuF-0002f2-OY for manet@ietf.org; Fri, 13 Jul 2007 12:22:11 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9NuB-0005Yj-7I for manet@ietf.org; Fri, 13 Jul 2007 12:22:11 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6DGM30x006957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Jul 2007 09:22:04 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6DGM3NM029813; Fri, 13 Jul 2007 09:22:03 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6DGM1eB029733; Fri, 13 Jul 2007 09:22:01 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 09:22:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] comments on draft-ietf-manet-packetbb-08.txt Date: Fri, 13 Jul 2007 09:21:54 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED90B@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] comments on draft-ietf-manet-packetbb-08.txt Thread-Index: AcfDY6u8BwYK2PIeTheZ1ni4DTugEAAtqzrgACWoYAAADOedAAARbiXwAA7aRIA= References: <374005f30707101930t38b5f465gf707845a60d5544a@mail.gmail.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED901@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED904@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED907@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Dearlove, Christopher (UK)" , "manet" X-OriginalArrivalTime: 13 Jul 2007 16:22:00.0594 (UTC) FILETIME=[F0D2E720:01C7C569] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd 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 Chris, Thanks for your response, and pls see my folloups below: Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Dearlove, Christopher (UK)=20 > [mailto:Chris.Dearlove@baesystems.com]=20 > Sent: Friday, July 13, 2007 2:02 AM > To: Templin, Fred L; manet > Subject: RE: [manet] comments on draft-ietf-manet-packetbb-08.txt >=20 >=20 > Thanks for these. Comments inline below with >>>=20 >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: 13 July 2007 01:32 > To: manet > Subject: [manet] comments on draft-ietf-manet-packetbb-08.txt >=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 > Comments on this draft (mostly editorial and clarifying > questions) follow. Overall comment is that this all looks > computationally expensive, but I have no way of quantifying. >=20 > Fred > fred.l.templin@boeing.com >=20 > 1) (semi-editorial) Section 2, the definition for "Address" > seems self-referential and never really specifies exactly > what an "address" is. Since the meaning of "address" is > already well understood in the IETF context and presumably > no different here, suggest dropping the definition. >=20 > >>> This one I don't agree with. Without it, what's the > >>> size of an address? I understand your point, but I don't believe (re)defining "address" under Terminolgy is the correct way to capture it.=20 IMHO it should be captured in normative text of the document instead, and you alreay do this in Section 3 where it says: "All addresses within a control message are assumed to be of the same size, deduced from IP. In the case of mixed IPv6 and IPv4 addresses, IPv4 addresses are represented as IPv4-mapped IPv6 addresses as specified in [2]." So, (re)defining "address" under terminology is IMHO redundant and potentially confusing. =20 =20 > 2) (editorial) Section 3, s/between in/in/ >=20 > >>> How many times have I read this and missed that. Thanks. OK. This was the only one of its ilk that I found, so it seems like this has been proof-read many times over. =20 > 3) (comment) Section 4, is this section really necessary? >=20 > >>> Here I'd take advice from people more familiar with the > >>> process than I am. The logic was that this is Standards > >>> Track, and people may be expecting a protocol. I'd happily > >>> lose it as long as the IESG or the RFC Editor won't want > >>> it back. OK on getting advice from IESG/RFC Editor. Maybe bring up during AUTH48? =20 > 4) (comment) Section 5.2 and elsewhere, it strikes me as odd > that the inclusion of optional fields is consistently phrased > in the negative (e.g., noorig, nohoplimit, nohopcount, etc.) > such that setting the bit means that the field is not present. > It results in casting things in a "double-negative", e.g. > noorig=3D0 means that "there is an orig". Any reason these were=20 > not phrased in the positive instead? >=20 > >>> The logic is from the origin. We designed this for OLSRv2, > >>> and only later modified to accommodate others. There is a > >>> "backwards to OLSRv1 partial compatibility" and zero is > >>> that mode, and the mode mandated by OLSRv2. I won't press the point, but it still seems odd to me. =20 > 5) (comment) Section 5.2, a 2-octet field > seems excessive, but I guess it is that way for 32-bit > alignment? Otherwise, a flag in could be > defined to cast is as either a 1-octet or 2-octet field.=20 >=20 > >>> That is a possibility. We haven't done it as we > >>> haven't seen enough value. It could be argued that you've jumped through many other complicated hoops for indeterminate value, so why not this one too? > 6) (comment) Section 5.2.1, I'm not seeing the benefit of > requiring all addresses to be the same length (i.e., using > IPv4-mapped IPv6 addresses if necessary). Wouldn't it make more > sense to define an bit that specifies whether > an address block contains all-IPv4 or all-IPv6 addresses? >=20 > >>> I don't want an IPv4/IPv6 bit because there is always the > >>> possibility of using this structure for other address > >>> sizes. OK. > >>> And really I'm not seeing this as a real need. > >>> How often do we actually mix the two in a single MANET? Never say never. > >>> Also the originator address needs a length. OK to leave this one as already documented. =20 > 7) (comment) Section 5.3, a fixed of 2-octets > seems excessive, but there seems to be no way to shorten > it for TLV blocks that are shorter than 255 bytes? >=20 > >>> I have come up with two (I think) nasty ways of doing > >>> it, but they add to the complexity (especially the > >>> parsing complexity) of the specification, for what I > >>> haven't viewed as enough win. But, would it be any more complex than some of the other hoops you are already jumping through, i.e., where do you draw the line? =20 > 8) (semi-substantial) Section 5.3.1, bit 0 (hassubtype) has > switched to phrasing an optional field selector bit in the > positive instead of the negative - see 4) above. To be > consistent, it should be renamed as "(nosubtype)" with the > bit definitions adjusted accordingly. (But IMHO, better would > be to phrase all optional field selector bits in the positive.) >=20 > >>> Here I expect the overwhelming majority of uses to be > >>> without a subtype (it was debateable whether to even add > >>> subtypes) so again the logic is zer =3D default. If we allow your explanation for 4) (which I am willing to do), then I would prefer to see this as "(nosubtype)". If we still disagree, then you're the one with the pen and I'm the one who gets to go off and grumble.=20 > 9) (comment) Section 5.3.1, under , why is it that: > "If present it MUST NOT be zero.", i.e., it is not immediately > apparent why a of 0 with a null "MUST NOT" > be included? >=20 > >>> That's a good point. We don't protect against inefficiency > >>> in other places (e.g. you can set both indexes to the same > >>> value rather than use singleindex) so why here. OK. > 10) (semi-editorial) Section 5.4, it should be noted that > padding is possible and may be desired for other purposes > than just 32-bit alignment, e.g., padding all messages to > a common size, MTU probing, etc. >=20 > >>> Now that's actually the first good thing I've heard > >>> about padding. I've never been convinced of its real > >>> value. But somebody wanted it, and it was painless in > >>> both definition and implementation, so it went in. OK. =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 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Jul 13 13:08: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 1I9OdL-0001WV-Jp; Fri, 13 Jul 2007 13:08:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I9OdJ-0001WO-Pn for manet-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 13:08:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9OdJ-0001WD-Dv for manet@ietf.org; Fri, 13 Jul 2007 13:08:45 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9OdI-0000yv-WA for manet@ietf.org; Fri, 13 Jul 2007 13:08:45 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6DH8Imv001851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Jul 2007 12:08:18 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6DH8Hlw009306; Fri, 13 Jul 2007 10:08:17 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6DH83Sx008717; Fri, 13 Jul 2007 10:08:11 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 10:08:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] comments on draft-ietf-manet-nhdp-04.txt Date: Fri, 13 Jul 2007 10:07:04 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED90C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] comments on draft-ietf-manet-nhdp-04.txt Thread-Index: AcfDY6u8BwYK2PIeTheZ1ni4DTugEAAtqzrgACWoYAAAHuiG4AAQB8sg References: <374005f30707101930t38b5f465gf707845a60d5544a@mail.gmail.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED901@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED904@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Dearlove, Christopher (UK)" , "manet" X-OriginalArrivalTime: 13 Jul 2007 17:08:03.0299 (UTC) FILETIME=[5F863B30:01C7C570] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 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 Chris - pls see my followups below: Fred fred.l.templin@boeing.com > -----Original Message----- > From: Dearlove, Christopher (UK)=20 > [mailto:Chris.Dearlove@baesystems.com]=20 > Sent: Friday, July 13, 2007 2:21 AM > To: Templin, Fred L; manet > Subject: RE: [manet] comments on draft-ietf-manet-nhdp-04.txt >=20 >=20 > Thanks again, and inline comments >>>=20 >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: 12 July 2007 19:21 > To: manet > Subject: [manet] comments on draft-ietf-manet-nhdp-04.txt >=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 > Comments on this draft follow. By way of disclaimer, > these comments are not to be considered as endorsement > of the protocol's correctness and/or its applicability > for any use-cases. >=20 > Fred > fred.l.templin@boeing.com >=20 > 1) (semi-substantial) Section 1, first sentence, reference > for "MANET" should be draft-ietf-autoconf-manetarch-04.txt > (which in turn cites RFC2501). >=20 > >>> We haven't done this, because this is Standards Track, > >>> and that's still only an ID. If it were an RFC (i.e. > >>> been accepted) I'd happily reference it. But I'm not > >>> sure right now. This we will need to discuss. I am sure you have already guessed my response, but the document already cites four works in progress so why not this one too - especially since it presumably documents *the* MANET Architecture. =20 > 2) (substantial) Section 2, definitions for {interface, MANET > interface, link, symmetric link} need to be squared with > draft-ietf-autoconf-manetarch-04.txt. In particular, there is > a tension between "link" as "a communications facility at a > layer below IP..." (per [MANETARCH], RFCs 2460/2461/2753, etc.), > and "link" as a neighboring relationship between nodes (per this > document) that needs to be harmonized. >=20 > Specific suggestion for "link" is: >=20 > "Link > A communications facility at a layer below IP, over which nodes > exchange IP packets directly without decrementing IP TTL (Hop > Limit) [MANETARCH]. A pairwise link (aka an adjacency) is said > to exists between two nodes X and Y if at least one node is > heard by the other on the underlying communications facility. > The term "link" in this document is therefore used to refer to > the pairwise links between two nodes unless otherwise noted." >=20 > >>> This one I want to think about. But I don't feel that we > >>> automatically have to follow manetarch if it causes us > >>> problems here. The first part of the definition could cite RFC{2460,2461,3753} instead, but [MANETARCH] would seem more appropriate. =20 > >>> And that's much too detailed for how we > >>> need the word here, and is inconsistent with it - that > >>> definition has a link between nodes, we have (and must > >>> have) a link as between MANET interfaces. The issue here is that there is a disparity between the two uses of the term "link" that needs to be resolved to avoid ambiguity. Perhaps you would be more amenable to the following slight re-wording of the proposal: "Link A communications facility at a layer below IP, over which nodes exchange IP packets directly without decrementing IP TTL (Hop Limit) [MANETARCH]. A pairwise link (aka an adjacency) is said to exist between two MANET interfaces if at least one interface is heard by the other. The term "link" in this document is therefore used to refer to the pairwise links between two MANET interfaces unless otherwise noted." > 3) (semi-substantial) Section 4.1, second bullet, "links to this > MANET interface" makes no sense, because an interface is a node's > attachment to a link; not vice-versa. Change to: "links associated > with this MANET interface". >=20 > >>> That's not right, because it loses the "to". We only record > >>> links which are to us, or to and from us (or lost examples > >>> thereof). OK to leave this one alone. =20 > 4) (comment) Section 5.1.1, should: "HELLO_INTERVAL" be called: > "HELLO_MAX_INTERVAL" instead? >=20 > >>> No. Too cumbersome, and HELLO_INTERVAL isn't just the > >>> maximum, in normal operation when nothing is changing > >>> it is the HELLO interval. OK. =20 > 5) (semi-substantial) Section 5.1.1, last paragraph, the term > "responsive" is not previously defined and its use here seems > ambiguous, e.g., what exactly is a "responsive HELLO message"? > The term is used in 4 places throughout the document and seems > ambiguous in all 4. Suggest adding "responsive" to terminology. >=20 > >>> See Section 4.3.1, second and third bullets. That doesn't quite do it for me. What would work would be to change: "As a response," to: "Responsively," in the second bullet. =20 > 6) (semi-editorial) Section 6, last sentence of first paragraph, > change: "Two addresses" to: "Two identical addresses". >=20 > >>> I see your point, but that actual change doesn't work for > >>> me, as at this point what is "identical"? I think if it's > >>> necessary to change that sentence (borderline in my > >>> opinion) that's not the change I'd make. How about: "Two addresses are considered equal if and only if they match and their associated prefix lengths are also equal." =20 > 7) (semi-substantial) Section 7, change: "links to that MANET > interface" to: "links associated with that MANET interface". > (Same comment as 3) above.) >=20 > >>> And see my comment above. Acceptable. =20 > 8) (semi-editorial) Section 7, final sentence, same comment > as 6) above. >=20 > >>> Ditto. See above. =20 > 9) (semi-substantial) Section 15, if this document is to go as > standards-track, "proposed" should be changed to: "recommended". >=20 > >>> Thanks. OK. =20 > 10) (comment) Section 15.1, does the recommended HELLO_INTERVAL > (HELLO_MAX_INTERVAL?) of 2 seconds relate in any way to the > expected characteristics of the underlying communications > facility? If so, maybe add a sentence saying so. >=20 > >>> It must (which is I think why we have had the proposed there). > >>> There should be something. OK. =20 > 11) (semi-substantial) Section 17, add [MANETARCH] as normative > reference.=20 >=20 > >>> See above, I'm not entirely happy with this. Actually, since [MANETARCH] is going as Informational, perhaps citing as informative is sufficient? =20 > (end of comments) >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=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. > ******************************************************************** >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Jul 14 09:19: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 1I9hWe-0005ZR-HA; Sat, 14 Jul 2007 09:19:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1I9hWd-0005YZ-9K for manet-confirm+ok@megatron.ietf.org; Sat, 14 Jul 2007 09:19:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9hWc-0005Wo-K1; Sat, 14 Jul 2007 09:19:06 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9hWY-0000No-8x; Sat, 14 Jul 2007 09:19:06 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Jul 2007 09:19:02 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAF5qmEZAZnme/2dsb2JhbACtEg X-IronPort-AV: i="4.16,538,1175486400"; d="scan'208"; a="126052206:sNHT30297268" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6EDJ1T9011752; Sat, 14 Jul 2007 09:19:01 -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 l6EDJ1WI005898; Sat, 14 Jul 2007 13:19:01 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); Sat, 14 Jul 2007 09:19:01 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jul 2007 09:19:01 -0400 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> References: <20070522232511.DD58016B0002@secure.archedrock.com> <7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C11646C-2152-41FA-97CB-20873155E3D2@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Sat, 14 Jul 2007 09:18:25 -0400 To: "Pascal Thubert ((pthubert))" , manet@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Jul 2007 13:19:01.0273 (UTC) FILETIME=[8B0D3890:01C7C619] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3671; t=1184419142; x=1185283142; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20Next=20step=20for=20RSN=20? |Sender:=20 |To:=20=22Pascal=20Thubert=20((pthubert))=22=20, =20ma net@ietf.org; bh=VHBbE3vbNb1oX6KYxLHCdb5xG3YO7RqvYhQGt+TTzno=; b=fiyv81OmqB3N8fJQr7GRU/clTqzsWU0OHYQpFapO8+O9/y39erRcCb2VujOh2hPCwPyEDKWI PyqgXhM0nMiG3gSENgf/nZYrfEezzkwwOKkdwziBmWqWrqk8ngD95Pqy; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: rsn@ietf.org Subject: [manet] Re: [RSN] Next step for RSN ? 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 Pascal, On May 24, 2007, at 9:45 AM, Pascal Thubert ((pthubert)) wrote: > Hi JP: > > Please see inline: > > It looks fairly obvious that a network made of N "mesh-under" > routing protocols is very unlikely to satisfy an end to end path > constraint and would be fairly complex to manage and tune. We all > remember the issue of IP routing over ATM PVCs routed by PNNI. > Think of this with N "Mesh-under" routing protocols. That said, > this is not to say that we exclude the use of "mesh-under" > solutions, but we propose to define a IP-based routing protocol. > > Pascal => I agree there's a lot of value to federate over IP the > various approaches that are defined for mesh-under. Indeed. > > The second step would consist of making a survey on the existing > routing protocols and see whether (1) they could be used as such > (2) they should be adapted (for instance, see whether AODV or OLR > or RIP could be made energy efficient, could support some form of > constrained based routing, ...) or (3) we should design a new > generic new protocol. > > Pascal => One aspect of this could be to consider the features that > mesh and sensor networks have deployed and why, and then see if > there is a need to generalize the approach at layer 3. For > instance, offline routing is popular in WSNs while not the > prominent model in IP or MANET. > Good point indeed (see TSMP, ...). There is a bit of off-line at the IETF for MPLS but indeed not that much on IP. On the goal of the RSN WG (should it be formed) would precisely to evaluate the pros/cons of all approach and supporting a mix approach might be an option. Anyway, food for future thoughts. Back to the protocol survey, a very first draft is available and requires much more work. Folks from MANET would be very welcome to provide feed-back/comments/ suggestions/... > Pascal => Another specificity could be to work on a tighter > integration with the radio and a more specific abstraction for L3. > I know we have that barrier at IETF against L2 related activities. > Yet, if the radio model provides such things as beacons, then it > could be beneficial to define a routing protocol that can take > advantage of the beacons. At the moment, IP is carried in data > frames only. I agree that we need an L2 abstraction layer since RF links in particular are quite specifics and their characteristics must be known by the routing protocol when they influence the routing decision, as stated in draft-culler-rl2n-routing-reqs-01. By the way, you and I have the action plan to produce that ID ;-) Back to your example on beacon, I would personally prefer to maintain a clear separation between layer to keep the L2 agnostic nature of routing. Why not defining local inter-layer mechanism (out of the standardization scope) as we do with many other media ? > > Pascal => We'll also have to work out the relationship with MANEMO. > My understanding is that MANEMO is for bigger boxes (routers > really) and has strong mobility and global reachability > constraints. That makes it pretty different in the objectives. > OTOH, there seems to be value to keep sharing views and ideas > between the groups, should they form. You are 100% right. One option might be to concentrate all routing function in one place or to clearly differentiate the routing objective. We do need to avoid any overlap. We (RSN) should provide feed-back to MANET (I just assigned an action item to myself ;-)) and vice versa. Thanks. JP. > > Pascal _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jul 16 00:11:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAHvb-0007Tp-TA; Mon, 16 Jul 2007 00:11:19 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IAHvZ-0007Oc-R1 for manet-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 00:11:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAHvZ-0007Me-Ev for manet@ietf.org; Mon, 16 Jul 2007 00:11:17 -0400 Received: from cassius.ee.usyd.edu.au ([129.78.13.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAHvU-0005X8-Nl for manet@ietf.org; Mon, 16 Jul 2007 00:11:17 -0400 Received: from ee.usyd.edu.au (localhost [127.0.0.1]) by cassius.ee.usyd.edu.au (8.13.6/8.13.6) with SMTP id l6G48t3E007304 for ; Mon, 16 Jul 2007 14:08:56 +1000 (EST) From: Guo Qiang Mao Received: from 203.143.170.222 (SquirrelMail authenticated user guoqiang) by www.ee.usyd.edu.au with HTTP; Mon, 16 Jul 2007 14:08:56 +1000 (EST) Message-ID: <4217.203.143.170.222.1184558936.squirrel@www.ee.usyd.edu.au> Date: Mon, 16 Jul 2007 14:08:56 +1000 (EST) To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.7) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-ElectricalEngineering-MailScanner-Information: Please contact the ISP for more information X-ElectricalEngineering-MailScanner: Found to be clean X-ElectricalEngineering-MailScanner-From: guoqiang@ee.usyd.edu.au Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cassius.ee.usyd.edu.au id l6G48t3E007304 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [manet] Call for Chapters on Localization in Wireless Sensor Networks X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org [Our apologizes if you receive multiple copies of this CFC] [CFP] Call for Chapters on Localization in Wireless Sensor Networks Book Title: Localization Algorithms and Strategies for Wireless Sensor Networks: Monitoring and Surveillance Techniques for Target Tracking Book webpage: http://www.ee.usyd.edu.au/~guoqiang/Research/BookOnLocalizationAlgorithms= .htm Editors: Guoqiang Mao and Baris Fidan Publishing Details: This book will be published by IGI Global http://www.igi-pub.com/ in 2008. Introduction Wireless sensor networks (WSNs) constitute a significant technology of today, attracting considerable research interest from various disciplines. Self-localization capability is a highly desirable characteristic of wireless sensor networks. In environmental monitoring applications such a= s bush fire surveillance, water quality monitoring and precision agriculture, the measurement data are meaningless without knowing the location from where the data are obtained. Moreover, location estimation may enable a myriad of applications such as inventory management, intrusion detection, road traffic monitoring, health monitoring, reconnaissance and surveillance. This book intends to cover the fundamental theories, the state-of-the-art research findings, and experimental studies and applications of WSN localization techniques. We expect the book to serve as a valuable and comprehensive reference for students, educators, researchers, and engineers who work in this rapidly evolving field. Recommended topics (not limited to) =95 Measurements techniques used in WSN localization =95 WSN localization algorithms =95 Fundamental theories in WSN localization =95 Graph theoretical analysis of characteristics of WSNs and application= of such analysis to WSN localization =95 Monitoring and surveillance techniques =95 Experimental studies =95 Applications of WSN localization techniques Invitation Prospective chapter authors are invited to submit, initially, a 1-2 page single column, single space proposal describing the proposed chapter in M= S Word or RTF format. The proposal should include the title, the abstract, the chapter organization, number of pages of the final manuscript intende= d to be submitted and contact authors. Each chapter is planned to fit 15-25 letter-size pages (single column, single space, 12 pt font). However, (only) fundamental chapter proposals of comprehensive review/survey style will be allowed to be up to 40 pages. Chapter templates will be provided once the proposals are submitted and acceptance decisions are made. Important Dates =95 Submission of Chapter Proposals: September 15, 2007 =95 Notification of Proposal Acceptance: October 15, 2007 =95 Full Chapter Submission: March 15, 2008 =95 Review Reports Due: May 15, 2008 =95 Final Version Submission: July 15, 2008 Contact =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Please make correspondence and proposal submissions to: Dr Guoqiang Mao School of Electrical and Information Engineering The University of Sydney NSW 2006, Australia Email: guoqiang@ee.usyd.edu.au Dr Baris Fidan National ICT Australia Locked Bag 8001 Canberra ACT 2601, Australia Email: baris.fidan@nicta.com.au _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Jul 16 04:49:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMGO-0001ut-Hv; Mon, 16 Jul 2007 04:49:04 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IAMGN-0001un-IS for manet-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 04:49:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMGM-0001ud-EO for manet@ietf.org; Mon, 16 Jul 2007 04:49:03 -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 1IAMG6-0007V5-9S for manet@ietf.org; Mon, 16 Jul 2007 04:49: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 l6G8lNG0007820 for ; Mon, 16 Jul 2007 09:47: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 l6G8lNlT007719 for ; Mon, 16 Jul 2007 09:47:23 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 16 Jul 2007 09:47:23 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 09:47: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] comments on draft-ietf-manet-nhdp-04.txt Date: Mon, 16 Jul 2007 09:47:22 +0100 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED90C@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] comments on draft-ietf-manet-nhdp-04.txt Thread-Index: AcfDY6u8BwYK2PIeTheZ1ni4DTugEAAtqzrgACWoYAAAHuiG4AAQB8sgAIXO9DA= References: <374005f30707101930t38b5f465gf707845a60d5544a@mail.gmail.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED901@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED904@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED90C@XCH-NW-7V2.nw.nos.boeing.com> From: "Dearlove, Christopher \(UK\)" To: "Templin, Fred L" , "manet" X-OriginalArrivalTime: 16 Jul 2007 08:47:22.0807 (UTC) FILETIME=[ED3C2C70:01C7C785] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > I am sure you have already guessed my response, but the > document already cites four works in progress so why not > this one too - especially since it presumably documents > *the* MANET Architecture. The difference is that we can be pretty confident that the others will progress to RFC before or at the same time as this one - three because they are from the same authors, and the IANA draft because it's simple and I'm confident it will go into the process soon. Manetarch we don't have that control over, and it's not as close to final. But I would like to be referencing manetarch, though not if it causes delay (e.g. if by putting it in we are forced to wait for it to be published, and something causes a serious delay). So at the moment it's not in, but we also would like to put it in, and I for one need to consult on this. > The issue here is that there is a disparity between the two > uses of the term "link" that needs to be resolved to avoid > ambiguity. Perhaps you would be more amenable to the following > slight re-wording of the proposal: Closer, but we need to consider directionality. At the moment can we agree to reconsider the definition of link, without coming to a firm decision on it. (Actually that applies to all of Fred's comments. You're getting my responses, but I'm not the only author. We'll be collecting together all the responses we get - including some of our own - and going through them. > That doesn't quite do it for me. What would work would be > to change: "As a response," to: "Responsively," in the > second bullet. I need to check the grammar (I don't have it in front of me) but that sounds like a good idea. =20 > How about: > > "Two addresses are considered equal if and only if they match > and their associated prefix lengths are also equal." That I like. > Actually, since [MANETARCH] is going as Informational, perhaps > citing as informative is sufficient? Could be. ******************************************************************** 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 Jul 16 06:40: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 1IANzs-0005v0-B3; Mon, 16 Jul 2007 06:40:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IANzq-0005n0-FV for manet-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 06:40:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IANzq-0005l0-3A for manet@ietf.org; Mon, 16 Jul 2007 06:40:06 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IANzb-0001E2-M4 for manet@ietf.org; Mon, 16 Jul 2007 06:40:06 -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 l6GAdI3l020449 for ; Mon, 16 Jul 2007 11:39:18 +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 l6GAdHBd028427 for ; Mon, 16 Jul 2007 11:39:17 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 16 Jul 2007 11:39:16 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 11:39: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] comments on draft-ietf-manet-packetbb-08.txt Date: Mon, 16 Jul 2007 11:39:15 +0100 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED90B@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] comments on draft-ietf-manet-packetbb-08.txt Thread-Index: AcfDY6u8BwYK2PIeTheZ1ni4DTugEAAtqzrgACWoYAAADOedAAARbiXwAA7aRIAAi4Nf0A== References: <374005f30707101930t38b5f465gf707845a60d5544a@mail.gmail.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED901@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED904@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED907@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED90B@XCH-NW-7V2.nw.nos.boeing.com> From: "Dearlove, Christopher \(UK\)" To: "Templin, Fred L" , "manet" X-OriginalArrivalTime: 16 Jul 2007 10:39:15.0785 (UTC) FILETIME=[8E7B5390:01C7C795] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > I understand your point, but I don't believe (re)defining > "address" under Terminolgy is the correct way to capture it.=20 > IMHO it should be captured in normative text of the document > instead, and you alreay do this in Section 3 where it says: > So, (re)defining "address" under terminology is IMHO redundant > and potentially confusing. I don't see it as confusing, but potentially redundant, OK. There is an issue that without this in the terminology, the variable address-length is arguably not well-defined here (at this point someone may say "what about a mixture?" - it's answered later). On the "think about" list. >>> 7) (comment) Section 5.3, a fixed of 2-octets >>> seems excessive, but there seems to be no way to shorten >>> it for TLV blocks that are shorter than 255 bytes? >=20 >> I have come up with two (I think) nasty ways of doing >> it, but they add to the complexity (especially the >> parsing complexity) of the specification, for what I >> haven't viewed as enough win. > > But, would it be any more complex than some of the other > hoops you are already jumping through, i.e., where do you > draw the line? Note that there is interaction between this and the single octet length (you can't have a TLV block longer than the message it's in) and then you are in the nasty situation of flags in one structure defining the state of another structure. My code (but of course others may do something quite different) has an OO packetbb parser, and packet builder and this (the latter especially) gets ugly here. Where you draw the line is a very good question, and I'm conscious that the line is not where various people would put it. Problem is, some want to move it to the left, others to the right, and yet more just want it nailed down somewhere as soon as possible. ******************************************************************** 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 Jul 16 11:20:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IASMv-0006LT-Ve; Mon, 16 Jul 2007 11:20:13 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IASMt-0006LL-MR for manet-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 11:20:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IASMt-0006LD-Cq; Mon, 16 Jul 2007 11:20:11 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IASMo-0007bv-9x; Mon, 16 Jul 2007 11:20:11 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm5c469be27f; Mon, 16 Jul 2007 23:31:47 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm704696cec1; Fri, 13 Jul 2007 03:59:26 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 13 Jul 2007 03:59:26 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91LJ-0005Uk-Ss; Thu, 12 Jul 2007 12:16:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91K3-0003Jq-NZ; Thu, 12 Jul 2007 12:15:19 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I91K3-0005is-GC; Thu, 12 Jul 2007 12:15:19 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 613692AC79; Thu, 12 Jul 2007 16:15:09 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I91Js-0003Fr-AQ; Thu, 12 Jul 2007 12:15:08 -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: Thu, 12 Jul 2007 12:15:08 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.2 (++) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-packetbb-08.txt X-BeenThere: manet@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Generalized MANET Packet/Message Format Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-packetbb-08.txt Pages : 49 Date : 2007-7-12 This document specifies a multi-message packet format that may be used by mobile ad hoc network routing and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-packetbb-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-packetbb-08.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-7-12111505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-packetbb-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-packetbb-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12111505.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Wed Jul 18 04:56: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 1IB5KS-0003ht-FD; Wed, 18 Jul 2007 04:56:16 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IB5KQ-0003du-5q for manet-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 04:56:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB5KP-0003dU-Hl for manet@ietf.org; Wed, 18 Jul 2007 04:56:13 -0400 Received: from nz-out-0506.google.com ([64.233.162.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB5KP-0001Ct-7u for manet@ietf.org; Wed, 18 Jul 2007 04:56:13 -0400 Received: by nz-out-0506.google.com with SMTP id n1so102979nzf for ; Wed, 18 Jul 2007 01:56:13 -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=XWe6SWOAqnKlG/6E0ji+2tpvCfCE4YL20k+0jlzy7jfuy6Zah3EwDr7yW8IWkh+LG+LGsCtcIVuGEKbTYoAwO4NQy8oDiOKwyzAN1/Wx4vZlo246do+syIGn4u2K2NLhGjhcYXrOEdKx4QcXbJl/xOKoDHr0iURQVFM7LTEhX1g= 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=qqSG5ckZ4079NFsiXUYCqm/30qCVdht2JKffS9ADAL1pFaeXOJAZsnLSWxO8ip9zhZy1kW9kp/yu3DlBz1OsjP5Ayl51m2jiaq84byLW5EY66fFZt0lGqu0cWlVjvPTkHim3bsIrBo7q3fI74Wmpv/53/900gst78B6UzT3LTdo= Received: by 10.67.99.4 with SMTP id b4mr170731ugm.1184748972036; Wed, 18 Jul 2007 01:56:12 -0700 (PDT) Received: by 10.142.108.5 with HTTP; Wed, 18 Jul 2007 01:56:11 -0700 (PDT) Message-ID: <77f1dba80707180156j3c2abb19ye150c7f0a01ca801@mail.gmail.com> Date: Wed, 18 Jul 2007 17:56:11 +0900 From: "Eunsook \"Eunah\" Kim" To: 6lowpan <6lowpan@lists.ietf.org>, manet@ietf.org, rsn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [manet] Soliciting comments on 'draft-oh-6lowpan-packetbb-dymoapp-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 Dear all, For our project experiments, we have tried to apply an existing ad-hoc routing solution to our sensor network testbed. We chose to simplify both DYMO and the corresponding PacketBB for application to 6LoWPAN. We carried out this experiment as one example of "How to apply exisiting protocols to 6LoWPAN", and we hope that our document will serve as an informative input for discussing routing issues in 6LoWPAN, by... - providing guidelines on how to simplify existing ad-hoc routing solutions, and - defining a PacketBB for 6LoWPAN. The draft is available at: http://www.ietf.org/internet-drafts/draft-oh-6lowpan-packetbb-dymoapp-01.txt Thanks, -eunsook PS: I've put this on the RSN and MANET lists too, as some folks there might be interested in seeing this. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jul 18 20:46:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBK9x-0000zz-P1; Wed, 18 Jul 2007 20:46:25 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IBK9w-0000zm-KL for manet-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 20:46:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBK9w-0000zd-Ag for manet@ietf.org; Wed, 18 Jul 2007 20:46:24 -0400 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBK9v-0004SG-6K for manet@ietf.org; Wed, 18 Jul 2007 20:46:24 -0400 Received: by wx-out-0506.google.com with SMTP id h27so315964wxd for ; Wed, 18 Jul 2007 17:46: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:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=t04hqraEmVftbbVIuBUqYaoneEkSrLjYIqZCWGZd7WSha/SxUVl/hNPGwlynQ3q1QKd8f2SSfWkO3pIA8V4yGvrImrYnC9MMqhJ6TGPq9I/EwEMCGETW7TMC1i0Ho6L+7nvnYgz1bRMb1akXhp0rcC+CZ/XJ8LmG9cEpc1MNSLI= 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=gysavpOHEbDi5D+Qqprgpfjf8ntlVqYOSeeIb6vaSiRPtb3clcKclOwJb/ECj/V5khs5AbWe1/8CavFOjM+aIBjl6Hd+myqCTE83d5g0Dfw6bYWF2VQGmLsh/9wMcfwDGsaB+dHs5gKcPIYXe9f2msHSvnnDR4ZSpztTCnypnNs= Received: by 10.90.36.3 with SMTP id j3mr2351348agj.1184805982780; Wed, 18 Jul 2007 17:46:22 -0700 (PDT) Received: by 10.90.56.12 with HTTP; Wed, 18 Jul 2007 17:46:22 -0700 (PDT) Message-ID: Date: Wed, 18 Jul 2007 17:46:22 -0700 From: "Anand PG" To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 7b67622444b66205 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [manet] WiMAX in Mesh mode X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear All, Can anyone please point me in the right direction as to where I can get hold of a WiMAX simulation model (in NS or any other) WITH MESH MODE? The ones I have come across so far have a PMP (Point-to-Multipoint) implementation and not the mesh implementation. Kind Regards Anand _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jul 19 08:40:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVIq-0001oP-Cm; Thu, 19 Jul 2007 08:40:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IBVIo-0001kj-Jg for manet-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:40:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IBVIo-0001jn-9h for manet@ietf.org; Thu, 19 Jul 2007 08:40:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVHm-0007VX-8v for manet@ietf.org; Thu, 19 Jul 2007 08:39:14 -0400 Received: from web50611.mail.re2.yahoo.com ([206.190.38.157]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBVHl-00079K-WB for manet@ietf.org; Thu, 19 Jul 2007 08:39:14 -0400 Received: (qmail 44946 invoked by uid 60001); 19 Jul 2007 12:39:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=1nsC/7OZGDKQwLo+aPAkN9CQPzTE4R94FWWKjb4XvdtZEr5S+j6dk+fbA6xEeN1TlXcmNARRwrCkwRb5QoBUej5EguKBngjZeT3r6v0FKzj2jrl/ZIGmDZcpF99+XmP1vtdKKWn9Yu3yB7TcENcjrzWeCMM72XFUuvqfLR9BJkQ=; X-YMail-OSG: glQPSJcVM1mXO0ylWHJyz78h12QUfnguKnwGwXw4CUe9QYCpNBuRTW2x1WscKSQO1A-- Received: from [202.154.224.112] by web50611.mail.re2.yahoo.com via HTTP; Thu, 19 Jul 2007 05:39:13 PDT Date: Thu, 19 Jul 2007 05:39:13 -0700 (PDT) From: Muhammad saleem Sheikh To: manet ietf MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <786315.44237.qm@web50611.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-TMDA-Confirmed: Thu, 19 Jul 2007 08:40:18 -0400 Subject: [manet] confirm of message X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shm_saleem@yahoo.com List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org hi ____________________________________________________________________________________ Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jul 19 08:42: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 1IBVKe-0002hS-QO; Thu, 19 Jul 2007 08:42:12 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IBVKd-0002h9-56 for manet-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:42:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVKc-0002h1-R2 for manet@ietf.org; Thu, 19 Jul 2007 08:42:10 -0400 Received: from web50610.mail.re2.yahoo.com ([206.190.38.249]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBVKc-0007Ei-HD for manet@ietf.org; Thu, 19 Jul 2007 08:42:10 -0400 Received: (qmail 86978 invoked by uid 60001); 19 Jul 2007 12:42:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=stBYZhloPtDEVh0CseBeRXsIRWORxWUQKKxEMEQqSdvH8LtR7DHcmZvL+uVK1eyPSGyVqLaMvGhzGZ/LPM3F3HaKZDMAJ3rDICD7LQ1ByV+ogS4j77DhKWVUx5elvf7Jw0VkODgYN6+ogWOPEjzAz7vrsk/f1KxZaT3u+MjvyeY=; X-YMail-OSG: pviea0UVM1meTlXyk9ANS69yFcGMvZo9v3jADaaL5HfapOKXRziTkpvvy.oeZc0ZhHlpQsVSnF6Kkg.yzPFDuD6lXaYtxB2E7RRrptf2MpqU6LwOtbI1OOBw_Maz2w-- Received: from [202.154.224.112] by web50610.mail.re2.yahoo.com via HTTP; Thu, 19 Jul 2007 05:42:10 PDT Date: Thu, 19 Jul 2007 05:42:10 -0700 (PDT) From: Muhammad saleem Sheikh To: manet ietf MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <164131.86451.qm@web50610.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [manet] MANET Help X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shm_saleem@yahoo.com List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I'm a new research student focusing on data replication in MANET. I may work on improving data accessibility and maintaining data consistency through replication in MANET under cluster arechtecture. 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 ____________________________________________________ ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jul 19 16:06: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 1IBcGT-0003JI-Qj; Thu, 19 Jul 2007 16:06:21 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IBcGT-0003JD-0f for manet-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 16:06:21 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IBcGS-0003J5-NY for manet@ietf.org; Thu, 19 Jul 2007 16:06:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbyk-0006vN-Vw for manet@ietf.org; Thu, 19 Jul 2007 15:48:03 -0400 Received: from alpha.xerox.com ([13.1.64.93]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBbyk-0003CP-Dc for manet@ietf.org; Thu, 19 Jul 2007 15:48:02 -0400 Received: from goldeneye.parc.com ([13.1.136.10]) by alpha.xerox.com with SMTP id <143278(1)>; Thu, 19 Jul 2007 12:47:50 PDT Received: from [13.1.110.82] ([13.1.110.82]) by goldeneye.parc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 12:47:50 -0700 Message-ID: <469FBFE7.9010808@parc.com> Date: Thu, 19 Jul 2007 12:47:51 PDT From: Marc Mosko User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 19:47:50.0296 (UTC) FILETIME=[B04C6180:01C7CA3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-TMDA-Confirmed: Thu, 19 Jul 2007 16:06:20 -0400 Subject: [manet] Postdoc position 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 Computing Science Laboratory (CSL) at the Palo Alto Research Center (PARC) invites applications for a full-time postdoctoral research or visiting scholar position in the areas of ad hoc wireless networking and Internet architecture starting in the fall of 2007. The candidate should have adequate research experience demonstrated through publications in international conferences and journals and implementations of working prototypes. Good verbal and written skills in English are essential. The candidate is expected to carry out research in at least one of the following areas in wireless ad hoc networks or Internet technology. The projects include: (a) Content-centric networking, which aims at developing a new architecture for the Internet focusing on content rather than connectivity of networks or hosts; (b) robust internetworking in disrupted environments, which is developing novel protocols and techniques for content dissemination in wireless networks subject to disruption; (c) multi-radio, spectrum-agile networks, which aims at developing algorithms and protocols for ad hoc networks of nodes endowed with multiple spectrum agile radios; and (d) multimedia dissemination in all-wireless networks, which aims at developing architectures and protocols for one-to-one and many-to-many communication using voice, video and data in WiFi compatible ad hoc networks. Preferably, a candidate should be able to implement research ideas in functioning prototypes in an appropriate programming language. For networking projects, a familiarity with Qualnet or ns2 and Linux kernel programming is a plus. The positions are available immediately for one year and are extensible to multiple years based on performance. If you are interested please send your CV, links to selected publications, and the names of three references to Dr. Marc Mosko (mmosko at parc dot com). _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Jul 21 04:23: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 1ICAF4-000084-Bl; Sat, 21 Jul 2007 04:23:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ICAF3-0008S9-3A for manet-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 04:23:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICAF2-0008PQ-M6 for manet@ietf.org; Sat, 21 Jul 2007 04:23:08 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICAF1-00036o-S9 for manet@ietf.org; Sat, 21 Jul 2007 04:23:08 -0400 Received: by nf-out-0910.google.com with SMTP id c10so74063nfd for ; Sat, 21 Jul 2007 01:23:07 -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:references; b=cHmHHjh9fhuBsFZUSpKNWmdDJSD9CTpjffcWrBxANsG/qrdbDnm9By9MJTRAszNCv6ZOzxK2EZ9Vsa2fAuixI9Cwpb7KxtOEJlwJUW/mo3tZa1YUol64FVBBRJD3D3phRvx5a7X1TRKi5dupdkTBS+3UsbSc3lRQJCa4FfSmfys= 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:references; b=CXi8J3bAdMkFUYwYRWh4E2bJQGjv+7m0WGMI72i17kmRH9B3C7lsVqSirHOK3+1BWknOgky8X8UDkdePdXUrJFtzCMW7lQPpIeoQfyvSGOQzz0zxsAc4lQ1E1rggVs0qkZL/WYNu/VMY+u15XYpdH58BYsQMJCLUZohSRyKGxRc= Received: by 10.86.70.8 with SMTP id s8mr904946fga.1185006186828; Sat, 21 Jul 2007 01:23:06 -0700 (PDT) Received: by 10.86.82.5 with HTTP; Sat, 21 Jul 2007 01:23:06 -0700 (PDT) Message-ID: Date: Sat, 21 Jul 2007 10:23:06 +0200 From: "Abdelouahid Derhab" To: shm_saleem@yahoo.com Subject: Re: [manet] MANET Help In-Reply-To: <164131.86451.qm@web50610.mail.re2.yahoo.com> MIME-Version: 1.0 References: <164131.86451.qm@web50610.mail.re2.yahoo.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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: , Content-Type: multipart/mixed; boundary="===============1129898103==" Errors-To: manet-bounces@ietf.org --===============1129898103== Content-Type: multipart/alternative; boundary="----=_Part_2201_2380347.1185006186789" ------=_Part_2201_2380347.1185006186789 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Muhammand, Here are some references: 1- Hao Yu and Hossam Hassanein Patrick Martin. Cluster-based replication fo= r large-scale mobile ad-hoc networks. In *International Conference on Wireles= s Networks, Communications and Mobile Computing*, pages 552-557, June 2005. 2- Jing Zheng, Jinshu Su, and Xicheng Lu. A clustering-based data replication algorithm in mobile ad hoc networks for improving data availability. In *Proceedings of 2nd International Symposium on Parallel an= d Distributed Processing and Applications (ISPA 2004)*, pages 399-409, 2004. 3- Abdelouahid Derhab and Nadjib Badache. Localized hybrid data delivery scheme using k-hop clustering algorithm in ad hoc networks. In *Proceedings of the 3rd IEEE International Conference on Mobile Adhoc and Sensor Systems Conference, (MASS 2006)*, October 2006. Best regards. Abdelouahid Derhab On 7/19/07, Muhammad saleem Sheikh wrote: > > I'm a new research student focusing on data > replication in MANET. I may work on improving data > accessibility and maintaining data consistency through > replication in MANET under cluster arechtecture. > > 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 > > ____________________________________________________ > > > > > _________________________________________________________________________= ___________ > Luggage? GPS? Comic books? > Check out fitting gifts for grads at Yahoo! Search > http://search.yahoo.com/search?fr=3Doni_on_mail&p=3Dgraduation+gifts&cs= =3Dbz > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > --=20 Name: Abdelouahid Derhab Affiliation: Basic software laboratory, CERIST. Address: Rue des 3 fr=E8res A=EFssou Ben Aknoun BP 143 Alger 16030 Alg=E9ri= e Tel +213 21 91 62 05/08 Fax +213 21 91 21 26 ------=_Part_2201_2380347.1185006186789 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Muhammand,
 
Here are some references:
 

1- Hao Yu and Hossam Hassanein Patrick Martin. Cluster-ba= sed replication for large-scale mobile ad-hoc networks. In

International Conference on Wireless Network= s, Communications and Mobile Computing , pages 552-557, June 2005.

2- Jing Zheng, Jinshu Su, and= Xicheng Lu. A clustering-based data replication algorithm in mobile ad hoc= networks for improving data availability. In=20 Proceedings of 2nd International= Symposium on Parallel and Distributed Processing and Applications (ISPA 20= 04), pages 399-409, 2004.=

3- Abdelouahid Derhab and Nadjib Badache. Localized hybri= d data delivery scheme using k-hop clustering algorithm in ad hoc networks.= In

Proceedings of the 3rd I= EEE International Conference on Mobile Adhoc and Sensor Systems Conference,= (MASS 2006) , October 2006.
Best regards.
Abdelouahid Derhab

 
On 7/19/07, = Muhammad saleem Sheikh <shm_= saleem@yahoo.com> wrote:
I'm a new research student f= ocusing on data
replication in MANET. I may work on improving data
ac= cessibility and maintaining data consistency through
replication in MANET under cluster arechtecture.

Any one that ha= ve good sources of information in
this field plz replay.

Waiting = of prompt responce,which help me alot.


Thanks in advance.

Regards,
Saleem

_____________________________________________= _______



     ___________________________= _________________________________________________________
Luggage? GPS? = Comic books?
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=3Doni_on_mail&p=3Dgraduation+gifts&a= mp;cs=3Dbz


_______________________________________________
manet ma= iling list
manet@ietf.org
https://www1.ietf.org/m= ailman/listinfo/manet



--
Name: Abdelouah= id Derhab

Affiliation: Basic software laboratory, CERIST.

Add= ress: Rue des 3 fr=E8res A=EFssou Ben Aknoun BP 143 Alger 16030 Alg=E9rie
Tel +213 21 91 62 05/08

Fax +213 21 91 21 26=20 ------=_Part_2201_2380347.1185006186789-- --===============1129898103== 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 --===============1129898103==-- From manet-bounces@ietf.org Mon Jul 23 18:33: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 1ID6TC-0006El-Io; Mon, 23 Jul 2007 18:33:38 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ID6TA-0006Eg-KW for manet-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 18:33:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID6TA-0006EY-AJ for manet@ietf.org; Mon, 23 Jul 2007 18:33:36 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID6TA-0005gF-1z for manet@ietf.org; Mon, 23 Jul 2007 18:33:36 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1221014nzf for ; Mon, 23 Jul 2007 15:33:35 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=DggszfNHHLff/GOVGIxVkZyhk/0WWityzDzMTTNpYQf08PBCb7o5dKn0ihhgkSSgwOf3H9fa+Kchsi/jl5R76TaRzpwrSISf5RaSxTpYY/YDyRDvZXh4ipcSOVaY7LvwSTRLTTGuVUPgmEyvIRYUozQtIc4qWa0aN9XoahDN430= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=YigYoQQjuaNWaAVBKxTrmrPHgu3tmW91YEJnmNTPP4AK8922cbAsTl8CpTVcJ3lVkfV4GteV3Us1VdW5kWwDKIEo3VzYlAIFHE0i4wlV7jUpx7PTR2ebGDPX+9J5R63kbbGL7tTIodkQqLLJ7HYeHosQ78ltF/YAzwzm22XBo8A= Received: by 10.115.46.9 with SMTP id y9mr3421059waj.1185230014787; Mon, 23 Jul 2007 15:33:34 -0700 (PDT) Received: by 10.114.112.17 with HTTP; Mon, 23 Jul 2007 15:33:28 -0700 (PDT) Message-ID: <1716228e0707231533k36f542b9v57cdd01b08b30f20@mail.gmail.com> Date: Tue, 24 Jul 2007 07:33:34 +0900 From: "=?ISO-2022-JP?B?GyRCQmdPQkVEQllHbBsoQg==?=" To: manet@ietf.org In-Reply-To: <1716228e0707231529u659df9dcs294cc6689336fc9c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1716228e0707231529u659df9dcs294cc6689336fc9c@mail.gmail.com> X-Google-Sender-Auth: f25192ead37c927e X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [manet] How to distinguish MANET interfaces and other interfaces? 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. In the NHDP-04, 10.1.1, OTHER_IF is used for distinguish MANET interface or not. But in this context, addresses which are in the local interface address block and does not have OTHER_IF TLV are inserted to the Link Set. But, when node has two different channel MANET interfaces and each interface has two addresses, that node's local address block does not include OTHER_IF and every four addresses are included. In this case, every addresses included in the local address block are inserted into the Link Set, but other channel interface addresses should not be inserted in the Link Set. I think, another TLV should be define for distinguish MANET interface or not. Or this is our misunderstanding? Thanks, Owada & Satoh -- Niigata University, Japan Yasunori Owada Satoh, hiroki Hitachi Ltd., Systems Development Laboratory _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jul 24 00:56:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDCRL-0001oW-IQ; Tue, 24 Jul 2007 00:56:07 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IDCRK-0001oR-C6 for manet-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 00:56:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDCRJ-0001oI-PE for manet@ietf.org; Tue, 24 Jul 2007 00:56:05 -0400 Received: from falcon.cqu.edu.au ([138.77.5.11] helo=mx.cqu.edu.au) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDCRI-0003PX-Ow for manet@ietf.org; Tue, 24 Jul 2007 00:56:05 -0400 Received: from [127.0.0.1] (helo=falcon.cqu.edu.au) by mx.cqu.edu.au with esmtp (Exim 4.63) (envelope-from ) id 1IDCR8-0002BY-8b; Tue, 24 Jul 2007 14:55:54 +1000 Received: from UNIMAIL.staff.ad.cqu.edu.au (remus.staff.ad.cqu.edu.au [138.77.34.93]) by falcon.cqu.edu.au (8.13.8/8.13.8) with ESMTP id l6O4tiD9008379; Tue, 24 Jul 2007 14:55:48 +1000 (EST) (envelope-from a.gyasi-agyei@cqu.edu.au) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jul 2007 14:55:39 +1000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CFP: ICAST'07 Extended Paper Submission Deadline 30 August'07 Thread-Index: AcfNr6Nj1HEyh+OdShaXjR4DiHj9dg== From: "Amoakoh Gyasi-Agyei" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: manet@ietf.org Subject: [manet] CFP: ICAST'07 Extended Paper Submission Deadline 30 August'07 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="===============0825713016==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============0825713016== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CDAE.E1958A2C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CDAE.E1958A2C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Researcher/Professional, [ I apologise in advance if this email disturbs you in any way. Thanks] We're pleased to update you with the following about ICAST'07 conference (Details at http://home.vicnet.net.au/~icastdn/) Extended Paper submission deadline: 30 August 2007 (Please submit online at https://www.conftool.net/icast07/) Early-bird registration deadline: 15 Oct 2007 (Please register online at https://www.conftool.net/icast07/) Thankyou Amoakoh ------_=_NextPart_001_01C7CDAE.E1958A2C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CFP: ICAST'07 Extended Paper Submission Deadline 30 = August'07

Dear = Researcher/Professional,

[ I apologise in advance if = this email disturbs you in any way. Thanks]

We're pleased to update you = with the following about ICAST'07 conference
(Details at = http://home.vicnet.net.au/~icastdn/<= SPAN LANG=3D"en-au">)

Extended Paper = submission deadline: 30 August 2007 = (Please submit online at https://www.conftool.net/icast07/)

Early-bird registration = deadline: 15 Oct 2007  (Please = register online at https://www.conftool.net/icast07/)


Thankyou
Amoakoh

------_=_NextPart_001_01C7CDAE.E1958A2C-- --===============0825713016== 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 --===============0825713016==-- From manet-bounces@ietf.org Tue Jul 24 03:27: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 1IDEnr-0000ue-Vw; Tue, 24 Jul 2007 03:27:31 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IDEno-0000pt-PQ for manet-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 03:27:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDEno-0000mg-BH for manet@ietf.org; Tue, 24 Jul 2007 03:27:28 -0400 Received: from lnx131.hrz.tu-darmstadt.de ([130.83.174.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDEnl-0007Y7-AL for manet@ietf.org; Tue, 24 Jul 2007 03:27:26 -0400 Received: from deeds05.deeds.informatik.tu-darmstadt.de (deeds05.deeds.informatik.tu-darmstadt.de [130.83.162.134]) by lnx131.hrz.tu-darmstadt.de (8.13.4/8.12.10) with ESMTP id l6O7R8L0014017; Tue, 24 Jul 2007 09:27:08 +0200 Received: from DEEDS03 (deeds03.deeds.informatik.tu-darmstadt.de [130.83.162.133]) by deeds05.deeds.informatik.tu-darmstadt.de (8.13.8/8.13.8) with ESMTP id l6O7R7CF017745; Tue, 24 Jul 2007 09:27:07 +0200 From: "Abdelmajid Khelil" To: , , Date: Tue, 24 Jul 2007 09:27:07 +0200 Message-ID: <001c01c7cdc4$0aba63e0$85a25382@deeds.informatik.tudarmstadt.de> 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: AcfNxApkmudTXfn7SfKCPjB1nNiwcg== X-TUD-HRZ-MailScanner: Found to be clean X-TUD-HRZ-MailScanner-SpamCheck: X-MailScanner-From: khelil@informatik.tu-darmstadt.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: 'Ismail Khalil Ibrahim' , 'Thomas Grill' Subject: [manet] CFP - TwUC 2007 - The 2nd International Workshop on Trustworthy Ubiquitous Computing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org -------- Apologies for multiple postings ----------- CALL FOR PAPERS - TwUC 2007 Second International Workshop on Trustworthy Ubiquitous Computing (TwUC 2007) December 3-5, 2007 Jakarta, Indonesia http://flash.tk.uni-linz.ac.at/conferences/twuc2007 ---------------------------------------------------------------------------- The 2nd Workshop on Trustworthy Ubiquitous Computing (TwUC 2007) is held in conjunction with IIWAS2007, December 3-5, 2007, in Jakarta, Indonesia. Ubiquitous applications are getting more and more to the market these days. In spite of many applications and projects in the area of ubiquitous and pervasive computing the success of this technologies and the acceptance from the user is still low resulting from missing trust into computing systems introduced into our real world. TwUC was established to provide a forum to scientists, engineers and industry to address recent research results, to present and discuss their ideas, theories, technologies, systems, tools, applications, work in progress and experiences on all theoretical and practical issues and to elaborate about the research areas of security, reliability and privacy which build the basis for creating trustworthy interfaces and computing environments for people interacting in ubiquitous environments. TOPICS OF INTEREST The conference program will include invited talks, peer reviewed full papers around but not limited to the following topics: - Security in ubiquitous computing environments - Security issues and technologies - Usage policies - Identity and access - Threat and vulnerability - Malicious software in ubiquitous environments - Integrity - Trusted computing - Trusting platforms - Reliability in ubiquitous computing environments - Software design - Software quality and metrics - User perceived QoS - Methods and concepts to enhance and ensure availability - Privacy in ubiquitous computing environments - Issues and appliances on privacy in ubiquitous computing environments - Data and information ownership and souvereignity of social and technical methods for ensuring confidentiality - Usability in ubiquitous computing environments - Designing the user interface in ubiquitous environments - Designing Interaction for ubiquitous appliances - Usability Evaluation Methods in ubiquitous environments IMPORTANT DATES September 1, 2007 Paper submission October 1, 2007 Acceptance Notification October 15, 2007 Camera-Ready Papers December 3-5, 2007 Workshop PUBLICATION All accepted conference papers will be published in the Austrian Computer Society book series. Distinguished papers, after further revisions, will be published in selected journals. For a detailed list of journals please visit our website http://flash.tk.uni-linz.ac.at/conferences/twuc2007 SUBMISSION The TwUC2007 workshop solicits full and short research papers. For detailed information concerning the submission please visit our website http://flash.tk.uni-linz.ac.at/conferences/twuc2007 CONTACT Thomas Grill Department of Telecooperation Johannes Kepler University Linz Altenberger Str. 69 4040 Linz, Austria Email: tom[at]iiwas.org _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jul 24 08:28: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 1IDJUU-0005st-50; Tue, 24 Jul 2007 08:27:50 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ID6P6-0005cE-Ko for manet-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 18:29:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID6P6-0005c6-B3 for manet@ietf.org; Mon, 23 Jul 2007 18:29:24 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID6P6-0005aq-1F for manet@ietf.org; Mon, 23 Jul 2007 18:29:24 -0400 Received: by wa-out-1112.google.com with SMTP id k17so2696485waf for ; Mon, 23 Jul 2007 15:29:23 -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=QeZ197x80Ig4DsNLppmblHwkuiqP3Eo+qFKOl40zAHx5yv6B8VG+m3GLw09Mfu54I1Ozs0twmZBJOlOUKueIWxzI8AcdOcmpJets6YOCvfniMC5TdofT5RqVAt/tbRObo6LrVT1nV79SKxcyB9FJFgg6CSxTn0jrJcue8fyA7fk= 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=cBZ+OpQxu4XdGSv7FUd1uvgKJ4J8q967Qn+6GubN+AzRPSRbRJV8plPP3EDuQCbte0X7IPbX+j3BFGZ8Ap+ZqSCv/esBTQ2Kr6jrn39MmeNLNffCrBzO8AenmvktD2I9/je8LIeVL2tIUsX6ClqRFMHMagoTTBRCBnAQA+GXevQ= Received: by 10.114.79.1 with SMTP id c1mr3422501wab.1185229763190; Mon, 23 Jul 2007 15:29:23 -0700 (PDT) Received: by 10.114.112.17 with HTTP; Mon, 23 Jul 2007 15:29:22 -0700 (PDT) Message-ID: <1716228e0707231529u659df9dcs294cc6689336fc9c@mail.gmail.com> Date: Tue, 24 Jul 2007 07:29:22 +0900 From: "=?ISO-2022-JP?B?GyRCQmdPQkVEQllHbBsoQg==?=" To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 3c1f942b8ec6f151 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Tue, 24 Jul 2007 08:27:48 -0400 Subject: [manet] How to distinguish MANET interfaces and other interfaces? 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. In the NHDP-04, 10.1.1, OTHER_IF is used for distinguish MANET interface or not. But in this context, addresses which are in the local interface address block and does not have OTHER_IF TLV are inserted to the Link Set. But, when node has two different channel MANET interfaces and each interface has two addresses, that node's local address block does not include OTHER_IF and every four addresses are included. In this case, every addresses included in the local address block are inserted into the Link Set, but other channel interface addresses should not be inserted in the Link Set. I think, another TLV should be define for distinguish MANET interface or not. Or this is our misunderstanding? Thanks, Owada & Satoh -- Niigata University, Japan Yasunori Owada Satoh, hiroki Hitachi Ltd., Systems Development Laboratory _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jul 25 10:57:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiIN-0004KD-6O; Wed, 25 Jul 2007 10:56:59 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IDiIK-0004K6-46 for manet-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 10:56:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiIJ-0004Jy-QR for manet@ietf.org; Wed, 25 Jul 2007 10:56:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDiIJ-0000jy-EN for manet@ietf.org; Wed, 25 Jul 2007 10:56:55 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2007 10:56:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJsBp0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,581,1175486400"; d="scan'208"; a="126981887:sNHT88402872" 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 l6PEusdP017985; Wed, 25 Jul 2007 10:56:54 -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 l6PEuoWQ026734; Wed, 25 Jul 2007 14:56:50 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, 25 Jul 2007 10:56:48 -0400 Received: from [10.81.246.143] ([10.81.246.143]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 10:56:48 -0400 Message-ID: <46A764AC.1000605@cisco.com> Date: Wed, 25 Jul 2007 10:56:44 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: T.Clausen@computer.org, manet@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2007 14:56:48.0384 (UTC) FILETIME=[06AA9000:01C7CECC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=439; t=1185375414; x=1186239414; 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:=20Comments=20on=20draft-ietf-manet-packetbb-08.txt |Sender:=20 |To:=20T.Clausen@computer.org,=20manet@ietf.org; bh=BHJU3fKSkqepzY5nwcfLur4YKjtStm40rT4kG1xwPi0=; b=ipfhb2v6xZekrVqPiHiPdb1jud1h0r/Kh9sXM1CmGQ1lpOxWOU3BX/8Jmq1iJCZ6SCE4tPDj ur8uq9Fd+eZx2EMMUWp/ilshVYd3Jw466D4gZwbh/G7YavgSZq9cqVMX; 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [manet] Comments on draft-ietf-manet-packetbb-08.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 Thomas: In the Address Block Examples section, could you please add examples that include IPv6 addresses that are based upon the head/tail-length? This would help validate the intended flexibility of the address block. And if possible, could you add a paragraph or two on the suggestions or requirements when building the address block as well as parsing and validating the address entries. Thanks -Bo Berry Cisco RTP, NC _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jul 25 11:00: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 1IDiLc-0006og-PA; Wed, 25 Jul 2007 11:00:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IDiLa-0006oa-9h for manet-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 11:00:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiLZ-0006oS-Ve for manet@ietf.org; Wed, 25 Jul 2007 11:00:18 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDiLZ-0005LF-LU for manet@ietf.org; Wed, 25 Jul 2007 11:00:17 -0400 Received: from dhcp-11e6.ietf69.org ([130.129.17.230]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IDiLW-0007Zq-Kl; Wed, 25 Jul 2007 11:00:14 -0400 X-MHO-User: U2FsdGVkX18NGiv6IBcAfaPZwUs7NDe9 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.17.230 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+BnXeRNzNpfPlzA/Tjw8dD In-Reply-To: <46A764AC.1000605@cisco.com> References: <46A764AC.1000605@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: Thomas Clausen Date: Wed, 25 Jul 2007 17:00:25 +0200 To: Bo Berry X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: manet@ietf.org Subject: [manet] Re: Comments on draft-ietf-manet-packetbb-08.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 Bo, Thanks for your comment. I'd be happy to do so -- would you have any preferences for *which* examples you'd like to see, or shall I just take my best pick? Cheers, Thomas On Jul 25, 2007, at 4:56 PM, Bo Berry wrote: > Thomas: > > In the Address Block Examples section, could you please add examples > that include IPv6 addresses that are based upon the head/tail-length? > This would help validate the intended flexibility of the address > block. > > And if possible, could you add a paragraph or two on the suggestions > or requirements when building the address block as well as parsing > and validating the address entries. > > Thanks > -Bo Berry > Cisco > RTP, NC > > > > > > > > > > > > > -- 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 Wed Jul 25 11:06: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 1IDiRe-00026L-A9; Wed, 25 Jul 2007 11:06:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IDiRd-00026G-6n for manet-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 11:06:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiRc-000268-SA for manet@ietf.org; Wed, 25 Jul 2007 11:06:32 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDiRc-0005Ut-Df for manet@ietf.org; Wed, 25 Jul 2007 11:06:32 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2007 11:06:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEADp0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,581,1175486400"; d="scan'208"; a="66106215:sNHT4933520636" 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 l6PF6F1U005307; Wed, 25 Jul 2007 11:06:15 -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 l6PF64Et020998; Wed, 25 Jul 2007 15:06:15 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, 25 Jul 2007 11:06:11 -0400 Received: from [10.81.246.143] ([10.81.246.143]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 11:06:11 -0400 Message-ID: <46A766E1.2010508@cisco.com> Date: Wed, 25 Jul 2007 11:06:09 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Thomas Clausen References: <46A764AC.1000605@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2007 15:06:11.0511 (UTC) FILETIME=[5650EC70:01C7CECD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=974; t=1185375975; x=1186239975; 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=20Comments=20on=20draft-ietf-manet-packetbb-08.txt |Sender:=20 |To:=20Thomas=20Clausen=20; bh=WhVyYdF+b/Xzr9KF7UWrkh9s8wu95eX5042lVD6R9cA=; b=iV9kwNWHitzrvQ61qxzFWI8DPcecvaKk0dI2TQaB7bCvYjXt7geSnAjpVPKumx+M3QNRDhsf R8CLh44i2So25nH0OWD2KXD6I/lRs8GX9845W8X/w5YrQY1SvYiVr2c0; 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: 0ddefe323dd869ab027dbfff7eff0465 Cc: manet@ietf.org Subject: [manet] Re: Comments on draft-ietf-manet-packetbb-08.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 Thomas: There are many scenarios in the manet RFCs and drafts that you can choose from. These would demonstrate 'real' examples. Thanks -Bo Thomas Clausen wrote: > Bo, > > Thanks for your comment. > > I'd be happy to do so -- would you have any preferences for *which* > examples you'd like to see, or shall I just take my best pick? > > Cheers, > > Thomas > > On Jul 25, 2007, at 4:56 PM, Bo Berry wrote: > >> Thomas: >> >> In the Address Block Examples section, could you please add examples >> that include IPv6 addresses that are based upon the head/tail-length? >> This would help validate the intended flexibility of the address block. >> >> And if possible, could you add a paragraph or two on the suggestions >> or requirements when building the address block as well as parsing >> and validating the address entries. >> >> Thanks >> -Bo Berry >> Cisco >> RTP, NC >> >> >> >> >> >> >> >> >> >> >> >> >> > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jul 25 11:48: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 1IDj5j-0003Dw-Ci; Wed, 25 Jul 2007 11:47:59 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IDj5g-0003Do-Uw for manet-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 11:47:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDj5g-0003De-Jh for manet@ietf.org; Wed, 25 Jul 2007 11:47:56 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDj5g-0006qj-7k for manet@ietf.org; Wed, 25 Jul 2007 11:47:56 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6PFltfP020596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 25 Jul 2007 08:47:55 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6PFlsiV014081 for ; Wed, 25 Jul 2007 10:47:54 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6PFlcUc013412 for ; Wed, 25 Jul 2007 10:47:44 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 08:47:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jul 2007 08:47:41 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED93A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <46A766E1.2010508@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SMF IPv4 DPD and wrapping the ip_id field Thread-Index: AcfOzYsWBKIY8uqMTuu28whyIG6gVwABIiCA References: <46A764AC.1000605@cisco.com> <46A766E1.2010508@cisco.com> From: "Templin, Fred L" To: X-OriginalArrivalTime: 25 Jul 2007 15:47:41.0360 (UTC) FILETIME=[2261BB00:01C7CED3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [manet] SMF IPv4 DPD and wrapping the ip_id field 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 John Heffner's document on "IPv4 Reassembly Errors at High Data Rates" talks about implications of wrapping the 'ip_id' field. The document is now in the RFC Editor queue. Below is the abstract and link to the draft: Fred fred.l.templin@boeing.com Abstract IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. http://www.ietf.org/internet-drafts/draft-heffner-frag-harmful-05.txt _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jul 25 12:08: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 1IDjPW-0004bw-9n; Wed, 25 Jul 2007 12:08:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IDjPU-0004al-4B for manet-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 12:08:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjPT-0004aY-QQ for manet@ietf.org; Wed, 25 Jul 2007 12:08:23 -0400 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDjPS-00038e-LI for manet@ietf.org; Wed, 25 Jul 2007 12:08:23 -0400 Received: by nz-out-0506.google.com with SMTP id n1so201380nzf for ; Wed, 25 Jul 2007 09:08: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:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=GBYXD3Q4qnyUCIaNCQ5jUhaJGjFWQ3J5wHrkjPRwcOPHJiDs1Qhp3z+rYc7UFqoWGUGk1xwV50CdFOqwMV8xODbhkR+OrP95aLsyAal3NBw6EVWCyRNcxmv5K1NilLIGjXwEQB0ejODsFjY/ASaRvlbWJcjQjdgu++T9NFGdlns= 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=H+LkW4eUsDtsbKqUsUGfTCCyMBP9jw/20fuuoIaO6+m2EULvmbGrflpqKIi8CMXjlCZu4z7x/72TZFCP65CACC9iUZhELEHj2VgL+84P9OU88z/5sHMkK+LUtp3VauNnFwSbGHRd4eBJcJAi8euAI46TUhGfR4ftUXBqs0dr8I0= Received: by 10.141.99.4 with SMTP id b4mr233396rvm.1185379701861; Wed, 25 Jul 2007 09:08:21 -0700 (PDT) Received: by 10.141.53.2 with HTTP; Wed, 25 Jul 2007 09:08:21 -0700 (PDT) Message-ID: <13786f330707250908j43851d56tcb74cc3691ad36ec@mail.gmail.com> Date: Wed, 25 Jul 2007 12:08:21 -0400 From: "Joseph Kopena" To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: a009f28ca88a20ed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [manet] SMF: Packet ID & Sequencing 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 preface by saying that I didn't totally follow all of the concerns raised in today's SMF DPD/ID discussion. However, I wanted to echo Joe Macker's comments about not trusting IP implementations' packet IDs and sequencing. My group has (successfully) used SMF (NRL implementation) in several projects, including deployed products. The biggest problems we've encountered were due to poor packet sequencing on different versions of the Windows and Linux kernels. This was a large hurdle for platforms on which we could not readily enable nrlsmf's resquencing. Notably, even if newer kernels are better behaved (they seem to be), PDA, embedded, and ruggedized platforms will remain problematic in this regard for some time. Avoiding these issues or countering them directly (resequencing or hashing) are important goals. Thx -- - joe kopena secure wireless agent testbed drexel university _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jul 25 12:08: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 1IDjQ3-0005RV-Ff; Wed, 25 Jul 2007 12:08:59 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IDjQ1-0005Qx-Gx for manet-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 12:08:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjQ1-0005Qf-5Y for manet@ietf.org; Wed, 25 Jul 2007 12:08:57 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDjQ0-0007pE-LJ for manet@ietf.org; Wed, 25 Jul 2007 12:08:57 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 25 Jul 2007 09:08:56 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHoSp0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,581,1175497200"; d="scan'208"; a="10438257:sNHT31081008" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6PG8tDo004660; Wed, 25 Jul 2007 09:08:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6PG8tTb019148; Wed, 25 Jul 2007 16:08:55 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 09:08:54 -0700 Received: from [130.129.82.251] ([10.21.116.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 09:08:54 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <22318303-639C-4DFA-952A-4D9491750F92@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Wed, 25 Jul 2007 11:08:48 -0500 To: adamson@itd.nrl.navy.mil, "Christopher ((UK)) Dearlove" , t.clausen@computer.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jul 2007 16:08:54.0277 (UTC) FILETIME=[19197350:01C7CED6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2525; t=1185379735; x=1186243735; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Thoughts=20on=20draft-ietf-manet-jitter-01.txt |Sender:=20; bh=hgXsZISHR3GlQ+uVRIevj4Fd7F6FvDaZvIuW8mwsjiQ=; b=bfYIDYU6rWh6Cga731ld9dP7XahvGpeGxEMydemBHK/e0+z/S02T8g00F1S0HE5jFboqDwef zjGqCZIh3tW+Y3kVooCXaPLR1pVeBBWqpiVQyQ18tQjguRHyOcdOpxAO; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: manet Subject: [manet] Thoughts on draft-ietf-manet-jitter-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I read this document, and it seems generally reasonable to me. Some of its specific recommendations seem odd though, such as suggesting that the jitter imposed on a message might correctly make the inter- transmission interval less than the minimum inter-transmission interval. In general, I would suggest that the actual inter- transmission interval for some message should never be less than the minimum inter-transmission interval (or zero if that is not specified), and never be greater than the maximum inter-transmission interval. In general, though, the minimum inter-transmission interval is far smaller than the maximum, on the order of tens of milliseconds vs some number of seconds. Specifying the jitter in terms of the minimum inter-transmission interval is therefore a good way to get far too much traffic. Generally, the jitter specifies an interval on the order of 10-25% of the maximum inter-transmission interval for the message in question. For example, if an OSPF Hello is being sent nominally every ten seconds, the jitter is uniformly distributed over one second, so that actual inter-transmission intervals are somewhere between nine and ten seconds. A review of the following documents will let you know how jitter is used in common routing protocols along the lines you have suggested. I would suggest that you adjust your text to agree with their algorithms, which are proven in the field. As I read the text, I wasn't at all sure that it would have considered them to be correct. http://www.ietf.org/rfc/rfc1142.txt 1142 OSI IS-IS Intra-domain Routing Protocol. D. Oran, Ed.. February 1990. (Format: TXT=425379, PS=1440951, PDF=490300 bytes) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc1765.txt 1765 OSPF Database Overflow. J. Moy. March 1995. (Format: TXT=21613 bytes) (Status: EXPERIMENTAL) http://www.ietf.org/rfc/rfc1768.txt 1768 Host Group Extensions for CLNP Multicasting. D. Marlow. March 1995. (Format: TXT=111499 bytes) (Status: EXPERIMENTAL) http://www.ietf.org/rfc/rfc4271.txt 4271 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed.. January 2006. (Format: TXT=222702 bytes) (Obsoletes RFC1771) (Status: DRAFT STANDARD) For the record, OSPF, RIP, and other routing implementations are generally jittered as well, although there isn't an obvious specification for that. Timer jitter is generally on the order of 10%. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Jul 25 23:07: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 1IDtgZ-0008Mx-92; Wed, 25 Jul 2007 23:06:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IDtgY-0008Kj-7U for manet-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 23:06:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDtgX-0008Ia-Sg for manet@ietf.org; Wed, 25 Jul 2007 23:06:41 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDtgX-00021l-GA for manet@ietf.org; Wed, 25 Jul 2007 23:06:41 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2007 23:06:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHasp0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,582,1175486400"; d="scan'208"; a="127047064:sNHT30327026" 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 l6Q36fIg030721 for ; Wed, 25 Jul 2007 23:06:41 -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 l6Q36EEn028534 for ; Thu, 26 Jul 2007 03:06:41 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); Wed, 25 Jul 2007 23:06:31 -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); Wed, 25 Jul 2007 23:06:31 -0400 Message-ID: <46A80FAD.5080403@cisco.com> Date: Wed, 25 Jul 2007 23:06:21 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: manet@ietf.org References: <46A764AC.1000605@cisco.com> <46A766E1.2010508@cisco.com> <374005f30707251611u68cb874bpc1cf7a6dc7157cbd@mail.gmail.com> In-Reply-To: <374005f30707251611u68cb874bpc1cf7a6dc7157cbd@mail.gmail.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2007 03:06:31.0378 (UTC) FILETIME=[F75D4320:01C7CF31] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1814; t=1185419201; x=1186283201; 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:=20Comments=20on=20link=20metrics |Sender:=20 |To:=20manet@ietf.org; bh=2RXy3SHmFp4DduCaMErDaoMu0O5nj0P3+xY2OkVOXYo=; b=dqtZVB0LyFjXNuqXIxaANfLl4frw+u3OM9kGXPrk0Im6+l/AWdJrFqUj0i/tFbf5CPDAsvsh EY5ogdhx8QaeIFzfRCpJ3CoQ0+zR5UnYE4/SbVp+5QVMGjlWVoAL1Q/X; 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: 7aafa0432175920a4b3e118e16c5cb64 Subject: [manet] Comments on link metrics 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 As we begin the discussions on the two link metric drafts OLSRv2 Update + Link Metrics for OLSRv2 http://www3.ietf.org/proceedings/07jul/slides/manet-9.pdf Metrics TLV - Dean http://www3.ietf.org/proceedings/07jul/slides/manet-8.pdf it would be useful, as Teco mentioned, to review previous link metric work. One reference can be found in RFC 4938, PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics Here we used PPPoE links to logically connect a radio to OSPF. Very simply, the radio link metrics are periodically reported to the router. The router translates the link metrics into a link cost and injects the new cost into OSPF to influence routing. Key considerations -There are many radio transceiver encoding schemes, 802.11 based schemes are one. That being the case, we let the radio manage the RF links with periodic link metric reports. The link metrics were boiled down to an abstract list that the local node can process without having to build in a lot of radio know-how. -The radio links are under constant change due to the nature of RF. Given this environment, there is a need for heuristics in the radio to throttle link metric reports. -Because routing protocols have different definitions of link cost, it was important to be able to translate the link metrics into a link cost for each routing protocol. This code is really associated with the routing protocol. -When link metrics are translated into a new routing cost, heuristics were again needed to throttle the effective change in link cost to avoid excessive flooding. For example, if the newly computed link cost is 1 point change, is there really a need to flood the network? Hope this reference helps -Bo _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jul 26 08:28: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 1IE2Ry-0005zd-DZ; Thu, 26 Jul 2007 08:28:14 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IE2Rx-0005zT-L2 for manet-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 08:28:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE2Rx-0005zJ-9u for manet@ietf.org; Thu, 26 Jul 2007 08:28:13 -0400 Received: from hiltonsmtp.worldspice.net ([216.37.94.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE2Rw-0002SD-Eu for manet@ietf.org; Thu, 26 Jul 2007 08:28:12 -0400 Received: (qmail 19458 invoked by uid 0); 26 Jul 2007 12:20:33 -0000 Received: by simscan 1.2.0 ppid: 19416, pid: 19446, t: 1.0865s scanners: clamav: 0.90.2/m: spam: 3.1.8 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on hiltonsmtp.worldspice.net X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=6.5 tests=BAYES_99,RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO Teco) (67.97.210.2) by hiltonsmtp.worldspice.net with SMTP; 26 Jul 2007 12:20:32 -0000 From: "Teco_Boot" To: Date: Thu, 26 Jul 2007 14:28:50 +0200 Message-ID: <001401c7cf80$86552900$74d26143@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: AcfPgITSUgDfMHh4SBOfMcBGH64FMw== X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [manet] SMF: DPD for IPv4 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, After reading back the SMF doc on IPv4 DPD, I think the text needs to be more accurate what the exact DPD algorithm is. I think the algorithm specification should be provided for all combinations of ip_id, df flag, mf flag and fragment offset. Below a draft specification. I also think we should try to be 100% compliant with RFC791. The consequence is that the protocol field is part of the checked tuple, so it will become I also think we should write a recommendation on usage of the ip_id field. It would specify the need for using a sequenced value, including packets marked for df. It would be a very short document, updating RFC791. A big issue is the value zero. Is this value prohibited or not? In the draft specification below, I included extended DPD, supporting fragmentation. Tagging (rewriting the ip_id) is a concern, mentioned by Fred Templin. We could discuss using encapsulation. If we go for fixing ip_id usage, tagging is a migration tool and is not used for nice behaving senders. Teco. +---------+----+----+----------------+-----------------------------------+ | ip_id | df | mf | fragment offset| action | +---------+----+----+----------------+-----------------------------------+ | zero | 0 | 0 | zero | invalid, do not forward (1) | | zero | 0 | 1 | zero | invalid, do not forward (1) | | zero | 1 | 0 | zero | tag and forward (4) | | zero | 1 | 1 | zero | invalid, do not forward (2) | | zero | 0 | 0 | nonzero | invalid, do not forward (1) | | zero | 0 | 1 | nonzero | invalid, do not forward (1) | | zero | 1 | 0 | nonzero | invalid, do not forward (3) | | zero | 1 | 1 | nonzero | invalid, do not forward (2,3) | | nonzero | 0 | 0 | zero | DPD check and forward (5) | | nonzero | 0 | 1 | zero | extended DPD check and forward (6)| | nonzero | 1 | 0 | zero | DPD check and forward (5) | | nonzero | 1 | 1 | zero | invalid, do not forward (2) | | nonzero | 0 | 0 | nonzero | extended DPD check and forward (6)| | nonzero | 0 | 1 | nonzero | extended DPD check and forward (6)| | nonzero | 1 | 0 | nonzero | invalid, do not forward (3) | | nonzero | 1 | 1 | nonzero | invalid, do not forward (2,3) | +---------+----+----+----------------+-----------------------------------+ 1: When the df flag is clear, the ip_id must be a non-zero value. ====> the question is, is a non-zero value really not allowed? It could also be one of the 65536 values. 2: When the df flag is checked, the mf flag must be cleared. 3: When the df flag is checked, the fragment offset must be zero. ====> Not exactly specified in RFC791. 4: Tagging (resequencing) the ip_id should be performed once, on the edge (ingress) of the MANET. As hosts could use a MANET router MANET interface to connect, tagging on all MANET interfaces is required. 5: DPD algorithm uses . 6: Extended DPD algorithm uses . _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Jul 26 18:52: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 1IECCN-0001lW-8L; Thu, 26 Jul 2007 18:52:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IECCL-0001lR-Vr for manet-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 18:52:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECCL-0001lH-M1 for manet@ietf.org; Thu, 26 Jul 2007 18:52:45 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IECCL-0002a9-4g for manet@ietf.org; Thu, 26 Jul 2007 18:52:45 -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 l6QMqWUV006904; Thu, 26 Jul 2007 18:52:36 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007072618523131423 ; Thu, 26 Jul 2007 18:52:31 -0400 From: "Joe Macker" To: "'Teco_Boot'" , References: <001401c7cf80$86552900$74d26143@Teco> Subject: RE: [manet] SMF: DPD for IPv4 Date: Thu, 26 Jul 2007 18:52:29 -0400 Message-ID: <002901c7cfd7$a4e3a890$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001401c7cf80$86552900$74d26143@Teco> Thread-Index: AcfPgITSUgDfMHh4SBOfMcBGH64FMwAVc+JQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Teco: These are some good notes. I believe we can consider adding the fragmentation support as you outlined and will begin discussing this with other contributors. I believe the DF set (ID=0) rewriting case does not break anything and is not used for IPSEC or fragmentation, but I will continue to discuss this with others. We know we have embedded kernels with this characteristic as part of early deployments. Thank you, Joe >-----Original Message----- >From: Teco_Boot [mailto:teco@inf-net.nl] >Sent: Thursday, July 26, 2007 8:29 AM >To: manet@ietf.org >Subject: [manet] SMF: DPD for IPv4 > >Hi, > >After reading back the SMF doc on IPv4 DPD, I think the text >needs to be more accurate what the exact DPD algorithm is. > >I think the algorithm specification should be provided for all >combinations of ip_id, df flag, mf flag and fragment offset. >Below a draft specification. > >I also think we should try to be 100% compliant with RFC791. >The consequence is that the protocol field is part of the >checked tuple, so it will become > > >I also think we should write a recommendation on usage of the >ip_id field. >It would specify the need for using a sequenced value, >including packets marked for df. It would be a very short >document, updating RFC791. >A big issue is the value zero. Is this value prohibited or not? > >In the draft specification below, I included extended DPD, >supporting fragmentation. > >Tagging (rewriting the ip_id) is a concern, mentioned by Fred >Templin. We could discuss using encapsulation. If we go for >fixing ip_id usage, tagging is a migration tool and is not >used for nice behaving senders. > >Teco. > > > >+---------+----+----+----------------+------------------------- >----------+ >| ip_id | df | mf | fragment offset| action > | >+---------+----+----+----------------+------------------------- >----------+ >| zero | 0 | 0 | zero | invalid, do not forward >(1) | >| zero | 0 | 1 | zero | invalid, do not forward >(1) | >| zero | 1 | 0 | zero | tag and forward (4) > | >| zero | 1 | 1 | zero | invalid, do not forward >(2) | >| zero | 0 | 0 | nonzero | invalid, do not forward >(1) | >| zero | 0 | 1 | nonzero | invalid, do not forward >(1) | >| zero | 1 | 0 | nonzero | invalid, do not forward >(3) | >| zero | 1 | 1 | nonzero | invalid, do not forward >(2,3) | >| nonzero | 0 | 0 | zero | DPD check and forward >(5) | >| nonzero | 0 | 1 | zero | extended DPD check and >forward (6)| >| nonzero | 1 | 0 | zero | DPD check and forward >(5) | >| nonzero | 1 | 1 | zero | invalid, do not forward >(2) | >| nonzero | 0 | 0 | nonzero | extended DPD check and >forward (6)| >| nonzero | 0 | 1 | nonzero | extended DPD check and >forward (6)| >| nonzero | 1 | 0 | nonzero | invalid, do not forward >(3) | >| nonzero | 1 | 1 | nonzero | invalid, do not forward >(2,3) | >+---------+----+----+----------------+------------------------- >----------+ > >1: When the df flag is clear, the ip_id must be a non-zero value. >====> the question is, is a non-zero value really not allowed? >It could also be one of the 65536 values. > >2: When the df flag is checked, the mf flag must be cleared. > >3: When the df flag is checked, the fragment offset must be zero. >====> Not exactly specified in RFC791. > >4: Tagging (resequencing) the ip_id should be performed once, >on the edge >(ingress) of the MANET. As hosts could use a MANET router >MANET interface to connect, tagging on all MANET interfaces is >required. > >5: DPD algorithm uses >. > >6: Extended DPD algorithm uses >agmentOffset> >. > > > > > > > > >_______________________________________________ >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 Sat Jul 28 07:55:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEktY-0005tc-Vb; Sat, 28 Jul 2007 07:55:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IEktY-0005tW-1V for manet-confirm+ok@megatron.ietf.org; Sat, 28 Jul 2007 07:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEktX-0005tN-DK for manet@ietf.org; Sat, 28 Jul 2007 07:55:39 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEktW-0004qO-VR for manet@ietf.org; Sat, 28 Jul 2007 07:55:39 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Jul 2007 04:55:38 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADfLqkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.19,193,1183359600"; d="scan'208"; a="190235764:sNHT26627031" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6SBtcJX015406 for ; Sat, 28 Jul 2007 04:55:38 -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 l6SBtXA0017003 for ; Sat, 28 Jul 2007 11:55:38 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); Sat, 28 Jul 2007 07:55:33 -0400 Received: from [10.81.246.162] ([10.81.246.162]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Jul 2007 07:55:33 -0400 Message-ID: <46AB2EAD.7020708@cisco.com> Date: Sat, 28 Jul 2007 07:55:25 -0400 From: Bo Berry User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: manet@ietf.org X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2007 11:55:33.0218 (UTC) FILETIME=[33CD2C20:01C7D10E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=944; t=1185623738; x=1186487738; 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:=20Comments=20on=20draft-ietf-manet-packetbb-08 |Sender:=20; bh=yBZI1c13L9VwsEWVwDmjJgvaosf0UnfTW4+49bfHLY4=; b=dylcQ1i0+P5tVKFo6d3Vp2pgPPQeEsJ3chvOBftseO0RHt3pUay/FJknHK7xSoHdXBig0gNl MC48f0iueEyFsRlQn83BY6Pp/sWKS3hRYWX90akg1UC+aS1e5xvBznPL; Authentication-Results: sj-dkim-3; header.From=bberry@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [manet] Comments on 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 All: Stan and I have discussed the idea of running the MANET protocol directly over IP with a few members off-line, and now would like to bring the discussion to the entire WG. draft-ietf-manet-packetbb-08 allows the packets to be carried over any transport. It specifically calls out TCP and UDP. The draft-ietf-manet-iana-05.txt is working to define a well known UDP port and multicast groups supporting IPv4/6. >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. This approach would bring MANET into the mainstream of other routing protocols. We would like to hear the constructive thoughts of others on this topic. Does it fit within the scope and objectives of the WG? Would this strategy help standardize a MANET routing protocol? Thanks in advance, -Bo _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Jul 28 09:01: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 1IEluw-0007Fr-Fs; Sat, 28 Jul 2007 09:01:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IEOpc-0005So-1P for manet-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 08:22:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEOpb-0005Sc-LW for manet@ietf.org; Fri, 27 Jul 2007 08:22:07 -0400 Received: from web45210.mail.sp1.yahoo.com ([68.180.197.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IEOpb-0002xo-6l for manet@ietf.org; Fri, 27 Jul 2007 08:22:07 -0400 Received: (qmail 45511 invoked by uid 60001); 27 Jul 2007 11:37:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=qsklL3qaN/C7KNlVI9f9Tyq9UvySvZpmqFlsYrzeiG7QS3oYAQSJauCR3ANPO2zu3A7UOrnqCQ6S366/EHEklULm3fNH4hOgRVvejcliyrinnTbYCJv9L3ol3XS5aCz6cKewbX1kMKRo/A4L5zPUJyUhCJmP0hT8ZwhKOhZBC+g=; Received: from [210.2.171.210] by web45210.mail.sp1.yahoo.com via HTTP; Fri, 27 Jul 2007 04:37:48 PDT Date: Fri, 27 Jul 2007 04:37:48 -0700 (PDT) From: zaheer aslam To: manet@ietf.org MIME-Version: 1.0 Message-ID: <943034.44326.qm@web45210.mail.sp1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Sat, 28 Jul 2007 09:01:07 -0400 Subject: [manet] Protocol 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="===============0866779323==" Errors-To: manet-bounces@ietf.org --===============0866779323== Content-Type: multipart/alternative; boundary="0-1203071547-1185536268=:44326" Content-Transfer-Encoding: 8bit --0-1203071547-1185536268=:44326 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Greetings respected sir, I am working on ARDSR protocol. I need some help. At this time i need the code of the algo of ARDSR protocol. kindly mail me that code so that i may proceed forward in research related to DRDSR protocol. Thanx alot. Yours sincerely M Zaheer ASLAM Student of MSCS INTERNATIONAL ISLAMIC UNIVERSITY ISLAMABAD. --------------------------------- Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. --------------------------------- Shape Yahoo! in your own image. Join our Network Research Panel today! --0-1203071547-1185536268=:44326 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Greetings respected sir,
I am working on ARDSR protocol. I need some help. At this time i need the code of the algo of ARDSR protocol.
kindly mail me that code so that i may proceed forward in research related to DRDSR protocol.
 
Thanx alot.
 
Yours sincerely
M Zaheer ASLAM
Student of MSCS 
INTERNATIONAL ISLAMIC UNIVERSITY ISLAMABAD.

Park yourself in front of a world of choices in alternative vehicles.
Visit the Yahoo! Auto Green Center.

Shape Yahoo! in your own image. Join our Network Research Panel today! --0-1203071547-1185536268=:44326-- --===============0866779323== 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 --===============0866779323==-- From manet-bounces@ietf.org Sat Jul 28 09:34: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 1IEmQr-0002Z6-PL; Sat, 28 Jul 2007 09:34:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IEmQp-0002Yo-EV for manet-confirm+ok@megatron.ietf.org; Sat, 28 Jul 2007 09:34:07 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IEmQp-0002Yg-5H for manet@ietf.org; Sat, 28 Jul 2007 09:34:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEmLy-0006nR-2f for manet@ietf.org; Sat, 28 Jul 2007 09:29:06 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEmLx-0007TD-Nk for manet@ietf.org; Sat, 28 Jul 2007 09:29:06 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2559726uge for ; Sat, 28 Jul 2007 06:29: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; b=QEN5aSozNG7nHYQpiWFc/GQiymOQJpkAkHx8LG3gNZBoolyd/idvOTBavgHmVr5xHTcF4USDpL0cyvFzP0RydfArcakEee1LffTwLFv1JUxO1b6Lmo2iChD1A+6KyYYtwDg4rKRdmy+Dr/bgmIaS7M8EDsQV1mm6a9sTE1tfXwo= 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=mAt7kGlXdPzzhfL3MyOP3/8zGNWIDTUv/MpSldiSz/bn4qlQLrQT0LyfRVrpZrcOVZaITQhDAPc5pZVIQxGuBP21AmTNlOerNiuAHgCESWXNe0w2TUA8XVRxtSyqd9aWf7hoobKR/NBMn1Oansb2jAp/g+qjLDh33Dlg8GPIw6U= Received: by 10.78.37.7 with SMTP id k7mr1012980huk.1185629344765; Sat, 28 Jul 2007 06:29:04 -0700 (PDT) Received: by 10.78.141.13 with HTTP; Sat, 28 Jul 2007 06:29:04 -0700 (PDT) Message-ID: Date: Sat, 28 Jul 2007 18:29:04 +0500 From: "Usman ALI Shah" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-TMDA-Confirmed: Sat, 28 Jul 2007 09:34:07 -0400 Subject: [manet] Older OLSR Implementations 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="===============0015526029==" Errors-To: manet-bounces@ietf.org --===============0015526029== Content-Type: multipart/alternative; boundary="----=_Part_9773_14651548.1185629344743" ------=_Part_9773_14651548.1185629344743 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I was looking for an older implementation of OLSR which I used with ns-2.1b9a back in early 2004 for my graduation project. Now after a gap of some three years I am trying to re-run my project but cannot find the OLSR implementation that I used then. As a hint, it used the the class "NS_OLSRAgent" for olsr agent and some files named neighbor.hh and types.hhetc. Can you kindly guide me in finding the required (old) OLSR implementation. Thanks in advance P.S. Perhaps I am getting old ------=_Part_9773_14651548.1185629344743 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
I was looking for an older implementation of OLSR which I used with ns-2.1b9a back in early 2004 for my graduation project. Now after a gap of some three years I am trying to re-run my project but cannot find the OLSR implementation that I used then. As a hint, it used the the class "NS_OLSRAgent" for olsr agent and some files named neighbor.hh and types.hh etc.
 
Can you kindly guide me in finding the required (old) OLSR implementation.
 
Thanks in advance
 
P.S.
Perhaps I am getting old
------=_Part_9773_14651548.1185629344743-- --===============0015526029== 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 --===============0015526029==-- From manet-bounces@ietf.org Mon Jul 30 13:55: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 1IFZSS-00031U-K8; Mon, 30 Jul 2007 13:55:04 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IFZSQ-00031K-AH for manet-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 13:55:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZSO-000318-Sm for manet@ietf.org; Mon, 30 Jul 2007 13:55:01 -0400 Received: from web23315.mail.ird.yahoo.com ([217.146.189.85]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IFZSN-0004do-AX for manet@ietf.org; Mon, 30 Jul 2007 13:55:00 -0400 Received: (qmail 53948 invoked by uid 60001); 30 Jul 2007 17:54:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=E9PEQeozeo7tZ8H1O1bdIYnJbuNDw8VrODj1ehcOwrd/4W4ZcZ0tCuLxYLgk+ue9R9E2pEjn/f6oTgtaPY5tY5h+HoVaW9+zKoaQloj8wXrS38aDBTmiQmwfj2+MaHMkTa9h95XOTxXsiafdKD5K/FTw3Im68kBd693VowqfZ/8=; X-YMail-OSG: _NAUlJsVM1n.IsFFPngc1cimEp7NIhBcY0DkL9p2iVSKPWsYsVcy3w8K4uVzLvsABmJCgw87yXiVOD11jqnQR7XBVZwOjSva5ZUbDQBpz6gH9WnmMKZj2.LWyZ4- Received: from [80.156.46.53] by web23315.mail.ird.yahoo.com via HTTP; Mon, 30 Jul 2007 19:54:58 CEST Date: Mon, 30 Jul 2007 19:54:58 +0200 (CEST) From: Yann To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1026993571-1185818098=:52775" Content-Transfer-Encoding: 8bit Message-ID: <322997.52775.qm@web23315.mail.ird.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Subject: [manet] Patches for NRLSMF 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 --0-1026993571-1185818098=:52775 Content-Type: multipart/alternative; boundary="0-1960347467-1185818098=:52775" --0-1960347467-1185818098=:52775 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello all, I use nrlsmf and made some modifications/corrections I'd like to share with anyone interested. Here are 3 patches that can be applied independently since they don't affect the same files. 1/ rewriteTTL.patch This patch adds a new functionality to nrlsmf that allows to overwrite the TTL of locally-generated packets (the application I use sends TTL=1 packets since its traffic is not supposed to be forwarded normally). 2/ fragmentOffset.patch This patch fixes some issues related to flags and offset when playing with fragmented IP packets. 3/ forwardFragment.patch This patch is my little contribution to an issue which coincidently began to be discussed last week by Teco Boot. My problems was that nrlsmf only forwarded the first fragment (others were considered as duplicates). I simply added the offset in the key for DPD and now all fragments are forwared. I'm very aware that it is only a quick and ugly solution but I don't need more for now. Also, I'd like to mention that these patches are incomplete since I didn't take into consideration IPv6 and IPSec. However, they should work well for IPv4. I hope they'll be appreciated, Have a nice day, Yann --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail --0-1960347467-1185818098=:52775 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello all,

I use nrlsmf and made some modifications/corrections I'd like to share with anyone interested.
Here are 3 patches that can be applied independently since they don't affect the same files.

1/ rewriteTTL.patch
This patch adds a new functionality to nrlsmf that allows to overwrite the TTL of locally-generated packets (the application I use sends TTL=1 packets since its traffic is not supposed to be forwarded normally).

2/ fragmentOffset.patch
This patch fixes some issues related to flags and offset when playing with fragmented IP packets.

3/ forwardFragment.patch
This patch is my little contribution to an issue which coincidently began to be discussed last week by Teco Boot. My problems was that nrlsmf only forwarded the first fragment (others were considered as duplicates). I simply added the offset in the key for DPD and now all fragments are forwared.
I'm very aware that it is only a quick and ugly solution but I don't need more for now.

Also, I'd like to mention that these patches are incomplete since I didn't take into consideration IPv6 and IPSec. However, they should work well for IPv4.

I hope they'll be appreciated,

Have a nice day,
Yann


Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail --0-1960347467-1185818098=:52775-- --0-1026993571-1185818098=:52775 Content-Type: application/octet-stream; name="rewriteTTL.patch" Content-Transfer-Encoding: base64 Content-Description: 1228020654-rewriteTTL.patch Content-Disposition: attachment; filename="rewriteTTL.patch" LS0tIDAtb3JpZy1uaWdobHktMjAwNzA3MzAvY29tbW9uL25ybHNtZi5jcHAJ MjAwNy0wNi0xMSAxNzo0Mjo0OC4wMDAwMDAwMDAgKzAwMDAKKysrIDEtcmV3 cml0ZVRUTC9jb21tb24vbnJsc21mLmNwcAkyMDA3LTA2LTEzIDE0OjQ1OjE3 LjAwMDAwMDAwMCArMDAwMApAQCAtNjcsNiArNjcsNyBAQAogICAgICAgICBi b29sICAgICAgICAgICAgcHJpb3JpdHlfYm9vc3Q7CiAgICAgICAgIGJvb2wg ICAgICAgICAgICBpcHY2X2VuYWJsZWQ7CiAgICAgICAgIGJvb2wgICAgICAg ICAgICByZXNlcXVlbmNlOworICAgICAgICB1X2NoYXIgICAgICAgICAgcmV3 cml0ZVRUTDsKICAgICAgICAgYm9vbCAgICAgICAgICAgIGZpcmV3YWxsX2Nh cHR1cmU7CiAgICAgICAgIGJvb2wgICAgICAgICAgICBmaXJld2FsbF9mb3J3 YXJkOwogICAgICAgICAKQEAgLTExMyw3ICsxMTQsNyBAQAogICAgICAgICAK IFNtZkFwcDo6U21mQXBwKCkKICA6IHNtZihHZXRUaW1lck1ncigpKSwgcnRf bWdyKE5VTEwpLCBwcmlvcml0eV9ib29zdCh0cnVlKSwKLSAgIGlwdjZfZW5h YmxlZChmYWxzZSksIHJlc2VxdWVuY2UoZmFsc2UpLAorICAgaXB2Nl9lbmFi bGVkKGZhbHNlKSwgcmVzZXF1ZW5jZShmYWxzZSksIHJld3JpdGVUVEwoMCks CiAgICBmaXJld2FsbF9jYXB0dXJlKGZhbHNlKSwKICNpZmRlZiBfUFJPVE9f REVUT1VSCiAgICBkZXRvdXJfaXB2NChOVUxMKSwgZGV0b3VyX2lwdjRfZmxh Z3MoMCksCkBAIC0xNDYsNiArMTQ3LDcgQEAKICAgICAgICAgICAgICAgICAg ICAgIiAgICAgICAgICAgW2ZvcndhcmQge29ufG9mZn1dW3JlbGF5IHtvbnxv ZmZ9XVxuIgogICAgICAgICAgICAgICAgICAgICAiICAgICAgICAgICBbaW5z dGFuY2UgPGluc3RhbmNlTmFtZT5dW3NtZlNlcnZlciA8c2VydmVyTmFtZT5d XG4iCiAgICAgICAgICAgICAgICAgICAgICIgICAgICAgICAgIFtyZXNlcXVl bmNlIHtvbnxvZmZ9XVtib29zdCB7b258b2ZmfV1cbiIKKyAgICAgICAgICAg ICAgICAgICAgIiAgICAgICAgICAgW3Jld3JpdGVUVEwgPG5ld1RUTD5dXG4i CiAgICAgICAgICAgICAgICAgICAgICIgICAgICAgICAgIFtkZWJ1ZyA8ZGVi dWdMZXZlbD5dW2xvZyA8ZGVidWdMb2dGaWxlPl1cblxuIgogICAgICAgICAg ICAgICAgICAgICAiICAgKE5vdGUgXCJmaXJld2FsbFwiIG9wdGlvbnMgbXVz dCBiZSBzcGVjaWZpZWQgX2JlZm9yZV8gaWZhY2UgY29uZmlnIGNvbW1hbmRz IVxuIik7CiB9CkBAIC0xNjcsNiArMTY5LDcgQEAKICAgICAiK3JlbGF5Iiwg ICAgICAgLy8ge29uIHwgb2ZmfSAgOiBhY3QgYXMgcmVsYXkgbm9kZSAoZGVm YXVsdCA9ICJvbiIpCiAJIitkZWZhdWx0Rm9yd2FyZCIsIC8vIHtvbiB8IG9m Zn0gIDogc2FtZSBhcyAicmVsYXkiCiAgICAgIityZXNlcXVlbmNlIiwgIC8v IHtvbiB8IG9mZn0gIDogcmVzZXF1ZW5jZSBvdXRib3VuZCBtdWx0aWNhc3Qg cGFja2V0cyAgIAorICAgICIrcmV3cml0ZVRUTCIsICAvLyA8bmV3VFRMPiAg OiBvdmVyd3JpdGUgdGhlIFRUTCBvZiBvdXRib3VuZCBtdWx0aWNhc3QgcGFj a2V0cwogICAgIC8vIitmaXJld2FsbCIsICAgIC8vIHtvbiB8IG9mZn0gOiB1 c2UgZmlyZXdhbGwgaW5zdGVhZCBvZiBQcm90b0NhcCB0byBjYXB0dXJlICYg Zm9yd2FyZCBwYWNrZXRzICAKICAgICAiK2ZpcmV3YWxsQ2FwdHVyZSIsIC8v IHtvbiB8IG9mZn0gOiB1c2UgZmlyZXdhbGwgaW5zdGVhZCBvZiBQcm90b0Nh cCB0byBjYXB0dXJlIHBhY2tldHMgCiAgICAgIitmaXJld2FsbEZvcndhcmQi LCAvLyB7b24gfCBvZmZ9IDogdXNlIGZpcmV3YWxsIGluc3RlYWQgb2YgUHJv dG9DYXAgdG8gZm9yd2FyZCBwYWNrZXRzCkBAIC02MTAsNiArNjEzLDEwIEBA CiAgICAgICAgICAgICByZXR1cm4gZmFsc2U7CiAgICAgICAgIH0KICAgICB9 ICAKKyAgICBlbHNlIGlmICghc3RybmNtcCgicmV3cml0ZVRUTCIsIGNtZCwg bGVuKSkKKyAgICB7CisgICAgICAgIHJld3JpdGVUVEwgPSBhdG9pKHZhbCk7 CisgICAgfQogICAgIGVsc2UgaWYgKCFzdHJuY21wKCJmaXJld2FsbENhcHR1 cmUiLCBjbWQsIGxlbikpCiAgICAgewogICAgICAgICAvLyAoVEJEKSAicmVt YXAgY2FwIiB3aGVuIHRoaXMgaXMgdG9nZ2xlZCAobmVlZCB0byBtYWtlIHN1 cmUgaW5wdXQgbm90aWZ5IGlzIGRvbmUpCkBAIC0xMzUxLDExICsxMzU4LDEz IEBACiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICBj YXNlIFByb3RvRGV0b3VyOjpPVVRCT1VORDoKICAgICAgICAgICAgICAgICAg ICAgeworLyoKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICghcmVzZXF1 ZW5jZSkgCiAgICAgICAgICAgICAgICAgICAgICAgICB7CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgRE1TRygwLCAiU21mQXBwOjpPblBrdEludGVy Y2VwdCgpIHdhcm5pbmc6IGludGVyY2VwdGVkIE9VVEJPVU5EIHBhY2tldCwg YnV0IHJlc2VxdWVuY2UgZGlzYWJsZWQ/IVxuIik7CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgICAgICAgICAgICAgICAg ICB9CisqLwogICAgICAgICAgICAgICAgICAgICAgICAgLy8gRm9yIE9VVEJP VU5EIHBhY2tldHMsIG1vZGlmeSBJRCBmaWVsZCAoSVB2NCkKICAgICAgICAg ICAgICAgICAgICAgICAgIC8vIG9yIGFkZCBEUEQgb3B0aW9uIChJUHY2KSBm b3IgCiAgICAgICAgICAgICAgICAgICAgICAgICAvLyBsb2NhbGx5LWdlbmVy YXRlZCwgZ2xvYmFsbHktc2NvcGVkCkBAIC0xMzkxLDggKzE0MDAsMTkgQEAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRE1TRyg4LCAiU21m QXBwOjpPblBrdEludGVyY2VwdCgpIHNraXBwaW5nIG5vbi1sb2NhbGx5LWdl bmVyYXRlZCBJUHY0IHBrdFxuIik7CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGJyZWFrOwogICAgICAgICAgICAgICAgICAgICAgICAgICAg IH0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZiAoMCA8IHJld3Jp dGVUVEwpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgeworICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBpcDRQa3QuU2V0VFRMKHJld3Jp dGVUVEwsIHRydWUpOworICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvLyBSZXNlcXVlbmNlIElE IGZpZWxkIHVzaW5nICJsb2NhbCIgc2VxdWVuY2UgcwotICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGlwNFBrdC5TZXRJRChzbWYuSW5jcmVtZW50SVB2 NExvY2FsU2VxdWVuY2UoJmRzdEFkZHIpLCB0cnVlKTsgIAorICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGlmIChyZXNlcXVlbmNlKSAKKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGlwNFBrdC5TZXRJRChzbWYuSW5jcmVtZW50SVB2NExvY2Fs U2VxdWVuY2UoJmRzdEFkZHIpLCB0cnVlKTsKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgZWxz ZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRE1TRygwLCAiU21mQXBwOjpPblBrdElu dGVyY2VwdCgpIHdhcm5pbmc6IGludGVyY2VwdGVkIE9VVEJPVU5EIHBhY2tl dCwgYnV0IHJlc2VxdWVuY2UgZGlzYWJsZWQ/IVxuIik7CisgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAgICAg fQogICAgICAgICAgICAgICAgICAgICAgICAgZWxzZSBpZiAoNiA9PSB2ZXJz aW9uKQogICAgICAgICAgICAgICAgICAgICAgICAgewo= --0-1026993571-1185818098=:52775 Content-Type: application/octet-stream; name="fragmentOffset.patch" Content-Transfer-Encoding: base64 Content-Description: 2509446437-fragmentOffset.patch Content-Disposition: attachment; filename="fragmentOffset.patch" LS0tIDEtcmV3cml0ZVRUTC9wcm90b2xpYi9jb21tb24vcHJvdG9Qa3RJUC5j cHAJMjAwNy0wMy0xOSAyMzoyNDoyMS4wMDAwMDAwMDAgKzAwMDAKKysrIDIt c2VuZEZyYWcvcHJvdG9saWIvY29tbW9uL3Byb3RvUGt0SVAuY3BwCTIwMDct MDctMzAgMTM6NDY6MTAuMDAwMDAwMDAwICswMDAwCkBAIC0xMzcsMTEgKzEz NywxMSBAQAogCiB2b2lkIFByb3RvUGt0SVB2NDo6U2V0RnJhZ21lbnRPZmZz ZXQoVUlOVDE2IGZyYWdtZW50T2Zmc2V0LCBib29sIHVwZGF0ZUNoZWNrc3Vt KSAgCiB7Ci0gICAgVUlOVDE2IGZyYWdPbGQgPSBudG9ocygoKFVJTlQxNiop YnVmZmVyX3B0cilbT0ZGU0VUX0ZSQUdNRU5UXSk7Ci0gICAgVUlOVDE2IGZy YWdOZXcgPSBmcmFnT2xkICYgMHhlMDAwOwotICAgIGZyYWdOZXcgfD0gKGZy YWdtZW50T2Zmc2V0ICYgMHgxZmZmKTsKKyAgICBVSU5UMTYgZnJhZ09sZCA9 ICgoVUlOVDE2KilidWZmZXJfcHRyKVtPRkZTRVRfRlJBR01FTlRdOworICAg IFVJTlQxNiBmcmFnTmV3ID0gZnJhZ09sZCAmIGh0b25zKDB4ZTAwMCk7Cisg ICAgZnJhZ05ldyB8PSBodG9ucyhmcmFnbWVudE9mZnNldC84ICYgMHgxZmZm KTsKICAgICBpZiAodXBkYXRlQ2hlY2tzdW0pIFVwZGF0ZUNoZWNrc3VtKGZy YWdPbGQsIGZyYWdOZXcpOwotICAgICgoVUlOVDE2KilidWZmZXJfcHRyKVtP RkZTRVRfRlJBR01FTlRdID0gaHRvbnMoZnJhZ05ldyk7CisgICAgKChVSU5U MTYqKWJ1ZmZlcl9wdHIpW09GRlNFVF9GUkFHTUVOVF0gPSBmcmFnTmV3Owog fSAvLyBlbmQgUHJvdG9Qa3RJUHY0OjpTZXRGcmFnbWVudE9mZnNldCgpCiAK IAotLS0gMS1yZXdyaXRlVFRML3Byb3RvbGliL2NvbW1vbi9wcm90b1BrdElQ LmgJMjAwNy0wMy0xOSAyMzoyNDoyMS4wMDAwMDAwMDAgKzAwMDAKKysrIDIt c2VuZEZyYWcvcHJvdG9saWIvY29tbW9uL3Byb3RvUGt0SVAuaAkyMDA3LTA3 LTMwIDEzOjQ2OjAwLjAwMDAwMDAwMCArMDAwMApAQCAtMTAwLDkgKzEwMCw5 IEBACiAgICAgICAgIAogICAgICAgICBlbnVtIEZsYWcKICAgICAgICAgewot ICAgICAgICAgICAgRkxBR19SRVNFUlZFRCA9IDB4NDAsICAvLyByZXNlcnZl ZCBiaXQKLSAgICAgICAgICAgIEZMQUdfREYgICAgICAgPSAweDIwLCAgLy8g MCA9IG1heSBmcmFnbWVudCwgIDEgPSBkb24ndCBmcmFnbWVudCAKLSAgICAg ICAgICAgIEZMQUdfTUYgICAgICAgPSAweDEwICAgLy8gMCA9IGxhc3QgZnJh Z21lbnQsIDEgPSBtb3JlIGZyYWdtZW50cworICAgICAgICAgICAgRkxBR19S RVNFUlZFRCA9IDB4ODAsICAvLyByZXNlcnZlZCBiaXQKKyAgICAgICAgICAg IEZMQUdfREYgICAgICAgPSAweDQwLCAgLy8gMCA9IG1heSBmcmFnbWVudCwg IDEgPSBkb24ndCBmcmFnbWVudCAKKyAgICAgICAgICAgIEZMQUdfTUYgICAg ICAgPSAweDIwICAgLy8gMCA9IGxhc3QgZnJhZ21lbnQsIDEgPSBtb3JlIGZy YWdtZW50cwogICAgICAgICB9OwogICAgICAgICAKICAgICAgICAgLy8gVXNl IHRoZXNlIHRvIHBhcnNlIGEgcGFja2V0CkBAIC0xMjEsNyArMTIxLDcgQEAK ICAgICAgICAgYm9vbCBGbGFnSXNTZXQoRmxhZyBmbGFnKSBjb25zdAogICAg ICAgICAgICAge3JldHVybiAoMCAhPSAoZmxhZyAmICgoKFVJTlQ4KilidWZm ZXJfcHRyKVtPRkZTRVRfRkxBR1NdKSkpO30KICAgICAgICAgVUlOVDE2IEdl dEZyYWdtZW50T2Zmc2V0KCkgY29uc3QKLSAgICAgICAgICAgIHtyZXR1cm4g KDB4MWZmZiAmICgoVUlOVDE2KilidWZmZXJfcHRyKVtPRkZTRVRfRlJBR01F TlRdKTt9CisgICAgICAgICAgICB7cmV0dXJuIDgqKDB4MWZmZiAmIG50b2hz KCgoVUlOVDE2KilidWZmZXJfcHRyKVtPRkZTRVRfRlJBR01FTlRdKSk7fQog ICAgICAgICBVSU5UOCBHZXRUVEwoKSBjb25zdAogICAgICAgICAgICAge3Jl dHVybiAoKChVSU5UOCopYnVmZmVyX3B0cilbT0ZGU0VUX1RUTF0pO30KICAg ICAgICAgUHJvdG9jb2wgR2V0UHJvdG9jb2woKSBjb25zdAo= --0-1026993571-1185818098=:52775 Content-Type: application/octet-stream; name="forwardFragment.patch" Content-Transfer-Encoding: base64 Content-Description: 3514344559-forwardFragment.patch Content-Disposition: attachment; filename="forwardFragment.patch" LS0tIDAtb3JpZy1uaWdobHktMjAwNzA3MzAvY29tbW9uL3NtZi5jcHAJMjAw Ny0wMy0xOSAyMzoyMTo1Ny4wMDAwMDAwMDAgKzAwMDAKKysrIDMtZnJhZ21l bnREZXRlY3Rpb24vY29tbW9uL3NtZi5jcHAJMjAwNy0wNy0zMCAxNzoxMTox OC4wMDAwMDAwMDAgKzAwMDAKQEAgLTY3LDkgKzY3LDEwIEBACiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBQcm90b0FkZHJl c3MqIHNyY0FkZHIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBjb25zdCBQcm90b0FkZHJlc3MqIGRzdEFkZHIsCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBVSU5UMzIgICAgICAgICAgICAg IHBrdElkLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dW5zaWduZWQgaW50ICAgICAgICBwa3RJZFNpemUpICAgICAgLy8gaW4gYml0 cyAKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2ln bmVkIGludCAgICAgICAgcGt0SWRTaXplLCAgICAgLy8gaW4gYml0cyAKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFVJTlQxNiAgICAg ICAgICAgICAgZnJhZ21lbnRPZmZzZXQpCiB7Ci0gICAgY2hhciBrZXlbNDhd OyAgLy8gSVB2NiB0YWdnZXJJZDpzcmM6ZHN0IHdvcnN0IGNhc2UKKyAgICBj aGFyIGtleVs1MF07ICAvLyBJUHY2IHRhZ2dlcklkOnNyYzpkc3Q6b2Zmc2V0 IHdvcnN0IGNhc2UKICAgICB1bnNpZ25lZCBpbnQga2V5Qnl0ZXMgPSAwOwog ICAgIGlmIChOVUxMICE9IHRhZ2dlcklkKQogICAgIHsKQEAgLTg3LDYgKzg4 LDkgQEAKICAgICAgICAgbWVtY3B5KGtleStrZXlCeXRlcywgZHN0QWRkci0+ R2V0UmF3SG9zdEFkZHJlc3MoKSwgZHN0TGVuKTsKICAgICAgICAga2V5Qnl0 ZXMgKz0gZHN0TGVuOwogICAgIH0KKyAgICBmcmFnbWVudE9mZnNldCA9IGh0 b25zKGZyYWdtZW50T2Zmc2V0KTsKKyAgICBtZW1jcHkoa2V5K2tleUJ5dGVz LCAmZnJhZ21lbnRPZmZzZXQsIDIpOworICAgIGtleUJ5dGVzICs9IDI7CiAg ICAgcmV0dXJuIChkdXBsaWNhdGVfdHJlZS5Jc0R1cGxpY2F0ZShjdXJyZW50 VGltZSwgcGt0SWQsIHBrdElkU2l6ZSwga2V5LCBrZXlCeXRlcyA8PCAzKSk7 CiB9ICAvLyBlbmQgU21mOjpJbnRlcmZhY2U6OklzRHVwbGljYXRlUGt0KCkK IApAQCAtNDgzLDYgKzQ4Nyw4IEBACiAgICAgdW5zaWduZWQgaW50IHBrdElk U2l6ZTsgIC8vIGluIGJpdHMKICAgICBVSU5UOCB0dGw7CiAgICAgYm9vbCBp c0lQU2VjUGt0ID0gZmFsc2U7CisgICAgVUlOVDE2IGZyYWdtZW50T2Zmc2V0 ID0gMDsKKyAgICAKICAgICBzd2l0Y2ggKHZlcnNpb24pCiAgICAgewogICAg ICAgICBjYXNlIDQ6CkBAIC01NjksNiArNTc1LDcgQEAKICAgICAgICAgICAg IH0KICAgICAgICAgICAgIHR0bCA9IGlwdjRQa3QuR2V0VFRMKCk7CiAgICAg ICAgICAgICBpZiAodHRsID4gMSkgaXB2NFBrdC5EZWNyZW1lbnRUVEwoKTsK KyAgICAgICAgICAgIGZyYWdtZW50T2Zmc2V0ID0gaXB2NFBrdC5HZXRGcmFn bWVudE9mZnNldCgpOwogICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgIH0K ICAgICAgICAgY2FzZSA2OgpAQCAtNjI5LDYgKzYzNiw3IEBACiAgICAgICAg ICAgICB9ICAgICAgIAogICAgICAgICAgICAgdHRsID0gaXB2NlBrdC5HZXRI b3BMaW1pdCgpOwogICAgICAgICAgICAgaWYgKHR0bCA+IDEpIGlwdjZQa3Qu U2V0SG9wTGltaXQodHRsIC0gMSk7CisgICAgICAgICAgICBmcmFnbWVudE9m ZnNldCA9IDA7CiAgICAgICAgICAgICBicmVhazsKICAgICAgICAgfQogICAg ICAgICBkZWZhdWx0OgpAQCAtNjQ0LDcgKzY1Miw3IEBACiAgICAgLy8gYXJy aXZlZCAoZHVlIHRvIGhlYXJpbmcgYSBNQU5FVCBuZWlnaGJvciBmb3J3YXJk aW5nIHRoaXMgcGFja2V0KQogICAgIGlmIChzcmNJZmFjZS0+R2V0UmVzZXF1 ZW5jZSgpKQogICAgIHsKLSAgICAgICAgc3JjSWZhY2UtPklzRHVwbGljYXRl UGt0KGN1cnJlbnRfdXBkYXRlX3RpbWUsIE5VTEwsIDAsICZzcmNJcCwgJmRz dElwLCBwa3RJZCwgcGt0SWRTaXplKTsKKyAgICAgICAgc3JjSWZhY2UtPklz RHVwbGljYXRlUGt0KGN1cnJlbnRfdXBkYXRlX3RpbWUsIE5VTEwsIDAsICZz cmNJcCwgJmRzdElwLCBwa3RJZCwgcGt0SWRTaXplLCBmcmFnbWVudE9mZnNl dCk7CiAgICAgfQogICAgIAogICAgIC8vIEl0ZXJhdGUgdGhyb3VnaCBwb3Rl bnRpYWwgb3V0Ym91bmQgaW50ZXJmYWNlcyAoImFzc29jaWF0ZSIgaW50ZXJm YWNlcykKQEAgLTcwNSw3ICs3MTMsNyBAQAogICAgICAgICAgICAgaWYgKGlz SVBTZWNQa3QpCiAgICAgICAgICAgICAgICAgaXNEdXBsaWNhdGUgPSBkc3RJ ZmFjZS5Jc0R1cGxpY2F0ZUlQU2VjUGt0KGN1cnJlbnRfdXBkYXRlX3RpbWUs IHNyY0lwLCBkc3RJcCwgcGt0U1BJLCBwa3RJZCk7CiAgICAgICAgICAgICBl bHNlICAKLSAgICAgICAgICAgICAgICBpc0R1cGxpY2F0ZSA9IGRzdElmYWNl LklzRHVwbGljYXRlUGt0KGN1cnJlbnRfdXBkYXRlX3RpbWUsIHRhZ2dlcklk LCB0YWdnZXJJZExlbmd0aCwgJnNyY0lwLCAmZHN0SXAsIHBrdElkLCBwa3RJ ZFNpemUpOworICAgICAgICAgICAgICAgIGlzRHVwbGljYXRlID0gZHN0SWZh Y2UuSXNEdXBsaWNhdGVQa3QoY3VycmVudF91cGRhdGVfdGltZSwgdGFnZ2Vy SWQsIHRhZ2dlcklkTGVuZ3RoLCAmc3JjSXAsICZkc3RJcCwgcGt0SWQsIHBr dElkU2l6ZSwgZnJhZ21lbnRPZmZzZXQpOwogICAgICAgICAgICAgaWYgKGlz RHVwbGljYXRlKQogICAgICAgICAgICAgewogICAgICAgICAgICAgICAgIERN U0coNiwgIm5ybHNtZjogcmVjZWl2ZWQgZHVwbGljYXRlIElQdiVkIHBhY2tl dCAuLi5cbiIsIHZlcnNpb24pOwotLS0gMC1vcmlnLW5pZ2hseS0yMDA3MDcz MC9jb21tb24vc21mLmgJMjAwNy0wNS0xNSAyMTo0NTo1MC4wMDAwMDAwMDAg KzAwMDAKKysrIDMtZnJhZ21lbnREZXRlY3Rpb24vY29tbW9uL3NtZi5oCTIw MDctMDctMzAgMTY6MTI6MjEuMDAwMDAwMDAwICswMDAwCkBAIC04MCw3ICs4 MCw4IEBACiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj b25zdCBQcm90b0FkZHJlc3MqIHNyY0FkZHIsCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjb25zdCBQcm90b0FkZHJlc3MqIGRzdEFk ZHIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBVSU5U MzIgICAgICAgICAgICAgIHBrdElELAotICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdW5zaWduZWQgaW50ICAgICAgICBwa3RJRFNpemUp OyAgICAgLy8gaW4gYml0cyAKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHVuc2lnbmVkIGludCAgICAgICAgcGt0SURTaXplLCAgICAg IC8vIGluIGJpdHMgCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBVSU5UMTYgICAgICAgICAgICAgIGZyYWdtZW50T2Zmc2V0KTsKICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICBib29sIElzRHVwbGlj YXRlSVBTZWNQa3QodW5zaWduZWQgaW50ICAgICAgICBjdXJyZW50VGltZSwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29u c3QgUHJvdG9BZGRyZXNzJiBzcmNBZGRyLAo= --0-1026993571-1185818098=:52775 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 --0-1026993571-1185818098=:52775-- From manet-bounces@ietf.org Mon Jul 30 21:00: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 1IFg5p-0007Ns-Vx; Mon, 30 Jul 2007 21:00:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IFg5n-0007NN-SB for manet-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 21:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFg5n-0007NF-IO for manet@ietf.org; Mon, 30 Jul 2007 21:00:07 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFg5m-0007pl-VX for manet@ietf.org; Mon, 30 Jul 2007 21:00:07 -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 l6V0xoCx014900; Mon, 30 Jul 2007 21:00:01 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007073021000113271 ; Mon, 30 Jul 2007 21:00:01 -0400 From: "Joe Macker" To: "'Joe Macker'" , "'Teco_Boot'" , References: <001401c7cf80$86552900$74d26143@Teco> <002901c7cfd7$a4e3a890$165cfa84@SEXTANT> Subject: RE: [manet] SMF: DPD for IPv4 Date: Mon, 30 Jul 2007 20:59:58 -0400 Message-ID: <000101c7d30e$1de68d00$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfPgITSUgDfMHh4SBOfMcBGH64FMwAVc+JQAM1kQ4A= In-Reply-To: <002901c7cfd7$a4e3a890$165cfa84@SEXTANT> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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 have been personally convinced through discussions that fixing unexpected ID field behavior, even in the limited non-IPSEC DF always zero case, is poor practice in general. If kernels handle ID properly SMF should be able to do passive IPv4 DPD reasonably well. We should not expect incremental increases either and that text will be changed. I am also tempted to add an alternative IPv4 hashing DPD method similar to the IPv6 approach. -Joe >-----Original Message----- >From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] >Sent: Thursday, July 26, 2007 6:52 PM >To: 'Teco_Boot'; manet@ietf.org >Subject: RE: [manet] SMF: DPD for IPv4 > >Teco: > >These are some good notes. I believe we can consider adding >the fragmentation support as you outlined and will begin >discussing this with other contributors. > >I believe the DF set (ID=0) rewriting case does not break >anything and is not used for IPSEC or fragmentation, but I >will continue to discuss this with others. We know we have >embedded kernels with this characteristic as part of early deployments. > >Thank you, >Joe > > >>-----Original Message----- >>From: Teco_Boot [mailto:teco@inf-net.nl] >>Sent: Thursday, July 26, 2007 8:29 AM >>To: manet@ietf.org >>Subject: [manet] SMF: DPD for IPv4 >> >>Hi, >> >>After reading back the SMF doc on IPv4 DPD, I think the text needs to >>be more accurate what the exact DPD algorithm is. >> >>I think the algorithm specification should be provided for all >>combinations of ip_id, df flag, mf flag and fragment offset. >>Below a draft specification. >> >>I also think we should try to be 100% compliant with RFC791. >>The consequence is that the protocol field is part of the checked >>tuple, so it will become >> >>I also think we should write a recommendation on usage of the ip_id >>field. >>It would specify the need for using a sequenced value, including >>packets marked for df. It would be a very short document, updating >>RFC791. >>A big issue is the value zero. Is this value prohibited or not? >> >>In the draft specification below, I included extended DPD, supporting >>fragmentation. >> >>Tagging (rewriting the ip_id) is a concern, mentioned by Fred >Templin. >>We could discuss using encapsulation. If we go for fixing >ip_id usage, >>tagging is a migration tool and is not used for nice behaving senders. >> >>Teco. >> >> >> >>+---------+----+----+----------------+------------------------- >>----------+ >>| ip_id | df | mf | fragment offset| action >> | >>+---------+----+----+----------------+------------------------- >>----------+ >>| zero | 0 | 0 | zero | invalid, do not forward >>(1) | >>| zero | 0 | 1 | zero | invalid, do not forward >>(1) | >>| zero | 1 | 0 | zero | tag and forward (4) >> | >>| zero | 1 | 1 | zero | invalid, do not forward >>(2) | >>| zero | 0 | 0 | nonzero | invalid, do not forward >>(1) | >>| zero | 0 | 1 | nonzero | invalid, do not forward >>(1) | >>| zero | 1 | 0 | nonzero | invalid, do not forward >>(3) | >>| zero | 1 | 1 | nonzero | invalid, do not forward >>(2,3) | >>| nonzero | 0 | 0 | zero | DPD check and forward >>(5) | >>| nonzero | 0 | 1 | zero | extended DPD check and >>forward (6)| >>| nonzero | 1 | 0 | zero | DPD check and forward >>(5) | >>| nonzero | 1 | 1 | zero | invalid, do not forward >>(2) | >>| nonzero | 0 | 0 | nonzero | extended DPD check and >>forward (6)| >>| nonzero | 0 | 1 | nonzero | extended DPD check and >>forward (6)| >>| nonzero | 1 | 0 | nonzero | invalid, do not forward >>(3) | >>| nonzero | 1 | 1 | nonzero | invalid, do not forward >>(2,3) | >>+---------+----+----+----------------+------------------------- >>----------+ >> >>1: When the df flag is clear, the ip_id must be a non-zero value. >>====> the question is, is a non-zero value really not allowed? >>It could also be one of the 65536 values. >> >>2: When the df flag is checked, the mf flag must be cleared. >> >>3: When the df flag is checked, the fragment offset must be zero. >>====> Not exactly specified in RFC791. >> >>4: Tagging (resequencing) the ip_id should be performed once, on the >>edge >>(ingress) of the MANET. As hosts could use a MANET router MANET >>interface to connect, tagging on all MANET interfaces is required. >> >>5: DPD algorithm uses >>. >> >>6: Extended DPD algorithm uses >>>agmentOffset> >>. >> >> >> >> >> >> >> >> >>_______________________________________________ >>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 Jul 30 21:08: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 1IFgDW-0003lS-RM; Mon, 30 Jul 2007 21:08:06 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IFgDU-0003l8-6k for manet-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 21:08:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFgDT-0003ko-Nv for manet@ietf.org; Mon, 30 Jul 2007 21:08:03 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFgDS-0000DM-RA for manet@ietf.org; Mon, 30 Jul 2007 21:08:03 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6V17kCv026827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Jul 2007 18:08:01 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6V17kYF023233; Mon, 30 Jul 2007 20:07:46 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6V17jnE023195; Mon, 30 Jul 2007 20:07:46 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 18:07:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] SMF: DPD for IPv4 Date: Mon, 30 Jul 2007 18:07:45 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED972@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <000101c7d30e$1de68d00$165cfa84@SEXTANT> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] SMF: DPD for IPv4 Thread-Index: AcfPgITSUgDfMHh4SBOfMcBGH64FMwAVc+JQAM1kQ4AAAMOCMA== References: <001401c7cf80$86552900$74d26143@Teco><002901c7cfd7$a4e3a890$165cfa84@SEXTANT> <000101c7d30e$1de68d00$165cfa84@SEXTANT> From: "Templin, Fred L" To: "Joe Macker" , "Teco_Boot" , X-OriginalArrivalTime: 31 Jul 2007 01:07:45.0603 (UTC) FILETIME=[34230930:01C7D30F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc 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 Suits me. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil]=20 > Sent: Monday, July 30, 2007 6:00 PM > To: 'Joe Macker'; 'Teco_Boot'; manet@ietf.org > Subject: RE: [manet] SMF: DPD for IPv4=20 >=20 > I have been personally convinced through discussions that=20 > fixing unexpected > ID field behavior, even in the limited non-IPSEC DF always=20 > zero case, is > poor practice in general. If kernels handle ID properly SMF=20 > should be able > to do passive IPv4 DPD reasonably well. We should not expect=20 > incremental > increases either and that text will be changed. I am also=20 > tempted to add an > alternative IPv4 hashing DPD method similar to the IPv6 approach. >=20 > -Joe >=20 > >-----Original Message----- > >From: Joe Macker [mailto:joseph.macker@nrl.navy.mil]=20 > >Sent: Thursday, July 26, 2007 6:52 PM > >To: 'Teco_Boot'; manet@ietf.org > >Subject: RE: [manet] SMF: DPD for IPv4=20 > > > >Teco: > > > >These are some good notes. I believe we can consider adding=20 > >the fragmentation support as you outlined and will begin=20 > >discussing this with other contributors. > > > >I believe the DF set (ID=3D0) rewriting case does not break=20 > >anything and is not used for IPSEC or fragmentation, but I=20 > >will continue to discuss this with others. We know we have=20 > >embedded kernels with this characteristic as part of early=20 > deployments. > > > >Thank you, > >Joe > > > > > >>-----Original Message----- > >>From: Teco_Boot [mailto:teco@inf-net.nl] > >>Sent: Thursday, July 26, 2007 8:29 AM > >>To: manet@ietf.org > >>Subject: [manet] SMF: DPD for IPv4 > >> > >>Hi, > >> > >>After reading back the SMF doc on IPv4 DPD, I think the=20 > text needs to=20 > >>be more accurate what the exact DPD algorithm is. > >> > >>I think the algorithm specification should be provided for all=20 > >>combinations of ip_id, df flag, mf flag and fragment offset. > >>Below a draft specification. > >> > >>I also think we should try to be 100% compliant with RFC791.=20 > >>The consequence is that the protocol field is part of the checked=20 > >>tuple, so it will become=20 > > >> > >>I also think we should write a recommendation on usage of the ip_id=20 > >>field. > >>It would specify the need for using a sequenced value, including=20 > >>packets marked for df. It would be a very short document, updating=20 > >>RFC791. > >>A big issue is the value zero. Is this value prohibited or not? > >> > >>In the draft specification below, I included extended DPD,=20 > supporting=20 > >>fragmentation. > >> > >>Tagging (rewriting the ip_id) is a concern, mentioned by Fred=20 > >Templin.=20 > >>We could discuss using encapsulation. If we go for fixing=20 > >ip_id usage,=20 > >>tagging is a migration tool and is not used for nice=20 > behaving senders. > >> > >>Teco. > >> > >> > >> > >>+---------+----+----+----------------+------------------------- > >>----------+ > >>| ip_id | df | mf | fragment offset| action =20 > >> | > >>+---------+----+----+----------------+------------------------- > >>----------+ > >>| zero | 0 | 0 | zero | invalid, do not forward=20 > >>(1) | > >>| zero | 0 | 1 | zero | invalid, do not forward=20 > >>(1) | > >>| zero | 1 | 0 | zero | tag and forward (4) =20 > >> | > >>| zero | 1 | 1 | zero | invalid, do not forward=20 > >>(2) | > >>| zero | 0 | 0 | nonzero | invalid, do not forward=20 > >>(1) | > >>| zero | 0 | 1 | nonzero | invalid, do not forward=20 > >>(1) | > >>| zero | 1 | 0 | nonzero | invalid, do not forward=20 > >>(3) | > >>| zero | 1 | 1 | nonzero | invalid, do not forward=20 > >>(2,3) | > >>| nonzero | 0 | 0 | zero | DPD check and forward=20 > >>(5) | > >>| nonzero | 0 | 1 | zero | extended DPD check and=20 > >>forward (6)| > >>| nonzero | 1 | 0 | zero | DPD check and forward=20 > >>(5) | > >>| nonzero | 1 | 1 | zero | invalid, do not forward=20 > >>(2) | > >>| nonzero | 0 | 0 | nonzero | extended DPD check and=20 > >>forward (6)| > >>| nonzero | 0 | 1 | nonzero | extended DPD check and=20 > >>forward (6)| > >>| nonzero | 1 | 0 | nonzero | invalid, do not forward=20 > >>(3) | > >>| nonzero | 1 | 1 | nonzero | invalid, do not forward=20 > >>(2,3) | > >>+---------+----+----+----------------+------------------------- > >>----------+ > >> > >>1: When the df flag is clear, the ip_id must be a non-zero value. > >>=3D=3D=3D=3D> the question is, is a non-zero value really not = allowed?=20 > >>It could also be one of the 65536 values. > >> > >>2: When the df flag is checked, the mf flag must be cleared. > >> > >>3: When the df flag is checked, the fragment offset must be zero. > >>=3D=3D=3D=3D> Not exactly specified in RFC791. > >> > >>4: Tagging (resequencing) the ip_id should be performed=20 > once, on the=20 > >>edge > >>(ingress) of the MANET. As hosts could use a MANET router MANET=20 > >>interface to connect, tagging on all MANET interfaces is required. > >> > >>5: DPD algorithm uses > >>. > >> > >>6: Extended DPD algorithm uses > >> >>agmentOffset> > >>. > >> > >> > >> > >> > >> > >> > >> > >> > >>_______________________________________________ > >>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 > > >=20 >=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 Tue Jul 31 02:23: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 1IFl8x-0005nw-1Q; Tue, 31 Jul 2007 02:23:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IFl8u-0005nI-Dg for manet-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 02:23:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFl8u-0005n0-1W for manet@ietf.org; Tue, 31 Jul 2007 02:23:40 -0400 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFl8t-0002kE-A8 for manet@ietf.org; Tue, 31 Jul 2007 02:23:39 -0400 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.100]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1IFl8r-0003HY-OQ; Mon, 30 Jul 2007 23:23:38 -0700 In-Reply-To: <46A80FAD.5080403@cisco.com> References: <46A764AC.1000605@cisco.com> <46A766E1.2010508@cisco.com> <374005f30707251611u68cb874bpc1cf7a6dc7157cbd@mail.gmail.com> <46A80FAD.5080403@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85F77F67-E6AB-42DA-8425-5F53211EF48C@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [manet] Comments on link metrics Date: Mon, 30 Jul 2007 23:23:34 -0700 To: Bo Berry X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -2.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 7542284d7b4f03aa030784a8bdd0e892 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 On Jul 25, 2007, at 8:06 PM, Bo Berry wrote: > > Manet WG > > As we begin the discussions on the two link metric drafts > > OLSRv2 Update + Link Metrics for OLSRv2 > http://www3.ietf.org/proceedings/07jul/slides/manet-9.pdf > > Metrics TLV - Dean > http://www3.ietf.org/proceedings/07jul/slides/manet-8.pdf > > it would be useful, as Teco mentioned, to review previous > link metric work. > > > One reference can be found in > > RFC 4938, PPP Over Ethernet (PPPoE) Extensions for Credit > Flow and Link Metrics > > Here we used PPPoE links to logically connect a radio to > OSPF. Very simply, the radio link metrics are periodically > reported to the router. The router translates the link metrics > into a link cost and injects the new cost into OSPF > to influence routing. > > > Key considerations > > -There are many radio transceiver encoding schemes, 802.11 based > schemes are one. That being the case, we let the radio manage > the RF links with periodic link metric reports. The link > metrics were boiled down to an abstract list that the local > node can process without having to build in a lot of radio know-how. > > -The radio links are under constant change due to the nature > of RF. Given this environment, there is a need for heuristics > in the radio to throttle link metric reports. > > -Because routing protocols have different definitions of link cost, > it was important to be able to translate the link metrics > into a link cost for each routing protocol. This code is > really associated with the routing protocol. > > -When link metrics are translated into a new routing cost, > heuristics were again needed to throttle the effective change in > link cost to avoid excessive flooding. For example, > if the newly computed link cost is 1 point change, is there > really a need to flood the network? There has been a great deal of work in the research community on this topic in the past few years, mostly due to the fact that hopcount does not capture intermediate links, asymmetric links, or temporally varying links. Given the desire for internetworking in heterogeneous networks (or even in networks with dynamic bitrates such as 11.b), ETT [Draves, Mobicom 2004] is generally a good approach, but it assumes layer 2 retransmissions. Fundamentally, what you find is that purely hello/broadcast approaches don't work well, as they don't adapt quickly to link changes and cause a lot of packets to be lost. Some starting points for the wireless place include: Aguayo, D., Bicket, J., Biswas, S., Judd, G., and Morris, R. Link-level measurements from an 802.11b mesh network. In Proc. of the ACM SIGCOMM Conf., 2004 Couto, D.~D., Aguayo, D., Bicket, J., and Morris, R. A High-Throughput Path Metric for Multi-Hop Wireless Routing. In Proc. of the ACM MobiCom Conf., 2003. Draves, R., Padhye, J., and Zill, B. Comparison of routing metrics for static multi-hop wireless networks. In Proc. of the ACM SIGCOMM Conf., 2004 Draves, R., Padhye, J., and Zill, B. Routing in Multi-Radio, Multi-Hop Wireless Mesh Networks. In Proc. of the ACM MobiCom Conf., 2004. Kim, K.-H., and Shin, K. On Accurate Measurement of Link Quality in Multi-hop Wireless Mesh Networks. In Proc. of the ACM MobiCom Conf., 2006. Kim, M., and Noble, B. Mobile Network Estimation. In Proc. of the ACM MobiCom Conf., 2001. Koksal, C.~E., and Balakrishnan, H. Quality-Aware Routing Metrics for Time-Varying Wireless Mesh Networks. IEEE Journal of Selected Areas in Communications, Nov 2006. Srinivasan, K., and Levis, P. RSSI is Under Appreciated. In Proceedings of the Third ACM Workshop on Embedded Networked Sensors (EmNets), 2006. Srinivasan, K., Dutta, P., Tavakoli, A., and Levis, P. Some Implications of Low-Power Wireless to IP Routing In Proceedings of HotNets V, 2006. Woo, A., and Culler, D. Evaluation of Efficient Link Reliability Estimators for Low-Power Wireless Networks. Tech. Rep. CSD-03-1270, {UC Berkeley}, May 2004. Zhao, J., and Govindan, R. Understanding Packet Delivery Performance in Dense Wireless Sensor Networks. In Proc. of the ACM SenSys Conf., 2003. Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Jul 31 04:01: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 1IFmfQ-0007T2-4Z; Tue, 31 Jul 2007 04:01:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IFmfO-0007Sp-4f for manet-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 04:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFmfN-0007Sh-RO for manet@ietf.org; Tue, 31 Jul 2007 04:01:17 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFmfL-0004KY-VT for manet@ietf.org; Tue, 31 Jul 2007 04:01:17 -0400 Received: (qmail 32267 invoked from network); 31 Jul 2007 10:01:14 +0200 Received: from unknown (HELO Teco) (217.169.232.206) by server9.hosting2go.nl with SMTP; 31 Jul 2007 10:01:10 +0200 From: "Teco_Boot" To: "'Joe Macker'" Date: Tue, 31 Jul 2007 10:01:14 +0200 Message-ID: <000001c7d349$0cac24b0$b500800a@Teco> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfTSMRyptaS15goS3+0XUYt67Qh2g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 2.8 (++) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 Cc: manet@ietf.org Subject: [manet] 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: , Content-Type: multipart/mixed; boundary="===============0207429346==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============0207429346== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C7D359.D0373EA0" This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C7D359.D0373EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 *). ------=_NextPart_000_0001_01C7D359.D0373EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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           &= nbsp;           &n= bsp;           |

+-------------+-----------------+-------------+--------------------= ----------------------+

| = 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) =           |<= /span>

| not = present | not present     | present     | = DPD header DPD check and forward    =      |

+-------------+-----------------+-------------+--------------------= ----------------------+

 

1: DPD check based on = <sourceAddress::destinationAddress::Identification::FragmentOffset>=

 

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 = *).

 

 

 

------=_NextPart_000_0001_01C7D359.D0373EA0-- --===============0207429346== 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 --===============0207429346==--